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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140212133726.GA3027@minipsycho.orion>
Date:	Wed, 12 Feb 2014 14:37:26 +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 02:04:45PM CET, qca_dlansky@...lcomm.com wrote:
>Hi Jiri,
>
>We have couple of questions about the team driver with regards to MAC addresses assignment.
>For our testing, we have ath9k (wlan1) as the port being added into team0.
>
>Q1:
>When team device created it gets some random MAC address. When adding wlan1 into team device, team sticks to its random MAC and doesn't inherit from the added port.
>This is because inside team_dev_type_check_change():
>
>if (dev->type == port_dev->type)
>        return 0;
>
>What is the reason for this behavior? Doesn't it make sense to inherit MAC from the 1st port being added?

Well there is no reason to inherit mac from first, second, ... port
added. consider that different order of addition would end up team with
different mac every time. Administrator can easily set mac addressto
anything which he sees fit and this mac will be always used.

>
>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?

>
>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.

>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