@JJ-Fullmer The r8152.c from the torvalds github site failed to compile on 4.19.65, I’m suspecting its for a later release of linux. The version from the torvalds site was 1.10.10. The version in 4.19.65 was 1.9.9 of the realtek driver.

I was able to compile the realtek driver from the wget github site. This version is 2.12. Here is a link to that kernel with the 2.12 driver built in. I also enabled the usb-c code in the kernel that appears to have not been set. I don’t know if its relevant, but it should be on for other applications. https://drive.google.com/open?id=1wZwwOwbEr0nR3mnPLKg7AsulwJaGhO0A

Download this as bzImageRT (watch your case) and copy it to the ipxe directory with the other kernel images. Manually register the host and then in the host definition add in bzImageRT as the kernel for that host. Then pxe boot into FOS Linux debug mode to see if the network adapter inits correctly with this updated driver.

@JJ-Fullmer Ok as we already know its a realtek 8153 chipset. From the lsusb command its the first one [17ef:720c].

Not detecting a carrier is something that seems to be symptomatic of this linux kernel driver with this chipset. Looking at the kernel code it looks like the RTL8152/8153 is at version 1.10.10 and I’ve found a driver on github at 2.12 https://github.com/wget/realtek-r8152-linux

Looking at the torvalds github site (if that’s real), it looks like the r8152.c driver was updated 22 days ago adding a device ID for the Lenovo Thinkpad USB-C dock Gen2 (which may address the OPs issue). https://github.com/torvalds/linux/blob/master/drivers/net/usb/r8152.c

It may be worth it to pull this r8152.c driver and rebuild the FOS Linux kernel to see if it changes anything.

@JJ-Fullmer said in issue with netcard of dock gen2 of lenovo l390:

I’m not seeing the Vendor ID, but the driver Provider is realtek

Ugh, realtek… nuff said…

Will you boot in FOG Linux debug mode and key in lsusb and post the output here. (sorry I forgot it was a usb network adapter).

If you could boot this into debug mode and then run the following command lsblk That will tell us what FOS sees for the local block devices.

Also what target hardware (mfg and model) is this?

@JJ-Fullmer Ok if we want to look deeper into the network adapter, can you provide what windows sees as the hardware ID for this troubled nic? We’ll need the vend_id and the hareware_id to cross it to a linux driver.

Well the simple answer is not the best one I’m afraid. Use the intel.kpxe or ipxe.kpxe boot loader/kernel. The undionly.kpxe boot loader uses the built in network card’s UNDI functions to work. This keeps the iPXE small and fast because it doesn’t need one of every driver in the world, all its needs is the UNDI (universal) driver. Well some firmware is not as compatible as others.

So what can you do?

1. First I would ensure the target computers have the latest firmware.
2. Switch to uefi and then use the iPXE boot loader of ipxe.efi.
3. Stay in bios mode and switch over to the ipxe.kpxe boot loader. Both the ipxe,efi and ipxe.kpxe us the internal iPXE drives (one of many) instead of the generic driver (undionly.kpxe) for all bios based computers.
4. If you have a windows 2012 or later or a linux dhcp server then you can create filters to only send the intel.kpxe driver to these specific models of dell computers. (for those that may find this post later, Dell is one of the few vendors that embed a model specific UUID that ca be detected by the dhcp server). I have not done this bit before, but should be similar to what we have in the wiki.

@EBCF I’m pretty sure its related to not having a null terminated string.

Some pxe boot firmware will take the byte count (in this case 0x0d) and others need a null terminated string and just ignore the byte count. Its kind of a toss up.

So what can you do? Well you can install dnsmasq on your fog server to supply the pxe boot information and then just ignore your dhcp server for pxe boot information. That is what I do at home with my soho isp router. It sends out itself as the bootp server for some stupid reason. I use dnsmasq on the fog server to override it. I have a tutorial on installing dnsmasq on the fog server if you need it.

@JJ-Fullmer You really should start your own thread since the conditions are a bit different. Having a screen shot of the error would be helpful. Also remember there is iPXE (ipxe.efi) as well as FOS Linux (bzImage) in the mix. Knowing which one is having the error is helpful.

Well I got shutdown before I could get started. Your pcap only contains the tftp packets. I/we need to see the dhcp packets. If your fog server, dhcp server, and pxe booting computer are on the same subnet (or in reality if your fog server and pxe booting client on the same subnet) please follow this tutorial and run it on the fog server. This will capture the dhcp/bootp as well as the tftp transfer: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

@EBCF said in Some computer models adding garbage bytes to undionly.kpxe tftp filename, causing failure to PXE boot.:

Our environment is DHCP provided by a Unifi Security Gateway

Without looking at the pcap just yet, my bet is that the dhcp server is at fault. We have seen some non-mainstream dhcp servers not ending the file name string with an ascii null character, but rely on the byte count to signal the text length. Let me look at the pcap to see how close I am.