headers
Johannes Berg | 1 Sep 01:40
Favicon

Re: [PATCH 2/3] mac80211: revamp key handling

On Fri, 2007-08-31 at 15:03 +0200, Michael Buesch wrote:

> I am sorry. I introduced this as I didn't understand my own weird code anymore. :)
> I think I'll fix this by using the hw_key_idx.

Well, I made it buggy :)

I noticed another thing: The code there sets the "default keys valid"
bit depending on WEP or not, while the v3 specs may say that it's a
weird thing to do. I suggest setting the "default keys valid" bit in STA
mode when group keys are configured and clearing it in AP mode; that
way, in AP mode, the four group key slots can also be used for the
transmit-only keys that have zeroed MAC addresses.

johannes
Permalink | Reply | 0 comments |
headers
David Woodhouse | 1 Sep 01:55
Favicon

Re: b43legacy woes

On Fri, 2007-08-31 at 17:26 -0500, Larry Finger wrote:
> The poor performance of the BCM4306/2 (your chip/card) is known. There has been a report that this 
> is a regression since 2.6.20, or so, has not been confirmed. With a 2.6.21 kernel, I got an iperf 
> transmit rate of 4 Mbs, but that quickly dropped to 0.3 Mbs without me changing anything - I just 
> repeated the iperf command. 

That reminds me... I accidentally invented a new wireless test. It's
intended to stream the full OS images to OLPC laptops on the production
line, and does so by multicast -- so there are no link-layer ACKs and
retries compensating for your packet loss; it all gets reported.

It's in git://git.infradead.org/mtd-utils.git; the tools are recv_image
and serve_image.

usage: recv_image <host> <port> <mtddev>
usage: serve_image <host> <port> <image> <erasesize> [<tx_rate>]

A $ dd if=/dev/urandom of=testfile bs=131072 count=50
A $ ./serve_image ff0f::114 12345 testfile 131072 85
	Inter-packet delay (avg): 32858µs
	Transmit rate: 85 KiB/s
	Checking CRC....85a0d369
	Checking block CRCS.... 50/50
	Image size 6400 KiB (0x00640000). 50 blocks at 47 pkts/block
	Estimated transmit time per cycle: 77s
	Sending data block 004e0000 packet  15/70    (85 KiB/s)    

B $ ./recv_image ff0f::114 12345 foo
	MEMGETINFO: Inappropriate ioctl for device
	Receive to file bar with (assumed) erasesize 131072
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Wu | 1 Sep 02:30

Re: [PATCH 1/6] adm8211: Switch to eeprom_93cx6

On Friday 31 August 2007 17:40, Ivo van Doorn wrote:
> > +	ADM8211_CSR_WRITE(SPR, reg);
> > +	ADM8211_CSR_READ(SPR);		// eeprom_delay
> > +}
> Is this extra delay needed? eeprom_93cx6 also performs
> a ndelay(450) during each pulse
>
It's required to ensure the data reaches the card, at the very least. I'm not 
sure if the read causes the hardware to do any sort of delay, if that's 
possible, but the previous eeprom reading code indicated that it did and 
didn't bother to do any actual delays.

-Michael Wu
Permalink | Reply | 0 comments |
headers
Johannes Berg | 1 Sep 03:12
Favicon

radiotap injection bugs & extending it

[John, Andy, sorry for the dupe, accidentally addressed to John instead
of the list. please reply here]

Hey,

Just noticed this:
__ieee80211_tx_prepare:

struct ieee80211_hdr *hdr = (struct ieee80211_hdr *) skb->data;
[...]
tx->sta = sta_info_get(local, hdr->addr1);
[...]
__ieee80211_parse_tx_radiotap(..)

which seems a bit weird. Shouldn't we grab the sta only after removing
the radiotap stuff? :)

Also, after doing more work on mac80211 I now again have hostapd running
via monitor interfaces. However, there's a bit of a problem there.

After a few changes to mac80211, I have these TX handlers:
        ieee80211_tx_h_check_assoc,
        ieee80211_tx_h_sequence,
        ieee80211_tx_h_ps_buf,
        ieee80211_tx_h_select_key,
        ieee80211_tx_h_michael_mic_add,
        ieee80211_tx_h_fragment,
        ieee80211_tx_h_encrypt,
        ieee80211_tx_h_rate_ctrl,
        ieee80211_tx_h_misc,
(Continue reading)

Permalink | Reply | 6 comments |
headers
Nick Kossifidis | 1 Sep 05:12
Picon
Gravatar

