Looking for possible causes. The issue is I have one system where the
MAC address has changed for no apparent reason.

The system is a MSI B75MA-G43 motherboard with on board
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller with Ubuntu
22.04.2 LTS desktop. NIC set to DHCP, and I have a Ubuntu server with
local DNS and DHCP server with a LAN pool where I set this client's IP
by matching the MAC address. Straight forward and easy. Been working for
years. For the third time this year the MAC address has changed where
client has the wrong IP breaking my LAN backup system. My OCD nature I
comment changes to record things so server's dhcpd.conf:
....
# 2023-03-04 Not sure how but Kenny's mac address changed
# 2023-06-23 Dang Kenny's mac changes again
# 2023-06-29 Kenny is back to previous MAC
....
host kenny {
#hardware ethernet 1e:2b:ad:33:12:64;
hardware ethernet d4:3d:7e:b6:ba:a8;
fixed-address 192.168.57.132;
}

Those are the two MAC addresses that NIC keeps switching so this morning
if failed recorded by dhcp server lease file /var/lib/dhcp/dhcpd.leases:

lease 192.168.57.193 {
starts 4 2023/06/29 09:34:30;
ends 4 2023/06/29 21:34:30;
cltt 4 2023/06/29 09:34:30;
binding state active;
next binding state free;
rewind binding state free;
hardware ethernet 1e:2b:ad:33:12:64; <-NOTE MAC now back to this...
uid "\001\036+\2553\022d";
client-hostname "kenny";
}

Confirmed on client Kenny:
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel
state UP group default qlen 1000
link/ether 1e:2b:ad:33:12:64 brd ff:ff:ff:ff:ff:ff
inet 192.168.57.193/24 brd 192.168.57.255 scope global dynamic
noprefixroute enp3s0
valid_lft 28111sec preferred_lft 28111sec
inet6 fe80::1feb:64a7:bae6:90da/64 scope link noprefixroute

Now last Friday when I debugged this ip addr command confirmed at the
time the MAC address was d4:3d:7e:b6:ba:a8 and not 1e:2b:ad:33:12:64.
Now it is 1e:2b:ad:33:12:64. HOW? I am not spoofing the MAC with
NetworkManger on Kenny(*). This is an Ethernet and not WiFi with
software MAC switching "pseudo-security" measure some employ on Wifi. I
have not recently updated BIOS on this system, so where should I look
for cause? Puzzled.

(*)Hostname South Park reference: original machine before rebuild from
scratch with new parts was cobbled together from used systems expecting
a "Hey they killed Kenny" moment at any time.

--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com

On 29/06/2023 17:43, Jonathan N. Little wrote:
> Looking for possible causes. The issue is I have one system where the
> MAC address has changed for no apparent reason.
>
> The system is a MSI B75MA-G43 motherboard with on board
> RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller with Ubuntu
> 22.04.2 LTS desktop. NIC set to DHCP, and I have a Ubuntu server with
> local DNS and DHCP server with a LAN pool where I set this client's IP
> by matching the MAC address. Straight forward and easy. Been working for
> years. For the third time this year the MAC address has changed where
> client has the wrong IP breaking my LAN backup system. My OCD nature I
> comment changes to record things so server's dhcpd.conf:
> ...
> # 2023-03-04 Not sure how but Kenny's mac address changed
> # 2023-06-23 Dang Kenny's mac changes again
> # 2023-06-29 Kenny is back to previous MAC
> ...
> host kenny {
> #hardware ethernet 1e:2b:ad:33:12:64;
> hardware ethernet d4:3d:7e:b6:ba:a8;
> fixed-address 192.168.57.132;
> }
>
> Those are the two MAC addresses that NIC keeps switching so this morning
> if failed recorded by dhcp server lease file /var/lib/dhcp/dhcpd.leases:
>
> lease 192.168.57.193 {
> starts 4 2023/06/29 09:34:30;
> ends 4 2023/06/29 21:34:30;
> cltt 4 2023/06/29 09:34:30;
> binding state active;
> next binding state free;
> rewind binding state free;
> hardware ethernet 1e:2b:ad:33:12:64; <-NOTE MAC now back to this...
> uid "\001\036+\2553\022d";
> client-hostname "kenny";
> }
>
> Confirmed on client Kenny:
> 2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel
> state UP group default qlen 1000
> link/ether 1e:2b:ad:33:12:64 brd ff:ff:ff:ff:ff:ff
> inet 192.168.57.193/24 brd 192.168.57.255 scope global dynamic
> noprefixroute enp3s0
> valid_lft 28111sec preferred_lft 28111sec
> inet6 fe80::1feb:64a7:bae6:90da/64 scope link noprefixroute
>
> Now last Friday when I debugged this ip addr command confirmed at the
> time the MAC address was d4:3d:7e:b6:ba:a8 and not 1e:2b:ad:33:12:64.
> Now it is 1e:2b:ad:33:12:64. HOW? I am not spoofing the MAC with
> NetworkManger on Kenny(*). This is an Ethernet and not WiFi with
> software MAC switching "pseudo-security" measure some employ on Wifi. I
> have not recently updated BIOS on this system, so where should I look
> for cause? Puzzled.
>
> (*)Hostname South Park reference: original machine before rebuild from
> scratch with new parts was cobbled together from used systems expecting
> a "Hey they killed Kenny" moment at any time.
>

