Re: 8.2.1 WPA testing
Hi Chris, On Sun, Mar 1, 2009 at 4:08 PM, Chris Ball c...@laptop.org wrote: I've been working on trying to quantify the difference in WPA behavior between 8.2.0 and 8.2.1. (...) Failures leave the string Activation (eth0/wireless): disconnected during association, asking for new key in /var/log/messages. A second type of failure is seen only on 8.2.0, namely Unhandled network capabilities 1001; this bug is fixed in 8.2.1, and was not included in the totals below. There were a number of timing problems between the driver, wpa_supplicant and NM, and the Unhandled network... was one of them. See #8667 and #8799 for more details. The patches submitted for those tickets addressed some of the problems, but not all. In addition to this, there are two important wireless fixes in 8.2.1: #7825 and #9048. The first one is a failure to associate to fast Access Points when WPA is enabled. This was a serious problem, making it impossible (not just unreliable) to associate with certain AP models. The second problem was causing a packet loss while scanning, something the xo does quite frequently. Conclusion: For this particular bug (being asked to re-enter the WPA passphrase at connection time), with the particular WPA access points at 1cc, we already had sporadic failures as of 8.2.0. 8.2.1 appears to make them slightly worse, perhaps suggesting a widening of a race condition in the newer driver or wireless firmware. We already know installing WPA keys to be time-critical: see relevant recent commits ¹ and ². I would suggest to compare the two versions with different AP models. For instance, with the D-Link WBR-2310 you will see a huge improvement when using 8.2.1. Advice: We should not claim reliable WPA support in 8.2.1. Agreed. However, I believe you can claim reliable WPA2 support, as the WPA2 handshake doesn't have this timing vulnerability. Have not tested extensively, but my experience was that WPA2 was very reliable. Cheers, Javier -- Javier Cardona cozybit Inc. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 8.2.1 WPA testing
On Mon, Mar 2, 2009 at 11:57 AM, Daniel Drake d...@laptop.org wrote: 2009/3/2 Javier Cardona jav...@cozybit.com: I would suggest to compare the two versions with different AP models. For instance, with the D-Link WBR-2310 you will see a huge improvement when using 8.2.1. Have you tested this using an actual present-day OS 8.2.1 build, or just using your custom kernel during the 8.2.1 development phase? Custom kernel. Were you using sugar to establish connectivity, or just by writing wpa_supplicant config files? Both. Javier -- Javier Cardona cozybit Inc. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: wpa_supplicant instructions?
Hi Michail,
On Wed, Oct 29, 2008 at 2:59 PM, Michael Stone [EMAIL PROTECTED] wrote:
Michailis mentioned to me that the wireless team had worked out a set of
command-line arguments for wpa_supplicant which yield excellent
association reliability. Could you please publish these arguments?
There is nothing special with the configuration that we use: it is
based in the example configuration files provided by wpa_supplicant
(man wpa_supplicant.conf).
But here it goes:
aloha.conf:
# WPA-PSK
network={
ssid=aloha-test
key_mgmt=WPA-PSK
proto=WPA
psk=passphrase
}
Then use it as:
wpa_supplicant -Dwext -ieth1 -B -c aloha.conf
Let me know if you need any additional details.
Cheers!
Javier
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: wpa_supplicant instructions?
On Wed, Oct 29, 2008 at 3:23 PM, Javier Cardona [EMAIL PROTECTED] wrote: Hi Michail, s/Michail/Michael/ sorry! ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Suspend vs Network Traffic - blockers
David, John, On Wed, Aug 13, 2008 at 12:07 AM, David Woodhouse [EMAIL PROTECTED] wrote: On Tue, 2008-08-12 at 14:44 -0700, Javier Cardona wrote: The two problems I had with the current wol-signature implementation were usability¹ and the inability to configure one ARP + one IPv6 Neighbor Solicitation trigger on *each* the msh and the eth interface. Doesn't neighbour solicitation happen as multicast, so you only need the wake-on-multicast for that? My assumption, based on observing OLPC traffic patterns, was that we did not want to wake up on all the multicast traffic that the xo was listening for. But keep reading... On Tue, Aug 12, 2008 at 7:17 PM, John Gilmore [EMAIL PROTECTED] wrote: We *do* want to wake on all multicast traffic that the kernel or user programs are listening for. (If every laptop is sending too much multicast traffic all the time, such that we could never suspend for more than a few seconds, then we'll need to fix that -- at the senders, by not sending it; not by making the recipients ignore it!) I believe that we've been trying to reduce multicast traffic from activities for a while now without success. So until this happens we can use the wow-signature method to further restrict which muticast traffic should be allowed to wake up the host. But if the excess of multicast traffic problem has been resolved, then yes, we don't need a specific trigger to wake up on Neighbor Solicitation messages. Plain multicast wakeup will just work. Cheers, Javier -- Javier Cardona cozybit Inc. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Suspend vs Network Traffic - blockers
Ricardo, On Tue, Aug 12, 2008 at 1:03 PM, Ricardo Carrano [EMAIL PROTECTED] wrote: Marvell will implement the new wow-signature API with the next firmware release (22p18) Though I agree now, as I agreed in the past, that the filter is not easy to use, I would say that it was a mechanism already in place (and the filter would not be used by an end user anyway). If I recall correctly, the filter was compatible with IPv6, it was just terribly ineficient in doing so. The two problems I had with the current wol-signature implementation were usability¹ and the inability to configure one ARP + one IPv6 Neighbor Solicitation trigger on *each* the msh and the eth interface. I would say that none of them are blockers, although the usability aspect may prevent the patch to be accepted upstream. It seems to me that this old filter method (let's call it old) is the only available option to do it fast. Do you guys believe we'll be able to test a new firmware and driver and push it to a build fast? Based on the time that we've been waiting for this, I don't expect a new firmware + driver to be ready in time for 8.2. Cheers, Javier [1] Having to know about Marvell's vendor ID, different configuration for msh0 than eth0, filter rules limited to 4 bytes which makes IPv6 signatures hardly readable, inability to append configurations with subsequent iwpriv calls... -- Javier Cardona cozybit Inc. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Suspend vs Network Traffic - blockers
John, On Tue, Aug 12, 2008 at 2:01 PM, John Gilmore [EMAIL PROTECTED] wrote: If we have multicast wakeup working, then IPv6 takes care of itself. Waking up on all multicast traffic would not only wake up the host on Neighbor Solicitation messages, but also on all other multicast traffic the interface was listening to before suspending (e.g. mDNS multicast messages). We probably do not want that, and the wow-signature approach gives finer grained control on exactly what messages we want to use as wake up triggers. Cheers, Javier -- Javier Cardona cozybit Inc. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: isolating cause of ticket 5848
Bill,
On Tue, Jun 10, 2008 at 2:25 PM, Bill Mccormick [EMAIL PROTECTED] wrote:
Hey guys,
I've tracked down some of the code that's causing this problem. (the
syslog file is invaluable for debugging nm problems in case you have to
do this again). NM is waiting for a netlink callback, specifically in
nm-device-802-11-mesh-olpc.c on lines 291-307. when NM doesn't get the
expected callback a timer (called the association timer) expires and NM
stops trying to setup the P2P mesh.
snip
if (iwe-cmd == SIOCGIWAP) {
addr = iwe-u.ap_addr.sa_data;
if ( !memcmp (addr, badaddr1, ETH_ALEN)
|| !memcmp (addr, badaddr2, ETH_ALEN)
|| !memcmp (addr, badaddr3, ETH_ALEN)) {
/* disassociated */
} else {
/* associated */
GSource * source = g_idle_source_new ();
if (source) {
nm_info (%s: Got association; scheduling association handler,
nm_device_get_iface (NM_DEVICE (self)));
g_object_ref (self);
g_source_set_priority (source,
G_PRIORITY_HIGH_IDLE);
g_source_set_callback (source,
handle_association_event, self, NULL);
g_source_attach (source,
nm_device_get_main_context (NM_DEVICE (self)));
g_source_unref (source);
}
}
/snip
handle_association_event() cancels the association timer, so if this
SIOCGIWAP message isn't received, or is received with an 'invalid' MAC,
then the timer never gets cancelled and NM gives up on the mesh setup.
Looking at the wireless.h header file, it looks like SIOCGIWAP is
normally used to get access point MAC addresses. In this guess, I
think the NM is expecting to get the MAC address of msh0.
Now it gets kinda confusing here. The SIOCGIWAP isn't actually used in
an ioctl() function, rather this is a message delivered via netlink and
SIOCGIWAP is the value of the iw_event.cmd field (see wireless.h again).
Javier, could you advise what this message is used for on the mesh
interface?
This is the first time I look into this, but inspecting the driver I
see that this event is sent:
1. [cmdrsp.c:44] when association is lost (MAC set to all zeros)
2. [join.c:232] when successfully joined an ad-hoc network (MAC set to BSSID)
3. [join.c:789] when successfully associated (MAC set to BSSID)
4. [join.c:874] when starting and ad-hoc netwrok (MAC set to BSSID)
5. [main.c:1202] when removing the interface (MAC set to all 0xaa's)
As far as I can tell, there is no SIOCGIWAP event generated by the
mesh interface, as the mesh interface is always on.
Javier
--
Javier Cardona
cozybit Inc.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
[PATCH olpc/stable] Rate adaptation configuration via iwconfig.
Implemented rate adaptation support via 'iwconfig rate' API. It is now
possible to specify a bit-rate value and append 'auto'. That will configure
rate adaptation to use all bit-rates equal or lower than than selected value.
Made lbs_cmd_802_11_rate_adapt_rateset a direct command.
This patch is made against olpc/stable so testing can start right away. If
feedback is good, I'll adapt to libertas-2.6 and resubmit to libertas-dev.
Signed-off-by: Javier Cardona [EMAIL PROTECTED]
---
drivers/net/wireless/libertas/cmd.c | 69 ++
drivers/net/wireless/libertas/cmd.h |2 +
drivers/net/wireless/libertas/cmdresp.c | 20 -
drivers/net/wireless/libertas/dev.h |5 +-
drivers/net/wireless/libertas/hostcmd.h |2 +-
drivers/net/wireless/libertas/join.c|2 +-
drivers/net/wireless/libertas/main.c|2 +-
drivers/net/wireless/libertas/rx.c |4 +-
drivers/net/wireless/libertas/wext.c| 27
9 files changed, 77 insertions(+), 56 deletions(-)
diff --git a/drivers/net/wireless/libertas/cmd.c
b/drivers/net/wireless/libertas/cmd.c
index 0ae9851..02f62a0 100644
--- a/drivers/net/wireless/libertas/cmd.c
+++ b/drivers/net/wireless/libertas/cmd.c
@@ -706,26 +706,62 @@ static int lbs_cmd_802_11_monitor_mode(struct lbs_private
*priv,
return 0;
}
-static int lbs_cmd_802_11_rate_adapt_rateset(struct lbs_private *priv,
- struct cmd_ds_command *cmd,
- u16 cmd_action)
+static __le16 lbs_rate_to_fw_bitmap(int rate, int lower_rates_ok)
{
- struct cmd_ds_802_11_rate_adapt_rateset
- *rateadapt = cmd-params.rateset;
+/* Bit Rate
+* 15:13 Reserved
+* 1254 Mbps
+* 1148 Mbps
+* 1036 Mbps
+* 9 24 Mbps
+* 8 18 Mbps
+* 7 12 Mbps
+* 6 9 Mbps
+* 5 6 Mbps
+* 4 Reserved
+* 3 11 Mbps
+* 2 5.5 Mbps
+* 1 2 Mbps
+* 0 1 Mbps
+**/
+
+ uint16_t ratemask;
+ int i = lbs_data_rate_to_fw_index(rate);
+ if (lower_rates_ok)
+ ratemask = (0x1fef (12 - i));
+ else
+ ratemask = (1 i);
+ return cpu_to_le16(ratemask);
+}
+
+int lbs_cmd_802_11_rate_adapt_rateset(struct lbs_private *priv,
+ uint16_t cmd_action)
+{
+ struct cmd_ds_802_11_rate_adapt_rateset cmd;
+ int ret;
lbs_deb_enter(LBS_DEB_CMD);
- cmd-size =
- cpu_to_le16(sizeof(struct cmd_ds_802_11_rate_adapt_rateset)
-+ S_DS_GEN);
- cmd-command = cpu_to_le16(CMD_802_11_RATE_ADAPT_RATESET);
- rateadapt-action = cpu_to_le16(cmd_action);
- rateadapt-enablehwauto = cpu_to_le16(priv-enablehwauto);
- rateadapt-bitmap = cpu_to_le16(priv-ratebitmap);
+ if (!priv-cur_rate !priv-enablehwauto)
+ return -EINVAL;
- lbs_deb_leave(LBS_DEB_CMD);
- return 0;
+ cmd.hdr.size =
+ cpu_to_le16(sizeof(struct cmd_ds_802_11_rate_adapt_rateset));
+
+ cmd.action = cpu_to_le16(cmd_action);
+ cmd.enablehwauto = cpu_to_le16(priv-enablehwauto);
+ cmd.bitmap = lbs_rate_to_fw_bitmap(priv-cur_rate, priv-enablehwauto);
+ ret = lbs_cmd_with_response(priv, CMD_802_11_RATE_ADAPT_RATESET,
+ cmd);
+ if (!ret cmd_action == CMD_ACT_GET) {
+ priv-ratebitmap = le16_to_cpu(cmd.bitmap);
+ priv-enablehwauto = le16_to_cpu(cmd.enablehwauto);
+ }
+
+ lbs_deb_leave_args(LBS_DEB_CMD, ret %d, ret);
+ return ret;
}
+EXPORT_SYMBOL_GPL(lbs_cmd_802_11_rate_adapt_rateset);
/**
* @brief Get the current data rate
@@ -1471,11 +1507,6 @@ int lbs_prepare_and_send_command(struct lbs_private
*priv,
ret = lbs_cmd_802_11_radio_control(priv, cmdptr, cmd_action);
break;
- case CMD_802_11_RATE_ADAPT_RATESET:
- ret = lbs_cmd_802_11_rate_adapt_rateset(priv,
-cmdptr, cmd_action);
- break;
-
case CMD_MAC_MULTICAST_ADR:
ret = lbs_cmd_mac_multicast_adr(priv, cmdptr, cmd_action);
break;
diff --git a/drivers/net/wireless/libertas/cmd.h
b/drivers/net/wireless/libertas/cmd.h
index e334f0e..b4100b7 100644
--- a/drivers/net/wireless/libertas/cmd.h
+++ b/drivers/net/wireless/libertas/cmd.h
@@ -46,5 +46,7 @@ int lbs_mesh_config(struct lbs_private *priv, uint16_t
enable, uint16_t chan);
int lbs_host_sleep_cfg(struct lbs_private *priv, uint32_t criteria);
int lbs_suspend(struct lbs_private *priv);
int lbs_resume(struct lbs_private *priv);
+int lbs_cmd_802_11_rate_adapt_rateset(struct
Thin firmware + driver first development release
Hi, We are happy to announce the first development release of the wireless firmware + driver compatible with the kernel's mac80211 stack. This is a first step towards supporting a soft Access Point (hostap) on the xo, a project in which are actively working. The release is made of the following pieces: Firmware: http://dev.laptop.org/pub/firmware/libertas/thinfirm Driver: git clone git://dev.laptop.org/users/javier/libertastf.git HOW_TO: http://dev.laptop.org/pub/firmware/libertas/thinfirm/HOW_TO Release Notes: - Implemented mac80211 support for scanning, association and rate adaptation. - No power management nor security is supported. - Driver can coexist with original libertas driver but we recommend blacklisting one of them in /etc/modprobe.d/blacklist and rmmod/modprobe when willing to experiment with it. - The driver has been greatly simplified, but we are still working in getting it simpler, specially in command handling. - Since the device does not report the MAC address until the firmware is loaded, we use a fake multicast mac address for the device until the first time an interface is brought up. Thanks to Johannes Berg for his help with this issue. - The driver was developed on wireless-testing branch and compiled fine on olpc-2.6 but faced other problems (display, touchpad) that prevented us testing it on the xo. Waiting for olpc-2.6 master to stabilize after it merged with 2.6.26. Please send all feedback to this list cc'ing luisca or javier AT cozybit.com Cheers, The friendly folks at cozybit -- Javier Cardona cozybit Inc. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Thin firmware + driver first development release
David, On Fri, May 9, 2008 at 8:05 PM, David Woodhouse [EMAIL PROTECTED] wrote: Excellent; thanks. Were you planning to make the API for this 'thin firmware' compatible with the 'thin firmware' on other devices? Other Marvell devices, yes, to whatever extent we can. Should the folks working on http://git.infradead.org/mrv8k-2.6.git be trying to merge with your driver? Not sure. I just found out about this project. We'll check it out and see. Thanks, Javier ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: WDS problems observed in today's testing
Jim, On 3/3/08, Jim Gettys [EMAIL PROTECTED] wrote: These were WRT54GL's running OpenWRT, just to ask the exact configuration? Not sure if it was a WRT54G or WRT54GL, but I'm certain that it was running the original Linksys firmware. Javier -- Javier Cardona cozybit Inc. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
WDS problems observed in today's testing
Michail, Chris, This afternoon I captured some traffic while Chris was running tests for Peru. The test setup consisted on ~25 laptops associated to a WRT54 access point. When the laptops were on, associated and (not sure about this) idle, we observed a high volume of wireless traffic. The spectrum analyzer showed close to 50% duty cycle utilization of the channel. We also observed that a few xo's could not associate, and some seemed to intermittently lose and recover association. Turning off the WRT54 (and therefore stopping all the infra traffic) freed up most of the bandwidth on that channel. In my 50 second capture (taken before turning off the AP) we observe: Total traffic: 15081 frames (100%) All WDS traffic (1): 6023 frames ( 40%) WDS, xo is source addr (2): 4343 frames ( 29%) (96% of the above xmitted at 1 Mbps (3) and 100% sent by a single AP(4)) Compare that with xo originated infra frames (5): 401 frames ( 3%) (77% of the above xmitted at rates higher than 2 Mbps (6)) What does all this mean? 1. Multicast traffic gets replicated and retransmitted. 2. The ratio of original frames to AP generated multicast retransmissions is 1:11 3. Taking into account the data rates this means that for 1 airtime unit used to transmit useful traffic, over 200 units are wasted transmitting useless WDS traffic. 4. All this is done by a single Cisco AP, MAC: 00:1e:7e:44:ce:6e Michail, is that one of OLPC APs? Chris, we should see a big improvement if we can disable that feature on the AP... or put it under water. I've posted my capture here: http://dev.laptop.org/~javier/captures/cisco-wds-traffic-around-xo-testbed.cap in case someone wants to double check my analysis (Ricardo?). Cheers, Javier (1) wlan.fc.ds == 3 (2) wlan.fc.ds == 3 and wlan.sa[0-2] == 00:17:C4 (3) wlan.fc.ds == 3 and wlan.sa[0-2] == 00:17:C4 and radiotap.datarate == 0x2 (4) wlan.fc.ds == 3 and wlan.sa[0-2] == 00:17:C4 and wlan.ta[4-5] == ce:6e (5) wlan.fc.ds == 1 and wlan.sa[0-2] == 00:17:C4 (6) wlan.fc.ds == 1 and wlan.sa[0-2] == 00:17:C4 and radiotap.datarate 4 -- Javier Cardona cozybit Inc. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: WDS problems observed in today's testing
Kim, Michail, The conclusion to all of this is that we should not use WRT54G in deployments, regardless of whether mesh is used or not (in fact, if we *only* use mesh we don't have this problem as the AP ignores mesh multicast traffic now). The WRT54G will forward multicast traffic to all other APs in the vicinity that it identifies as peers using flawed criteria (Lazy-WDS). Since the xo's generate a lot of multicast traffic, that creates a risk of triggering the multicast storms that we saw at OLPC. Javier PS. If we have no choice but to use that AP, then we should re-image the AP with a distribution that allows turning WDS off. In Tomato (http://www.polarcloud.com/tomato) this can be achieved via Basic - Wireless Mode = 'Access Point' and NOT 'Access Point + WDS' On 3/1/08, Javier Cardona [EMAIL PROTECTED] wrote: Ricardo, - The access point Javier mentions is the one I bought yesterday (Linksys WRT54G) Agreed, yes: 35 00:1d:7e:44:ce:6e Broadcast Beacon frame,SSID: linksys - Most of this traffic is retransmission (3606): (wlan.fc.ds == 3 and wlan.sa[0-2] == 00:17:C4 and wlan.ta[4-5] == ce:6e) (wlan.fc.retry == 1) Agreed. - It is also interesting to detect other wds peers this AP identified (one is 00:0b:85:53:27:50 and got 1066 of these frames). ((wlan.fc.ds == 3 and wlan.sa[0-2] == 00:17:C4 and wlan.ta[4-5] == ce:6e)) (wlan.ra == 00:0b:85:53:27:50) Yes. Note that none of the WDS peers are xo's, as was the case in the past. It seems that the linksys is expecting acks for this wds frames (which btw are mulcast frames). It is amazing. Well, even if the final destination is a multicast address, those WDS frames are unicast, and therefore acknowledged. What's troubling is that the WDS links are not torn down when the link quality is so poor. But we all know that Lazy-WDS is a flawed protocol. I believe we should compare this with the previous capture from the Netgear AP, just to confirm that this is (again) specific to WDS issues on the Linksys. I don't have access to that capture. Maybe David? Javier On Sat, Mar 1, 2008 at 5:23 AM, Javier Cardona [EMAIL PROTECTED] wrote: Michail, Chris, This afternoon I captured some traffic while Chris was running tests for Peru. The test setup consisted on ~25 laptops associated to a WRT54 access point. When the laptops were on, associated and (not sure about this) idle, we observed a high volume of wireless traffic. The spectrum analyzer showed close to 50% duty cycle utilization of the channel. We also observed that a few xo's could not associate, and some seemed to intermittently lose and recover association. Turning off the WRT54 (and therefore stopping all the infra traffic) freed up most of the bandwidth on that channel. In my 50 second capture (taken before turning off the AP) we observe: Total traffic: 15081 frames (100%) All WDS traffic (1): 6023 frames ( 40%) WDS, xo is source addr (2): 4343 frames ( 29%) (96% of the above xmitted at 1 Mbps (3) and 100% sent by a single AP(4)) Compare that with xo originated infra frames (5): 401 frames ( 3%) (77% of the above xmitted at rates higher than 2 Mbps (6)) What does all this mean? 1. Multicast traffic gets replicated and retransmitted. 2. The ratio of original frames to AP generated multicast retransmissions is 1:11 3. Taking into account the data rates this means that for 1 airtime unit used to transmit useful traffic, over 200 units are wasted transmitting useless WDS traffic. 4. All this is done by a single Cisco AP, MAC: 00:1e:7e:44:ce:6e Michail, is that one of OLPC APs? Chris, we should see a big improvement if we can disable that feature on the AP... or put it under water. I've posted my capture here: http://dev.laptop.org/~javier/captures/cisco-wds-traffic-around-xo-testbed.cap in case someone wants to double check my analysis (Ricardo?). Cheers, Javier (1) wlan.fc.ds == 3 (2) wlan.fc.ds == 3 and wlan.sa[0-2] == 00:17:C4 (3) wlan.fc.ds == 3 and wlan.sa[0-2] == 00:17:C4 and radiotap.datarate == 0x2 (4) wlan.fc.ds == 3 and wlan.sa[0-2] == 00:17:C4 and wlan.ta[4-5] == ce:6e (5) wlan.fc.ds == 1 and wlan.sa[0-2] == 00:17:C4 (6) wlan.fc.ds == 1 and wlan.sa[0-2] == 00:17:C4 and radiotap.datarate 4 -- Javier Cardona cozybit Inc. -- Javier Cardona cozybit Inc. -- Javier Cardona cozybit Inc. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: WDS problems observed in today's testing
John, On 3/1/08, John Watlington [EMAIL PROTECTED] wrote: I was told that 17 laptops were associated on Friday, w. lots of bandwidth left over. Question 1: What is lots of bandwidth ? CSMC networks don't work well past around 50 - 60% of available bandwidth... What I recall is 50% duty cycle and a channel grade of 22/100. The channel grade takes into account not only the duty cycle but also the noise floor. I did not re-check those numbers after turning the AP off, but there was a drastic improvement of the channel energy profile. The limit of concurrent users for a low-end AP like the WRT54G is ~30. But in the capture we see that the AP is wasting most of its time transmitting WDS frames at low rates. That is very likely to be the reason why we could not get more than 17 laptops associated. Question 2: Did this bandwidth measurement include the relayed WDS frames ? Yes it did: the WDS frames were in the same channel. Javier On Mar 1, 2008, at 2:17 PM, Kim Quirk wrote: Was anyone able to get a test with a different AP? We were only able to associate something like 20 laptops on Fri. Do we believe it should be 30 or more? Kim On 3/1/08, Javier Cardona [EMAIL PROTECTED] wrote: Kim, Michail, The conclusion to all of this is that we should not use WRT54G in deployments, regardless of whether mesh is used or not (in fact, if we *only* use mesh we don't have this problem as the AP ignores mesh multicast traffic now). The WRT54G will forward multicast traffic to all other APs in the vicinity that it identifies as peers using flawed criteria (Lazy-WDS). Since the xo's generate a lot of multicast traffic, that creates a risk of triggering the multicast storms that we saw at OLPC. Javier PS. If we have no choice but to use that AP, then we should re-image the AP with a distribution that allows turning WDS off. In Tomato (http://www.polarcloud.com/tomato) this can be achieved via Basic - Wireless Mode = 'Access Point' and NOT 'Access Point + WDS' On 3/1/08, Javier Cardona [EMAIL PROTECTED] wrote: Ricardo, - The access point Javier mentions is the one I bought yesterday (Linksys WRT54G) Agreed, yes: 35 00:1d:7e:44:ce:6e Broadcast Beacon frame,SSID: linksys - Most of this traffic is retransmission (3606): (wlan.fc.ds == 3 and wlan.sa[0-2] == 00:17:C4 and wlan.ta[4-5] == ce:6e) (wlan.fc.retry == 1) Agreed. - It is also interesting to detect other wds peers this AP identified (one is 00:0b:85:53:27:50 and got 1066 of these frames). ((wlan.fc.ds == 3 and wlan.sa[0-2] == 00:17:C4 and wlan.ta[4-5] == ce:6e)) (wlan.ra == 00:0b:85:53:27:50) Yes. Note that none of the WDS peers are xo's, as was the case in the past. It seems that the linksys is expecting acks for this wds frames (which btw are mulcast frames). It is amazing. Well, even if the final destination is a multicast address, those WDS frames are unicast, and therefore acknowledged. What's troubling is that the WDS links are not torn down when the link quality is so poor. But we all know that Lazy-WDS is a flawed protocol. I believe we should compare this with the previous capture from the Netgear AP, just to confirm that this is (again) specific to WDS issues on the Linksys. I don't have access to that capture. Maybe David? Javier On Sat, Mar 1, 2008 at 5:23 AM, Javier Cardona [EMAIL PROTECTED] wrote: Michail, Chris, This afternoon I captured some traffic while Chris was running tests for Peru. The test setup consisted on ~25 laptops associated to a WRT54 access point. When the laptops were on, associated and (not sure about this) idle, we observed a high volume of wireless traffic. The spectrum analyzer showed close to 50% duty cycle utilization of the channel. We also observed that a few xo's could not associate, and some seemed to intermittently lose and recover association. Turning off the WRT54 (and therefore stopping all the infra traffic) freed up most of the bandwidth on that channel. In my 50 second capture (taken before turning off the AP) we observe: Total traffic: 15081 frames (100%) All WDS traffic (1): 6023 frames ( 40%) WDS, xo is source addr (2): 4343 frames ( 29%) (96% of the above xmitted at 1 Mbps (3) and 100% sent by a single AP(4)) Compare that with xo originated infra frames (5): 401 frames ( 3%) (77% of the above xmitted at rates higher than 2 Mbps (6)) What does all this mean? 1. Multicast traffic gets replicated and retransmitted. 2. The ratio of original frames to AP generated multicast retransmissions is 1:11 3. Taking into account the data rates
Re: Wireshark
Ricardo, On 2/25/08, Ricardo Carrano [EMAIL PROTECTED] wrote: Applies the patch and compiled but failed to execute (on Ubuntu)... 14:43:34 Err file about_dlg.c: line 250 (splash_update): assertion failed: (ul_sofar = ul_count) Aborted (core dumped) Any ideas? Has someone tried this on Ubuntu? Oh, I just commented out that assertion and it all worked with a fuss: (lt-wireshark:32429): Gtk-CRITICAL **: gtk_progress_set_percentage: assertion `percentage = 0 percentage = 1.0' failed Who cares if the progress bar goes beyond 100%... :) Javier On Mon, Feb 25, 2008 at 4:37 AM, John Watlington [EMAIL PROTECTED] wrote: A version of wireshark which is patched to monitor the new mesh protocol is available at: (older, F7 version) http://dev.laptop.org/~wad/wireshark-0.99.5.mesh.patch http://dev.laptop.org/~wad/wireshark-0.99.5-1.i386.rpm http://dev.laptop.org/~wad/wireshark-gnome-0.99.5-1.i386.rpm (current, F8 version) http://dev.laptop.org/~wad/wireshark-0.99.7.mesh.patch http://dev.laptop.org/~wad/wireshark-0.99.7.mesh.i386.rpm http://dev.laptop.org/~wad/wireshark-gnome-0.99.7.mesh.i386.rpm I'm still not seeing RREQ traffic, but I haven't played around with the new version much. Enjoy, wad On Feb 21, 2008, at 2:54 PM, Javier Cardona wrote: On 2/21/08, John Watlington [EMAIL PROTECTED] wrote: Thanks for the reply. What is your estimate of the difficulty in supporting the new mesh format ? We were really hoping to examine the simple mesh traffic carefully next week, and this puts a big crimp in those plans. It would take me about three hours, including testing, generating the patch, etc. I don't have that time this week but may work on it early next week. Javier wad On Feb 21, 2008, at 1:20 PM, Javier Cardona wrote: John, The patch was up to date up until we had to change the format of broadcast traffic. It has not been updated since. Unicast traffic should still be parsed correctly. Please contact Ronak if you want us to work on this. Cheers, Javier On 2/21/08, John Watlington [EMAIL PROTECTED] wrote: Yeah, but I was hoping not to have to parse each packet manually to determine if it is carrying data (TCP,UDP,etc.) or Path/Route discovery traffic. So nobody has patched wireshark to actually decipher mesh traffic ? wad On Feb 21, 2008, at 9:31 AM, Ricardo Carrano wrote: Isn't the LLC traffic what you're looking for? I see a lot of multicast traffic on your file, particularly to 01:00:5e:7f:47:31. They are LLC. On Thu, Feb 21, 2008 at 10:38 AM, John Watlington [EMAIL PROTECTED] wrote: My screen looks like the screen shot you sent when looking at that data. I can see the mesh headers on the pings. Take a look at the data I pointed to. It tried to record a session of a number of laptops collaborating. I set the capture mask to 7 (beacons, link layer, and data). But all I see in wireshark is beacons and LLC traffic. Given your data and screenshot, this is user error not misapplied patch... Still, is there any way to dig deeper into simple mesh traffic ? wad On Feb 21, 2008, at 8:15 AM, Ricardo Carrano wrote: capture.dump -- Javier Cardona cozybit Inc. -- Javier Cardona cozybit Inc. -- Javier Cardona cozybit Inc. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mesh portal discovery
John, The DHCP procedure currently being used only discovers the nearest mesh portal when it is first run (DHCP_DISCOVER), not when it tries to renew (DHCP_REQUEST). Furthermore, as the address previously assigned indicates which mesh portal was selected, it seems like we should always be discovering, not renewing... You probably don't want that: a mesh point might have equal cost routes to several mesh portals. In that case you want some hysteresis: only change to a new MPP if it offers a big advantage over the current one. As long as it can communicate with it by hopping through the mesh, it will renew the existing lease and never discover a closer MPP/DHCP server This was the problem that prompted my original message on this thread. One way to do this would be to run a simple daemon that 1. Periodically sends traffic to the anycast address. If you want to use dhclient for this ( assuming it is patched as described here: http://www.cozybit.com/projects/mpp-utils/index.html#update ) you could send frames to the anycast address like this: # dhclient eth0 -1 -lf /dev/null -sf /bin/true 2. Compare the metric of the best mpp with the current mpp. This can be done via iwpriv fwt_list calls. 3. If the cost difference justifies it, wipe out the existing leases and re-discover # rm /var/lib/dhcp3/* ; dhclient eth0 Cheers, Javier -- Javier Cardona cozybit Inc. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Networking hangs
Hi Hal, On 11/25/07, Hal Murray [EMAIL PROTECTED] wrote: After a while (1 to several hours), the network stops working. The mouse still works, at least until I try something that's too complicated. (...) Is this a known problem? If not, what should I do to get more info? ... This sounds like http://dev.laptop.org/ticket/4470 Javier ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PyCON-Organizers] OLPCs not considerate wireless users
Rob, After brainstorming with some other folks at Hacker's, our feeling is the problem was caused by having multiple APs with the same identical SSID, but multiple MACs. This should be easy to reproduce if you can reconfigure several APs without causing other problems. :-) It would be a great help if folks would capture traffic when they observe network problems with the xo's. Here's how to do it on the xo itself: http://dev.laptop.org/ticket/4805#comment:22 This way we could really get some insight on what was the real cause for this problem. For this particular instance, does anyone recall what was the brand/model of those access points? Cheers, Javier -- Javier Cardona cozybit Inc. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: b-test-4 radio range, extreme range
On 10/7/07, James Cameron [EMAIL PROTECTED] wrote: Walked up a mountain near my house with a B4, with another B4 on top of an extension ladder, to see if I could get them to work over 6.3km. They didn't, but not much can be concluded about the hardware from this, since the failure was likely to be terrain or evironment. Could you place a third laptop half way between the two? :) Javier ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: radio off guarantee?
Don't have a box with me right now to confirm, but this command sequence used to turn off the radio: # killall NetworkManager # iwpriv eth0 radiooff Javier On 9/17/07, James Cameron [EMAIL PROTECTED] wrote: Low priority ... removing the usb8xxx kernel driver is not a conventional use case. On Mon, Sep 17, 2007 at 10:32:35PM -0400, Bernardo Innocenti wrote: I don't see how removing the usb8xxx kernel driver may affect X client connections. I'd say the two have to be independent. I agree. But it happens. I've reproduced it. I'll try some later builds though. 566 is a bit old now. Sorry. Where do you see this message? By pressing Control/Alt/F2. The X server /usr/bin/X has file descriptor 2 (stderr) anchored to /dev/tty2, per ls -l /proc/`pgrep X`/fd ... therefore the second text console contains the message, repeating. Check for $XAUTHORITY: it should point to a file containing the xauth cookie. Got it. /proc/`pgrep X`/environ contains XAUTHORITY which points to /home/olpc/.Xauthority last changed several days ago, which contains a hostname of xo-05-27-F1.localdomain, but the current /bin/hostname output is localhost.localdomain ... so I conjecture that removing the wireless kernel driver results in the hostname not being the same as what it was before. -- James Cameronmailto:[EMAIL PROTECTED] http://quozl.netrek.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Javier Cardona cozybit Inc. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Marvell
On 9/13/07, Bernardo Innocenti [EMAIL PROTECTED] wrote: Are there patents on 802.11s? Even though it's an IEEE standard? http://standards.ieee.org/db/patents/pat802_11.html Scroll down to 802.11s. Apple, Microsoft and Fujitsu do at least provide the patent/application number. The other 8 companies will probably wait until the standard is ratified. That gives them more leverage. -- Javier Cardona cozybit Inc. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
