[Xorp-hackers] Patch for a netlink problem: Can't set MAC address

[Pavlin Radoslavov]

> In fea/ifconfig_set_netlink.cc , there is code that attempts to
> set interface MAC addresses.  This code fails to work correctly
> because the netlink payload that it sends is a simple MAC address.
> The kernel code is looking for a struct sockaddr.

Thank you for the fix. Now it is applied to CVS:

Revision  Changes                               Path
1.28      +35 -4;  commitid: 3cdc44d7ee127ea6; xorp/fea/ifconfig_set_netlink.cc

> One odd-ball thing is that the payload length (rta_len) must be
> truncated.  It must be set to the sizeof
> sa_family+mac_address_length rather than the larger, and more
> correct, sizeof sockaddr

Setting the payload length to sa_family+mac_address_length is
probably intentiional, because this mechanism is suppose to work
with large hardware addresses as indicated in the following email:

http://marc2.theaimsgroup.com/?l=linux-kernel&m=104137641925584&w=2
For the record, the patch in that email is an earlier version of
what actually was added to the kernel:
http://www.ussg.iu.edu/hypermail/linux/kernel/0301.1/2436.html

However, what I found really odd is the fact that the payload is
suppose to be a MAC address contained inside "struct sockaddr", but
rta_len only is suppose to be ETH_ALEN, when the correct value
should be sizeof(sa_family) + mac_address_length.
I believe this is a bug in the Linux kernel API (at least version
2.6.17).

The particular problematic code in the kernel is inside
net/core/rtnetlink.c, do_setlink():
    ...
    if (ida[IFLA_ADDRESS - 1]) {
        ...
        if (ida[IFLA_ADDRESS - 1]->rta_len != RTA_LENGTH(dev->addr_len))
            goto out;
            err = dev->set_mac_address(dev, RTA_DATA(ida[IFLA_ADDRESS - 1]));
            ...

        [ Where dev->set_mac_address() expects to see a second argument of
          type "struct sockaddr". ]

I am going to send an email to the author of that patch about the
issue.

Thanks,
Pavlin

P.S. I have added this information to the code itself (in case the
API is fixed in the future and we need to fix the XORP code itself).

P.P.S. Just curious: how did you find the right solution.
I didn't find any online documentation or any sample code while
studying your patch, so I had to read the kernel source code to
confirm those odd values :)