Looking up d4:3d:7e:b6:ba:a8 I see vendor is Micro-Star Int'L Co.

Looking up 1e:2b:ad:33:12:64 (three separate web sites) I get "No such vendor, Locally administered addresses (LAA):
the address is assigned to a device by a network administrator"

Sorry if this is no help

--
No Micro$oft products were used in the URLs above, or in preparing this message.
Recommended reading: http://www.catb.org/~esr/faqs/smart-questions.html#befor

On 6/29/2023 10:43 AM, Jonathan N. Little wrote:
> Looking for possible causes. The issue is I have one system where the
> MAC address has changed for no apparent reason.
>
> The system is a MSI B75MA-G43 motherboard with on board
> RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller with Ubuntu
> 22.04.2 LTS desktop. NIC set to DHCP, and I have a Ubuntu server with
> local DNS and DHCP server with a LAN pool where I set this client's IP
> by matching the MAC address. Straight forward and easy. Been working for
> years. For the third time this year the MAC address has changed where
> client has the wrong IP breaking my LAN backup system. My OCD nature I
> comment changes to record things so server's dhcpd.conf:
> ...
> # 2023-03-04 Not sure how but Kenny's mac address changed
> # 2023-06-23 Dang Kenny's mac changes again
> # 2023-06-29 Kenny is back to previous MAC
> ...
> host kenny {
> #hardware ethernet 1e:2b:ad:33:12:64;
> hardware ethernet d4:3d:7e:b6:ba:a8;
> fixed-address 192.168.57.132;
> }
>
> Those are the two MAC addresses that NIC keeps switching so this morning
> if failed recorded by dhcp server lease file /var/lib/dhcp/dhcpd.leases:
>
> lease 192.168.57.193 {
> starts 4 2023/06/29 09:34:30;
> ends 4 2023/06/29 21:34:30;
> cltt 4 2023/06/29 09:34:30;
> binding state active;
> next binding state free;
> rewind binding state free;
> hardware ethernet 1e:2b:ad:33:12:64; <-NOTE MAC now back to this...
> uid "\001\036+\2553\022d";
> client-hostname "kenny";
> }
>
> Confirmed on client Kenny:
> 2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel
> state UP group default qlen 1000
> link/ether 1e:2b:ad:33:12:64 brd ff:ff:ff:ff:ff:ff
> inet 192.168.57.193/24 brd 192.168.57.255 scope global dynamic
> noprefixroute enp3s0
> valid_lft 28111sec preferred_lft 28111sec
> inet6 fe80::1feb:64a7:bae6:90da/64 scope link noprefixroute
>
> Now last Friday when I debugged this ip addr command confirmed at the
> time the MAC address was d4:3d:7e:b6:ba:a8 and not 1e:2b:ad:33:12:64.
> Now it is 1e:2b:ad:33:12:64. HOW? I am not spoofing the MAC with
> NetworkManger on Kenny(*). This is an Ethernet and not WiFi with
> software MAC switching "pseudo-security" measure some employ on Wifi. I
> have not recently updated BIOS on this system, so where should I look
> for cause? Puzzled.
>
> (*)Hostname South Park reference: original machine before rebuild from
> scratch with new parts was cobbled together from used systems expecting
> a "Hey they killed Kenny" moment at any time.
>

This article seems to suggest the MAC is flashed into the 8111E.
I used to see references to "Vital Data" as some sort of table
in a BIOS for storing NIC information. It's hard to say in your
case, exactly what form the malfunction takes. A more logical partition,
would be for the NIC to be vanilla CMOS, and a serial EEPROM to be
connected to the side of it, to hold critical data. I'm not particularly
interested in this "repair recipe", because your device does not
seem to have "lost" the data, merely misplaced it.

https://www.youtube.com/watch?v=acxJMt6nT2g

2,346 views Dec 24, 2020
Ethernet controller RTL8111E got replaced on an MSI P67A-GD65.
After the replacement, the MAC address reported by the controller
is 00:00:00:00:00:00 which is invalid, preventing network from
working properly under Windows and PXE. We use the PG8168 tool
to program the original MAC address back into the new RTL8111E chip.

