Problem

A customer of Artwork's reported that on his Linux workstation (configured with dual ethernet cards) he could not obtain any hostid using the flexlm utility lmhostid. We traced the problem to the ethernet card configuration. Apparently the flexlm licensing mechanism looks for the MAC address only on the eth0 interface and if, for some reason, there is no network adapator assigned to eth0, lmhostid returns no hostid (since lmhostid obtains its hostid based on the network card's MAC address.) This, in turn, prevents one from generating a license for the machine.

This hasn't been a problem on most machines since eth0 is usually assigned to the "first" network adaptor.

Apparently some flavors of Linux use a dynamic method of assigning device files/names which result in network adaptors assigned to names other than eth0. We were able to duplicate this problem on a laptop running Ubuntu 7 (kernel 2.6-20). Based on working with this machine we could duplicate the customer's problem and then search for a "work-around."

Workaround

We have found a workaround that maps the network card to eth0 but first, a little background about how the adaptors are dynamically assigned.

Device mapping on some of our Linux machines are controlled by the file /etc/iftab.

On our Ubuntu test machine this file, /etc/iftab, is not present and the network devices assignment is controlled by files located in the /etc/udev/rules.d directory.

What's in Rules.d

This directory will contain two files with names the same as (or similar to) the following:

75-persistent-net-generator.rules

70-persistent-net.rules

The file, 75-persistent-net-generator.rules, contains rules for a script /lib/udev/write_net_rules that runs each time the machine boots up.

# these rules generate rules for persistent network device naming

ACTION=="add", SUBSYSTEM=="net", KERNEL=="eth*|ath*|wlan*|ra*|sta*" \
    NAME!="?*", DRIVERS=="?*", GOTO="persistent_net_generator_do"

GOTO="persistent_net_generator_end"
LABEL="persistent_net_generator_do"

# build device description string to add a comment the generated rule
SUBSYSTEMS=="pci", ENV{COMMENT}="PCI device $attr{vendor}:$attr{device} ($attr{driver})"
SUBSYSTEMS=="usb", ENV{COMMENT}="USB device 0x$attr{idVendor}:0x$attr{idProduct} ($attr{driver})"
SUBSYSTEMS=="ieee1394", ENV{COMMENT}="Firewire device $attr{host_id})"
SUBSYSTEMS=="xen", ENV{COMMENT}="Xen virtual device"
ENV{COMMENT}=="", ENV{COMMENT}="$env{SUBSYSTEM} device ($attr{driver})"

IMPORT{program}="write_net_rules $attr{address}"
ENV{INTERFACE_NEW}=="?*", NAME="$env{INTERFACE_NEW}"

LABEL="persistent_net_generator_end"

The second file, 70-persistent-net.rules, contains the names of the device files:

# This file was automatically generated by the /lib/udev/write_net_rules
# program, probably run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single line.


# PCI device 0x10de:0x054c (forcedeth)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:00:6c:cf:5d:76", NAME="eth0"

# PCI device 0x14e4:0x4311 (bcm43xx)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:00:00:1a:73:a5", NAME="eth1"

# PCI device 0x10de:0x054c (forcedeth)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:00:6c:cf:5d:76", NAME="eth2"

# PCI device 0x14e4:0x4311 (bcm43xx)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:00:00:1a:73:a5", NAME="eth3"

# PCI device 0x10de:0x054c (forcedeth)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:00:6c:cf:5d:76", NAME="eth4"

# PCI device 0x14e4:0x4311 (bcm43xx)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:00:00:1a:73:a5", NAME="eth5"

It appears to us that each time the networking is reconfigured (for example, if one switches from a wireless adaptor to a wired adaptor) and then rebooted, this rule file gets updated and new network device names are assigned. On this particular machine, which is regularly switched from a wireless connection to a wired connection, the most recent ethernet assignments had incremented to eth76.

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
192.168.0.0     *               255.255.255.0   U         0 0          0 eth76
link-local      *               255.255.0.0     U         0 0          0 eth76
default         192.168.0.1     0.0.0.0         UG        0 0          0 eth76

The Remedy

There may be more than one way to address this issue but one that worked in this case was to edit the file, 70-persistent-net.rules, and remove all references to the "net" subsytem devices. Then make sure that the file, /etc/network/interfaces is set up appropriately to work on eth0. On our test box we edited as follows:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.0.181
netmask 255.255.255.0
gateway 192.168.0.1

Then reboot and check to see that eth0 is attached to one of the network adaptors on your machine.

Permanent Solution?

This is probably not a good permanent solution since if one makes any changes to the networking, the machine will probably once again update the network adaptor device names and break lmhostid. However, at the moment it is all we have. Any users with more information should contact us at support@artwork.com.