WiFi Refresh -- Report 4

[Phil Nelson <phil%NetBSD.org@localhost>]

Hello tech-net@,

  This is my fourth report on the status of the WiFi Refresh.
(Sorry this is a little late.)

After 200 hours of work on porting the FreeBSD WiFi stack to
NetBSD, I finally have one driver (urtwn) working in station
mode over an open AP.   This is the first step in getting
a successful port.

---->~/netbsd/src.wifi/sys
steelhead[26]$ ifconfig urtwn0
urtwn0: flags=0x8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        ssid notusable
        powersave on (100ms sleep)
        bssid e0:91:f5:5d:62:be chan 4
        ec_capabilities=ffffffffea4cae10
        ec_enabled=63c52788
        address: 74:da:38:e2:9d:fd
        media: IEEE802.11 autoselect mode 11g
        status: active
        inet 192.168.1.100/24 broadcast 192.168.1.255 flags 0x0

---->~/netbsd/src.wifi/sys
steelhead[27]$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=10.318401 ms
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=5.284244 ms
^C
----192.168.1.1 PING Statistics----
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 5.284244/7.801322/10.318401/3.559687 ms


There is still a lot of work to be done to complete this job.

For station mode:
  a) getting WEP working
  b) getting the code to work with wpa_supplicant

For the urtwn driver:
  a) Major cleanup, removing the urtwn scan code since there
     is generic code to do this now.
  b) adding in support for N and AC modes (needs hardward documents
     to be able to do this)

For the framework in general:
  a) complete NetBSD specific ioctls.  This is for support of current
     tools.   In the long run, tools should be moved to use the
     generic ioctls supported in the frame work.  (ifconfig and others)
  b) ddb and trace sections are not working at all.
  c) no testing has been done with other modes.   Modes supported by
     the framework include adhoc station, software ware AP mode, monitor
     mode, Mesh Point link and WDS link.
  d) Very few sysctls are currently working.
  e) Does not support modules and module loading.
  f) No IPv6 testing to date

For drivers:

  A rather major rewrite of the drivers is in order.  A lot of stuff
  done in the urtwn driver was moved in to the 802.11 stack.  These
  include:

  a) running scanning.   Callbacks are specified for a number of
     scanning related tasks.

  b) preparing the frame for transmission.  The framework has a
     couple of new callbacks, transmit() and raw_xmit().  These
     are handed mbufs with packets ready to transmit, either for
     queuing (transmit) or immediate trasnmit (raw_xmit).

     urtwn used the struct ifnet if_snd queue but the framework
     is not expecting that.  I added a new send queue in the
     softc for handling the transmit() packets.  (Similar to what
     is in the FreeBSD "ram" driver.)

  A complete new set of callbacks needs to be implemented (including
  those mentioned above.)

  A major change for  drivers is that the "struct ifnet" should
  no longer be in the softc.   The framework expects a device softc
  and then for each active interface a "vap" structure that is
  created via a "vap_create" callback.  At the poing of vap_create,
  the "struct ifnet" is now allocated.   For the 802.11 framework,
  if_softc in the struct ifnet should now point to the VAP.  The
  VAP in turn has a pointer to the device softc and the ifnet struct.
  This will require changes in all drivers.  And this change can not
  be done mechanically.

  This change does open up the possibility of having two interfaces
  on a single device.   I'm not sure this is a good way to do things
  and currently, the urtwn will not allow a second vap_create 

For the rest of the system:

  Currently all of the executibles interacting with the 802.11 framework
  were compiled with -current with the old 802.11 includes.   Changes in
  the 802.11 h files will require changes in programs that use the 802.11
  framework.   As mentioned before, ifconfig will need to be updated.
  At minimum, it will need to use the "old list scan" interface since the
  new one has a completely different structure returned to the user.

  Known list of programs that may need updates due to the new 802.11 code
  are:  ifconfig, dhcp*, wpa*, hostapd, route, wiconfig, wlanctl, kdump,
  and rump_dhcpclient.


More work will be happening on this in September.   I expect about 50
more hours of work before the end of September.   After that, I will
continue to work on it, but at a slower pace.  The final report will
be at the end of September.

   Work for September is expected to be:

      a)  WEP and WPA
      b)  urtwn clean-up
      c)  documentation so others may help

-- Phil