MSGID:  cc51d886   
   REPLY: <10j6luo$3nt82$1@dont-email.me> d777a910   
   PID: PyGate 1.5.2   
   TID: PyGate/Linux 1.5.2   
   CHRS: CP1252 2   
   TZUTC: 1100   
   REPLYADDR zsd@jdvb.ca   
   REPLYTO 3:633/10 UUCP   
   On 2026-01-01 at 16:37 AST, Tauno Voipio    
   wrote:   
   > 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.   
      
   Given that all of my systems have been running NetworkManager for many   
   years, and that I have only seen this happen once, I'm having a hard time   
   seeing why you can make such a definitive statement.  Care to elaborate?   
      
   > In my RasPi3B+ router, I disabled and stopped NetworkManager.   
   > systemd-networkd is perfectly capable to handle the DHCP   
   > client duties.   
      
   I run a number of systemd-free systems, and having as much commonality as   
   possibly reduces admin time.  So, for me, I would prefer to stay away from   
   switching network configuration tools if at all possible.  YMMV.   
      
                                   Jim   
      
      
   --- PyGate Linux v1.5.2   
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)   
   SEEN-BY: 105/81 106/201 128/187 129/14 305 153/7715 154/110 218/700   
   SEEN-BY: 226/30 227/114 229/110 112 134 200 206 275 300 317 400 426   
   SEEN-BY: 229/428 470 616 664 700 705 266/512 291/111 292/854 320/219   
   SEEN-BY: 322/757 342/200 396/45 460/58 633/10 280 414 418 420 422   
   SEEN-BY: 633/509 2744 712/848 770/1 902/26 2320/105 5020/400 5075/35   
   PATH: 633/10 280 229/426