From: zsd@jdvb.ca
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
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
