netdev - Re: [PATCH] Marvell Libertas 8388 802.11b/g USB driver (v2)

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 22 Jan 2007 09:26:13 -0200
From:	Marcelo Tosatti <marcelo@...ck.org>
To:	Johannes Berg <johannes@...solutions.net>
Cc:	Dan Williams <dcbw@...hat.com>, Jiri Benc <jbenc@...e.cz>,
	Marcelo Tosatti <marcelo@...ck.org>,
	netdev <netdev@...r.kernel.org>, Jeff Garzik <jgarzik@...ox.com>,
	"John W. Linville" <linville@...hat.com>,
	"Luis R. Rodriguez" <mcgrof@...il.com>,
	Arnd Bergmann <arnd@...db.de>,
	Arnaldo Carvalho de Melo <acme@...stprotocols.net>
Subject: Re: [PATCH] Marvell Libertas 8388 802.11b/g USB driver (v2)

On Wed, Jan 17, 2007 at 06:01:24PM +0000, Johannes Berg wrote:
> On Wed, 2007-01-17 at 12:43 -0500, Dan Williams wrote:
> 
> > I said "mostly" fullmac.  Sort of like ipw2100 (IIRC) is softmac but it
> > does all the association stuff in firmware.  It doesn't fit fullmac, but
> > it's a lot more fullmac than atheros.  There isn't any management frame
> > processing, it doesn't do any data frame processing.
> 
> Right. I hadn't looked at data frames but suspected this is the case.
> 
> > The 8388 architecture is typical of a thick firmware architecture, where
> > the firmware handles all 802.11 MAC management tasks.  The host driver
> > downloads standard 802.3 frames to the firmware to be transmitted over
> > the link as 802.11 frames.
> > 
> > I thought these 2 things were essentially _the_ definition of fullmac,
> > please correct me if I'm wrong.
> 
> Well we'll need more terms here. I had a short chat with Jouni and we
> agree that what the Marvell card is doing is exposing the MLME
> interface, and what d80211 is doing is implementing most of the MLME.
> 
> I guess the thing I'm saying is that exposing the MLME interface which
> changes fairly frequently is a bad thing and I'd love to have firmware
> that exposes lower level stuff like .
> 
> > Perhaps I just don't understand how flexible d80211 has become; when we
> > last were talking about it 8 months ago, it appears that it could not
> > handle parts that did significant pieces of work in firmware, like the
> > 8388 does.  Do we have the functionality in d80211 yet to handle pieces
> > that are a full mix of hybrid full/soft mac?
> 
> No, we don't have that yet, and we might never have. But I think I'm
> starting to understand the issues at hand a bit better and it seems that
> we'll need cfg80211 to be redefined.

So using the d80211 stack is completly out of question?

Another detail is the way we deal with mesh networking: a separate
device "mshX" is created, and that certainly does not fit d80211?

-
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