Hi Rick and others,

Folks here at the San Lorenzo Valley Amateur Radio Club are very excited with HSMM-MESH. I don't have an article about our achievements, but here is an update.

Our most significant success is adding 2m/6m-repeater control via an HSMM-MESH link. This new control link eliminates our club's monthly telephone bill. I don't think we're ready to publish details, but at the repeater site we use a WRT54GL with an RS-232 port. This link to the repeater is one of three links that comprise our current, disconnected network of five nodes.

We have many eager members, working equipment, and rolling terrain that is covered with 200-foot redwood trees. So CLOS is a challenge. Generally, the two nodes on opposite rims of the valley can see each other, but sights to and from potential locations lower down are blocked by vegetation. To understand our dilemma, here is a link to a (large) web page that shows parts of the valley that are visible from my house. Click the "Satellite" link in the upper-right corner to see what we're presented with. Although the visible area is large, what I can see is mostly trees, not houses.

http://www.slvarc.org/k3rry.html

Our long-term goal is to get a more complete network installed that has at least two available connections to the Internet. Since our 11-km rim-to-rim link is surprisingly robust (even though it goes through a tree) my hope is that that we will be able to connect the network using more rim nodes. With improved coverage, our network will serve as connections for other, temporarily deployed HSMM-MESH nodes.

We've experimented with both commercial and home-brew antennas. Here are some of the home-brew ones:

https://www.slvarc.org/all-articles/100-home-brew-night-2012

Kerry Veenstra, K3RRY

Carl,

I agree that running opposite currents in each twisted pair is good and the plan
when running non-DC signals but, bad design or not, one pair in one direction and
one pair in the other is the IEEE standard (802.3af/802.3at) for PoE -- pairs 4&5
are DC+ and 7&8 are DC-. Doing it otherwise would force us to make our own PoE
adapters. Granted, that isn't difficult but not desired.

Not sure if the Kipster used 100μF in parallel with a 0.1μF or not -- that was my
first suggestion (EE Power Supplies 101). Still, I would think that such a combo
was already on the input side of the '54G's regulator and it's hard to drag most
o'scopes up to the top of a water tower to find out if the problem is transients or not.
(No, a small handheld 'scope wasn't available) We can guess/estimate/engineer all
we want but the fact of the matter is that the 10,000μF cap did do the trick and
it was left that way. Thanks for your input nonetheless!

-Rusty-

Is anyone doing Flash upgrades to WRT54G v5+ ?

I understand that Micronics makes a 4MB flash module that is pin compatible for the WRT54G.

It is also possible to replace the 2 MB flash chip in the WRT54G with a 4 MB flash chip. The Macronix International 29LV320BTC-90 is a suitable part although others may work as well. The user must first install a JTAG header and use a JTAG cable to back up the firmware, then replace the chip and restore the firmware with the JTAG cable. After testing for proper functionality of the modified unit, third-party firmware can be flashed using the JTAG cable and a suitable image file.

Any hardware hackers that can help would be appreciated.

Our terrain in the SF East Bay hills, between Oakland and the Central Valley, presents a similar problem with many deep inland valleys. 

Whether we like it or not, we will have to rely on five hilltop sites for nodes.  The good news is that there are multiple hops possible between these five sites, and one or another of them will reach into nearly every isolated pocket.

But we still will need a number of mesh nodes in each of those pockets to be truly useful.

I'm still very interested in any reflections from those hams who have lived with a growing local mesh over the last few years.  What did you observe that was crucial to getting people involved?

Glen

I made another experiment, this time using the binary intended for the WRT54G and GL instead of that intended for the GS. It also works, and the power LED now comes on -- amber, not green. The easy setup LED is now off. The LAN and WAN ports are still swapped. Incidentally, in order to revert back to DD-WRT from either of these I had to change the filename suffix of the DD-WRT binary from BIN to TRX -- otherwise HSMM-MESH wouldn't complete the firmware upgrade. But certainly it is possible, and easy, to run HSMM-MESH on a WTR54GS Travel Router.

