RFC: Driver for Wireless RNDIS USB devices.

Hello,

This is second try on wireless RNDIS patchset started by Bjorge Dijkstra. Since Bjorge has disappeared, I claim maintainership of rndis_wext and this patchset until he returns.

This patchset adds support for various 802.11 USB devices based on Broadcom 4320 chip. Chip uses RNDIS to communicate with the host, so module depend heavily on rndis_host/cdc_ether/usbnet and needs some changes on these modules in order to work.

Patches 1-6 are from first patchset:
1. Fix sparse warning: returning void valued expression
2. [cdc_ether] Hardwire CDC descriptors when missing
3. [rndis_host] Use 1KB buffer in rndis_unbind
4. [rndis_host] Halt device if rndis_bind fails
5. [rndis_host] Fix rndis packet filter flags
6. [usbnet] Use wlan device name for RNDIS wireless devices

Of these 1, 3 and 4 are not required for this version of rndis_wext to work.

Actual wireless part is changed from extension on rndis_host to separate driver. Different devices are detected by device specific USB vendor/product IDs as the way done with Windows drivers instead of detecting RNDIS media type like in first patchset.

New patches 7-14:
7. [rndis_host] Split up rndis_host.c
8. [rndis_host] export functions
9. [usbnet] add driver_priv pointer to 'struct usbnet'
10. [rndis_host] Add rndis_early_init function pointer to 'struct rndis_data'.
11. [rndis_host] Add rndis_link_change function pointer to 'struct rndis_data'.
12. Move usbnet.h and rndis_host.h to include/linux/usb
13. [rndis_host] blacklist known wireless RNDIS devices
14. Add new driver 'rndis_wext' for wireless RNDIS devices.

Patches should be applied in order, series apply cleanly to 2.6.24-rc8.

- Jussi Kivilinna

-
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 6 lines · Jussi Kivilinna

Hello,

This is second try on wireless RNDIS patchset started by Bjorge Dijkstra. Since Bjorge has disappeared, I claim maintainership of rndis_wext and this patchset until he returns.

Quoted 4 lines

This patchset adds support for various 802.11 USB devices based on Broadcom 4320 chip. Chip uses RNDIS to communicate with the host, so module depend heavily on rndis_host/cdc_ether/usbnet and needs some changes on these modules in order to work.

Any change of getting driver merged in 2.6.25?

I would like to have this driver soon, and FWIW I just put it in the Fedora Rawhide kernel last night.

However, I find that it does not seem to associate with WEP networks on my USR5421. I haven't had a chance to try it on open or WPA networks, nor have I had a chance to debug it. It does scan and see the networks.

Have you tested the driver as posted? What device(s) are you using? Have you used it on encrypted networks?

Quoted 8 lines · John W. Linville

I would like to have this driver soon, and FWIW I just put it in the Fedora Rawhide kernel last night.

However, I find that it does not seem to associate with WEP networks on my USR5421. I haven't had a chance to try it on open or WPA networks, nor have I had a chance to debug it. It does scan and see the networks.

Quoted 2 lines

Have you tested the driver as posted? What device(s) are you using? Have you used it on encrypted networks?

I guess I should start testing more if I'm going to be maintainer, you're right WEP doesn't work. Unencrypted and WPA/WPA2 networks do work for me but not WEP. Ad-Hoc and hidden WPA networks do not work either. I have Buffalo WLI-U2-KG125S which should have same hardware/firmware as USR5421.

Overall this looks fine to me for initial merge. I have a couple of comments:

-- I'm not too excited about the "Ndis_802_*" naming scheme for data structures, although I know you copied it from elsewhere. I'd like to see it changed, but I don't consider that a merge blocker.

-- I foresee this driver surviving a conversion to use the new cfg80211 configuraiton API. So the "rndis_wext" name may not be the best long-term choice. I might suggest something like "rndis_wlan". I don't see why we couldn't change that post-merge, although I would prefer to do that before the final 2.6.25 release.

So, I intend to push this upstream for 2.6.25. Please consider making the changes cited above, especially the name change.

Hello,

This is second try on wireless RNDIS patchset started by Bjorge Dijkstra. Since Bjorge has disappeared, I claim maintainership of rndis_wext and this patchset until he returns.

This patchset adds support for various 802.11 USB devices based on Broadcom 4320 chip. Chip uses RNDIS to communicate with the host, so module depend heavily on rndis_host/cdc_ether/usbnet and needs some changes on these modules in order to work.

Patches 1-6 are from first patchset:
1. Fix sparse warning: returning void valued expression
2. [cdc_ether] Hardwire CDC descriptors when missing
3. [rndis_host] Use 1KB buffer in rndis_unbind
4. [rndis_host] Halt device if rndis_bind fails
5. [rndis_host] Fix rndis packet filter flags
6. [usbnet] Use wlan device name for RNDIS wireless devices

Of these 1, 3 and 4 are not required for this version of rndis_wext to work.

Actual wireless part is changed from extension on rndis_host to separate driver. Different devices are detected by device specific USB vendor/product IDs as the way done with Windows drivers instead of detecting RNDIS media type like in first patchset.

New patches 7-14:
7. [rndis_host] Split up rndis_host.c
8. [rndis_host] export functions
9. [usbnet] add driver_priv pointer to 'struct usbnet'

10. [rndis_host] Add rndis_early_init function pointer to 'struct rndis_data'.
11. [rndis_host] Add rndis_link_change function pointer to 'struct rndis_data'.

12. Move usbnet.h and rndis_host.h to include/linux/usb

13. [rndis_host] blacklist known wireless RNDIS devices

14. Add new driver 'rndis_wext' for wireless RNDIS devices.

Patches should be applied in order, series apply cleanly to 2.6.24-rc8.

- Jussi Kivilinna

Quoted 1 line

13. [rndis_host] blacklist known wireless RNDIS devices

That will be a headache over time though ... can't you just let the probe succeed enough to recogize it's wireless (using the media flag) and then bail, so the next driver can try?

Quoted 5 lines · David Brownell

Quoted 1 line

13. [rndis_host] blacklist known wireless RNDIS devices

That will be a headache over time though ... can't you just let the probe succeed enough to recogize it's wireless (using the media flag) and then bail, so the next driver can try?

Sure, that works too (but causes a little bit more message flood).