ARP Request/Reply

RouterOS General
1

Is there a function for the mikrotik to reply arp requests for know address (already in arp table)?
HostA is ARP requesting for the HostB (who is hostb-ip), both are in the same bridge; can the MikroTik answer the request (and not the HostB itself)?

My setup is:

  • RouterOS v6.45.8 (Long-term) mipsbe
  • Bridge using RSTP + arp reply-only mode
  • ether1 in the bridge port + arp reply-only mode
  • wlan1 in the bridge port + arp reply-only mode
  • dhcp server running in the bridge

The HostA is connected in ether1 and HostB is wireless connected to wlan1; the HostB enters in low-power mode and do not response broadcast packets, including arp requests.
So for HostA connect to HostB I have to manually add it’s MAC in the HostA table OR have the MikroTik to send any kind of packet to HostB (like arp-ping).

Adding a script in MikroTik to ping HostB time-to-time solves the problem but then HostB does not enters in low-power mode and the battery drains faster.
Adding static mac in HostA table is not good because I do need using DHCP and HostB IP may change overtime.

Is there a better solution for this?

Thanks in advance,
Willian

2

I’ve heard a rumour that in order to make broadcasts working reliably over wlan, one should set multicast-helper=full on AP’s wireless interface (works for broadcasts as well despites the name of option).

3

Thanks for the tip, it’s no exactly what I wanted but will do for now.

From the wiki: full - all multicast packet mac address are changed to unicast mac addresses prior sending them out; so my HostB will now receive a bunch of broadcast as unicast, it’ll cost a bit more battery life for sure.

4

Might be worth looking at the /ip dhcp-server option add-arp=yes, and local proxy-arp https://wiki.mikrotik.com/wiki/Manual:IP/ARP#Local_Proxy_Arp mode.

5

DHCP already set to add leases to arp table; tested proxy-arp and local-proxy-arp in the eth1, didn’t work, it should get the router Mac as response but it didn’t.

6

But won’t miss any broadcasts which is your issue, isn’t it? And I don’t think battery will suffer much more … wifi devices wake up regularly any way and those broadcasts converted to unicasts will get flushed during wake-up time … unicasts are buffered in AP while broadcasts/multicasts are not so it’s easy for sleeping wifi device to miss them.

The big drawback of using this method is that broadcasts/multicasts are transmitted over the air in multiple copies (number of copies is the same as number of registered wifi clients). Which can be an issue with some massive multicast streams (e.g. IP TV), but not so much for normal broadcasts inside smallish LAN.

7

For now the solution is:

  • Set multicast-helper to full in the wlan1 interface; now broadcast packets will be send as unicast and wake up the device
  • create a bridge filter to drop broadcast MAC destiny (FF:FF:FF:FF:FF:FF) when protocol is 800 (ip) and out interface is wlan1; yes the computers in the other interfaces do send a lot of broacast packets and this block then all but leaves ARP working

It’s good for now, thanks for the help :slight_smile:


But it would be handful if MikroTik could response all ARP requests as it has all in ARP table; maybe in version 7? :laughing:

8

In principle AP knows MAC addresses but doesn’t know corresponding IP addresses because AP is an L2 device. Only L3 devices have both kinds of data.

Unless an L2 device performs a very limited grade of packet inspection - for this purpose inspecting only IP headers would suffice.