[SOLVED] udev annoyances

Skaperen · 03-04-2011, 08:19 AM

I set up a system on a hard drive using a machine I have here that is identical to a remote machine the system was intended for. Everything was working fine here. The hard drive was shipped to the remote site and plugged in there. But networking was not working. Turns out udev forced the network interfaces to be renamed. So instead of them being eth0 and eth1, they were renamed as eth2 and eth3 on the remote machine. The configuration, referencing eth0 and eth1, therefore did not work. I've found the culprit to be udev and edited the file "/etc/udev/rules.d/70-persistent-net.rules" to work around it by matching the remote machine's MAC addresses to eth0 and eth1.

I understand udev is trying to make things consistent in case devices probe out to other locations at the next reboot or power cycle. But in this kind of situation, udev is actually doing more harm than good.

Is there by chance any feature in udev to make it smarter? If not, how can I configure udev to just not mess with network interfaces at all (while still leaving it working for other devices)?

SL00b · 03-04-2011, 01:06 PM

If you don't care which NIC comes up as which ethernet device, you could just wildcard the MAC address in the udev rules. This is pretty typical if you're just going to bond them to the same IP for redundancy.

But if you do care, maybe because you're going to be bridging two networks and those need to be statically assigned, the best I could say is to look at "udevadm info" and see if there's something else that's different between the two you can key off of.

Otherwise, I'd say you're going to have to obtain the MAC addresses of your machine you're cloning to ahead of time, and once you've got everything else set up the way you want, change /etc/udev/rules.d/70-persistent-net.rules to match the MAC addresses of the new machine, then shut down and ship the HDD.

Skaperen · 03-04-2011, 01:58 PM

For now it's the "don't care" scenario. Both NICs will connect to the one and only LAN at their location. Or in some cases just one of them, with the other not connected.

How is a wild card done? Change ATTR{address}=="00:25:90:14:c4:59" to be ATTR{address}=="*" ?

At some point in the future I'm sure I will want a configuration with 2 or more separate LANs having different subnets. And to complicate things more, some LANs may have more than one subnet. The only way I can see to do this is a smart network manager that watches what traffic is arriving on each NIC, and figures out what is out there based on various seen traffic, like all the ARP broadcasts. It could also have information about each subnet listed, including known hosts/routers in each, which it could try to ping on all NICs until it finds things.

SL00b · 03-04-2011, 02:08 PM

Quote:

Originally Posted by Skaperen

How is a wild card done? Change ATTR{address}=="00:25:90:14:c4:59" to be ATTR{address}=="*" ?

Yep.

Skaperen · 03-04-2011, 02:21 PM

OK, so how does that work for 2 or more NICs?

Code:

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="*", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="*", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="*", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2"

Will this try to name all three to be "eth0" or will it know to name them from different rules?

SL00b · 03-04-2011, 02:44 PM

It'll just grab them as it finds them, so the first device it brings up will become eth0, the next eth1, and so on.

If you want to see a working example:

Code:

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="32:*", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00.*", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00.*", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2"

In this example, eth0 is an entirely different type of card, and it'll always have the first value in the MAC set to 32. The other two devices are two different ports on the same card.

Skaperen · 03-04-2011, 02:57 PM

So how do I tell udev to simply not make any assignments whatsoever, and to leave all network interfaces named as the kernel originally named them, and not even try to record the current names for future?

SL00b · 03-08-2011, 08:09 AM

If that's what you want to accomplish, I suppose you could wildcard all the entries except kernel=, and hardcode that one, so it'd look like this:

Code:

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="*", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth0", NAME="eth0"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="*", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth1", NAME="eth1"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="*", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth2", NAME="eth2"

Skaperen · 03-08-2011, 01:39 PM

So basically this just forces a 1 to 1 mapping for each interface named ... and I just make sure to name at least as many interfaces as I might have?

SL00b · 03-08-2011, 03:55 PM

That's how it'd work in theory, at least, yes.

Let me know how it turns out.

Skaperen · 03-24-2011, 08:25 AM

It would be nice if udev had the ability to list devices and interfaces (I think of interfaces as devices, too, BTW) to "block" from its actions.

SL00b · 03-24-2011, 08:36 AM

I suppose if you wrote your rules in such a way that none of the rules are a match, it'd have to leave it alone.

For example, if you had two rules, for kernel==eth0 and kernel==eth2, then eth1 wouldn't match any of those rules, and it couldn't do anything with it.

I'm not sure why you'd want to, though.

Skaperen · 03-25-2011, 01:28 PM

What would happen with no rules at all? Nothing should match, right? But the effect I got was that it generated rules to match the existing situation so it could make that happen again (ultimately to pair that IP address to that MAC address).

I think that is fundamentally wrong. MAC addresses can change, too. I got bit by that several times. Now I'm using the wildcard example, expanded to cover eth0 to eth9 (just in case). It's in my "tree of files to drop in whenever I install a new Linux system".