WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: unreliable ethernet setup  (Read 4275 times)

Offline medvedm

  • Newbie
  • *
  • Posts: 48
unreliable ethernet setup
« on: December 14, 2010, 01:02:34 PM »
Hi-

I've run into an interesting situation with TC and I was hoping you guys would have some idea about what is going.  I've got a system with 3 NICs, one on the main board, and two on an expansion board.  The one on the main board is the only one I care about using right now, and I want it to be a static IP (of the 192.168.100.x variety).  So I set it (both with ifconfig and the network app).  It worked fine for a couple of reboots and then it lost the IP.

Except that what happened is that it didn't actually lose the IP.  eth0 was still set as 192.168.100.10, but it suddenly couldn't ping anything any more.  So I looked around in the dmesg log and saw that eth1 was reporting it was up... which shouldn't be possible because nothing is plugged into that port.  Nevertheless, I configured eth1 to be the right IP and was now able to ping everyone.

Is there a way to hard associate an Ethernet adapter with eth0, eth1, or eth2?  That way when the system boots up the right adapter is with the right device and gets the right IP address.

Or have I totally missed something?

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 11044
Re: unreliable ethernet setup
« Reply #1 on: December 14, 2010, 01:11:23 PM »
udev rules. You can assign names by MAC address, for example.
The only barriers that can stop you are the ones you create yourself.

Offline danielibarnes

  • Hero Member
  • *****
  • Posts: 548
Re: unreliable ethernet setup
« Reply #2 on: December 14, 2010, 01:16:52 PM »

Offline medvedm

  • Newbie
  • *
  • Posts: 48
Re: unreliable ethernet setup
« Reply #3 on: December 14, 2010, 03:59:36 PM »
Thanks, I think this got me what I needed.

Offline medvedm

  • Newbie
  • *
  • Posts: 48
Re: unreliable ethernet setup
« Reply #4 on: December 15, 2010, 09:02:19 AM »
Yeah, except I can't seem to make this work right.

I added a file to /etc/udev/rules.d/ called 10-local-network.rules with the following lines:

KERNEL=="eth*", ATTR{address}=="00:20:9d:15:54:72", NAME="eth0"
KERNEL=="eth*", ATTR{address}=="00:d0:81:07:00:36", NAME="eth2"
KERNEL=="eth*", ATTR{address}=="00:d0:81:07:00:37", NAME="eth1"

But, it is still totally random if 72 or 36 gets eth0.  Of course, I added my file to filetool.lst so it gets backed up.

I checked the addresses using udevadm and they are right.

I'm sure I've missed something, help?

Offline medvedm

  • Newbie
  • *
  • Posts: 48
Re: unreliable ethernet setup
« Reply #5 on: December 15, 2010, 09:06:24 AM »
Another total newb question: in testing these changes I'm having to restart everytime, I"m sure I could do something easier like unload and reload the ethernet module, right?

To do so, I'd do something like this:  modprobe -r e1000e
and then to relaod: modprobe -a e1000e


Offline tinypoodle

  • Hero Member
  • *****
  • Posts: 3857
Re: unreliable ethernet setup
« Reply #6 on: December 15, 2010, 11:02:40 AM »
and then to relaod: modprobe -a e1000e

Where did you get the '-a' from?
"Software gets slower faster than hardware gets faster." Niklaus Wirth - A Plea for Lean Software (1995)

Offline medvedm

  • Newbie
  • *
  • Posts: 48
Re: unreliable ethernet setup
« Reply #7 on: December 15, 2010, 11:17:44 AM »
BusyBox v1.17.2 (2010-09-24 12:19:23 PDT) multi-call binary.

Usage: modprobe [-alrqvsb] MODULE [symbol=value]...

Options:
        -a      Load multiple MODULEs
        -l      List (MODULE is a pattern)
        -r      Remove MODULE (stacks) or do autoclean
        -q      Quiet
        -v      Verbose
        -s      Log to syslog
        -b      Apply blacklist to module names too

Offline tinypoodle

  • Hero Member
  • *****
  • Posts: 3857
