Because of the geometry of the jack on the back of the 54G, the plug with the 2.5 mm hole seems to work with either the 2.1 or 2.5 jack.  I believe AE5AE is correct on the sizes, which would be "size M,"  but "size N" seems to work, too.

WRT54G v1.0 (5-volt supply) used a barrel connector OD=5.5mm ID=2.5mm.

Newer models from v1.1 up (12-volt supply) used the same except ID=2.1mm

This made it difficult to put 12v into a 5v box.

The length of the conductor plus ring was about 10mm so anything longer (within reason) should be OK.

Good point,

The Ubiquiti gear is mostly single port, to link multiple Ubiquiti devices or multiple local computers together you would need to add a switch,  and if you need a WAN port it would need to be a vlan capable switch as noted in the install instructions.

If the node was tower mounted this was often still needed anyways (take a look at a lot of the outdoor setups in weatherproof boxes )

It is certainly a point to keep in mind when looking at the station setup.

Ubiquiti is great in a lot of ways, but consider your application.  The 54G has a 4 port switch, and WAN port, which counts a lot in some applications. 

Some hints here:

http://www.broadband-hamnet.org/documentation/68-firmware-installation-instructions.html

Look for the TFTP section.

http://www.broadband-hamnet.org/documentation/71-using-safe-mode-to-reset-a-forgotten-password.html

I'm a confirmed newbie in this area and probably suffering from information overload.  I'm quite confused over all the IP type addresses floating around even in a simple node to node system.  What I am trying to do is to omit the computer(s) in a very simple system whereby one plain old telephone is connected to an ATA (Linksys PAP2) at each of two nodes using WRT54GL's and BBHN 1.0.0.

I have gotten this to work fine using my wired LAN instead of the WRT54GL's.  I followed Linksys document id: 108746 (Configuring IP dialing on PAP2), only I modified it to use only line 2 on each ATA and to use a dial code of "77" for each phone to dial/ring/connect to the other.  Should be simple, but when I put the WRT54's in there instead of my wired LAN, I cannot get it to work.

I feel my problem is most likely in the dial plan.  Maybe someone can spot the error, or else give me some advice how it should all be set up.  I'm open to suggestions.  I'd like to get this working for a short range demonstration before a group coming up in a few days.

Here is the PAP2 dial plan used at the AE5K-104 node:

(77S0<:@AE5K-105:5061>)

and the AE5K-105 node:

(77S0<:@AE5K-104:5061>)

But I have also tried the various IP addresses associated with either node in place of the "AE5K-105" to no avail.  As I said before, it worked like a charm using assigned wired LAN addresses in place of the node name. (And I realize this simplistic configuration could be just a start toward more complex systems.)

Please steer me in the right direction before I wear out my RJ45 connectors!  Thanks...

Don AE5K

Hi Conrad,

I believe it was a discussion you were having with someone else that provided me the heads up on the red led of the AirGrid M2 HP. I appreciate the tip during that discussion as it was primary in discovering what was creating my situation. 

Yes, my AirGrid M2 HP has the 0xe242 boardid, so I will keep an eye out for the update. Thank you for the info regarding this. I have a second AirGrid M2 HP as well as a NanoStation M2 and a Bullet 2HP to experiment with.

Now that I have a "working" system, I can reread a lot of the info over again to gain a different perspective as to how best to design a system and be able to share with others in our area with some of the more difficult information that needs to be digested. I now have a better understanding of how fickle the RF paths of these things can be.

The forum here has been very helpful.

Mike, N7KMJ

Alright, I made another mistake.  I took one of my Linksys Routers that was flashed with the HSMM-Program v.1 and changed the settings.   I changed the node type from “Mesh Node” to I think Gateway Mesh.   Now  I can’t access the router no matter how hard I try.

Anyone have any ideas?

Thanks in advance.

I'm not aware of an overall diagram that's been already built but some of the key details are under About OLSR and About OpenWRT on the Left side of the screen.

"What are the specific "firmware" pieces and how are they separate from BBHN? How do the pieces interact, such that if I upgrade to new hardware, I know what pieces I must download?"

Seperate pieces of firmware do not exist, the firmware is the compilation of all software needed to run a BBHN node.  This is all taken part of as a supported built firmware, you change devices to a new supported device you install the full firmware the new image on the unit and everything you need to run is there.

Core among these software components are the operating system (Linux based) OLSRD, programs to provide an easy configuration (the User Interface) and various other ancillary packages to provide services to the network(DNS/DHCP/etc)

All the default software is essentially controlled by the setup code to be self configuring and meet the standards of BBHN's ecosystem.

Well a couple items come to mind.

First the OpenSSL library is about 1mb in size,  that's a lot of additional space on these nodes which may depending upon where you are at, bring little reward.

