Hostid changing with network

[prestige787]

I'm having a problem where when I use my laptop on a different newtork, the hostid changes. More specifically, when I connect to a wpa2 enterprise network, the hostid becomes 00000000 (found with "hostid" command). On my home network the hostid is very different (still 8 characters though). As far as I know hostid should change only if the hardware changes, not the network you connect to. This is a problem for me as some software I need checks the hostid to validate the license. Is there any way that I can prevent the hostid from changing? I believe I followed the handbook exactly for network setup (dhcp).

[Hu]

What led you to think that the hostid is hardware related? As I read the documentation in man hostid, it has a decent chance of being the IPv4 address of your current hostname, if that is resolvable. That can easily change as you roam networks, so any license locks keyed to it are just defective. They should not be relying on that identifier for anything. Fortunately, according to man gethostid (referenced from man hostid), glibc can get an administrator-chosen hostid from etc, so you should be able to set the hostid to whatever value your broken licensing scheme wants to see.

[mike155]

You could fake the hostid. Create a program '/opt/fake_hostid/bin/hostid':

Code: Select all

#! /bin/bash
echo "1bac013d"

Start the program that calls 'hostid' to check the license with:

Code: Select all

PATH="/opt/fake_hostid/bin:$PATH" yourprogram

[no101]

if /etc/hostid exists, hostid(1) and gethostid(3) will read from that file instead. sethostid(3) will write to that file.

This is a trivial program to write the existing result of gethostid() into /etc/hostid. Run it on a working machine and then when you switch the network, hostid should still return the old id.

Code: Select all

#include <stdio.h>
#include <unistd.h>

int
main()
{
	if (sethostid(gethostid())) {
		perror("sethostid");
	}
}

Save that as save_hostid.c and compile it with

Code: Select all

gcc -o save_hostid save_hostid.c

Only root can execute the sethostid() command so it has to be run as root. You only need to run it once to generate the file, then switch networks and things should just work. To undo the forgery, just remove /etc/hostid.

Note: you should never just blindly run code off the internet so you can check what that code does with

Code: Select all

man 3 sethostid
man 3 perror

[prestige787]

Ok it's been a while but I still have not fixed this issue. I believe the root cause is related to this:

https://support.spirent.com/SpirentCSC/ ... d=SOL11499

I've tried a bunch of solutions I found online but none fix the problem.

The ifconfig command has the loop back first, and the actual card second. Is there any way to change this?

[grknight]

https://support.spirent.com/SpirentCSC/ ... d=SOL11499:

FLEXnet license manager only understand network interfaces starting with ethX and with network interface names like emX, pXpX, virbrX will return a null MAC address.

This means only ethernet is supported and wireless is not mentioned as available (can be a dumb program). As well as the net.ifnames=0 kernel command-line option needs to be included.

The ifconfig command has the loop back first, and the actual card second. Is there any way to change this?

This is nothing that is relevant as you can't change it.

If the hostid is changing after connecting to wireless, then, before it is connected, if hostid command gives a valid answer, write it to the file /etc/hostid and it will always be read from there.

[prestige787]

I am actually on wifi both times, not connecting to ethernet at all on this particular machine. I have already used a fix provided in this thread to get the hostid command to return a non zero value, however even with net.ifnames=0 set,

Code: Select all

./lmutil lmhostid

returns all zeroes (this is the binary tool the program uses to get the flexnet hostid) on the enterprise network, but on my home networks it returns a non zero value, so it must rely on something other than hostid.

[Hu]

For future readers, note that prestige787 opened an additional thread on this topic as Maple17. Given how this thread has gone to date, I am not inclined quite yet to merge the two threads, though I could be convinced to do so. For now, I am settling for posting cross-links in each thread so readers can find both of them.