From dcbw at redhat.com  Sun Oct  1 10:55:49 2006
From: dcbw at redhat.com (Dan Williams)
Date: Sun, 01 Oct 2006 10:55:49 -0400
Subject: Marvell regulatory domain info storage?
Message-ID: <1159714549.2721.15.camel@localhost.localdomain>

Hi,

Talking with Mitch this week brought up an interesting question.  Where
regulatory domain information for the wireless stored?  We have to know
what channels we can(not) operate on for a given country, and therefore
must communicate that information to the laptop.

Does the Marvell chip have internal EEPROM that we write the appropriate
region code to?  Or must we pull that value from the SPI flash and write
it to the card during init?  It appears that the driver pulls a preset
region code from the card, see wlan_ret_get_hw_spec() in wlan_cmdresp.c.
That indicates that the region code is either in (a) firmware, or (b) in
EEPROM on the card.  The region code may apparently be set from
userspace with a private ioctl.

Thoughts?  At worst, we do country-specific flashes, which we were
already going to do for fonts & translations.  At best, the server
and/or firstboot process communicates region code somehow.
 
Dan




From jg at laptop.org  Sun Oct  1 15:32:46 2006
From: jg at laptop.org (Jim Gettys)
Date: Sun, 01 Oct 2006 15:32:46 -0400
Subject: Marvell regulatory domain info storage?
In-Reply-To: <1159714549.2721.15.camel@localhost.localdomain>
References: <1159714549.2721.15.camel@localhost.localdomain>
Message-ID: <1159731166.6029.6.camel@localhost.localdomain>

On Sun, 2006-10-01 at 10:55 -0400, Dan Williams wrote:
> Hi,
> 
> Talking with Mitch this week brought up an interesting question.  Where
> regulatory domain information for the wireless stored?  We have to know
> what channels we can(not) operate on for a given country, and therefore
> must communicate that information to the laptop.
> 
> Does the Marvell chip have internal EEPROM that we write the appropriate
> region code to?  Or must we pull that value from the SPI flash and write
> it to the card during init?  

This should be pretty easy.  On the manufacturing line, they know what
language/keyboard they are loading, and the machine's destination.

> It appears that the driver pulls a preset
> region code from the card, see wlan_ret_get_hw_spec() in wlan_cmdresp.c.
> That indicates that the region code is either in (a) firmware, or (b) in
> EEPROM on the card.  The region code may apparently be set from
> userspace with a private ioctl.
> 
> Thoughts?  At worst, we do country-specific flashes, which we were
> already going to do for fonts & translations.  At best, the server
> and/or firstboot process communicates region code somehow.
>  

Doesn't help: you could be off frequency for these operations.
                           - Jim

-- 
Jim Gettys
One Laptop Per Child




From khaled at laptop.org  Sun Oct  1 19:09:14 2006
From: khaled at laptop.org (Khaled Hassounah)
Date: Sun, 01 Oct 2006 19:09:14 -0400
Subject: Marvell regulatory domain info storage?
In-Reply-To: <9FA16888AD1BF64ABCE6C2532CCEB98AE17CA3@xmb-sjc-219.amer.cisco.com>
References: <9FA16888AD1BF64ABCE6C2532CCEB98AE17CA3@xmb-sjc-219.amer.cisco.com>
Message-ID: <45204A9A.7070109@laptop.org>

> As you mentioned, we would need the country specific flashes and that
> would be a good place for the region codes as well. The only caveat is,
> what happens when a kid with a laptop goes from one country to another ?

Trying to solve that problem would be an overkill. You don't reconfigure
your network card every time you travel.

Khaled


From wmb at firmworks.com  Mon Oct  2 02:04:55 2006
From: wmb at firmworks.com (Mitch Bradley)
Date: Sun, 01 Oct 2006 20:04:55 -1000
Subject: Marvell regulatory domain info storage?
In-Reply-To: <1159731166.6029.6.camel@localhost.localdomain>
References: <1159714549.2721.15.camel@localhost.localdomain>
	<1159731166.6029.6.camel@localhost.localdomain>
Message-ID: <4520AC07.3020209@firmworks.com>

The region code, or something equivalent, is a good candidate for the 
"manufacturing data" that Quanta will put in their special section of 
FLASH.  I'm thinking of a two-prong approach:

a) The manufacturing data will include a region code and the driver will 
have a lookup table that maps region code to a list of 
regulatory-approved channels.

b) Optionally, the manufacturing data can also include an explicit 
channel list (probably a bitmask) that, if present, will override the 
region-derived channel list.


Jim Gettys wrote:
> On Sun, 2006-10-01 at 10:55 -0400, Dan Williams wrote:
>   
>> Hi,
>>
>> Talking with Mitch this week brought up an interesting question.  Where
>> regulatory domain information for the wireless stored?  We have to know
>> what channels we can(not) operate on for a given country, and therefore
>> must communicate that information to the laptop.
>>
>> Does the Marvell chip have internal EEPROM that we write the appropriate
>> region code to?  Or must we pull that value from the SPI flash and write
>> it to the card during init?  
>>     
>
> This should be pretty easy.  On the manufacturing line, they know what
> language/keyboard they are loading, and the machine's destination.
>
>   
>> It appears that the driver pulls a preset
>> region code from the card, see wlan_ret_get_hw_spec() in wlan_cmdresp.c.
>> That indicates that the region code is either in (a) firmware, or (b) in
>> EEPROM on the card.  The region code may apparently be set from
>> userspace with a private ioctl.
>>
>> Thoughts?  At worst, we do country-specific flashes, which we were
>> already going to do for fonts & translations.  At best, the server
>> and/or firstboot process communicates region code somehow.
>>  
>>     
>
> Doesn't help: you could be off frequency for these operations.
>                            - Jim
>
>   



From dcbw at redhat.com  Mon Oct  2 09:45:50 2006
From: dcbw at redhat.com (Dan Williams)
Date: Mon, 02 Oct 2006 09:45:50 -0400
Subject: Marvell regulatory domain info storage?
In-Reply-To: <4520AC07.3020209@firmworks.com>
References: <1159714549.2721.15.camel@localhost.localdomain>
	<1159731166.6029.6.camel@localhost.localdomain>
	<4520AC07.3020209@firmworks.com>
Message-ID: <1159796750.2834.2.camel@localhost.localdomain>

On Sun, 2006-10-01 at 20:04 -1000, Mitch Bradley wrote:
> The region code, or something equivalent, is a good candidate for the 
> "manufacturing data" that Quanta will put in their special section of 
> FLASH.  I'm thinking of a two-prong approach:
> 
> a) The manufacturing data will include a region code and the driver will 
> have a lookup table that maps region code to a list of 
> regulatory-approved channels.

Right; the current libertas driver already looks up the region code from
the card itself.  But if we get that from the manufacturing area, the
driver has a few tables (mostly for US, EU, and Japan) that show allowed
channels.  We'll likely need to add a lot more tables for different
countries.

> b) Optionally, the manufacturing data can also include an explicit 
> channel list (probably a bitmask) that, if present, will override the 
> region-derived channel list.

I'm not sure, but there may also be power restrictions on a per-country
basis too.  Need to look that up.  At least the FCC restricts power
output of unlicensed devices, but I'm not sure if that's band-specific.

Dan

> 
> Jim Gettys wrote:
> > On Sun, 2006-10-01 at 10:55 -0400, Dan Williams wrote:
> >   
> >> Hi,
> >>
> >> Talking with Mitch this week brought up an interesting question.  Where
> >> regulatory domain information for the wireless stored?  We have to know
> >> what channels we can(not) operate on for a given country, and therefore
> >> must communicate that information to the laptop.
> >>
> >> Does the Marvell chip have internal EEPROM that we write the appropriate
> >> region code to?  Or must we pull that value from the SPI flash and write
> >> it to the card during init?  
> >>     
> >
> > This should be pretty easy.  On the manufacturing line, they know what
> > language/keyboard they are loading, and the machine's destination.
> >
> >   
> >> It appears that the driver pulls a preset
> >> region code from the card, see wlan_ret_get_hw_spec() in wlan_cmdresp.c.
> >> That indicates that the region code is either in (a) firmware, or (b) in
> >> EEPROM on the card.  The region code may apparently be set from
> >> userspace with a private ioctl.
> >>
> >> Thoughts?  At worst, we do country-specific flashes, which we were
> >> already going to do for fonts & translations.  At best, the server
> >> and/or firstboot process communicates region code somehow.
> >>  
> >>     
> >
> > Doesn't help: you could be off frequency for these operations.
> >                            - Jim
> >
> >   
> 



From wmb at firmworks.com  Mon Oct  2 19:25:55 2006
From: wmb at firmworks.com (Mitch Bradley)
Date: Mon, 02 Oct 2006 13:25:55 -1000
Subject: Marvell regulatory domain info storage?
In-Reply-To: <D1575D47310FC94D902C8675241E8E3E023A5519@msiexch01.marvell.com>
References: <D1575D47310FC94D902C8675241E8E3E023A5519@msiexch01.marvell.com>
Message-ID: <4521A003.2050908@firmworks.com>

Ronak Chokshi wrote:
>
> -        Burning the region code in the manufacturing data of the 
> EEPROM is an option but a slightly difficult one. A better suggestion 
> would be maintain this information on an external flash memory and 
> have the driver read this information from the flash. This is what we 
> have suggested to most of our customers also.
>
The OLPC manufacturing data that I was talking about is in the same 
FLASH that contains the system BIOS.  Is that the sort of "external 
flash memory" that you recommend?

We were not intending to change the EEPROM that is attached to the 
Marvell wireless device on a per-county basis.
>
> This also has an added advantage that it keeps the WLAN module the 
> same for all the laptops going in several countries.
>
>  
>
Yes, that is our intention.




From dcbw at redhat.com  Tue Oct  3 12:08:41 2006
From: dcbw at redhat.com (Dan Williams)
Date: Tue, 03 Oct 2006 12:08:41 -0400
Subject: [PATCH] libertas: WE quality fixes
Message-ID: <1159891722.5107.3.camel@localhost.localdomain>

Set IW_QUAL_DBM on updated quality values, and use real noise value to
calculate quality (fixes /proc/net/wireless display too).

Signed-off-by: Dan Williams <dcbw at redhat.com>

diff --git a/drivers/net/wireless/libertas/wlan_wext.c b/drivers/net/wireless/libertas/wlan_wext.c
index fbe370d..e03e57a 100644
--- a/drivers/net/wireless/libertas/wlan_wext.c
+++ b/drivers/net/wireless/libertas/wlan_wext.c
@@ -2108,7 +2108,7 @@ static struct iw_statistics *wlan_get_wi
 	PRINTM(INFO, "Signal Level = %#x\n", priv->wstats.qual.level);
 	PRINTM(INFO, "Noise = %#x\n", priv->wstats.qual.noise);
 
-	rssi = priv->wstats.qual.level - MRVDRV_NF_DEFAULT_SCAN_VALUE;
+	rssi = priv->wstats.qual.level - priv->wstats.qual.noise;
 	if (rssi < 15)
 		rssi_qual = rssi * POOR / 10;
 	else if (rssi < 20)
@@ -2152,7 +2152,7 @@ static struct iw_statistics *wlan_get_wi
 
 	/* Calculate quality */
 	priv->wstats.qual.qual = max(quality, (u32)100);
-	priv->wstats.qual.updated = IW_QUAL_ALL_UPDATED;
+	priv->wstats.qual.updated = IW_QUAL_ALL_UPDATED | IW_QUAL_DBM;
 	stats_valid = 1;
 
 out:




From dcbw at redhat.com  Tue Oct  3 12:08:40 2006
From: dcbw at redhat.com (Dan Williams)
Date: Tue, 03 Oct 2006 12:08:40 -0400
Subject: [PATCH] libertas: inode diet fixes
Message-ID: <1159891720.5107.2.camel@localhost.localdomain>

Fix inode member usage under 2.6.18.

Signed-off-by: Dan Williams <dcbw at redhat.com>

