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

[michaeloberg]

First, thank you to everyone for your continued support and efforts for those of us running FOG.

I have 515 HP Probooks that will not register with FOG correctly. IPXE is showing the correct MAC of the computer, but FOG is showing the MAC of the USB Type-C Dongle.

Here is what I can tell you:
Brand new installation of Debian 10 with FOG 1.5.9 and the latest Kernel 5.10.71

I set this box up as a new server and purposely did not migrate my Database over as I had over 100 images and thousands of clients. I wanted to clean this up and now is a great time as I have all new hardware. Last week we were able to get my Dell 7420 laptops passing the MAC through the docking stations by updating to the latest Kernel, however this did not fix the HP Laptops. The HP Laptops are using a dongle - Part # 855474-003

In researching on my own, I found a known issue with these dongle from HP’s website. I found a flash utility that updates the dongle and tried this on multiple ones with no avail.
https://support.hp.com/us-en/document/c07022776

Thanks in advance,

Mike

[Sebastian Roth]

@michaeloberg Let me start with some basic questions just to make sure. If you boot into Windows, does it show the correct MAC of the Probook itself (not the dongle’s MAC) and we can assume MAC pass-through is working using this combination of hardware?

Can you please boot some Live Linux OS that comes with a pretty new Linux kernel version to see what MAC address is showing up in that case? E.g. deepin (5.15), Clonezilla (5.14.6), Alpinelinux (5.15) or whatever else you find.

[michaeloberg]

@sebastian-roth
In Windows, the computer shows the correct (System MAC) not the Dongle MAC.

Deepin (full version 20.3) also shows the correct (System MAC) not the Dongle MAC.

Also when PXE booting, before it enters FOG, it does show the system MAC correctly. I opened a ticket with HP and these are some of the troubleshooting steps they had me do to isolate the problem to FOG and not the BIOS/Windows and in this case a GUI version of Linux (Deepin).

[george1421]

@michaeloberg The issue is with iPXE not FOS Linux, or the FOG server. I know its a bit complicated to understand, but iPXE is not seeing the system mac address but the dongle address. iPXE is detecting a mac address and checks with the FOG server, and the fog server is saying the system is unregistered. At this point FOS linux (bzImage [a.k.a. the kernel] + init.xz) is not even running yet.

I would first start out by rebuilding a current version of iPXE (another FOSS project unrelated to FOG) to see if that group has addressed the issue with iPXE. I have a tutorial here: https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe

Understand this might not fix the issue, but having a current version of iPXE has addressed a few other issues similar to this.

[Sebastian Roth]

@george1421 You are spot on here I think. Debugging the other issue with @michaeloberg I started with iPXE but was wrong then and this time went the other way from the kernel side but wrong again.

[michaeloberg]

@george1421 @Sebastian-Roth

I updated iPXE and I have the same results, the MAC address recognized by FOG is the Dongle MAC, not the System MAC.

Here is a screen shot before the iPXE update, note the (g4bd0) hex number:

Here is a screenshot after the iPXE update to verify the current date using ls -la /tftpboot/*.efi

Here is a screenshot after I updated iPXE, note the (g98625) hex number:

And finally here is what it looks like when I boot to FOG and choose “Client System Information (Compatibility)” then choose option 6 - Display MAC Address (displays the Dongle MAC):

Hopefully this is enough information to get us through to the next step, I appreciate the help.

Michael

[george1421]

@michaeloberg Ok I think I’m missing something because I’m seeing this backwards.

iPXE is seeing 6c:02:e0:86:07:45 (numbers may be close I have bad eyes today) HP is the nic vendor

FOS Linux is seeing 3c:18:a0:cb:3f:b7 Luxshare Precision Industry Company is the nic vendor

So when you go into the firmware bios, you have mac address passthrough enabled?

What does the bios say the LOM mac address is. Do you have a screen shot?

When in windows on the same computer, what does ipconfig /all report as the mac address of the device (before you touch any firmware settings)?

Something is not linking up with what we’ve seen in the past. Your conditions appear to be backwards (I’m not implying they are, just my understanding is backwards from what I expected).

FWIW: Having the latest version of IPXE will not hurt you so you did not waste your time. The latest version of iPXE did solve a few other issues.

[michaeloberg]

@george1421
I am not sure why iPXE is showing 6c:02:e0:86:07:45 (I initially thought this was the SYSTEM MAC, it is not).

The MAC that FOG is reporting, 3c:18:a0:cb:3f:b7 is the Dongle MAC.

The BIOS is set for “MAC Addressing Passthrough - System MAC”

The MAC Address of the system is 3c:18:a0:cb:3f:b7

Here is a screenshot of the windows cmd ipconfig /all:

[george1421]

@michaeloberg OK this IS what I was expecting. Both FOS Linux and Windows are telling us the same thing. They are both seeing the mac address built into the LOM (lan on motherboard). Both Windows and FOS Linux are using advanced network drives so it will (should) detect the mac address of the LOM.

Now iPXE is the odd man out. It is reporting 6c:02:e0:86:07:45 which I’m going to guess is the dongle mfg mac address. Is the dongle made by HP? The reason why I question is that the vendor code [6c:02:e0] belongs to HP where the LOM vendor code [3c:18:a0] belongs to a Chinese sounding company name (not that its a bad thing, just a bit unexpected for a LOM nic).

So we are still at iPXE is seeing a different mac address than FOS Linux and Windows is seeing. That is the root of the problem. Because when you register a computer FOS Linux is running and sees the right mac address, but when the computer enters iPXE it is seeing a different mac address (of the dongle) so it things its unregistered.

For your uefi boot strap loader are you using ipxe.efi? If so, have you tried snponly.efi instead? Does that give us a different results? You will be able to tell right away from the iPXE menu. If its working it will show the host as being registered (assuming you already registered the host once).

[michaeloberg]

@george1421

I apologize, I have way to many things going on right now. 6c:02:e0:86:07:45 is the MAC of the machine in the BIOS:

3c:18:a0:cb:3f:b7 is the MAC of the HP Dongle - Part # 855474

3c:18:a0:cb:3f:b7 shown in the following 2 captures (the first Windows ipconfig, the second Deepin) are of the HP Dongle, not the system address:

Again I am so sorry about the confusion.

So recap, IP in iPXE is correct, IP in FOG is recognizing the Dongle MAC. I did change my 067 Bootfile Name in DHCP to snponly.efi and it PXE boots, but FOG still reports the Dongle MAC.

Michael

[george1421]

@michaeloberg Again this is backwards from I would expected. That’s OK none the less. Because windows and Deepin are displaying incorrectly (so to speak). I’m also assuming that FOS Linux is also showing the same as windows and Deepin.

So the question is why are these high level operating systems giving us the dongle mac and not ipxe which is a low level (limited) boot loader. FWIW snponly.efi uses the ueif built in nic driver. So in theory the value it reports should be right.

In the firmware the screen shot you showed host based mac address, what other options are in the drop down list?

[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.