Re: [PATCH 1/5] Net: ath5k, split hw into hw, phy and initvals

2007/8/30, John W. Linville <linville@...>:
> On Thu, Aug 30, 2007 at 04:50:01AM +0300, Nick Kossifidis wrote:
> > 2007/8/28, Christoph Hellwig <hch@...>:
>
> > > ath5k_hw_phy.o should probably be ath5k_phy.o by conventions used by
> > > most drivers and ath5k_hw_inivals.o mights aswell be something like
> > > ath5k_init.o
>
> > If you check out the code you'll see i'm using the same convention
> > inside them, ath5k_hw* files contain hw related functions
> > (ath5k_hw_≤name>) while driver code has ath5k_<name>. Also ath5k_init
> > is misleading, file acually includes initial register settings for
>
> I have to agree w/ Christoph -- the extra "_hw" in the names is just
> a bit unwieldy.
>
> John
>
> P.S.  "ath5k_initvals.c" seems acceptable to me.

ACK, i'll remove _hw ;-)

--

-- 
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
Permalink | Reply | 0 comments |
headers
Andrew Morton | 1 Sep 06:16

borkage in 2.6.23-rc4-mm1


Am seeing random crap like this:

Aug 31 20:57:46 sony dhclient: DHCPREQUEST on eth1 to 255.255.255.255 port 67
Aug 31 20:57:51 sony dhclient: DHCPREQUEST on eth1 to 255.255.255.255 port 67
Aug 31 20:57:56 sony dhclient: dhclient(4537) is already running - exiting. 
Aug 31 20:57:56 sony dhclient: exiting.
Aug 31 20:58:05 sony dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 4
Aug 31 20:58:07 sony kernel: ipw2200: Firmware error detected.  Restarting.
Aug 31 20:58:09 sony dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 7
Aug 31 20:58:16 sony dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 14
Aug 31 20:58:16 sony dhclient: DHCPOFFER from 192.168.2.1
Aug 31 20:58:16 sony dhclient: DHCPREQUEST on eth1 to 255.255.255.255 port 67
Aug 31 20:58:20 sony dhclient: DHCPREQUEST on eth1 to 255.255.255.255 port 67
Aug 31 20:58:20 sony dhclient: DHCPACK from 192.168.2.1
Aug 31 20:58:20 sony NET[4946]: /sbin/dhclient-script : updated /etc/resolv.conf
Aug 31 20:58:20 sony dhclient: bound to 192.168.2.5 -- renewal in 125513 seconds.
Aug 31 20:59:45 sony ntpd[2059]: sendto(192.36.143.234): Invalid argument
Aug 31 20:59:51 sony ntpd[2059]: sendto(193.225.14.163): Invalid argument
Aug 31 20:59:52 sony ntpd[2059]: sendto(193.60.199.78): Invalid argument
Aug 31 21:01:31 sony kernel: ipw2200: Firmware error detected.  Restarting.
Aug 31 21:01:54 sony ntpd[2059]: sendto(192.36.143.234): Invalid argument
Aug 31 21:01:59 sony ntpd[2059]: sendto(193.225.14.163): Invalid argument
Aug 31 21:02:02 sony ntpd[2059]: sendto(193.60.199.78): Invalid argument
Aug 31 21:04:04 sony ntpd[2059]: sendto(192.36.143.234): Invalid argument
Aug 31 21:04:05 sony kernel: ipw2200: Firmware error detected.  Restarting.
Aug 31 21:04:07 sony ntpd[2059]: sendto(193.225.14.163): Invalid argument
Aug 31 21:04:12 sony ntpd[2059]: sendto(193.60.199.78): Invalid argument
Aug 31 21:05:21 sony kernel: ipw2200: Firmware error detected.  Restarting.
(Continue reading)

Permalink | Reply | 8 comments |
headers
Pavel Roskin | 1 Sep 06:34
Picon

[PATCH 00/35] Update at76_usb to the start of mac80211 port

This brings at76_usb to the point where Kalle Valo started mac80211
conversion.

Further patches that bring the driver to version 0.16 will be submitted
once it's clear how the conflicts with Kalle's changes can be resolved
(i.e. which patch goes first and which must be rebased).

--

-- 
Regards,
Pavel Roskin
Permalink | Reply | 40 comments |
headers
Pavel Roskin | 1 Sep 06:34
Picon

[PATCH 01/35] Protect at76_get_op_mode() and at76_get_mib() against short reads