00:00 Problem & symptoms
01:45 Possible workaround under Windows. Note that Linux will automatically
generate a random MAC address in this case so network still works.
03:30 MAC address also missing inside BIOS Setup, confirming it's not a Windows problem.
03:49 Downloading&extracting PG8168 tool
06:40 Creating a bootable FreeDOS USB drive under Linux
08:35 Making some space on the drive and copying PG8168 tool
10:10 Booting on the USB drive
11:50 Showing programmed MAC address
12:35 Programming new MAC address
14:20 Confirming MAC address is good in BIOS Setup and PXE works
15:45 Confirming networking now works properly under Windows and MAC address is correct

Download PG8168: [Protected by Lenovo serial check...]
https://support.lenovo.com/ro/en/downloads/ds028993
Download FreeDOS: https://www.ibiblio.org/pub/micro/pc-...

*******

https://www.datasheet-pdf.info/entry/RTL8111E-Datasheet-PDF

https://www.datasheet-pdf.info/attach/1/3829665364.pdf

Section "6.7 Vital Product Data" is stored in a 93C46.
That could be where the MAC is stored.

Now, a question would be, why is the write protect not asserted ???

It's either that, or an alternate theory is, the chip does not
initialize itself properly, does not read the 93C46 at power up,
and the internal registers in the 8111E are left at 00:00:00:00:00:00 .

Summary: Replace NIC card, is the least waste of your time.
It's too bad there are so few Ethernet chip makers now.
Many replacement cards will be RealTek as well.
I would prefer a Marvell if I could find one.

Paul

Henry Crun wrote:
> On 29/06/2023 17:43, Jonathan N. Little wrote:
>> Looking for possible causes. The issue is I have one system where the
>> MAC address has changed for no apparent reason.
>>
>> The system is a MSI B75MA-G43 motherboard with on board
>> RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller with Ubuntu
>> 22.04.2 LTS desktop. NIC set to DHCP, and I have a Ubuntu server with
>> local DNS and DHCP server with a LAN pool where I set this client's IP
>> by matching the MAC address. Straight forward and easy. Been working for
>> years. For the third time this year the MAC address has changed where
>> client has the wrong IP breaking my LAN backup system. My OCD nature I
>> comment changes to record things so server's dhcpd.conf:
>> ...
>> # 2023-03-04 Not sure how but Kenny's mac address changed
>> # 2023-06-23 Dang Kenny's mac changes again
>> # 2023-06-29 Kenny is back to previous MAC
>> ...
>> host kenny {
>>          #hardware ethernet 1e:2b:ad:33:12:64;
>>          hardware ethernet d4:3d:7e:b6:ba:a8;
>>          fixed-address 192.168.57.132;
>> }
>>
>> Those are the two MAC addresses that NIC keeps switching so this morning
>> if failed recorded by dhcp server lease file /var/lib/dhcp/dhcpd.leases:
>>
>> lease 192.168.57.193 {
>>    starts 4 2023/06/29 09:34:30;
>>    ends 4 2023/06/29 21:34:30;
>>    cltt 4 2023/06/29 09:34:30;
>>    binding state active;
>>    next binding state free;
>>    rewind binding state free;
>>    hardware ethernet 1e:2b:ad:33:12:64; <-NOTE MAC now back to this...
>>    uid "\001\036+\2553\022d";
>>    client-hostname "kenny";
>> }
>>
>> Confirmed on client Kenny:
>> 2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel
>> state UP group default qlen 1000
>>      link/ether 1e:2b:ad:33:12:64 brd ff:ff:ff:ff:ff:ff
>>      inet 192.168.57.193/24 brd 192.168.57.255 scope global dynamic
>> noprefixroute enp3s0
>>         valid_lft 28111sec preferred_lft 28111sec
>>      inet6 fe80::1feb:64a7:bae6:90da/64 scope link noprefixroute
>>
>> Now last Friday when I debugged this ip addr command confirmed at the
>> time the MAC address was  d4:3d:7e:b6:ba:a8 and not 1e:2b:ad:33:12:64.
>> Now it is 1e:2b:ad:33:12:64. HOW? I am not spoofing the MAC with
>> NetworkManger on Kenny(*). This is an Ethernet and not WiFi with
>> software MAC switching "pseudo-security" measure some employ on Wifi. I
>> have not recently updated BIOS on this system, so where should I look
>> for cause? Puzzled.
>>
>> (*)Hostname South Park reference: original machine before rebuild from
>> scratch with new parts was cobbled together from used systems expecting
>> a "Hey they killed Kenny" moment at any time.
>>  
>
> Looking up d4:3d:7e:b6:ba:a8 I see vendor is Micro-Star Int'L Co.

