Binding of ethX to the interfaces.

Hi

I have a pretty good grasp of linux. Been using it for a fair while.
This morning I compiled kernel 2.6.7 and installed it. As has happened
several times before, upon booting, my ethernet interfaces have been rebound
to different aliases. i.e. eth2 became eth0 and eth0 became eth2. eth1
stayed the same. To clarify - the network settings of each is ok and
doesn't conflict with firewall rules. This isn't too big a problem since
it's a matter of switching the cables around. However, two of the
interfaces are 100mb and one is 10mb. I'd rather use the 10mb with my cable
modem.

I'm pretty sure the MAC address can be specified in either the
/etc/sysconfig/network-scripts/ifcfg-ethX files or /etc/sysconfig/hwconf
entries. I'm not too sure about this though and would appreciate any advice
on offer.

Using Fedora BTW.

Cheers
Dan

On Tue, 29 Jun 2004 14:15:31 +0100, Dan McDaid wrote:
> Hi
>
> I have a pretty good grasp of linux. Been using it for a fair while.
> This morning I compiled kernel 2.6.7 and installed it. As has happened
> several times before, upon booting, my ethernet interfaces have been rebound
> to different aliases. i.e. eth2 became eth0 and eth0 became eth2. eth1
> stayed the same. To clarify - the network settings of each is ok and
> doesn't conflict with firewall rules. This isn't too big a problem since
> it's a matter of switching the cables around. However, two of the
> interfaces are 100mb and one is 10mb. I'd rather use the 10mb with my cable
> modem.

Hmmm, thought eth0 was assigned to the first nic found of the buss.
Verify pnp os is off/false/no in your pc's bios.
SWAG: Maybe using acpi=nopci in your boot loader options might help.
I would also try moving the 10meg nic to different slot

> I'm pretty sure the MAC address can be specified in either the
> /etc/sysconfig/network-scripts/ifcfg-ethX files or /etc/sysconfig/hwconf
> entries.

You can but what that does is tell the nic to fake it's mac and will not
swap the cables for you.

"Bit Twister" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...

> Hmmm, thought eth0 was assigned to the first nic found of the buss.
> Verify pnp os is off/false/no in your pc's bios.
> SWAG: Maybe using acpi=nopci in your boot loader options might help.
> I would also try moving the 10meg nic to different slot
>
> > I'm pretty sure the MAC address can be specified in either the
> > /etc/sysconfig/network-scripts/ifcfg-ethX files or /etc/sysconfig/hwconf
> > entries.
>
> You can but what that does is tell the nic to fake it's mac and will not
> swap the cables for you.
>
It has occured to me that the last time this problem happened, I was forced
into using eth2 as my external interface (in the past I'd always used eth0).
A brief glance shows that infact, the interfaces are now actually correctly
assigned. The one at the beginning of the bus is eth0 travelling through to
the third interface which is correctly eth2.

What is probable is that I missed the driver out of the kernel for the first
(10mb) card and added it later. Still, I can't explain why when the driver
eventually got added that it didn't start getting detected first.
Bonkers.

Cheers
Dan

On Tue, 29 Jun 2004 15:13:02 +0100, Dan McDaid wrote:
>
> What is probable is that I missed the driver out of the kernel for the first
> (10mb) card and added it later. Still, I can't explain why when the driver
> eventually got added that it didn't start getting detected first.

Well, now that we seem to have conflicting information, I wonder what
is is going on in your distro. Just what is your distribution,
Redhat, Mandrake, Slack,,,

I cannot see how just swapping cable makes it work since ip address is in
the ethX config file, unless you renamed the ethX files.

My written English has been poor today. I think perhaps I'm just confusing
you now.

I have RedHat Fedora. Running a shiny new 2.6.7 kernel.

From the start of the PCI bus, I have a shit ne2000 clone (RealTek of
somesort). That's 10mb. The next two are identical DLink520's via-rhine
compatibles. The idea is that the first is for the cable modem and the
other two for two internal nets. 10.0.0.0/24 and 10.0.1.0/24.

When I first set this box up, as expected the ne2000 was eth0. eth1 was
10.0.0.0/24 and eth2 10.0.1.0/24.

When I upgraded my kernel to 2.6.5 I had an issue on rebooting - I can't
remember exactly what happened, but basically eth0 was still dhcp eth1 was
still 10.0.0.0/24 and eth2 still 10.0.1.0/24. The difference however was
that eth0 was now bound to the latter DLink card and eth2 was the ne2000.
eth1 remained unchanged. This meant that the cable modem was connected now
to an internal net configuration and the second internal net connected to
the externally configured interface. The swapping of cables is a workaround
here - and is what I did to fix the situation when it happened again (the
process had reversed) today :- upgrading to 2.6.7.

I suppose if its possible to make the kernel (im not sure) assign the
ethernet controllers in reverse order then its possible that this is what
happened in my 2.6.5 upgrade. Instead of putting eth0 at the first detected
interface on the bus, it put it at the last and vice versa. With only three
interfaces this would be why eth1 remained unaffected. Is this a
possibility?

Anyway. It's all working fine, I've re-written the ifcfg-eth files to
revert to my _original_ setup whereby the ne2000 is the external interface,
and bound to eth0.
More than anything I was thinking 'out loud' when I wrote my first post.
Thanks for the replies.

Dan

"Dan McDaid" <(E-Mail Removed)> said:
>This morning I compiled kernel 2.6.7 and installed it. As has happened
>several times before, upon booting, my ethernet interfaces have been rebound
>to different aliases. i.e. eth2 became eth0 and eth0 became eth2. eth1
>stayed the same.
....
>I'm pretty sure the MAC address can be specified [...]

Apologies for being vague, but I do remember seeing a tool that allowed
you to rename interfaces, identifying them by their MAC address -- but
this is all I remember. So, by searching, you might be able to find this
tool. I remember it wasn't installed on my distribution (RH9), but could
already be part of FC.
--
Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)

