[tulip] Problem with DFE-530TX

[Donald Becker]

On Tue, 31 Oct 2000, Olof Wolgast wrote:

> I'm writing to this list because none exists for the rhine-chipset, and 
> other DLink-cards uses the tulip chipset.

Normally I would complain, but this is detail applies to the tulip driver as
well.

> My problem:
> All modules load ok, that's fine. But my network connection is locked 
> to the MAC-address of the Ethernet card. In windows, I can specify 
> which MAC-address to use. Default is 000000000000. If I try that in 
> Linux, via the hw ether - parameter with ifconfig, the MAC-address 

I hope you don't mean that you are setting the MAC (station) address to
00:00:00:00:00:00!!

> shown with ifconfig is ok, but it doesn't work. I have heard that if 
> the MAC-address is specified with ifconfig, what is really happening is 
> that the kernel puts the interface in promiscuous mode and applys a 
> filter. Is that true?

No.  The kernel does the Right Thing.  Specifying the hardware/station/MAC
address to use results in exactly the same operation as if that value had
been read from the EEPROM.

The way the drivers work (or "should work", since I don't review all of the
ones I didn't write) is as follows (from "pci-skeleton.c")

   At driver initialization time the drivers copies the station address from
   the board's EEPROM to dev->dev_addr[].  The code looks something like
      netdev_probe1() {
        ...
	for (i = 0; i < 6; i++)
		dev->dev_addr[i] = eeprom_read(ioaddr, i);

   Each time the driver is started, dev->dev_addr[] is copied to the chip's
   station address register.
     netdev_open() {
        ...
	for (i = 0; i < 6; i++)
		writeb(dev->dev_addr[i], ioaddr + StationAddr + i);

   The default method for changing the station address is eth_mac_addr() in
     drivers/net/net_init.c
   If the interface is running, the function returns -EBUSY.  Otherwise the
   function copies the address from the parameter ("-hwaddr
   00:11:22:33:44:55") to  dev->dev_addr[].
     eth_mac_addr(struct device *dev, void *p) {
	struct sockaddr *addr=p;
	if(dev->start)
		return -EBUSY;
	memcpy(dev->dev_addr, addr->sa_data,dev->addr_len);
	return 0;
     }

A driver may optionally provide its own version of eth_mac_addr(), but there
is rarely a sane reason to do this.  Changing the station address of a
active interface is full of races, and the device driver almost always has
to do the equivalent of stopping and restarting the chip.

> And if, how do I solve my problem? The diag 
> program can't write the MAC-address.

Most of the diag programs can write the station address.  Sometime they
require a very minor source code tweak.  Please don't make those change.
If that option had been available, you would have used it and probably ended
up with two interfaces with identical station addresses.


Donald Becker				becker@scyld.com
Scyld Computing Corporation		http://www.scyld.com
410 Severn Ave. Suite 210		Second Generation Beowulf Clusters
Annapolis MD 21403			410-990-9993