DHCP Problem after FOG menu

[george1421]

@chrisyoung In your original picture, what happens when you press the enter key?

If you manually register a client, then tell the client to do a debug capture/deploy can you get to the command prompt of the FOS linux running on the target computer?

[chrisyoung]

@george1421

Hi George,

I am able to get to the iPXE> prompt

[george1421]

@chrisyoung OK sorry I read way to many posts then. I thought you were getting through the ipxe menu but getting hung up on once the FOS engine starts, it can’t init the network interface (where the kernel parameter discussion was coming from).

But looking at the first image again, that looks like the FOS engine so I’m a bit confused exactly where the image is from in the pxe booting process. Because the FOS engine should not return you to the ipxe> command prompt.

[chrisyoung]

@george1421

Hi George,

The first image I posted was from after I selected full host registration from the FOG menu.

Here is what I am seeing after enabling debug

[george1421]

@chrisyoung Sorry I got sidetracked by my real job.

Ok the ifconfig is interesting. What device is the mac address listed for eth0? Since eth0 exists and has a mac address FOS is able to talk to it (otherwise you would just have the lo interface).

[chrisyoung]

@george1421

That would be the wireless adapter MAC address

[george1421]

@chrisyoung That is very strange (as with this whole thread). The FOS Linux shouldn’t have drivers for wireless devices and yet it ignores the ethernet adapter in the dock (which it should support).

I guess I need to find someone else in the FOG forum that has one of these devices to see if they can give guidance. Because this is not behaving as the others have. It appears that the ethernet adapter is working because you can PXE boot from it. PXE booting only works from valid uefi network adapters. Its strange that FOS can’t see this usb etherent adapter though.

[george1421]

@george1421 I’m not seeing any past issues that could help with this one.

Lets take a different approach, I assume this carbon has an OS already on this device. Can you boot into windows and get the hardware ID for this network device? I forget what the ID is formated as under windows, but under linux it might look like this made up number [8086:1234]. We can check that network adapter vendor number against the supported driver list in linux (not related to fog).

[chrisyoung]

@george1421

This is what I get from the device manager under hardware ID

usb\vid_17E9&PID_431F&REV_0102&MI_05

[george1421]

@chrisyoung said in DHCP Problem after FOG menu:

usb\vid_17E9&PID_431F&REV_0102&MI_05

OK good the linux translation would be [17E9:431F]

DisplayLink Network Adapter NCM

From https://wiki.gentoo.org/wiki/DisplayLink
Required kernel parameters
Device Drivers —>
<> Network device support —>
<> USB Network Adapters —>
-M- CDC NCM support
<M> CDC MBIM support

http://nothen.com.ar/en/support-for-displaylink-adapters-on-linux/
Specific linux kernel driver code: http://nothen.com.ar/resources/displaylink-1.0.68.txz

If I understand correctly the cdc ncm module is needed and should be part of linux 4.7.2 onwards.

[Sebastian Roth]

I am not exactly sure but back in my mind I remember that we had issues with those CDC drivers and possibly removed those from the current kernel. Yes, looks like it: https://github.com/FOGProject/fogproject/blob/dev-branch/kernel/TomElliott.config.64

# CONFIG_USB_NET_CDCETHER is not set
# CONFIG_USB_NET_CDC_EEM is not set
# CONFIG_USB_NET_CDC_NCM is not set

Let me see if I find those old posts in the forum…

[chrisyoung]

@Sebastian-Roth

Is there a way to use an older Kernel that did have those settings?

Thanks,

Chris

[Sebastian Roth]

Quoting myself from the post here:

I just found out that all the RTL8152/8153 based connectors are blacklisted in the cdc_ether driver (see here: http://lxr.free-electrons.com/source/drivers/net/usb/cdc_ether.c#L686). Your microsoft NIC isn’t just because they don’t know/care about those yet I guess.

The issue we had was that MS surface devices wouldn’t properly boot with those CDC drivers in the kernel. As we didn’t need those back then we just removed them back in late 2015. I wouldn’t recommend using a kernel that old.

@Tom-Elliott Do you mind adding this driver to the kernel? http://nothen.com.ar/resources/displaylink-1.0.68.txz

@chrisyoung Or you could just build your very own kernel following the wiki article here: https://wiki.fogproject.org/wiki/index.php?title=Build_TomElliott_Kernel

[Tom Elliott]

@Sebastian-Roth Sorry to not read much, but do you by chance have straight up dmethod I could use to add?

[Tom Elliott]

@george1421, @Sebastian-Roth Turns out I can enable the NCM and MBIM without the EEM and CDCETHER (If I remember correctly, the cdcether was the thing causing all of our issues).

[Tom Elliott]

Kernels are updated with NCM and MBIM support.

Please try:

wget -O /var/www/fog/service/ipxe/bzImage https://fogproject.org/kernels/bzImage
wget -O /var/www/html/fog/service/ipxe/bzImage https://fogproject.org/kernels/bzImage
wget -O /var/www/fog/service/ipxe/bzImage32 https://fogproject.org/kernels/bzImage32
wget -O /var/www/html/fog/service/ipxe/bzImage32 https://fogproject.org/kernels/bzImage32

[george1421]

@Tom-Elliott Nice, it will be interesting to see if that addresses the issue.

It does appear that these DisplayLink chipset (and variants) are used in quite a few of these new external tablet docks from different hardware vendors. So if this addresses the OP’s issue without creating new headaches its a good move to add to the fog kernel.

[Sebastian Roth]

@Tom-Elliott Great stuff! Yeah from what I see in those MS surface posts it was only the CDC -ether driver causing the issue. Keeping my fingers crossed…