Adding SSL may concern some operators so it would certainly have to be operators choice (My nodes are running the block known encryption package which means I wouldn't permit SSL admin to traverse my node)

I've actually been playing with the thought of attack this like packet did,  either using a partial passcode, or even better, using a One Time Password so the same code will never work again.

I think that SSL for the node admin page wouldn't be a bad thing to look into.  a self-signed certificate could work; I've been toying with the idea of an addon to the node interface that would allow a user to generate a certificate right in the GUI.  From there, you could just have your browser accept the certificate, and it should let you know if changes due to someone tampering with it.  As long as this was done before the node goes on the air I would think it would be pretty secure and relatively easy to work with.

OH! And on a related note...

I am running an FBB BBS on a Raspberry Pi, and I'm very interested in how Rpi's are being used as mesh nodes. I read G6BPQ's post about his software for Rpi, and his use of it with a LinkSys router. I have an email in to him asking for more details, but maybe someone else here is doing that and can tell me which software runs on the Pi, and what runs on the router?

Joe

I'm newly interested in HSMM-MESH, and I've been casually perusing this website for a couple of days now. I am looking for a summary architecture diagram of the hardware/software components talked about here.

I am a technical person (professionally a computer engineer), and I understand networks and TCP/IP, and I'm a long time ham with digital inclinations. So, I am not looking for a tutorial about networks or bandwidth, or noise floors. I want to know how the pieces being developed interconnect.

Does such a diagram exist? If so, please someone point me to it !

Specific question for example...

On one of the pages here, it announces that Ubiquiti firmware on the download site is compatible with BBHN 1.somethingorother . Other places give specific instructions on how to download firmware to a LinkSys router to make it a complete mesh node.

What are the specific "firmware" pieces and how are they separate from BBHN? How do the pieces interact, such that if I upgrade to new hardware, I know what pieces I must download?

I am sure I will eventually find all the information I need here, if I look long enough. But a diagram or two would speed a newbie's process immensely.

Joe

AG6QO@AG6QO.#NCA.CA.USA.NOAM

Ah that little red led works again :)

It has become a diagnostic tool on my bench when testing to know if I broke something or not. Funny enough I never meant to use it as much as I do, it's one of the first things I look at when I can't get a connection.

Polarization has quite an effect ( you can see why horizontal is recommended over verticle to git rid of local noise)

In regards to the banner warning: if the board is is "0xe242" I was made aware of it the other day and proper full support should be in the next major release (planning to ship to beta soon).  If it is a diffrent ID than the procedure listed http://www.broadband-hamnet.org/hsmm-mesh-forums/view-postlist/forum-37-ubnt-firmware/topic-759-help-us-gather-info-on-ubnt-devices.html would be appreciated.

Expect some issue with wifi control (power/antenna selection) but otherwise mos all other features should work normally.

We're finding out Ubiquiti has a lot of model IDs out there and many have slight differences requiered to support correctly but we are commited to adding them in as we receive them.

Howdy,

A ham friend mentioned he read on the internet about the neat networking system.. Broadband-hamnet.
We've enjoyed networking via AX25 and Linux many years ago, but it fell to the wayside due to life
and other reasons. I've recently talked him into Ubuntu Linux on his RaspberryPi.

Anyway, I researched this Broadband-Hamnet and discovered it to be exactly what we were trying to
accomplish back in our AX25 days. For another networking project, I had purchased a couple of Ubiquiti
AirGrid M2 HP systems, but the project never seen completion and were laying around. I already had
a Linksys WRT54GL router. So, curosity got the better of me and I downloaded the firmware for the
WRT54GL and the AirGrid M2 HP. Both firmware uploads went flawlessly.

I have a Dell 2850 server running Zoneminder security camera system with six cameras and wview
weather station running Davis WeatherPro system. After understanding what capabilities Broadband-Hamnet possesed, my goal was to set up a system with access to the Dell 2850 server, Zoneminder and wview.

The AirGrid M2 HP was Cat5'd to the Dell 2850 via eth1 and the WRT54GL was Cat5'd to my laptop via eth0. Both systems came up as expected via direct dotted addressing or via localnode.local.mesh:8080,but could not access either or. I set up the addressing for linking to Zoneminder and wview. No linking worked. I started with "direct" first then experimented with "nat". After three days, frustration started setting in.

The "dumbest things" part of this post... I decided to revert back to basics and started "pinging"
addresses. All addresses pinged just fine except... to the LAN port of the AirGrid M2 HP. The ping
started out ok, but then dropped out, then came back, then dropped out again. I thought "this is weird".

The path between the WRT54GL and the AirGrid was no more than 40ft. I figured the path would never
be and issue in such a short distance. I was WRONG! I had the AirGrid (without the grid reflector)
laying flat on a book. During my pings, I noticed the red led on the AirGrid going on and off. Laying
flat meant a "horizontal" polarization. I thought, "what the heck" and situated it in the "vertical"
position and to my amazement... EVERYTHING... stated working perfectly!!! I was able to link into
the Zoneminder system as well as the wview weather system via the Broadband-Hamnet system. FANTASTIC!!

The "direct" default system does work straight away. But, sometimes... the "dumbest" things prevent
success. ( smile )

Thanks to everyone involved with putting together this very capable system. I'm on our local VHF repeater
getting other hams in our area interested. Now that I can absolutely claim "IT WORKS", interest will
surely grow in NE Oregon.

Thanks again...

73
Mike, N7KMJ

P.S.  I'm getting a !!!! UNTESTED HARDWARE !!!! banner on the AirGrid M2 HP link page. Clicking
on the link displays a !!!! UNSUPPORTED DEVICE !!!! and suggests to file a ticket with my
experience. The AirGrid M2 HP seems to be working just fine. How do I file a ticket or do
I just need to update something?