Which makes sense because it is an MSI motherboard. IIRC that was the
MAC address that I originally had the dhcp server trap to set the IP.

>
> Looking up 1e:2b:ad:33:12:64 (three separate web sites) I get "No such
> vendor,  Locally administered addresses (LAA): the address is assigned
> to a device by a network administrator"

Which is strange because last night it switched to this MAC:

jonathan@kenny:~$ ip link show enp3s0
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel
state UP mode DEFAULT group default qlen 1000
link/ether 1e:2b:ad:33:12:64 brd ff:ff:ff:ff:ff:ff permaddr
c6:51:bd:c3:b2:ab

So the MAC is currently 1e:2b:ad:33:12:64. Now the above has a
"permaddr" value of c6:51:bd:c3:b2:ab. Googling seems to indicate
"permaddr" is present when overriding NIC's MAC by spoofing. 1) I am not
spoofing. 2) c6:51:bd:c3:b2:ab also has no vendor ID.

So I when looking to see where|what could be overriding the MAC like so
legacy config since this system has been migrated over the years from
earlier versions of Ubuntu.

1) No overrides in /etc/systemd/networkd.conf

2) No overrides in legacy /etc/network/interfaces or
/etc/network/interfaces.d

3) Network settings using new netplan as configured by 22.04 installer
/etc/netplan/01-network-manager-all.yaml

# Let NetworkManager manage all devices on this system
network:
version: 2
renderer: NetworkManager

So using NetworkManager so I checked for any overrides in
NetworkManager's configuration

4) /etc/NetworkManager/NetworkManager.conf
[main]
plugins=ifupdown,keyfile

[ifupdown]
managed=false

[device]
wifi.scan-rand-mac-address=no

Well the Wifi card is not set for random MAC address! But nothing about
the Ethernet...

5) Nothing set here either:

jonathan@kenny:~$ ls -l /usr/lib/NetworkManager/conf.d/
total 16
-rw-r--r-- 1 root root 225 Jun 9 2022 10-dns-resolved.conf
-rw-r--r-- 1 root root 80 Jun 9 2022 10-globally-managed-devices.conf
-rw-r--r-- 1 root root 58 Jun 9 2022 20-connectivity-ubuntu.conf
-rw-r--r-- 1 root root 306 Apr 4 2022 no-mac-addr-change.conf

So I am at a loss. It looks like the MAC address should be
d4:3d:7e:b6:ba:a8 which it was the other day but now it is being
overrided somewhere but I cannot find it.

>
> Sorry if this is no help
>

--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com

