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:	Mon, 22 Jan 2007 10:20:47 -0500
From:	"Jon Smirl" <jonsmirl@...il.com>
To:	"Marcelo Tosatti" <marcelo@...ck.org>
Cc:	"Johannes Berg" <johannes@...solutions.net>,
	"Dan Williams" <dcbw@...hat.com>, "Jiri Benc" <jbenc@...e.cz>,
	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 1/22/07, Marcelo Tosatti <marcelo@...ck.org> wrote:
> 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?

What is the general solution for 802.11s? I'm working on an embedded
design that would benefit from 11s support and I'd rather not have to
roll my own mesh implementation in user space. I'd also like to get an
idea of what kind of hardware I need to design onto my board given
that the 8388 is not available general consumption. My system has
plenty of power and CPU available so a softmac type 11s solution is
the most cost effective. It seems to me that the design of a software
based 11s stack should be coordinated with the 8388 firmware one.

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

-- 
Jon Smirl
jonsmirl@...il.com
-
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