WAP54G firmware upgrade goes awry

Robert Coe · 2006-06-18T18:52:25+00:00

The other day I upgraded the firmware on one of my Linksys WAP54G accesspoints from 2.08 to 3.04. I did it remotely from a PC in another building. Allwent well until the upgrade was declared complete, whereupon the access pointbecame totally unresponsive. It continued to serve wireless clients, but couldnot be managed. Even manually rebooting didn't help. I finally had to swap itout, reset it to factory settings, and reconfigure it from scratch. (Theupgrade did "take"; the displayed firmware level is now 3.04.)Just to make sure it wasn't a fluke, I did the same thing to another WAP54Gover the weekend, from home. Now I can't contact that one either, so I guessI'll have to swap it out tomorrow and reconfigure it from scratch.Is this a known problem? Is there a workaround (installing an intermediateupgrade, for example)? I've got about a dozen more WAP54Gs I'd like toupgrade, and swapping them all out would be a pain.Bob

Jun 18, 2006 23 Replies

Rate this thread:

John Navas 20 years ago

On Sat, 01 Jul 2006 10:03:18 -0700, Jeff Liebermann wrote in :

You are correct, as I noted in an earlier response.

Here I beg to differ. A network bridge doesn't have anything to do with IP addresses since it operates on the data link layer. Thus a gateway address and netmask aren't meaningful to the bridge, especially since they won't necessarily be related to the proper port. In other words, they are only meaningful to the management module. The correct thing for the bridge to do is to either learn the correct port from the incoming Ethernet management frame, or flood the response to all ports, initially at least, learning which port to use for future responses, just as it does with all other network traffic.

Vote

Jeff Liebermann 20 years ago

John Navas hath wroth:

Generally true for most consumer access points and bridges. Wwrong for the better bridges and access points. The higher end devices all have syslog, ntp, snmp, smtp for emailing log files, dnsmasq, and other services that usually require internet access to work. Without these, the bridge would not need a gateway to the internet as in a typical commodity access point. But, with these services, a functional gateway is a requirement.

Another example is the typical print server. Many of these can automagically check for firmware updates from the internal web based admin interface. However, that doesn't work unless the default gateway is configured and functioning. Of course, if IPP (internet printing protocol) is being used, the gateway is manditory.

Management and services features.

I don't think a bridge can determine the default gateway by this method.

Vote

John Navas 20 years ago

On Mon, 03 Jul 2006 19:49:18 -0700, Jeff Liebermann wrote in :

Sure, but those are management services that aren't really part of the bridge -- the management module is functionally separate (and is even physically separate with some devices), and a gateway is only necessary when leaving local subnets by means of a router, which isn't true in many cases.

Right, but not part of the bridge.

True, but it will work fine when the source is on a local subnet, as it often is. I personally think it's a bad idea to have network hardware devices making non-local connections on their own.

Vote