In <vYdEc.1434$(E-Mail Removed)> "Dan McDaid" <(E-Mail Removed)> writes:
>This morning I compiled kernel 2.6.7 and installed it. As has happened
>several times before, upon booting, my ethernet interfaces have been rebound
>to different aliases. i.e. eth2 became eth0 and eth0 became eth2.
>

Wow, I was just going to report the same problem.

I have a single board computer in an embedded system, with three NICs.
One is a pcnet32 (comes up as eth0) and there's a daughter card with
two eepro100 NICs (come up as eth1 and eth2).

Previous versions of Redhat back to RH7.1 always had the same mapping
of eth1 and eth2. I go and update to Fedora Core2 with the 2.6.5
kernel and it swaps eth1 and eth2 on me.

The behavior is repeatable, I put the same custom mini-FC2 distro on a
different unit with identical hardware configuration and 'that' one had
eth1/eth2 flipped as well when running FC2.

Note that this unit is hard-wired and can't be simply rewired (ie, swap
the eth1/eth2 rj45 wires), there are a couple dozen of these things out
in the field worldwide, I can't have the situation where a kernel
and/or o/s update. Any ideas ?

Basically the nic with mac ending in '06' (irq-7) comes up as eth1
under FC2 with 2.6.5, yet it comes up as eth2 on all previous RH versions.

Any ideas what's going on or how to fix it ? One thing I noticed on
multiple units was that one nic is always on IRQ-14, yet on a couple
other units the second IRQ might differ (IRQ-7 or IRQ-9).

Here's the output from dmesg on FC2:

