DHCP Problem after FOG menu

[george1421]

Right, I know the pxe kernel has it configured to look at net0, if that doesn’t come up then it tries net1.

The issue is that the FOS engine doesn’t seem to give up on eth0 and move on to eth1.

[Wayne Workman]

I’ve wanted to change the inits to look for custom kernel arguments regarding mutli-nic for a while now, just never got around to it.

A similar problem in the past, a fellow had boxes with dual-nics each on separate networks. A peculiar setup, yes. But I figured we could pass kernel arguments via the host’s general page in the web interface that the inits could later look for (like network address), the inits would bring up all network faces and try to get an address, then shut down all the interfaces that didn’t match the kernel argument.

Typically wireless subnets in enterprise are not the same as wired subnets, they are usually separated. So the same idea would apply.

[chrisyoung]

@Wayne-Workman

Hi Waytne,

Did you ever get anywhere with that issue? Is there a list of kernel arguments somewhere that I could look at?

Thanks,

Chris

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