headers
=?gb2312?q?=CD=F5=ABh?= | 8 Oct 06:16

hostap0.6.4 + ath5k

Hi,all
I deployed hostap0.6.4 + ath5k, and got 2 problems.

My env is: kernel 2.6.26, hostap 0.6.4
compat-wireless-old-2008-10-06.tar.bz2
libnl-1.0-pre8.tar.tar

1. when make wireless souce tree, there are several
WARNINGs:
  Building modules, stage 2.

  MODPOST 39 modules
WARNING: "ieee80211_hdrlen"
[/home/wangyue/VLAN_WPA_ath5k/compat-wireless-2.6-old/drivers/net/wireless/iwlwifi/iwlcore.ko]
undefined!
WARNING: "ieee80211_hdrlen"
[/home/wangyue/VLAN_WPA_ath5k/compat-wireless-2.6-old/drivers/net/wireless/iwlwifi/iwl3945.ko]
undefined!
WARNING: "ieee80211_hdrlen"
[/home/wangyue/VLAN_WPA_ath5k/compat-wireless-2.6-old/drivers/net/wireless/b43legacy/b43legacy.ko]
undefined!
WARNING: "ieee80211_hdrlen"
[/home/wangyue/VLAN_WPA_ath5k/compat-wireless-2.6-old/drivers/net/wireless/b43/b43.ko]
undefined!
WARNING: "ieee80211_hdrlen"
[/home/wangyue/VLAN_WPA_ath5k/compat-wireless-2.6-old/drivers/net/wireless/ath5k/ath5k.ko]
undefined!
WARNING: "ieee80211_hdrlen"
[/home/wangyue/VLAN_WPA_ath5k/compat-wireless-2.6-old/drivers/net/wireless/adm8211.ko]
undefined!
(Continue reading)

Permalink | Reply | 0 comments |
headers
Zhu Yi | 8 Oct 03:33

[PATCH 1/4 V2] iwlwifi: make initial calibration set configurable

From: Tomas Winkler <tomas.winkler@...>

This patch adds ability to configure initial calibration set. Not all HW
supported by iwlwifi use the same calibration set, XTAL is one example.
Some clean ups are also included in this patch.

Signed-off-by: Tomas Winkler <tomas.winkler@...>
Signed-off-by: Zhu Yi <yi.zhu@...>
---
 drivers/net/wireless/iwlwifi/iwl-5000-hw.h  |    1 +
 drivers/net/wireless/iwlwifi/iwl-5000.c     |   44 +++++++++++++++++---------
 drivers/net/wireless/iwlwifi/iwl-calib.c    |    8 +++--
 drivers/net/wireless/iwlwifi/iwl-commands.h |   27 +++++++----------
 drivers/net/wireless/iwlwifi/iwl-dev.h      |    4 ++-
 5 files changed, 49 insertions(+), 35 deletions(-)

