Device reporting multiple invalid ip addresses over mDNS

[LukeWinikates]

Describe the bug

After updating to the current release, my pi devices are broadcasting some incorrect IP addresses over mDNS.

If I ping my hifi-office.local, I currently see:

% ping hifi-office.local
PING hifi-office.local (172.17.0.1): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1

Sometimes, hifi-office.local resolves to 10.0.0.1 instead.

Both of those IP addresses do not belong to this device - I can't SSH to the device there, and I can't visit that IP address in the browser and get the HiFiBerry UI.

I happened to be able to get to hifi-office.local in my browser, which showed a different IP address in the 192.168.1.x range. That IP address which works reliably for SSH and web UI access.

HiFiBerryOS version
20240319

HiFiBerry sound card

DAC+/Amp2

To Reproduce
Steps to reproduce the behavior:

1. Install HiFiBerryOS64, 20240319
2. Configure device to use WiFi network
3. from terminal, run ping $DEVICENAME.local
4. See request timeouts

Expected behavior

With prior versions of HiFiBerryOS, ping $DEVICENAME.local always resolved to an address in the 198.1

Here are the entries I see in the Discovery mDNS browser for MacOS

_airplay._tcp. (Protocol for streaming of audio/video content) - 4 items
...
hifi-office
hifi-office.local.
10.0.0.1:7000
192.168.1.19:7000
[a long ipv6 address]
172.17.0.1:7000

For some reason, Airplay is always able to connect, which makes me wonder if the devices themselves are using ipv6 and not picking from the ipv4 address entries.

I wonder if this is related to something from the temporary access point used for setup over wifi?

hifiberry-os/buildroot/package/raspi-wifi/dnsmasq.conf

Line 2 in 3d0c52a

dhcp-range=10.0.0.10,10.0.0.15,12h

hifiberry-os/buildroot/package/raspi-wifi/tempap-dnsmasq.service

Line 10 in 3d0c52a

ExecStartPre=/sbin/ifconfig wlan0 10.0.0.1 up

I have a second device that also reports itself as 172.17.0.1:7000

[hifiberry]

This hasn't to do with he temporary access point, but with the docker subsystem. We'll check how we can disable these IP addresses.

[madc]

I can confirm this with the current alpha 8 release. In my network, 10.0.0.1 is used by the wifi router. So this issue creates stability issues and even brings down the WIFI it I tray to ping/portscan the hifiberryOS device.

[hifiberry]

No docker container is using 10.x.x.x What exactly is your problem?

[madc]

@LukeWinikates stated in the initial issue: Sometimes, hifi-office.local resolves to 10.0.0.1 instead.

I'm no network expert, but I', pretty sure, I see a related issue. My network is in the 10.0.0.0 IP range and the device is set to use WIFI with a static IP (10.0.0.12). But it sometimes also seems to respond to 10.0.0.1 and the hifiberryOS Ui is shown instead of my routers web UI

I just realized that the issues intensified, when I introduced a second hifiberryOS device to the network (also alpha 8, 10.0.0.13) yesterday. Running an IP/Port scan over the network would bring the whole WIFI down. I than removed the devices from the network and everything is back to normal.

OP was talking about their device had up to three separate IP addresses (their network, docker and 10.0.0.1). The last one is also used for the temporary AP when setting up hifiberryOS for the first time. Therefor they mentioned the theory, this issue is related to the temporary AP.

Please let me know, if I can provide any additional information, I'm happy to help.

[madc]

@hifiberry I think, I've been able to get more insights on the issue.

After writing the comment above I did a fresh install with the latest stable version (linked on the hifiberry website). Yesterday I noticed that some devices in the network would get unusual IP addresses citing 10.0.0.12 as source (instead of the router, 10.0.0.1). When I check the network for dhcp servers I now get the following result:

❯ sudo nmap --script broadcast-dhcp-discover
Starting Nmap 7.95 ( https://nmap.org ) at 2024-06-02 09:43 CEST
Pre-scan script results:
| broadcast-dhcp-discover: 
|   Response 1 of 2: 
|     Interface: wlp170s0
|     IP Offered: 10.0.0.218
|     DHCP Message Type: DHCPOFFER
|     Server Identifier: 10.0.0.1
|     IP Address Lease Time: 1d00h00m00s
|     Renewal Time Value: 12h00m00s
|     Rebinding Time Value: 21h00m00s
|     Subnet Mask: 255.255.255.0
|     Broadcast Address: 10.0.0.255
|     Domain Name Server: 10.0.0.10, 1.1.1.1, 10.0.0.1
|     Router: 10.0.0.1
|   Response 2 of 2: 
|     Interface: wlp170s0
|     IP Offered: 10.0.0.15
|     DHCP Message Type: DHCPOFFER
|     Server Identifier: 10.0.0.12
|     IP Address Lease Time: 12h00m00s
|     Renewal Time Value: 6h00m00s
|     Rebinding Time Value: 10h30m00s
|     Subnet Mask: 255.255.255.0
|     Broadcast Address: 10.0.0.255
|     Router: 10.0.0.12
|_    Domain Name Server: 10.0.0.12
WARNING: No targets were specified, so 0 hosts scanned.
Nmap done: 0 IP addresses (0 hosts up) scanned in 10.52 seconds

Now here is what I think happens:

• Unrelated to this issue we are currently experiencing issues with our internet connection. This issues are currently resolved by restarting the router.
• As a result the hifiberryOS devices loose connection to WIFI and start the internal AP and the internal DHCP server is started.
• WIFI comes back up and the hifiberryOS device reconnects, AP is closed but the dhcp server is kept running
• After restarting the hifiberryOS device, only the dhcp server from my main router is active.

Does this scenario makes sense?
Please let me know, if I'd provide more information or create a separate issue.