eth1: Intel Corp. 82559ER (#2), 00:20:CE:A0:22:06, IRQ 7.
Receiver lock-up bug exists -- enabling work-around.
Board assembly 689661-004, Physical connectors present: RJ45
Primary interface chip i82555 PHY #1.
General self-test: passed.
Serial sub-system self-test: passed.
Internal registers self-test: passed.
ROM checksum self-test: passed (0xdbd8681d).
Receiver lock-up workaround activated.
divert: allocating divert_blk for eth2
eth2: Intel Corp. 82559ER, 00:20:CE:A0:22:05, IRQ 14.
Receiver lock-up bug exists -- enabling work-around.
Board assembly 689661-004, Physical connectors present: RJ45
Primary interface chip i82555 PHY #1.
General self-test: passed.
Serial sub-system self-test: passed.
Internal registers self-test: passed.
ROM checksum self-test: passed (0xdbd8681d).
Receiver lock-up workaround activated.


And from lspci -vv also on FC2...

02:00.0 Ethernet controller: Intel Corp. 82559ER (rev 09)
Subsystem: Intel Corp.: Unknown device 0009
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64 (2000ns min, 14000ns max), cache line size 08
Interrupt: pin A routed to IRQ 14
Region 0: Memory at fc8fe000 (32-bit, non-prefetchable) [size=4K]
Region 1: I/O ports at de80 [size=64]
Region 2: Memory at fc8a0000 (32-bit, non-prefetchable) [size=128K]
Expansion ROM at fc600000 [disabled] [size=1M]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=2 PME-

02:01.0 Ethernet controller: Intel Corp. 82559ER (rev 09)
Subsystem: Intel Corp.: Unknown device 0009
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64 (2000ns min, 14000ns max), cache line size 08
Interrupt: pin A routed to IRQ 7
Region 0: Memory at fc8ff000 (32-bit, non-prefetchable) [size=4K]
Region 1: I/O ports at df00 [size=64]
Region 2: Memory at fc8c0000 (32-bit, non-prefetchable) [size=128K]
Expansion ROM at fc700000 [disabled] [size=1M]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=2 PME-


Any help would be appreciated....

--
----------- Vince Skahan -------------- (E-Mail Removed) -----------
The DoJ has determined that Linux has established and exploited a monopoly
in the nonproprietary UNIX market by means of predatory zero pricing and
blatantly superior implementation -- Stan Kelly-Bootle

Hey Vince,

I don't know if you saw my follow up post. It is strange that you have this
problem with the same kernel. It is probably coincidence more than
anything. Have you tried installing 2.6.7 to see if it reverts to how
things used to be?

This actually seemed to be my confusion - it would seem that 2.6.5 was the
bad boy. I cannot explain. I had thought that perhaps the kernel was
detecting the nics backwards on the pci bus, which was consistent with the
problem but seemingly not so in your case.

Let me know how you get on with this..
Dan

"Vince Skahan" <(E-Mail Removed)> wrote in message
>
> Wow, I was just going to report the same problem.
>
> I have a single board computer in an embedded system, with three NICs.
> One is a pcnet32 (comes up as eth0) and there's a daughter card with
> two eepro100 NICs (come up as eth1 and eth2).
>
> Previous versions of Redhat back to RH7.1 always had the same mapping
> of eth1 and eth2. I go and update to Fedora Core2 with the 2.6.5
> kernel and it swaps eth1 and eth2 on me.
>
> The behavior is repeatable, I put the same custom mini-FC2 distro on a
> different unit with identical hardware configuration and 'that' one had
> eth1/eth2 flipped as well when running FC2.
>
> Note that this unit is hard-wired and can't be simply rewired (ie, swap
> the eth1/eth2 rj45 wires), there are a couple dozen of these things out
> in the field worldwide, I can't have the situation where a kernel
> and/or o/s update. Any ideas ?
>
> Basically the nic with mac ending in '06' (irq-7) comes up as eth1
> under FC2 with 2.6.5, yet it comes up as eth2 on all previous RH versions.
>
> Any ideas what's going on or how to fix it ? One thing I noticed on
> multiple units was that one nic is always on IRQ-14, yet on a couple
> other units the second IRQ might differ (IRQ-7 or IRQ-9).
>
> Here's the output from dmesg on FC2:
>
> eth1: Intel Corp. 82559ER (#2), 00:20:CE:A0:22:06, IRQ 7.
> Receiver lock-up bug exists -- enabling work-around.
> Board assembly 689661-004, Physical connectors present: RJ45
> Primary interface chip i82555 PHY #1.
> General self-test: passed.
> Serial sub-system self-test: passed.
> Internal registers self-test: passed.
> ROM checksum self-test: passed (0xdbd8681d).
> Receiver lock-up workaround activated.
> divert: allocating divert_blk for eth2
> eth2: Intel Corp. 82559ER, 00:20:CE:A0:22:05, IRQ 14.
> Receiver lock-up bug exists -- enabling work-around.
> Board assembly 689661-004, Physical connectors present: RJ45
> Primary interface chip i82555 PHY #1.
> General self-test: passed.
> Serial sub-system self-test: passed.
> Internal registers self-test: passed.
> ROM checksum self-test: passed (0xdbd8681d).
> Receiver lock-up workaround activated.
>
>
> And from lspci -vv also on FC2...
>
> 02:00.0 Ethernet controller: Intel Corp. 82559ER (rev 09)
> Subsystem: Intel Corp.: Unknown device 0009
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
> Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
> Latency: 64 (2000ns min, 14000ns max), cache line size 08
> Interrupt: pin A routed to IRQ 14
> Region 0: Memory at fc8fe000 (32-bit, non-prefetchable) [size=4K]
> Region 1: I/O ports at de80 [size=64]
> Region 2: Memory at fc8a0000 (32-bit, non-prefetchable) [size=128K]
> Expansion ROM at fc600000 [disabled] [size=1M]
> Capabilities: [dc] Power Management version 2
> Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
> Status: D0 PME-Enable- DSel=0 DScale=2 PME-
>
> 02:01.0 Ethernet controller: Intel Corp. 82559ER (rev 09)
> Subsystem: Intel Corp.: Unknown device 0009
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
> Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
> Latency: 64 (2000ns min, 14000ns max), cache line size 08
> Interrupt: pin A routed to IRQ 7
> Region 0: Memory at fc8ff000 (32-bit, non-prefetchable) [size=4K]
> Region 1: I/O ports at df00 [size=64]
> Region 2: Memory at fc8c0000 (32-bit, non-prefetchable) [size=128K]
> Expansion ROM at fc700000 [disabled] [size=1M]
> Capabilities: [dc] Power Management version 2
> Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
> Status: D0 PME-Enable- DSel=0 DScale=2 PME-
>
>
> Any help would be appreciated....
>
> --
> ----------- Vince Skahan --------------
(E-Mail Removed) -----------
> The DoJ has determined that Linux has established and exploited a monopoly
> in the nonproprietary UNIX market by means of predatory zero pricing and
> blatantly superior implementation -- Stan Kelly-Bootle

In <XoOFc.22991$(E-Mail Removed) > "Dan McDaid" <(E-Mail Removed)> writes:
>I don't know if you saw my follow up post. It is strange that you have this
>problem with the same kernel. It is probably coincidence more than
>anything. Have you tried installing 2.6.7 to see if it reverts to how
>things used to be?

The latest 2.6.6 from Fedora Core2 updates does 'not' fix the problem.

>This actually seemed to be my confusion - it would seem that 2.6.5 was the
>bad boy. I cannot explain. I had thought that perhaps the kernel was
>detecting the nics backwards on the pci bus, which was consistent with the
>problem but seemingly not so in your case.

Actually I think that might be what's going on, the NIC at IRQ14 is
winning and getting eth1 when it used to get eth2, maybe a PCI bus
priority thing ?

The hacks with nameif do work, but are very undesirable for my
particular use for a number of supportability reasons.

Basically one way to force it is to rename things to get the
map I need:
- nameif eth1tmp mac_address_for_eth2
- nameif eth1 mac_address_for_eth1
- nameif eth2 mac_address_for_eth2
- then bring up the interfaces

The problem I have is that I don't know beforehand which mac address
should go to which ethNNN device, I just know that I want 2.6 to be
forced to act like 2.0 and 2.2 and 2.4 did in how it automatically
assigns device to ethNNN.

--
----------- Vince Skahan -------------- (E-Mail Removed) -----------
The DoJ has determined that Linux has established and exploited a monopoly
in the nonproprietary UNIX market by means of predatory zero pricing and
blatantly superior implementation -- Stan Kelly-Bootle