|
This project was created by Intel to enable support for the Intel PRO/Wireless 2915ABG Network Connection and Intel PRO/Wireless 2200BG Network Connection mini PCI adapters. This project (IPW2200) is intended to be a community effort as much as is possible given some working constraints (mainly, no HW documentation is available) If you are an end user looking for a driver to use, please use stable versions (versions ending in a 0). You can always find the latest tested stable release from Intel's Laptop Products page. If you are looking to help develop or test, please see this notice before using one of the unstable / untested snapshots. As always, in both cases (users or developers/testers) please send feedback, bug reports, feature requests and any fixes you come up with. Please let us know which distrubition you use this with, and any problems you encounter. You can submit bugs to the Bugzilla repository available at BugHost.
Other Intel wireless project pages:
In order to use the IPW2200 driver you will need the following:
We have put up a development mailing list to help in development. You can frequently find people on IRC channel #ipw2100 on irc.freenode.org. The following are links to projects, archives, and other sites that may be of use to IPW2200/2915 users:
Packages (not maintained by ipw2200 project):
Other IPW2200/2915 related open source projects:
Jul 12 2007 Changes in 1.2.2
Jan 05 2007 Changes in 1.2.1
Sep 13 2006 Changes in 1.2.0
Aug 21 2006 Changes in 1.1.4
Jun 12 2006 Changes in 1.1.3
[ more ]
A quick blurb about the release version numbers use:
The version numbers used for the snapshots indicate whether a release is a tested and stable release, or an unstable development release. A version where the last number is a 0 indicates a stable release. Versions ending in anything other than 0 are unstable. For example, 1.0.0 is stable, 1.0.1 is a development snapshot/release. Stable versions require a more extensive validation pass to be executed and will not be made available as frequently as the development snapshots. Only fully tested and verified drivers should be used and deployed by end users. The development and unstable snapshots are intended only for development and testing. For more information, please see this notice.
Firmware files fail to load even if installed
In some kernel configurations (users have most frequently reported the
problem only with 2.6.9), the default timeout value for the hotplug
subsystem is too low. You may have this problem if you see the
following in your kernel log (via dmesg or /var/log/messages):
ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, 1.0.1 ipw2200: Copyright(c) 2003-2004 Intel Corporation ipw2200: Detected Intel PRO/Wireless 2200BG Network Connection ipw2200: ipw-2.2-boot.fw load failed: Reason -2 ipw2200: Unable to load firmware: 0xFFFFFFFE ipw2200: failed to register network device ipw2200: probe of 0000:00:0b.0 failed with error -5 To work around this, you can increase the default timeout value: echo 100 > /sys/class/firmware/timeoutand then reload the ipw2200 module. If this corrects your problem, you may wish to add the above line to your system startup scripts prior to the point at which the driver module would be loaded. The other most common reason for getting the above error is that the firmware files are not installed in the correct location. Please see the INSTALL document for information on installing the firmware files. My wireless settings keep being changed!
If you are trying to manually set wireless configuration settings, you
may find yourself fighting for control with your specific distribution.
If you aren't familiar with how your distribution works, or what might
be reconfiguring the wireless tools, you can try the following:
% IWPATH=`dirname \`which iwconfig\``
% mv ${IWPATH}/iwconfig ${IWPATH}/iwconfig.bin
% echo "#\!/bin/sh
date >> /tmp/iwconfig.log
ps --forest >> /tmp/iwconfig.log
echo \"iwconfig $*\" >> /tmp/iwconfig.log
${IWPATH}/iwconfig.bin $1 $2 $3 $4 $5 $6 $7 $8 $9" > ${IWPATH}/iwconfig
% chmod +x ${IWPATH}/iwconfig
NOTE: You must be root to perform the above.
You can test that the above is working:
% iwconfig % cat /tmp/iwconfig.log Tue Oct 5 14:04:51 CDT 2004 PID TTY TIME CMD 16409 pts/1 00:00:00 su 16410 pts/1 00:00:00 \_ bash 24762 pts/1 00:00:00 \_ iwconfig 24764 pts/1 00:00:00 \_ psNow, the next time you experience your distribution changing your wireless configuration, check the contents of /tmp/iwconfig.log. It will tell you when iwconfig was last executed, what the arguments were, and what the processes are that were executing at that time. From this you can typically determine which scripts on your system are involved in managing your wireless devices. To restore your system to the way it was:
% IWPATH=`dirname \`which iwconfig\``
% mv ${IWPATH}/iwconfig.bin ${IWPATH}/iwconfig
Make ipw2200 interface "down" by default: patch
This patch moves the firmware loading and card initialization from dev->init
to dev->open and de-initialize it in dev->close. This makes the ipw2200 card
consume much less power when it is not used. Hence the patch makes users and
PowerTop happy.
Fix make patch_kernel problem for ipw2200-1.1.4: patch
Fix compile error when IPW2200_DEBUG is not defined: patch
In-tree Kconfig update for ipw2200-1.1.3: patch
Kconfig updates for IPW2200_QOS and IPW2200_RADIOTAP IPW2200_PROMISCUOUS Enable rtap interface for RF promiscuous mode while associated: patch
With this patch, a new promiscuous mode is enabled. Once applied, when you load the module 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. Example usage: First, see what filter bits are available: % ./filters Now 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 As a side note, you can see a sample user space application to pull the packets in user space in the file ipwstats.c. Check the start of that file for information on building and running that utility. Signed-off-by: James Ketrenos <jketreno@linux.intel.com> --- Makefile | 24 + filters | 56 +++ in-tree/Kconfig.ipw2200 | 83 +++++ ipw2200.c | 661 ++++++++++++++++++++++++++++++++++++++++-- ipw2200.h | 83 +++++ ipwstats.c | 752 ++++++++++++++++++++++++++++++++++++++++++++++++ ipwstats.cc | 571 ++++++++++++++++++++++++++++++++++++ 7 files changed, 2192 insertions(+), 38 deletions(-) ipw2200: Fix endian issues with v3.0 fw image format: patch
This patch corrects endian issues with the v3.0 fw image format. ipw2200.c | 23 ++++++++++++----------- 1 file changed, 12 insertions(+), 11 deletions(-) Fix problem with diversity algorithm causing disassocaition in 1.1.1: patch
In 1.1.1 a patch went in which enables the "slow diversity" algorithm. This algorithm forces one antenna or the other, if the background noise is significantly quieter in one than the other. It favors the quieter antenna, and won't kick in unless the difference is significant. This is showing to be problematic in some environments and is reverted by this patch. Signed-off-by: James Ketrenos <jketreno@linux.intel.com> Upgrade 1.1.0 to use new 3.0 fw image format: patch
The 3.0 fw image does not add any new capabilities, but it should fix two problems experienced by users: 1) Race conditions with the request_firmware interface and udev/hotplug are improved as only a single request_firmware call is now required to load the firmware and microcode (vs. 3 separate calls previously) 2) The monitor mode firmware (sniffer) is now packaged with the correct boot image so it can now function without frequent restarts. Once you apply the above, you will also need to upgrade your firmware image to the 3.0 version available from downloadable from: http://ipw2200.sf.net/firmware.php Fix problem with broadcast packets (DHCP, etc.) with 1.0.11, 1.0.12.: patch
If you experience problems with DHCP stalling out and not being able to
obtain an IP address, but statically configuring an IP address allows
you to access the network, you may need this patch to change how
broadcast packets are detected with older kernels.
Fix QoS command sending bug with ipw_send_cmd_pdu() in 1.0.9: patch
The patch fixes a couple of errors regarding QoS in 1.0.9, which
results in compile warnings and malfunction of the driver.
ipw2200-1.0.7 compatibility with older Wireless Extensions...: patch
If you encounter problems with compiling ipw2200-1.0.7, for example
IW_EVENT_CAPA_K_0 being undefined, etc. then try this patch.
Problem sending broadcast packets with 1.0.7: patch
This patch corrects the problem with sending broadcast packets in 1.0.7
(see bug # 798). You need to apply this patch and the patch available
on http://ieee80211.sf.net/#patches.
ipw2200-1.0.5 make indicates it will remove ipw.ko: patch
The portion of the Makefile that checks for old versions of the ipw2200
module on the system will incorrectly list ipw.ko as a module target for
deletion. This patch corrects that behavior.
ipw2200-1.0.5 Add tx_power setting for 802.11a channels: patch
This patch will update the 802.11a tables when 'iwconfig iface txpower'
is used to set the transmit power.
2.6.12 compile problem with is_multicast_ethr_addr: patch
If you have updated to 2.6.12 and are experiencing a compilation problem
with a redefinition of is_multicast_ethr_addr, you can use this patch to
correct the problem.
Thanks to David Michael Leo Brown for this patch (thanks to all that
sent in this patch)
Leaving monitor mode and can no longe associate: patch
Not all of the configuration parameters are reset when switching modes
(ad-hoc, managed, monitor). This patch modifies the driver to call
sw_reset on mode change.
Does your AP use short preamble?: patch
This is a test patch against 1.0.0 to better support short preamble mode
in environments that support it.
Cumulative patchset against 1.0.0: patch
This patchset includes the following changes:
If you have any questions, concerns, etc. please
email
Zhu Yi.
| |||||||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||||||