Hi @GordDelaney, thanks for the info, that’s really useful to know. The problem does need solving; it causes the PiAware webpage to throw up the dump1090 warning for a few seconds every 15 mins, and it also means that a percentage of MLAT messages are being repeatedly lost according to piaware.log.
piaware[771]: NOTICE from adept server: 25% of multilateration messages (UDP) are not reaching the server - check your network?
I’m also of the conclusion now that this is some interaction between the latest Debian on the RPi and the networking of some routers. I’ve been remoted onto my mate’s network this evening doing a lot of testing. Here’s what I’ve found.
The OS sees the conflict no matter what unique IPv4 it has, meaning it’s not coming from any genuine external IPv4 conflict. It must be an OS interpretation of some situation which is being treated like a conflict. It may be IPv6 related.
Roy wrote a patch which saves the ARP packet contents when this happens. Sure enough they are being saved. They are all identical and they don’t reveal anything that Wireshark hasn’t already revealed, that they are ARP announcements following RFC 5227 Section 2.3.
pi@piaware:/tmp $ md5sum dhcpcd-arp*
c5683475e67e806b48a61e21888cc48f dhcpcd-arp-0.raw
c5683475e67e806b48a61e21888cc48f dhcpcd-arp-1.raw
c5683475e67e806b48a61e21888cc48f dhcpcd-arp-2.raw
...
pi@piaware:/tmp $ xxd dhcpcd-arp-0.raw
00000000: 0001 0800 0604 0001 0000 0000 0000 c0a8 ................
00000010: 0104 0000 0000 0000 c0a8 0104 ............
0001 is ARP hardware type Ethernet
0800 is ARP protocol type IPv4
06 is ARP hardware size
04 is ARP protocol size
0001 is ARP opcode type Request
000000000000 is sender MAC (on a remote Wireshark this part of the ARP announcement packet shows as the Pi’s MAC)
c0a80104 is sender IP which is 192.168.1.4
000000000000 is target MAC
c0a80104 is target IP which is 192.168.1.4
If I change the PiAware’s IP address in /boot/piaware-config.txt to another unused one and reboot with that, the Pi does indeed use the new address. The problem still happens and all that changes is the IP’s captured in the ARP packets are the new IP, eg for 192.168.1.7 it’s c0a80107.
However during PiAware’s startup there are all kinds of messages involving wlan0, and these are mostly caused by dhcpcd removing the address bindings. This in turn seems to be related to various things which don’t appear on my PiAware at all, eg
piaware dhcpcd[752]: wlan0: carrier lost
after which dhcpcd removes all the address bindings and everything goes through the cycle again. Or
piaware dhcpcd[348]: Too few arguments.
No idea what’s in the PiAware build is triggering that, it’s not appearing in mine.
Some of the error messages relate to IPv6. Perhaps this “conflict” is related to some IPv6 aspect which isn’t being handled correctly by dhcpcd or something else. The router does support IPv6 but it’s not used by the ISP so perhaps there’s some default settings which are causing problems on the LAN.
It’s not a direct Pi-hole interaction
My mate is using Pi-hole as his nameserver and that is configured in /boot/piaware-config.txt. If I change it back to the router and reboot, the conflict process still takes place. The only other IP in the conflg that PiAware knows about is the router which is a Sagemcom CS50001 with ISP branded firmware, offering multiple services as most of these consumer devices do.
The conflict cycle timing is not coming from PiAware
On his network this process of claim/defend/fail/drop/renew is taking place every 15 minutes at 53, 08, 23 and 38 minutes past the hour. This is regardless of when PiAware is booted so it’s being dicated by something external to PiAware. Later today I’m going to ask him to power-cycle the router so it’s back up between those minutes and see if that changes when the conflict takes place.
It’s not vrsfeed
I wrote a short script which uses socat to feed data to a VRS server. I wondered if that could be causing a problem, but stopping it from running makes no difference.
I think my next step will be to capture a complete syslog from reboot to the conflict process taking place and seeing if Roy notices anything related to these wlan0 messages, in particular around IPv6.