configured.
Countermeasures default to being turned off when wpa_supplicant runs,
regardless of if TKIP is being used. They are only turned on if a TKIP
is running. The warning we were printing is therefore not needed.
Signed-off-by: James Ketrenos <jketreno@linux.intel.com>
Wireless extensions moved the get_wireless_stats handler from being
in net_device into wireless_handler.
Signed-off-by: Benoit Boissinot <benoit.boissinot@ens-lyon.org>
Signed-off-by: James Ketrenos <jketreno@linux.intel.com>
The problem is caused by the patch in bug455 -- Channel change flood
generates fatal error.
The patch set the DISASSOCIATING status bit after sending the command.
The process was scheduled out when waiting for the command to be sent to
the card. The disassociated notification clears the DISASSOCIATING bit
in the tasklet before the process set the bit.
Move the bit setting code before sending the command now.
Signed-off-by: Hong Liu <hong.liu@intel.com>
Signed-off-by: James Ketrenos <jketreno@linux.intel.com>
The PF_SYNCTHREAD check was introduced to try and remain compatible with
SWSUSP2. This check is no longer needed with newer versions.
Signed-off-by: James Ketrenos <jketreno@linux.intel.com>
error when it tries to auth to a WPA ap. The patch filters out WPA
networks if the card is not wpa enabled when selecting network to
associate to.
Signed-off-by: Hong Liu <hong.liu@intel.com>
Because of the frequent channel change, it is possible that when we are
try to associate with channel 1 (authenticated but not associated).
Another channel change comes at this time, then the driver will issue
disassociate command to the firmware which will cause the fatal error.
It seems that the association/disassociation procedure should not be
interrupted.
The patch attached adds test on STATUS_ASSOCIATING | STATUS_DISASSOCIATING
in ipw_send_cmd(), when ensures that commands will not be sent to firmware
when we are in these two status.
Signed-off-by: Hong Liu <hong.liu@intel.com>
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
(handle_probe_response, handle_beacon, handle_association_response).
Fixed a problem with ipw_send_cmd() returning non-zero on success.
Signed-off-by: James Ketrenos <jketreno@linux.intel.com>
You can now specify via the module parameter 'cmdlog' to allocate a
ring buffer for caching host commands sent to the firmware. They can
then be dumped at any time via the sysfs entry 'cmd_log'
Signed-off-by: James Ketrenos <jketreno@linux.intel.com>
codes to the caller and changed ipw_send_cmd itself to print the error
message to the syslog indicating which command failed to be sent.
Signed-off-by: James Ketrenos <jketreno@linux.intel.com>
via sysfs even if debugging disabled. When a firmware error is
captured, it will be dumped to the kernel log (if debug enabled) and
captured in memory to be retrieved via sysfs.
If an error has already been captured, subsequent errors will be
dropped.
The existing error can be cleared by writing to the error log entry.
Signed-off-by: James Ketrenos <jketreno@linux.intel.com>
with request_scan being called before initialized if invoked from
insmod, resulting in no association occurring during boot until iwlist
scan is run.
Signed-off-by: James Ketrenos <jketreno@linux.intel.com>
If we configure the wep keys after creating the ibss network, the
beacons of this network will not show correctly (it still shows "key
off" in iwlist scan report). This is because we don't update the
beacon info in firmware.
Signed-off-by: Hong Liu <hong.liu@intel.com>
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
iwconfig matches what their hardware can actually do in regard to
supported channel maps, etc.
Signed-off-by: James Ketrenos <jketreno@linux.intel.com>
We send SYSTEM_CONFIG command after the TGI_KEY command if hardware
encryption is enabled. It sometimes causes a firmware stall (firmware
doesn't respond to any request) and finally bungs up the Tx send queue.
The solution is to send SYSTEM_CONFIG command in the post association
stage from a workqueue.
Signed-off-by: James Ketrenos <jketreno@linux.intel.com>
* Fixed#452 problem with setting retry limit (thanks to Hong Liu)
* Fixed#592 race condition during association causing firmware errors
* Fixed#602 problem with building in 64-bit environment
* Fixed#625 problem with SCAN_REQUEST_EXT sometimes failing
* Fixed#645 problem with bit rate not decreasing when moving laptop
farther from AP
* Fixed#656 problem with 'iwconfig eth1 mode auto' and 'modprobe'
locking the system
* Fixed#667 problem with "No space for Tx" for hwcrypto=1
* Fixed#685 kernel panic in rmmod caused by led work is still queued
* Fixed#695 problem with network doesn't reassociate after suspend/resume
* Fixed#701 problem with 'iwprvi sw_reset' not resetting the card from
monitor mode
* Fixed#710 problem with monitor mode being used after a WEP key has
been configured
* Fixed network->mode vs. priv->ieee->iw_mode checking (thanks to Ben Cahill)
* Fixed "Unknown management packet %d" warning
* Fixed setting channels multiple times in monitor mode causes scan stopped
* Fixed ipw_wx_sw_reset doesn't switch firmware if mode is changed.
* Add duplicate packet checking code (kill ping DUP! and TKIP replay warning)
* Fix hardware encryption (both WEP and AES) doesn't work with fragmentation.
Signed-off-by: James Ketrenos <jketreno@linux.intel.com>
support wpa_supplicant with open AP. We need this to make driver_ipw
work.
driver_ext has already had the similar code with the WE-18 support
added.
Signed-off-by: James Ketrenos <jketreno@linux.intel.com>
* Added WE-18 support. This allows the use of -Dext with wpa_supplicant
> 0.4.x (thanks to Hong Liu)
* Fixed#339 problem with iwconfig set/get txpower (thanks to Hong Liu)
* Fixed#598 problem when with error messages when module loaded with
'disable=1' (thanks to Hong Liu)
* Fixed#640 problem with 'iwlist retry' now showing min/max retry
* Fixed compatibility with wpa_supplicant and the new -Dipw interface
(that included a fix for 64-bit compatibility)
* Added CFG_CRC_CHECK which allows passing through packets with bad
CRCs while in monitor mode.
Signed-off-by: James Ketrenos <jketreno@linux.intel.com>
