NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
[BUG] GS108tv3 blocks udp broadcasts to port 123
Hi Guys,
I was evaluating the GS108Tv3 for table/POS access switch usage. I discovered that third party hardware suddenly was not able to communicatie with eachother anymore, so I investigated it, and discovered that sending broadcasts to udp poort 123 is actively dropped by the switch.
It's a bit of an unfortunate port, but that does not justify blocking the port.
Test case: take a factory reset GS108Tv3 with any firmware version up to 7.0.4.4 .
Attach a system on one port, and use this script:
root@ultra:~# for i in 122 123 124; do echo crap| socat - UDP4-DATAGRAM:10.255.255.255:$i,broadcast;done
It just broadcasts "crap" to udp ports 122, 123 and 124.
On another port listen to the device:
tcpdump -nei eth0 ether host 00:1e:06:31:cc:12 and udp
15:54:59.343666 00:1e:06:31:cc:12 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 60: 10.235.0.1.56381 > 10.255.255.255.122: UDP, length 5
15:55:00.373540 00:1e:06:31:cc:12 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 60: 10.235.0.1.38117 > 10.255.255.255.124: UDP, length 5
The switch also sees it drops packets, but it doesn't say why. In the web interface: Monitoring,Ports,Port Detailed Statistics clearly shows two counters:
Total Received Packets Not Forwarded
| 9 |
Dropped Transmit Frames
| 9 |
Could someone tell me how to report a grave bug like this to netgear?
EDIT 1:
16:48:31.565478 00:1e:06:31:cc:12 > 33:33:00:00:55:55, ethertype IPv6 (0x86dd), length 67: fe80::21e:6ff:fe31:cc12.56472 > ff02::5555.122: UDP, length 5
16:48:32.075350 00:1e:06:31:cc:12 > 33:33:00:00:55:55, ethertype IPv6 (0x86dd), length 67: fe80::21e:6ff:fe31:cc12.54246 > ff02::5555.123: NTPv4, Client, length 5
16:48:32.584974 00:1e:06:31:cc:12 > 33:33:00:00:55:55, ethertype IPv6 (0x86dd), length 67: fe80::21e:6ff:fe31:cc12.47350 > ff02::5555.124: UDP, length 5
16:49:38.466926 00:1e:06:31:cc:12 > 01:00:5e:01:01:01, ethertype IPv4 (0x0800), length 60: 10.235.0.1.60205 > 224.1.1.1.122: UDP, length 5
16:49:38.977551 00:1e:06:31:cc:12 > 01:00:5e:01:01:01, ethertype IPv4 (0x0800), length 60: 10.235.0.1.40214 > 224.1.1.1.123: NTPv4, Client, length 5
16:49:39.487050 00:1e:06:31:cc:12 > 01:00:5e:01:01:01, ethertype IPv4 (0x0800), length 60: 10.235.0.1.46736 > 224.1.1.1.124: UDP, length 5
So it's specific to IPv4 broadcast.
My next EDIT will when I move the management to out-of-band instead of in band, because I fear it might be a filter to specifically protect the host cpu, but the host cpu should just get by with a tiny iptables if it's necessary.
Update:
We got a beta release 7.0.4.7beta that fixed the issue.
Currently the switch has been running production for 2 months I think, and not a problem that's related to that switch.
Of course I've seen weird things going on in the switch (upnp, weird configuration daemons and such), but it doesn't stop it from working. So that beta seems good.
Changing the management vlan will be my next achievement, I fear I have to do that with scripted tftp download, sed, tftp upload, reboot. As the web doesn't allow it, and the command line doesn't allow it. Maybe if we use the serial console, but we do not intend to solder one on every switch ;-).Anyway, past the initial problems of getting a support ticket opened (the "owner" is a different person than the tech support here), the support crew was helpful in getting it resolved.
Regards,
Ard van Breemen
12 Replies
So:
If I move the management-vlan to out-of-band (which is hard to do, because it refuses to do it from the web interface, you need to upload a configuration file with the management-vlan set) then it still blocks.
However: if I configure sntp broadcast syncing or disable sntp at all, suddenly udp port 123 broadcasts are forwarded, independent of the VLAN.
I would have settled for an OOB workaround, but I can not settle for a managed switch that I can't time sync. I need port 123 broadcast forwarded, it's a switch.
schumaku and YeZ do you know what is the best way to get attention for this bug from netgear? I mean we are not really tiny customers. But a switch as the GS108Tv3 in it's current state should not have been sold if it fails to do it's one major task: switch traffic undiscriminately. And I think the fix should not be that hard, because the code currently actively ads an acl for udp port 123 on the switch asic. It can just not do that and everything is fine.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
