Can we check slave_ops->ndo_set_mac_address?
1476 if ((slave_ops->ndo_set_mac_address) &&
(!bond->params.fail_over_mac ||
1477 BOND_MODE(bond) != BOND_MODE_ACTIVEBACKUP)) {
1478 /* Set slave to master's mac address. The
application already
1479 * set the master's mac address to that of the first slave
1480 */
1481 memcpy(addr.sa_data, bond_dev->dev_addr,
bond_dev->addr_len);
1482 addr.sa_family = slave_dev->type;
1483 res = dev_set_mac_address(slave_dev, &addr);
1484 if (res) {
1485 netdev_dbg(bond_dev, "Error %d calling
set_mac_address\n", res);
1486 goto err_restore_mtu;
1487 }
1488 }
On Tue, Aug 9, 2016 at 11:09 AM, Jörn Engel <[email protected]> wrote:
> Hello Tianhong!
>
> On Tue, Aug 09, 2016 at 10:18:41AM +0800, Ding Tianhong wrote:
>>
>> I don't understand your problem clearly, can you explain more about how the
>> 00503b6f702e break tun-interfaces
>> and we will try to fix it.
>
> Here is a trivial testcase:
> openvpn --mktun --dev tun0
> echo +tun0 > /sys/class/net/bond0/bonding/slaves
>
> Worked fine before your patch, no longer works after your patch. Works
> again after my patch.
>
>> and more, dev_set_mac_address will change the salver's mac address, some nic
>> don't support to change the mac address and
>> could not work as bond slave, so we need to check the return value, I don't
>> think this patch has any effective improvement.
>
> Using bonding in balance-rr mode, there doesn't seem to be a need to
> change the mac address. I suppose you might care in other modes, but I
> don't.
>
> Jörn
>
> --
> Time? What's that? Time is only worth what you do with it.
> -- Theo de Raadt
