website crashing router ?!?

Hi all,

Got a crazy but repeatable crash situation.

I have a Netgear WGT624v1 with firmware 4.2.4 (the latest AFAIK). Fragmentation limit is set to 1536 and RTS/CTS to 768.

If I go to the

formatting link
store locator page and enter my zip code (01890 if anyone cares to try it), the router crashes immediately upon relaying the resulting web page. There are no other symptoms of failure other than immediately losing internet access.

AFAICT, the wireless AP stays up - new clients will associate after the crash, but no services (DHCP, DNS, routing, configuration, etc.) are available ... even from wired nodes ... until I cycle power on the device.

The crash is completely repeatable - it happens every single time I try and it doesn't matter whether I initiate it from a wired or a wireless node. It seems like some data from the page is causing the crash. I reported the situation to Netgear but I haven't heard anything back from them yet.

I have never seen or even heard of something like this before. Has it happened to anyone else? Does anyone know what causes it?

Thanks, George

Reply to
George Neuner
Loading thread data ...

Sorry, page don't crash for me. Try reflashing the firmware, otherwise it appears to be a boat ancor.

Sean Hartling Skybeam High Speed Wireless Internet

Reply to
Sean

"Sean" wrote in news:F2xtd.649$ snipped-for-privacy@news.flashnewsgroups.com:

What do you mean "boat ancor"? That's what the router should be used for?

Reply to
The Chairman

Tried both wired and wireless. No problem using Belkin equipment.

Good luck... Terry

Reply to
Wiz-z-z

Wierd. It has crashed about a dozen times on me and only when I touch that particular web page. Nothing else I do seems to bother it.

I'll reset and reflash it. Maybe something didn't take.

George

Reply to
George Neuner

Reflashing solved the problem. Thanks everyone.

George

Reply to
George Neuner

Glad it's sorted! But it still intrigues me as to why that particular site caused it...

Reply to
David Quinton

Oh, it's easy enough. Some possibilities.

  1. NAT requires that the router sniff the contents of the data packets to deal with brain dead protocols such as ftp, games, IM, H.323, etc) that do not supply enough information in the header to adquately rescribble the header. While all the packets should have been http, sniffing the contents might have yielded weird results.

  1. When you flash a router, you should always reset it to defaults. There are lots of registers that are set by the firmware that are not easily accessible from the web based config. Flashing does not always reset everything and the firmware may be using garbage for one of it's parameters.

  2. Some ethernet switches have diagnostic modes that are entered by a long and obscure character sequence. Chances are very slim that you'll accidentally encounter one of these, but it does happen.
Reply to
Jeff Liebermann

I also would love to know what caused the crash. I'm a professional software engineer and have written a number of network apps. I have seen connections permanently stalled by mismatched MTUs and whatnot, but in 15 years I have never before seen any commercially available router actually crash due to a connection.

George

Reply to
George Neuner

Yeah, but most SOHO gateway/routers only sniff protocols on connections directly to the router using the protocol's default port. In this case the outgoing HTTP connection was not addressed to the router and should simply have been passed through with NAT.

Good advice. I do reset factory defaults whenever possible before I do a firmware upgrade. I learned that the hard way many years ago when I destroyed an expensive flash modem.

I've never seen any switch or router with the general capability to sniff commands out of a forwarded data circuit. Every unit I've ever encountered either had out-of-band control or required in-band commands be sent directly to its own network address. The only exceptions were units that would also respond to a certain set of commands sent to the network broadcast address or to a multicast address. That might be what you are referring to ... although IMO "enter diagnostic mode" should not be a broadcast command.

Yeah I know the internal command port is "just another port" and the unit "forwards" to itself when contacted directly. Still command recognition should be limited to input on that unique control port and not be generally available on the "normal" forwarding ports.

George

Reply to
George Neuner

I beg to differ slightly. Cheapo routers sniff ALL unicast packets because many of the TCP headers (RFC793) do not contain the both the source and destination port numbers sufficient to define the service type. NAT reasigns port numbers by protocol and session, so the port numbers get rapidly scrambled anyway. It's much easier to simply decode everything and use a decision tree to determine if the contents define a known protocol (ftp, games, IRC, H.323, etc) that insists on using almost random port numbers.

Many of the current crop of cheapo routers don't have any sanity check on flash updates. With some companys recycling model numbers, it's easy enough to upload the wrong flash and trash the device. Some don't even have a checksum/CRC check which means you can upload garbage. Some save their settings as a binary image of the memory map, which screws up badly if you upload it to a router with a different firmware image. I found that one the hard way on a "mass install" using a saved image.

Broadcom has some ethernet switch chips (exact numbers lost in my notes somewhere) that use in-band signalling and use the "extra" port for some type of switch to router CPU communications. I found out the hard way that the diagnostic enable bit pattern would work with any port. Someone found a graphics image that accidentally had the correct pattern and would effectively lock up the switch when viewed (through the switch). The good news is that it only looks at data going into a port, not out of a port, so you would usually need to be sending the diagnostic enable bit pattern, instead of receiving it. That cuts down the odds of accidentally hitting it considerably.

Reply to
Jeff Liebermann

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.