From: Jean Tourrilhes <jt@bougret.hpl.hp.com>
To: Jouni Malinen <jkmaline@cc.hut.fi>,
netdev@oss.sgi.com, hostap@shmoo.com,
Pedro Ramalhais <ramalhais@serrado.net>
Subject: Re: Updated WE-18 (WPA) proposal
Date: Mon, 30 Aug 2004 09:50:26 -0700 [thread overview]
Message-ID: <20040830165026.GD29492@bougret.hpl.hp.com> (raw)
In-Reply-To: <20040830045441.GA7415@jm.kir.nu>
On Sun, Aug 29, 2004 at 09:54:41PM -0700, Jouni Malinen wrote:
> Finally, I had enough time to implement and test the proposed WE-18
> (WPA) changes with Host AP driver and wpa_supplicant.
Great !
> Since WE-17 has apparently not yet been merged all the way into
> linux-2.6 tree, the patch below is against Linux 2.6.8.1 that has been
> patched with WE-17 patch (http://www.hpl.hp.com/personal/
> Jean_Tourrilhes/Linux/iw268_we17-10.diff).
Don't worry, I'll fix that. Anyway, WE-17 is pending in Jeff's
tree, and I don't think he will make major changes to it.
> - replaced optional parameter (iw_point) to SIOCSIWSCAN with a new ioctl
> (SIOCSIWSCANEXT) since the previous design was not really backwards
> compatible (e.g., 'iwlist wlan0 scan' did not work)
Latest Wireless Tools actually fixes that. Most distro seems
to have adopted WT-27-preXX, and I plan to release WT-27 soon after
WE-17, so I would not consider that a big issue.
Having a separate ioctl has one advantage, you know if the
driver support it or not. One the other hand, having a single ioctl
may reduce bloat.
> Question: is length field in struct iw_point in bytes or tokens
> (token_size bytes)? I assumed it was in bytes, but this did not work
> very well with WE ioctls that had token_size != 1; I made SIOCSIWSCANEXT
> use token_size = 1 for now, but it could be replaced to be
> sizeof(struct) and min_tokens=max_tokesn=1 once this question is
> resolved.
Originally, I was using length == num-tokens, with token-size != 1.
However, after a while, I realised that having length ==
num-bytes was a much better option, so that's why the "newer" ioctls
tend to all have token_size == 1.
In the case of SIOCSIWSCANEXT, it's especially important as
the struct may grow in the future, so the size would allow to
distinguish the various additions.
Thanks a lot !
Jean
next prev parent reply other threads:[~2004-08-30 16:50 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-30 4:54 Updated WE-18 (WPA) proposal Jouni Malinen
2004-08-30 16:50 ` Jean Tourrilhes [this message]
2004-08-30 17:28 ` Jeff Garzik
2004-08-30 17:42 ` Jean Tourrilhes
2004-08-30 17:55 ` Jeff Garzik
2004-08-30 22:01 ` Luis R. Rodriguez
2004-08-30 22:20 ` Jeff Garzik
2004-08-31 8:54 ` Luis R. Rodriguez
2004-08-31 15:33 ` Pedro Ramalhais
2004-08-31 15:48 ` Vladimir Kondratiev
2004-08-31 21:04 ` Luis R. Rodriguez
2004-08-31 0:49 ` Pedro Ramalhais
2004-08-31 1:30 ` Jouni Malinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040830165026.GD29492@bougret.hpl.hp.com \
--to=jt@bougret.hpl.hp.com \
--cc=hostap@shmoo.com \
--cc=jkmaline@cc.hut.fi \
--cc=jt@hpl.hp.com \
--cc=netdev@oss.sgi.com \
--cc=ramalhais@serrado.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.