MSGID: <10j6luo$3nt82$1@dont-email.me> d777a910
REPLY: 15bd7ffc
PID: PyGate 1.5.2
TID: PyGate/Linux 1.5.2
CHRS: CP1252 2
TZUTC: 0200
REPLYADDR tauno.voipio@notused.fi.invalid
REPLYTO 3:633/10 UUCP
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
--- 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
|
