Adding a parameter to net80211_input?

[Quentin Garnier]

Hi,

I've been working on importing support for RALink 2860 devices from
OpenBSD, because that's the WLAN chip the EeeBox has.

Like wi(4), this chip is able to do encryption and decryption in the
hardware. Like wi(4), it has the issue that the net80211 layer isn't
too keen on the idea.

wi(4) has a weird workaround for that, clearing _F_DROPUNENC from the
ic's flags when deemed appropriate.

I've been thinking of what could be a better solution, and so far the
best I could come up with is to pass an additional parameter to
ieee80211_input() indicating that the frame has been decrypted already,
when appropriate.

There is more needed to make wi(4) work in hostap mode (although I
don't have that one handy, sorry).

Would anyone think of a better way of doing that?

Obviously I'd like to commit that support as soon as possible and
hopefully as less intrusively as possible...

I note that FreeBSD's wi(4) doesn't seem to have that workaround, or an
additional parameter to ieee80211_input. My guess is that either the
driver is broken with WEP, or they changed it so it doesn't do any
crypto in hardware...

[David Young]

Post by Quentin Garnier
Hi,
I've been working on importing support for RALink 2860 devices from
OpenBSD, because that's the WLAN chip the EeeBox has.
Like wi(4), this chip is able to do encryption and decryption in the
hardware. Like wi(4), it has the issue that the net80211 layer isn't
too keen on the idea.

Actually, the net80211 layer *is* keen on the idea. Maybe it appears
otherwise. Can you say more about that?

How has OpenBSD dealt with WEP?

Dave

[Quentin Garnier]

Post by David Young

Post by Quentin Garnier
Hi,
I've been working on importing support for RALink 2860 devices from
OpenBSD, because that's the WLAN chip the EeeBox has.
Like wi(4), this chip is able to do encryption and decryption in the
hardware. Like wi(4), it has the issue that the net80211 layer isn't
too keen on the idea.

Actually, the net80211 layer *is* keen on the idea. Maybe it appears
otherwise. Can you say more about that?

Do you remember the workaround wi(4) has to use not to see F_DROPUNENC
kill all frames?

You called it grotty in the first place :)
http://mail-index.netbsd.org/tech-net/2007/11/26/0005.html

I guess the problem is that just like for wi, the crypto headers are
lost.

Post by David Young
How has OpenBSD dealt with WEP?

They pass a parameter to ieee80211_input.

[Sam Leffler]

Post by Quentin Garnier

Post by David Young

Post by Quentin Garnier
Hi,
I've been working on importing support for RALink 2860 devices from
OpenBSD, because that's the WLAN chip the EeeBox has.
Like wi(4), this chip is able to do encryption and decryption in the
hardware. Like wi(4), it has the issue that the net80211 layer isn't
too keen on the idea.

Actually, the net80211 layer *is* keen on the idea. Maybe it appears
otherwise. Can you say more about that?

Do you remember the workaround wi(4) has to use not to see F_DROPUNENC
kill all frames?
You called it grotty in the first place :)
http://mail-index.netbsd.org/tech-net/2007/11/26/0005.html
I guess the problem is that just like for wi, the crypto headers are
lost.

Post by David Young
How has OpenBSD dealt with WEP?

They pass a parameter to ieee80211_input.

FreeBSD defines an M_WEP flag to tag mbufs that have been decrypted (and
the WEP header removed) but still have the WEP bit set in the 802.11
header (IEEE80211_FC1_WEP).

If you're adding support for 2860 h/w crypto then this is the least of
your worries. The more difficult issue is how to deal with TKIP
requiring phase1 be handled by the driver.

Sam


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Young]

Post by Quentin Garnier

Post by David Young

Post by Quentin Garnier
Hi,
I've been working on importing support for RALink 2860 devices from
OpenBSD, because that's the WLAN chip the EeeBox has.
Like wi(4), this chip is able to do encryption and decryption in the
hardware. Like wi(4), it has the issue that the net80211 layer isn't
too keen on the idea.

Actually, the net80211 layer *is* keen on the idea. Maybe it appears
otherwise. Can you say more about that?

Do you remember the workaround wi(4) has to use not to see F_DROPUNENC
kill all frames?
You called it grotty in the first place :)
http://mail-index.netbsd.org/tech-net/2007/11/26/0005.html

It is grotty. I do not think that it should be repeated.

Post by Quentin Garnier
I guess the problem is that just like for wi, the crypto headers are
lost.

I guess so. Does the Ralink adapter clear the crypto bit,
IEEE80211_FC1_WEP, or leave it set? Does it indicate the key number
by using, for example, bits in the rx descriptor? Is it possible to
program the Ralink adapter to decrypt without removing the WEP header?

I think that the best option is probably to let software do WEP.
Second best option may be to add a capability flag to net80211
(IEEE80211_C_xxx)that tells it that the h/w does the WEP decapsulation,
then fiddle a bit with ieee80211_input().

Dave

[Quentin Garnier]

Post by David Young

Post by Quentin Garnier

Post by David Young

Post by Quentin Garnier
Hi,
I've been working on importing support for RALink 2860 devices from
OpenBSD, because that's the WLAN chip the EeeBox has.
Like wi(4), this chip is able to do encryption and decryption in the
hardware. Like wi(4), it has the issue that the net80211 layer isn't
too keen on the idea.

Actually, the net80211 layer *is* keen on the idea. Maybe it appears
otherwise. Can you say more about that?

Do you remember the workaround wi(4) has to use not to see F_DROPUNENC
kill all frames?
You called it grotty in the first place :)
http://mail-index.netbsd.org/tech-net/2007/11/26/0005.html

It is grotty. I do not think that it should be repeated.

Fair enough. I agree.

Post by David Young

Post by Quentin Garnier
I guess the problem is that just like for wi, the crypto headers are
lost.

I guess so. Does the Ralink adapter clear the crypto bit,
IEEE80211_FC1_WEP, or leave it set? Does it indicate the key number

It leaves it set. Exactly like wi(4)

Post by David Young
by using, for example, bits in the rx descriptor? Is it possible to

It might. I can't be affirmative without testing, but the chip-
sepcific header of the frame has 2 bits named KeyIndex in the Ralink
linux driver.

Post by David Young
program the Ralink adapter to decrypt without removing the WEP header?

I didn't find anything remotely connected to that in the register
definitions in the Ralink linux driver.

Post by David Young
I think that the best option is probably to let software do WEP.

I can probably do that.

Post by David Young
Second best option may be to add a capability flag to net80211
(IEEE80211_C_xxx)that tells it that the h/w does the WEP decapsulation,
then fiddle a bit with ieee80211_input().

Maybe. I'll try cooking something up.