Help with an IPTables rule to suppress TV ARP broadcasts on WiFi

[Ari_el]

Using the latest asus-merlin release on an AC-3100 router. Works great - rock solid, nice and stable.

Here is the situation I want to address, something I think could be doable with an IPTables rule.

- I have samsung smarttv, connected directly via ethernet (cable) that is arp'ing the router (default gateway) IP address every two seconds. Like so:

617 82.329712958 SamsungE_xx:xx:xx Broadcast ARP 60 Who has 192.168.1.1? Tell 192.168.1.13
631 84.173493751 SamsungE_xx:xx:xx Broadcast ARP 60 Who has 192.168.1.1? Tell 192.168.1.13
...​

Where: .1 is the wifi AP/router, and .13 is the TV.

This appears to be normal for samsung TVs (lots of people noticed this behavior). Can't be turned off or anything; no issue with this per-se, the problem:

I see is that these ARP broadcasts that (I know) are answered directly on the wire by the asus router (as expected)
The ARP messages are ALSO forwarded and broadcasted by asus-merlin out to both WiFi accessess, 5Ghz/2.4Ghz, creating constant noise in both and (I guess) keeping clients more awake than they should be.​

So I would like to do the following

Suppress ARP broadcasts from being sent out of the WiFi radios if they contain: "Who has 192.168.1.1"

... since it doesn't make sense for the router to forward a broadcast asking for the MAC address of itself (unless I am missing something)
​

I am able to ssh into the router and am able to setup basic bash scripts in JFFS (I have some). ifconfig shows vlan1 and vlan2 which I believe are the wifi radios.

Is it possible to have a DROP rule with the condition above, based on the ARP message content ("who has 192.168.1.1"), and would this have an impact on router performance? guidance/hints/comments welcome - thanks

 

[kfp]

... since it doesn't make sense for the router to forward a broadcast asking for the MAC address of itself (unless I am missing something)

The router is not forwarding anything, that’s just how broadcasts work. Every device connected to the same switch would get it.

Why do you want to suppress these messages? ARP broadcasts are fairly normal on all networks.

 

[agilani]

Is the tv connecting via 2.4ghz wifi? I noticed a ton of arp issues on the latest code base which ended up being wireless layer 2 issues. Changing the channel to something less congested manually fixed the problem. This is not a merlin issue. I tried stock for 3 to 4 weeks and it has the exact same problem.

On the same segment traffic is mac to mac. In order for the tv to talk to the router, it has to get the mac address of the router. This is a normal broadcast. So either its not getting the answer (layer 2 issue) or its arp cache is corrupted. In my case it was a layer 2 wifi congestion issue.

Disabling/blocking arp will break the tv's ability to talk to the router at all (or all devices attempting to communicate with that device). All arp is broadcast to every device on that subnet for layer 2 communication. All traffic that is bound to the default gateway must have the mac address of the device.

Arp cache also has a timeout which once expired would require that the device do an arp to get the mac address of the device its communicating with. I don't think there is any way to see what your tv's os is set to.

 

[john9527]

Why do you want to suppress these messages? ARP broadcasts are fairly normal on all networks.

Actually, the router doesn't like these high frequency arp queries. Each one interrupts networkmap (which is doing it's own arp processing), so it takes a long time to complete identifying the clients.

 

[kfp]

Actually, the router doesn't like these high frequency arp queries. Each one interrupts networkmap (which is doing it's own arp processing), so it takes a long time to complete identifying the clients.

Huh, TIL.

Every 2 seconds is indeed excessive but I didn’t think it’ll impact anything.

I guess a more correct solution would be to try to resolve this on the Samsung end, otherwise maybe only a managed switch can help?

 

[sfx2000]

ARP broadcasts are normal... every two seconds is a bit high, but not excessive.

On the Samsung TV - is WiFi on? If so, try turning it off if possible...

 

[agilani]

Actually, the router doesn't like these high frequency arp queries. Each one interrupts networkmap (which is doing it's own arp processing), so it takes a long time to complete identifying the clients.

Huh? Every device in a layer 2 network will use arp to find the mac address of its neighbors for ANY device that is not already in its arp table that it needs to communicate with. There is something most likely wrong with the TV or the router is not replying. My guess would be the TV. Every device in that subnet should be receiving the arp requests and replies. Especially one for the default router for that segment. If the TV was working correctly, it should be able to build its arp table by just listening on the line instead of arping for the default router every 2 seconds. That being said, this is how a network operates 101.

Without doing a network capture or being able to get a terminal session on the tv it would be difficult to say anything more about this subject.

 

[kfp]

Huh? <snip> There is something most likely wrong with the TV or the router is not replying.

Pretty sure we’re all on the same page here, just that the constant arp would interfere with networkmap since it is doing its own arm storm.

OP mentioned the router responding so it must be TV not handling the responses properly or just bad design.

@Ari_el Maybe do a software/firmware update on your TV?

 

[john9527]

OP mentioned the router responding so it must be TV not handling the responses properly or just bad design.

Remember, Samsung TVs used 'localhost' for their hostname......need I say more.

 

[sfx2000]

In any event, don't try to suppress ARP's via iptables - it'll break things...

If there's a host that might be problematic, fix it..

 

[sfx2000]

Remember, Samsung TVs used 'localhost' for their hostname......need I say more.

The forum found a fix, which was to set the IP of the samsung device outside of the DHCP scope..

Silly that samsung hardcoded a reserved hostname there...