Re: WDS problems observed in today's testing
These were WRT54GL's running OpenWRT, just to ask the exact configuration? Note that (the last I heard) some of the newer WRT54G's have too little RAM to run OpenWRT, which is why the WRT54GL model was introduced, IIRC. - Jim On Mon, 2008-03-03 at 16:47 +1030, Kim Hawtin wrote: Javier Cardona wrote: 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. these APs are capable of ~65 concurrent users. at linux.conf.au this year we had associated clients regularly hitting over 60 clients *per* WRT54GL. we had about 25 installed around the venue. the maximum associated clients we saw on one AP was 68. we were using the default install of OpenWRT 7.09. 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. regards, Kim ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Jim Gettys One Laptop Per Child ___ 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
Re: WDS problems observed in today's testing
I believe it is a WRT54Gv8 model (which, btw has not enough memory to run some of the openwrt variants around). It is brand new AP (bought it at BestBuy) with stock LInksys firmware. It is still at 1cc (I brought another (same model) with me so not to disturb the tests in place). On Mon, Mar 3, 2008 at 3:22 PM, Javier Cardona [EMAIL PROTECTED] wrote: 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: WDS problems observed in today's testing
On Mon, 2008-03-03 at 10:22 -0800, Javier Cardona wrote: 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. Yup. They will always have the problem. My point was that if you see a WRT54G (as opposed to the WRT54GL), you have to dig deeper to figure out if they can run OpenWRT or not. Some can; some cannot Nothing like changing hardware in a significant way without changing the model number. This has details: http://wiki.openwrt.org/OpenWrtDocs/Hardware/Linksys/WRT54G?highlight=(OpenWrtDocs/Hardware) - Jim -- Jim Gettys One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
RE: WDS problems observed in today's testing
We encountered this problem elsewhere and found out that the latest version of the firmware from Linksys (only works on the WRT54G v8 routers btw; might also work for the WAP54G as well) resolves the WDS problem. http://www.linksys.com/servlet/Satellite?blobcol=urldatablobheadername1 =Content-Typeblobheadername2=Content-Dispositionblobheadervalue1=text% 2Fplainblobheadervalue2=inline%3B+filename%3DWRT54G-v8_v8.00.5_fwReleas eNotes.txtblobkey=idblobtable=MungoBlobsblobwhere=1193773201628ssbin ary=truelid=8663037401B159 (Please paste the above link on your browser; clicking on the above link somehow didn't work for me). In the firmware version 8.00.5, it specifically mentions: Resolves issue with using a WAP54G in repeater mode. This looks to be a fairly recent version of the firmware. Regards, Ronak -Original Message- From: [EMAIL PROTECTED] [mailto:devel- [EMAIL PROTECTED] On Behalf Of Jim Gettys Sent: Monday, March 03, 2008 10:38 AM To: [EMAIL PROTECTED] Cc: OLPC Developer's List Subject: Re: WDS problems observed in today's testing On Mon, 2008-03-03 at 10:22 -0800, Javier Cardona wrote: 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. Yup. They will always have the problem. My point was that if you see a WRT54G (as opposed to the WRT54GL), you have to dig deeper to figure out if they can run OpenWRT or not. Some can; some cannot Nothing like changing hardware in a significant way without changing the model number. This has details: http://wiki.openwrt.org/OpenWrtDocs/Hardware/Linksys/WRT54G?highlight=(O pe nWrtDocs/Hardware) - Jim -- Jim Gettys One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: WDS problems observed in today's testing
Yup. They will always have the problem. My point was that if you see a WRT54G (as opposed to the WRT54GL), you have to dig deeper to figure out if they can run OpenWRT or not. Some can; some cannot A simple rule of thumb. Recent units can't. Nothing like changing hardware in a significant way without changing the model number. Be thankful that they made the L version for hackers like us. -- These are my opinions, not necessarily my employer's. I hate spam. ___ 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
Just to add that: - The access point Javier mentions is the one I bought yesterday (Linksys WRT54G) - 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) - It is also interesting to detect other wds peers this AP identified (one is 00:0b:85:53:27:50 and got ). ((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) I believe we should compare this with the previous capture from the Netgear AP, just to confirm that this is (agian) specific to WDS issues on the Linksys. 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.caphttp://dev.laptop.org/%7Ejavier/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
(last version was incomplete): Just to add that: - The access point Javier mentions is the one I bought yesterday (Linksys WRT54G) - 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) - 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) It seems that the linksys is expecting acks for this wds frames (which btw are mulcast frames). It is amazing. 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. -- RC 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.caphttp://dev.laptop.org/%7Ejavier/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
I have associated and run successfully web and collaboration sessions between groups of 5 machines with 40 XOs on a WRT54GS running DD-WRT M. Kim Quirk [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 03/01/2008 02:20 PM To Javier Cardona [EMAIL PROTECTED], Kim Quirk [EMAIL PROTECTED], Michail Bletsas [EMAIL PROTECTED], Chris Ball [EMAIL PROTECTED], OLPC Developer's List [EMAIL PROTECTED], Jim Gettys [EMAIL PROTECTED], Ricardo Carrano [EMAIL PROTECTED] cc Subject Re: WDS problems observed in today's testing 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 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
Re: WDS problems observed in today's testing
Javier Cardona 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' dd-wrt (http://www.dd-wrt.com/) has a tab for Wireless - WDS which allows you to disable lazy WDS. Sameer 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. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: WDS problems observed in today's testing
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... Question 2: Did this bandwidth measurement include the relayed WDS frames ? wad 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 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
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 this