On Thu, 29 Jun 2023 23:26:57 -0400, Jonathan N. Little wrote:
> Henry Crun wrote:
>> On 29/06/2023 17:43, Jonathan N. Little wrote:
>>> Looking for possible causes. The issue is I have one system where the
>>> MAC address has changed for no apparent reason.
>>>
>>> The system is a MSI B75MA-G43 motherboard with on board
>>> RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller with Ubuntu
>>> 22.04.2 LTS desktop. NIC set to DHCP, and I have a Ubuntu server with
>>> local DNS and DHCP server with a LAN pool where I set this client's IP
>>> by matching the MAC address. Straight forward and easy. Been working for
>>> years. For the third time this year the MAC address has changed where
>>> client has the wrong IP breaking my LAN backup system. My OCD nature I
>>> comment changes to record things so server's dhcpd.conf:
>>> ...
>>> # 2023-03-04 Not sure how but Kenny's mac address changed
>>> # 2023-06-23 Dang Kenny's mac changes again
>>> # 2023-06-29 Kenny is back to previous MAC
>>> ...
>>> host kenny {
>>>          #hardware ethernet 1e:2b:ad:33:12:64;
>>>          hardware ethernet d4:3d:7e:b6:ba:a8;
>>>          fixed-address 192.168.57.132;
>>> }
>>>
>>> Those are the two MAC addresses that NIC keeps switching so this morning
>>> if failed recorded by dhcp server lease file /var/lib/dhcp/dhcpd.leases:
>>>
>>> lease 192.168.57.193 {
>>>    starts 4 2023/06/29 09:34:30;
>>>    ends 4 2023/06/29 21:34:30;
>>>    cltt 4 2023/06/29 09:34:30;
>>>    binding state active;
>>>    next binding state free;
>>>    rewind binding state free;
>>>    hardware ethernet 1e:2b:ad:33:12:64; <-NOTE MAC now back to this...
>>>    uid "\001\036+\2553\022d";
>>>    client-hostname "kenny";
>>> }
>>>
>>> Confirmed on client Kenny:
>>> 2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel
>>> state UP group default qlen 1000
>>>      link/ether 1e:2b:ad:33:12:64 brd ff:ff:ff:ff:ff:ff
>>>      inet 192.168.57.193/24 brd 192.168.57.255 scope global dynamic
>>> noprefixroute enp3s0
>>>         valid_lft 28111sec preferred_lft 28111sec
>>>      inet6 fe80::1feb:64a7:bae6:90da/64 scope link noprefixroute
>>>
>>> Now last Friday when I debugged this ip addr command confirmed at the
>>> time the MAC address was  d4:3d:7e:b6:ba:a8 and not 1e:2b:ad:33:12:64.
>>> Now it is 1e:2b:ad:33:12:64. HOW? I am not spoofing the MAC with
>>> NetworkManger on Kenny(*). This is an Ethernet and not WiFi with
>>> software MAC switching "pseudo-security" measure some employ on Wifi. I
>>> have not recently updated BIOS on this system, so where should I look
>>> for cause? Puzzled.
>>>
>>> (*)Hostname South Park reference: original machine before rebuild from
>>> scratch with new parts was cobbled together from used systems expecting
>>> a "Hey they killed Kenny" moment at any time.
>>>  
>>
>> Looking up d4:3d:7e:b6:ba:a8 I see vendor is Micro-Star Int'L Co.
>
> Which makes sense because it is an MSI motherboard. IIRC that was the
> MAC address that I originally had the dhcp server trap to set the IP.
>
>>
>> Looking up 1e:2b:ad:33:12:64 (three separate web sites) I get "No such
>> vendor,  Locally administered addresses (LAA): the address is assigned
>> to a device by a network administrator"
>
> Which is strange because last night it switched to this MAC:
>
> jonathan@kenny:~$ ip link show enp3s0
> 2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel
> state UP mode DEFAULT group default qlen 1000
> link/ether 1e:2b:ad:33:12:64 brd ff:ff:ff:ff:ff:ff permaddr
> c6:51:bd:c3:b2:ab
>
> So the MAC is currently 1e:2b:ad:33:12:64. Now the above has a
> "permaddr" value of c6:51:bd:c3:b2:ab. Googling seems to indicate
> "permaddr" is present when overriding NIC's MAC by spoofing. 1) I am not
> spoofing. 2) c6:51:bd:c3:b2:ab also has no vendor ID.
>
> So I when looking to see where|what could be overriding the MAC like so
> legacy config since this system has been migrated over the years from
> earlier versions of Ubuntu.
>
> 1) No overrides in /etc/systemd/networkd.conf
>
> 2) No overrides in legacy /etc/network/interfaces or
> /etc/network/interfaces.d
>
> 3) Network settings using new netplan as configured by 22.04 installer
> /etc/netplan/01-network-manager-all.yaml
>
> # Let NetworkManager manage all devices on this system
> network:
> version: 2
> renderer: NetworkManager
>
> So using NetworkManager so I checked for any overrides in
> NetworkManager's configuration
>
> 4) /etc/NetworkManager/NetworkManager.conf
> [main]
> plugins=ifupdown,keyfile
>
> [ifupdown]
> managed=false
>
> [device]
> wifi.scan-rand-mac-address=no
>
> Well the Wifi card is not set for random MAC address! But nothing about
> the Ethernet...
>
> 5) Nothing set here either:
>
> jonathan@kenny:~$ ls -l /usr/lib/NetworkManager/conf.d/
> total 16
> -rw-r--r-- 1 root root 225 Jun 9 2022 10-dns-resolved.conf
> -rw-r--r-- 1 root root 80 Jun 9 2022 10-globally-managed-devices.conf
> -rw-r--r-- 1 root root 58 Jun 9 2022 20-connectivity-ubuntu.conf
> -rw-r--r-- 1 root root 306 Apr 4 2022 no-mac-addr-change.conf
>
> So I am at a loss. It looks like the MAC address should be
> d4:3d:7e:b6:ba:a8 which it was the other day but now it is being
> overrided somewhere but I cannot find it.

I would try booting a live cd and checking just to have a second
opinion about mac.

On 6/29/2023 11:26 PM, Jonathan N. Little wrote:

> 5) Nothing set here either:
>
> jonathan@kenny:~$ ls -l /usr/lib/NetworkManager/conf.d/
> total 16
> -rw-r--r-- 1 root root 225 Jun 9 2022 10-dns-resolved.conf
> -rw-r--r-- 1 root root 80 Jun 9 2022 10-globally-managed-devices.conf
> -rw-r--r-- 1 root root 58 Jun 9 2022 20-connectivity-ubuntu.conf
> -rw-r--r-- 1 root root 306 Apr 4 2022 no-mac-addr-change.conf
>
> So I am at a loss

