netdev - Re: team driver MAC addresses questions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 12 Feb 2014 17:16:27 +0100
From:	Jiri Pirko <jiri@...nulli.us>
To:	qca_dlansky <qca_dlansky@...lcomm.com>
Cc:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	qca_vkondrat <qca_vkondrat@....qualcomm.com>
Subject: Re: team driver MAC addresses questions

Wed, Feb 12, 2014 at 03:17:10PM CET, qca_dlansky@...lcomm.com wrote:
>>Q2:
>>We've noticed the following behavior:
>>- wlan1 has some MAC address - m1
>>- team0 created with random MAC address - m2
>>
>>root@...foo:~# ip link
>>1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT 
>>    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>>2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000
>>    link/ether 00:21:70:be:4f:68 brd ff:ff:ff:ff:ff:ff
>>4: wlan1: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN mode DORMANT qlen 1000
>>    link/ether 44:39:c4:18:b5:7a brd ff:ff:ff:ff:ff:ff
>>12: team0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT 
>>    link/ether 9a:ac:d5:91:df:aa brd ff:ff:ff:ff:ff:ff
>>
>>- When adding port wlan1 into team0, m1 gets assigned to team0 and m2 
>>gets assigned to wlan1
>>
>>root@...foo:~# LD_LIBRARY_PATH=/usr/local/lib/ teamdctl team0 port add 
>>wlan1 root@...foo:~# ip link
>>1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT 
>>    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>>2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000
>>    link/ether 00:21:70:be:4f:68 brd ff:ff:ff:ff:ff:ff
>>4: wlan1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master team0 state UP mode DORMANT qlen 1000
>>    link/ether 9a:ac:d5:91:df:aa brd ff:ff:ff:ff:ff:ff
>>12: team0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT 
>>    link/ether 44:39:c4:18:b5:7a brd ff:ff:ff:ff:ff:ff
>>
>>This is a bit strange for us. We were expecting both of them to have the same MAC address.
>>
>>Further investigation showed that when adding the port, the MAC address of the added port is set twice:
>>once by team_add_slave(), when wlan1 is still down. The MAC address is set to m2.
>>second time by team_set_mac_address(), after wlan1 is up. The MAC address is set to m1.
>
>Are you using teamd? What config?
>
>[DL]  just 'teamd -d', no config at all


Ok. So here's what is going on:

During the port enslave when the port device is down, team driver
changes hwaddr of the port to team one (round robin mode does that).

After that, teamd detects that port was added and sets team hwaddr
according to the first enslaved port. That will lead to change of hwaddr
of port again, now it is upped.

The reason for this behaviour is that userspace controls hwaddr
assignement.

So for you case the workaround is to specify hwaddr in teamd config.
After that, teamd will not set hwaddr according to first enslaved port.

>
>>
>>However, the 2nd call fails which leaves wlan1 with m2. The reason for the failure is because ath9k doesn't support IFF_LIVE_ADDR_CHANGE.
>>
>>Our question: in team_set_mac_address(), in case there is a failure setting MAC address for any port inside port_list, doesn't it make sense to undo MAC address changes and report the failure up the stack?
>>
>
>Yes. That would be probably the proper thing to do. WOuld you send the patch or I should do it? Would be needed to do something similar what bonding does.
>
>[DL] Let us think about it. We want to prepare patch, but we need time to do so.
>

Feel free to send me draft, questions, anything you need.

Jiri

>>Thanks,
>>  Vladimir & Dedy.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html