Dell Latitude 3340 with USB-C Ethernet Adapter - bad mac address registered

[pbriec]

Hi,

i have a question related to FOG and USB-C Ethernet Adapter.
The USB-C Ethernet Adapter has his own MAC Address (0C:xxxxxxxxx)
The Laptop Dell Latitude 3340 (without built-in ethernet port) has all options related to WOL and PXE in the BIOS. The MAC Address passthrough is also configured.
In Windows, with command line “ipconfig /all”, i can see the MAC Address from the PC with passthrough (28:xxxxxxxx)

If i boot to NIC USB, i can see the DHCP check the mac address (28:xxxxxxxxx). FOG doesn’t recognize the PC so i’m starting the full inventory.
When, i check back the inventory in FOG, i can see FOG has registered the PC with the USB-C adapter Mac address (0C:xxxxxxxxx)
If i manually change the mac address in FOG UI then it is recognized by FOG and i can WOL it. I have to check if i can boot it to PXE from WOL.
How FOG can register the good mac address (28:xxxxxxxx) and not the bad one (0C:xxxxxxx)

All the 30 laptops will be in charging cart with ethernet connections. So i want to use ethernet WOL to PXE to deploy images to PCs.

thanks for your answer. I’ve search in the forums but i didn’t find the same case.
Pierre

[Tom Elliott]

@pbriec https://forums.fogproject.org/topic/15885/hp-probook-430-g8-system-mac-not-passing-through-usb-type-c-dongle/4

This seems, as best I can tell, to have a similar problem.

I am seeing in this thread that the debug mode seems to get the correct device mac address (passthrough) but the getMACAddresses function we have in place appears to be getting the physical mac address off the device.

It’s interesting as ip a s works just fine, but FOG is using a command: ip -0 addr (along with some pipe commands) to get all device MAC addresses.

Would you be willing to boot your system into debug mode of FOS and performing some tests to see if we can confirm and potential address the problem?

[pbriec]

Hi @Tom-Elliott

i’ve run the debug mode and tried the two command lines
The result is the same: mac 0C:xxxxxxxx

anyway, dhcp and tftp before fog menu is using 28:xxxxxxxx mac address

[Tom Elliott]

@pbriec In the link I provided, @george1421 posted a different init.xz image file, I don’t know if that file is still available.

If you follow that post though, it should give enough direction to help provide the steps.

From your FOG Server

• Effectively, make a backup of your existing init.xz file:
  mv /var/www/fog/service/ipxe/init{,_orig}.xz
• Download the file
  curl -o init.xz https://drive.usercontent.google.com/download?id=1cFsPlkrqlwOjblHErCGr-OXHiKZd8jeZ&export=download&authuser=0
• Set the domacset=1 flag for all devices moving forward:
  • Goto FOG Settings and look for the “FOG_KERNEL_ARGS” element and add domacset=1 and save.
• Start a compatibility and see if the right mac address is now working

Hopefully it does

[george1421]

@Tom-Elliott said in Dell Latitude 3340 with USB-C Ethernet Adapter - bad mac address registered:

posted a different init.xz image file, I don’t know if that file is still available.

I can confirm that the file still exists.

I would have hoped that the later kernels would support mac pass through by now.

[pbriec]

@george1421 @Tom-Elliott

Hi, sorry for the late answer, i’m not everyday in that office, and i can’t make tests at any time.
Ok, so i’ve downloaded and installed the init.xz provided in the other thread.
Now, if i set the PC in debug mode, and run the two command lines.
The laptop is now recognized with 28:xxxxxxxx mac address.
But if i run the compatibility mode in FOG menu, MAC address is 0C:xxxxxxxxx
So i’ve deleted the PC in fog UI, and try a full inventory. The mac address is 0C:xxxxxxxx
So it still doesn’t work

[Tom Elliott]

@pbriec and you have the domacset flag set at the global level?

[pbriec]

@Tom-Elliott

yes, in FOG Configuration > FOG Settings > General Settings > KERNEL ARGS
domacset=1

I hope it’s in the right place.
Pierre

[Tom Elliott]

@pbriec That is the correct place.

With that set, I wonder why it’s not passing the correct mac through.

There’s not really a reason why in debug mode it works, but out of debug mode, it doesn’t

Just thinking out loud.

[pbriec]

Hi @Tom-Elliott

is there any workaround?
thanks

Pierre

[Tom Elliott]

@pbriec I suppose, what kernel are you currently using?

[pbriec]

@Tom-Elliott

how to check that?
I’ve seen that in FOG Configuration: bzImage and bzImage32
I’ve never updated kernel in FOG

[george1421]

@pbriec From the FOG web ui -> FOG Configuration -> Kernel update. It should tell you the current version and what is available. Download both the x64 and x32 bit version for the latest version of the FOS Linux kernel.

[pbriec]

@george1421 @Tom-Elliott

