Skip to contentSkip to conversation

fix tuntap oversight

PATCH In review Jeremy Martin 3 participants 5 messages Apr 12, 2004

Subsystems (3)
Networking Network drivers TUN/TAP driver
lore
Share & tools
lore

Jeremy Martin

author
#0 lore raw

PATCH 1/1 fix tuntap oversight

Hi everyone,

This 2.6.5 patch for the universal tuntap driver allows setting the MAC address via ifconfig(8).

I'm not subscribed to netdev so if you could CC me that'd be awesome.

-Jeremy

Patch contents:

-- CUT HERE --

===== drivers/net/tun.c 1.33 vs edited =====

drivers/net/tun.c +10 -0
@@ -117,6 +117,15 @@
 	return &tun->stats;
 }
 
+static int tun_mac_addr(struct net_device *dev, void *p)
+{
+	struct sockaddr *addr=p;
+	if (netif_running(dev))
+		return -EBUSY;
+	memcpy(dev->dev_addr, addr->sa_data,dev->addr_len);
+	return 0;
+}
+
 /* Initialize net device. */
 static void tun_net_init(struct net_device *dev)
 {

@@ -138,6 +147,7 @@
 	case TUN_TAP_DEV:
 		/* Ethernet TAP Device */
 		dev->set_multicast_list = tun_net_mclist;
+		dev->set_mac_address = tun_mac_addr;
 
 		/* Generate random Ethernet address.  */
 		*(u16 *)dev->dev_addr = htons(0x00FF);
#1 lore raw

drivers/net/tun.c line 127

Quoted 8 lines · On Sun, 11 Apr 2004 23:59:47 -0700 Jeremy Martin <[email protected]> wrote:
drivers/net/tun.c +8 -0
+static int tun_mac_addr(struct net_device *dev, void *p)
+{
+	struct sockaddr *addr=p;
+	if (netif_running(dev))
+		return -EBUSY;
+	memcpy(dev->dev_addr, addr->sa_data,dev->addr_len);
+	return 0;
+}

This netif_running() check is not necessary, and in fact wrong.

In fact, if ethernet drivers erroneously do this, this causes them to fail to support the ALB bonding driver modes which require on-the-fly MAC address changes while the interface is up.

author
#2 lore raw
Quoted 9 lines · David S. Miller

This netif_running() check is not necessary, and in fact wrong.

In fact, if ethernet drivers erroneously do this, this causes them to fail to support the ALB bonding driver modes which require on-the-fly MAC address changes while the interface is up.

I just took a look in drivers/net/
and

	acenic.c
	atarilance.c
	b44.c
	cs89x0.c
	net_init.c
	typhoon.c

all use that netif_running() check when setting the MAC. I actually just pulled the function from net_init.c for the tun change. Are these broken? (I'm asking in total ignorance so be gentle :).

-Jeremy

#3 lore raw
Quoted 21 lines · Jeremy Martin
Quoted 8 lines · David S. Miller

This netif_running() check is not necessary, and in fact wrong.

In fact, if ethernet drivers erroneously do this, this causes them to fail to support the ALB bonding driver modes which require on-the-fly MAC address changes while the interface is up.

I just took a look in drivers/net/
and

	acenic.c
	atarilance.c
	b44.c
	cs89x0.c
	net_init.c
	typhoon.c
Quoted 3 lines

all use that netif_running() check when setting the MAC. I actually just pulled the function from net_init.c for the tun change. Are these broken? (I'm asking in total ignorance so be gentle :).

It's different for a driver that drives real hardware.

struct net_device::set_mac_address() is called inside rtnl_lock(). The safe thing to do is
1) read MAC address from eeprom on probe
2) write MAC address to hardware upon each dev->open()
3) use default eth_mac_addr() from net_init.c

And the netif_running() check in eth_mac_addr() is correct, because it does not update the hardware MAC address (which in this API would be impossible).

Normally the netif_running() check is for hardware that cannot update its MAC address safely during operation.

Jeff