kern/110284: [PATCH] Invalid Assumption in SIOCSIFADDR in ether_ioctl()

Devon H. O'Dell devon.odell at
Tue Mar 13 20:40:06 UTC 2007

>Number:         110284
>Category:       kern
>Synopsis:       [PATCH] Invalid Assumption in SIOCSIFADDR in ether_ioctl()
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Mar 13 20:40:05 GMT 2007
>Originator:     Devon H. O'Dell
>Release:        6.2-STABLE
Coyote Point Systems, Inc.
FreeBSD 6.2-STABLE FreeBSD 6.2-STABLE #3: Fri Feb 23 16:45:30 EST 2007     dho at  i386
Many NICs simply offload ioctls for SIOCSIFADDR to ether_ioctl(). When in
ether_ioctl(), we call the interface's if_init() routine. This is good 
when the interface is down and we haven't assigned an IP address yet. 
However, this routine is also called when aliases are added to the 

Calling if_init() at this point is undesirable because the chip is 
lready running and doesn't need to be initialized again. Additionally, 
for some chips (em(4) and vr(4) in my observations) the number of chip 
resets and the time required to autonegotiate is significant enough to 
cause the NIC to go OTL for a significant period of time (>15 seconds).

The attached patch only calls if_init() if the driver's if_flags field 
*DOES NOT* have the IFF_RUNNING bit set.

The gratuitous ARP (which is sent, if I understand correctly, because of
the succeeding arp_ifinit() call) should still be sent in either case.
I'm not sure whether this is visible on all em(4) or vr(4) chips. To
visualize the problem, open two terminal sessions. In one, ping a machine
on the same network. On another, add an interface alias. Some number of
packets should never reach their destination.
A patch is available at

I would have attached it, but the form doesn't like the Content-type
of my if_ethersubr.patch :(

More information about the freebsd-bugs mailing list