diff --git a/drivers/net/wireless/iwlwifi/iwl-5000-hw.h b/drivers/net/wireless/iwlwifi/iwl-5000-hw.h
index c479ee2..66ed993 100644
--- a/drivers/net/wireless/iwlwifi/iwl-5000-hw.h
+++ b/drivers/net/wireless/iwlwifi/iwl-5000-hw.h
@@ -132,6 +132,7 @@ struct iwl5000_shared {
 /* calibrations defined for 5000 */
 /* defines the order in which results should be sent to the runtime uCode */
 enum iwl5000_calib {
+	IWL5000_CALIB_XTAL,
 	IWL5000_CALIB_LO,
 	IWL5000_CALIB_TX_IQ,
 	IWL5000_CALIB_TX_IQ_PERD,
diff --git a/drivers/net/wireless/iwlwifi/iwl-5000.c b/drivers/net/wireless/iwlwifi/iwl-5000.c
index f6003e7..ba92667 100644
(Continue reading)

Permalink | Reply | 3 comments |
headers
Leo L. Schwab | 7 Oct 23:26

compat-wireless-2.6-old: Can't Load Modules

	When I tried the latest (last night's) version of
compat-wireless-2.6-old on my 2.6.26 Debian laptop, I got the following
error messages when I tried to 'modprobe iwl3945":

Oct  7 02:20:14 walkies kernel: cfg80211: exports duplicate symbol rfkill_force_state (owned by rfkill)

	Once that happened, there were a series of cascading failures:

Oct  7 02:20:14 walkies kernel: mac80211: Unknown symbol wiphy_register
Oct  7 02:20:14 walkies kernel: mac80211: Unknown symbol wiphy_new
Oct  7 02:20:14 walkies kernel: mac80211: Unknown symbol wiphy_unregister
Oct  7 02:20:14 walkies kernel: mac80211: Unknown symbol ieee80211_radiotap_iterator_init
Oct  7 02:20:14 walkies kernel: mac80211: Unknown symbol __ieee80211_get_channel
Oct  7 02:20:14 walkies kernel: mac80211: Unknown symbol ieee80211_radiotap_iterator_next
Oct  7 02:20:14 walkies kernel: mac80211: Unknown symbol ieee80211_channel_to_frequency
Oct  7 02:20:14 walkies kernel: mac80211: Unknown symbol ieee80211_frequency_to_channel
Oct  7 02:20:14 walkies kernel: mac80211: Unknown symbol wiphy_free
Oct  7 02:20:14 walkies kernel: iwl3945: Unknown symbol ieee80211_free_hw
Oct  7 02:20:14 walkies kernel: iwl3945: Unknown symbol ieee80211_alloc_hw
Oct  7 02:20:14 walkies kernel: iwl3945: Unknown symbol ieee80211_notify_mac
Oct  7 02:20:14 walkies kernel: iwl3945: Unknown symbol ieee80211_register_hw
Oct  7 02:20:14 walkies kernel: iwl3945: Unknown symbol ieee80211_rate_control_unregister
Oct  7 02:20:14 walkies kernel: iwl3945: Unknown symbol __ieee80211_get_radio_led_name
Oct  7 02:20:14 walkies kernel: iwl3945: Unknown symbol ieee80211_wake_queue
Oct  7 02:20:14 walkies kernel: iwl3945: Unknown symbol __ieee80211_get_tx_led_name
Oct  7 02:20:14 walkies kernel: iwl3945: Unknown symbol ieee80211_tx_status_irqsafe
Oct  7 02:20:14 walkies kernel: iwl3945: Unknown symbol __ieee80211_get_rx_led_name
Oct  7 02:20:14 walkies kernel: iwl3945: Unknown symbol ieee80211_wake_queues
Oct  7 02:20:14 walkies kernel: iwl3945: Unknown symbol ieee80211_rate_control_register
Oct  7 02:20:14 walkies kernel: iwl3945: Unknown symbol sta_info_get
(Continue reading)

Permalink | Reply | 0 comments |
headers
John W. Linville | 7 Oct 21:14

[RFC PATCH] rtl8187: do not report ACKs if USB Tx status is non-zero

The vendor-supplied driver treats a USB Tx failure as an un-ACKed frame.
I don't see why we shouldn't do the same thing -- hopefully this makes
rate-scaling algorithms behave sanely with the rtl8187 driver.

Thanks to Felix Fietkau <nbd@...> for suggesting this as an
option.

Signed-off-by: John W. Linville <linville@...>
---
This is currently untested -- anyone with rtl8187 bored enough to try
it? :-)

 drivers/net/wireless/rtl8187_dev.c |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/drivers/net/wireless/rtl8187_dev.c b/drivers/net/wireless/rtl8187_dev.c
index ca5deb6..ae21191 100644
--- a/drivers/net/wireless/rtl8187_dev.c
+++ b/drivers/net/wireless/rtl8187_dev.c
@@ -164,7 +164,12 @@ static void rtl8187_tx_cb(struct urb *urb)
 	skb_pull(skb, priv->is_rtl8187b ? sizeof(struct rtl8187b_tx_hdr) :
 					  sizeof(struct rtl8187_tx_hdr));
 	memset(&info->status, 0, sizeof(info->status));
-	info->flags |= IEEE80211_TX_STAT_ACK;
+	if (!(info->flags & IEEE80211_TX_CTL_NO_ACK)) {
+		if (!urb->status)
+			info->flags |= IEEE80211_TX_STAT_ACK;
+		else /* assume ACK not received */
+			info->status.excessive_retries = 1;
+	}
(Continue reading)

Permalink | Reply | 0 comments |
headers
John W. Linville | 7 Oct 21:31

[PATCH] rtl8180: normalize quality measurment for 100-point scale

Otherwise, we get values like "133/100" for quality output from
iwconfig. :-(

Signed-off-by: John W. Linville <linville@...>
---
This is currently untested, but it seems reasonable to me...any takers?  :-)

 drivers/net/wireless/rtl8180_dev.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/wireless/rtl8180_dev.c b/drivers/net/wireless/rtl8180_dev.c
index b7172a1..e9edcaa 100644
--- a/drivers/net/wireless/rtl8180_dev.c
+++ b/drivers/net/wireless/rtl8180_dev.c
@@ -132,7 +132,7 @@ static void rtl8180_handle_rx(struct ieee80211_hw *dev)

 			rx_status.antenna = (flags2 >> 15) & 1;
 			/* TODO: improve signal/rssi reporting */
-			rx_status.qual = flags2 & 0xFF;
+			rx_status.qual = ((flags2 & 0xFF) * 100) / 256;
 			rx_status.signal = (flags2 >> 8) & 0x7F;
 			/* XXX: is this correct? */
 			rx_status.rate_idx = (flags >> 20) & 0xF;
--

-- 
1.5.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
Johannes Berg | 7 Oct 20:14

wpa supplicant interface up delay

                         * Wait some time to allow driver to initialize before
                         * starting configuring the driver. This seems to be  
                         * needed at least some drivers that load firmware etc.
                         * when the interface is set up.

which drivers are those, and why can't we fix the drivers instead? This
seems like a bug in the drivers that they return from their open
callback prematurely.

johannes
Permalink | Reply | 3 comments |
headers
Johannes Berg | 7 Oct 19:27

[PATCH] mac80211: fix HT information element parsing

There's no checking that the HT IEs are of the right length
which can be used by an attacker to cause an out-of-bounds
access by sending a too short HT information/capability IE.
Fix it by simply pretending those IEs didn't exist when too
short.

Signed-off-by: Johannes Berg <johannes@...>
---
 net/mac80211/ieee80211_i.h |    6 ++----
 net/mac80211/mlme.c        |    3 ---
 net/mac80211/util.c        |    8 ++++----
 3 files changed, 6 insertions(+), 11 deletions(-)

--- everything.orig/net/mac80211/ieee80211_i.h	2008-10-07 16:52:04.000000000 +0200
+++ everything/net/mac80211/ieee80211_i.h	2008-10-07 16:53:04.000000000 +0200
@@ -816,8 +816,8 @@ struct ieee802_11_elems {
 	u8 *ext_supp_rates;
 	u8 *wmm_info;
 	u8 *wmm_param;
-	u8 *ht_cap_elem;
-	u8 *ht_info_elem;
+	struct ieee80211_ht_cap *ht_cap_elem;
+	struct ieee80211_ht_addt_info *ht_info_elem;
 	u8 *mesh_config;
 	u8 *mesh_id;
 	u8 *peer_link;
@@ -844,8 +844,6 @@ struct ieee802_11_elems {
 	u8 ext_supp_rates_len;
 	u8 wmm_info_len;
 	u8 wmm_param_len;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Johannes Berg | 7 Oct 18:57

mac80211 driver API

Hi,

Another thing I noticed when looking at the short slot stuff is that a
number of drivers do not use the use_short_preamble flag but also do not
set IEEE80211_HW_2GHZ_SHORT_PREAMBLE_INCAPABLE; this seems like a bug
affecting at least b43legacy, ath5k, at76_usb, rtl8180, rtl8187.

You should review the mac80211 driver API for things you aren't using
but should be using, this affects a number of drivers, for example
adm8211, p54, stlc45xx, ath5k, ath9k, libertas_tf, rtl8180, rtl8187
don't use radio_enabled; a number of drivers don't use power_level.

There are also still drivers (ath5k, adm8211, rtl8180, iwlwifi,
libertas_tf, zd1211rw, mac80211_hwsim, ...?) not using the
IEEE80211_TX_CTL_ASSIGN_SEQ flag, I can fix those since I broke them,
but help from the authors would be appreciated since I don't know the hw
in all cases, I know that stlc45xx for example can use a corresponding
firmware flag for it.

Do we need a document that indicates which parts of the API must be
implemented? Or should we mark such things in mac80211.h? Would
something like this help? I've thrown this together quickly so it
probably isn't complete yet...

A driver must (alternatives in order of preference)
 * either honour the IEEE80211_TX_CTL_USE_RTS_CTS flag
   or implement the set_rts_threshold call
 * either honour the IEEE80211_TX_CTL_USE_CTS_PROTECT flag
   or honour bss_conf's use_cts_prot value
 * either honour IEEE80211_TX_CTL_SHORT_PREAMBLE
(Continue reading)

Permalink | Reply | 2 comments |
headers
Johannes Berg | 7 Oct 11:04

mac80211 and IEEE80211_CONF_SHORT_SLOT_TIME

Hi,

I just realised that for whatever reason mac80211 isn't setting the
IEEE80211_CONF_SHORT_SLOT_TIME flag. I'm not sure when or why that was
removed, but clearly it isn't used.

Can you please fix the drivers using it (b43, b43legacy, iwlwifi, p54,
rt2x00, rtl8180, rtl8187) to use the bss_conf's use_short_slot instead?
I'll fix mac80211 to set that appropriately.

johannes
Permalink | Reply | 4 comments |
headers
Johannes Berg | 7 Oct 12:03

[PATCH 0/8] mac80211 fixes/cleanups/updates

Here are a few mac80211 patches.

johannes

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 10 comments |
headers
Larry Finger | 7 Oct 17:23

[PATCH] p54: Fix compilation problem on PPC

The commit entitled "p54: Fix sparse warnings" introduced a compile
error on PPC architecture. Thanks to Johannes Berg
<johannes@...> for reporting this problem.

Signed-off-by: <Larry.Finger@...>
---

John,

This is 2.6.28 material. I hope this comes through OK. I don't have
access to my usual way of submitting patches.

Larry
---

Johannes,

Do you have access to a p54 device, or were you just compile testing?
In my mind, there is still a big question regarding the endianness of
one of the data arrays.

Larry
---

Index: wireless-testing/drivers/net/wireless/p54/p54common.c
===================================================================
--- wireless-testing.orig/drivers/net/wireless/p54/p54common.c
+++ wireless-testing/drivers/net/wireless/p54/p54common.c
@@ -482,7 +482,6 @@ static int p54_parse_eeprom(struct ieee8
 	printk(KERN_ERR "p54: eeprom parse failed!\n");
(Continue reading)

Permalink | Reply | 3 comments |

Gmane