I've verified a somewhat obscure bug in the new mesh 1.1.2 upgrade on WRT54GS ver 1.0 (S/N starts with CGN1).  It has to do with certain NICs on certain computers connecting to the LAN ports.  My routers were on 1.0.0 and all LAN ports were working fine with all computers and devices.  However after upgrading to ver 1.1.2 two of my Dell computers (with Broadcom NICs, although I don't know if this is indicative of the issue) cannot talk to the router when connected to the LAN ports.  They do not get DHCP addresses, and if set for a static IP in the proper LAN range for the router, they do not communicate to the router or other devices on the LAN.

I have two of these WRT54GS ver 1.0 and both experience the same issue.  I've reloaded both twice with ver 1.1.2 and same issue.  I have a WRT54GS ver 2.1 and a ver 1.1 and both of these work just fine.  The real strange part of this is that the 1.1.2 upgrade works fine with these same computers right after it is loaded when it is in the "interim" mode, where the IP range is 172.27.0.X.  These Dells, one on Windows XP and one running Centos Linux ver 5.7, get an IP fine in the 172.27.0.X network.  It's after I name the node and set the password for the first time (making no other changes to the config), it reboots and comes up as an active node that the issue occurs.  Other devices like a Polycom SIP phone and an HP laptop on Windows 8 get DHCP just fine.  And all other functions of the node seem to be fine; they can be seen on the WAN side by other nodes running 1.1.2 firmware and can be connected to and managed, and those devices that are properly getting an IP address can be seen as well.

Like I said, it's a pretty obscure issue but is a bug none the less so I thought I'd post it.  I'm willing to do any testing anyone would like, just let me know.  Also, is there a definitive version listing, as I'd like to see what other changes were made in 1.1.2 versus 1.0.0, as I have other LAN and WAN networking scenarios that changed between the these releases.  By the way, what is the meaning of the "(mid)" seen next to neighbor nodes now with 1.1.2?

73, Bill, N4SV

Thank you for the report,

This sounds like it is similar to BBHN->ticket:55 and likely is from the same root cause.

http://www.broadband-hamnet.org/hsmm-mesh-forums/view-postlist/forum-3-firmware/topic-1038-v10x-to-v112-one-pc-discovered-other-not.html

http://www.broadband-hamnet.org/hsmm-mesh-forums/view-postlist/forum-3-firmware/topic-1050-v10-to-v112-no-dhcp-for-wrt54gs-v10.html

Release notes: http://www.broadband-hamnet.org/documentation/195-bbhn110-firmware-release

1.1.0 was basically a compatibility only upgrade to make the Linksys units work in a similar fashion to how the Ubiquiti units would be working,  1.1.1/1.1.2 were bugfixes to initial release of items broken in 1.1.0.  No 1.0.0 bugs have been fixed in the 1.1.x line for Linksys and there is no known bug list for 1.0.0 Linksys builds (The Ubiquiti build however has all its known bugs from its 1.0.1 in the ticket system)

Mid refers to the use of Device to Device Linking (DTDLINK) created for the Ubiquiti devices and ported to the Linksys devices.  It is a signal that means the node is connected on 2 or more  mesh interfaces,  on the stock build this is WIFI and the DTDLINK virtual interface that is created at boot.

As noted in the previous threads, please refer to to BBHN->ticket:55 for details and status on the issue. The ticket system handles more of the updates as it tracks the progress of issues.

Also as noted in other threads, the issue is with the WRT hardware, there are work around in the current release such as using an external switch to buffer between the hardware in the WRT54 and the devices you wish to use.

Yes the bug came out in 1.1.0, because we started doing more with the hardware,  tasks the hardware should be able to handle, the fact that it has issue wasn't seen as part of 1.0.0 and below is because we were not attempting to utilize that part of the hardware, the bug however still existed in the hardware and just wasn't seen.

Conrad, can you provide a link to "Ticket 55:", as I'd like to read this issue over a bit more.  I put ticket 55 in the site search but came up empty.  You indicate a workaround is to add an external Ethernet switch, but until I try it I am skeptical this will work.  As I have proven in my testing not all NICs are susceptible, some work on the LAN and some don't.  The type of switch might work and might not and so doesn't seem a reliable workaround, and certainly can't be considered a "fix".  Guess I am looking for a more technical description of the issue to fully understand.  You say it is a hardware issue, that in releases beyond 1.0.0 you are utilizing the Linksys hardware differently and because of an issue in Linksys the LAN stops working properly.  Again as I said before, if you change your code and something breaks (and you can't fix the hardware) then it seems you want to revert that part of the code causing the issue back to the way it was done in 1.0.0, even if you loose some other added new functionality.  Something as basic is if the LAN works or not seems a pretty important feature to have to "work around" to make functional, don't you think.

Bill, N4SV

This should get you there

http://ubnt.hsmm-mesh.org/products/BBHN/ticket/55

I have had this same problem with a WRT54G VERSION 2.0 at my location. I have also reloaded the software twice (once by RF link because I couldn't talk to it on the Ethernet) #### Still scratching my head over that one but much more to do to upgrade my network to 1.1.2. 73 Dave WA5DJJ

I have loaded 1.1.2 on WRT54GS versions 1, 2, and 4.  I have not had a problem.  

As other posters in this thread have suggested, I believe that this is a conflict between the Ethernet chips on your computer and the WRT54GS.  I am using a Toshiba Laptiop.  The Ethernet properties indicate a Realtek chip set.  This is a hardware bug in the older WRT54G routers.  If the conflicting chip set is also used in an Ethernet switch then I would expect the same problem.  

If you have a different computer, you might want to try that.  

Clint, AE5CA

To my knowledge and all the reports I have seen it is not an issue in a default install of 3.0.0 and above.

Everyone I have seen comment on it says that it works.