
Intel(R) PRO/Wireless 3945ABG Network Connection driver for Linux* in 
support of:

Intel(R) PRO/Wireless 3945ABG Network Connection Adapter
Intel(R) PRO/Wireless 3945BG Network Connection Adapter

Copyright (C) 2005 - 2006, Intel Corporation

ISSUES

Version: 1.1.2
Date   : November 01, 2006
------------------------------

The following are the most common issues reported by users at the time of
this release.  

Additional details may be found at http://bughost.org by entering in the bug
number referenced.

Issues summarized below:

1. Strongest AP is not always selected for association
2. IEEE 802.11b transmit is faster than receive at lower signal levels
3. Cannot associate with open networks using LEAP authentication
4. Cannot associate with access points set to only support a single OFDM rate
5. Kernel panic while transferring large amounts of data
6. Configuring PSP mode while in an ad-hoc network results in packet loss
7. Scanned access points count is smaller while associated
8. iwspy threshold events are not triggered
9. Problems obtaining a DHCP lease with some dhcp client/server combinations
10. Cannot use WPA with EAP with older wpa_supplicant versions
11. Problems with WPA with AES and fragmentation 
12. Problem obtaining an IRQ (driver does not responsd) if ACPI disabled.
13. Problem with some wireless commands on 64-bit systems
14. Problem finding new network to associate with while currently associated.
15. Occassional microcode restarts / errors reported in kernel log
16. Hidden networks in 5.2Ghz band (IEEE 802.11a) may not work
17. Error loading ipw3945 module -- unknown symbols.

Issue summaries:

1. Strongest AP is not always selected for association

There is a bug in the ieee80211 subsystem available in the Linux kernel that
can cause the AP selection logic to not pick the strongest access point.  If
you know a specific network has a better signal than the one you are 
associated with, you can force the driver to use that access point by using
the iwconfig's 'ap' command (see the iwconfig man page)

This issue is fixed if you upgrade to a kernel containing the ieee80211
subsystem version 1.1.13 or newer.

http://bughost.org/bugzilla/show_bug.cgi?id=958


2. IEEE 802.11b transmit is faster than receive at lower signal levels

If you are using an 802.11b wireless network, you may notice that as the 
signal level of the network associated with decreases, the driver's
ability to receive TCP data decreases faster than the ability to transmit
TCP data. In high signal levels and closer proximity to the access point,
data rates are as expected.  

http://bughost.org/bugzilla/show_bug.cgi?id=959


3. Cannot associate with open networks using LEAP authentication

If your wireless network is configured to use no encryption, but does use
LEAP authentication, you may not be able to associate with it.  To work 
around this problem, configure a static WEP key on your access point and
configure the same WEP key on the client.

http://bughost.org/bugzilla/show_bug.cgi?id=1077


4. Cannot associate with access points set to only support a single OFDM rate

If your access point is configured to only support a single OFDM receive
data rate, you may not be able to associate with it. To work around this issue,
configure your AP to use more than one OFDM (802.11G) data rate.

http://bughost.org/bugzilla/show_bug.cgi?id=961


5. Kernel panic while transferring large amounts of data

We have had one report of a kernel panic during file transfers.  While we
have not been able to reproduce the failure, we are documenting it here.
We are currently investigating the issue.  If you experience any kernel
panics or crashes, please see the bug referenced below; and provide any
information related to your specific issues; information that you may have
could help in resolving the issue.

There is currently no known workaround.  The problem has reportedly only 
impacted one user to date.

http://bughost.org/bugzilla/show_bug.cgi?id=931


6. Configuring PSP mode while in an ad-hoc network results in packet loss

If you configure the system to use PSP (via iwpriv set_power) while in
an ad-hoc network, you will experience significant packet loss in the
network.

The workaround is to not use PSP mode in an ad-hoc network.

http://bughost.org/bugzilla/show_bug.cgi?id=968


7. Scanned access points count is smaller while associated

While associated, scanning may not find as many access points as reliably
as scanning while not associated.  This is a result of the amount of time
that can be spent out of the associated channel without disrupting the
current association.  Scan information defaults to expiring if a network
does not receive a beacon or probe response within 15 seconds.

Workaround: Try scanning, then wait a second or two, and then scan again.
The second and subsequent scans should collect more of the scan data that
may have been missed in the first scan.  You can also increase the default
maximum scan age by specifying the maximum age of a network in milliseconds
to the sysfs entry 'scan_age'.  See README.ipw3945 for more information.

http://bughost.org/bugzilla/show_bug.cgi?id=965


8. iwspy threshold events are not triggered

If you configure a threshold event based on signal level, that event may
not be triggered when the threshold is crossed.   

This issue is fixed if you upgrade to a kernel containing the ieee80211
subsystem version 1.1.13 or newer.

http://bughost.org/bugzilla/show_bug.cgi?id=966


9. Problems obtaining a DHCP lease with some dhcp client/server combinations