Was down a couple of days.. I was getting worried!

Try reading over this one:

http://www.hsmm-mesh.org/documentation/96-using-the-mesh.html

It tells how to do it a bit easier I like to think, plus setting options for your NIC to make things work more smoothly

I think the snag you may be hitting is setting the IPs for the LOCAL NETWORK, a.k.a your main LAN, not the mesh lan.

Jim

Here's what I have and want to do.

I've got two routers with the mesh software successfully installed.  I would put one inside my house and plugged into the switch built into the DSL modem.  The second one I plan to hang from a pine tree with POE to power it and http://www.amazon.com/gp/product/B0046CBR3W/ref=ox_sc_act_title_10?ie=UTF8&m=A2LM6ZPY06LT1N probably using this antenna.  I can get it hung at about 60'.

I'll be in a rural area but when it gets installed I'll show it to the local club to try and get some more hams interested.

So I'm unsure how to proceed with the software settings.  I was following the instructions at this site and didn't get too far before running into a snag.  http://ohiopacket.org/index.php/Integrating_HSMM-MESH_into_an_existing_network

When I got to 2. it says to change the IP address to 1.240 and save it.  But the software said that was incorrect and wouldn't allow it to be saved.  

2. On the LAN section, change the IP address to an address which falls within the existing subnet. In this example we will choose 192.168.1.240. The subnet mask of 255.255.255.0 should be left as is. If you want to have the option of providing Internet access to HSMM-MESH, set the default gateway to 192.168.1.1. Defining the gateway does not automatically give HSMM-MESH Internet access, there is a checkbox in the WAN section which can be turned on and off as needed. It is also important to uncheck the "DHCP" option. Your existing router is handling DHCP services and should be the only DHCP server on the network.

So what's the best writeup on how to set up the routers with one being installed inside to the switch and one hanging up outside to form a mesh, share internet amongst the mesh and allow the mesh and internet to be shared locally through the ethernet cord.

Another thought:  10,000 μF is awfully large, and suggests your friend didn't know that electrolytic capacitors typically have considerable inductance of their own, making them useless for bypassing high-frequency transients.  The load variations you're talking about contain both low frequencies (which you would bypass with an electrolytic capacitor) and quite high frequencies into the GHz (which you would bypass, for example, with a ceramic, mica, or styrene capacitor).

If your friend had used, say, a 100μF electrolytic capacitor and a 0.1 μF ceramic capacitor in parallel, with short leads, he probably would have found that, even with inductance in the supply leads, operation would have been solid.  After all, anyone who ever designed power supplies knows that inductance in power-supply leads is generally a good thing.

Time to put on my EE hat.  Retired now, I'm an old design engineer.

The inductance is easily avoidable.  The four unused conductors in a Cat5e cable consist of two twisted pairs.  If you blithely use one twisted pair for the positive, and the other for the negative, then, sure enough, the inductance could be a problem.

If, however, you wire it so that the conductors in each twisted pair are carrying equal and opposite currents, the inductance will be reduced by as much as several orders of magnitude.  This occurs because inductance depends upon the creation of a magnetic field surrounding the wires -- and if two conductors are intimately close together and carrying equal currents in opposite directions they don't create a significant magnetic field -- the magnetic field each member of the pair would create is canceled by the other.  Thus they'll have very little inductance.

That's why the wires are twisted in the first place -- in order to avoid magnetic effects, which might couple them to other pairs.  Don't want that.

I'll bet your friend never thought about that, and used one pair in one direction, and the other pair in the other direction.  Bad practice. 

The real problem of running PoE on umpteen hundred feet of CAT5e is the inductance!  It causes problems when the current used by the WRT54G fluctuates!  It can AND will vary quite a bit.

This can be fixed by installing a large capacitor in parallel to the WRT54G at its end of the power cable.

