• MAC address mystery

    From Jonathan N. Little@21:1/5 to All on Thu Jun 29 10:43:57 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Henry Crun@21:1/5 to Jonathan N. Little on Thu Jun 29 18:19:06 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul@21:1/5 to Jonathan N. Little on Thu Jun 29 13:39:13 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jonathan N. Little@21:1/5 to Henry Crun on Thu Jun 29 23:26:57 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul@21:1/5 to Jonathan N. Little on Fri Jun 30 09:04:57 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bit Twister@21:1/5 to Jonathan N. Little on Fri Jun 30 07:51:32 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jonathan N. Little@21:1/5 to Bit Twister on Fri Jun 30 10:52:33 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bit Twister@21:1/5 to Jonathan N. Little on Fri Jun 30 10:15:42 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jonathan N. Little@21:1/5 to Bit Twister on Fri Jun 30 13:12:07 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Kirk_Rockstein@21:1/5 to Jonathan N. Little on Fri Jun 30 16:48:31 2023
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jonathan N. Little@21:1/5 to All on Fri Jun 30 13:50:32 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jonathan N. Little@21:1/5 to Jonathan N. Little on Mon Jul 3 06:51:44 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)