linux-kernel - Re: Roaming / offchannel enhancements for broadcast / multicast frames

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]

Date:	Fri, 8 Oct 2010 17:08:28 -0700
From:	Paul Stewart <pstew@...gle.com>
To:	"Luis R. Rodriguez" <mcgrof@...il.com>
Cc:	linux-wireless <linux-wireless@...r.kernel.org>,
	linux-kernel@...r.kernel.org, Matt Smith <Matt.Smith@...eros.com>,
	Srinivasa Duvvuri <Srinivasa.Duvvuri@...eros.com>,
	Carolyn Waller <Carolyn.Waller@...eros.com>,
	Amod Bodas <Amod.Bodas@...eros.com>,
	David Quan <David.Quan@...eros.com>,
	Bennyam Malavazi <Bennyam.Malavazi@...eros.com>,
	Cliff Holden <Cliff.Holden@...eros.com>,
	Aeolus Yang <Aeolus.Yang@...eros.com>,
	Kevin Hayes <kevin@...eros.com>
Subject: Re: Roaming / offchannel enhancements for broadcast / multicast frames

On Fri, Oct 8, 2010 at 12:54 PM, Luis R. Rodriguez <mcgrof@...il.com> wrote:
> We spoke about how to handle broadcast / multicast frames when going
> offchannel at the Wireless Summit [1]. A lot of these talks were lead
> due to a Chrome side open bug [2].

Thanks for getting the ball rolling, Luis.  Technically the bug is in
ChromumOS ("Chrome" is a web browser).

> Userspace may want to force a roam when this deadzone event hits.

Why not just disassociate at this point?  I'm not sure what the
difference is between a "dead zone" situation and a reason to
completely disconnect.

> Once we have these two in place we can then ignore bgscan requests
> (when associated) unless a force scan command has been issued by
> userspace, or unless we are idle.

By "ignore" do you mean "postpone" or or "return an appropriate error
to userspace"?  Either of those are acceptable.  Not doing anything at
all wouldn't be good.  There's an additional issue about what happens
when we are in the middle of a bgscan and new tx traffic appears.

> In the worst case scenario and unfortunately this seems to be the most
> common one, a DTIM of 1 is used and we will have to be on channel and
> awake every beacon interval. In this case we may want to optimize scan
> time by not scanning passive scan channels.

A compromise would be to go off-channel for less than a full beacon
interval when doing background passive channel scans in DTIM=1
networks.  It's certainly better than (a) not scanning at all and (b)
arguably better than intentionally dropping mcast.  An 80% beacon-time
passive listen will get you 80% of the beacons, assuming linear
probability, and even more over time if you account for beacon skew
between networks.

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