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 www.sears.com 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
--
for email reply remove "/" from address

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

"George Neuner" <gneuner2/@comcast.net> wrote in message
news:(E-Mail Removed)...
> 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 www.sears.com 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
> --
> for email reply remove "/" from address

"Sean" <(E-Mail Removed)> wrote in
news:F2xtd.649$(E-Mail Removed):

> 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
>

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

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

Good luck... Terry

On Wed, 08 Dec 2004 06:20:21 GMT, "Sean" <(E-Mail Removed)>
wrote:

>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

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

--
for email reply remove "/" from address

On Tue, 07 Dec 2004 17:06:56 -0500, George Neuner
<gneuner2/@comcast.net> wrote:

Reflashing solved the problem. Thanks everyone.

George
--
for email reply remove "/" from address

On Wed, 08 Dec 2004 16:48:17 -0500, George Neuner
<gneuner2/@comcast.net> wrote:

>On Tue, 07 Dec 2004 17:06:56 -0500, George Neuner
><gneuner2/@comcast.net> wrote:
>
>Reflashing solved the problem. Thanks everyone.

Glad it's sorted!
But it still intrigues me as to why that particular site caused it...
--
Interesting Xmas gifts: <http://www.awin1.com/tclick.php?id=405&mid=182> . <http://BizOrg.co.uk/shopping/>
Locate your Mobile phone: <http://www.bizorg.co.uk/news.html>

On Thu, 09 Dec 2004 08:08:45 +0000, David Quinton
<(E-Mail Removed)> wrote:

>On Wed, 08 Dec 2004 16:48:17 -0500, George Neuner
><gneuner2/@comcast.net> wrote:
>
>>On Tue, 07 Dec 2004 17:06:56 -0500, George Neuner
>><gneuner2/@comcast.net> wrote:
>>
>>Reflashing solved the problem. Thanks everyone.
>
>Glad it's sorted!
>But it still intrigues me as to why that particular site caused it...

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
--
for email reply remove "/" from address

On Thu, 09 Dec 2004 11:31:59 -0500, George Neuner
<gneuner2/@comcast.net> wrote:

>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

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.

2. 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.

3. 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.


--
Jeff Liebermann (E-Mail Removed)
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 AE6KS 831-336-2558

On Thu, 09 Dec 2004 09:25:14 -0800, Jeff Liebermann
<(E-Mail Removed)> wrote:

>On Thu, 09 Dec 2004 11:31:59 -0500, George Neuner
><gneuner2/@comcast.net> wrote:
>
>>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
>
>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.

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.

>2. 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.

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.

>3. 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.

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
--
for email reply remove "/" from address