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

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

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