netdev - Re: [RFC] Do not activate promiscuous mode on wlan interfaces for bridging.

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

Date:	Thu, 12 Jun 2008 11:10:50 -0700
From:	Luis Carlos Cobo <luisca@...ybit.com>
To:	Jouni Malinen <j@...fi>
Cc:	linux-wireless@...r.kernel.org, shemminger@...ux-foundation.org,
	johannes@...solutions.net, bridge@...ux-foundation.org,
	Linux Netdev List <netdev@...r.kernel.org>
Subject: Re: [RFC] Do not activate promiscuous mode on wlan interfaces for
	bridging.

Thank you very much for your comments Jouni.

On Thu, 2008-06-12 at 08:33 +0300, Jouni Malinen wrote:
> Whether the "promiscuous mode" is really a suitable name for this mode
> is another question, though, since there are more ways to be
> promiscuous in wireless networks than wired.. ;-)

Indeed, but the bridge sets promiscuous mode, not monitor. This means
that the device will receive every frame within its configured BSS
whether it is addressed to it or not. For an AP actually this mode
should make no difference, since every frame not coming from the AP is
addressed to the AP.


> This is not strictly speaking correct. 4-address frame format (WDS) can
> be used in other (non-AP) modes, too. Anyway, they do not require the
> interface to be in promiscuous mode since addr1 of the frames is the
> unicast address of the receiving device regardless of the original
> destination address.

Agreed, will reword that.

-- 
Luis Carlos Cobo Rus       GnuPG ID: 44019B60
cozybit Inc.


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