HP Probook 430 G8 System MAC not passing through USB Type-C Dongle
-
@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 -
@michaeloberg No problem. Since the files are coming from a google drive and not the “official” fog project web site you need to do things a bit differently.
First download them to your windows computer. They will go into the downloads folder.
Now they are in your downloads folder you have 2 options. You can go the gui route or command line by using putty’s
pscpprogram. The GUI route is probably the easiest, by installing winscp Use winscp to log into your FOG server. If you can login as root then do so. My guess it will only let you login as a normal user. Log into your fog server with winscp. If you can log into as root the navigate to/var/www/html/fog/service/ipxeand drop the files. If you have to log in as a normal user then just drop the files in your normal user home directory. Then open a command prompt and issue
sudo cp bzImage-rt-v215 /var/www/html/fog/service/ipxe
and
sudo cp bzImage-rt-opts /var/www/html/fog/service/ipxeEdit: Tom knows all of the tricks to get things done…
-
Hopefully I did this correctly. I used Tom’s commands and then changed the kernel parameters in the GUI and then at the debug prompt ran ip addr to get the MAC, it both instances it pulled the Dongle Address (3c:18:a0:cb:3f:b7).
Here is the confirmation of the kernel for rt-v215 followed by the ip addr and the grep -i -e firmware /var/log/message command:
Here is the confirmation of the kernel for rt-opts followed by the ip addr and the grep -i -e firmware /var/log/message command:
-
@michaeloberg Yep that was right. And we have another bread crumb to follow. We see for the ops kernel, it wants rtl8153a-4.fw
I CAN fix that. Give me a minute (well about 10).
-
@michaeloberg Try this as bzImage-rt-opts2
wget -O /var/www/fog/service/ipxe/bzImage-rt-opts2 https://drive.google.com/uc?id=1ovhBUdH5OHadajGepSuOxCjBCMh-rCos&export=downloadsame protocol as the last opts kernel. Again this might not solve the mac address issue but it looks different than the previous kernel with the same fog kernel settings but updated nic driver. We can rule out the older nic driver at fault here.
-
OK, downloaded rt-opts2 kernel and ran the same commands as before, here is the output and verification snapshot of the opts2 kernel:
-
@michaeloberg Well unfortunately we’ve hit a wall. But you have some additional things to now tell HP support.
We are using the latest linux kernel, with the appropriate settings for this nic driver. Yet we are still not seeing the pass thru mac address.
We attempted to use the latest realtek nic driver with the latest linux kernel and no success. (I’m really not liking this approach because its not keeping the linux kernel pure with well tested drivers, but we needed to do it to rule out an old linux kernel driver at fault).
The native windows driver is doing the same thing.
-
@george1421
I will let you know when I hear back from HP, have a good weekend.Mike
-
I opened a ticket with HP on Friday, they escalated it and still haven’t heard back. I will update the post as soon as I hear from them.
Michael
-
@sebastian-roth said in HP Probook 430 G8 System MAC not passing through USB Type-C Dongle:
@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.
I’m sorry, I don’t mean to threadjack, but I have been strugglebussing for years (literally) trying to get these Lenovo ThinkPad x1 Carbon Gens 7, 8 and 9 to image with a dongle but have had no luck. Using this kernal has solved the USB adapter problems. How do I go about making it the main kernal so I don’t have to pre-create a machine and specify the kernal?
Please feel free to break this off into another thread (I just wanted it to have some context,) as there are a few other things that I have questions about.
Thank you so much for the amazing things y’all do!
-
@george1421
Update - HP has a Mac Address Management software they had me install in the Windows environment that worked, however it doesn’t do anything for FOS or Deepin. The program is called hpmamsrv.exe.Here is the software: https://ftp.hp.com/pub/softpaq/sp95501-96000/sp95997.exe
I have requested more information after relaying that this issue is not resolved as it doesn’t work for the Operating Systems.
I will let you know when I hear back from HP.
Michael
-
@michaeloberg Digging into the code a bit deeper I see that the stock linux kernel 8153 nic driver (v1.11) has support for mac pass through for lenovo. The realtek v2.15 driver (I added to one of the test kernels bzImage-rt-215) has additional support for Dell. Both Lenovo and Dell are specifically called out in the driver, but not HP. It looks like HP got around the windows driver issue by issuing a <snark>hack</snark> shim app that updates the mac address outside of the nic driver.
So if we think about it from a hacker’s perspective (1980’s terms not 2000’s terms for hacker) iPXE (which is reading the right value) is passing the mac address to bzImage as a kernel parameter (at least it should be). We might be able to use the “HP fix way” and use ethtool to replace the mac address of the detected nic. I know for a linux router project I worked on I was able to change the mac address of the nic to present itself as an Xbox mac. We would need to do this before the nic adapter is initialized in FOS linux (totally possible) so that means we might need a custom init.xz (also possible). Let me do some testing.
-
@george1421 This post is to just get my thoughts documented.
If we edit the FOS
/etc/init.d/S40networkstartup script and add a flag check after the network interface has been confirmed. If that flag says swap out the mac address with the one provided by iPXE then use theipprogram to replace the mac address.UNDERSTAND: NOTHING has been tested here. I just finished gluing it together from different code snippets.The heart of the code would be this section.
for retry in $(seq 3); do /sbin/udhcpc -i $iface --now ustat="$?" curl -Ikfso /dev/null "${web}"/index.php --connect-timeout 5 cstat="$?" # If the udhcp is okay AND we can curl our web # we know we have link so no need to continue on. # NOTE: the link to web is kind of important, just # exiting on dhcp request is not sufficient. if [[ $ustat -eq 0 && $cstat -eq 0 ]]; then if [[ ! -z $mac0 && ! -z $domacset ]]; then # Update the mac address if the DOMACSET flag # has been raised ip link set dev $iface down ip link set dev $iface address $mac0 ip link set dev $iface up fi exit 0 fi echo "Either DHCP failed or we were unable to access ${web}/index.php for connection testing." # If we are on the 2nd loop, lets check too seeif # spanning tree is blocking dhcp if [ $seq -eq 2 ]; then echo "Waiting for Spanning Tree timeout on $iface" sleep 27 else sleep 1 fi doneI also added in a bonus that on the 3rd try to init the interface, I added in a 27 second delay for spanning tree to start forwarding data. I figure if we get to the 3rd try the interface will probably not come up cause it either works right away or it doesn’t. One reason why it doesn’t is that spanning tree has the port in a blocking state.
The complete S40network file would be this:
#!/bin/bash # # Start the network.... # if [[ -n $has_usb_nic ]]; then echo "Please unplug your device and replug it into the usb port" echo -n "Please press enter key to connect [Enter]" read -p "$*" echo "Sleeping for 5 seconds to allow USB to sync back with system" sleep 5 fi # Geo-Grabbing kernel parameters because the variables are probably not set yet for var in $(cat /proc/cmdline); do var=$(echo "${var}" | awk -F= '{name=$1; gsub(/[+][_][+]/," ",$2); gsub(/"/,"\\\"", $2); value=$2; if (length($2) == 0 || $0 !~ /=/ || $0 ~ /nvme_core\.default_ps_max_latency_us=/) {print "";} else {printf("%s=%s", name, value)}}') [[ -z $var ]] && continue; eval "export ${var}" 2>/dev/null done # Enable loopback interface echo -e "auto lo\niface lo inet loopback\n\n" > /etc/network/interfaces /sbin/ip addr add 127.0.0.1/8 dev lo /sbin/ip link set lo up sleep 10 # Generated a sorted list with primary interfaces first read p_ifaces <<< $(/sbin/ip -0 addr show | awk 'ORS=NR%2?FS:RS' | awk -F'[: ]+' 'tolower($0) ~ /link[/]?ether/ && tolower($0) ~ /'$mac'/ {print $2}' | tr '\n' ' ') read o_ifaces <<< $(/sbin/ip -0 addr show | awk 'ORS=NR%2?FS:RS' | awk -F'[: ]+' 'tolower($0) ~ /link[/]?ether/ && tolower($0) !~ /'$mac'/ {print $2}' | tr '\n' ' ') ifaces="$p_ifaces $o_ifaces" for iface in $ifaces; do echo "Starting $iface interface and waiting for the link to come up" echo -e "auto $iface\niface $iface inet dhcp\n\n" >> /etc/network/interfaces /sbin/ip link set $iface up # Wait till the interface is fully up and ready (spanning tree) timeout=0 linkstate=0 until [[ $linkstate -eq 1 || $timeout -ge 35 ]]; do let timeout+=1 linkstate=$(/bin/cat /sys/class/net/$iface/carrier) [[ $linkstate -eq 0 ]] && sleep 1 || break done [[ $linkstate -eq 0 ]] && echo "No link detected on $iface for $timeout seconds, skipping it." && continue for retry in $(seq 3); do /sbin/udhcpc -i $iface --now ustat="$?" curl -Ikfso /dev/null "${web}"/index.php --connect-timeout 5 cstat="$?" # If the udhcp is okay AND we can curl our web # we know we have link so no need to continue on. # NOTE: the link to web is kind of important, just # exiting on dhcp request is not sufficient. if [[ $ustat -eq 0 && $cstat -eq 0 ]]; then # Geo-Checking to see if we should swap out the mac address if [[ ! -z $mac && ! -z $domacset ]]; then # Update the mac address if the DoMACSet flag # has been raised ip link set dev $iface down ip link set dev $iface address $mac ip link set dev $iface up fi exit 0 fi echo "Either DHCP failed or we were unable to access ${web}/index.php for connection testing." # Geo-If we are on the 2nd loop, lets check too seeif # spanning tree is blocking dhcp if [ $seq -eq 2 ]; then echo "Waiting for Spanning Tree timeout on ${iface}..." sleep 27 else sleep 1 fi done echo "No DHCP response on interface $iface, skipping it." done # If we end up here something went wrong as we do exit the script as soon as we get an IP! if [[ -z "$(echo $ifaces | tr -d ' ')" ]]; then # because ifaces is constructed with a space, we must strip it echo "No network interfaces found, your kernel is most probably missing the correct driver!" else echo "Failed to get an IP via DHCP! Tried on interface(s): $ifaces" fi echo "Please check your network setup and try again!" [[ -z $isdebug ]] && sleep 60 && reboot echo "Press enter to continue" read exit 1 -
@michaeloberg OK I have a new one-off init built. Download this file to
/var/www/html/fog/service/ipxedirectory. I debugged and replaced the script below in this this init to support mac spoofing like HP is doing. https://drive.google.com/file/d/1cFsPlkrqlwOjblHErCGr-OXHiKZd8jeZ/view?usp=sharingWe are still debugging here. So lets take baby steps. Once this is downloaded go into the host definition for this specific computer. We need to update some values.
Host Init: init_macset.xz
Host Kernel Arguments: domacset=1This tells this specific computer to use the new init (virtual hard drive). And the kernel parameter flags the mac replacement code to run. That way without that flag the network inits normally.
Schedule another task in debug mode on this dongled computer. Once in the FOS Linux CLI key in
ip a slets see if the nic has the mac address of the pass through mac. If not key in this commandcat /proc/cmdlineand post the results here. -
Thank you for the explanation and work on this. You mentioned to download the init_macset and place it in the /var/www/html/fog/service/ipxe directory. I have the file downloaded to my computer, how do I go about transferring that to my FOG Server? When I was downloading and testing kernels, I did that directly in the cli of the FOG server through Putty from the shared google drive.
TIA,
Michael
-
@michaeloberg You can use pscp from command line. That is putty’s copy program. Understand its all command line. Or you can use WinSCP which is a gui based copy program much like filezilla client or windows exporer (ish).
or we can hack up the URL that Tom provided below
wget -O /var/www/fog/service/ipxe/init_macset.xz https://drive.google.com/uc?id=1cFsPlkrqlwOjblHErCGr-OXHiKZd8jeZ&export=download
