Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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)?
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.
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.
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.
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?
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.
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".
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.