HP Probook 430 G8 System MAC not passing through USB Type-C Dongle
-
@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.
Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)
Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG
-
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. -
@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…
-
@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
-
@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.
Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)
Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG
-
@sebastian-roth I’m not ready to blame the FOS Linux kernel just yet. If you look at the truth table (in my head) its indeterminate right now. On the left side you have FOS Linux and Windows acting the same by only showing the dongle mac address. On the right side you have the bios that is saying pass the 6C mac address through and iPXE seeing the 6C mac address for the dongle. If we can move Windows to the right side then I would say its something in the linux kernel (which it might still be).
Thinking back a bit, we did have an issue with the realtek… 8125 I think, where the driver in the kernel version was at 1.1 and on the realtek web site they had something like 1.7 or 1.8 for that same nic. With the linux kernel verison the nic would not talk on the network but with the updated driver from the realtek web site it worked just fine. It was something like they had the 8125, 8125A and 8125B version of the nic hardware which took the later driver to make them all work correctly. Its been a year or so, so I don’t remember the exact details. I do remember making a one-off kernel for that issue.
Edit: From one of the previous screen shots (all of them really helped us understand the situation) I see the hardware ID of that network adapter is [0bda:8153]. A quick google search found this page. I’m not sure I understand their logic for the kernel parameters, but it does list them. http://linux-hardware.org/?id=usb:0bda-8153
Edit2: Good-golly-bob that was hard to find the current driver. It looks like 2.15 is the latest external kernel driver. I have not looked in the linux source code yet to determine the current embedded driver version. Realtek official driver Then I came across this article. Realtek RTL8156 2.5G Chips + RTL8153 To Be Supported By Linux 5.13 Looking at a the realtek web site it looks like they have a 8153, 8153A, B, and now C versions. I wonder if what the OP has is one of the later versions of the chip that needs the updated driver. @Sebastian-Roth Didn’t I see you just built a test 5.15.x kernel? If so it may be interesting to try to see if it pulls in the pass through mac. That would push FOS Linux to the right side (<snark> who cares about windows anyway</snark>). Atually if you look at the listing for the windows driver it lists “Realtek USB GbE Family Controller” and not the specific model driver, but the generic one.
Edit3: The version of the realtek driver in 5.10.63 is still v1.11
Edit4: Looking at the linux firmware I see specific firmware for the 8153 nics
$ ls rtl815* rtl8153a-2.fw rtl8153a-4.fw rtl8153c-1.fw rtl8156b-2.fw rtl8153a-3.fw rtl8153b-2.fw rtl8156a-2.fw -
@sebastian-roth
Willing to try the latest 5.10.83 Kernel, but wondering how I do that.In CLI, I normally do the following to update to the latest Kernel:
cd /var/www/html/fog/service/ipxe
mv bzImage bzImage.orig
mv bzImage32 bzImage32.orig
wget https://fogproject.org/kernels/bzImage
wget https://fogproject.org/kernels/bzImage32
chown www-data:www-data bzImage*
file bzImage*Since you have given me a web address, how to I modify the syntax above to pull the latest Kernel from https://fogproject.org/kernels/bzImage-no-cdc_ether
I have really tried learning Linux, I have bought a book, watched videos and searched forums. Not everything is universal across the board for Linux. Please have patience as this is a very basic question but I’m afraid I don’t know how to update the Kernel.
Thank you,
Michael
-
@michaeloberg You can test that kernel for sure, but I think the answer is 5.13 and later. I see there is a 5.15.5 that was just created on https://fogproject.org/kernels/
Lets to with this route.
cd /var/www/html/fog/service/ipxe wget https://fogproject.org/kernels/bzImage-5.15.5 wget https://fogproject.org/kernels/bzImage-no-cdc_etherThat should bring them down to the FOG server without messing up anything else.
Now go into the web ui for that host that you manually registered with the 6C mac address. There is a kernel field. For Sebastians test enter
bzImage-no-cdc_etherin that field and schedule a debug capture or deploy doesn’t matter. Make sure you turn mac address pass through back on before you do that.Now pxe boot it, you should see bzImage-no-cdc_ether get transferred to the target computer. After a few screens of text you will be dropped at the fos linux command pompt. Key in
ip a sand look at the mac address for that adapter is it the dongle address or the pass through address?Now go back into the web ui and change the kernel parameter to
bzImage-5.15.5and save the settings. Now go to the target computer and key inrebootOnce again pxe boot into the debug mode (there is still an open deploy task so all you need to do is reboot the target computer and repxe boot it). When running under the 5.15 kernel see if the right mac address is passed withip a s -
Followed the steps you mentioned and when putting the kernel in for the host as bzImage-no-cdc_ether here are the screenshots of the boot and ip a s results:
Then I changed the parameter to bzImage-5.15.5 and here are the screenshots of the boot and ip a s results:
You can see in both cases the dongle address is display and not the System Address.
-
@michaeloberg Thank you for sticking with us on this. I guess the only trick I have left is to see if I can compile linux 5.15.5 with the updated driver from realtek to see if that resolves the issue. If that doesn’t then … I’m not sure. I will look at that tonight since I don’t have a lot of extra time during the day.
Make sure the firmware is updated on both the computer and network adapter please.
Lastly just to be sure that you are running the updated kernel. On the screen where you typed in the
ip a scommand if you typed inuname -ait should show you the kernel version. For the bzImage-5.15.5 file it should show 5.15.5 -
Sounds good and thank you. I have opened a ticket with HP as well, they escalated this to tier II engineering and am waiting for a call back.
I did update the BIOS on the computer from 1.06.03 to 1.06.04 and verified the NIC and Dongle have the latest firmware and even re-flashed the Dongle.
Here is the output from doing the command uname -a (keep in mind I still have bzImage-5.15.5 in the Host Kernel field in the GUI).
-
@michaeloberg OK I have a few kernels I want you to test. Please test each one to see if it reads the pass-thru mac address.
This first one is bzImage-rt-v215 This kernel has the version 2.15 driver from the realtek web site. The version built into the linux kernel is at version 1.11. This is kernel version 5.15.6
https://drive.google.com/file/d/1qxcjC9ZrV8lVh4T6rgBtmtgSp7SWRzL9/view?usp=sharingThis next one is stock FOS linux kernel 5.15.6 but has the additional kernel options listed here: http://linux-hardware.org/?id=usb:0bda-8153 this kernel is called bzImage-rt-opts
https://drive.google.com/file/d/1t4WgWHOv3wIFjnodRtMsRcaO87XIZxM4/view?usp=sharingDon’t get discouraged if neither one of these works. We are trying to find out where the problem isn’t right now. I want you to run this command after you boot into debug mode and/if if fails
grep -i -e firmware /var/log/messagesWhat I’m looking for is if the rt8153 or something network related complains about missing firmware. As I mentioned before I did see several 8153 hardware specific firmware listed but we are not including them by default. The linux kernel will complain if it needs the firmware but none are built into the kernel. This is not a common error, but does happen now and again. Your case is unique so we are casting a wide net here.For the developers here are the setting changes I found when I compared the FOS Linux default config vs the web site.
# CONFIG_USB_IPHETH is not set CONFIG_USB_NET_CDCETHER=y CONFIG_USB_PEGASUS=y CONFIG_USB_RTL8150=y CONFIG_USB_USBNET=y CONFIG_USB_CATC=y CONFIG_USB_RTL8152=y # CONFIG_USB_GADGET is not set CONFIG_USB_PHY=y CONFIG_USB_SUPPORT=y CONFIG_USB_NET_DRIVERS=y # CONFIG_USB_RTL8153_ECM is not setThe not set ones are the deviations between the web site and the default FOS configurations. Personally I think the key is the last realtek settings but I set them all in the above kernel.
Here are the kernel option descriptions.
x Symbol: USB_IPHETH [=n] x x Type : tristate x x Defined at drivers/net/usb/Kconfig:580 x x Prompt: Apple iPhone USB Ethernet driver x x Depends on: NETDEVICES [=y] && USB_NET_DRIVERS [=y] x x Location: x x -> Device Drivers x x -> Network device support (NETDEVICES [=y]) x x -> USB Network Adapters (USB_NET_DRIVERS [=y]) x Symbol: USB_GADGET [=n] x x Type : tristate x x Defined at drivers/usb/gadget/Kconfig:17 x x Prompt: USB Gadget Support x x Depends on: USB_SUPPORT [=y] x x Location: x x -> Device Drivers x x -> USB support (USB_SUPPORT [=y]) x x Selects: USB_COMMON [=y] && NLS [=y] x x Selected by [n]: x x - USB_EHCI_TEGRA [=n] && USB_SUPPORT [=y] && USB [=y] && USB_EHCI_HCD [=yx x Symbol: USB_RTL8153_ECM [=n] x x Type : tristate x x Defined at drivers/net/usb/Kconfig:638 x x Prompt: RTL8153 ECM support x x Depends on: NETDEVICES [=y] && USB_NET_DRIVERS [=y] && USB_NET_CDCETHER [x x Location: x x -> Device Drivers x x -> Network device support (NETDEVICES [=y]) x x -> USB Network Adapters (USB_NET_DRIVERS [=y]) x x x -
Thanks for the update, one question I have is what/how do I apply the new kernel t once I download it? Before I was always downloading and applying them with this command:
cd /var/www/html/fog/service/ipxe
mv bzImage bzImage.orig
mv bzImage32 bzImage32.orig
wget https://fogproject.org/kernels/bzImage
wget https://fogproject.org/kernels/bzImage32
chown www-data:www-data bzImage
file bzImage**For the no-cdc_ther and 5.15 kernels, you had me type:
wget https://fogproject.org/kernels/bzImag-5.15.5
wget https://fogproject.org/kernels/bzImage-no-cdc_etherAnd then change the kernel parameters in the GUI.
Thank you,
Michael
-
As this is for testing I’d suggest:
wget -O /var/www/fog/service/ipxe/bzImage-rt-v215 https://drive.google.com/uc?id=1qxcjC9ZrV8lVh4T6rgBtmtgSp7SWRzL9&export=download wget -O /var/www/fog/service/ipxe/bzImage-rt-opts https://drive.google.com/uc?id=1t4WgWHOv3wIFjnodRtMsRcaO87XIZxM4&export=downloadFrom the host in question, assuming it’s registered, go to edit it and in the Kernel field type in the name of the kernel file to test:
E.G.:
bzImage-rt-v215
bzImage-rt-opts
