duplicate MAC addresses

duplicate MAC addresses

[marty]

[-- Attachment #1: Type: text/plain, Size: 2110 bytes --]

I got trouble...
(duplicate MAC addresses)

I have a Jetway atom-330 mini-itx board with a builtin NIC and 3-NIC
daughtercard. All 4 NICS are realtek 8169. The software is recent.
The machine works impressively except for described following issues:

The builtin NIC always comes in as eth0 on boot.
The remaining daughtercard NICS have MACS from a different sequence.
On boot all 4 NICS are seen as unique by the kernel and assigned unique
interrupts, (which is very nice).

Enter udev...

On boot udev stalls for 120+ seconds while it executes
i801_smbus functions. This may be a unsupported hardware issue
or other software issue but it is not normal. This may be the problem.

After udev finishes the "70-persistent-net.rules" are borked and eth3 is
assigned the MAC of eth0, causing a duplicate MAC.
On the next boot udev sees the duplicate and renames eth3 to eth3_rename
and the network scripts won't enable it. It becomes useless.

"ip link show" always lists eth3/eth3_rename with the MAC of eth0 as below. Why?

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
UNKNOWN qlen 1000
    link/ether 00:30:18:ab:4a:8f brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
UNKNOWN qlen 1000
    link/ether 00:30:18:ab:6a:46 brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
UNKNOWN qlen 1000
    link/ether 00:30:18:ab:6a:47 brd ff:ff:ff:ff:ff:ff
5: eth3_rename: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 00:30:18:ab:4a:8f brd ff:ff:ff:ff:ff:ff

What I really don't know is:
After the kernel probes the hardware and acquires the MACs, where
does it keep that info?
Why doesn't udev use that correct probed kernel info for eth3, rather than
configure eth3 with the MAC of eth0? Why probe the hardware trice?
Where is this going wrong? I suspect i801_smbus...

Marty B.
-- 
An artist who is forced to work a specific schedule, is no longer
an artist; he is just hired help. Inspiration cannot be purchased.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: duplicate MAC addresses

[Greg KH]

On Tue, Aug 18, 2009 at 04:27:04PM -0400, marty wrote:
> I got trouble...
> (duplicate MAC addresses)

That's a bug in your hardware, have you asked your manufacturer to
resolve this for you?  That violates the ethernet spec...

thanks,

greg k-h

Re: duplicate MAC addresses

[Matthew Dharm]

[-- Attachment #1: Type: text/plain, Size: 497 bytes --]

On Tue, Aug 18, 2009 at 04:27:04PM -0400, marty wrote:
> I got trouble...
> (duplicate MAC addresses)

Do an 'ifconfig -a' and see if the ports are actually reporting the same
MAC on multiple interfaces, or if this is a software bug...

Matt


-- 
Matthew Dharm                              Home: mdharm-usb@one-eyed-alien.net 
Maintainer, Linux USB Mass Storage Driver

Hey, has anyone seen the Microsoft sales guy? It's his feeding time...
					-- Mike
User Friendly, 4/17/1998

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

duplicate MAC addresses

[marty]

[-- Attachment #1: Type: text/plain, Size: 3094 bytes --]

Greg KH wrote:
> > On Tue, Aug 18, 2009 at 04:27:04PM -0400, marty wrote:
>> >> I got trouble...
>> >> (duplicate MAC addresses)
> >
> > That's a bug in your hardware, have you asked your manufacturer to
> > resolve this for you?  That violates the ethernet spec...
> >
> > thanks,
> >
> > greg k-h
> > '

Thanks for responding Greg,
Indeed the MACs should be unique, and they ARE according to kernel.
As I was only guessing can you please be a bit more specific as to
'where' you believe that problem lies?
Then I can contact manufacturer with good information.
Thanks so much,

PS:
Thanks,thanks,thanks,thanks... for the work you have done with linux.

Marty B.

PPS: for Matt Dharm
Your email fragged my ancient email client and I had to do more work. Gaaa...
What's with that I wonder?  I have enough problems right now.
plaintext only, thanks...

> I got trouble...
> (duplicate MAC addresses)
> 
> I have a Jetway atom-330 mini-itx board with a builtin NIC and 3-NIC
> daughtercard. All 4 NICS are realtek 8169. The software is recent.
> The machine works impressively except for described following issues:
> 
> The builtin NIC always comes in as eth0 on boot.
> The remaining daughtercard NICS have MACS from a different sequence.
> On boot all 4 NICS are seen as unique by the kernel and assigned unique
> interrupts, (which is very nice).
> 
> Enter udev...
> 
> On boot udev stalls for 120+ seconds while it executes
> i801_smbus functions. This may be a unsupported hardware issue
> or other software issue but it is not normal. This may be the problem.
> 
> After udev finishes the "70-persistent-net.rules" are borked and eth3 is
> assigned the MAC of eth0, causing a duplicate MAC.
> On the next boot udev sees the duplicate and renames eth3 to eth3_rename
> and the network scripts won't enable it. It becomes useless.
> 
> "ip link show" always lists eth3/eth3_rename with the MAC of eth0 as below. Why?
> 
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
> UNKNOWN qlen 1000
>     link/ether 00:30:18:ab:4a:8f brd ff:ff:ff:ff:ff:ff
> 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
> UNKNOWN qlen 1000
>     link/ether 00:30:18:ab:6a:46 brd ff:ff:ff:ff:ff:ff
> 4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
> UNKNOWN qlen 1000
>     link/ether 00:30:18:ab:6a:47 brd ff:ff:ff:ff:ff:ff
> 5: eth3_rename: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
>     link/ether 00:30:18:ab:4a:8f brd ff:ff:ff:ff:ff:ff
> 
> What I really don't know is:
> After the kernel probes the hardware and acquires the MACs, where
> does it keep that info?
> Why doesn't udev use that correct probed kernel info for eth3, rather than
> configure eth3 with the MAC of eth0? Why probe the hardware trice?
> Where is this going wrong? I suspect i801_smbus...
> 
> Marty B.




-- 
An artist who is forced to work a specific schedule, is no longer
an artist; he is just hired help. Inspiration cannot be purchased.




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: duplicate MAC addresses

[Alan Jenkins]

On 8/18/09, marty <marty@goodoldmarty.com> wrote:
> I got trouble...
> (duplicate MAC addresses)
>
> I have a Jetway atom-330 mini-itx board with a builtin NIC and 3-NIC
> daughtercard. All 4 NICS are realtek 8169. The software is recent.
> The machine works impressively except for described following issues:
>
> The builtin NIC always comes in as eth0 on boot.
> The remaining daughtercard NICS have MACS from a different sequence.
> On boot all 4 NICS are seen as unique by the kernel and assigned unique
> interrupts, (which is very nice).
>
> Enter udev...
>
> On boot udev stalls for 120+ seconds while it executes
> i801_smbus functions. This may be a unsupported hardware issue
> or other software issue but it is not normal. This may be the problem.
>
> After udev finishes the "70-persistent-net.rules" are borked and eth3 is
> assigned the MAC of eth0, causing a duplicate MAC.
> On the next boot udev sees the duplicate and renames eth3 to eth3_rename
> and the network scripts won't enable it. It becomes useless.
>
> "ip link show" always lists eth3/eth3_rename with the MAC of eth0 as below.
> Why?
>
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
> UNKNOWN qlen 1000
>     link/ether 00:30:18:ab:4a:8f brd ff:ff:ff:ff:ff:ff
> 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
> UNKNOWN qlen 1000
>     link/ether 00:30:18:ab:6a:46 brd ff:ff:ff:ff:ff:ff
> 4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
> UNKNOWN qlen 1000
>     link/ether 00:30:18:ab:6a:47 brd ff:ff:ff:ff:ff:ff
> 5: eth3_rename: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen
> 1000
>     link/ether 00:30:18:ab:4a:8f brd ff:ff:ff:ff:ff:ff
>
> What I really don't know is:
> After the kernel probes the hardware and acquires the MACs, where
> does it keep that info?
> Why doesn't udev use that correct probed kernel info for eth3, rather than
> configure eth3 with the MAC of eth0? Why probe the hardware trice?
> Where is this going wrong? I suspect i801_smbus...
>

The long boot delay with i801_smbus sounds like a bug I've seen
elsewhere.  It's not necessarily related to your MAC woes, but it is
the sort of thing that could cause weird "undefined behaviour":

<http://bugzilla.kernel.org/show_bug.cgi?id\x13620> /
<http://bugzilla.kernel.org/show_bug.cgi?id\x12376>

Have you tried not loading the driver?  E.g.

echo "blacklist i2c_i801" >> /etc/modprobe.d/blacklist.conf

which should prevent it from being loaded by udev.

If the kernel version is < 2.6.30 then booting with
"acpi_enforce_resource=strict" will hopefully have the same effect as
the blacklist.  2.6.30 made this option the default, but then broke
the feature; I think it will be fixed in 2.6.32.

Regards
Alan

Re: duplicate MAC addresses

[Rui Santos]

marty wrote:
> I got trouble...
> (duplicate MAC addresses)
>
> I have a Jetway atom-330 mini-itx board with a builtin NIC and 3-NIC
> daughtercard. All 4 NICS are realtek 8169. The software is recent.
> The machine works impressively except for described following issues:
>
> The builtin NIC always comes in as eth0 on boot.
> The remaining daughtercard NICS have MACS from a different sequence.
> On boot all 4 NICS are seen as unique by the kernel and assigned unique
> interrupts, (which is very nice).
>
> Enter udev...
>
> On boot udev stalls for 120+ seconds while it executes
> i801_smbus functions. This may be a unsupported hardware issue
> or other software issue but it is not normal. This may be the problem.
>
> After udev finishes the "70-persistent-net.rules" are borked and eth3 is
> assigned the MAC of eth0, causing a duplicate MAC.
> On the next boot udev sees the duplicate and renames eth3 to eth3_rename
> and the network scripts won't enable it. It becomes useless.
>
> "ip link show" always lists eth3/eth3_rename with the MAC of eth0 as below. Why?
>
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
> UNKNOWN qlen 1000
>     link/ether 00:30:18:ab:4a:8f brd ff:ff:ff:ff:ff:ff
> 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
> UNKNOWN qlen 1000
>     link/ether 00:30:18:ab:6a:46 brd ff:ff:ff:ff:ff:ff
> 4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
> UNKNOWN qlen 1000
>     link/ether 00:30:18:ab:6a:47 brd ff:ff:ff:ff:ff:ff
> 5: eth3_rename: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
>     link/ether 00:30:18:ab:4a:8f brd ff:ff:ff:ff:ff:ff
>
> What I really don't know is:
> After the kernel probes the hardware and acquires the MACs, where
> does it keep that info?
> Why doesn't udev use that correct probed kernel info for eth3, rather than
> configure eth3 with the MAC of eth0? Why probe the hardware trice?
> Where is this going wrong? I suspect i801_smbus...
>   
Hi Marty,

    I assume you have a Jetway NC92-330-LF motherboard and a Jetway
AD3RTLAN-G Daughterboard.
    If so, I also have that same hardware running and I'm experiencing
none of the issues you describe.

    I'm using a semi-stantard openSUSE 11.1 ditribution. The only change
I've made is that I'm using a 2.6.30.x kotd kernel.

    If you require any information for debugging issue, please ask.

> Marty B.
>   
Rui Santos
http://www.ruisantos.com/

Veni, vidi, Linux!

duplicate MAC addresses

[marty]

[-- Attachment #1: Type: text/plain, Size: 1127 bytes --]

Greg KH wrote:
> > On Tue, Aug 18, 2009 at 04:27:04PM -0400, marty wrote:
>> >> I got trouble...
>> >> (duplicate MAC addresses)
> >
> > That's a bug in your hardware, have you asked your manufacturer to
> > resolve this for you?  That violates the ethernet spec...

Aha!
if I delete the /etc/udev/rules.d/70-persistent-net.rules the
system boots fast but the new rules are borked.
On next boot udev stalls a long time, and renames the duplicate interface.
I removed i2c_smbus module that I didn't need. Not related to issue.

The debug messages indicate some type of hardware issue on south side is
possible. I will try to fix it. I ordered a new daughter board to test this.
If no good I will replace all the hardware without crying. My software will
run on anything, thanks to you guys...

If I can resolve this issue I will document it and forward the results to the
list. (I am not on that list so I can't read anything not sent to me.)

Marty B.

-- 
An artist who is forced to work a specific schedule, is no longer
an artist; he is just hired help. Inspiration cannot be purchased.






[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

duplicate MAC addresses

[marty]

[-- Attachment #1: Type: text/plain, Size: 897 bytes --]

Greg KH wrote:
> > On Tue, Aug 18, 2009 at 04:27:04PM -0400, marty wrote:
>> >> I got trouble...
>> >> (duplicate MAC addresses)
> >
> > That's a bug in your hardware, have you asked your manufacturer to
> > resolve this for you?  That violates the ethernet spec...

I have resolved that problem as of today. I found this was caused
by the software I had been using. If a hardware issue remains, it is moot.

The bonding driver/utilities normally sets the bond address to the MAC of the
first NIC. But it also set the MAC of the slave (eth3) to the MAC of the first
NIC. This persists through reboots so that is how my MACs got duplicated.

Resetting the MAC corrected those problems and everything works fine now.

Marty B.
-- 
An artist who is forced to work a specific schedule, is no longer
an artist; he is just hired help. Inspiration cannot be purchased.








[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: duplicate MAC addresses

[John Stoffel]

>>>>> "marty" = marty  <marty@goodoldmarty.com> writes:

marty> Greg KH wrote:
>> > On Tue, Aug 18, 2009 at 04:27:04PM -0400, marty wrote:
>>> >> I got trouble...
>>> >> (duplicate MAC addresses)
>> >
>> > That's a bug in your hardware, have you asked your manufacturer to
>> > resolve this for you?  That violates the ethernet spec...

marty> I have resolved that problem as of today. I found this was
marty> caused by the software I had been using. If a hardware issue
marty> remains, it is moot.

marty> The bonding driver/utilities normally sets the bond address to
marty> the MAC of the first NIC. But it also set the MAC of the slave
marty> (eth3) to the MAC of the first NIC. This persists through
marty> reboots so that is how my MACs got duplicated.

marty> Resetting the MAC corrected those problems and everything works
marty> fine now.

Doesn't this point to a udev rules problem?  What should happen if
there are conflicting devices which both satisfy a condition, but
where only one device is allowed to match?

Now I realize that with MAC addresses you're actually allowed to have
multiple NICs on a host all with the SAME Mac addr, but only if
they're on different segments.  Older Sun boxes all used to have a
single MAC address across all ports.  This usually isn't a problem
since the ethernet spec says that MAC addresses are local to the
segment, and with switches and bridges, the segment is is limited.

Fails when you have bonding drivers and other HA tricks which I'm not
up on though.  

John

Re: duplicate MAC addresses

[marty]

[-- Attachment #1: Type: text/plain, Size: 2972 bytes --]

John Stoffel wrote:
>>>>>> "marty" == marty  <marty@goodoldmarty.com> writes:
> 
> marty> Greg KH wrote:
>>>> On Tue, Aug 18, 2009 at 04:27:04PM -0400, marty wrote:
>>>>>> I got trouble...
>>>>>> (duplicate MAC addresses)
>>>> That's a bug in your hardware, have you asked your manufacturer to
>>>> resolve this for you?  That violates the ethernet spec...
> 
> marty> I have resolved that problem as of today. I found this was
> marty> caused by the software I had been using. If a hardware issue
> marty> remains, it is moot.
> 
> marty> The bonding driver/utilities normally sets the bond address to
> marty> the MAC of the first NIC. But it also set the MAC of the slave
> marty> (eth3) to the MAC of the first NIC. This persists through
> marty> reboots so that is how my MACs got duplicated.
> 
> marty> Resetting the MAC corrected those problems and everything works
> marty> fine now.
> 
> Doesn't this point to a udev rules problem?  What should happen if
> there are conflicting devices which both satisfy a condition, but
> where only one device is allowed to match?
> 
> Now I realize that with MAC addresses you're actually allowed to have
> multiple NICs on a host all with the SAME Mac addr, but only if
> they're on different segments.  Older Sun boxes all used to have a
> single MAC address across all ports.  This usually isn't a problem
> since the ethernet spec says that MAC addresses are local to the
> segment, and with switches and bridges, the segment is is limited.
> 
> Fails when you have bonding drivers and other HA tricks which I'm not
> up on though.  
> 
> John
> 
> 
> 

OOPS... Duplicate MACS won't work on a single box. On a network, yes.
Duplicate MACS mess everything up, because the lower networking layers do not
use IP addresses. They depend on the MAC to route the traffic.

I thought this was a udev problem. Greg KH suggested a hardware problem, but
I fixed it by removing the bonding driver from my config. Took a lot of debug.
I am using shorewall to configure iptables, which has another means to handle
multiple ISP's using packet marking. Works and as far as I can see no issues.

I was able to make the bonding driver work, but only if I manually corrected the
borked MAC beforehand. My changes didn't survive reboot. Something is broken in
that driver. I haven't looked as yet but I'm sure someone will discover it.

There was a issue with udev, however not a rule; the LFS bootscripts I use
were guilty. --retry-failed is in invalid option on udev-1.46. Caused a big
delay for some reason. I commented it out and it boots fast now.

BTW, this is a handy thing we can do on linux.
ip link set eth0 address 01:02:03:04:05:06
That will set a MAC address and survives reboot (on my system anyway).

Marty B.



-- 
An artist who is forced to work a specific schedule, is no longer
an artist; he is just hired help. Inspiration cannot be purchased.




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: duplicate MAC addresses

[Alan Jenkins]

On 8/24/09, marty <marty@goodoldmarty.com> wrote:
> John Stoffel wrote:
>>>>>>> "marty" = marty  <marty@goodoldmarty.com> writes:
>>
>> marty> Greg KH wrote:
>>>>> On Tue, Aug 18, 2009 at 04:27:04PM -0400, marty wrote:
>>>>>>> I got trouble...
>>>>>>> (duplicate MAC addresses)
>>>>> That's a bug in your hardware, have you asked your manufacturer to
>>>>> resolve this for you?  That violates the ethernet spec...
>>
>> marty> I have resolved that problem as of today. I found this was
>> marty> caused by the software I had been using. If a hardware issue
>> marty> remains, it is moot.
>>
>> marty> The bonding driver/utilities normally sets the bond address to
>> marty> the MAC of the first NIC. But it also set the MAC of the slave
>> marty> (eth3) to the MAC of the first NIC. This persists through
>> marty> reboots so that is how my MACs got duplicated.
>>
>> marty> Resetting the MAC corrected those problems and everything works
>> marty> fine now.
>>
>> Doesn't this point to a udev rules problem?  What should happen if
>> there are conflicting devices which both satisfy a condition, but
>> where only one device is allowed to match?
>>
>> Now I realize that with MAC addresses you're actually allowed to have
>> multiple NICs on a host all with the SAME Mac addr, but only if
>> they're on different segments.  Older Sun boxes all used to have a
>> single MAC address across all ports.  This usually isn't a problem
>> since the ethernet spec says that MAC addresses are local to the
>> segment, and with switches and bridges, the segment is is limited.
>>
>> Fails when you have bonding drivers and other HA tricks which I'm not
>> up on though.
>>
>> John
>>
>>
>>
>
> OOPS... Duplicate MACS won't work on a single box. On a network, yes.
> Duplicate MACS mess everything up, because the lower networking layers do
> not
> use IP addresses. They depend on the MAC to route the traffic.
>
> I thought this was a udev problem. Greg KH suggested a hardware problem, but
> I fixed it by removing the bonding driver from my config. Took a lot of
> debug.
> I am using shorewall to configure iptables, which has another means to
> handle
> multiple ISP's using packet marking. Works and as far as I can see no
> issues.
>
> I was able to make the bonding driver work, but only if I manually corrected
> the
> borked MAC beforehand. My changes didn't survive reboot. Something is broken
> in
> that driver. I haven't looked as yet but I'm sure someone will discover it.
>
> There was a issue with udev, however not a rule; the LFS bootscripts I use
> were guilty. --retry-failed is in invalid option on udev-1.46. Caused a big
> delay for some reason. I commented it out and it boots fast now.
>
> BTW, this is a handy thing we can do on linux.
> ip link set eth0 address 01:02:03:04:05:06
> That will set a MAC address and survives reboot (on my system anyway).

That's a bug, and it's what causes you grief when you reboot with a
bonding configuration.  I'm pretty sure it's fixable.

Your DNS was down or something when I elaborated on this earlier
<http://thread.gmane.org/gmane.linux.hotplug.devel/14491>.  You
wouldn't know from these crippled web interfaces, but I addressed the
message to the r8169 maintainer.  No reply yet though.

Regards
Alan

Re: duplicate MAC addresses

[Alan Jenkins]

On 8/25/09, Alan Jenkins <sourcejedi.lkml@googlemail.com> wrote:
> On 8/24/09, marty <marty@goodoldmarty.com> wrote:
>> John Stoffel wrote:
>>>>>>>> "marty" = marty  <marty@goodoldmarty.com> writes:
>>>
>>> marty> Greg KH wrote:
>>>>>> On Tue, Aug 18, 2009 at 04:27:04PM -0400, marty wrote:
>>>>>>>> I got trouble...
>>>>>>>> (duplicate MAC addresses)
>>>>>> That's a bug in your hardware, have you asked your manufacturer to
>>>>>> resolve this for you?  That violates the ethernet spec...
>>>
>>> marty> I have resolved that problem as of today. I found this was
>>> marty> caused by the software I had been using. If a hardware issue
>>> marty> remains, it is moot.
>>>
>>> marty> The bonding driver/utilities normally sets the bond address to
>>> marty> the MAC of the first NIC. But it also set the MAC of the slave
>>> marty> (eth3) to the MAC of the first NIC. This persists through
>>> marty> reboots so that is how my MACs got duplicated.
>>>
>>> marty> Resetting the MAC corrected those problems and everything works
>>> marty> fine now.
>>>
>>> Doesn't this point to a udev rules problem?  What should happen if
>>> there are conflicting devices which both satisfy a condition, but
>>> where only one device is allowed to match?
>>>
>>> Now I realize that with MAC addresses you're actually allowed to have
>>> multiple NICs on a host all with the SAME Mac addr, but only if
>>> they're on different segments.  Older Sun boxes all used to have a
>>> single MAC address across all ports.  This usually isn't a problem
>>> since the ethernet spec says that MAC addresses are local to the
>>> segment, and with switches and bridges, the segment is is limited.
>>>
>>> Fails when you have bonding drivers and other HA tricks which I'm not
>>> up on though.
>>>
>>> John
>>>
>>>
>>>
>>
>> OOPS... Duplicate MACS won't work on a single box. On a network, yes.
>> Duplicate MACS mess everything up, because the lower networking layers do
>> not
>> use IP addresses. They depend on the MAC to route the traffic.
>>
>> I thought this was a udev problem. Greg KH suggested a hardware problem,
>> but
>> I fixed it by removing the bonding driver from my config. Took a lot of
>> debug.
>> I am using shorewall to configure iptables, which has another means to
>> handle
>> multiple ISP's using packet marking. Works and as far as I can see no
>> issues.
>>
>> I was able to make the bonding driver work, but only if I manually
>> corrected
>> the
>> borked MAC beforehand. My changes didn't survive reboot. Something is
>> broken
>> in
>> that driver. I haven't looked as yet but I'm sure someone will discover
>> it.
>>
>> There was a issue with udev, however not a rule; the LFS bootscripts I
>> use
>> were guilty. --retry-failed is in invalid option on udev-1.46. Caused a
>> big
>> delay for some reason. I commented it out and it boots fast now.
>>
>> BTW, this is a handy thing we can do on linux.
>> ip link set eth0 address 01:02:03:04:05:06
>> That will set a MAC address and survives reboot (on my system anyway).
>
> That's a bug, and it's what causes you grief when you reboot with a
> bonding configuration.  I'm pretty sure it's fixable.

To be more specific, it's fine to set the MAC address; the bug is that
the change survives a reboot.

> Your DNS was down or something when I elaborated on this earlier
> <http://thread.gmane.org/gmane.linux.hotplug.devel/14491>.  You
> wouldn't know from these crippled web interfaces, but I addressed the
> message to the r8169 maintainer.  No reply yet though.
>
> Regards
> Alan
>