Re: The bonding driver should notify userspace of MAC address change

["Nicolas de Pesloüan" <nicolas.2p.debian@gmail.com>]

Le 15/04/2011 23:45, Jay Vosburgh a écrit :
> Nicolas de Pesloüan<nicolas.2p.debian@gmail.com>  wrote:
>
>> Agreed.
>>
>>> 	Is there some race window there between the register and the
>>> netif_carrier_off?
>>
>> It might be that dhcpd does not wait for link to be up before starting to send DHCP requests.
>
> 	It looks like it's not related to carrier state at all:
>
> #212: dhcpcd requires restart to get an IP address for bonded interface
> -----------------------+-----------------
>    Reporter:  mgorny@…  |      Owner:  roy
>        Type:  defect    |     Status:  new
>    Priority:  major     |  Milestone:
>   Component:  dhcpcd    |    Version:  5.1
> Resolution:            |   Keywords:
> -----------------------+-----------------
>
> Comment (by roy):
>
>   Sorry, the above isn't too clear.
>
>   dhcpcd will read the hardware address when the interface is marked IFF_UP
>   or when given RTM_NEWLINK with ifi->ifi_change = ~0U, the latter being
>   sent by some drivers to tell userland that an interface characteristic has
>   changed - like say a hardware address - if the driver supports such a
>   change whilst still up. Normal behaviour is to mark device as DOWN before
>   changing hardware address. bonding does this whilst marked UP, hence this
>   issue.
>
>   carrier going up / down is just that, it's not a signal to re-read the
>   interface characteristics.
>
>
> 	Now this confuses me again; I thought that running the dhcp
> client (dhcpcd) over bonding has worked for years, although I've not
> personally tried it recently.  Perhaps it varies by distro.  In any
> event, this behavior of bonding (setting the bond's MAC without a
> down/up flip) has never been different in my memory.

I use dhcpcd over bonding everyday on my laptop (debian/testing), for several years.

bond0 uses eth0 and wlan0 as slaves. The time to get a DHCP reply vary, mostly because the time to 
register to the wifi AP is not perfectly stable. Sometimes (not very often), I need to ifdown/ifup 
to get a DHCP reply. This might be due to dhcpcd reading the MAC too early and getting an all zero 
MAC. I need to try and double check this, but as it happen early in the boot process and not very 
often, it will be hard to diagnose.

That being said, sending a DHCP request with an all zero source MAC sounds very strange to me.

The RFC for DHCP (RFC2131) states that a DHCP server must be prepared to broadcast the reply if the 
client hardware address is null.

    If 'giaddr' is zero and 'ciaddr' is zero, and the broadcast bit is
    set, then the server broadcasts DHCPOFFER and DHCPACK messages to
    0xffffffff. If the broadcast bit is not set and 'giaddr' is zero and
    'ciaddr' is zero, then the server unicasts DHCPOFFER and DHCPACK
    messages to the client's hardware address and 'yiaddr' address.  In
    all cases, when 'giaddr' is zero, the server broadcasts any DHCPNAK
    messages to 0xffffffff.

But a DHCP server must store a client identifier associated with a given dynamic IP address for the 
duration of the lease, to be able to give the same IP address to the same client if this client 
restarts while the lease is still valid.

If the client hardware address is all zero and the client configuration does not provide some other 
user defined identifier, then the client identifier is not unique and the DHCP server should - I 
think - ignore the request.

So, except if the local dhcpcd configuration contains an user defined identifier, I think dhcpcd 
should wait for the MAC address to be not null before sending any requests.

	Nicolas.

> 	I've not yet dug down to see if NETDEV_CHANGEADDR will result in
> an RTM_NEWLINK to user space.  At first glance it doesn't look like it.
>
> 	When bonding goes link up, however, I think linkwatch_do_dev
> will issue an RTM_NEWLINK (via a call to netdev_state_change), or,
> alternately, dev_change_flags will do it at IFF_UP time.
>
> 	-J
>
> ---
> 	-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
>