website crashing router ?!?

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
10 answers Last reply
More about website crashing router
  1. 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
  2. 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?
  3. Archived from groups: alt.internet.wireless (More info?)

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

    Good luck... Terry
  4. 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
  5. 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
  6. 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>
  7. 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
  8. 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
  9. 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
  10. 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
Ask a new question

Read More

Wireless Crash Wireless Networking