Skip navigation.
Home
Now Shipping Version 7.0

eth0 and eth1 keep switching


Posts: 46

I have been having trouble with eth0 and eth1 (wireless and ethernet cards) switching places between reboots. I've done some reading in other forums on the subject, but I haven't found a solution that works yet. A lot of discussions on the matter suggest changing the order that they startup when booting. However, Mepis doesn't use the /etc/modprobe.conf file like other distributions do. Is there a way in Mepis 6.0 to decide which (wireless or ethernet) will get the designation eth0 and which gets eth1 once and for all?

Thanks,
Vergil

Nix Hard's picture

Go into MEPIS Utilities >

Go into System Configeration > System Administration > MEPIS Utilities > Network > Disable the network interface you don't want to start at boot time > click apply > stop/restart the network interface you want to use/are using.

Still does it. . .

Thanks for the suggestion. I tried it, and here's what happened:

I had checked the "start at system boot" box for eth0 (my wireless connection) in the Mepis utilities, and unchecked that box for eth1. Then, the next time I boot up, my wireless did not connect so I go to the Mepis Utilities and enable eth1 and start it up, and it connects to my wireless network. The next time I boot it switched again back to eth0 and I keep having to reconnect in Mepis Utilities. Is there a way to assign wireless and ethernet to eth0 and eth1 (respectively) forever?

Thanks again

Jon Du Quesne's picture

How Are The IP Addresses Assigned?

vmueller, how are your IP addresses assigned? Are you using DHCP (dynamic) assignment? If so, who/what is assigning the address? Is it through your wireless router. More details please.

Depending upon the above (using dynamic or static IP) it might be possible to assign the IP address based on the MAC address of the two cards. I'm not sure off hand; this is a guess.

And just for clarification, is eth0 the wireless card or eth1?

Jon

udev is the answer

OK, after a bit of research I learned how to write a udev rule to fix the problem.

First you need to find the mac address of the card you want to be eth0.

If the that card is now eth0 , open a Konsole and use the command:
udevinfo -a -p /sys/class/net/eth0

if it's currently at eth1 instead use:
udevinfo -a -p /sys/class/net/eth1

Leave that window open so you can copy and paste in a moment.

As root open an editor (a good way is <alt>F2 kdesu kedit) and enter this:
KERNEL=="eth*", SYSFS{address}=="00:00:00:00:00:00", NAME="eth0"

In place of the SYSFS{address} line, paste in the SYSFS{address} line from the output you got from udevinfo.

Save this file in the /etc/udev/rules.d directory with the name: 11-local.rules

When you reboot this script will make sure that the card with that mac address is named eth0. The other one will end up as eth1 by default.

Good Luck!

The easiest way looks to me

The easiest way looks to me to use wlan for the wireless instead of eth0/1 in multilities..
If that is not possible try it with adding an udev rule.
You have to create a file /etc/udev/rules.d/010_netinterfaces.rules .
For example move the ethernet networkcard to eth1

KERNEL=="eth*", SYSFS{address}=="00:11:22:ee:dd:cc", NAME="eth1"

You will find your HWaddress(here 00:11:22:ee:dd:cc) here: kinfocenter>network interfaces.

udev IS the answer

Thanks for the walkthrough. I now have my network interfaces set up exactly like I want them, with wireless on wlan0 and ethernet on eth0. They don't switch back and forth any more, which is very helpful.

Again, thanks for the help. Sorry it took a while to respond.

Jon Du Quesne's picture

Good News

vmueller, glad to hear things are now working.

For the education of others (myself included) could you please post some specifics of exactly what you channged and how (diretories and files); without giving away any security related information of course? That way if anyone else has a similar problem we can show them how to do it.

Thanks in advance.

Jon

For the record

Jon,

Sorry I didn't recap what I did. I essentially followed timbk4cq's suggestion verbatim, and my problem was resolved. I couldn't write it any better myself.

vmueller

more info

Ok, I guess I can add this little organizational tip to what timbk wrote in his walkthrough:

If you are setting up a wireless and an ethernet connection, go ahead and assign the wireless card to wlan0 and the ethernet connection to eth0. That at least helps me remember which network interface does wireless and which controls the ethernet card (I have my modem set up as ppp0), and I don't have to remember "ok, wireless is eth0 and Ethernet is eth1" every time I want to send one commands from the terminal.

I wish distributions would adopt that convention universally, because it helps prevent problems like the one I was having.

vmueller

m_pav's picture

udev rule can sometimes cause a lockup with vmware

I had this same problem on my Toshiba Tecra M30. My wired and wireless were swapping addresses and there was no way I could get them to play together nicely and stop stealing the others address. I needed to install VMware but was unable to get any reliable networking happening so I had to can the idea until I was pointed to this post a few months back.

I followed the instructions and pinned the wireless to eth1 which I monitored for a month and all was well until I installed VMware and it's associated vmnet devices. Now I had to contend with random lockups on startup during the hardware initialization stage and always at the 10% mark (if using splashy) which is where the ipw200 module is loaded.

The only way I had of recovering was to hold the power button in for 6 seconds and kill everything, then wait for ages while my system checked the hard disk after an unclean unmount - grrr. This happened 2-3 times out of 10 starts, not including the forced restarts.

The wireless driver used is ipw200 which has native kernel support, so the wireless device is given "native" support, making it appear to be a wired device to the linux kernel.

I am trialling a small change to the rule to see if that helps, and so far, my system has responded as I hoped it would. What I did was to pin the device to a more appropriate device name like ath0 so as to get it out of the eth devices and blow me down if it didn't work. After approx 10 months of frustrations, a simple adjustment to a rule I had been using for 2-3 months appeared to have done the trick, and here is the rule I applied.

KERNEL=="eth*", SYSFS{address}=="xx:xx:xx:xx:xx:xx", NAME="ath0"

I don't know if it will stop the fighting, but I certainly hope it will. For now, I need to uninstall vmware and re-install it to have the net devices correctly mapped because I know of no other way, but I am going to switch to the 686 kernel because I need to utilise that little bit extra it will give me for running a virtual machine.

Mike P

--------------------
Life may not be the party we thought, but while we're here, we may as well dance.
Break M$'s shackles from your feet and free yourself with Mepis

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.