I originally posted this in the Firmware forum as a follow on to another question, but thought it might help to put it out here under "Problems"...duh...so if you think you're reading this twice, you're probably right!

I have two nodes, a WRT54GS v1 and a WRT54G v3. I upgraded both from BBHN v1.0.0 to v1.1.2 using my home PC, and both of them come up on it and work just fine. However, the GS is used in my shack and is connected to a repurposed HP Compaq t5000 thin client running Windows CE .NET 4.2 as a dedicated terminal. With release 1.0.0 the GS and the t5000 worked together beautifully; now after the 1.1.2 upgrade, they won't talk to each other. But, if I connect the G to the thin client it works just fine on 1.1.2, so there's definitely something different in the GS that's keeping it from working exactly like the G, but I can't figure out what it is or if I can correct it in some way. I really would like to get this resolved; I want to take advantage of the extra memory in the GS to support applications, but maintain the direct access to it using the thin client.

At the moment the simple better solution is to go with Ubiquiti gear with those concerns mentioned.

I personally would not recommend using Linksys as part of an EMCOM deployment for numerous reasons including Power draw, Operating Condition support (temp and moisture), Performance of the hardware (cpu speed and packet forward ability), Performance of the RF Hardware (stronger RF output, no loss installation, higher quality receiver)

I've already seen multiple networks do full rip and replace on older generation Linksys gear to Ubiquiti as early as the 1.0.1 release.

A fix is in the repo but its holding because we are working much bigger tickets right now but if you have access to the backend and an unaffected device you can change it manually if need be, all details are in the code repo (note: we do not have the resources to walk users through this procedure at this time)

While UBNT is the preferred option... If you are deferring this cost, an alternative quick-and-dirty workaround, if you or a friend know ssh and vi, is to edit the /etc/config/network file and separate the ports to be in a unique vlan 0, 1, or 2 for your needs. This defect occurs when mixing vlans on same port--a desirable feature to plug any cable in any port. In my case, I had a UBNT AirCam that was completely ignored. I edited the file this way to get it working:

config switch eth0

    option vlan0 "2 3 4 5*"

    option vlan1 "0 5"

    option vlan2 "1t 5t "

vlan2 = DtD = port 1 (which may be port 4 label on the back depending on version)

vlan1 = WAN stays the same

vlan0 = LAN ports with the Aircam.

Joe AE6XE

If you are not running this on a production (served agency) network a beta release of version 3.0.0 has been posted to the Software Downloads section of the website under "Experimental Builds".

3.0.0 uses a V3 protocol so it will not link with older networks.  It is believed to resolve a number of issues (including devices not working off a Linksys router)  however as a beta build it has not been fully tested so unknown issues may exist in it so if you have a few nodes you use for testing you may want to install it with those.