website crashing router ?!?

[Guest]

Archived from groups: alt.internet.wireless (More info?)

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]

Archived from groups: alt.internet.wireless (More info?)

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:nk8cr05fdp0sufq1dloah3180l272fp7e5@4ax.com...
> 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

 

[Guest]

Archived from groups: alt.internet.wireless (More info?)

"Sean" <shartling@skybeam.com> wrote in
news:F2xtd.649$6N2.366@news.flashnewsgroups.com:

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

 

[Guest]

Archived from groups: alt.internet.wireless (More info?)

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

Good luck... Terry

 

[Guest]

Archived from groups: alt.internet.wireless (More info?)

On Wed, 08 Dec 2004 06:20:21 GMT, "Sean" <shartling@skybeam.com>
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

 

[Guest]

Archived from groups: alt.internet.wireless (More info?)

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

 

[Guest]

Archived from groups: alt.internet.wireless (More info?)

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>

 

[Guest]

Archived from groups: alt.internet.wireless (More info?)

On Thu, 09 Dec 2004 08:08:45 +0000, David Quinton
<usenet_2004D_email@REMOVETHISBITbizorg.co.uk> 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

 

[Guest]

Archived from groups: alt.internet.wireless (More info?)

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 jeffl@comix.santa-cruz.ca.us
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 AE6KS 831-336-2558

 

[Guest]

Archived from groups: alt.internet.wireless (More info?)

On Thu, 09 Dec 2004 09:25:14 -0800, Jeff Liebermann
<jeffl@comix.santa-cruz.ca.us> 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

 

[Guest]

Archived from groups: alt.internet.wireless (More info?)

On Thu, 09 Dec 2004 17:05:14 -0500, George Neuner
<gneuner2/@comcast.net> wrote:

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

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.

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

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.

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

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.


--
# Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
# 831.336.2558 voice http://www.LearnByDestroying.com
# jeffl@comix.santa-cruz.ca.us
# 831.421.6491 digital_pager jeffl@cruzio.com AE6KS