[netdrivers] Re: Probs with changing the MAC address

[Andy Reischle]

Thorsten,
I can confirm the problem as described:

In a Linix-HA environment (using the heartbeat package), I need to move
several interfaces including their MAC addresses from one machine to the
other. This works for the Intel NICs but not for the D-Link DFE-530TX
4-Port (Sundance).

I basically follow the same procedure:

> ip link set eth1 down
> ip link set eth1 address de:ad:be:ef:00:01
> ip link set eth1 down   <- up, you mean :-)
(I'll assign the IP address after then)

an "ip link show" shows that the mac is set correctly.
But Donald's mii-diag reports the original hardware address.
(Don't know if this is relevant)

>After I assign an IP address, the interface is not
>responding anymore. The NIC responds The funny thing
>about this is, that when the interface is set
>into promiscous mode by etherreal for example a
>"ping" works alright.

In fact the interface *does* respond under two conditions:
1) It receives a broadcast (mac ff:ff:ff:ff:ff:ff)
2) It is in promisc mode

It is normal behaviour to accept broadcast packets regardless
of the own mac address. Therefore the ARP-Request is answered
using the MAC address entered manually.
*BUT* when a (eg. IP-) packet is sent to that MAC address then, it
is ignored by either the NIC hardware or the driver, so the kernel
never sees it. Unless the interface is in promisc mode. Then, of
course all packets are processed. - That's how I understand the process.

The problem doesn't seem to be uncommon:
http://www.uwsg.iu.edu/hypermail/linux/net/0101.0/0005.html
(I think Donald Becker misunderstood the question here)
And some guys at an university who run a beowulf cluster
http://ilab.usc.edu/beo/
They describe the more or less same problem although with different
NIC hardware.

>Of cause a hint on a solution to that problem, would
>make my day a lot more uncomplicated either...

Hmmm... the only thing I can think of is to leave the interfaces
in promisc mode. But there must be an other way to do it with style.

To me the question remains: Which bit is it that drops the data? Is it the
actual card hardware (and if so, can that behaviour be changed by
setting it up properly)?
Or is it a problem of the driver module and can be fixed?

Regards,

Andy

-- 
Beam me up Scotty