Time to stick a NIC card in it, and see if the MAC stabilizes.

If the MAC of the temporary NIC card is the same as it was in some other
Test Machine, then you know your OS is not using overrides.

Paul

Bit Twister wrote:
> On Thu, 29 Jun 2023 23:26:57 -0400, Jonathan N. Little wrote:
>> Henry Crun wrote:

<snip>

>>>
>>> Looking up d4:3d:7e:b6:ba:a8 I see vendor is Micro-Star Int'L Co.
>>
>> Which makes sense because it is an MSI motherboard. IIRC that was the
>> MAC address that I originally had the dhcp server trap to set the IP.
>>
>>>
>>> Looking up 1e:2b:ad:33:12:64 (three separate web sites) I get "No such
>>> vendor,  Locally administered addresses (LAA): the address is assigned
>>> to a device by a network administrator"
>>
>> Which is strange because last night it switched to this MAC:
>>
>> jonathan@kenny:~$ ip link show enp3s0
>> 2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel
>> state UP mode DEFAULT group default qlen 1000
>> link/ether 1e:2b:ad:33:12:64 brd ff:ff:ff:ff:ff:ff permaddr
>> c6:51:bd:c3:b2:ab
>>
>> So the MAC is currently 1e:2b:ad:33:12:64. Now the above has a
>> "permaddr" value of c6:51:bd:c3:b2:ab. Googling seems to indicate
>> "permaddr" is present when overriding NIC's MAC by spoofing. 1) I am not
>> spoofing. 2) c6:51:bd:c3:b2:ab also has no vendor ID.
>>
>> So I when looking to see where|what could be overriding the MAC like so
>> legacy config since this system has been migrated over the years from
>> earlier versions of Ubuntu.

<snip>

> I would try booting a live cd and checking just to have a second
> opinion about mac.
>

Duh! Great idea to eliminate any possible configuration issues...<grabs
my yumi thumbdrive>

Well, this is puzzling. The non-MSI vendor MAC "1e:2b:ad:33:12:64" is
showing here in the live session:

ubuntu@ubuntu:~$ ip link show enp3s0
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel
state UP mode DEFAULT group default qlen 1000
link/ether 1e:2b:ad:33:12:64 brd ff:ff:ff:ff:ff:ff

Same as normal boot:

jonathan@kenny:~$ ip link show enp3s0
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel
state UP mode DEFAULT group default qlen 1000
link/ether 1e:2b:ad:33:12:64 brd ff:ff:ff:ff:ff:ff permaddr
ee:a5:38:4c:ed:67

Only difference is the normal boot includes the permaddr parameter
ee:a5:38:4c:ed:67. Also strange is this permaddr parameter changed from
yesterday where it was "c6:51:bd:c3:b2:ab" not "ee:a5:38:4c:ed:67"

--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com

On Fri, 30 Jun 2023 10:52:33 -0400, Jonathan N. Little wrote:
> Bit Twister wrote:
>> On Thu, 29 Jun 2023 23:26:57 -0400, Jonathan N. Little wrote:
>>> Henry Crun wrote:
>
><snip>
>
>>>>
>>>> Looking up d4:3d:7e:b6:ba:a8 I see vendor is Micro-Star Int'L Co.
>>>
>>> Which makes sense because it is an MSI motherboard. IIRC that was the
>>> MAC address that I originally had the dhcp server trap to set the IP.
>>>
>>>>
>>>> Looking up 1e:2b:ad:33:12:64 (three separate web sites) I get "No such
>>>> vendor,  Locally administered addresses (LAA): the address is assigned
>>>> to a device by a network administrator"
>>>
>>> Which is strange because last night it switched to this MAC:
>>>
>>> jonathan@kenny:~$ ip link show enp3s0
>>> 2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel
>>> state UP mode DEFAULT group default qlen 1000
>>> link/ether 1e:2b:ad:33:12:64 brd ff:ff:ff:ff:ff:ff permaddr
>>> c6:51:bd:c3:b2:ab
>>>
>>> So the MAC is currently 1e:2b:ad:33:12:64. Now the above has a
>>> "permaddr" value of c6:51:bd:c3:b2:ab. Googling seems to indicate
>>> "permaddr" is present when overriding NIC's MAC by spoofing. 1) I am not
>>> spoofing. 2) c6:51:bd:c3:b2:ab also has no vendor ID.
>>>
>>> So I when looking to see where|what could be overriding the MAC like so
>>> legacy config since this system has been migrated over the years from
>>> earlier versions of Ubuntu.
>
><snip>
>
>> I would try booting a live cd and checking just to have a second
>> opinion about mac.
>>
>
> Duh! Great idea to eliminate any possible configuration issues...<grabs
> my yumi thumbdrive>
>
> Well, this is puzzling. The non-MSI vendor MAC "1e:2b:ad:33:12:64" is
> showing here in the live session:
>
> ubuntu@ubuntu:~$ ip link show enp3s0
> 2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel
> state UP mode DEFAULT group default qlen 1000
> link/ether 1e:2b:ad:33:12:64 brd ff:ff:ff:ff:ff:ff
>
> Same as normal boot:
>
> jonathan@kenny:~$ ip link show enp3s0
> 2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel
> state UP mode DEFAULT group default qlen 1000
> link/ether 1e:2b:ad:33:12:64 brd ff:ff:ff:ff:ff:ff permaddr
> ee:a5:38:4c:ed:67
>
> Only difference is the normal boot includes the permaddr parameter
> ee:a5:38:4c:ed:67. Also strange is this permaddr parameter changed from
> yesterday where it was "c6:51:bd:c3:b2:ab" not "ee:a5:38:4c:ed:67"