diff --git a/drivers/net/wireless/libertas/wlan_debugfs.c b/drivers/net/wireless/libertas/wlan_debugfs.c
index 3a6b055..d5435f7 100644
--- a/drivers/net/wireless/libertas/wlan_debugfs.c
+++ b/drivers/net/wireless/libertas/wlan_debugfs.c
@@ -19,7 +19,7 @@ void libertas_debug_init(wlan_private * 
 
 static int open_file_generic(struct inode *inode, struct file *file)
 {
-	file->private_data = inode->u.generic_ip;
+	file->private_data = inode->i_private;
 	return 0;
 }
 




From dcbw at redhat.com  Tue Oct  3 14:19:45 2006
From: dcbw at redhat.com (Dan Williams)
Date: Tue, 03 Oct 2006 14:19:45 -0400
Subject: [PATCH] libertas: harmonize key length defines (again)
Message-ID: <1159899585.8657.2.camel@localhost.localdomain>

This time, make the WEP key lengths consistent with the WPA ones.

Replace usage of MRVL_MAX_WPA_KEY_LENGTH with
MRVL_MAX_KEY_WPA_KEY_LENGTH because they are confusingly similar and do
the same thing anyway.

Signed-off-by: Dan Williams <dcbw at redhat.com>


diff --git a/drivers/net/wireless/libertas/wlan_cmd.c b/drivers/net/wireless/libertas/wlan_cmd.c
index 152c057..dc6f76b 100644
--- a/drivers/net/wireless/libertas/wlan_cmd.c
+++ b/drivers/net/wireless/libertas/wlan_cmd.c
@@ -440,7 +440,7 @@ static int wlan_cmd_802_11_key_material(
 	memset(&pKeyMaterial->KeyParamSet, 0,
 	       sizeof(struct MrvlIEtype_KeyParamSet));
 
-	if (pKey->KeyLength == WPA_AES_KEY_LEN) {
+	if (pKey->KeyLength == KEY_LEN_WPA_AES) {
 		PRINTM(INFO, "WPA_AES\n");
 		pKeyMaterial->KeyParamSet.KeyTypeId =
 		    wlan_cpu_to_le16(KEY_TYPE_ID_AES);
@@ -458,7 +458,7 @@ static int wlan_cmd_802_11_key_material(
 		else		//AES group key: multicast
 			pKeyMaterial->KeyParamSet.KeyInfo |=
 			    wlan_cpu_to_le16(KEY_INFO_AES_MCAST);
-	} else if (pKey->KeyLength == WPA_TKIP_KEY_LEN) {
+	} else if (pKey->KeyLength == KEY_LEN_WPA_TKIP) {
 		PRINTM(INFO, "WPA_TKIP\n");
 		pKeyMaterial->KeyParamSet.KeyTypeId =
 		    wlan_cpu_to_le16(KEY_TYPE_ID_TKIP);
diff --git a/drivers/net/wireless/libertas/wlan_defs.h b/drivers/net/wireless/libertas/wlan_defs.h
index 8e7fb7a..b02980e 100644
--- a/drivers/net/wireless/libertas/wlan_defs.h
+++ b/drivers/net/wireless/libertas/wlan_defs.h
@@ -293,17 +293,12 @@ #define WLAN_802_11_AI_RESFI_ASSOCIATION
 /** WPA Key LENGTH*/
 /* Support 4 keys per key set */
 #define MRVL_NUM_WPA_KEY_PER_SET        4
-#define MRVL_MAX_WPA_KEY_LENGTH 	32
 #define MRVL_MAX_KEY_WPA_KEY_LENGTH     32
 
-#define WPA_AES_KEY_LEN 		16
-#define WPA_TKIP_KEY_LEN 		32
-
-/* A few details needed for WEP (Wireless Equivalent Privacy) */
-/* 104 bits */
-#define MAX_WEP_KEY_SIZE		13
-/*40 bits RC4 - WEP*/
-#define MIN_WEP_KEY_SIZE		5
+#define KEY_LEN_WPA_AES			16
+#define KEY_LEN_WPA_TKIP		32
+#define KEY_LEN_WEP_104			13
+#define KEY_LEN_WEP_40			5
 
 #define RF_ANTENNA_1		0x1
 #define RF_ANTENNA_2		0x2
diff --git a/drivers/net/wireless/libertas/wlan_wext.c b/drivers/net/wireless/libertas/wlan_wext.c
index e03e57a..27886ff 100644
--- a/drivers/net/wireless/libertas/wlan_wext.c
+++ b/drivers/net/wireless/libertas/wlan_wext.c
@@ -331,7 +331,7 @@ static int wlan_set_encode_wpa(struct ne
 	HEXDUMP("KeyMaterial: ", (u8 *) pKey->KeyMaterial, pKey->KeyLength);
 
 	// current driver only supports key length of up to 32 bytes
-	if (pKey->KeyLength > MRVL_MAX_WPA_KEY_LENGTH) {
+	if (pKey->KeyLength > MRVL_MAX_KEY_WPA_KEY_LENGTH) {
 		PRINTM(INFO, " Error in key length \n");
 		return WLAN_STATUS_FAILURE;
 	}
@@ -405,7 +405,7 @@ static int wlan_set_encode_nonwpa(struct
 		 * Check the size of the key 
 		 */
 
-		if (dwrq->length > MAX_WEP_KEY_SIZE) {
+		if (dwrq->length > KEY_LEN_WEP_104) {
 			return -EINVAL;
 		}
 
@@ -429,11 +429,11 @@ static int wlan_set_encode_nonwpa(struct
 			memcpy(pWep->KeyMaterial, extra, dwrq->length);
 
 			/* Set the length */
-			if (dwrq->length > MIN_WEP_KEY_SIZE) {
-				pWep->KeyLength = MAX_WEP_KEY_SIZE;
+			if (dwrq->length > KEY_LEN_WEP_40) {
+				pWep->KeyLength = KEY_LEN_WEP_104;
 			} else {
 				if (dwrq->length > 0) {
-					pWep->KeyLength = MIN_WEP_KEY_SIZE;
+					pWep->KeyLength = KEY_LEN_WEP_40;
 				} else {
 					/* Disable the key */
 					pWep->KeyLength = 0;
@@ -1129,7 +1129,7 @@ static int wlan_get_encode(struct net_de
 
 	if (adapter->EncryptionStatus == Wlan802_11Encryption2Enabled
 	    && !dwrq->length) {
-		dwrq->length = MAX_WEP_KEY_SIZE;
+		dwrq->length = KEY_LEN_WEP_104;
 	}
 
 	PRINTM(INFO, "Return flags=0x%x\n", dwrq->flags);
@@ -2518,15 +2518,14 @@ int wlan_set_encode(struct net_device *d
 		    struct iw_request_info *info,
 		    struct iw_point *dwrq, char *extra)
 {
-
 	struct WLAN_802_11_KEY *pKey = NULL;
 
 	ENTER();
 
-	if (dwrq->length > MAX_WEP_KEY_SIZE) {
+	if (dwrq->length > KEY_LEN_WEP_104) {
 		pKey = (struct WLAN_802_11_KEY *)extra;
 
-		if (pKey->KeyLength <= MAX_WEP_KEY_SIZE) {
+		if (pKey->KeyLength <= KEY_LEN_WEP_104) {
 			//dynamic WEP
 			dwrq->length = pKey->KeyLength;
 			dwrq->flags = pKey->KeyIndex + 1;




From blizzard at redhat.com  Tue Oct  3 14:44:32 2006
From: blizzard at redhat.com (Christopher Blizzard)
Date: Tue, 03 Oct 2006 14:44:32 -0400
Subject: Marvell regulatory domain info storage?
In-Reply-To: <D1575D47310FC94D902C8675241E8E3E023A5540@msiexch01.marvell.com>
References: <D1575D47310FC94D902C8675241E8E3E023A5540@msiexch01.marvell.com>
Message-ID: <4522AF90.9090907@redhat.com>

Ronak Chokshi wrote:
> The OLPC manufacturing data that I was talking about is in the same 
> FLASH that contains the system BIOS.  Is that the sort of "external 
> flash memory" that you recommend?
> 
>>> Yes.
> 
> Ronak

Given the choice between putting this on the onboard SPI flash and 
putting it as a config option for the driver, I would rather it be part 
of the driver.  It's just more convenient for us and the other option 
just adds another level of pain for per-country flashing.

--Chris

>  
> 
> -----Original Message-----
> From: Mitch Bradley [mailto:wmb at firmworks.com] 
> Sent: Monday, October 02, 2006 4:26 PM
> To: Ronak Chokshi
> Cc: Dan Williams; devel at laptop.org; Michail Bletsas; jg at laptop.org;
> libertas-dev at lists.infradead.org
> Subject: Re: Marvell regulatory domain info storage?
> 
> Ronak Chokshi wrote:
>> -        Burning the region code in the manufacturing data of the 
>> EEPROM is an option but a slightly difficult one. A better suggestion 
>> would be maintain this information on an external flash memory and 
>> have the driver read this information from the flash. This is what we 
>> have suggested to most of our customers also.
>>
> The OLPC manufacturing data that I was talking about is in the same 
> FLASH that contains the system BIOS.  Is that the sort of "external 
> flash memory" that you recommend?
> 
> We were not intending to change the EEPROM that is attached to the 
> Marvell wireless device on a per-county basis.
>> This also has an added advantage that it keeps the WLAN module the 
>> same for all the laptops going in several countries.
>>
>>  
>>
> Yes, that is our intention.
> 
> 
> _______________________________________________
> Devel mailing list
> Devel at laptop.org
> http://mailman.laptop.org/mailman/listinfo/devel



From wmb at firmworks.com  Tue Oct  3 15:13:40 2006
From: wmb at firmworks.com (Mitch Bradley)
Date: Wed, 04 Oct 2006 03:13:40 +0800
Subject: Marvell regulatory domain info storage?
In-Reply-To: <4522AF90.9090907@redhat.com>
References: <D1575D47310FC94D902C8675241E8E3E023A5540@msiexch01.marvell.com>
	<4522AF90.9090907@redhat.com>
Message-ID: <4522B664.4070405@firmworks.com>

I got some pushback from Quanta yesterday.  They want to put the region 
information in the EEPROM attached to the Marvel device, instead of in 
the manufacturing data area of the SPI FLASH.

I'm not sure of all their rationale; the one point that got through the 
language barrier clearly was the fact that, if it's in EEPROM, there's 
no need to implement a conduit to convey the information from the 
manufacturing data area to the wireless driver.  I also suspect that 
Quanta may be wanting to treat the manufacturing data area as their 
private sandbox.  Both points have some merit.

Up to now, I hadn't been considering the conduit issue.  I tend to thing 
of things in terms of Open Firmware that is well integrated with the 
kernel, in which case such a conduit is "just there".  At present, we 
don't have a convenient conduit.

Quanta has no problem with separately customizing both the SPI FLASH and 
the Marvell EEPROM.




From jg at laptop.org  Tue Oct  3 15:24:28 2006
From: jg at laptop.org (Jim Gettys)
Date: Tue, 03 Oct 2006 15:24:28 -0400
Subject: Marvell regulatory domain info storage?
In-Reply-To: <4522B664.4070405@firmworks.com>
References: <D1575D47310FC94D902C8675241E8E3E023A5540@msiexch01.marvell.com>
	<4522AF90.9090907@redhat.com>  <4522B664.4070405@firmworks.com>
Message-ID: <1159903468.6029.456.camel@localhost.localdomain>

>From our point of view, this is preferable as well: it means the USB
version of the marvell device and ours can look that much more similar.

I suspect they don't care because the have to program the eeprom for the
marvell chip anyway.
                                              - Jim


On Wed, 2006-10-04 at 03:13 +0800, Mitch Bradley wrote:
> I got some pushback from Quanta yesterday.  They want to put the region 
> information in the EEPROM attached to the Marvel device, instead of in 
> the manufacturing data area of the SPI FLASH.
> 
> I'm not sure of all their rationale; the one point that got through the 
> language barrier clearly was the fact that, if it's in EEPROM, there's 
> no need to implement a conduit to convey the information from the 
> manufacturing data area to the wireless driver.  I also suspect that 
> Quanta may be wanting to treat the manufacturing data area as their 
> private sandbox.  Both points have some merit.
> 
> Up to now, I hadn't been considering the conduit issue.  I tend to thing 
> of things in terms of Open Firmware that is well integrated with the 
> kernel, in which case such a conduit is "just there".  At present, we 
> don't have a convenient conduit.
> 
> Quanta has no problem with separately customizing both the SPI FLASH and 
> the Marvell EEPROM.
> 
> 
> _______________________________________________
> Devel mailing list
> Devel at laptop.org
> http://mailman.laptop.org/mailman/listinfo/devel
-- 
Jim Gettys
One Laptop Per Child




From dcbw at redhat.com  Tue Oct  3 16:18:32 2006
From: dcbw at redhat.com (Dan Williams)
Date: Tue, 03 Oct 2006 16:18:32 -0400
Subject: [PATCH] libertas: wlan_cmd.c - use standard key length defines
Message-ID: <1159906712.9884.2.camel@localhost.localdomain>

Use standard key length defines rather than private ones.

Signed-off-by: Dan Williams <dcbw at redhat.com>

diff --git a/drivers/net/wireless/libertas/wlan_cmd.c b/drivers/net/wireless/libertas/wlan_cmd.c
index 152c057..db7a5af 100644
--- a/drivers/net/wireless/libertas/wlan_cmd.c
+++ b/drivers/net/wireless/libertas/wlan_cmd.c
@@ -243,9 +243,6 @@ static int wlan_cmd_802_11_sleep_params(
 	return WLAN_STATUS_SUCCESS;
 }
 
-#define WEP_40_BIT_LEN	5
-#define WEP_104_BIT_LEN	13
-
 /** 
  *  @brief This function prepares command of set_wep.
  *  
@@ -277,12 +274,12 @@ static int wlan_cmd_802_11_set_wep(wlan_
 		PRINTM(INFO, "Tx Key Index: %u\n", wep->KeyIndex);
 
 		switch (Adapter->WepKey[0].KeyLength) {
-		case WEP_40_BIT_LEN:
+		case KEY_LEN_WEP_40:
 			wep->WEPTypeForKey1 = HostCmd_TYPE_WEP_40_BIT;
 			memmove(wep->WEP1, Adapter->WepKey[0].KeyMaterial,
 				Adapter->WepKey[0].KeyLength);
 			break;
-		case WEP_104_BIT_LEN:
+		case KEY_LEN_WEP_104:
 			wep->WEPTypeForKey1 = HostCmd_TYPE_WEP_104_BIT;
 			memmove(wep->WEP1, Adapter->WepKey[0].KeyMaterial,
 				Adapter->WepKey[0].KeyLength);
@@ -297,12 +294,12 @@ static int wlan_cmd_802_11_set_wep(wlan_
 		}
 
 		switch (Adapter->WepKey[1].KeyLength) {
-		case WEP_40_BIT_LEN:
+		case KEY_LEN_WEP_40:
 			wep->WEPTypeForKey2 = HostCmd_TYPE_WEP_40_BIT;
 			memmove(wep->WEP2, Adapter->WepKey[1].KeyMaterial,
 				Adapter->WepKey[1].KeyLength);
 			break;
-		case WEP_104_BIT_LEN:
+		case KEY_LEN_WEP_104:
 			wep->WEPTypeForKey2 = HostCmd_TYPE_WEP_104_BIT;
 			memmove(wep->WEP2, Adapter->WepKey[1].KeyMaterial,
 				Adapter->WepKey[1].KeyLength);
@@ -317,12 +314,12 @@ static int wlan_cmd_802_11_set_wep(wlan_
 		}
 
 		switch (Adapter->WepKey[2].KeyLength) {
-		case WEP_40_BIT_LEN:
+		case KEY_LEN_WEP_40:
 			wep->WEPTypeForKey3 = HostCmd_TYPE_WEP_40_BIT;
 			memmove(wep->WEP3, Adapter->WepKey[2].KeyMaterial,
 				Adapter->WepKey[2].KeyLength);
 			break;
-		case WEP_104_BIT_LEN:
+		case KEY_LEN_WEP_104:
 			wep->WEPTypeForKey3 = HostCmd_TYPE_WEP_104_BIT;
 			memmove(wep->WEP3, Adapter->WepKey[2].KeyMaterial,
 				Adapter->WepKey[2].KeyLength);
@@ -337,12 +334,12 @@ static int wlan_cmd_802_11_set_wep(wlan_
 		}
 
 		switch (Adapter->WepKey[3].KeyLength) {
-		case WEP_40_BIT_LEN:
+		case KEY_LEN_WEP_40:
 			wep->WEPTypeForKey4 = HostCmd_TYPE_WEP_40_BIT;
 			memmove(wep->WEP4, Adapter->WepKey[3].KeyMaterial,
 				Adapter->WepKey[3].KeyLength);
 			break;
-		case WEP_104_BIT_LEN:
+		case KEY_LEN_WEP_104:
 			wep->WEPTypeForKey4 = HostCmd_TYPE_WEP_104_BIT;
 			memmove(wep->WEP4, Adapter->WepKey[3].KeyMaterial,
 				Adapter->WepKey[3].KeyLength);




From mzbycp at 0pointer.de  Wed Oct  4 20:36:20 2006
From: mzbycp at 0pointer.de (Lennart Poettering)
Date: Thu, 5 Oct 2006 02:36:20 +0200
Subject: Ability to set the 802.11s TTL for outgoing packets
Message-ID: <20061005003620.GA17768@ecstasy.ring2.lan>

Hi!

I am currently doing some scalability work for the Avahi mDNS/DNS-SD
responder (see avahi.org) for usage in OLPC. For that I'd like to be
able to set the 802.11s TTL for outgoing packets. The background is
that to minimize the necessary traffic I'd like to take the mesh
topology into account when distributing the Avahi service information
over the network. Right now I can read the mesh forwarding table from
userspace. However, it's not yet possible to multicast packets to just
a subset of the hosts in the mesh, depending on the
proximity. However, such a feature would become very handy in my work,
and probably even for other projects. (Think of an RTP video cast to
only the hosts nearby)

After reading through the 80211s draft I came the conclusion that the
"Mesh TTL field" (7.1.3.5a.1) in the packet header could be used for
what I am looking for. Setting it to 1 should allow me to multicast
packets to just my direct neighbors and nobody else. (or did I miss
anything? the 802.11s draft is not that verbose in its current
version)

The marvell hardware interface right now doesn't seem to allow setting
the TTL for each outgoing packet as I understood the driver. (Actually
it doesn't even allow setting the TTL at all, not even globally)

Fixing up the driver to pass this value along in the TxPD structure
doesn't seem too difficult to me. However I wonder how feasible it is
to get the firmware improved to accept this field in each TxPD
message. Does anyone at OLPC have direct access to the firmware
sources? Or is Marvell open to requests like this one?

What I have in mind in the end is that I can use a setsockopt() or a
sendmsg() field for setting the mesh TTL for outgoing packets, much
like it is done with IP ttls with the IPPROTO_IP::IP_TTL sockopt.

Any thoughts or ideas?

Lennart

-- 
Lennart Poettering; lennart [at] poettering [dot] net
ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.infradead.org/pipermail/libertas-dev/attachments/20061005/0948e195/attachment.bin 

From rick at efn.org  Thu Oct  5 12:47:22 2006
From: rick at efn.org (Rick Bronson)
Date: Thu, 05 Oct 2006 09:47:22 -0700
Subject: Libertas driver
Message-ID: <E1GVWNW-0006rk-00@amazonia>

Hi,

  I just wondered if you know of anyone that used your OLPC
Libertas WiFi driver on the Dlink DWL-G122 Rev D USB WiFi adapter
which, as far as I can figure, has the Libertas chip?

  I copied the /usr/src/linux/drivers/net/wireless/libertas from the
OLCP kernel to my 2.6.16, compiled it and stuck these files in
/lib/firmware:

  -rw-rw-rw-  1 rick solar  237056 Oct  5 07:13 USB55N50.sys
  -rw-rw-rw-  1 rick solar  236928 Oct  5 07:14 USB55N51.sys
  -rw-rw-rw-  1 rick solar  105808 Aug 25 16:39 usb8388FWT.bin
  -rw-rw-rw-  1 rick solar  108220 Aug 27 11:35 usb8388MRP.bin
  -rw-rw-rw-  1 rick solar  101744 Oct  4 10:59 usb8388_A1_W8015FP14_FW2.bin


  Then I tried:

modprobe firmware_class
cd /lib/modules/2.6.16/kernel/drivers/net/wireless/libertas
insmod usb8xxx.ko fw_name=XXXX

  where XXXX is one of the files above.  Here is what I got for usb8388FWT.bin:
http://www.efn.org/~rick/pub/debug.txt

  Any help is greatly appreciated!

  Rick

                                                                   _
                                                                  | |
                                                                  / /__
.----------------------------------------------------------._____/ (___)
| Rick Bronson rick at efn.org     Tel 541-485-7264           |       (___)
| Amazonia Computing http://www.efn.org/~rick      __ o    |_____  (___)
| 5050 Donald Street     "Onde esta dinheiro?"    _`\<,    |     \_(___)
| Eugene, OR  97405       -- Gal Costa         __( )/( )__ |
`----------------------------------------------------------'


From slamb at slamb.org  Fri Oct  6 03:56:59 2006
From: slamb at slamb.org (Scott Lamb)
Date: Fri, 06 Oct 2006 00:56:59 -0700
Subject: Marvell regulatory domain info storage?
In-Reply-To: <1159796750.2834.2.camel@localhost.localdomain>
References: <1159714549.2721.15.camel@localhost.localdomain>	<1159731166.6029.6.camel@localhost.localdomain>	<4520AC07.3020209@firmworks.com>
	<1159796750.2834.2.camel@localhost.localdomain>
Message-ID: <45260C4B.5020906@slamb.org>

Dan Williams wrote:
> I'm not sure, but there may also be power restrictions on a per-country
> basis too.  Need to look that up.  At least the FCC restricts power
> output of unlicensed devices, but I'm not sure if that's band-specific.

</lurk>

I was just asking an expert about this sort of thing, so I can relay
some information:

1) There are indeed per-country power limits. Not only does the number
change, but its meaning, too - some countries measure by RMS, others by
peak.

2) Calibration is per-country, too. I didn't get the details, but maybe
this is related to the above - the calibration procedure might just do
one power measure. This information is for my company's device, so YMMV.

3) Khaled said this: "You don't reconfigure your network card every time
you travel." This is because the laptop gets its regulatory domain
information from the Access Point via 802.11d. You can't legally operate
Access Points in different regulatory domains without adjustment. Now, I
have absolutely no idea what this means for mesh networking...

Warm regards,
Scott

-- 
Scott Lamb <http://www.slamb.org/>


From pjones at redhat.com  Fri Oct  6 18:21:26 2006
From: pjones at redhat.com (Peter Jones)
Date: Fri, 06 Oct 2006 18:21:26 -0400
Subject: Marvell regulatory domain info storage?
In-Reply-To: <45260C4B.5020906@slamb.org>
References: <1159714549.2721.15.camel@localhost.localdomain>
	<1159731166.6029.6.camel@localhost.localdomain>
	<4520AC07.3020209@firmworks.com>
	<1159796750.2834.2.camel@localhost.localdomain>
	<45260C4B.5020906@slamb.org>
Message-ID: <1160173286.31043.43.camel@localhost.localdomain>

On Fri, 2006-10-06 at 00:56 -0700, Scott Lamb wrote:

> 3) Khaled said this: "You don't reconfigure your network card every time
> you travel." This is because the laptop gets its regulatory domain
> information from the Access Point via 802.11d. You can't legally operate
> Access Points in different regulatory domains without adjustment. Now, I
> have absolutely no idea what this means for mesh networking...

Huh?  That doesn't quite follow.  You can't know if it's legal to
associate with an AP during scanning, or even know what channels you're
allowed to scan, until you've selected your regulatory domain.

When a scan is initiated, you already have a list of channels that's ok
to talk on, and it's determined by a static table in the driver, indexed
by the geo code read from the firmware on the machine -- typically the
firmware of the WiFi device itself.

See, for example, wlan_scan_create_channel_list() in
libertas/wlan_scan.c, or ipw_request_scan() (and its helper
ipw_add_scan_channels() ) in ipw2200.c .

It's certainly possible to hack things up to use a user-settable geo,
but that is not what drivers currently do.

-- 
  Peter



From slamb at slamb.org  Fri Oct  6 18:37:51 2006
From: slamb at slamb.org (Scott Lamb)
Date: Fri, 6 Oct 2006 15:37:51 -0700
Subject: Marvell regulatory domain info storage?
In-Reply-To: <1160173286.31043.43.camel@localhost.localdomain>
References: <1159714549.2721.15.camel@localhost.localdomain>
	<1159731166.6029.6.camel@localhost.localdomain>
	<4520AC07.3020209@firmworks.com>
	<1159796750.2834.2.camel@localhost.localdomain>
	<45260C4B.5020906@slamb.org>
	<1160173286.31043.43.camel@localhost.localdomain>
Message-ID: <256DB250-0C32-4AD6-A118-0346447F5C88@slamb.org>


On Oct 6, 2006, at 3:21 PM, Peter Jones wrote:

> On Fri, 2006-10-06 at 00:56 -0700, Scott Lamb wrote:
>
>> 3) Khaled said this: "You don't reconfigure your network card  
>> every time
>> you travel." This is because the laptop gets its regulatory domain
>> information from the Access Point via 802.11d. You can't legally  
>> operate
>> Access Points in different regulatory domains without adjustment.  
>> Now, I
>> have absolutely no idea what this means for mesh networking...
>
> Huh?  That doesn't quite follow.  You can't know if it's legal to
> associate with an AP during scanning, or even know what channels  
> you're
> allowed to scan, until you've selected your regulatory domain.
>
> When a scan is initiated, you already have a list of channels  
> that's ok
> to talk on, and it's determined by a static table in the driver,  
> indexed
> by the geo code read from the firmware on the machine -- typically the
> firmware of the WiFi device itself.
>
> See, for example, wlan_scan_create_channel_list() in
> libertas/wlan_scan.c, or ipw_request_scan() (and its helper
> ipw_add_scan_channels() ) in ipw2200.c .
>
> It's certainly possible to hack things up to use a user-settable geo,
> but that is not what drivers currently do.

I think my wording is at fault here. I'm talking about the way a  
modern general consumer laptop is supposed to work. I have not looked  
at any of the code you're describing. What I heard (which seems  
consistent with a quick sanity check against wikipedia's 802.11d  
entry) is that the AP sends out the regulatory domain as part of the  
beacon, so laptops can read this information before transmitting  
anything back.

-- 
Scott Lamb <http://www.slamb.org/>




From dwmw2 at infradead.org  Sat Oct  7 05:59:00 2006
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sat, 07 Oct 2006 10:59:00 +0100
Subject: Marvell regulatory domain info storage?
In-Reply-To: <256DB250-0C32-4AD6-A118-0346447F5C88@slamb.org>
References: <1159714549.2721.15.camel@localhost.localdomain>
	<1159731166.6029.6.camel@localhost.localdomain>
	<4520AC07.3020209@firmworks.com>
	<1159796750.2834.2.camel@localhost.localdomain>
	<45260C4B.5020906@slamb.org>
	<1160173286.31043.43.camel@localhost.localdomain>
	<256DB250-0C32-4AD6-A118-0346447F5C88@slamb.org>
Message-ID: <1160215140.4795.79.camel@pmac.infradead.org>

On Fri, 2006-10-06 at 15:37 -0700, Scott Lamb wrote:
> I think my wording is at fault here. I'm talking about the way a  
> modern general consumer laptop is supposed to work. I have not
> looked  
> at any of the code you're describing. What I heard (which seems  
> consistent with a quick sanity check against wikipedia's 802.11d  
> entry) is that the AP sends out the regulatory domain as part of the  
> beacon, so laptops can read this information before transmitting  
> anything back.

That only works for passive scan, surely?

-- 
dwmw2



From javier at cozybit.com  Mon Oct  9 14:48:46 2006
From: javier at cozybit.com (Javier Cardona)
Date: Mon, 9 Oct 2006 11:48:46 -0700
Subject: Ability to set the 802.11s TTL for outgoing packets
In-Reply-To: <20061005003620.GA17768@ecstasy.ring2.lan>
References: <20061005003620.GA17768@ecstasy.ring2.lan>
Message-ID: <b211f6ec0610091148p4764f32kb890cc99a3508309@mail.gmail.com>

Hi Lennart,

The data frames in the current implementation of the libertas mesh
routing protocol do not include the newer Mesh Forwarding Control
field (where the TTL counter lives).  Instead, they are in the
standard 4-address WDS format, which is the format supported by the on
chip MAC controller.

However, a TTL counter is used in mesh management frames.  Management
frames are used to discover the routes used to forward unicast frames.
 The TTL counter in mgmt frames limits the number of hops that a route
request will travel.  Routing loops are possible in roots manually
created by users (and this would cause infinite retransmissions!), but
not in routes discovered by the mesh routing protocol.   This TTL is
now a compile time variable, but could be made available to the driver
if needed.

We are currently working with Marvell in implementing support for
in-mesh broadcast, for which we'll have to find a way to implement TTL
in data frames.  But until that is complete, broadcast requests are
not forwarded, and that could be just what you need:  in the current
released firmware, a broadcast frame will only reach its direct
neighbors.

In summary:

The TTL in data frames would determine how many hops a data packet
would travel.  This is not implemented yet.

The TTL in management frames determines how far a node will look for
nodes it has traffic for.  This is a compile time variable that could
easily be exported to userland.

In the current release, broadcast frames only reach a node's direct neighbors.

Please let me know what would be the requirements to support your mDNS
responder.

Javier

-- 
Javier Cardona
cozybit Inc.
e javier_AT_cozybit.com


From mzbycp at 0pointer.de  Mon Oct  9 16:00:22 2006
From: mzbycp at 0pointer.de (Lennart Poettering)
Date: Mon, 9 Oct 2006 22:00:22 +0200
Subject: Ability to set the 802.11s TTL for outgoing packets
In-Reply-To: <b211f6ec0610091148p4764f32kb890cc99a3508309@mail.gmail.com>
References: <20061005003620.GA17768@ecstasy.ring2.lan>
	<b211f6ec0610091148p4764f32kb890cc99a3508309@mail.gmail.com>
Message-ID: <20061009200021.GA9687@tango.0pointer.de>

On Mon, 09.10.06 11:48, Javier Cardona (javier at cozybit.com) wrote:

> Hi Lennart,

Hi!

> The data frames in the current implementation of the libertas mesh
> routing protocol do not include the newer Mesh Forwarding Control
> field (where the TTL counter lives).  Instead, they are in the
> standard 4-address WDS format, which is the format supported by the on
> chip MAC controller.

So OLPC isn't really implementing that protocol that shall become
802.11s?

> However, a TTL counter is used in mesh management frames.  Management
> frames are used to discover the routes used to forward unicast frames.
> The TTL counter in mgmt frames limits the number of hops that a route
> request will travel.  Routing loops are possible in roots manually
> created by users (and this would cause infinite retransmissions!), but
> not in routes discovered by the mesh routing protocol.   This TTL is
> now a compile time variable, but could be made available to the driver
> if needed.

I guess this mgmt TTL would not be usable for my work, since it would
globally limit the range for all outgoing packets, from all
applications, not just for those generated by Avahi.

> We are currently working with Marvell in implementing support for
> in-mesh broadcast, for which we'll have to find a way to implement TTL
> in data frames.  But until that is complete, broadcast requests are
> not forwarded, and that could be just what you need:  in the current
> released firmware, a broadcast frame will only reach its direct
> neighbors.

Broadcasts that are not forwarded at all might be an interim solution
for my problem. However, they will not suffice in the long term.

The protocol design I am currently working on (and which already works
quite well in a simulation) is based on having each node cooperating
with nodes found nearby. When a node boots up, it sends out a single
welcome packet with TTL=1 (broadcast) If noone responds it will raise
the TTL to 2, and retry, and so on. It will stop when it managed to
reach (i.e. get a response from) at least 10 other nodes, or so.

Simply because not every node will necessarily run Avahi (just
think of the case when the CPU is powered off, but the WLAN chip still
forwards traffic) I need to do those broadcasts/multicasts with a
TTL != 1. If every single node would run Avahi those TTL=1 broadcasts
would be sufficient. 

I guess for a start i can simply use those broadcasts for my work,
like you suggest, and simply assume that Avahi runs on every single
node, however in the long run I'd really like to make use of different
TTL values.

> In summary:
> 
> The TTL in data frames would determine how many hops a data packet
> would travel.  This is not implemented yet.

Do you have any idea when this will be available?

> The TTL in management frames determines how far a node will look for
> nodes it has traffic for.  This is a compile time variable that could
> easily be exported to userland.

While I am not going to use this in Avahi this might really make sense
to export to userspace, nonetheless.

> In the current release, broadcast frames only reach a node's direct 
> neighbors.
> 
> Please let me know what would be the requirements to support your mDNS
> responder.

All what I need is a way to reach just the hosts "nearby". Because the
CPU of nodes nearby might not be powered on or running Avahi I need
the functionality to broadcast with a TTL > 1.

It's not really important whether this is actually implemented with
multicasting or broadcasting. I assume that most of the OLPC machines
*will* run Avahi, hence in effect there is not much of a difference if
I send my packets with a broadcast or with a multicast.

Please note that I will never use large TTLs, i.e. those > 10. Hence,
a dirty solution could be to define some magic MAC addresses like
FF:FF:FF:FF:FF:FE which behave like a broadcast with TTL=1 and so
on. If you did this there wouldn't be a need to change the frame
format.

Something completely unrelated:

I am currently doing lots of simulations for my new protocol. For that
I generate random mesh networks. However, I am not quite sure what
parameters to choose for these networks. My job is to get Avahi to
scale for up to 10.000 hosts, so that's one parameter. I read
somehwere that the diameter of the mesh graph is expected to be low,
in the range of 4-5. Is this true? What about the degree of the the
vertices (in the sense of graph theory, i.e. the number of connected
other vertices)? What is the maximum degree of vertices that is
expected in real-world networks? What are the parameters the Marvell
hardware has been designed for?

One last thing: is cross-posting to the libertas and olpc-networking
mailing lists a good idea? I started this because I didn't know which
one to use, but perhaps we should move this thread to only one of
them. (probably libertas-dev?)

Thank you very much for your response!

Lennart

-- 
Lennart Poettering; lennart [at] poettering [dot] net
ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/


From javier at cozybit.com  Tue Oct 10 15:12:49 2006
From: javier at cozybit.com (Javier Cardona)
Date: Tue, 10 Oct 2006 12:12:49 -0700
Subject: Ability to set the 802.11s TTL for outgoing packets
In-Reply-To: <20061009200021.GA9687@tango.0pointer.de>
References: <20061005003620.GA17768@ecstasy.ring2.lan>
	<b211f6ec0610091148p4764f32kb890cc99a3508309@mail.gmail.com>
	<20061009200021.GA9687@tango.0pointer.de>
Message-ID: <b211f6ec0610101212v751214a2n2773d8d5965e4d69@mail.gmail.com>

Hi Lennart,

> So OLPC isn't really implementing that protocol that shall become
> 802.11s?

The intent is to follow 802.11s, yes.  Right now we have implemented a
subset of it such as the route discovery and path selection protocols,
which follow the HWMP protocol defined in Sec. 11A.4.3.1.1.  But some
things, like the new Type and Subtypes defined for Mesh Data (Sect
7.1.3.1.2), or the Mesh Forwarding Control field (Sect. 7.1.3.5a) are
not supported by the existing hardware.  The priority is to have
working firmware rather than full compatibility with a standard that's
still being developed.

Also, it's important to keep in mind that we are working from existing
code that we want to leverage as much as possible.  For instance, the
firmware is capable of acting simultaneously as a mesh node as well as
an infrastructure client.

> (...)
>
> > The TTL in data frames would determine how many hops a data packet
> > would travel.  This is not implemented yet.
>
> Do you have any idea when this will be available?

We are working on this right now.  I would say that there will be an
official release in two months or so.

> All what I need is a way to reach just the hosts "nearby". Because the
> CPU of nodes nearby might not be powered on or running Avahi I need
> the functionality to broadcast with a TTL > 1.
>
> It's not really important whether this is actually implemented with
> multicasting or broadcasting. I assume that most of the OLPC machines
> *will* run Avahi, hence in effect there is not much of a difference if
> I send my packets with a broadcast or with a multicast.
>
> Please note that I will never use large TTLs, i.e. those > 10. Hence,
> a dirty solution could be to define some magic MAC addresses like
> FF:FF:FF:FF:FF:FE which behave like a broadcast with TTL=1 and so
> on. If you did this there wouldn't be a need to change the frame
> format.

We will probably implement this as a sockopt, as you suggested earlier.

> I am currently doing lots of simulations for my new protocol. For that
> I generate random mesh networks. However, I am not quite sure what
> parameters to choose for these networks. My job is to get Avahi to
> scale for up to 10.000 hosts, so that's one parameter. I read
> somehwere that the diameter of the mesh graph is expected to be low,
> in the range of 4-5. Is this true? What about the degree of the the
> vertices (in the sense of graph theory, i.e. the number of connected
> other vertices)? What is the maximum degree of vertices that is
> expected in real-world networks? What are the parameters the Marvell
> hardware has been designed for?

The number's I've heard are around 2000 nodes, and I have no info
about the degree of the vertices.

> One last thing: is cross-posting to the libertas and olpc-networking
> mailing lists a good idea? I started this because I didn't know which
> one to use, but perhaps we should move this thread to only one of
> them. (probably libertas-dev?)

I don't know either ;)  So I'll just follow your lead for now...

Javier

-- 
Javier Cardona
cozybit Inc.
e javier_AT_cozybit.com


From mzbycp at 0pointer.de  Tue Oct 10 15:44:58 2006
From: mzbycp at 0pointer.de (Lennart Poettering)
Date: Tue, 10 Oct 2006 21:44:58 +0200
Subject: Ability to set the 802.11s TTL for outgoing packets
In-Reply-To: <b211f6ec0610101212v751214a2n2773d8d5965e4d69@mail.gmail.com>
References: <20061005003620.GA17768@ecstasy.ring2.lan>
	<b211f6ec0610091148p4764f32kb890cc99a3508309@mail.gmail.com>
	<20061009200021.GA9687@tango.0pointer.de>
	<b211f6ec0610101212v751214a2n2773d8d5965e4d69@mail.gmail.com>
Message-ID: <20061010194457.GB8137@tango.0pointer.de>

On Tue, 10.10.06 12:12, Javier Cardona (javier at cozybit.com) wrote:

Hi!

> > Please note that I will never use large TTLs, i.e. those > 10. Hence,
> > a dirty solution could be to define some magic MAC addresses like
> > FF:FF:FF:FF:FF:FE which behave like a broadcast with TTL=1 and so
> > on. If you did this there wouldn't be a need to change the frame
> > format.
> 
> We will probably implement this as a sockopt, as you suggested
> earlier.

OK, that sounds nice. BTW, besides the ability to set the TTL for
outgoing packets I'd need the ability to query the TTL for incoming
packets, too.

> > in the range of 4-5. Is this true? What about the degree of the the
> > vertices (in the sense of graph theory, i.e. the number of connected
> > other vertices)? What is the maximum degree of vertices that is
> > expected in real-world networks? What are the parameters the Marvell
> > hardware has been designed for?
> 
> The number's I've heard are around 2000 nodes, and I have no info
> about the degree of the vertices.

Could you point me to a guy who might know this? 

Or does anyone else on this ML have any idea?

There is another variable in my simulation that I don't know much
about. That is maximum amount of traffic I am allowed generate on each
link for my service discovery. The Marvell chip is 54Mbit, right? I
read somewhere that OLPC will use it in 2MBit mode only, to save
power. Is that correct? Do yo know how much of these 2Mbit will
practically be left for application use? I am assuming that I may use
10% of that at max. Yes, I know that this value is probably not useful
without knowing how many machines are part of a the cell, but if i
know the maximum degree of the vertices I'll know that too.

> > One last thing: is cross-posting to the libertas and olpc-networking
> > mailing lists a good idea? I started this because I didn't know which
> > one to use, but perhaps we should move this thread to only one of
> > them. (probably libertas-dev?)
> 
> I don't know either ;)  So I'll just follow your lead for now...

Mhm, since nobody is complaining I'll keep cross-posting. ;-)

Thanks, 
        Lennart

-- 
Lennart Poettering; lennart [at] poettering [dot] net
ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/


From ypod at media.mit.edu  Wed Oct 11 11:51:56 2006
From: ypod at media.mit.edu (Polychronis Ypodimatopoulos)
Date: Wed, 11 Oct 2006 11:51:56 -0400
Subject: OLPC boards in promiscuous mode
Message-ID: <452D131C.4030709@media.mit.edu>

Hello,

We are using 7 OLPC boards in promiscuous mode to capture all frames being sent by other nodes, using pcapy in Python. Nodes are in the same ad-hoc cloud with each other. Our application sends about up to 50 frames/sec. 

Initially, everything works fine, but after running for about 1 min, the wifi driver stops being as responsive (takes a long time to send a single frame) and frames captured by pcapy are garbled (they fail some digest check). At the moment that things start getting wrong, the following messages appears repeatedly in /var/log/messages:

Sep 30 20:00:02 dhcp-9-196 kernel: NETDEV WATCHDOG: eth0: transmit timed out

Finally, I also get the following in /var/log/messages:

BUG: rwlock bad magic on CPU#0, ifconfig/5882, c023eba0 (Not tainted)
 <c05c99e2> ip_check_mc+0x1c/0x7c  <c05a65b4> ip_route_input+0xdc/0xbf1
 <c82bae08> __ip_ct_refresh_acct+0xec/0x106 [ip_conntrack]  <c82bc191>
ip_conntrack_in+0x2f7/0x3bc [ip_conntrack]
 <c05ce914> fib_create_info+0x11e/0x97e  <c05a3d44> nf_iterate+0x38/0x6a
 <c05a885c> ip_rcv_finish+0x0/0x1fd  <c05a3e77> nf_hook_slow+0x4d/0xb5
 <c05a885c> ip_rcv_finish+0x0/0x1fd  <c05a8e85> ip_rcv+0x1f9/0x3d7
 <c05a885c> ip_rcv_finish+0x0/0x1fd  <c041e726> __mod_timer+0x8a/0x94
 <c058fad9> netif_receive_skb+0x20a/0x265  <c05911c2>
process_backlog+0x6e/0xec
 <c05912b8> net_rx_action+0x78/0x11b  <c041b313> __do_softirq+0x35/0x7f
 <c0404bb1> do_softirq+0x38/0x3f
 =======================
 <c0404b6e> do_IRQ+0x75/0x80  <c041cf8d> register_proc_table+0xc8/0xdc
 <c0402f3a> common_interrupt+0x1a/0x20  <c0428a7c> mutex_trylock+0x15c/0x169
 <c041cf8d> register_proc_table+0xc8/0xdc  <c041cfbe>
register_sysctl_table+0x1d/0xa2
 <c05cb866> ip_mc_init_dev+0xc/0xbb  <c041d03b>
register_sysctl_table+0x9a/0xa2
 <c05c77de> devinet_sysctl_register+0xf8/0x11f  <c05c79b8>
inetdev_init+0x101/0x127
 <c05c850f> devinet_ioctl+0x3a8/0x56c  <c04635ca> open_namei+0x7b/0x5d3
 <c0586dc0> sock_ioctl+0x1ae/0x1cd  <c0586c12> sock_ioctl+0x0/0x1cd
 <c0464629> do_ioctl+0x19/0x4c  <c046485b> vfs_ioctl+0x1ff/0x216
 <c04648be> sys_ioctl+0x4c/0x66  <c0402cc7> syscall_call+0x7/0xb


Running the same exact application (with the same data) on PCs with atheros chipsets yields absolutely no similar problems and the application behaves normally. The following is my OLPC board configuration:

Kernel: 2.6.16-1.2221_FC6 (rawhide)
Firmware: usb8388_A1_W8015FP14_FW2.bin

Thanks,

Polychronis Ypodimatopoulos
Viral Communications
MIT Media Lab









From dcbw at redhat.com  Mon Oct 16 10:41:47 2006
From: dcbw at redhat.com (Dan Williams)
Date: Mon, 16 Oct 2006 10:41:47 -0400
Subject: [PATCH] libertas: if_usb.c compile fix
Message-ID: <1161009707.27332.1.camel@localhost.localdomain>

Missing priv-> in 2 places.

Signed-off-by: Dan Williams <dcbw at redhat.com>

diff --git a/drivers/net/wireless/libertas/if_usb.c b/drivers/net/wireless/libertas/if_usb.c
index 2f7c552..cb58965 100644
--- a/drivers/net/wireless/libertas/if_usb.c
+++ b/drivers/net/wireless/libertas/if_usb.c
@@ -615,7 +615,7 @@ #define MRVDRV_MIN_PKT_LEN	30
 			break;
 		}
 
-		spin_lock_irqsave(&adapter->driver_lock, flags);
+		spin_lock_irqsave(&priv->adapter->driver_lock, flags);
 		/* take care of CurCmd = NULL case by reading the 
 		 * data to clear the interrupt */
 		if (!priv->adapter->CurCmd) {
@@ -629,7 +629,7 @@ #define MRVDRV_MIN_PKT_LEN	30
 		priv->wlan_dev.upld_len = (RecvLength - MESSAGE_HEADER_LEN);
 		memcpy(cmdBuf, RecvBuff + MESSAGE_HEADER_LEN,
 		       priv->wlan_dev.upld_len);
-		spin_unlock_irqrestore(&adapter->driver_lock, flags);
+		spin_unlock_irqrestore(&priv->adapter->driver_lock, flags);
 
 		kfree_skb(skb);
 




From mtosatti at redhat.com  Mon Oct 16 11:57:49 2006
From: mtosatti at redhat.com (Marcelo Tosatti)
Date: Mon, 16 Oct 2006 13:57:49 -0200
Subject: [PATCH] libertas: if_usb.c compile fix
In-Reply-To: <1161009707.27332.1.camel@localhost.localdomain>
References: <1161009707.27332.1.camel@localhost.localdomain>
Message-ID: <20061016155749.GA26175@dmt>

On Mon, Oct 16, 2006 at 10:41:47AM -0400, Dan Williams wrote:
> Missing priv-> in 2 places.

Already fixed in previous commit, thanks!

> 
> Signed-off-by: Dan Williams <dcbw at redhat.com>
> 
> diff --git a/drivers/net/wireless/libertas/if_usb.c b/drivers/net/wireless/libertas/if_usb.c
> index 2f7c552..cb58965 100644
> --- a/drivers/net/wireless/libertas/if_usb.c
> +++ b/drivers/net/wireless/libertas/if_usb.c
> @@ -615,7 +615,7 @@ #define MRVDRV_MIN_PKT_LEN	30
>  			break;
>  		}
>  
> -		spin_lock_irqsave(&adapter->driver_lock, flags);
> +		spin_lock_irqsave(&priv->adapter->driver_lock, flags);
>  		/* take care of CurCmd = NULL case by reading the 
>  		 * data to clear the interrupt */
>  		if (!priv->adapter->CurCmd) {
> @@ -629,7 +629,7 @@ #define MRVDRV_MIN_PKT_LEN	30
>  		priv->wlan_dev.upld_len = (RecvLength - MESSAGE_HEADER_LEN);
>  		memcpy(cmdBuf, RecvBuff + MESSAGE_HEADER_LEN,
>  		       priv->wlan_dev.upld_len);
> -		spin_unlock_irqrestore(&adapter->driver_lock, flags);
> +		spin_unlock_irqrestore(&priv->adapter->driver_lock, flags);
>  
>  		kfree_skb(skb);
>  
> 


From rick at efn.org  Mon Oct 16 17:07:20 2006
From: rick at efn.org (Rick Bronson)
Date: Mon, 16 Oct 2006 14:07:20 -0700
Subject: Dlink DWL-G122 Rev D
Message-ID: <E1GZZg8-0002Bs-00@amazonia>

Hi,

  I made some progress using the OLPC Libertas WiFi driver on the
Dlink DWL-G122 Rev D USB WiFi adapter but now I'm stuck.  Would anyone
have just a minute to look at http://www.efn.org/~rick/pub/debug.txt
and tell me where to go next?

  Any help is greatly appreciated!

  Rick


From rick at efn.org  Tue Oct 17 10:13:52 2006
From: rick at efn.org (Rick Bronson)
Date: Tue, 17 Oct 2006 07:13:52 -0700
Subject: Dlink DWL-G122 Rev D
In-Reply-To: <D1575D47310FC94D902C8675241E8E3E024C3A2E@msiexch01.marvell.com>
	(rchokshi@marvell.com)
References: <D1575D47310FC94D902C8675241E8E3E024C3A2E@msiexch01.marvell.com>
Message-ID: <E1GZphY-0001L7-00@amazonia>

Hi Ronak,

  Thanks very much for the help.

  It appears that it's a 8338 chip from the inf file:

[Marvell]
%MRVL8338.DeviceDesc% =  W8338USB.ndi.NT,USB\VID_1286&PID_1FA8
%MRVL833815.DeviceDesc% =  W833815USB.ndi.NT,USB\VID_1286&PID_1FAA
%MRVL833810.DeviceDesc% =  W833810USB.ndi.NT,USB\VID_07D1&PID_3B01

  The VID/PID is 07D1:3B01 so it matches the 3rd line above.

  Is this chip supported by the OLPC driver?

  I don't think it's downloading continuously, it's just that debug is
turned on and it shows every 512 byte block that gets sent.  After the
download happens the "Lnk" light comes on on the Dlink.  I take this
to mean that the download was successful.

  Thanks very much.

  Rick

> Hi Rick,
> 
> I am not sure whether the Dlink adapter has the same chipset as the OLPC
> WiFi module. In that case, the firmware may not work with this adapter.
> Any particular reason you are testing the OLPC WiFi driver with this
> adapter?
> 
> =20
> 
> Also, from the logs, it seems like your driver keeps downloading the
> firmware continuously - not sure what that is.
> 
> =20
> 
> Thanks=20
> 
> Ronak
> 
> -----Original Message-----
> From: libertas-dev-bounces at lists.infradead.org
> [mailto:libertas-dev-bounces at lists.infradead.org] On Behalf Of Rick
> Bronson
> Sent: Monday, October 16, 2006 2:07 PM
> To: libertas-dev at lists.infradead.org
> Subject: [BULK] Dlink DWL-G122 Rev D
> Importance: Low
> 
> =20
> 
> Hi,
> 
> =20
> 
>   I made some progress using the OLPC Libertas WiFi driver on the
> 
> Dlink DWL-G122 Rev D USB WiFi adapter but now I'm stuck.  Would anyone
> 
> have just a minute to look at http://www.efn.org/~rick/pub/debug.txt
> 
> and tell me where to go next?
> 
> =20
> 
>   Any help is greatly appreciated!
> 
> =20
> 
>   Rick
> 
> =20
> 
> _______________________________________________
> 
> libertas-dev mailing list
> 
> libertas-dev at lists.infradead.org
> 
> http://lists.infradead.org/mailman/listinfo/libertas-dev
> 
> 
> ------_=_NextPart_001_01C6F187.5F53BC85
> Content-Type: text/html;
> 	charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
> 
> <html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
> xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
> xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
> xmlns=3D"http://www.w3.org/TR/REC-html40">
> 
> <head>
> <meta http-equiv=3DContent-Type content=3D"text/html; =
> charset=3Dus-ascii">
> <meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
> <style>
> <!--
>  /* Font Definitions */
>  @font-face
> 	{font-family:"MS Mincho";
> 	panose-1:2 2 6 9 4 2 5 8 3 4;}
> @font-face
> 	{font-family:"\@MS Mincho";}
>  /* Style Definitions */
>  p.MsoNormal, li.MsoNormal, div.MsoNormal
> 	{margin:0in;
> 	margin-bottom:.0001pt;
> 	font-size:12.0pt;
> 	font-family:"Times New Roman";}
> a:link, span.MsoHyperlink
> 	{color:blue;
> 	text-decoration:underline;}
> a:visited, span.MsoHyperlinkFollowed
> 	{color:purple;
> 	text-decoration:underline;}
> p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
> 	{margin:0in;
> 	margin-bottom:.0001pt;
> 	font-size:10.0pt;
> 	font-family:"Courier New";}
> span.EmailStyle18
> 	{mso-style-type:personal;
> 	font-family:Arial;
> 	color:navy;}
> span.EmailStyle19
> 	{mso-style-type:personal;
> 	font-family:Arial;
> 	color:navy;}
> span.EmailStyle20
> 	{mso-style-type:personal;
> 	font-family:Arial;
> 	color:navy;}
> span.EmailStyle21
> 	{mso-style-type:personal-reply;
> 	font-family:Arial;
> 	color:navy;}
> @page Section1
> 	{size:8.5in 11.0in;
> 	margin:1.0in 77.95pt 1.0in 77.95pt;}
> div.Section1
> 	{page:Section1;}
> -->
> </style>
> 
> </head>
> 
> <body lang=3DEN-US link=3Dblue vlink=3Dpurple>
> 
> <div class=3DSection1>
> 
> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
> style=3D'font-size:
> 10.0pt;font-family:Arial;color:navy'>Hi =
> Rick,<o:p></o:p></span></font></p>
> 
> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
> style=3D'font-size:
> 10.0pt;font-family:Arial;color:navy'>I am not sure whether the Dlink =
> adapter
> has the same chipset as the OLPC WiFi module. In that case, the firmware =
> may not
> work with this adapter. Any particular reason you are testing the OLPC =
> WiFi
> driver with this adapter?<o:p></o:p></span></font></p>
> 
> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
> style=3D'font-size:
> 10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>
> 
> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
> style=3D'font-size:
> 10.0pt;font-family:Arial;color:navy'>Also, from the logs, it seems like =
> your driver
> keeps downloading the firmware continuously &#8211; not sure what that =
> is.<o:p></o:p></span></font></p>
> 
> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
> style=3D'font-size:
> 10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>
> 
> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
> style=3D'font-size:
> 10.0pt;font-family:Arial;color:navy'>Thanks =
> <o:p></o:p></span></font></p>
> 
> <div>
> 
> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
> style=3D'font-size:
> 10.0pt;font-family:Arial;color:navy'>Ronak</span></font><o:p></o:p></p>
> 
> </div>
> 
> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
> style=3D'font-size:
> 10.0pt'>-----Original Message-----<br>
> From: libertas-dev-bounces at lists.infradead.org
> [mailto:libertas-dev-bounces at lists.infradead.org] On Behalf Of Rick =
> Bronson<br>
> Sent: Monday, October 16, 2006 2:07 PM<br>
> To: libertas-dev at lists.infradead.org<br>
> Subject: [BULK] Dlink DWL-G122 Rev D<br>
> Importance: Low<o:p></o:p></span></font></p>
> 
> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
> style=3D'font-size:
> 10.0pt'><o:p>&nbsp;</o:p></span></font></p>
> 
> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
> style=3D'font-size:
> 10.0pt'>Hi,<o:p></o:p></span></font></p>
> 
> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
> style=3D'font-size:
> 10.0pt'><o:p>&nbsp;</o:p></span></font></p>
> 
> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
> style=3D'font-size:
> 10.0pt'>&nbsp; I made some progress using the OLPC Libertas WiFi driver =
> on the<o:p></o:p></span></font></p>
> 
> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
> style=3D'font-size:
> 10.0pt'>Dlink DWL-G122 Rev D USB WiFi adapter but now I'm stuck.&nbsp; =
> Would
> anyone<o:p></o:p></span></font></p>
> 
> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
> style=3D'font-size:
> 10.0pt'>have just a minute to look at =
> http://www.efn.org/~rick/pub/debug.txt<o:p></o:p></span></font></p>
> 
> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
> style=3D'font-size:
> 10.0pt'>and tell me where to go next?<o:p></o:p></span></font></p>
> 
> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
> style=3D'font-size:
> 10.0pt'><o:p>&nbsp;</o:p></span></font></p>
> 
> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
> style=3D'font-size:
> 10.0pt'>&nbsp; Any help is greatly =
> appreciated!<o:p></o:p></span></font></p>
> 
> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
> style=3D'font-size:
> 10.0pt'><o:p>&nbsp;</o:p></span></font></p>
> 
> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
> style=3D'font-size:
> 10.0pt'>&nbsp; Rick<o:p></o:p></span></font></p>
> 
> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
> style=3D'font-size:
> 10.0pt'><o:p>&nbsp;</o:p></span></font></p>
> 
> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
> style=3D'font-size:
> 10.0pt'>_______________________________________________<o:p></o:p></span>=
> </font></p>
> 
> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
> style=3D'font-size:
> 10.0pt'>libertas-dev mailing list<o:p></o:p></span></font></p>
> 
> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
> style=3D'font-size:
> 10.0pt'>libertas-dev at lists.infradead.org<o:p></o:p></span></font></p>
> 
> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
> style=3D'font-size:
> 10.0pt'>http://lists.infradead.org/mailman/listinfo/libertas-dev<o:p></o:=
> p></span></font></p>
> 
> </div>
> 
> </body>
> 
> </html>
> 
> ------_=_NextPart_001_01C6F187.5F53BC85--
> 


From dcbw at redhat.com  Tue Oct 17 10:46:30 2006
From: dcbw at redhat.com (Dan Williams)
Date: Tue, 17 Oct 2006 10:46:30 -0400
Subject: Dlink DWL-G122 Rev D
In-Reply-To: <E1GZphY-0001L7-00@amazonia>
References: <D1575D47310FC94D902C8675241E8E3E024C3A2E@msiexch01.marvell.com>
	<E1GZphY-0001L7-00@amazonia>
Message-ID: <1161096390.3737.1.camel@localhost.localdomain>

On Tue, 2006-10-17 at 07:13 -0700, Rick Bronson wrote:
> Hi Ronak,
> 
>   Thanks very much for the help.
> 
>   It appears that it's a 8338 chip from the inf file:

Hmm, OLPC uses an 8388, not an 8338.  Wrong chip maybe?

88w8388-bdk1 is the number on the actual chip itself.

Dan


> [Marvell]
> %MRVL8338.DeviceDesc% =  W8338USB.ndi.NT,USB\VID_1286&PID_1FA8
> %MRVL833815.DeviceDesc% =  W833815USB.ndi.NT,USB\VID_1286&PID_1FAA
> %MRVL833810.DeviceDesc% =  W833810USB.ndi.NT,USB\VID_07D1&PID_3B01
> 
>   The VID/PID is 07D1:3B01 so it matches the 3rd line above.
> 
>   Is this chip supported by the OLPC driver?
> 
>   I don't think it's downloading continuously, it's just that debug is
> turned on and it shows every 512 byte block that gets sent.  After the
> download happens the "Lnk" light comes on on the Dlink.  I take this
> to mean that the download was successful.
> 
>   Thanks very much.
> 
>   Rick
> 
> > Hi Rick,
> > 
> > I am not sure whether the Dlink adapter has the same chipset as the OLPC
> > WiFi module. In that case, the firmware may not work with this adapter.
> > Any particular reason you are testing the OLPC WiFi driver with this
> > adapter?
> > 
> > =20
> > 
> > Also, from the logs, it seems like your driver keeps downloading the
> > firmware continuously - not sure what that is.
> > 
> > =20
> > 
> > Thanks=20
> > 
> > Ronak
> > 
> > -----Original Message-----
> > From: libertas-dev-bounces at lists.infradead.org
> > [mailto:libertas-dev-bounces at lists.infradead.org] On Behalf Of Rick
> > Bronson
> > Sent: Monday, October 16, 2006 2:07 PM
> > To: libertas-dev at lists.infradead.org
> > Subject: [BULK] Dlink DWL-G122 Rev D
> > Importance: Low
> > 
> > =20
> > 
> > Hi,
> > 
> > =20
> > 
> >   I made some progress using the OLPC Libertas WiFi driver on the
> > 
> > Dlink DWL-G122 Rev D USB WiFi adapter but now I'm stuck.  Would anyone
> > 
> > have just a minute to look at http://www.efn.org/~rick/pub/debug.txt
> > 
> > and tell me where to go next?
> > 
> > =20
> > 
> >   Any help is greatly appreciated!
> > 
> > =20
> > 
> >   Rick
> > 
> > =20
> > 
> > _______________________________________________
> > 
> > libertas-dev mailing list
> > 
> > libertas-dev at lists.infradead.org
> > 
> > http://lists.infradead.org/mailman/listinfo/libertas-dev
> > 
> > 
> > ------_=_NextPart_001_01C6F187.5F53BC85
> > Content-Type: text/html;
> > 	charset="us-ascii"
> > Content-Transfer-Encoding: quoted-printable
> > 
> > <html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
> > xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
> > xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
> > xmlns=3D"http://www.w3.org/TR/REC-html40">
> > 
> > <head>
> > <meta http-equiv=3DContent-Type content=3D"text/html; =
> > charset=3Dus-ascii">
> > <meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
> > <style>
> > <!--
> >  /* Font Definitions */
> >  @font-face
> > 	{font-family:"MS Mincho";
> > 	panose-1:2 2 6 9 4 2 5 8 3 4;}
> > @font-face
> > 	{font-family:"\@MS Mincho";}
> >  /* Style Definitions */
> >  p.MsoNormal, li.MsoNormal, div.MsoNormal
> > 	{margin:0in;
> > 	margin-bottom:.0001pt;
> > 	font-size:12.0pt;
> > 	font-family:"Times New Roman";}
> > a:link, span.MsoHyperlink
> > 	{color:blue;
> > 	text-decoration:underline;}
> > a:visited, span.MsoHyperlinkFollowed
> > 	{color:purple;
> > 	text-decoration:underline;}
> > p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
> > 	{margin:0in;
> > 	margin-bottom:.0001pt;
> > 	font-size:10.0pt;
> > 	font-family:"Courier New";}
> > span.EmailStyle18
> > 	{mso-style-type:personal;
> > 	font-family:Arial;
> > 	color:navy;}
> > span.EmailStyle19
> > 	{mso-style-type:personal;
> > 	font-family:Arial;
> > 	color:navy;}
> > span.EmailStyle20
> > 	{mso-style-type:personal;
> > 	font-family:Arial;
> > 	color:navy;}
> > span.EmailStyle21
> > 	{mso-style-type:personal-reply;
> > 	font-family:Arial;
> > 	color:navy;}
> > @page Section1
> > 	{size:8.5in 11.0in;
> > 	margin:1.0in 77.95pt 1.0in 77.95pt;}
> > div.Section1
> > 	{page:Section1;}
> > -->
> > </style>
> > 
> > </head>
> > 
> > <body lang=3DEN-US link=3Dblue vlink=3Dpurple>
> > 
> > <div class=3DSection1>
> > 
> > <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
> > style=3D'font-size:
> > 10.0pt;font-family:Arial;color:navy'>Hi =
> > Rick,<o:p></o:p></span></font></p>
> > 
> > <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
> > style=3D'font-size:
> > 10.0pt;font-family:Arial;color:navy'>I am not sure whether the Dlink =
> > adapter
> > has the same chipset as the OLPC WiFi module. In that case, the firmware =
> > may not
> > work with this adapter. Any particular reason you are testing the OLPC =
> > WiFi
> > driver with this adapter?<o:p></o:p></span></font></p>
> > 
> > <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
> > style=3D'font-size:
> > 10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>
> > 
> > <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
> > style=3D'font-size:
> > 10.0pt;font-family:Arial;color:navy'>Also, from the logs, it seems like =
> > your driver
> > keeps downloading the firmware continuously &#8211; not sure what that =
> > is.<o:p></o:p></span></font></p>
> > 
> > <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
> > style=3D'font-size:
> > 10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>
> > 
> > <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
> > style=3D'font-size:
> > 10.0pt;font-family:Arial;color:navy'>Thanks =
> > <o:p></o:p></span></font></p>
> > 
> > <div>
> > 
> > <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
> > style=3D'font-size:
> > 10.0pt;font-family:Arial;color:navy'>Ronak</span></font><o:p></o:p></p>
> > 
> > </div>
> > 
> > <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
> > style=3D'font-size:
> > 10.0pt'>-----Original Message-----<br>
> > From: libertas-dev-bounces at lists.infradead.org
> > [mailto:libertas-dev-bounces at lists.infradead.org] On Behalf Of Rick =
> > Bronson<br>
> > Sent: Monday, October 16, 2006 2:07 PM<br>
> > To: libertas-dev at lists.infradead.org<br>
> > Subject: [BULK] Dlink DWL-G122 Rev D<br>
> > Importance: Low<o:p></o:p></span></font></p>
> > 
> > <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
> > style=3D'font-size:
> > 10.0pt'><o:p>&nbsp;</o:p></span></font></p>
> > 
> > <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
> > style=3D'font-size:
> > 10.0pt'>Hi,<o:p></o:p></span></font></p>
> > 
> > <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
> > style=3D'font-size:
> > 10.0pt'><o:p>&nbsp;</o:p></span></font></p>
> > 
> > <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
> > style=3D'font-size:
> > 10.0pt'>&nbsp; I made some progress using the OLPC Libertas WiFi driver =
> > on the<o:p></o:p></span></font></p>
> > 
> > <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
> > style=3D'font-size:
> > 10.0pt'>Dlink DWL-G122 Rev D USB WiFi adapter but now I'm stuck.&nbsp; =
> > Would
> > anyone<o:p></o:p></span></font></p>
> > 
> > <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
> > style=3D'font-size:
> > 10.0pt'>have just a minute to look at =
> > http://www.efn.org/~rick/pub/debug.txt<o:p></o:p></span></font></p>
> > 
> > <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
> > style=3D'font-size:
> > 10.0pt'>and tell me where to go next?<o:p></o:p></span></font></p>
> > 
> > <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
> > style=3D'font-size:
> > 10.0pt'><o:p>&nbsp;</o:p></span></font></p>
> > 
> > <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
> > style=3D'font-size:
> > 10.0pt'>&nbsp; Any help is greatly =
> > appreciated!<o:p></o:p></span></font></p>
> > 
> > <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
> > style=3D'font-size:
> > 10.0pt'><o:p>&nbsp;</o:p></span></font></p>
> > 
> > <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
> > style=3D'font-size:
> > 10.0pt'>&nbsp; Rick<o:p></o:p></span></font></p>
> > 
> > <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
> > style=3D'font-size:
> > 10.0pt'><o:p>&nbsp;</o:p></span></font></p>
> > 
> > <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
> > style=3D'font-size:
> > 10.0pt'>_______________________________________________<o:p></o:p></span>=
> > </font></p>
> > 
> > <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
> > style=3D'font-size:
> > 10.0pt'>libertas-dev mailing list<o:p></o:p></span></font></p>
> > 
> > <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
> > style=3D'font-size:
> > 10.0pt'>libertas-dev at lists.infradead.org<o:p></o:p></span></font></p>
> > 
> > <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
> > style=3D'font-size:
> > 10.0pt'>http://lists.infradead.org/mailman/listinfo/libertas-dev<o:p></o:=
> > p></span></font></p>
> > 
> > </div>
> > 
> > </body>
> > 
> > </html>
> > 
> > ------_=_NextPart_001_01C6F187.5F53BC85--
> > 
> 
> _______________________________________________
> libertas-dev mailing list
> libertas-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libertas-dev



From dwmw2 at infradead.org  Tue Oct 17 12:49:05 2006
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 17 Oct 2006 17:49:05 +0100
Subject: Mailer problems
Message-ID: <1161103745.23666.90.camel@hades.cambridge.redhat.com>

Please remember that the libertas-dev list does not accept HTML mail,
and it does not accept replies from broken mailers which break threading
by omitting the References: headers which RFC2822 says you should have.

You should make sure that you have HTML mail disabled when posting to
the list (in fact, just disabling it in general is best). You should
also read http://david.woodhou.se/email.html and attempt to conform to
the other guidelines there.

The level of traffic on this particular list is low enough that if we
_really_ have to, we could get away with disabling the check on the
threading breakage. It's not ideal, but it wouldn't be so unworkable. A
while ago, I suggested that if Marvell is _really_ unable to conform to
basic mail standards, I could do that. I seem to recall that someone was
going consult with your IT folks and get back to me about that -- but
you haven't done so, and you're still using broken software.

Please, either fix your broken software or use something non-broken.
Failing that, tell me that you are unable to conform to the RFCs and
I'll put in a workaround for it as I suggested before.

Please _don't_ just keep posting messages to the list that it doesn't
accept, and ignoring the rejections.

-- 
dwmw2



From rick at efn.org  Tue Oct 17 16:21:31 2006
From: rick at efn.org (Rick Bronson)
Date: Tue, 17 Oct 2006 13:21:31 -0700
Subject: Dlink DWL-G122 Rev D
In-Reply-To: <D1575D47310FC94D902C8675241E8E3E024C3B2F@msiexch01.marvell.com>
	(rchokshi@marvell.com)
References: <D1575D47310FC94D902C8675241E8E3E024C3B2F@msiexch01.marvell.com>
Message-ID: <E1GZvRL-0002CR-00@amazonia>

Ronak,

  I noticed that both the 8388 and the 8338 are both in the libertas
family.  Could the OLPC driver be made to work with the 8338 or would
that be a huge task?

  Rick


> Hmm, OLPC uses an 8388, not an 8338.  Wrong chip maybe?
> 
> =20
> 
> >> Yes, a different chip. The OLPC driver is not at all designed to work
> with this chip.
> 
> =20
> 
> Ronak
> 
> =20


From rchokshi at marvell.com  Tue Oct 17 17:38:33 2006
From: rchokshi at marvell.com (Ronak Chokshi)
Date: Tue, 17 Oct 2006 14:38:33 -0700
Subject: Dlink DWL-G122 Rev D
Message-ID: <D1575D47310FC94D902C8675241E8E3E024C3D54@msiexch01.marvell.com>

Hi Rick,
This will be a substantial task. The RAM where the firmware resides, in
both of these chips are of different sizes. 8388 has a larger one and
8338 has a very small. Hence, the firmware designed for 8388 will not
load on the 8338 part. Several other blocks on the SoC are different
too, although they are of the same family.

Thanks 
Ronak

-----Original Message-----
From: libertas-dev-bounces at lists.infradead.org
[mailto:libertas-dev-bounces at lists.infradead.org] On Behalf Of Rick
Bronson
Sent: Tuesday, October 17, 2006 1:22 PM
To: libertas-dev at lists.infradead.org
Subject: Re: Dlink DWL-G122 Rev D
Importance: Low

Ronak,

  I noticed that both the 8388 and the 8338 are both in the libertas
family.  Could the OLPC driver be made to work with the 8338 or would
that be a huge task?

  Rick


> Hmm, OLPC uses an 8388, not an 8338.  Wrong chip maybe?
> 
> =20
> 
> >> Yes, a different chip. The OLPC driver is not at all designed to
work
> with this chip.
> 
> =20
> 
> Ronak
> 
> =20

_______________________________________________
libertas-dev mailing list
libertas-dev at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/libertas-dev


From rick at efn.org  Tue Oct 17 17:50:32 2006
From: rick at efn.org (Rick Bronson)
Date: Tue, 17 Oct 2006 14:50:32 -0700
Subject: Dlink DWL-G122 Rev D
In-Reply-To: <D1575D47310FC94D902C8675241E8E3E024C3D54@msiexch01.marvell.com>
	(rchokshi@marvell.com)
References: <D1575D47310FC94D902C8675241E8E3E024C3D54@msiexch01.marvell.com>
Message-ID: <E1GZwpU-0002O3-00@amazonia>

Ronak,

  One last question.

  Assuming I have the right firmware (extracted from the *.sys file)
for this part and assuming that the unit is downloaded and running
(the "Lnk" light comes on), then would it be a big task?  In other
words is the USB API a lot different between the 8338 and the 8388?

  Thanks,

  Rick

> Hi Rick,
> This will be a substantial task. The RAM where the firmware resides, in
> both of these chips are of different sizes. 8388 has a larger one and
> 8338 has a very small. Hence, the firmware designed for 8388 will not
> load on the 8338 part. Several other blocks on the SoC are different
> too, although they are of the same family.
> 
> Thanks 
> Ronak
> 
> -----Original Message-----
> From: libertas-dev-bounces at lists.infradead.org
> [mailto:libertas-dev-bounces at lists.infradead.org] On Behalf Of Rick
> Bronson
> Sent: Tuesday, October 17, 2006 1:22 PM
> To: libertas-dev at lists.infradead.org
> Subject: Re: Dlink DWL-G122 Rev D
> Importance: Low
> 
> Ronak,
> 
>   I noticed that both the 8388 and the 8338 are both in the libertas
> family.  Could the OLPC driver be made to work with the 8338 or would
> that be a huge task?
> 
>   Rick
> 
> 
> > Hmm, OLPC uses an 8388, not an 8338.  Wrong chip maybe?
> > 
> > =20
> > 
> > >> Yes, a different chip. The OLPC driver is not at all designed to
> work
> > with this chip.
> > 
> > =20
> > 
> > Ronak
> > 
> > =20
> 
> _______________________________________________
> libertas-dev mailing list
> libertas-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libertas-dev
> 


From rchokshi at marvell.com  Tue Oct 17 17:55:44 2006
From: rchokshi at marvell.com (Ronak Chokshi)
Date: Tue, 17 Oct 2006 14:55:44 -0700
Subject: Dlink DWL-G122 Rev D
Message-ID: <D1575D47310FC94D902C8675241E8E3E024C3D8A@msiexch01.marvell.com>

Rick,
The API is also very different between the two. The software stack on
both look completely different. There is a separate team of engineers
who have designed the software stack on 8338.

Ronak

-----Original Message-----
From: Rick Bronson [mailto:rick at efn.org] 
Sent: Tuesday, October 17, 2006 2:51 PM
To: Ronak Chokshi
Cc: libertas-dev at lists.infradead.org
Subject: Re: Dlink DWL-G122 Rev D

Ronak,

  One last question.

  Assuming I have the right firmware (extracted from the *.sys file)
for this part and assuming that the unit is downloaded and running
(the "Lnk" light comes on), then would it be a big task?  In other
words is the USB API a lot different between the 8338 and the 8388?

  Thanks,

  Rick

> Hi Rick,
> This will be a substantial task. The RAM where the firmware resides,
in
> both of these chips are of different sizes. 8388 has a larger one and
> 8338 has a very small. Hence, the firmware designed for 8388 will not
> load on the 8338 part. Several other blocks on the SoC are different
> too, although they are of the same family.
> 
> Thanks 
> Ronak
> 
> -----Original Message-----
> From: libertas-dev-bounces at lists.infradead.org
> [mailto:libertas-dev-bounces at lists.infradead.org] On Behalf Of Rick
> Bronson
> Sent: Tuesday, October 17, 2006 1:22 PM
> To: libertas-dev at lists.infradead.org
> Subject: Re: Dlink DWL-G122 Rev D
> Importance: Low
> 
> Ronak,
> 
>   I noticed that both the 8388 and the 8338 are both in the libertas
> family.  Could the OLPC driver be made to work with the 8338 or would
> that be a huge task?
> 
>   Rick
> 
> 
> > Hmm, OLPC uses an 8388, not an 8338.  Wrong chip maybe?
> > 
> > =20
> > 
> > >> Yes, a different chip. The OLPC driver is not at all designed to
> work
> > with this chip.
> > 
> > =20
> > 
> > Ronak
> > 
> > =20
> 
> _______________________________________________
> libertas-dev mailing list
> libertas-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libertas-dev
> 


From dpreed at reed.com  Wed Oct 18 10:24:09 2006
From: dpreed at reed.com (David P. Reed)
Date: Wed, 18 Oct 2006 10:24:09 -0400
Subject: OLPC boards in promiscuous mode
In-Reply-To: <D1575D47310FC94D902C8675241E8E3E024C385E@msiexch01.marvell.com>
References: <D1575D47310FC94D902C8675241E8E3E024C385E@msiexch01.marvell.com>
Message-ID: <45363909.4050203@reed.com>

Is there any reason we cannot get the source code for the firmware right 
now? To be honest, we are doing what we are doing on the OLPC hardware 
based on the presumption that we will have full and open access to 
change the firmware functionality, and not have to depend on Marvell to 
decide what we should and shouldn't want.

the 4.5 second routing response is just not at all what we want - our 
nodes are riding on elevators and passing by while people are carrying 
them walking and on bicycles. Our use is not "fixed wireless". That may 
be what OLPC thinks it needs today, but I suspect even that thought will 
prove wrong in the "wild".


Ronak Chokshi wrote:
>
> That?s correct.
>
> Ronak
>
> ------------------------------------------------------------------------
>
> *From:* Michail Bletsas [mailto:mbletsas at laptop.org]
> *Sent:* Monday, October 16, 2006 1:11 PM
> *To:* Ronak Chokshi
> *Cc:* Aswath Mohan; David P. Reed; libertas-dev at lists.infradead.org; 
> Andrew Lippman; Nadav Aharony; Polychronis Ypodimatopoulos
> *Subject:* RE: OLPC boards in promiscuous mode
>
>
> Ronak,
>
> Then in his case, he should be using the "plain" WiFi firmware. Correct?
>
> M.
>
>
>
> *"Ronak Chokshi" <rchokshi at marvell.com>*
>
> 10/16/2006 04:07 PM
>
> 	
>
> To
>
> 	
>
> "Polychronis Ypodimatopoulos" <ypod at MIT.EDU>
>
> cc
>
> 	
>
> <libertas-dev at lists.infradead.org>, "David P. Reed" <dpreed at reed.com>, 
> "Andrew Lippman" <lip at media.mit.edu>, "Michail Bletsas" 
> <mbletsas at laptop.org>, "Nadav Aharony" <nadav at MIT.EDU>, "Aswath Mohan" 
> <amohan at marvell.com>
>
> Subject
>
> 	
>
> RE: OLPC boards in promiscuous mode
>
> 	
>
>
>
>
> Hi Polychronis,
> Sorry for the delay. This is expected behavior for the firmware that 
> you are using. The packet loss is because, approx. every 4.5 seconds, 
> the routes in the nodes expire. This is by design. As a result, the 
> individual nodes kick off a new Route Request packet to find the next 
> hop towards the final destination MAC address (DA) even if it is one 
> hop away. The Route Req and Route Reply take a finite time to transmit 
> and then to process and hence this results in the delay in the packet 
> transfers and thereafter in ping losses. This is initial algorithm 
> that we have designed and implemented and has been heavily geared 
> towards link reliability/stability/freshness. We will be making 
> further modifications (including fine tuning the time mentioned above) 
> to make it more robust and hence to minimize such packet losses.
>
> Hope this helps.
>
> Thanks
> Ronak
>
> ------------------------------------------------------------------------
>
>
> *From:* Polychronis Ypodimatopoulos [mailto:ypod at MIT.EDU] *
> Sent:* Wednesday, October 11, 2006 7:04 PM*
> To:* Ronak Chokshi*
> Cc:* libertas-dev at lists.infradead.org; David P. Reed; Andrew Lippman; 
> Michail Bletsas; Nadav Aharony; Polychronis Ypodimatopoulos*
> Subject:* Re: OLPC boards in promiscuous mode
>
> Hello Ronak,
>
> Thanks for your response.
> I installed the new firmware on 3 of the laptops. The errors have gone 
> away, but most of the problems are still here.
>
> I did a simple test to show that using the new firmware (usb8388.bin 
> USB 8388 Release for MRP 
> <http://www.marvell.com/drivers/driverDisplay.do?dId=164&pId=38>), as 
> opposed to the old one (usb8388_A1_W8015FP14_FW2.bin) has made things 
> somewhat worse.
>
> Machines A,B,C have the new firmware and machines D,E,F have the old 
> firmware, a total of 6 machines.
> I 'm concurrently pinging as follows:
> A to B
> B to C
> C to A
>
> And also the other group:
> D to E
> E to F
> F to D
>
> The following table summarizes ping results for each node of the two 
> groups:
> ====================================
> pair total time average time
> ------------------------------------
> A to B 225.43
> B to C 47.59 153.29
> C to A 186.84
> ------------------------------------
> D to E 58.45
> E to F 57.33 55.55
> F to D 50.86
> ====================================
>
> I should note that the only difference between the two groups of 
> machines is only the firmware being used.
> Finally, I also tried to concurrently ssh from one machine to another, 
> in the same pattern as the ping.
> In the second group (old firmware) I managed to ssh to each successive 
> machine in reasonable times. In the first group I was never given a 
> prompt to enter the password of the next machine in the circle!
>
> During all tests, I was using ssh to login to each of the six machines 
> through a USB wired interface. I was issuing commands to all three 
> machines of the two groups by sending tty input to all three sessions 
> of each group concurrently.
>
> Best
> Polychronis
>
>
> PS What follows is a detailed list of the ping commands.
>
> Ping results of A (10.0.9.132):
> [root at olpc1 ~]# ping 10.0.7.221 -c20
> PING 10.0.7.221 (10.0.7.221) 56(84) bytes of data.
> 64 bytes from 10.0.7.221: icmp_seq=4 ttl=64 time=3.98 ms
> 64 bytes from 10.0.7.221: icmp_seq=5 ttl=64 time=3.80 ms
> 64 bytes from 10.0.7.221: icmp_seq=6 ttl=64 time=3.88 ms
> 64 bytes from 10.0.7.221: icmp_seq=7 ttl=64 time=60.1 ms
> 64 bytes from 10.0.7.221: icmp_seq=10 ttl=64 time=4.41 ms
> 64 bytes from 10.0.7.221: icmp_seq=11 ttl=64 time=3.81 ms
> 64 bytes from 10.0.7.221: icmp_seq=12 ttl=64 time=4.96 ms
> 64 bytes from 10.0.7.221: icmp_seq=13 ttl=64 time=63.2 ms
> 64 bytes from 10.0.7.221: icmp_seq=16 ttl=64 time=4.00 ms
> 64 bytes from 10.0.7.221: icmp_seq=17 ttl=64 time=3.90 ms
> 64 bytes from 10.0.7.221: icmp_seq=18 ttl=64 time=3.99 ms
> 64 bytes from 10.0.7.221: icmp_seq=19 ttl=64 time=65.4 ms
>
> --- 10.0.7.221 ping statistics ---
> 20 packets transmitted, 12 received, 40% packet loss, time 19011ms
> rtt min/avg/max/mdev = 3.809/18.804/65.464/25.516 ms
>
>
> Ping results of B (10.0.7.221):
> [root at olpc3 ~]# ping 10.0.8.204 -c20
> PING 10.0.8.204 (10.0.8.204) 56(84) bytes of data.
> 64 bytes from 10.0.8.204: icmp_seq=3 ttl=64 time=4.19 ms
> 64 bytes from 10.0.8.204: icmp_seq=4 ttl=64 time=3.84 ms
> 64 bytes from 10.0.8.204: icmp_seq=5 ttl=64 time=3.87 ms
> 64 bytes from 10.0.8.204: icmp_seq=6 ttl=64 time=3.89 ms
> 64 bytes from 10.0.8.204: icmp_seq=9 ttl=64 time=4.82 ms
> 64 bytes from 10.0.8.204: icmp_seq=10 ttl=64 time=3.85 ms
> 64 bytes from 10.0.8.204: icmp_seq=11 ttl=64 time=3.87 ms
> 64 bytes from 10.0.8.204: icmp_seq=12 ttl=64 time=3.89 ms
> 64 bytes from 10.0.8.204: icmp_seq=15 ttl=64 time=3.83 ms
> 64 bytes from 10.0.8.204: icmp_seq=16 ttl=64 time=3.85 ms
> 64 bytes from 10.0.8.204: icmp_seq=17 ttl=64 time=3.87 ms
> 64 bytes from 10.0.8.204: icmp_seq=18 ttl=64 time=3.82 ms
>
> --- 10.0.8.204 ping statistics ---
> 20 packets transmitted, 12 received, 40% packet loss, time 19010ms
> rtt min/avg/max/mdev = 3.823/3.970/4.829/0.284 ms
>
>
>
> Ping results of C (10.0.8.204):
> [root at olpc4 ~]# ping 10.0.9.132 -c20
> PING 10.0.9.132 (10.0.9.132) 56(84) bytes of data.
> 64 bytes from 10.0.9.132: icmp_seq=3 ttl=64 time=3.91 ms
> 64 bytes from 10.0.9.132: icmp_seq=4 ttl=64 time=3.59 ms
> 64 bytes from 10.0.9.132: icmp_seq=5 ttl=64 time=3.61 ms
> 64 bytes from 10.0.9.132: icmp_seq=6 ttl=64 time=3.63 ms
> 64 bytes from 10.0.9.132: icmp_seq=10 ttl=64 time=3.61 ms
> 64 bytes from 10.0.9.132: icmp_seq=11 ttl=64 time=9.36 ms
> 64 bytes from 10.0.9.132: icmp_seq=12 ttl=64 time=4.61 ms
> 64 bytes from 10.0.9.132: icmp_seq=14 ttl=64 time=72.6 ms
> 64 bytes from 10.0.9.132: icmp_seq=16 ttl=64 time=3.59 ms
> 64 bytes from 10.0.9.132: icmp_seq=17 ttl=64 time=3.61 ms
> 64 bytes from 10.0.9.132: icmp_seq=18 ttl=64 time=3.62 ms
> 64 bytes from 10.0.9.132: icmp_seq=20 ttl=64 time=71.1 ms
>
> --- 10.0.9.132 ping statistics ---
> 20 packets transmitted, 12 received, 40% packet loss, time 19012ms
> rtt min/avg/max/mdev = 3.591/15.582/72.673/25.236 ms
>
>
>
> Ping results of D (10.0.9.87):
> [root at olpc5 inet]# ping 10.0.9.1 -c20
> PING 10.0.9.1 (10.0.9.1) 56(84) bytes of data.
> 64 bytes from 10.0.9.1: icmp_seq=1 ttl=64 time=8.30 ms
> 64 bytes from 10.0.9.1: icmp_seq=2 ttl=64 time=2.75 ms
> 64 bytes from 10.0.9.1: icmp_seq=3 ttl=64 time=2.42 ms
> 64 bytes from 10.0.9.1: icmp_seq=4 ttl=64 time=2.45 ms
> 64 bytes from 10.0.9.1: icmp_seq=5 ttl=64 time=2.97 ms
> 64 bytes from 10.0.9.1: icmp_seq=6 ttl=64 time=4.14 ms
> 64 bytes from 10.0.9.1: icmp_seq=7 ttl=64 time=4.36 ms
> 64 bytes from 10.0.9.1: icmp_seq=8 ttl=64 time=2.39 ms
> 64 bytes from 10.0.9.1: icmp_seq=9 ttl=64 time=2.37 ms
> 64 bytes from 10.0.9.1: icmp_seq=10 ttl=64 time=2.34 ms
> 64 bytes from 10.0.9.1: icmp_seq=11 ttl=64 time=2.34 ms
> 64 bytes from 10.0.9.1: icmp_seq=12 ttl=64 time=2.51 ms
> 64 bytes from 10.0.9.1: icmp_seq=13 ttl=64 time=2.38 ms
> 64 bytes from 10.0.9.1: icmp_seq=14 ttl=64 time=2.43 ms
> 64 bytes from 10.0.9.1: icmp_seq=15 ttl=64 time=2.31 ms
> 64 bytes from 10.0.9.1: icmp_seq=16 ttl=64 time=2.46 ms
> 64 bytes from 10.0.9.1: icmp_seq=17 ttl=64 time=2.49 ms
> 64 bytes from 10.0.9.1: icmp_seq=18 ttl=64 time=2.40 ms
> 64 bytes from 10.0.9.1: icmp_seq=19 ttl=64 time=2.19 ms
> 64 bytes from 10.0.9.1: icmp_seq=20 ttl=64 time=2.45 ms
>
> --- 10.0.9.1 ping statistics ---
> 20 packets transmitted, 20 received, 0% packet loss, time 19003ms
> rtt min/avg/max/mdev = 2.198/2.927/8.303/1.356 ms
>
>
> Ping results of E (10.0.9.1):
> [root at olpc6 inet]# ping 10.0.8.2 -c20
> PING 10.0.8.2 (10.0.8.2) 56(84) bytes of data.
> 64 bytes from 10.0.8.2: icmp_seq=1 ttl=64 time=6.22 ms
> 64 bytes from 10.0.8.2: icmp_seq=2 ttl=64 time=7.66 ms
> 64 bytes from 10.0.8.2: icmp_seq=3 ttl=64 time=2.75 ms
> 64 bytes from 10.0.8.2: icmp_seq=4 ttl=64 time=1.89 ms
> 64 bytes from 10.0.8.2: icmp_seq=5 ttl=64 time=3.68 ms
> 64 bytes from 10.0.8.2: icmp_seq=6 ttl=64 time=2.70 ms
> 64 bytes from 10.0.8.2: icmp_seq=7 ttl=64 time=2.46 ms
> 64 bytes from 10.0.8.2: icmp_seq=8 ttl=64 time=2.49 ms
> 64 bytes from 10.0.8.2: icmp_seq=9 ttl=64 time=1.90 ms
> 64 bytes from 10.0.8.2: icmp_seq=10 ttl=64 time=2.40 ms
> 64 bytes from 10.0.8.2: icmp_seq=11 ttl=64 time=2.95 ms
> 64 bytes from 10.0.8.2: icmp_seq=12 ttl=64 time=2.58 ms
> 64 bytes from 10.0.8.2: icmp_seq=13 ttl=64 time=2.48 ms
> 64 bytes from 10.0.8.2: icmp_seq=14 ttl=64 time=1.89 ms
> 64 bytes from 10.0.8.2: icmp_seq=15 ttl=64 time=1.90 ms
> 64 bytes from 10.0.8.2: icmp_seq=16 ttl=64 time=2.55 ms
> 64 bytes from 10.0.8.2: icmp_seq=17 ttl=64 time=2.45 ms
> 64 bytes from 10.0.8.2: icmp_seq=18 ttl=64 time=2.47 ms
> 64 bytes from 10.0.8.2: icmp_seq=19 ttl=64 time=2.00 ms
> 64 bytes from 10.0.8.2: icmp_seq=20 ttl=64 time=1.91 ms
>
> --- 10.0.8.2 ping statistics ---
> 20 packets transmitted, 20 received, 0% packet loss, time 19003ms
> rtt min/avg/max/mdev = 1.892/2.871/7.665/1.441 ms
>
>
> Ping results of F (10.0.8.2):
> [root at olpc7 inet]# ping 10.0.9.87 -c20
> PING 10.0.9.87 (10.0.9.87) 56(84) bytes of data.
> 64 bytes from 10.0.9.87: icmp_seq=1 ttl=64 time=2.41 ms
> 64 bytes from 10.0.9.87: icmp_seq=2 ttl=64 time=5.47 ms
> 64 bytes from 10.0.9.87: icmp_seq=3 ttl=64 time=1.96 ms
> 64 bytes from 10.0.9.87: icmp_seq=4 ttl=64 time=1.97 ms
> 64 bytes from 10.0.9.87: icmp_seq=5 ttl=64 time=2.00 ms
> 64 bytes from 10.0.9.87: icmp_seq=6 ttl=64 time=6.13 ms
> 64 bytes from 10.0.9.87: icmp_seq=7 ttl=64 time=5.16 ms
> 64 bytes from 10.0.9.87: icmp_seq=8 ttl=64 time=1.93 ms
> 64 bytes from 10.0.9.87: icmp_seq=9 ttl=64 time=2.47 ms
> 64 bytes from 10.0.9.87: icmp_seq=10 ttl=64 time=1.99 ms
> 64 bytes from 10.0.9.87: icmp_seq=11 ttl=64 time=2.01 ms
> 64 bytes from 10.0.9.87: icmp_seq=12 ttl=64 time=1.90 ms
> 64 bytes from 10.0.9.87: icmp_seq=13 ttl=64 time=1.93 ms
> 64 bytes from 10.0.9.87: icmp_seq=14 ttl=64 time=1.96 ms
> 64 bytes from 10.0.9.87: icmp_seq=15 ttl=64 time=1.98 ms
> 64 bytes from 10.0.9.87: icmp_seq=16 ttl=64 time=1.87 ms
> 64 bytes from 10.0.9.87: icmp_seq=17 ttl=64 time=1.89 ms
> 64 bytes from 10.0.9.87: icmp_seq=18 ttl=64 time=1.92 ms
> 64 bytes from 10.0.9.87: icmp_seq=19 ttl=64 time=1.94 ms
> 64 bytes from 10.0.9.87: icmp_seq=20 ttl=64 time=1.97 ms
>
> --- 10.0.9.87 ping statistics ---
> 20 packets transmitted, 20 received, 0% packet loss, time 19000ms
> rtt min/avg/max/mdev = 1.878/2.545/6.133/1.297 ms
>
>
>
>
>
>
>
>
>
>


From mtosatti at redhat.com  Wed Oct 18 12:55:22 2006
From: mtosatti at redhat.com (Marcelo Tosatti)
Date: Wed, 18 Oct 2006 14:55:22 -0200
Subject: OLPC boards in promiscuous mode
In-Reply-To: <452D131C.4030709@media.mit.edu>
References: <452D131C.4030709@media.mit.edu>
Message-ID: <20061018165522.GA2523@dmt>

On Wed, Oct 11, 2006 at 11:51:56AM -0400, Polychronis Ypodimatopoulos wrote:
> Hello,
> 
> We are using 7 OLPC boards in promiscuous mode to capture all frames being sent by other nodes, using pcapy in Python. Nodes are in the same ad-hoc cloud with each other. Our application sends about up to 50 frames/sec. 
> 
> Initially, everything works fine, but after running for about 1 min, the wifi driver stops being as responsive (takes a long time to send a single frame) and frames captured by pcapy are garbled (they fail some digest check). At the moment that things start getting wrong, the following messages appears repeatedly in /var/log/messages:
> 
> Sep 30 20:00:02 dhcp-9-196 kernel: NETDEV WATCHDOG: eth0: transmit timed out
> 
> Finally, I also get the following in /var/log/messages:
> 
> BUG: rwlock bad magic on CPU#0, ifconfig/5882, c023eba0 (Not tainted)
>  <c05c99e2> ip_check_mc+0x1c/0x7c  <c05a65b4> ip_route_input+0xdc/0xbf1
>  <c82bae08> __ip_ct_refresh_acct+0xec/0x106 [ip_conntrack]  <c82bc191>
> ip_conntrack_in+0x2f7/0x3bc [ip_conntrack]
>  <c05ce914> fib_create_info+0x11e/0x97e  <c05a3d44> nf_iterate+0x38/0x6a
>  <c05a885c> ip_rcv_finish+0x0/0x1fd  <c05a3e77> nf_hook_slow+0x4d/0xb5
>  <c05a885c> ip_rcv_finish+0x0/0x1fd  <c05a8e85> ip_rcv+0x1f9/0x3d7
>  <c05a885c> ip_rcv_finish+0x0/0x1fd  <c041e726> __mod_timer+0x8a/0x94
>  <c058fad9> netif_receive_skb+0x20a/0x265  <c05911c2>
> process_backlog+0x6e/0xec
>  <c05912b8> net_rx_action+0x78/0x11b  <c041b313> __do_softirq+0x35/0x7f
>  <c0404bb1> do_softirq+0x38/0x3f
>  =======================
>  <c0404b6e> do_IRQ+0x75/0x80  <c041cf8d> register_proc_table+0xc8/0xdc
>  <c0402f3a> common_interrupt+0x1a/0x20  <c0428a7c> mutex_trylock+0x15c/0x169
>  <c041cf8d> register_proc_table+0xc8/0xdc  <c041cfbe>
> register_sysctl_table+0x1d/0xa2
>  <c05cb866> ip_mc_init_dev+0xc/0xbb  <c041d03b>
> register_sysctl_table+0x9a/0xa2
>  <c05c77de> devinet_sysctl_register+0xf8/0x11f  <c05c79b8>
> inetdev_init+0x101/0x127
>  <c05c850f> devinet_ioctl+0x3a8/0x56c  <c04635ca> open_namei+0x7b/0x5d3
>  <c0586dc0> sock_ioctl+0x1ae/0x1cd  <c0586c12> sock_ioctl+0x0/0x1cd
>  <c0464629> do_ioctl+0x19/0x4c  <c046485b> vfs_ioctl+0x1ff/0x216
>  <c04648be> sys_ioctl+0x4c/0x66  <c0402cc7> syscall_call+0x7/0xb
> 
> 
> Running the same exact application (with the same data) on PCs with atheros chipsets yields absolutely no similar problems and the application behaves normally. The following is my OLPC board configuration:
> 
> Kernel: 2.6.16-1.2221_FC6 (rawhide)
> Firmware: usb8388_A1_W8015FP14_FW2.bin

Hi Polychnoris,

Did you compile your own kernel version? 
Are you using PS mode?


From dcbw at redhat.com  Thu Oct 19 13:14:51 2006
From: dcbw at redhat.com (Dan Williams)
Date: Thu, 19 Oct 2006 13:14:51 -0400
Subject: EnforceProtection bit in CMD_MAC_CONTROL
Message-ID: <1161278091.19644.4.camel@localhost.localdomain>

Hi,

What exactly does this bit do?  Is it like the 'privacy invoked' bit in
other drivers?  Or is it like the 'exclude unencrypted' bit in other
drivers?  Or something completely different?

Thanks,
Dan




From ypod at MIT.EDU  Thu Oct 19 22:43:32 2006
From: ypod at MIT.EDU (Polychronis Ypodimatopoulos)
Date: Thu, 19 Oct 2006 22:43:32 -0400
Subject: OLPC boards in promiscuous mode
In-Reply-To: <20061018165522.GA2523@dmt>
References: <452D131C.4030709@media.mit.edu> <20061018165522.GA2523@dmt>
Message-ID: <453837D4.70208@mit.edu>

Hello,

>
> Hi Polychnoris,
>
> Did you compile your own kernel version? 
>   
no. I use the standard kernel that comes with rawhide.

> Are you using PS mode?
>   
do you mean promiscuous mode? yes.


From dcbw at redhat.com  Fri Oct 20 22:28:01 2006
From: dcbw at redhat.com (Dan Williams)
Date: Fri, 20 Oct 2006 22:28:01 -0400
Subject: [PATCH] libertas: don't deadlock on associate
Message-ID: <1161397681.3537.6.camel@localhost.localdomain>

libertas_cmd_80211_associate() is run from within
libertas_prepare_and_send_command().  Therefore, it is locked.  But it
called libertas_set_radio_control(), which re-enters
libertas_prepare_and_send_command(), leading to a deadlock on
association.  This patch moves the libertas_set_radio_control() command
to wlan_associate() instead, the (indirect) caller of
libertas_cmd_80211_associate() anyway.

Signed-off-by: Dan Williams <dcbw at redhat.com>

diff --git a/drivers/net/wireless/libertas/wlan_join.c b/drivers/net/wireless/libertas/wlan_join.c
index f0dfc16..7207ece 100644
--- a/drivers/net/wireless/libertas/wlan_join.c
+++ b/drivers/net/wireless/libertas/wlan_join.c
@@ -431,6 +431,7 @@ #endif				/* REASSOCIATION */
  */
 static int wlan_associate(wlan_private * priv, struct bss_descriptor * pBSSDesc)
 {
+	wlan_adapter *Adapter = priv->adapter;
 	int ret;
 
 	ret = libertas_prepare_and_send_command(priv, HostCmd_CMD_802_11_AUTHENTICATE,
@@ -442,6 +443,14 @@ static int wlan_associate(wlan_private *
 		return ret;
 	}
 
+	/* set preamble to firmware */
+	if (Adapter->capInfo.ShortPreamble && pBSSDesc->Cap.ShortPreamble) {
+		Adapter->Preamble = HostCmd_TYPE_SHORT_PREAMBLE;
+	} else {
+		Adapter->Preamble = HostCmd_TYPE_LONG_PREAMBLE;
+	}
+	libertas_set_radio_control(priv);
+
 	ret = libertas_prepare_and_send_command(priv, HostCmd_CMD_802_11_ASSOCIATE,
 				    0, HostCmd_OPTION_WAITFORRSP, 0, pBSSDesc);
 
@@ -812,15 +821,6 @@ int libertas_cmd_80211_associate(wlan_pr
 	       pBSSDesc->MacAddress, sizeof(pAsso->PeerStaAddr));
 	pos += sizeof(pAsso->PeerStaAddr);
 
-	/* set preamble to firmware */
-	if (Adapter->capInfo.ShortPreamble && pBSSDesc->Cap.ShortPreamble) {
-		Adapter->Preamble = HostCmd_TYPE_SHORT_PREAMBLE;
-	} else {
-		Adapter->Preamble = HostCmd_TYPE_LONG_PREAMBLE;
-	}
-
-	libertas_set_radio_control(priv);
-
 	/* set the listen interval */
 	pAsso->ListenInterval = Adapter->ListenInterval;
 




From dcbw at redhat.com  Fri Oct 20 23:25:43 2006
From: dcbw at redhat.com (Dan Williams)
Date: Fri, 20 Oct 2006 23:25:43 -0400
Subject: [PATCH] libertas: update to WE-18
Message-ID: <1161401143.6095.3.camel@localhost.localdomain>

Implement WE-18 handlers for WPA and consolidate security/encryption
calls into a common set of functions and key structures.  Doesn't work
with WPA yet due to the lack of deferred association, but it's no worse
than before.

Signed-off-by: Dan Williams <dcbw at redhat.com>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: we-fixes.patch.bz2
Type: application/x-bzip
Size: 9506 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/libertas-dev/attachments/20061020/7adb3a3d/attachment.bin 

