From: tauno.voipio@notused.fi.invalid   
      
   On 31.12.2025 22.09, Jim Diamond wrote:   
   > On 2025-12-31 at 09:15 AST, Richard Kettlewell    
   wrote:   
   >> druck writes:   
   >>> On 30/12/2025 01:00, Jim Diamond wrote:   
   >>>> However, it was worth a look. Maybe. According to the router, the   
   >>>> "mystery" address is paired with the wifi card's actual ethernet (MAC)   
   >>>   
   >>> MAC's aren't just Ethernet, WiFi and Bluetooth interfaces also have them.   
   >>>   
   >>>> address, whereas the "proper" address is (currently) paired with the   
   >>>> same ethernet address, except the last octet is 8C instead of 8D.   
   >>>> This makes me think that it is showing "Connected" or "Disconnected"   
   >>>> according to the ethernet address which is working, and it is not   
   >>>> careful about pairing that with the correct IPv4 address.   
   >>>   
   >>> You often see a difference of 1 when something creates a virtual   
   >>> network interface for use by a virtual machine or container. The   
   >>> virtual network card is assigned the second IP address and can operate   
   >>> independently from anything using the hosts primary interface and IP   
   >>> address.   
   >>   
   >> At least on my 3B and 4B, the wired and wireless interfaces have   
   >> adjacent MACs.   
   >>   
   >> PS C:\Users\rjk> ssh shairo ip link show   
   >> 1: lo: mtu 65536 qdisc noqueue state UNKNOWN   
   mode DEFAULT group default qlen 1000   
   >> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00   
   >> 2: eth0: mtu 1500 qdisc noop state DOWN mode   
   DEFAULT group default qlen 1000   
   >> link/ether dc:a6:32:cb:73:6b brd ff:ff:ff:ff:ff:ff   
   >> 3: wlan0: mtu 1500 qdisc fq_codel   
   state UP mode DORMANT group default qlen 1000   
   >> link/ether dc:a6:32:cb:73:6c brd ff:ff:ff:ff:ff:ff   
   >>   
   >> If both interfaces were connected to the same network then I might see   
   >> something similar to Jim’s situation.   
   >>   
   >> I did ask Jim for ‘ip addr show’ output but it has not appeared.   
   >   
   > Mea culpa, I thought I did.   
   >   
   > Here is today's output... but I have long since gotten rid of that extra   
   > IP, so I'm not sure if this is at all interesting:   
   >   
   > 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group   
   default qlen 1000   
   > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00   
   > inet 127.0.0.1/8 scope host lo   
   > valid_lft forever preferred_lft forever   
   > inet6 ::1/128 scope host noprefixroute   
   > valid_lft forever preferred_lft forever   
   > 2: eth0: mtu 1500 qdisc mq state DOWN   
   group default qlen 1000   
   > link/ether dc:a6:32:37:93:8c brd ff:ff:ff:ff:ff:ff   
   > 3: wlan0: mtu 1500 qdisc pfifo_fast state   
   UP group default qlen 1000   
   > link/ether dc:a6:32:37:93:8d brd ff:ff:ff:ff:ff:ff   
   > inet 192.168.2.74/24 brd 192.168.2.255 scope global noprefixroute wlan0   
   > valid_lft forever preferred_lft forever   
   > inet6 fe80::d10a:4386:b7f7:43f9/64 scope link noprefixroute   
   > valid_lft forever preferred_lft forever   
   >   
   > Should it happen again I'll capture this output in case it helps find the   
   > source.   
   >   
   > Jim   
      
   If your system is running NetworkManager, it is the culprit.   
      
   In my RasPi3B+ router, I disabled and stopped NetworkManager.   
   systemd-networkd is perfectly capable to handle the DHCP   
   client duties.   
      
   After this, you have to create the needed interface and   
   network descriptions into /etc/systemd/network, and that's it.   
      
   The two links in the directory are fine, do not mess with them.   
      
   --   
      
   Tauno Voipio   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   
|