Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
大约 1 年 前同步成功

通知 153
Star 36
Fork 7
cloud-kernel
cloud-kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 06 6月, 2006 1 次提交
  3. 25 4月, 2006 3 次提交
    • Z
      [PATCH] wireless Kconfig add IPW2200_RADIOTAP · 34f8ae46
      由 Zhu Yi 提交于 
      Makefile both IPW2200_RADIOTAP and IPW2200_PROMISCUOUS depend on
IPW2200_MONITOR. Let IPW2200_PROMISCUOUS select IPW2200_RADIOTAP.
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      34f8ae46
    • Z
      [PATCH] ipw2200: rename CONFIG_IPW_QOS to CONFIG_IPW2200_QOS · e43e3c1e
      由 Zhu Yi 提交于 
      Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e43e3c1e
    • Z
      [PATCH] ipw2200: Enable rtap interface for RF promiscuous mode while associated · d685b8c2
      由 Zhu Yi 提交于 
      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: NJames Ketrenos <jketreno@linux.intel.com>
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      d685b8c2
  5. 20 4月, 2006 1 次提交
    • J
      [PATCH] Revert NET_RADIO Kconfig title change · c1783454
      由 Jean Tourrilhes 提交于 
      	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
2.6.17-rc1.
	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: NJean Tourrilhes <jt@hpl.hp.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      c1783454
  7. 01 4月, 2006 1 次提交
  9. 28 3月, 2006 5 次提交
  11. 25 3月, 2006 1 次提交
  13. 23 3月, 2006 1 次提交
    • J
      [PATCH] WE-20 for kernel 2.6.16 · 711e2c33
      由 Jean Tourrilhes 提交于 
      	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
encapsulated.
	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: NJean Tourrilhes <jt@hpl.hp.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      711e2c33
  15. 17 2月, 2006 3 次提交
  17. 11 2月, 2006 1 次提交
  19. 31 1月, 2006 2 次提交
  21. 15 1月, 2006 2 次提交
  23. 13 1月, 2006 1 次提交
  25. 01 12月, 2005 2 次提交
  27. 11 11月, 2005 1 次提交
    • S
      [PATCH] Atmel wireless update · b16a228d
      由 simon@thekelleys.org.uk 提交于 
      * Merge PCMCIA card table with new Brodowski PCMCIA id table.
* Add missing entries to PCMCIA id table.
* Other tweaks to conform with Documentation/driver-changes.txt
  (types, call request_region, etc)
* Fix size of requested IO region.
* Reduce printk verbosity.
* Remove EXPERIMENTAL
* tweak to association code - don't force shared key authentication
  when wep in use.
Signed-off-by: NJeff Garzik <jgarzik@pobox.com>
      b16a228d
  29. 15 10月, 2005 1 次提交
  31. 06 9月, 2005 3 次提交
  33. 26 8月, 2005 1 次提交
  35. 24 8月, 2005 1 次提交
  37. 28 6月, 2005 1 次提交
  39. 28 5月, 2005 2 次提交
  41. 16 5月, 2005 1 次提交
    • D
      [PATCH] wireless: 3CRWE154G72 Kconfig help fix · c8920ba0
      由 Daniel Andersen 提交于 
      Version 2 of the 3com OfficeConnect 11g Cardbus Card aka 3CRWE154G72 is not
supported by the prism54 project.  To stop confusion, the kernel
documentation should state so as 3com made a good job hiding the version.
Signed-off-by: NAndrew Morton <akpm@osdl.org>

diff -puN drivers/net/wireless/Kconfig~wireless-3crwe154g72-kconfig-help-fix drivers/net/wireless/Kconfig
      c8920ba0
  43. 13 5月, 2005 1 次提交
  45. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      由 Linus Torvalds 提交于 
      Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
      1da177e4