HP Probook 430 G8 System MAC not passing through USB Type-C Dongle
-
@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 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
-
@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?
-
Here is the screenshot from the BIOS:
-
@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"
'lsusbStay 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.
-
@george1421
Below is the output: -
@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. -
@george1421
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.
Michael
- The first one was lspcl - nm | grep -i -e “net”
-
@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
-
@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:
-
@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.
-
@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. -
@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.
-
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:
-
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:
-
@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.
-
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.
-
@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 -
@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.
-
@george1421
I mean that it passes the Dongle MAC through iPXE.