headers
Ivo van Doorn | 1 Apr 16:01
Picon

[PATCH] rt2x00: Use correct length in descriptor

This fixes an important issue where the incorrect length is being
passed to the descriptor initializor. This incorrect initialization will
cause frames to be send out incorrectly.

Signed-off-by: Ivo van Doorn <IvDoorn@...>

---

diff --git a/drivers/net/wireless/mac80211/rt2x00/rt2500usb.c b/drivers/net/wireless/mac80211/rt2x00/rt2500usb.c
index 187076d..537d0c5 100644
--- a/drivers/net/wireless/mac80211/rt2x00/rt2500usb.c
+++ b/drivers/net/wireless/mac80211/rt2x00/rt2500usb.c
@@ -1555,8 +1555,7 @@ static int rt2500usb_write_tx_data(struct rt2x00_dev *rt2x00dev,

 	skb_push(skb, rt2x00dev->hw->extra_tx_headroom);
 	txd = (struct data_desc*)skb->data;
-	rt2500usb_write_tx_desc(rt2x00dev, txd, ieee80211hdr,
-		skb->len, control);
+	rt2500usb_write_tx_desc(rt2x00dev, txd, ieee80211hdr, length, control);
 	memcpy(&entry->tx_status.control, control, sizeof(*control));
 	entry->skb = skb;

diff --git a/drivers/net/wireless/mac80211/rt2x00/rt73usb.c b/drivers/net/wireless/mac80211/rt2x00/rt73usb.c
index 9c9fbce..7b3b878 100644
--- a/drivers/net/wireless/mac80211/rt2x00/rt73usb.c
+++ b/drivers/net/wireless/mac80211/rt2x00/rt73usb.c
@@ -1714,7 +1714,7 @@ static int rt73usb_write_tx_data(struct rt2x00_dev *rt2x00dev,

 	skb_push(skb, rt2x00dev->hw->extra_tx_headroom);
 	txd = (struct data_desc*)skb->data;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ivo van Doorn | 1 Apr 16:01
Picon

[PATCH] rt2x00: Correctly enable the radio

The DEVICE_ENABLED_RADIO_HW flag was accidently added,
this flag is only used (and set correctly) with the rfkill patch
applied to it.
WIthout the rfkill patch this will only prevent the radio to be
enabled for PCI devices.

Signed-off-by: Ivo van Doorn <IvDoorn@...>

---

diff --git a/drivers/net/wireless/mac80211/rt2x00/rt2400pci.c b/drivers/net/wireless/mac80211/rt2x00/rt2400pci.c
index f8a9867..f296fda 100644
--- a/drivers/net/wireless/mac80211/rt2x00/rt2400pci.c
+++ b/drivers/net/wireless/mac80211/rt2x00/rt2400pci.c
@@ -1228,8 +1228,7 @@ static int rt2400pci_enable_radio(struct rt2x00_dev *rt2x00dev)
 	 * Don't enable the radio twice.
 	 * or if the hardware button has been disabled.
 	 */
-	if (GET_FLAG(rt2x00dev, DEVICE_ENABLED_RADIO) ||
-	    !GET_FLAG(rt2x00dev, DEVICE_ENABLED_RADIO_HW))
+	if (GET_FLAG(rt2x00dev, DEVICE_ENABLED_RADIO))
 		return 0;

 	/*
diff --git a/drivers/net/wireless/mac80211/rt2x00/rt2500pci.c b/drivers/net/wireless/mac80211/rt2x00/rt2500pci.c
index bddbbf9..4fff8db 100644
--- a/drivers/net/wireless/mac80211/rt2x00/rt2500pci.c
+++ b/drivers/net/wireless/mac80211/rt2x00/rt2500pci.c
@@ -1354,8 +1354,7 @@ static int rt2500pci_enable_radio(struct rt2x00_dev *rt2x00dev)
 	 * Don't enable the radio twice,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ivo van Doorn | 1 Apr 16:01
Picon

[PATCH] rt2x00: new USB ID for rt73usb

This will add a new USB ID for the rt73usb driver

Signed-off-by: Ivo van Doorn <IvDoorn@...>

---

diff --git a/drivers/net/wireless/mac80211/rt2x00/rt73usb.c b/drivers/net/wireless/mac80211/rt2x00/rt73usb.c
index 7b3b878..21bb298 100644
--- a/drivers/net/wireless/mac80211/rt2x00/rt73usb.c
+++ b/drivers/net/wireless/mac80211/rt2x00/rt73usb.c
@@ -2938,6 +2938,7 @@ static struct usb_device_id rt73usb_device_table[] = {
 	{ USB_DEVICE(0x1690, 0x0722) },
 	/* ASUS */
 	{ USB_DEVICE(0x0b05, 0x1723) },
+	{ USB_DEVICE(0x0b05, 0x1724) },
 	/* Belkin */
 	{ USB_DEVICE(0x050d, 0x7050) },
 	{ USB_DEVICE(0x050d, 0x705a) },
Permalink | Reply | 0 comments |
headers
Larry Finger | 2 Apr 05:50
Favicon

WPA does not connect to bcm43xx-mac80211 when using NetworkManager


Dan,

My bcm43xx-mac80211 system generates the following log entries when trying to connect using WPA-PSK
TKIP controlled by NetworkManager. The same configuration works with bcm43xx-softmac.

eth1: Initial auth_alg=0
eth1: authenticate with AP 00:14:bf:85:49:fa
eth1: RX authentication from 00:14:bf:85:49:fa (alg=0 transaction=2 status=0)
eth1: authenticated
eth1: associate with AP 00:14:bf:85:49:fa
eth1: RX AssocResp from 00:14:bf:85:49:fa (capab=0x31 status=0 aid=2)
eth1: associated
wmaster0: Added STA 00:14:bf:85:49:fa
eth1: RX deauthentication from 00:14:bf:85:49:fa (reason=15)
eth1: deauthenticated
eth1: set_encrypt - unknown addr 00:00:00:00:00:00
eth1: authenticate with AP 00:14:bf:85:49:fa
eth1: RX authentication from 00:14:bf:85:49:fa (alg=0 transaction=2 status=0)
eth1: authenticated
eth1: associate with AP 00:14:bf:85:49:fa
eth1: RX ReassocResp from 00:14:bf:85:49:fa (capab=0x31 status=0 aid=2)
eth1: associated
eth1: starting scan

It does the original open authentication and associates, but the final WPA authentication times out.

I'm using Michael Buesch's "mb" tree with the "mac80211: use IWEVGENIE" and "mac80211: set enc_capa"
patches by Michael Wu. My distro is openSUSE 10.2 on an x86_64 system.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Dan Williams | 2 Apr 06:12
Picon
Favicon

Re: WPA does not connect to bcm43xx-mac80211 when using NetworkManager

On Sun, 2007-04-01 at 22:50 -0500, Larry Finger wrote:
> Dan,
> 
> My bcm43xx-mac80211 system generates the following log entries when trying to connect using WPA-PSK
> TKIP controlled by NetworkManager. The same configuration works with bcm43xx-softmac.

So what you're saying here is that NM works with softmac, but doesn't
work with mac80211?

> eth1: Initial auth_alg=0
> eth1: authenticate with AP 00:14:bf:85:49:fa
> eth1: RX authentication from 00:14:bf:85:49:fa (alg=0 transaction=2 status=0)
> eth1: authenticated
> eth1: associate with AP 00:14:bf:85:49:fa
> eth1: RX AssocResp from 00:14:bf:85:49:fa (capab=0x31 status=0 aid=2)
> eth1: associated
> wmaster0: Added STA 00:14:bf:85:49:fa
> eth1: RX deauthentication from 00:14:bf:85:49:fa (reason=15)
> eth1: deauthenticated
> eth1: set_encrypt - unknown addr 00:00:00:00:00:00
> eth1: authenticate with AP 00:14:bf:85:49:fa
> eth1: RX authentication from 00:14:bf:85:49:fa (alg=0 transaction=2 status=0)
> eth1: authenticated
> eth1: associate with AP 00:14:bf:85:49:fa
> eth1: RX ReassocResp from 00:14:bf:85:49:fa (capab=0x31 status=0 aid=2)
> eth1: associated
> eth1: starting scan
> 
> It does the original open authentication and associates, but the final WPA authentication times out.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Michael Wu | 2 Apr 07:26

Re: WPA does not connect to bcm43xx-mac80211 when using NetworkManager

On Sunday 01 April 2007 23:50, Larry Finger wrote:
> I'm using Michael Buesch's "mb" tree with the "mac80211: use IWEVGENIE" and
> "mac80211: set enc_capa" patches by Michael Wu. My distro is openSUSE 10.2
> on an x86_64 system.
>
I had a similar (probably same) issue but it doesn't seem to happen as much 
now. If you're using the tree from 
http://bu3sch.de/gitweb?p=wireless-dev.git;a=summary - that does not contain 
a number of very useful patches from Jiri's tree which are currently in 
Linville's wireless-dev. Please try with the patches from Linville's tree.

If it continues to occur, try unloading the module (bcm43xx_mac80211) and 
loading it again as a workaround. If that works, we most likely are seeing 
the same issue. I also recommend updating wpa_supplicant (SuSE 10.2 ships 
with 0.4.9 IIRC, I test with 0.5.7) but that probably doesn't matter much.

-Michael Wu
Permalink | Reply | 0 comments |
headers
Dan Williams | 2 Apr 15:47
Picon
Favicon

SIOCSIWAP behavior question

Should setting a BSSID trigger a disconnection event from the driver?
Obviously a disconnect event shouldn't be triggered if the BSSID being
set is the same BSSID the card is already associated with.  Or does that
mean "reassociate unconditionally" ?

But suppose we have two APs in the same ESS with obviously different
BSSIDs.  The card automatically associates with one BSSID, but
wpa_supplicant decides it likes the other BSSID and calls SIOCSIWAP to
lock to that one during the association process.  Should the driver
issue an IWAP event of 00:00:00:00:00:00 before attempting
re-association with the BSSID that wpa_supplicant wants?

The libertas driver currently does this; it sometimes confuses
wpa_supplicant and is arguably wrong behavior because drivers don't
issue disconnection events when auto-roaming from BSSID to BSSID in the
same ESS.

Conversely, if you have two access points 'linksys' with different
BSSIDs that really _are_ two different ESSs, this would screw up
userspace tools if a disconnect _wasn't_ sent.  But in this case
automatic tools have more problems than driver events.

Thoughts?  I guess I vote for not sending disconnect events if that
BSSID has the same capabilities and the same SSID as the current
association BSS.

Dan
Permalink | Reply | 7 comments |
headers
Dan Williams | 2 Apr 15:55
Picon
Favicon

Re: SIOCSIWAP behavior question

On Mon, 2007-04-02 at 09:47 -0400, Dan Williams wrote:
> Should setting a BSSID trigger a disconnection event from the driver?

Hmm; badly phrased question.  I really meant:

Should setting a BSSID _always_ trigger a disconnection event from the
driver?

> Obviously a disconnect event shouldn't be triggered if the BSSID being
> set is the same BSSID the card is already associated with.  Or does that
> mean "reassociate unconditionally" ?
> 
> But suppose we have two APs in the same ESS with obviously different
> BSSIDs.  The card automatically associates with one BSSID, but
> wpa_supplicant decides it likes the other BSSID and calls SIOCSIWAP to
> lock to that one during the association process.  Should the driver
> issue an IWAP event of 00:00:00:00:00:00 before attempting
> re-association with the BSSID that wpa_supplicant wants?
> 
> The libertas driver currently does this; it sometimes confuses
> wpa_supplicant and is arguably wrong behavior because drivers don't
> issue disconnection events when auto-roaming from BSSID to BSSID in the
> same ESS.
> 
> Conversely, if you have two access points 'linksys' with different
> BSSIDs that really _are_ two different ESSs, this would screw up
> userspace tools if a disconnect _wasn't_ sent.  But in this case
> automatic tools have more problems than driver events.
> 
> Thoughts?  I guess I vote for not sending disconnect events if that
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jouni Malinen | 2 Apr 17:54

Re: SIOCSIWAP behavior question

On Mon, Apr 02, 2007 at 09:47:35AM -0400, Dan Williams wrote:
> Should setting a BSSID trigger a disconnection event from the driver?

Just the act of setting BSSID? No.

> Obviously a disconnect event shouldn't be triggered if the BSSID being
> set is the same BSSID the card is already associated with.  Or does that
> mean "reassociate unconditionally" ?

I would ike to see disconnect event only if the driver/stack notices
that it cannot complete association and based on this, believes its
association to the ESS is lost.

> But suppose we have two APs in the same ESS with obviously different
> BSSIDs.  The card automatically associates with one BSSID, but
> wpa_supplicant decides it likes the other BSSID and calls SIOCSIWAP to
> lock to that one during the association process.  Should the driver
> issue an IWAP event of 00:00:00:00:00:00 before attempting
> re-association with the BSSID that wpa_supplicant wants?

I would not like to see this. I see this as re-association within the
same ESS and the driver/stack should just report the new BSSID after
successful re-association. The exact same behavior should apply here
regardless of whether BSSID was set (sort of forced re-association) or
not (driver/stack re-associating, e.g., due to signal strength
difference).

> The libertas driver currently does this; it sometimes confuses
> wpa_supplicant and is arguably wrong behavior because drivers don't
> issue disconnection events when auto-roaming from BSSID to BSSID in the
(Continue reading)

Permalink | Reply | 2 comments |
headers
Johannes Berg | 2 Apr 12:06
Favicon

Re: [PATCH 2.6] WE-22 : prevent information leak on 64 bit


> 	Johannes Berg discovered that kernel space was leaking to
> userspace on 64 bit platform. He made a first patch to fix that. This
> is an improved version of his patch.
> 	This was tested on 2.6.21-rc4. Would you mind pushing that
> upstream ?

Just FYI. This patch applies with rejects in net/core/rtnetlink.c and
net/core/wireless.c to wireless-dev. The changes in those two files can
be ignored completely since they affect only the removed
wext-over-netlink interface.

johannes
Permalink | Reply | 14 comments |

Gmane