netdev - Re: on the topic of alternate MAC addresses

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: <1193218100.5715.14.camel@johannes.berg>
Date:	Wed, 24 Oct 2007 11:28:20 +0200
From:	Johannes Berg <johannes@...solutions.net>
To:	David Miller <davem@...emloft.net>
Cc:	jeff@...zik.org, netdev@...r.kernel.org
Subject: Re: on the topic of alternate MAC addresses

On Tue, 2007-10-23 at 20:22 -0700, David Miller wrote:

> However, it's not the virt clients that do this, it's the control
> node (aka: domain 0) which has to manage these things.
> 
> It has to manage all of the global hardware resources and allocate
> them out to itself and the clients anyways.
> 
> And this is why I think it's sufficient to just publish the list of
> MAC addresses from the driver, and leave the allocation and policy
> to the userland virtualizatin daemon running on the control node.

From a wireless angle, however, it's not sufficient. It appears that
there are some wireless cards that have multiple MAC addresses in their
EEPROM (or a way to generate multiple, by e.g. the vendor assigning only
even addresses and reserving odd ones). Then, bringing up a second,
third, ... virtual wireless interface should for best usability choose
an alternate address if the same one cannot be used due to restrictions.

We can probably manage this issue in userspace, in fact, for AP mode we
require proper configuration in hostapd, but it seems that some sort of
reservation system would be easier for multiple virtual station
interfaces when supported (currently no driver does).

johannes

Download attachment "signature.asc" of type "application/pgp-signature" (829 bytes)