Personally I would be nervous/parodied and do a clean install
assuming you are talking about a wired Ethernet device.

Going to update my custom sys_audit script to check mac addys

I found a few bits of interesting information here
https://superuser.com/questions/349579/what-can-cause-a-mac-address-to-change

On 2023-06-29, Jonathan N. Little <lws4art@gmail.com> wrote:
> Looking for possible causes. The issue is I have one system where the
> MAC address has changed for no apparent reason.
>
> The system is a MSI B75MA-G43 motherboard with on board
> RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller with Ubuntu
> 22.04.2 LTS desktop. NIC set to DHCP, and I have a Ubuntu server with
> local DNS and DHCP server with a LAN pool where I set this client's IP
> by matching the MAC address. Straight forward and easy. Been working for
> years. For the third time this year the MAC address has changed where
> client has the wrong IP breaking my LAN backup system. My OCD nature I
> comment changes to record things so server's dhcpd.conf:
> ...
> # 2023-03-04 Not sure how but Kenny's mac address changed
> # 2023-06-23 Dang Kenny's mac changes again
> # 2023-06-29 Kenny is back to previous MAC
> ...
> host kenny {
> #hardware ethernet 1e:2b:ad:33:12:64;
> hardware ethernet d4:3d:7e:b6:ba:a8;
> fixed-address 192.168.57.132;
> }
>
> Those are the two MAC addresses that NIC keeps switching so this morning
> if failed recorded by dhcp server lease file /var/lib/dhcp/dhcpd.leases:
>
> lease 192.168.57.193 {
> starts 4 2023/06/29 09:34:30;
> ends 4 2023/06/29 21:34:30;
> cltt 4 2023/06/29 09:34:30;
> binding state active;
> next binding state free;
> rewind binding state free;
> hardware ethernet 1e:2b:ad:33:12:64; <-NOTE MAC now back to this...
> uid "\001\036+\2553\022d";
> client-hostname "kenny";
> }
>
> Confirmed on client Kenny:
> 2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel
> state UP group default qlen 1000
> link/ether 1e:2b:ad:33:12:64 brd ff:ff:ff:ff:ff:ff
> inet 192.168.57.193/24 brd 192.168.57.255 scope global dynamic
> noprefixroute enp3s0
> valid_lft 28111sec preferred_lft 28111sec
> inet6 fe80::1feb:64a7:bae6:90da/64 scope link noprefixroute
>
> Now last Friday when I debugged this ip addr command confirmed at the
> time the MAC address was d4:3d:7e:b6:ba:a8 and not 1e:2b:ad:33:12:64.
> Now it is 1e:2b:ad:33:12:64. HOW? I am not spoofing the MAC with
> NetworkManger on Kenny(*). This is an Ethernet and not WiFi with
> software MAC switching "pseudo-security" measure some employ on Wifi. I
> have not recently updated BIOS on this system, so where should I look
> for cause? Puzzled.
>
> (*)Hostname South Park reference: original machine before rebuild from
> scratch with new parts was cobbled together from used systems expecting
> a "Hey they killed Kenny" moment at any time.
>

Is macchanger installed on that machine?
Is it enabled in /etc/default/macchanger?

Bit Twister wrote:
> Personally I would be nervous/parodied and do a clean install
> assuming you are talking about a wired Ethernet device.

Yes, wired Ethernet. Yes always put security first, partly why I do not
rely on ISP routers and my LAN is behind a Linux server and FW. Since I
have scripts managing and backing up all systems and uses FQDN if
anything changes I get notified.

>
> Going to update my custom sys_audit script to check mac addys
>

