HP Probook 430 G8 System MAC not passing through USB Type-C Dongle

[michaeloberg]

@george1421

Here is the screenshot from the BIOS:

[george1421]

@michaeloberg Well I was hoping on a more useful group of settings.

Lets do this. Manually register the mac address of the dongle and assign it to a fake host. Now within the host definition schedule a deploy task, but before you tick the deploy button tick the debug checkbox. Now schedule the task.

PXE boot the target computer. This should throw you into debug mode and after a few screens of text it should drop you to the FOS Linux command prompt.

From here I want you to run a few commands.
lspci -nn | grep -i -e "net"
'lsusb ip a s`

Stay in debug mode because I might have you look through the syslog file in FOS Linux to see if we see anything unique about that network adapter or computer. There is something strange going on that we just don’t know yet.

[michaeloberg]

@george1421
Below is the output:

[george1421]

@michaeloberg one quick clarity the ip a s should be executed by itself.

Curious question: Where did that intel nic come from? The ip a s command will tell us a bit more.

[michaeloberg]

@george1421
I ran two separate commands:

1. The first one was lspcl - nm | grep -i -e “net”
   This gave me this output:

2. The second command was lsusb ip a s
   This gave me this output:
   

I may be confused as you mentioned this:

Which I did on two separate lines in the CLI from the # prompt.

Let me know if this was incorrect.

Michael

[george1421]

@michaeloberg said in HP Probook 430 G8 System MAC not passing through USB Type-C Dongle:

lsusb ip a s

See that bit is wrong.

The command is lsusb which produces the output you posted. That part is good.

The next bit ip a s should give you this type of output.

$ ip a s
1: lo: <LOOPBACK,UP,LOWER_UP> 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 
       valid_lft forever preferred_lft forever
2: eno1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether XX:XX:bb:63:0c:XX brd ff:ff:ff:ff:ff:ff
3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether XX:XX:b7:04:a2:XX brd ff:ff:ff:ff:ff:ff
    inet 192.168.212.187/24 brd 192.168.212.255 scope global dynamic noprefixroute wlp3s0
       valid_lft 37097sec preferred_lft 37097sec
    inet6 2601:40b:4100:2716::21a/128 scope global dynamic noprefixroute 
       valid_lft 308858sec preferred_lft 308858sec
    inet6 fd42:b71b:30f0::21a/128 scope global noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 fd42:b71b:30f0:0:90d4:758f:44a5:1dcf/64 scope global temporary dynamic 
       valid_lft 598699sec preferred_lft 79808sec
    inet6 fd42:b71b:30f0:0:f154:fbbb:6b8c:c8ef/64 scope global mngtmpaddr nopref

[michaeloberg]

@george1421 Here is the output of the command ip a s

NOTE the 3c:18a:cb:3f:b7 is the MAC of the HP Dongle:

[Sebastian Roth]

@michaeloberg I just had a weird idea. Any chance there is another NIC in that probook? Maybe WLAN? Possibly the MAC we see in iPXE is from a totally different adapter.

To me it doesn’t make sense that Windows/Linux and all higher layer OSs see the USB dongle MAC but iPXE would see the pass-through MAC from the probook itself. Not impossible but I’d find it strange.

[george1421]

@sebastian-roth said in HP Probook 430 G8 System MAC not passing through USB Type-C Dongle:

I just had a weird idea. Any chance there is another NIC in that probook? Maybe WLAN? Possibly the MAC we see in iPXE is from a totally different adapter.

Exactly where I was heading. The intel nic [8086:a0f0] is a wifi adapter.

vendor: 8086 (“Intel Corporation”), device: a0f0 (“Wi-Fi 6 AX201”)

FOS Linux does not on purpose include wifi drivers so we wouldn’t see this in the ip a s command (but was hoping it would be there anyway). Its possible that ipxe does have the drivers for that nic. That mystery 6c-02 address is coming from somewhere.

[george1421]

@michaeloberg Just for testing can you disable that wifi adapter in bios/firmware and see if iPXE then sees only the dongle mac address?

I’m thinking this… in the uefi firmware it only knows about/sees the wifi adapter (because its built in), so in this case its passing through the mac address of the wifi adapter to the dongle. Since ipxe has the drivers for the wifi adapter (guess) its honoring the mac pass through feature.

[michaeloberg]

@sebastian-roth

Here is a screenshot of the NICs, Red Line is the Dongle and Blue Line is the Wi-Fi:

iPXE is showing the MAC of the System as indicated in the BIOS:

iPXE:

[michaeloberg]

@george1421 @Sebastian-Roth

So I disabled the Wi-Fi card in the BIOS:

iPXE still shows the BIOS (System MAC):

FOG still show the Dongle MAC:

So I removed the Wi-Fi Card:

Same thing, here is the MAC on the card and it matches ipconfig in windows:

ipconfig from earlier:

[Sebastian Roth]

@michaeloberg said in HP Probook 430 G8 System MAC not passing through USB Type-C Dongle:

