BeggerBelief
New Around Here
Hi,
been a lurker on this site for a number of months, thought now is an ideal time to make my first post.
FYI, and a request to see if anybody else can reproduce. I have a support ticket open with Netgear, but the response hasn't been too favourable in my opinion, they simply want to close the case.
Anyway, recently purchased a netgear switch GS724v3 (firmware 5.0.2.14) for home/lab use. Set up a basic lan and was investigating some network issue on my NAS, large number of errors on particular ports. Performed some basic trouble shooting steps, including pings of large packets when i observed strange behaviour on the network. My local interface kept on dropping. Turns out the switch was reloading, and continued to reload until i stopped the ping.
Dec 7 19:52:21 192.168.0.239 Dec 07 19:53:18 192.168.0.239-1 UNKN[2188695972]: sntp_client.c(1735) 922 %% SNTP: system clock synchronized on Tue Dec 07 19:53:18 2010 UTC
Dec 7 19:54:13 192.168.0.239 Jan 01 00:00:33 192.168.0.239-1 TRAPMGR[2185027644]: traputil.c(600) 31 %% Cold Start: Unit: 0
I was able to reproduce at will by simple pinging the management address ( eg 192.168.0.239). Initially performing a ping flood, after about 3172 (ish) packets the switch reloaded. Further tests without flooding (but large pings) caused it to reload after 55 or so packets!! maybe more time based than volume
On reseting the switch back to factory defaults, reinstalling a newly downloaded version of the latest firmware (5.0.2.14), the issue wasn't reproducible. However simply re-enabling the max frame size (default 1518 -> 9126) on the connected interfaces, I was able to at will, reproduce the issue.
simply executing the (ping -s 65507 192.168.0.239) seemed to cause the issue. Other OS may not allow you running such a command, i just happened to be root on my Mac (osx 10.6) at the time. obviously Jumbo frame support is required. I tried from another Mac, same result. Not been able to try from Windows/linux as i do not have a gig interface in either of my other machines.
be interested if anybody else can confirm the behaviour.
Obviously if any DoS protection is enabled (ICMP size etc) should prevent this particular issue and vector, but may not totally resolve the underlying issue. based on my tests, i was unable to reproduce when setting the max frame size to 9125 bytes or less, so appears to be maybe some simple buffer-overflow/bounds checking issue (although the potential possibilities this opens is worrying).
In addition, from my limited testing, this was only traffic targeted at the mgmt ip, so make sure the mgmt vlan is on a trusted network and not external (sounds obvious i know), and change the default mgmt IP, maybe consider disabling Jumbo frames.
May not be anything to worry about, certain factor need to be in place etc, without further details from Netgear, hard to say.
Will follow up with anything else i hear.
Cheers
BeggersBelief
been a lurker on this site for a number of months, thought now is an ideal time to make my first post.
FYI, and a request to see if anybody else can reproduce. I have a support ticket open with Netgear, but the response hasn't been too favourable in my opinion, they simply want to close the case.
Anyway, recently purchased a netgear switch GS724v3 (firmware 5.0.2.14) for home/lab use. Set up a basic lan and was investigating some network issue on my NAS, large number of errors on particular ports. Performed some basic trouble shooting steps, including pings of large packets when i observed strange behaviour on the network. My local interface kept on dropping. Turns out the switch was reloading, and continued to reload until i stopped the ping.
Dec 7 19:52:21 192.168.0.239 Dec 07 19:53:18 192.168.0.239-1 UNKN[2188695972]: sntp_client.c(1735) 922 %% SNTP: system clock synchronized on Tue Dec 07 19:53:18 2010 UTC
Dec 7 19:54:13 192.168.0.239 Jan 01 00:00:33 192.168.0.239-1 TRAPMGR[2185027644]: traputil.c(600) 31 %% Cold Start: Unit: 0
I was able to reproduce at will by simple pinging the management address ( eg 192.168.0.239). Initially performing a ping flood, after about 3172 (ish) packets the switch reloaded. Further tests without flooding (but large pings) caused it to reload after 55 or so packets!! maybe more time based than volume
On reseting the switch back to factory defaults, reinstalling a newly downloaded version of the latest firmware (5.0.2.14), the issue wasn't reproducible. However simply re-enabling the max frame size (default 1518 -> 9126) on the connected interfaces, I was able to at will, reproduce the issue.
simply executing the (ping -s 65507 192.168.0.239) seemed to cause the issue. Other OS may not allow you running such a command, i just happened to be root on my Mac (osx 10.6) at the time. obviously Jumbo frame support is required. I tried from another Mac, same result. Not been able to try from Windows/linux as i do not have a gig interface in either of my other machines.
be interested if anybody else can confirm the behaviour.
Obviously if any DoS protection is enabled (ICMP size etc) should prevent this particular issue and vector, but may not totally resolve the underlying issue. based on my tests, i was unable to reproduce when setting the max frame size to 9125 bytes or less, so appears to be maybe some simple buffer-overflow/bounds checking issue (although the potential possibilities this opens is worrying).
In addition, from my limited testing, this was only traffic targeted at the mgmt ip, so make sure the mgmt vlan is on a trusted network and not external (sounds obvious i know), and change the default mgmt IP, maybe consider disabling Jumbo frames.
May not be anything to worry about, certain factor need to be in place etc, without further details from Netgear, hard to say.
Will follow up with anything else i hear.
Cheers
BeggersBelief