Some dhcp clients have problems in communicating with specific dhcp
servers while obtaining frequent and renewed leases.  If your dhcp client
stalls while trying to obtain an IP address and you are associated to a 
valid network (with the correct WEP key if appropriate), you can try the
following workaround:

  1.  Kill any current instances of your dhcp client:
	% killall dhclient || killall dhdpcd
	% rm /var/run/{dhcpcd,dhclient}*pid
  2.  Remove any cached lease files
	See the man page for your dhcp client to determine which files
	these are.  It is usually one of the following:
	% rm /var/run/cache/dhcpcd-* 
	% rm /var/lib/dhcp/dhclient*leases
  3.  Restart the dhcp client
	% dhclient eth1 || dhcpcd eth1


10. Cannot use WPA with EAP with older wpa_supplicant versions

Users have reported problems using older (0.3.x) versions of 
wpa_supplicant with various authentication modes (WPA PSK, etc.).  
If you experience problems using wpa_supplicant, please upgrade to the 
latest version of the supplicant (0.4.6 or newer)


11. Problems with WPA with AES and fragmentation 

In some configurations, setting fragmentation on client results in 
AES not functioning.  If you experience this behavior, please try
with fragmentation disabled or check with your AP manufacturer for 
a firmware upgrade.


12. Problem obtaining an IRQ (driver does not responsd) if ACPI disabled.

Some laptops may have a problem with their BIOS in conjunction with 
Linux such that if ACPI is disabled (via acpi=off on the kernel command 
line or by not compiling it into the kernel), the driver will not be 
able to correctly obtain an IRQ needed to operate the device.

The current workaround is to ensure ACPI (CONFIG_ACPI) is enabled in 
the kernel and that 'acpi=off' is not provided as a kernel command line 
argument.


13. Problem with some wireless commands on 64-bit systems

Due to an issue in handling 64-bit integers in the v28 based versions of 
the wireless tools, we recommend that only wireless tools based on v29 be 
used on 64-bit platforms.


14. Problem finding new network to associate with while currently associated.

This issue is related to the issue of having a smaller list of access points 
reported during a scan while associated vs. not associated.  While associated, 
the driver can not leave the associatd channel for very long or it will lose
beacons / data.  This places a restriction on how long the driver can dwell
on a channel waiting for a beacon from a new network.

If you are trying to move to a new network, especially one with ssid 
broadcast disabled (hidden network), while associated you may experience
this problem.

The current workaround is to disassociate from the active network by 
issuing the command 'iwconfig essid off'

http://bughost.org/bugzilla/show_bug.cgi?id=1024


15. Occassional microcode restarts / errors reported in kernel log

Some users have reported seeing microcode restarts under varying environmental
conditions.  We are investigating this issue.  A symptom of this problem is 
recurring loss of association combined with messages in the kernel log about 
a Microcode SW error.  If you experience this behavior, please check the 
detailed bug information at bughost.org.

http://bughost.org/bugzilla/show_bug.cgi?id=1085
and
http://bughost.org/bugzilla/show_bug.cgi?id=1066


16. Hidden networks in 5.2Ghz band (IEEE 802.11a) may not work

If your network utilizes a hidden network SSID and resides in the 5.2Ghz band,
the driver may not be able to associate with it.  

A workaround is to restrict the client to operating solely in the 5.2Ghz band
via 'iwpriv eth1 set_mode 1'.

http://bughost.org/bugzilla/show_bug.cgi?id=972


17. Error loading ipw3945 module -- unknown symbols.

Due to the differences between all of the various distributions and build 
environments in the community, you may end up in a situation where loading 
the ipw3945.ko module does not work (even after perfectly following the steps 
in the INSTALL document).  The most common error seen is:

   Error inserting ipw3945.ko: -1 Unknown symbol in module.

The issue is likely being caused by an ieee80211 subsystem existing in your
distribution's kernel that is out of sync with the ieee80211 subsystem you have
attempted to install per the INSTALL steps.

We recommend checking the web forums for your distribution, the 
http://ieee80211.sf.net web page, and the http://ipw3945.sf.net web page for 
tips or links to information on working through this situation.

http://bughost.org/bugzilla/show_bug.cgi?id=1056


------------------------------
Copyright (C) 2005 - 2006, Intel Corporation

INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH INTEL PRODUCTS.  
EXCEPT AS PROVIDED IN INTEL'S TERMS AND CONDITIONS OF SALE FOR SUCH PRODUCTS, 
INTEL ASSUMES NO LIABILITY WHATSOEVER, AND INTEL DISCLAIMS ANY EXPRESS OR 
IMPLIED WARRANTY RELATING TO SALE AND/OR USE OF INTEL PRODUCTS, INCLUDING 
LIABILITY OR WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, 
MERCHANTABILITY, OR INFRINGEMENT OF ANY PATENT, COPYRIGHT, OR OTHER 
INTELLECTUAL PROPERTY RIGHT. 

This document is subject to change without notice. 

* Other names and brands may be claimed as the property of others.

