linux-kernel - Re: libertas (private) ioctls vs. nl80211

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: <1181861312.23567.18.camel@xo-28-0B-88.localdomain>
Date:	Thu, 14 Jun 2007 18:48:32 -0400
From:	Dan Williams <dcbw@...hat.com>
To:	Holger Schurig <hs4233@...l.mn-solutions.de>
Cc:	Christoph Hellwig <hch@...radead.org>,
	Johannes Berg <johannes@...solutions.net>,
	linux-wireless@...r.kernel.org, akpm@...l.org,
	linux-kernel@...r.kernel.org
Subject: Re: libertas (private) ioctls vs. nl80211

On Thu, 2007-06-14 at 22:03 +0200, Holger Schurig wrote:
> > Independent of any nl80211 status the private libertas ioctls have to
> > go.  Not only don't we want private ioctls for mesh networking but
> > rather have it as driver-independent interface, but the actual
> > libertas interface is the worst possible choice.
> 
> I have been told that the Libertas mesh functionality is not 802.11s, 

Technically this is correct.  A bit more back-story though.  802.11s is
still in draft form.  It'll be there for a while yet.  Stuff like
authentication and encryption are in heavy flux.  Previously, the mesh
stuff was using the 4th value in the 802.11 frame type.  But it turns
out that a lot of fullmac parts can't handle that because they drop
those frames in silicon.  So the standard is moving towards using WDS
frames without changing the frame type, which is what the Marvell
implementation is _already_ using.  I repeat, the standard is moving
towards the Marvell mesh implementation.  Furthermore, the CozyBit guys
who wrote the Marvell mesh implementation are heavily involved in the
802.11s standards groups anyway.

> Marvell brew their own beer (because it predates 802.11s, I guess). 
> However, for the kernel I'd see more an interface that supports 
> 802.11s --- or is flexible to support both this and the libertas one.

Definitely; 

> I also have two related observations:
> 
> If I'm correctt, the only non-mesh ioctl in ioctl.c is the led_gpio 
> ioctl. Theoretically one can abstract this, many WLAN chips have GPIOs. 

Plus the set_region call that can be replaced by whatever the regulatory
stuff comes up with.

> But mostly there is no documentation available about how those GPIOs 
> are used, where they are soldered to etc. To blindly allow changing 
> arbitrary GPIOs migth even be harmful to the hardware.
> 
> That said: with the USB 8388 dongle that I have, the LED GPIO iwpriv 
> call didn't do anything. Not sure if it works on OLPC ... but I doubt 
> that one can see the LEDs there ...

I think it's all dependent on the firmware; do you know what version of
the CF firmware you have?  The ledgpio function is apparently from an
older version of the firmware but is still in our 8388 5.x branch.
There's apparently a new command for this sort of thing.

> Another thing: I'm working on a CF 8385 based driver. Here I have a 
> firmware that does not (as far as I know this undocumented pile of 
> bytes) have any mesh functionality at all. So I need a way from if_cs.c 
> to disable all those iwpriv ioctls. Haven't thought about this issue 
> yet, other things are more pressing right now. However, I already don't 
> create the mshX interface.

Well, can't the ioctl stuff just return -EOPNOTSUPP or something if mesh
isn't available?

Dan

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