i’ve downloaded and installed the last kernel 6.1.63 (both x64 & x86).
I still get the mac’s dongle address in the compatibility menu. In debug menu, all is fine.

[Tom Elliott]

@pbriec The team and I in the background have been doing a lot a bit of testing.

Would you be willing to install the latest working-1.6 branch (or dev-branch)? I know this is technically an alpha, and will take a moment to get used to using, but functionally it should operate like normal just with a new UI:

cd /path/to/fog/installer
git checkout working-1.6
git pull
cd bin
sudo ./installfog.sh -y

This should download latest inits which, to the best of our knowledge works to set the mac.

You would need the domacset=1 setting.

Effectively, what this does, is it sets a new variable as part of the bootup called setmacto as the same as the mac address of the net0 adapter. (Thank you @george1421) If domacset is configured and this variable is set, it will do the network startup, get dhcp, check if the network is up and available, and then set that device to the setmacto MAC address, and reaccomplish DHCP since the MAC changed.

I have added this code to dev-branch as well, but if you’re willing to test the working-1.6 it’s worth it in my opinion (of course I would say that lol).

Of course if you aren’t comfortable testing the alpha, but okay with the iterative development (dev-branch) change the checkout to use that branch.

This should work though it does require (on registration) the domacset=1 at a global level - which I think is fine.

Also, the installer I have the argument -y this just means to ‘Auto accept’ as it may ask questions. If you’re uncomfortable with that method, please just remove the -y argument.

[pbriec]

Hi @Tom-Elliott,

So i’ve tested and it seems to work.
Now, i’ve the same MAC address both in compatibiliy mode and after dhcp process.
I’ve read again my notes and i can’t manager to wake up with WOL.
I don’t know what is wrong.
I will contact Dell tomorrow. I remember it was working before.
I’ve tested another laptop with ethernet, and it’s working fine.
The WOL processus could be unmanaged with usb ethernet adapter?

thanks
Pierre

[Tom Elliott]

@pbriec

I have modified the init’s that should automate the fixing of mac address when there’s a passthrough (variance of ipxe -> init) noticed.

You will no longer need the domacset flag defined, it will just do the action of setting the mac address as appropriate:

https://github.com/FOGProject/fos/releases/tag/EXP_20240618

Replacing the init files as required shoudl fix this issue and as we get new versions happening, this will become a standard.

[pbriec]

@Tom-Elliott

Ok, i’ve updated the init.xz and init_32.xz files. I confirm that i do not have to set the kernel args now.
I’ve registered the laptop from scratch and now it’s the correct mac address.

I’ve noticed some bad things with this new FOG.

An old laptop can be woken up and FOG create a task that is not automatically deleted after.
This new laptop with USB adapter cannot be woken up and the task is remaining in the actives tasks.

I’ve never managed to wake up this new laptop
In the new Fog, i have the following error: “DataTables warning: table id=host-snapin-history-table - Ajax error. For more information about this error, please see https://datatables.net/tn/7”
So it doesn’t start the PC, and if i wake up it manually, it will boot to fog trying to do something that failed.
refind also doesn’t boot correctly the PC.

So the new fog is fine about the mac address problem but the fonctionnalities are strange
Have you noticed that?

Pierre

[Tom Elliott]

@pbriec I don’t know what you mean by waking up an old laptop. I’m assuming there’s a task that you’re not able to see in the UI, but that was an imaging type of task (those are the type that do WOL)

As to why your new laptop is not able to WOL, i do not know if it’s because of the passthrough vs the actual MAC address of the adapter. You could test, but adding the true mac address of the adapter to the host and tasking to see if it wakes up. This is because the magic packet needs to indicate the burned in address (to my knowledge) for the interface to actually respond and kick up the system. Then again, i don’t know how an externally but connected (USB-C/USB-A) wire would tell the laptop to wake up. I could imagine it working on USB-C, but still having a bit more difficultly than a natively board mounted network card.

As for the host-snapin-history-table, I’m aware of the issue, but I have not yet been able to replicate it.

I’ll see if I can do so today, by creating a false entry.

Thank you!

[Tom Elliott]

@pbriec Figured out, I think, the issue of your host-snapin-history-table:

It’s database entries have gone out of sync:

Please login to your mysql/mariadb on the server: (The password will be in your /opt/fog/.fogsettings file under snmysqlpass or something very similary, usually under the variable named snmysqluser=fogmaster

mysql -u fogmaster -p fog

It will prompt for your password, which you collected earlier and hit enter

in the mysql side you can run:

delete from snapinJobs where sjID not in (select stJobID from snapinTasks) or sjID=0;
delete from snapinJobs where sjHostID not in (select hostID from hosts) or sjHostID=0;
delete from snapinTasks where stJobID not in (select sjID from snapinJobs) or stJobID=0;

That should fix the host-snapin-history-table issue.