1. 19 Dec, 2007 1 commit
  2. 10 Nov, 2007 1 commit
  3. 17 Oct, 2007 1 commit
  4. 10 Oct, 2007 9 commits
  5. 08 Jul, 2007 1 commit
  6. 11 Jun, 2007 2 commits
  7. 10 May, 2007 1 commit
  8. 07 May, 2007 1 commit
  9. 02 May, 2007 1 commit
  10. 28 Apr, 2007 1 commit
  11. 25 Apr, 2007 2 commits
  12. 03 Oct, 2006 1 commit
  13. 29 Aug, 2006 1 commit
  14. 27 Jul, 2006 1 commit
  15. 05 Jul, 2006 1 commit
    • Daniel Drake's avatar
      [PATCH] ZyDAS ZD1211 USB-WLAN driver · e85d0918
      Daniel Drake authored
      There are 60+ USB wifi adapters available on the market based on the ZyDAS
      ZD1211 chip.
      Unlike the predecessor (ZD1201), ZD1211 does not have a hardware MAC, so most
      data operations are coordinated by the device driver. The ZD1211 chip sits
      alongside an RF transceiver which is also controlled by the driver. Our driver
      currently supports 2 RF types, we know of one other available in a few marketed
      products which we will be supporting soon.
      Our driver also supports the newer revision of ZD1211, called ZD1211B. The
      initialization and RF operations are slightly different for the new revision,
      but the main difference is 802.11e support. Our driver does not support the
      QoS features yet, but we think we know how to use them.
      This driver is based on ZyDAS's own GPL driver available from www.zydas.com.tw.
      ZyDAS engineers have been responsive and supportive of our efforts, so thumbs
      up to them. Additionally, the firmware is redistributable and they have
      provided device specs.
      This driver has been written primarily by Ulrich Kunitz and myself. Graham
      Gower, Greg KH, Remco and Bryan Rittmeyer have also contributed. The
      developers of ieee80211 and softmac have made our lives so much easier- thanks!
      We maintain a small info-page: http://zd1211.ath.cx/wiki/DriverRewrite
      If there is enough time for review, we would like to aim for inclusion in
      2.6.18. The driver works nicely as a STA, and can connect to both open and
      encrypted networks (we are using software-based encryption for now). We will
      work towards supporting more advanced features in the future (ad-hoc, master
      mode, 802.11a, ...).
      Signed-off-by: default avatarDaniel Drake <dsd@gentoo.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  16. 05 Jun, 2006 1 commit
  17. 24 Apr, 2006 3 commits
    • Zhu Yi's avatar
      [PATCH] wireless Kconfig add IPW2200_RADIOTAP · 34f8ae46
      Zhu Yi authored
      Makefile both IPW2200_RADIOTAP and IPW2200_PROMISCUOUS depend on
      Signed-off-by: default avatarZhu Yi <yi.zhu@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Zhu Yi's avatar
    • Zhu Yi's avatar
      [PATCH] ipw2200: Enable rtap interface for RF promiscuous mode while associated · d685b8c2
      Zhu Yi authored
      With this patch, a new promiscuous mode is enabled. If the module is loaded
      with the rtap_iface=1 module parameter, two interfaces will be created
      (instead of just one).
      The second interface is prefixed 'rtap' and provides received 802.11 frames
      on the current channel to user space in a radiotap header format.
      Example usage:
              % modprobe ipw2200 rtap_iface=1
              % iwconfig eth1 essid MyNetwork
              % dhcpcd eth1
              % tcpdump -i rtap0
      If you do not specify 'rtap_iface=1' then the rtap interface will
      not be created and you will need to turn it on via:
              % echo 1 > /sys/bus/pci/drivers/ipw2200/*/rtap_iface
      You can filter out what type of information is passed to user space via
      the rtap_filter sysfs entry.  Currently you can tell the driver to
      transmit just the headers (which will provide the RADIOTAP and IEEE
      802.11 header but not the payload), to filter based on frame control
      type (Management, Control, or Data), and whether to report transmitted
      frames, received frames, or both.
      The transmit frame reporting is based on a patch by Stefan Rompf.
      Filters can be get and set via a sysfs interface. For example, set the
      filter to only send headers (0x7), don't report Tx'd frames (0x10), and
      don't report data frames (0x100):
              % echo 0x117 > /sys/bus/pci/drivers/ipw2200/*/rtap_filter
      All your packets are belong to us:
              % tethereal -n -i rtap0
      Signed-off-by: default avatarJames Ketrenos <jketreno@linux.intel.com>
      Signed-off-by: default avatarZhu Yi <yi.zhu@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  18. 19 Apr, 2006 1 commit
    • Jean Tourrilhes's avatar
      [PATCH] Revert NET_RADIO Kconfig title change · c1783454
      Jean Tourrilhes authored
      	2.6.17-rc1 changed the title for the entry CONFIG_NET_RADIO. I
      personally disagree with this change and want it reverted. Patch for
      	Rationale : WIRELESS_EXT is an invisible option. Therefore,
      the only way for a user to enable it is via NET_RADIO. Some users need
      to do that for out-of-tree drivers. Therefore it should be mentionned
      in the title of the option.
      	Rationale2 : the option just below is called "Wireless
      Extension API over RtNetlink". Some users may confuse this option for
      the main "Wireless Extension" option. Therefore reverting this change
      help disambiguate the relation between those two options.
      Signed-off-by: default avatarJean Tourrilhes <jt@hpl.hp.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  19. 31 Mar, 2006 1 commit
  20. 27 Mar, 2006 5 commits
  21. 24 Mar, 2006 1 commit
    • Dave Jones's avatar
      [WIRELESS]: Fix config dependencies. · 868d2c1e
      Dave Jones authored
      I accidentally ended up with a config that set NET_RADIO off,
      and NET_WIRELESS_RTNETLINK on, which blew up thus..
      net/built-in.o: In function `do_setlink':net/core/rtnetlink.c:479: undefined reference to `wireless_rtnetlink_set'
      net/built-in.o: In function `do_getlink':net/core/rtnetlink.c:521: undefined reference to `wireless_rtnetlink_get'
      Signed-off-by: default avatarDave Jones <davej@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  22. 23 Mar, 2006 1 commit
    • Jean Tourrilhes's avatar
      [PATCH] WE-20 for kernel 2.6.16 · 711e2c33
      Jean Tourrilhes authored
      	This is version 20 of the Wireless Extensions. This is the
      completion of the RtNetlink work I started early 2004, it enables the
      full Wireless Extension API over RtNetlink.
      	Few comments on the patch :
      	o totally driver transparent, no change in drivers needed.
      	o iwevent were already RtNetlink based since they were created
      (around 2.5.7). This adds all the regular SET and GET requests over
      RtNetlink, using the exact same mechanism and data format as iwevents.
      	o This is a Kconfig option, as currently most people have no
      need for it. Surprisingly, patch is actually small and well
      	o Tested on SMP, attention as been paid to make it 64 bits clean.
      	o Code do probably too many checks and could be further
      optimised, but better safe than sorry.
      	o RtNetlink based version of the Wireless Tools available on
      my web page for people inclined to try out this stuff.
      	I would also like to thank Alexey Kuznetsov for his helpful
      suggestions to make this patch better.
      Signed-off-by: default avatarJean Tourrilhes <jt@hpl.hp.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  23. 17 Feb, 2006 2 commits