I believe if you added a third test to this: "Test 3: Pull the ethernet cable out of the RPI, wait 15 seconds and then insert the cable." you would find that the behavior would have reversed.SurferTim wrote:
Easy. Disable one, then the other.
Test 1: Enable wifi.Pull the ethernet cable out of the RPi.
Test 2: Disable wifi.Insert the ethernet cable into the RPi.
Ah I see what you mean, and yes using only one interface at a time works as expected, with the .local address working in both cases, and sudo hostname -I returning only the currently enabled interface's IP address.
I re-enabled wifi after testing just ethernet (test 2) and then rebooted, and annoyingly the .local address resolved to the wifi interface again.
I have the exact situation at home: 1 Raspberry Pi , 2 interfaces both on the same LAN (Ethernet and WiFi). I am away for this week so I have a slightly different configuration: 1 Raspberry Pi, Ethernet and WiFi on different LANs.
I pinged my local address: ping RasPi5.local and it performed the ping on the Wifi address.
After removing and replacing the ethernet cable the same: ping RasPi5.local performed the ping on the ethernet address.
If this test works, what I think is happening is when the last interface is started it will use that interface to respond to the .local request. Because the ethernet interface probably starts first on start up with the WiFi connecting later, all requests for .local will go to the WiFi address.
If this works in your case (or mine when I get home), this could probably be simulated by performing a ethernet "down" command followed by an "up" command based on some time delay after bootup.
Just something to try.
Statistics: Posted by dschneider — Wed Jan 29, 2025 1:23 am