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


  • @george1421 @Sebastian-Roth

    So I disabled the Wi-Fi card in the BIOS:
    Disabled WiFi.jpg
    iPXE still shows the BIOS (System MAC):
    iPXE Same.jpg
    FOG still show the Dongle MAC:
    FOG MAC Same.jpg
    So I removed the Wi-Fi Card:
    Removed WiFi Card.jpg
    Same thing, here is the MAC on the card and it matches ipconfig in windows:
    WiFi Mac Label.JPG
    ipconfig from earlier:
    MAC Addresses.JPG


  • @sebastian-roth

    Here is a screenshot of the NICs, Red Line is the Dongle and Blue Line is the Wi-Fi:

    MAC Addresses.JPG

    iPXE is showing the MAC of the System as indicated in the BIOS:

    BIOS Screen Capture.JPG

    iPXE:

    After.jpg

  • Moderator

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

  • Moderator

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

  • Moderator

    @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

    ip a s.JPG

    NOTE the 3c:18a:cb:3f:b7 is the MAC of the HP Dongle:

    Dongle.JPG

  • Moderator

    @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
    I ran two separate commands:

    1. The first one was lspcl - nm | grep -i -e "net"
      This gave me this output:

    first command.JPG

    1. The second command was lsusb ip a s
      This gave me this output:
      second command.JPG

    I may be confused as you mentioned this:
    commands.JPG

    Which I did on two separate lines in the CLI from the # prompt.

    Let me know if this was incorrect.

    Michael

  • Moderator

    @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
    Below is the output:

    update.jpg

  • Moderator

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


  • @george1421

    Here is the screenshot from the BIOS:

    BIOS Options.jpg

  • Moderator

    @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?


  • @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:

    BIOS Screen Capture.JPG

    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:

    Windows Snip.JPG

    Deepin Screenshot.jpg

    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

  • Moderator

    @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).


  • @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:

    Windows Snip.JPG

  • Moderator

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


  • @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:

    Before PXE Upgrade.jpg

    Here is a screenshot after the iPXE update to verify the current date using ls -la /tftpboot/*.efi

    ls PXE.JPG

    Here is a screenshot after I updated iPXE, note the (g98625) hex number:

    After.jpg

    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):

    Before PXE Upgrade2.jpg

    Hopefully this is enough information to get us through to the next step, I appreciate the help.

    Michael

  • Moderator

    @george1421 You are spot on here I think. Debugging the other issue with @michaeloberg I started with iPXE but was wrong then and this time went the other way from the kernel side but wrong again. 😉

  • Moderator

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

355
Online

9.1k
Users

15.7k
Topics

145.9k
Posts