Kip, AE5IB, found that a nice large electrolytic around 10,000-uF provided sufficient capacitance. Yes, smaller values were tried with the 180-ft of CAT5 cable that was in use but they didn't keep the router from going a bit nuts.

     -Rusty-

That was no rumor! There is/was an endian-ness or byte-sex problem in the secure plugin for OLSR. I put my corrections into the OLSR source code after the last HSMM-MESH release of v0.4.2, the OLSR maintainers have my fixes, and they have been in the last few of the official released builds. Unfortunately, said code hasn't been brought into the HSMM-MESH source code tree and we haven't had a subsequent release. Part of the delay in getting this out is that a minor release of the code would break things in that nodes with previous firmware versions would no longer work with nodes containing the fixed version. There's more to maintaining a project like this than just putting out code. A lot of people start belly-aching when things stop working, especially between minor releases.

Technically the code was incorrect for all CPU architectures! It was luck that same-byte-sex architectures could exchange the secure plugin info back and forth. Problems arose when you mixed certain CPU architectures. Since HSMM-MESH.org only produced code for the WRT54G the endian-ness of the secure plugin data was a non-issue. My experimentation with alternate routers discovered the actual issue. Finding the code that was burping (actually the missing code!) was a real trick as well. BTW, the CPUs in your PCs, Pandaboards, and Gumstix cards all share the same byte-sex or endian-ness. That is why they all mesh together if you have the secure plugin enabled. Throw in a mesh node with an Atheros chip set or a MIPS (not MIPS-el) chip set (to name two) and they won't mesh.

The 'secure' plugin is nothing more than a "secret" hankdshake between mesh nodes. If you don't have the secret handshake you simply don't get listed as part of the mesh but it does not stop you from connecting with other nodes directly with telnet, ssh, http or whatever protocol -- you just needed to know the remote node's IP address since your OLSRd doesn't collect the DNS entries for the other nodes. I think the HSMM-MESH project is about the only one using the secure plugin for OLSR. Since it does NOT provide any real security I'm hoping that our illustrious Chief Developer in Charge decides to remove it from the upcoming versions.

Instead of everyone trying to hack the code, it's far simpler to experiment by commenting out the secure plugin from the olsrd.conf file of all nodes involved if you want to mix nodes that have different byte orientations. This is the way I run my mesh at home because I dink and diddle with different types of routers.

As we've stated before, if you are doing something DIFFERENT with your mesh, please change the SSID of your mesh from HSMM-MESH to HSMM-MESH-YOURCALL or something of that ilk. This is the indicator we suggest to show that a given mesh is 'different'.

-Rusty-

There are (were?) two problems holding back the Bullet devices from working on the mesh.

The first rumor was there was an indian-ness problem in the radio and the code that made the secure module in the mesh fail.   As I remember, technically, the Bullet was correct, and the WRT54G's, X86 and ARM are all doing it "wrong".  I've personally built and run olsrd on x86, Pandaboards, and Gumstix w/o any problems and connected into the hsmm-mesh with security enabled, so I find it hard to believe that three platforms are wrong, but anyway.   It should be reasonable to make our own 'hacked' module that does whatever translation and basically uses a 'backwards' security module to work with the existing hsmm-mesh.    Anyway, I never got to see becuase you run into the bigger problem first.  

The 2nd issue was there was no ad-hoc support in the wifi stack used in revisions of software in the bullet and that kept you from getting a 'layer 2' connection to even start playing.    It's easy enough to build the latest openWRT which should have updated wifi stack to support adhoc, but mangling that to run on the bullet had it's own annoying buglist.  It builds, but doesn't have any of the goodies to setup root correctly and be workable.

On a whim, I looked at the latest 5.5 firmware release notes and it looks like they have fixed the ad-hoc problem.  Basically, it looks like they just picked up the latest linux projects and merged that into the ubnt firmware.  

If all that's broken is the security part, assuming that's even a real problem I might have enough free time to fix the other things that need attention.

 Has anybody looked into this in the last month or so?  I don't want to duplicate work that's being done.

Thanks,

KE5TNO