All of lore.kernel.org
 help / color / mirror / Atom feed
* Multiple ARP replies for same address on openwrt module 6.6.69.2024.3-r3
@ 2025-01-09 10:31 Matteo Fortini
  2025-01-09 10:55 ` Sven Eckelmann
  0 siblings, 1 reply; 4+ messages in thread
From: Matteo Fortini @ 2025-01-09 10:31 UTC (permalink / raw)
  To: b.a.t.m.a.n

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.



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Multiple ARP replies for same address on openwrt module 6.6.69.2024.3-r3
  2025-01-09 10:31 Multiple ARP replies for same address on openwrt module 6.6.69.2024.3-r3 Matteo Fortini
@ 2025-01-09 10:55 ` Sven Eckelmann
  2025-01-09 11:32   ` Matteo Fortini
  0 siblings, 1 reply; 4+ messages in thread
From: Sven Eckelmann @ 2025-01-09 10:55 UTC (permalink / raw)
  To: b.a.t.m.a.n; +Cc: Matteo Fortini, Antonio Quartulli, Linus Lüssing

[-- Attachment #1: Type: text/plain, Size: 1523 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Multiple ARP replies for same address on openwrt module 6.6.69.2024.3-r3
  2025-01-09 10:55 ` Sven Eckelmann
@ 2025-01-09 11:32   ` Matteo Fortini
  2025-01-09 12:47     ` [SOLVED] " Matteo Fortini
  0 siblings, 1 reply; 4+ messages in thread
From: Matteo Fortini @ 2025-01-09 11:32 UTC (permalink / raw)
  To: Sven Eckelmann, b.a.t.m.a.n; +Cc: Antonio Quartulli, Linus Lüssing

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [SOLVED] Re: Multiple ARP replies for same address on openwrt module 6.6.69.2024.3-r3
  2025-01-09 11:32   ` Matteo Fortini
@ 2025-01-09 12:47     ` Matteo Fortini
  0 siblings, 0 replies; 4+ messages in thread
From: Matteo Fortini @ 2025-01-09 12:47 UTC (permalink / raw)
  To: Sven Eckelmann, b.a.t.m.a.n; +Cc: Antonio Quartulli, Linus Lüssing

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2025-01-09 12:47 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-01-09 10:31 Multiple ARP replies for same address on openwrt module 6.6.69.2024.3-r3 Matteo Fortini
2025-01-09 10:55 ` Sven Eckelmann
2025-01-09 11:32   ` Matteo Fortini
2025-01-09 12:47     ` [SOLVED] " Matteo Fortini

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.