I am noticing random unreachability of hosts in my network, in particular if I just nmap -sP the whole range.
I traced it down to ARP poisoning, and the source seems to be two hosts running batman-adv which are claiming the same address.
This is a sample output from arping
ARPING 192.168.99.1 42 bytes from 02:00:01:bb:00:07 (192.168.99.1): index=0 time=4.204 msec 56 bytes from 02:00:06:bb:00:07 (192.168.99.1): index=1 time=363.556 msec 42 bytes from 02:00:01:bb:00:07 (192.168.99.1): index=2 time=3.743 msec 56 bytes from 02:00:06:bb:00:07 (192.168.99.1): index=3 time=385.352 msec
issue is, 02:00:06:bb:00:07 is not the right node and the host is unreachable. The other MAC is the right one.
If I clear the ARP cache in my source host, then the remote host is reachable again as it gets the right answer.
The problem started after updating to the 24.10RC series of openwrt.
On Thursday, 9 January 2025 11:31:06 CET Matteo Fortini wrote:
I am noticing random unreachability of hosts in my network, in particular if I just nmap -sP the whole range.
I traced it down to ARP poisoning, and the source seems to be two hosts running batman-adv which are claiming the same address.
[...]
issue is, 02:00:06:bb:00:07 is not the right node and the host is unreachable. The other MAC is the right one.
If I clear the ARP cache in my source host, then the remote host is reachable again as it gets the right answer.
Might be DAT related. But I am not sure of it. Can you please add the output of
$ batctl mj
to see the (batadv interface specific) configuration.
This might be helpful for Antonio/Linus. If it is enabled, you could also try to disable it on all involved hosts via:
$ batctl dat disable
Just to see if it has any influence on the behavior (to see if there is any ARP poisoning in the long run - not to solve the intermediate problem).
The problem started after updating to the 24.10RC series of openwrt.
When you used 23.05.x before, then this would suggest that it was introduced somewhere between 2023.1 and 2024.3 (or OpenWrt) somehow.
I didn't test it but a quick check in the sources suggest that the 23.05 batman-adv sources (from the routing feed) should also work with 24.10 - so you could actually git-bisect openwrt routing from 6afc0452c2534ed0bc65b59b1fb6fd74439ddf27 to eaa4aba30b017de66bece8ef9d3dde5299fc787d
Kind regards, Sven
I apologize, the issue is still present even if I downgrade everything to 23.05.
I don't recollect having modified any batman config. Maybe it's been sometime since I hadn't tried a nmap
DAT is disabled, I've always had issues with "incoming packet with same mac address" and that was the only way to make it go away.
Here's the batctl mj output on all batman nodes.
{"version":"2023.1-openwrt-7","algo_name":"BATMAN_V","mesh_ifindex":12,"mesh_ifname":"bat0","mesh_address":"02:00:06:aa:00:00","hard_ifindex":16,"hard_ifname":"m-11s-0","hard_address":"b4:4b:d6:22:55:1c","tt_ttvn":6,"bla_crc":24857,"mcast_flags":{"all_unsnoopables": false,"want_all_ipv4": false,"want_all_ipv6": false,"want_no_rtr_ipv4": true,"want_no_rtr_ipv6": true,"raw": 24},"mcast_flags_priv":{"bridged": false,"querier_ipv4_exists": false,"querier_ipv6_exists": false,"querier_ipv4_shadowing": false,"querier_ipv6_shadowing": false,"raw": 0},"aggregated_ogms_enabled":true,"ap_isolation_enabled":false,"isolation_mark":0,"isolation_mask":0,"bonding_enabled":false,"bridge_loop_avoidance_enabled":true,"distributed_arp_table_enabled":false,"fragmentation_enabled":false,"gw_bandwidth_down":100,"gw_bandwidth_up":20,"gw_mode":"client","gw_sel_class":50,"hop_penalty":30,"multicast_forceflood_enabled":false,"orig_interval":1000,"multicast_fanout":16}
{"version":"2023.1-openwrt-7","algo_name":"BATMAN_V","mesh_ifindex":13,"mesh_ifname":"bat0","mesh_address":"02:00:03:aa:00:00","hard_ifindex":18,"hard_ifname":"phy1-mesh0","hard_address":"86:af:ca:1a:6b:3b","tt_ttvn":37,"bla_crc":17083,"mcast_flags":{"all_unsnoopables": false,"want_all_ipv4": false,"want_all_ipv6": false,"want_no_rtr_ipv4": true,"want_no_rtr_ipv6": true,"raw": 24},"mcast_flags_priv":{"bridged": false,"querier_ipv4_exists": false,"querier_ipv6_exists": false,"querier_ipv4_shadowing": false,"querier_ipv6_shadowing": false,"raw": 0},"aggregated_ogms_enabled":true,"ap_isolation_enabled":false,"isolation_mark":0,"isolation_mask":0,"bonding_enabled":false,"bridge_loop_avoidance_enabled":true,"distributed_arp_table_enabled":false,"fragmentation_enabled":false,"gw_bandwidth_down":100,"gw_bandwidth_up":20,"gw_mode":"client","gw_sel_class":50,"hop_penalty":30,"multicast_forceflood_enabled":false,"orig_interval":1000,"multicast_fanout":16}
Il 09/01/25 11:55, Sven Eckelmann ha scritto:
On Thursday, 9 January 2025 11:31:06 CET Matteo Fortini wrote:
I am noticing random unreachability of hosts in my network, in particular if I just nmap -sP the whole range.
I traced it down to ARP poisoning, and the source seems to be two hosts running batman-adv which are claiming the same address.
[...]
issue is, 02:00:06:bb:00:07 is not the right node and the host is unreachable. The other MAC is the right one.
If I clear the ARP cache in my source host, then the remote host is reachable again as it gets the right answer.
Might be DAT related. But I am not sure of it. Can you please add the output of
$ batctl mj
to see the (batadv interface specific) configuration.
This might be helpful for Antonio/Linus. If it is enabled, you could also try to disable it on all involved hosts via:
$ batctl dat disable
Just to see if it has any influence on the behavior (to see if there is any ARP poisoning in the long run - not to solve the intermediate problem).
The problem started after updating to the 24.10RC series of openwrt.
When you used 23.05.x before, then this would suggest that it was introduced somewhere between 2023.1 and 2024.3 (or OpenWrt) somehow.
I didn't test it but a quick check in the sources suggest that the 23.05 batman-adv sources (from the routing feed) should also work with 24.10 - so you could actually git-bisect openwrt routing from 6afc0452c2534ed0bc65b59b1fb6fd74439ddf27 to eaa4aba30b017de66bece8ef9d3dde5299fc787d
Kind regards, Sven
Turns out during some updates I had re-installed mesh11sd and, even with default config, it was messing with the network configuration in many ways. I found it complaining in the logs at some time.
Thank you for your support
Il 09/01/25 12:32, Matteo Fortini ha scritto:
I apologize, the issue is still present even if I downgrade everything to 23.05.
I don't recollect having modified any batman config. Maybe it's been sometime since I hadn't tried a nmap
DAT is disabled, I've always had issues with "incoming packet with same mac address" and that was the only way to make it go away.
Here's the batctl mj output on all batman nodes.
{"version":"2023.1-openwrt-7","algo_name":"BATMAN_V","mesh_ifindex":12,"mesh_ifname":"bat0","mesh_address":"02:00:06:aa:00:00","hard_ifindex":16,"hard_ifname":"m-11s-0","hard_address":"b4:4b:d6:22:55:1c","tt_ttvn":6,"bla_crc":24857,"mcast_flags":{"all_unsnoopables": false,"want_all_ipv4": false,"want_all_ipv6": false,"want_no_rtr_ipv4": true,"want_no_rtr_ipv6": true,"raw": 24},"mcast_flags_priv":{"bridged": false,"querier_ipv4_exists": false,"querier_ipv6_exists": false,"querier_ipv4_shadowing": false,"querier_ipv6_shadowing": false,"raw": 0},"aggregated_ogms_enabled":true,"ap_isolation_enabled":false,"isolation_mark":0,"isolation_mask":0,"bonding_enabled":false,"bridge_loop_avoidance_enabled":true,"distributed_arp_table_enabled":false,"fragmentation_enabled":false,"gw_bandwidth_down":100,"gw_bandwidth_up":20,"gw_mode":"client","gw_sel_class":50,"hop_penalty":30,"multicast_forceflood_enabled":false,"orig_interval":1000,"multicast_fanout":16}
{"version":"2023.1-openwrt-7","algo_name":"BATMAN_V","mesh_ifindex":13,"mesh_ifname":"bat0","mesh_address":"02:00:03:aa:00:00","hard_ifindex":18,"hard_ifname":"phy1-mesh0","hard_address":"86:af:ca:1a:6b:3b","tt_ttvn":37,"bla_crc":17083,"mcast_flags":{"all_unsnoopables": false,"want_all_ipv4": false,"want_all_ipv6": false,"want_no_rtr_ipv4": true,"want_no_rtr_ipv6": true,"raw": 24},"mcast_flags_priv":{"bridged": false,"querier_ipv4_exists": false,"querier_ipv6_exists": false,"querier_ipv4_shadowing": false,"querier_ipv6_shadowing": false,"raw": 0},"aggregated_ogms_enabled":true,"ap_isolation_enabled":false,"isolation_mark":0,"isolation_mask":0,"bonding_enabled":false,"bridge_loop_avoidance_enabled":true,"distributed_arp_table_enabled":false,"fragmentation_enabled":false,"gw_bandwidth_down":100,"gw_bandwidth_up":20,"gw_mode":"client","gw_sel_class":50,"hop_penalty":30,"multicast_forceflood_enabled":false,"orig_interval":1000,"multicast_fanout":16}
Il 09/01/25 11:55, Sven Eckelmann ha scritto:
On Thursday, 9 January 2025 11:31:06 CET Matteo Fortini wrote:
I am noticing random unreachability of hosts in my network, in particular if I just nmap -sP the whole range.
I traced it down to ARP poisoning, and the source seems to be two hosts running batman-adv which are claiming the same address.
[...]
issue is, 02:00:06:bb:00:07 is not the right node and the host is unreachable. The other MAC is the right one.
If I clear the ARP cache in my source host, then the remote host is reachable again as it gets the right answer.
Might be DAT related. But I am not sure of it. Can you please add the output of
$ batctl mj
to see the (batadv interface specific) configuration.
This might be helpful for Antonio/Linus. If it is enabled, you could also try to disable it on all involved hosts via:
$ batctl dat disable
Just to see if it has any influence on the behavior (to see if there is any ARP poisoning in the long run - not to solve the intermediate problem).
The problem started after updating to the 24.10RC series of openwrt.
When you used 23.05.x before, then this would suggest that it was introduced somewhere between 2023.1 and 2024.3 (or OpenWrt) somehow.
I didn't test it but a quick check in the sources suggest that the 23.05 batman-adv sources (from the routing feed) should also work with 24.10 - so you could actually git-bisect openwrt routing from 6afc0452c2534ed0bc65b59b1fb6fd74439ddf27 to eaa4aba30b017de66bece8ef9d3dde5299fc787d
Kind regards, Sven
b.a.t.m.a.n@lists.open-mesh.org
-
Matteo Fortini -
Sven Eckelmann