Mostly being challenged by not figuring out the cause. Double checked
and I confirmed that I had updated the bios on that board to the latest
version awhile ago. It is my wife's system which she only uses it now to
check Facebook. I will be doing a clean install of 24.04 when it released.

> I found a few bits of interesting information here
> https://superuser.com/questions/349579/what-can-cause-a-mac-address-to-change

This of course is the onboard NIC, not a card. MSI still in operation so
driver updates should not be the cause. Not spoofing, and I know how;
when our library had a cable company ISP and we had a static IP for the
server they originally used a consumer Linksys router. I replaced it
with a linux router|server|fw and rather than having to deal with ISP's
support to update MAC on file for our static IP I just used the old
Linksys router's MAC. Worked for years and after multiple hardware
upgrades until we got a fiber connection that made the process moot.

--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com

Kirk_Rockstein wrote:
> Is macchanger installed on that machine?
> Is it enabled in /etc/default/macchanger?
Nope. I do all the IT.

jonathan@kenny:~$ ls /etc/default/macchanger
ls: cannot access '/etc/default/macchanger': No such file or directory

jonathan@kenny:~$ apt-cache policy macchanger
macchanger:
Installed: (none)
Candidate: 1.7.0-5.4
Version table:
1.7.0-5.4 500
500 http://us.archive.ubuntu.com/ubuntu jammy/universe amd64
Packages

--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com

Jonathan N. Little wrote:
> Bit Twister wrote:
>> On Thu, 29 Jun 2023 23:26:57 -0400, Jonathan N. Little wrote:
>>> Henry Crun wrote:
>
> <snip>
>
>>>>
>>>> Looking up d4:3d:7e:b6:ba:a8 I see vendor is Micro-Star Int'L Co.
>>>
>>> Which makes sense because it is an MSI motherboard. IIRC that was the
>>> MAC address that I originally had the dhcp server trap to set the IP.
>>>
>>>>
>>>> Looking up 1e:2b:ad:33:12:64 (three separate web sites) I get "No such
>>>> vendor,  Locally administered addresses (LAA): the address is assigned
>>>> to a device by a network administrator"
>>>
>>> Which is strange because last night it switched to this MAC:
>>>
>>> jonathan@kenny:~$ ip link show enp3s0
>>> 2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel
>>> state UP mode DEFAULT group default qlen 1000
>>> link/ether 1e:2b:ad:33:12:64 brd ff:ff:ff:ff:ff:ff permaddr
>>> c6:51:bd:c3:b2:ab
>>>
>>> So the MAC is currently 1e:2b:ad:33:12:64. Now the above has a
>>> "permaddr" value of c6:51:bd:c3:b2:ab. Googling seems to indicate
>>> "permaddr" is present when overriding NIC's MAC by spoofing. 1) I am not
>>> spoofing. 2) c6:51:bd:c3:b2:ab also has no vendor ID.
>>>
>>> So I when looking to see where|what could be overriding the MAC like so
>>> legacy config since this system has been migrated over the years from
>>> earlier versions of Ubuntu.
>
> <snip>
>
>> I would try booting a live cd and checking just to have a second
>> opinion about mac.
>>
>
> Duh! Great idea to eliminate any possible configuration issues...<grabs
> my yumi thumbdrive>
>
> Well, this is puzzling. The non-MSI vendor MAC "1e:2b:ad:33:12:64" is
> showing here in the live session:
>
> ubuntu@ubuntu:~$ ip link show enp3s0
> 2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel
> state UP mode DEFAULT group default qlen 1000
> link/ether 1e:2b:ad:33:12:64 brd ff:ff:ff:ff:ff:ff
>
> Same as normal boot:
>
> jonathan@kenny:~$ ip link show enp3s0
> 2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel
> state UP mode DEFAULT group default qlen 1000
> link/ether 1e:2b:ad:33:12:64 brd ff:ff:ff:ff:ff:ff permaddr
> ee:a5:38:4c:ed:67
>
> Only difference is the normal boot includes the permaddr parameter
> ee:a5:38:4c:ed:67. Also strange is this permaddr parameter changed from
> yesterday where it was "c6:51:bd:c3:b2:ab" not "ee:a5:38:4c:ed:67"
>

So we had a power failure last night so I shut the system down for 6
hours and this morning the damn MAC address changed back to
"d4:3d:7e:b6:ba:a8" the one I suspect is real because its lookup link to
Micro-Star Int'l Co, Ltd

jonathan@kenny:~$ ip link show enp3s0
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel
state UP mode DEFAULT group default qlen 1000
link/ether d4:3d:7e:b6:ba:a8 brd ff:ff:ff:ff:ff:ff

Note also no permaddr field. This is bizarre!

--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com