iPXE is showing the MAC of the System as indicated in the BIOS:

Ok, I think this picture is key here. Seems like the UEFI settings tell us the 6C-… MAC address is what it calls the “System Address”. Whatever that is.

[george1421]

While I don’t agree with this premise, but what happens if you disable the host based mac address in the firm ware, does ipxe see the mac address of the usb adapter then?

This is really counter to what we want (i.e. a unique mac address for each device) but right now its keeping you from imaging that computer. This one has me really baffled. What shouldn’t be working is working, and what should be working is not.

[michaeloberg]

@sebastian-roth
In the simplest way to describe the overall issue I am having with these HP Probooks would be to state - “MAC Address passthrough works through iPXE but not any higher level Operating Systems - Linux, FOS, or Windows.”

Breaking it down as to what we have done and tried, I don’t know what the next step would be. We have a new server, updated iPXE, tried different Operating Systems, removed variables (Wi-Fi), is it possible that new computers aren’t meant to be imaged or maintain a static MAC address but take the MAC of the USB-Type C Dongle as the intent for these in corporate networks would be for them to remain with the computer and not on a rack meant for imaging?

I tested these Dongles on an HP Elitebook 845 G8 with the USB C and not integrated NIC and it worked. These were the units I was supposed to get, but do to the pandemic and industry shortages I had to get the Probooks because I found 515 of them in stock.

This is extremely frustrating and I know it isn’t anyone’s fault, but none-the-less mind boggling.

Is the current state and future of imaging mass quantities of computers over? I have been doing this for over 23 years. Altiris when I worked for Gateway Computers, Norton Ghost, Novell ZENworks, WDS, and for the last 7 years FOG. Never have I struggled this much.

And @george1421 - disabling the host based MAC, then PXE booting does nothing - shows this (shows the Dongle MAC):

Sorry a bit of a rant there, just trying to open my thought process up on what it could be or not meant to…

Thanks,
Michael

[george1421]

@michaeloberg said in HP Probook 430 G8 System MAC not passing through USB Type-C Dongle:

And @george1421 - disabling the host based MAC, then PXE booting does nothing - shows this (shows the Dongle MAC):

It does nothing in that it doesn’t pxe boot? What it does do on the surface is make ipxe mac == fos linux mac. Everything now sees the dongle mac.

[michaeloberg]

@george1421
I mean that it passes the Dongle MAC through iPXE.

[george1421]

@michaeloberg OK you can image this computer in its current state where both iPXE and FOS Linux agree on the mac address of the target computer.

Just restating the truth table as I see it:
So this is a HP usb dongle pxe booting in an HP computer. The dongle is supported by the uefi firmware because you are able to pxe boot. If the usb dongle wasn’t support it wouldn’t be listed as an option to PXE boot from.

Turning off the mac pass through in the firmware allows the mac address of the dongle to be presented to both iPXE and FOS Linux.

With mac pass through enabled iPXE is seeing the pass through mac address but neither are MS Windows or FOS Linux, both still show the mac address of the dongle.

…
Is there a firmware update for this computer? Its been out for over a year, has the firmware been updated?

Is there a nic driver specific (vendor supplied) for this nic for MS Windows? MS Windows may have just used its default nic driver. There might be vendor specific features that might not be present in the stock windows driver. Thinking if we can break the Windows to FOS Linux equivalency we can point to the nic driver in FOS Linux.

Is there a firmware update for this usb dongle? Thinking it might be missing something needed for mac address pass through… but then iPXE wouldn’t be seeing the right value…

[Sebastian Roth]

@michaeloberg said in HP Probook 430 G8 System MAC not passing through USB Type-C Dongle:

MAC Address passthrough works through iPXE but not any higher level Operating Systems - Linux, FOS, or Windows.

This is definitely something HP needs to explain I would think! If Windows is not able to see the system/pass-through MAC then it’s likely their fault. Though I still find it interesting that iPXE has access to this MAC.

Definitely look into firmware updates as suggested by George.

Edit: Ok, looking at the pictures again and again I might have another route here. The USB NIC chip seems to be a Realtek 8153 according to the USB IDs. Without much thinking I opened the (first link on the web)[http://linux-hardware.org/?id=usb:0bda-8153] and found the cdc_ether driver mentioned in there. This driver has a story to it. We removed it from our kernel back in the days of the 4.x Linux kernel series because it caused trouble with MS Surface devices. When going to the 5.x series it was re-enabled (for unknown reasons - by kernel oldconfig?) and we still have it in our kernels now. There was a post about this in March but we never got to decide weather we would remove the cdc_ether again or not: https://forums.fogproject.org/topic/15238/laptop-with-integrated-4g-modem

[Sebastian Roth]

@michaeloberg Ok, I just build a new kernel without the cdc_ether driver included (latest 5.10.83): https://fogproject.org/kernels/bzImage-no-cdc_ether

Give that a try and let us know.