Re: Suspend vs Network Traffic - blockers
Hi Deepak, Thanks for asking. I believe that infra mode = AP but no school server. My take is that this is a blocker. Until more school servers are deployed in the field, this will be one of our most common deployment models. I believe that you are referring 7972 and I'll leave that in blocker status until forced to choose a smaller list. If there's something else you can't do while looking at this, we could try to compare them... Thanks, Greg S Deepak Saxena wrote: On Aug 13 2008, at 03:27, Ricardo Carrano was caught saying: But the important result is that collaboration does not seem to be working in infra mode. Irrespective of the filter status, no icon is being presented in the mesh view of the other XO. Does anyone else experienced this? Would this be considered a blocker for 8.2 or do we primarilly care about collaboration in mesh mode for deployments? ~Deepak ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Suspend vs Network Traffic - blockers
On Fri, Aug 15, 2008 at 12:56 PM, Greg Smith [EMAIL PROTECTED] wrote: Hi Deepak, Thanks for asking. I believe that infra mode = AP but no school server. My take is that this is a blocker. Until more school servers are deployed in the field, this will be one of our most common deployment models. I believe that you are referring 7972 and I'll leave that in blocker status until forced to choose a smaller list. If there's something else you can't do while looking at this, we could try to compare them... Thanks, Greg S Deepak Saxena wrote: On Aug 13 2008, at 03:27, Ricardo Carrano was caught saying: But the important result is that collaboration does not seem to be working in infra mode. Irrespective of the filter status, no icon is being presented in the mesh view of the other XO. Does anyone else experienced this? Would this be considered a blocker for 8.2 or do we primarilly care about collaboration in mesh mode for deployments? ~Deepak Greg and Deepak, It's my mistake that I don't know of the policy to mark bugs as blockers. Please, point me to the policy if there is one written. I did marked 7972 as blocker, because I assume that G1G1 people will get together and try to collaborate. At this point I believe it is not that a serious issue, but I also believe that networks.cfg related issues are with us for some time now. I am unable to do further tests with this one now. Cheers! Ricardo ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Suspend vs Network Traffic - blockers
Hi Ricardo, We have not been good about communicating that so you are not the only one unclear on the policy. What we have is documented at: http://wiki.laptop.org/go/Trac_conventions Linked from the dev.laptop.org home page. In short, you can mark a bug blocks?:8.2.0 and we will find it and try to triage it up to blocks:8.2.0 or down to blocks-:8.2.0 (or possibly change the milestone to 8.2.1). HTHs. Thanks, Greg S PS this is my understanding and not necessarily the consensus of the group. Very likely other people have different opinions. Ricardo Carrano wrote: On Fri, Aug 15, 2008 at 12:56 PM, Greg Smith [EMAIL PROTECTED] wrote: Hi Deepak, Thanks for asking. I believe that infra mode = AP but no school server. My take is that this is a blocker. Until more school servers are deployed in the field, this will be one of our most common deployment models. I believe that you are referring 7972 and I'll leave that in blocker status until forced to choose a smaller list. If there's something else you can't do while looking at this, we could try to compare them... Thanks, Greg S Deepak Saxena wrote: On Aug 13 2008, at 03:27, Ricardo Carrano was caught saying: But the important result is that collaboration does not seem to be working in infra mode. Irrespective of the filter status, no icon is being presented in the mesh view of the other XO. Does anyone else experienced this? Would this be considered a blocker for 8.2 or do we primarilly care about collaboration in mesh mode for deployments? ~Deepak Greg and Deepak, It's my mistake that I don't know of the policy to mark bugs as blockers. Please, point me to the policy if there is one written. I did marked 7972 as blocker, because I assume that G1G1 people will get together and try to collaborate. At this point I believe it is not that a serious issue, but I also believe that networks.cfg related issues are with us for some time now. I am unable to do further tests with this one now. Cheers! Ricardo ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Suspend vs Network Traffic - blockers
Deepak, Would this be considered a blocker for 8.2 ... (Not my call.) or do we primarilly care about collaboration in mesh mode for deployments? Very few deployments use mesh mode, because it currently doesn't scale up to more than about ten nearby laptops. (It's due to many interactions between the mesh firmware, the use of multicast presence packets, and the limited bandwidth available on WiFi. We have had numerous fundamental bugs in these areas -- many of which you've seen referred to in this thread -- and are only now being able to re-test after months of effort spent trying to fix some of those bugs.) So OLPC's recommended configuration with more than 10 laptops in a school is to have one (or more) 802.11 access point, and have the XO's use it in ordinary WiFi mode. Some places have school servers, some don't. When there is a school server, it's sitting on a wired Ethernet attached to the WiFi routers. Due to the mesh/multicast overload problems, very few Active Antennas are in use in deployments, as I understand it. And I'm pretty sure that very few deployments use any kind of WiFi network interface directly inside the school server; they use Ethernet there. This page is the best reference for deployment scenarios: http://wiki.laptop.org/go/Networking_scenarios (It even says (Troublesome Scenario: Simple WiFi) that an access point without a school server is problematic with more than a few XO's, because the XO's will use multicast for presence detection, and 802.11 access points tend to use low speed 1Mbps transmissions for multicast packets. With a school server there, the XO's will not use multicast, they'll use ordinary high speed unicast packets to and from the presence service in the school server.) John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Suspend vs Network Traffic - blockers
Hi everyone, On Fri, Aug 15, 2008 at 6:14 PM, John Gilmore [EMAIL PROTECTED] wrote: Deepak, Would this be considered a blocker for 8.2 ... (Not my call.) or do we primarilly care about collaboration in mesh mode for deployments? Very few deployments use mesh mode, because it currently doesn't scale up to more than about ten nearby laptops. (It's due to many interactions between the mesh firmware, the use of multicast presence packets, and the limited bandwidth available on WiFi. We have had numerous fundamental bugs in these areas -- many of which you've seen referred to in this thread -- and are only now being able to re-test after months of effort spent trying to fix some of those bugs.) So OLPC's recommended configuration with more than 10 laptops in a school is to have one (or more) 802.11 access point, and have the XO's use it in ordinary WiFi mode. Some places have school servers, some don't. When there is a school server, it's sitting on a wired Ethernet attached to the WiFi routers. Due to the mesh/multicast overload problems, very few Active Antennas are in use in deployments, as I understand it. And I'm pretty sure that very few deployments use any kind of WiFi network interface directly inside the school server; they use Ethernet there. This page is the best reference for deployment scenarios: http://wiki.laptop.org/go/Networking_scenarios (It even says (Troublesome Scenario: Simple WiFi) that an access point without a school server is problematic with more than a few XO's, because the XO's will use multicast for presence detection, and 802.11 access points tend to use low speed 1Mbps transmissions for multicast packets. With a school server there, the XO's will not use multicast, they'll use ordinary high speed unicast packets to and from the presence service in the school server.) They are calling my flight so, I'll have to be quick. Actually in the presence of an access point, multicast will scale better since it will not be retransmitted by every node in the mesh. Wireless is inherently a broadcast medium. Also, many access points will allow you to change the multicast rate. The question of scalability in infra mode is just a question of the bandwidth demands of the application. Actually this is also true for mesh mode (a chat will do better than a video based activity). In short, the way things are implemented now, infra mode will always scale better. But I certainly agree that infra mode is important for us. With or without a school server or a jabber server. Sorry, for being in a hurry. Cheers! Ricardo John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Suspend vs Network Traffic - blockers
Hi Morgan, You are right about those two being the top ones. I would just add that Simple Wifi http://wiki.laptop.org/go/Networking_scenarios#Simple_WiFi should also be considered. Thanks, Greg S Morgan Collett wrote: On Wed, Aug 13, 2008 at 18:31, Deepak Saxena [EMAIL PROTECTED] wrote: On Aug 13 2008, at 03:27, Ricardo Carrano was caught saying: But the important result is that collaboration does not seem to be working in infra mode. Irrespective of the filter status, no icon is being presented in the mesh view of the other XO. Does anyone else experienced this? Would this be considered a blocker for 8.2 or do we primarilly care about collaboration in mesh mode for deployments? As I understand it, our most likely deployment scenario is http://wiki.laptop.org/go/Networking_scenarios#School_WiFi, with http://wiki.laptop.org/go/Networking_scenarios#Simple_Mesh for ad-hoc away-from-school collaboration. Ricardo, what did you mean by infra mode? Wifi with, or without, a schoolserver/jabber server? Regards Morgan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Suspend vs Network Traffic - blockers
On Wed, Aug 13, 2008 at 09:31:11AM -0700, Deepak Saxena wrote: On Aug 13 2008, at 03:27, Ricardo Carrano was caught saying: But the important result is that collaboration does not seem to be working in infra mode. Irrespective of the filter status, no icon is being presented in the mesh view of the other XO. Does anyone else experienced this? Would this be considered a blocker for 8.2 or do we primarilly care about collaboration in mesh mode for deployments? It's may well be a blocker but I haven't gotten to spend enough time with an XO to understand what's going on. Please get it filed in trac with a nice description. As you do so, please also consider whether there are any similarities with #7612. Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Suspend vs Network Traffic - blockers
On Wed, Aug 13, 2008 at 7:04 PM, Michael Stone [EMAIL PROTECTED] wrote: On Wed, Aug 13, 2008 at 09:31:11AM -0700, Deepak Saxena wrote: On Aug 13 2008, at 03:27, Ricardo Carrano was caught saying: But the important result is that collaboration does not seem to be working in infra mode. Irrespective of the filter status, no icon is being presented in the mesh view of the other XO. Does anyone else experienced this? Would this be considered a blocker for 8.2 or do we primarilly care about collaboration in mesh mode for deployments? It's may well be a blocker but I haven't gotten to spend enough time with an XO to understand what's going on. Please get it filed in trac with a nice description. As you do so, please also consider whether there are any similarities with #7612. Michael, I think you mean another ticket (?). Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Suspend vs Network Traffic - blockers
On Wed, Aug 13, 2008 at 7:04 PM, Michael Stone [EMAIL PROTECTED] wrote: On Wed, Aug 13, 2008 at 09:31:11AM -0700, Deepak Saxena wrote: On Aug 13 2008, at 03:27, Ricardo Carrano was caught saying: But the important result is that collaboration does not seem to be working in infra mode. Irrespective of the filter status, no icon is being presented in the mesh view of the other XO. Does anyone else experienced this? Would this be considered a blocker for 8.2 or do we primarilly care about collaboration in mesh mode for deployments? It's may well be a blocker but I haven't gotten to spend enough time with an XO to understand what's going on. Please get it filed in trac with a nice description. As you do so, please also consider whether there are any similarities with #7612. I added a ticket (7972). Further investigation seems to associate the bug with preexistent version of netwoks.cfg. But I am far from happy with this diagnoses. It would be very helpful if someone could repeat that. Update to joyride with olpc-update and check if this will cause duplicity of the access point icon and the symptoms described in the ticket. And them remove networks.cfg, restart, and check if collaboration starts working. (I marked this as a blocker and component presence-service, but I'm not sure if this is correct) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Suspend vs Network Traffic - blockers
On Tue, Aug 12, 2008 at 3:44 PM, Deepak Saxena [EMAIL PROTECTED] wrote: On Aug 12 2008, at 12:19, Javier Cardona was caught saying: So it doesn't look like Javier's patch actually went into one of our official branches (stable/testing/master). I'm also not sure we need it b/c testing and stable have the following commit that came in 6 days after Javier's patch on trac and it seems to deal with the same issue: commit c16eba59c2183f9d4952eca4d720982cfbe8e031 Author: David Woodhouse [EMAIL PROTECTED] Date: Mon May 19 18:47:52 2008 +0100 libertas: fix multicast handling on eth and msh interfaces You are correct. The patch that I sent is unnecessary, as David Woodhouse rewrote it in a much better way. I tested his implementation and it passed all our test cases. So you can ignore my patch. (In case anyone needs them, our tests for this are here: http://dev.laptop.org/~javier/misc/olpc-mcast-stable-tests.tar.gz) Great! Ricardo, when you get a chance, can you validate on latest joyride that everything is working OK? I performed basic tests on the wake on multicast with joyride 2292. In case someone wants to reproduce, this is a very user level test. It goes like: Wake on multicast test: -- - Set wake on multicast in one XO (XO-A) with: ethtool -s eth0 wol um - Put XO-A in mesh-1 - Put the XO in the neighbor view, so it's easy for you to check the results. - Wait for XO-A to sleep (power led blinking at every two seconds I guess) - From another XO (XO-B), generate an event that should be displayed in the neighbor view of the XO-A. For example, connect XO-B in mesh-1. The XO-A should wake and the XO-B icon should appear on its neighbor view - Wait for XO-A to sleep again - - From another node (XO-B), generate another event that should be displayed in the neighbor view of the XO-A. For example, start and share an activity. The XO-A should wake and the activity icon should appear on its neighbor view Repeat the same without setting the wake on multicast. Sharing activities are not expected to work. Repeat the cycle but now with both XOs connected to an access point. -- When the tests were performed using the mesh interface, apart from a cosmetic issue (*), it seemed to work as expected. But the important result is that collaboration does not seem to be working in infra mode. Irrespective of the filter status, no icon is being presented in the mesh view of the other XO. Does anyone else experienced this? (*) Cosmetic: In one test, XO-B was turned off. it's icon disappear from A's neighbor view, but not completely (the tip of the head was still there) Cheers! Ricardo ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Suspend vs Network Traffic - blockers
On Wed, Aug 13, 2008 at 08:27, Ricardo Carrano [EMAIL PROTECTED] wrote: (*) Cosmetic: In one test, XO-B was turned off. it's icon disappear from A's neighbor view, but not completely (the tip of the head was still there) That's probably a hippo-canvas bug. I've logged #7933 because I couldn't find an existing ticket. Regards Morgan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Suspend vs Network Traffic - blockers
On 8/12/08, John Gilmore [EMAIL PROTECTED] wrote: If try to I ping ff02::5, which isn't interesting to the target, then my %#$*((# flakey CTRL key goes out and won't let me type any more, even with an external keyboard. Tapping slightly hard with one finger all over the shift/ctl/alt/fn area fixes this for me eventually. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Suspend vs Network Traffic - blockers
On 13 Aug 2008, at 11:51, Morgan Collett wrote: On Wed, Aug 13, 2008 at 08:27, Ricardo Carrano [EMAIL PROTECTED] wrote: (*) Cosmetic: In one test, XO-B was turned off. it's icon disappear from A's neighbor view, but not completely (the tip of the head was still there) That's probably a hippo-canvas bug. I've logged #7933 because I couldn't find an existing ticket. Yea I had opened: http://dev.laptop.org/ticket/7660 Neighborhood view generates quite some pixel cruft if you leave the view open in a reasonably active area. Just about all the icons are slightly cropped when drawn** and only partially erased (XO budies, Shared activities, APs). Switch away from the view and back again draws things correctly. **live update draws only, it seems a full neighborhood redraw when switching to the view uses a different code path and functions correctly. --Gary ___ 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
On Wed, Aug 13, 2008 at 18:31, Deepak Saxena [EMAIL PROTECTED] wrote: On Aug 13 2008, at 03:27, Ricardo Carrano was caught saying: But the important result is that collaboration does not seem to be working in infra mode. Irrespective of the filter status, no icon is being presented in the mesh view of the other XO. Does anyone else experienced this? Would this be considered a blocker for 8.2 or do we primarilly care about collaboration in mesh mode for deployments? As I understand it, our most likely deployment scenario is http://wiki.laptop.org/go/Networking_scenarios#School_WiFi, with http://wiki.laptop.org/go/Networking_scenarios#Simple_Mesh for ad-hoc away-from-school collaboration. Ricardo, what did you mean by infra mode? Wifi with, or without, a schoolserver/jabber server? Regards Morgan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Suspend vs Network Traffic - blockers
Dear all, It is very important to correctly approach the interactions between suspend/resume and network traffic. There are at least two mechanisms that need to be in place for both things to be able to operate together without causing major issues: 1 - The multicast address populating on the firmware, that is needed for collaboration to work: http://dev.laptop.org/ticket/6818 2 - The signature based filter, that is needed for ARP to work (keeping in mind that no ARP, no unicast traffic, nothing): http://dev.laptop.org/ticket/6993#comment:2 Both items above represented driver patches that were proposed, discussed and implemented at least in a test kernel or in one of our branches. It is very important that they are confirmed to be in production kernels to be released in 8.2.0. It is also very important that the configurations are done properly. As you can see in http://dev.laptop.org/ticket/6993#comment:2 wake on ARP will not be set automagically. A configuration example can be found in: http://dev.laptop.org/ticket/6993#comment:3 Cheers! Ricardo ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Suspend vs Network Traffic - blockers
Hi Chris, On Tue, Aug 12, 2008 at 11:46 AM, Chris Ball [EMAIL PROTECTED] wrote: Hi Ricardo, There are at least two mechanisms that need to be in place for both things to be able to operate together without causing major issues: 1 - The multicast address populating on the firmware, that is needed for collaboration to work: http://dev.laptop.org/ticket/6818 We're using the testing kernel branch for 8.2, and the latest testing kernels are in the latest Joyride builds. Could you or Deepak confirm that the patches you'd like are in there? I think Deepak is the person to answer to this. 2 - The signature based filter, that is needed for ARP to work (keeping in mind that no ARP, no unicast traffic, nothing): http://dev.laptop.org/ticket/6993#comment:2 As above. It is also very important that the configurations are done properly. As you can see in http://dev.laptop.org/ticket/6993#comment:2 wake on ARP will not be set automagically. A configuration example can be found in: http://dev.laptop.org/ticket/6993#comment:3 Would you recommend keeping track of our current eth0/msh0 IP addresses when programming wake-on-all-ARP, or should we just enable it globally? Hm. That's a good question. Between implementention complexity (of changing the filter eveytime an IP changes) and power efficiency (of preventing some unnecessary wake ups), at this point in time (pretty close to release), I would be inclined towards the second approach. (By the way, the EC now suppresses 8388 wakeups when in sleep/lid closed mode, so we don't need to change the filter/wol behavior when switching between suspend and sleep; we can leave it in suspend configuration.) Thanks, - Chris. -- Chris Ball [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Suspend vs Network Traffic - blockers
On Aug 12 2008, at 12:22, Ricardo Carrano was caught saying: Dear all, It is very important to correctly approach the interactions between suspend/resume and network traffic. There are at least two mechanisms that need to be in place for both things to be able to operate together without causing major issues: 1 - The multicast address populating on the firmware, that is needed for collaboration to work: http://dev.laptop.org/ticket/6818 So it doesn't look like Javier's patch actually went into one of our official branches (stable/testing/master). I'm also not sure we need it b/c testing and stable have the following commit that came in 6 days after Javier's patch on trac and it seems to deal with the same issue: commit c16eba59c2183f9d4952eca4d720982cfbe8e031 Author: David Woodhouse [EMAIL PROTECTED] Date: Mon May 19 18:47:52 2008 +0100 libertas: fix multicast handling on eth and msh interfaces We weren't properly handling multicast on the mesh interface. Fix that, which involves setting up the hardware to use the union of dev-mc_list for both eth%d and msh%d devices. This means we can't do it directly from -set_multicast_list() because we'd need to lock the other device to read its list, and we can't do that because it might deadlock. So punt the actual work to keventd. Also, invoke the same when taking an interface down; for some reason the core calls -set_multicast_list while IFF_UP is still set in dev-flags when we're taking it down, so its addresses don't get removed then. We also convert MAC_MULTICAST_ADR to a direct command while we're at it, removing one more entry from the big switch statement in the deprecated lbs_prepare_and_send_command() function. Change the priority of the 'unknown command' warnings in that switch statement too, because we really do want to know about it if it happens. Signed-off-by: David Woodhouse [EMAIL PROTECTED] Ricardo, have you reproduced the issues with the latest kernels? 2 - The signature based filter, that is needed for ARP to work (keeping in mind that no ARP, no unicast traffic, nothing): http://dev.laptop.org/ticket/6993#comment:2 This patch applies cleanly and if we need this for 8.2 mesh to work properly, I'm OK pushing it in (depending on how our discussion on change control ends up) but would like to see us vet this upstream for the future. Instead of iwpriv, we could theoretically extend the ethtool interface to support this if we think more HW in the future will support this sort of filtering. Javier, can you work on push to upstream? Have we already tried and been NACKed? Thanks for point these out Ricardo! rant This is not the first set of issues that have come up due to out-of-tree, non-upstream development that was stuck in one of our trees or trac and we need to work on reducing our differences from upstream. Our delta is just going to get bigger and unmaintainble with regressions constantly popping up as patches get dropped. For 9.1 (9.2 more realistically?) I highly suggest one of our priorities be that a stock kernel.org kernel just works out of the box on our lovely little laptop, even if that means rewriting parts of drivers, firmware, etc. /rant ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Suspend vs Network Traffic - blockers
Hi, We are waiting for Marvell for an updated firmware that implements a simpler API to configure wake-on-wlan signatures. The proposed API was really hard to use and would require additional changes to support IPv6. Before pushing this upstream we wanted to have a cleaner driver/fw interface. Marvell will implement the new wow-signature API with the next firmware release (22p18) OK, so I'll not push the existing patches into 8.2 and we can roll this into 8.2.1 when all the bits are ready. Does this mean we'll be without wake-on-ARP for 8.2? Is there something we can do to avoid that? Thanks, - Chris. -- Chris Ball [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Suspend vs Network Traffic - blockers
We can use the existing filter API M - Original Message - From: Chris Ball [EMAIL PROTECTED] Sent: 08/12/2008 03:49 PM AST To: [EMAIL PROTECTED] Cc: Javier Cardona [EMAIL PROTECTED]; Ricardo Carrano [EMAIL PROTECTED]; Kimberley Quirk [EMAIL PROTECTED]; [EMAIL PROTECTED]; Michail Bletsas; Devel [EMAIL PROTECTED]; David Woodhouse [EMAIL PROTECTED] Subject: Re: Suspend vs Network Traffic - blockers Hi, We are waiting for Marvell for an updated firmware that implements a simpler API to configure wake-on-wlan signatures. The proposed API was really hard to use and would require additional changes to support IPv6. Before pushing this upstream we wanted to have a cleaner driver/fw interface. Marvell will implement the new wow-signature API with the next firmware release (22p18) OK, so I'll not push the existing patches into 8.2 and we can roll this into 8.2.1 when all the bits are ready. Does this mean we'll be without wake-on-ARP for 8.2? Is there something we can do to avoid that? Thanks, - Chris. -- Chris Ball [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Suspend vs Network Traffic - blockers
Hi, OK, so I'll not push the existing patches into 8.2 and we can roll this into 8.2.1 when all the bits are ready. Does this mean we'll be without wake-on-ARP for 8.2? Is there something we can do to avoid that? We can use the existing filter Not if Deepak doesn't merge it, surely? Maybe I misunderstood something? - Chris. -- Chris Ball [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Suspend vs Network Traffic - blockers
Yes, Deepak will have to merge the required patches. M - Original Message - From: Chris Ball [EMAIL PROTECTED] Sent: 08/12/2008 03:55 PM AST To: Michail Bletsas Cc: Deepak Saxena [EMAIL PROTECTED]; Javier Cardona [EMAIL PROTECTED]; Ricardo Carrano [EMAIL PROTECTED]; Kimberley Quirk [EMAIL PROTECTED]; greg [EMAIL PROTECTED]; Devel [EMAIL PROTECTED] Subject: Re: Suspend vs Network Traffic - blockers Hi, OK, so I'll not push the existing patches into 8.2 and we can roll this into 8.2.1 when all the bits are ready. Does this mean we'll be without wake-on-ARP for 8.2? Is there something we can do to avoid that? We can use the existing filter Not if Deepak doesn't merge it, surely? Maybe I misunderstood something? - Chris. -- Chris Ball [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Suspend vs Network Traffic - blockers
Hi Javier, On Tue, Aug 12, 2008 at 3:19 PM, Javier Cardona [EMAIL PROTECTED] wrote: Deepak, On Tue, Aug 12, 2008 at 10:38 AM, Deepak Saxena [EMAIL PROTECTED] wrote: There are at least two mechanisms that need to be in place for both things to be able to operate together without causing major issues: 1 - The multicast address populating on the firmware, that is needed for collaboration to work: http://dev.laptop.org/ticket/6818 So it doesn't look like Javier's patch actually went into one of our official branches (stable/testing/master). I'm also not sure we need it b/c testing and stable have the following commit that came in 6 days after Javier's patch on trac and it seems to deal with the same issue: commit c16eba59c2183f9d4952eca4d720982cfbe8e031 Author: David Woodhouse [EMAIL PROTECTED] Date: Mon May 19 18:47:52 2008 +0100 libertas: fix multicast handling on eth and msh interfaces You are correct. The patch that I sent is unnecessary, as David Woodhouse rewrote it in a much better way. I tested his implementation and it passed all our test cases. So you can ignore my patch. (In case anyone needs them, our tests for this are here: http://dev.laptop.org/~javier/misc/olpc-mcast-stable-tests.tar.gz) 2 - The signature based filter, that is needed for ARP to work (keeping in mind that no ARP, no unicast traffic, nothing): http://dev.laptop.org/ticket/6993#comment:2 This patch applies cleanly and if we need this for 8.2 mesh to work properly, I'm OK pushing it in (depending on how our discussion on change control ends up) but would like to see us vet this upstream for the future. Instead of iwpriv, we could theoretically extend the ethtool interface to support this if we think more HW in the future will support this sort of filtering. Javier, can you work on push to upstream? Have we already tried and been NACKed? We are waiting for Marvell for an updated firmware that implements a simpler API to configure wake-on-wlan signatures. The proposed API was really hard to use and would require additional changes to support IPv6. Before pushing this upstream we wanted to have a cleaner driver/fw interface. 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 inneficient in doing so. It seeems 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? Cheers! Ricardo ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Suspend vs Network Traffic - blockers
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). Setting up the filter to wake the machine on EVERY arp packet would be trivial. These occur pretty often on an active network, though; I think they're the most common broadcast packets. So we'd get a fair number of useless wakeups, almost equivalent to wake on all broadcasts. It would be more power efficient to set the filter to only wake on every arp that's addressed to our own IPv4 address. (Doing this for the general case of multiple IPv4 addresses on the same interface is also possible, just harder to test. I don't think NetworkManager ever puts two IPv4 addresses on either eth0 or msh0; doing so requires manual configuration, so we could skip that in the short term and file a bug report for the long term.) (On the other hand, IPv6 requires support for multiple IPv6 addresses on the same interface, to support automatic renumbering without dropping existing TCP connections, but see below.) If I recall correctly, the filter was compatible with IPv6, it was just terribly inneficient in doing so. If we have multicast wakeup working, then IPv6 takes care of itself. All ethernet-like kernel drivers already configure the multicast filter to have the right set of MAC addresses to receive IPv6 arps, which are called Neighbor Discovery packets, and which arrive in multicast packets, not in broadcast packets. There's no need for an additional filter beyond the existing multicast filter. We hashed this out painfully over many months in #4616 (which is still not closed). In joyride-2263, wake on multicast did not appear to be enabled by the driver by default. This should be fixed. You can manually set it with ethtool. Caveat: I haven't yet rerun the tests for the half-dozen existing TRAC bugs that deal with suspend and libertas. I just quickly looked at what the ethtool command reported. John ___ 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
Thank you, Javier! On Tue, Aug 12, 2008 at 6:44 PM, Javier Cardona [EMAIL PROTECTED] wrote: 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. Agreed. 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. Agreed too. 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... Yes. It's not what we want for 2009. Agreed once more. -- 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: Suspend vs Network Traffic - blockers
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... The wake-on-multicast code *already* uses the existing multicast filter, which is already set up by the Linux driver. It only wakes us up when a multicast *that we're interested in* comes along. Just as an awake Libertas only hands the host multicast packets *that we're interested in*. This is why IPv6 based their arp on multicast. It just works, without waking up every other host on that network to receive a broadcast that it didn't really need to see. And without adding painful kludges to the network interface hardware/firmware. See http://dev.laptop.org/ticket/4616#comment:22 I'm testing this with two laptops, each G1G1 MP, each joyride-2263. Both are associated with an access point about four feet away. When I do: ping6 -i eth0 ff02::1 I get pings back from both of them when they're awake. (In fact, I get TWO pings back from the target XO, and one from the source.) On both of them, ethtool eth0 reports Wake on: u. When the target XO is suspended, and I do the same command, then I get no pings back from the target. If I do ethtool -s eth0 wol um on the target, and re-ping from the source, I get three lines (two from the target, one from the source) for each ping, until the target suspends; then I get some seconds of no response from the target, then after it awakens, I get a bunch of packets back from it (that were buffered). If try to I ping ff02::5, which isn't interesting to the target, then my %#$*((# flakey CTRL key goes out and won't let me type any more, even with an external keyboard. So I can't test it. I've tried talking to a repair shop to get a new keyboard, and got no response. Sorry... What it's supposed to do is to not wake up. That's what happened last time I tested it. Somebody with two working keyboards will have to do this test. I didn't get to test them on msh0, which is where the original bug report #4616 happened. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Suspend vs Network Traffic - blockers
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). Sorry, I may have misinterpreted Javier's message due to his use of all in the sentence. Indeed, we *do* want to wake from an automatic suspend whenever an mDNS message comes in. The reason we had so much trouble with the Presence Service and activity sharing in the presence of autosuspend, is because the laptop wouldn't maintain its presence on the network, and wouldn't respond when other laptops sought it out. Laptops were always disappearing from each others' view. That's the thing we're trying to fix here. We don't want to wake on all multicast traffic. 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!) That's why we need the low level bits to really start working -- so we can do system-level testing. Last time we did serious system-level testing, early in 2008, everything melted. We identified a bunch of complicated things to fix, and we've fixed some of them -- it's time to push all those fixes into one release, and do system-level testing again.) John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