Don't rely on usb_control_msg() returning -EPIPE in absence of working
firmware.  In some cases, no error is returned, but no data is read.

Interpret short reads as an error, return -EIO.

Signed-off-by: Pavel Roskin <proski@...>
---

 drivers/net/wireless/at76_usb.c |   18 +++++++++++++-----
 1 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/at76_usb.c b/drivers/net/wireless/at76_usb.c
index d5e939e..f2a74d4 100644
--- a/drivers/net/wireless/at76_usb.c
+++ b/drivers/net/wireless/at76_usb.c
@@ -578,7 +578,10 @@ static int at76_get_op_mode(struct usb_device *udev)
 			      USB_CTRL_GET_TIMEOUT);
 	if (ret < 0)
 		return ret;
-	return op_mode;
+	else if (ret < 1)
+		return -EIO;
+	else
+		return op_mode;
 }

 /* Load a block of the second ("external") part of the firmware */
@@ -695,10 +698,15 @@ static struct reg_domain const *at76_get_reg_domain(u16 code)
 static inline int at76_get_mib(struct usb_device *udev, u16 mib, void *buf,
 			       int buf_size)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pavel Roskin | 1 Sep 06:34
Picon

[PATCH 02/35] Use existing macros to find bulk in and bulk out endpoints

Signed-off-by: Pavel Roskin <proski@...>
---

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

diff --git a/drivers/net/wireless/at76_usb.c b/drivers/net/wireless/at76_usb.c
index f2a74d4..be9ef6e 100644
--- a/drivers/net/wireless/at76_usb.c
+++ b/drivers/net/wireless/at76_usb.c
@@ -2045,10 +2045,7 @@ static int at76_alloc_urbs(struct at76_priv *priv,
 			 __func__,
 			 i, endpoint->bEndpointAddress, endpoint->bmAttributes);

-		if ((endpoint->bEndpointAddress & 0x80) &&
-		    ((endpoint->bmAttributes & 3) == 0x02)) {
-			/* we found a bulk in endpoint */
-
+		if (usb_endpoint_is_bulk_in(endpoint)) {
 			priv->read_urb = usb_alloc_urb(0, GFP_KERNEL);
 			if (!priv->read_urb) {
 				err("No free urbs available");
@@ -2058,9 +2055,7 @@ static int at76_alloc_urbs(struct at76_priv *priv,
 			    usb_rcvbulkpipe(udev, endpoint->bEndpointAddress);
 		}

-		if (((endpoint->bEndpointAddress & 0x80) == 0x00) &&
-		    ((endpoint->bmAttributes & 3) == 0x02)) {
-			/* we found a bulk out endpoint */
+		if (usb_endpoint_is_bulk_out(endpoint)) {
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pavel Roskin | 1 Sep 06:34
Picon

[PATCH 03/35] Rewrite at76_alloc_urbs() in a more linear fashion

Signed-off-by: Pavel Roskin <proski@...>
---

 drivers/net/wireless/at76_usb.c |   66 +++++++++++++++++++++------------------
 1 files changed, 35 insertions(+), 31 deletions(-)

diff --git a/drivers/net/wireless/at76_usb.c b/drivers/net/wireless/at76_usb.c
index be9ef6e..d1d604e 100644
--- a/drivers/net/wireless/at76_usb.c
+++ b/drivers/net/wireless/at76_usb.c
@@ -2026,8 +2026,7 @@ static void at76_delete_device(struct at76_priv *priv)
 static int at76_alloc_urbs(struct at76_priv *priv,
 			   struct usb_interface *interface)
 {
-	struct usb_endpoint_descriptor *endpoint;
-	struct usb_device *udev = priv->udev;
+	struct usb_endpoint_descriptor *endpoint, *ep_in, *ep_out;
 	int i;
 	int buffer_size;
 	struct usb_host_interface *iface_desc;
@@ -2037,41 +2036,46 @@ static int at76_alloc_urbs(struct at76_priv *priv,
 	at76_dbg(DBG_URB, "%s: NumEndpoints %d ", __func__,
 		 interface->altsetting[0].desc.bNumEndpoints);

+	ep_in = NULL;
+	ep_out = NULL;
 	iface_desc = interface->cur_altsetting;
 	for (i = 0; i < iface_desc->desc.bNumEndpoints; i++) {
 		endpoint = &iface_desc->endpoint[i].desc;
(Continue reading)

Permalink | Reply | 0 comments |

Gmane