Hi Jouni!
Since you're the author of the WE-18 patch proposal i have a few
questions about it:
- what kind of information should be used in set_genie/get_genie
requests? I know it's a pointer, but what is the information it points
to? ipw2100 firmware expects: capabilities, listening interval,
current_ap, var_ie_len and var_ie for setting IEs.
- How should IW_AUTH_CIPHER_PAIRWISE and IW_AUTH_CIPHER_GROUP be used
with crypt_tkip/crypt_ccmp ?
This one is more oriented to the design of the wireless extensions and
should probably go to Jean Tourrilhes:
- the switch/case logic (for set_auth/get_auth at least) should really
be in the wireless extensions. The driver should only need to set
function pointers to the required actions, otherwise, every driver will
have to code the whole logic around the multiplexing of the IOCTL,
requiring more work amongst drivers, and the code will get less
readable. Maybe this could be done also to the rest of the wireless
extensions. I simply cannot understand the reason why the IOCTL
interface is exposed to the driver. The driver shouldn't even know that
some functionality is being called from an IOCTL. From the wireless
extensions point of view the driver should only provide the methods to
do certain tasks, not the logics around the passing of information from
userspace(ex: wireless tools) to kernel space(wireless extensions) this
just duplicates driver work.
Thanks!
PS: I was hoping someone had already answer my e-mail about the creation
of a linux wireless mailing list, and this message would be sent to the
new list... oh well
--
Pedro Ramalhais [off-list ref]
On Sun, Aug 08, 2004 at 02:36:40AM +0100, Pedro Ramalhais wrote:
- what kind of information should be used in set_genie/get_genie
requests? I know it's a pointer, but what is the information it points
to? ipw2100 firmware expects: capabilities, listening interval,
current_ap, var_ie_len and var_ie for setting IEs.
There are additional IEEE 802.11 information elements, including
identification and length bytes. The data area can include one more
multiple IEs (e.g., WPA, RSN, WME). Capabilities, listen interval, and
current AP would be from other ioctls.
- How should IW_AUTH_CIPHER_PAIRWISE and IW_AUTH_CIPHER_GROUP be used
with crypt_tkip/crypt_ccmp ?
I'm not sure what you mean with this. Cipher configuration is an
optional mechanism that some drivers can use for WPA configuration. This
is especially to make it easier to use drivers that were originally
designed for NDIS since they generate WPA IE based on the cipher
configuration whereas some of the (non-NDIS) drivers that I have worked
with get WPA IE from the Supplicant (i.e., they can share the same code
for this) and can ignore these values.
PS: I was hoping someone had already answer my e-mail about the creation
of a linux wireless mailing list, and this message would be sent to the
new list... oh well
What's wrong with using netdev for this? I think this was the result
from the last time the topic of adding a new list came up and I don't
think anything have changed since then. As long as people don't complain
about getting too much messages about wireless development on netdev, I
don't see much point in adding a new list.
--
Jouni Malinen PGP id EFC895FA
On Sun, Aug 08, 2004 at 02:36:40AM +0100, Pedro Ramalhais wrote:
This one is more oriented to the design of the wireless extensions and
should probably go to Jean Tourrilhes:
- the switch/case logic (for set_auth/get_auth at least) should really
be in the wireless extensions.
Not everybody is using a wireless card, and of those using
wireless cards, not all of them are using WPA. Therefore, my goal is
to minimise kernel bloat.
If you don't like the current situation, there are two avenues :
o use different ioctls
o use a separate common module to demultiplex the ioctl
PS: I was hoping someone had already answer my e-mail about the creation
of a linux wireless mailing list, and this message would be sent to the
new list... oh well
Check the archive of netdev mailing list a few months back.
Have fun...
Jean