Re: unreliable ethernet setup
« Reply #8 on: December 15, 2010, 11:22:47 AM »
I stand corrected.   :-[
"Software gets slower faster than hardware gets faster." Niklaus Wirth - A Plea for Lean Software (1995)

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 11044
Re: unreliable ethernet setup
« Reply #9 on: December 15, 2010, 11:57:17 AM »
When testing, as root

#edit file
udevadm control --reload-rules
#remove module
udevadm trigger

Since backup is a bit too late in the boot process, you'll probably need something like that in bootsync.sh.
The only barriers that can stop you are the ones you create yourself.

Offline medvedm

  • Newbie
  • *
  • Posts: 48
Re: unreliable ethernet setup
« Reply #10 on: December 20, 2010, 12:50:45 PM »
I'm not sure I know what you mean by "Since backup is a bit too late in the boot process, you'll probably need something like that in bootsync.sh."

Has anyone out there ever actually got this working?  If so, I'd love to see a copy of your rules file for udev because everything I'm trying is not working at all.  It seems a bunch of the udev stuff was borrowed from LFS, so I googled how LFS does at and still having no luck.

AGGHHH!!!!

This is another one of those things in the "should be easy but isn't" category.

Offline tinypoodle

  • Hero Member
  • *****
  • Posts: 3857
"Software gets slower faster than hardware gets faster." Niklaus Wirth - A Plea for Lean Software (1995)

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 11044
Re: unreliable ethernet setup
« Reply #12 on: December 20, 2010, 01:29:53 PM »
Works for me using instructions above.

Quote
etc/udev/rules.d/10-ethernet.rules
KERNEL=="eth*", ATTR{address}=="52:54:00:12:34:56", NAME="netc"

Quote
opt/bootsync.sh
#!/bin/sh
# put other system startup commands here, the boot process will wait until they complete.
# Use bootlocal.sh for system startup commands that can run in the background
# and therefore not slow down the boot process.
/opt/bootlocal.sh &
udevadm control --reload-rules
modprobe -r e1000
udevadm trigger

This works in Qemu, renaming the card from eth0 to netc.

Quote
I'm not sure I know what you mean by "Since backup is a bit too late in the boot process, you'll probably need something like that in bootsync.sh."

Backup happens quite late in the boot process, by this time the cards have already been brought up. This is why the module has to be removed, so that the new rules will be in effect.


edit: The busybox equivalent to ifrename is nameif, which can also be used.
« Last Edit: December 20, 2010, 01:31:53 PM by curaga »
The only barriers that can stop you are the ones you create yourself.

Offline danielibarnes

  • Hero Member
  • *****
  • Posts: 548
Re: unreliable ethernet setup
« Reply #13 on: December 20, 2010, 02:04:34 PM »
Thanks for the tip about nameif. I did not think of that. It looks like that gives you two ways to solve the problem. You can save name/address pairs in /etc/mactab:

# Begin /etc/mactab
# This file relates MAC addresses to interface names.
# We need this so that we can force the name we want
# even if the kernel finds the interfaces in the
# wrong order.

# eth0 under 2.4, eth1 under 2.6
beannet 00:60:97:52:9A:94

# eth1 under 2.4, eth0 under 2.6
sparenet 00:A0:C9:43:8F:77

# End /etc/mactab

Offline medvedm

  • Newbie
  • *
  • Posts: 48
Re: unreliable ethernet setup
« Reply #14 on: December 20, 2010, 02:40:44 PM »
Ahhhh, now the missing piece comes together.  Once I added the code below to my bootsync.sh, this starting working out.  I didn't understand that the actual /etc/udev/rules.d/10-network.rules files wasn't restored in time to be run by the udev tool.  I guess in that case, udev obviously wouldn't rename the stuff correctly.

May I suggest a wiki page describing this?  I'll even write up the first draft.  The bootsync.sh file edit is incredibly important, and TC specific.  Also, in my bootsynch.sh, I put the call to bootlocal.sh at the bottom... because in bootlocal, it calls the IP address config scripts, which I don't want to happen until AFTER I am sure the devices are named correctly.

Side note - most of the stuff I read on the web says not to use nameif, that udev is the way to do it.

Thanks for the help!

M