HP Probook 430 G8 System MAC not passing through USB Type-C Dongle
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:
@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.
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 scommand (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.
@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 Here is the output of the command ip a s
NOTE the 3c:18a:cb:3f:b7 is the MAC of the HP Dongle:
lsusb ip a s
See that bit is wrong.
The command is
lsusbwhich produces the output you posted. That part is good.
The next bit
ip a sshould 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
I ran two separate commands:
- The first one was lspcl - nm | grep -i -e "net"
This gave me this output:
- 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.
- The first one was lspcl - nm | grep -i -e "net"
@michaeloberg one quick clarity the
ip a sshould be executed by itself.
Curious question: Where did that intel nic come from? The
ip a scommand will tell us a bit more.
Below is the output:
@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"
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.
Here is the screenshot from the BIOS:
@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?
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.
@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).
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:
@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 /allreport 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.
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.
@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.