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  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 11 Aug 2014 16:56:55 -0700
From:	Marcel Holtmann <marcel@...tmann.org>
To:	Daniel Gimpelevich <daniel@...pelevich.san-francisco.ca.us>
Cc:	"John W. Linville" <linville@...driver.com>,
	"linux-wireless@...r.kernel.org Wireless" 
	<linux-wireless@...r.kernel.org>,
	Johannes Berg <johannes@...solutions.net>,
	"David S. Miller" <davem@...emloft.net>,
	Network Development <netdev@...r.kernel.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] allow setting wiphy.perm_addr after driver probe

Hi Daniel,

>> Internally it might do that, but I do not see it exposing the
>> NL80211_ATTR_MAC when you get the attributes for wiphy.
> 
> When wlan0 is created, it can be created with its own MAC irrespective
> of the wiphy MAC. In OpenWrt, the wlan0 MAC can be supplied and assigned
> to a netdev created on a specific wiphy identified by its MAC, and if
> that cannot be predicted, there is no wlan0.

the way I read the nl80211 code is that the NL80211_CMD_NEW_INTERFACE requires a wiphy device to be specified. And that is actually just a number. So I have no idea what the MAC has to here.

>> So I am still saying that when you do NL80211_CMD_NEW_INTERFACE allow
>> providing NL80211_ATTR_MAC to set the MAC address to be used. It might
>> be useful that the wiphy exposes an attribute saying that it does not
>> have a default MAC address, but that should be it. I do not like these
>> magic 00:00:00:00:00:00 games. As I mentioned earlier, in Bluetooth we
>> just deal with allowing the driver to set a flag that it does not have
>> a valid address. And then the core takes care of dealing with it.
>> 
> An attribute saying there is no default MAC is helpful only if there is
> a way to supply a new default to the wiphy.

Why does the wiphy need to know the MAC if it is always specified from userspace when actually creating the new netdev interface. Works for P2P devices, so why wouldn't it work for access point and station mode?

Regards

Marcel



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists