DHCP Problem after FOG menu

[chrisyoung]

Good afternoon,

First post here, but I have been using FOG for a few years now.

This issue has me stumped.

I have a late 2016 (or early 2017) Lenovo X1 Carbon (has no ethernet port) and I am using a USB3.0 Lenovo basic dock (P/N DL3700) for its ethernet port.

I have followed this guide BIOS and UEFI Co-Existence and setup our server 2012 DHCP as instructed.

We are running FOG 1.3.4 on CentOS7

I am able to PXE boot using ipxe.efi and I am able to get an IP on the net1 interface (interface net0 fails), and from there I am greeted with the FOG Menu.

Now my problems begin once I try to do a host registration or quick image.

I get the following.

I have also tried manually creating the host and adding the has_usb_nic=1 option and I get the same result.

I have also tried putting a dumb switch in-between the main connection and the PC with no change.

Any ideas as I am stumped.

Cheers,

Chris

[george1421]

Can you tell by the mac addresses for eth1 if that is your usb ethernet adapter?

This is an interesting one, in that I’m not sure if there is a way to tell the FOS linux engine to ignore eth0 and use eth1 instead. This doesn’t appear to be a spanning tree issue. It sounds like FOS is trying to use the eth0 (which is probably the wireless adapter) and not eth1 which is the ethernet adapter in the dock.

I know others have use the dock with the carbons without issue.

[chrisyoung]

Hi George,

During the pre menu process it looks for an IP for net0 (has no MAC listed) and then for net1 (with the MAC of the dock) then it boots to the 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?