Good News. I managed to get this working (albeit via changes in sugar). The details are at :: <a href="http://git.sugarlabs.org/dextrose/mainline/commit/4ac1a5300f4c43608b0f009a23d966d404a15632">http://git.sugarlabs.org/dextrose/mainline/commit/4ac1a5300f4c43608b0f009a23d966d404a15632</a> Regards, Ajay <div class="gmail_quote">On Wed, May 2, 2012 at 6:02 PM, Paul Fox <<a href="mailto:pgf@laptop.org" target="_blank">pgf@laptop.org</a>> wrote: <blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div class="im">martin wrote: > On Wed, May 2, 2012 at 3:22 AM, Ajay Garg <<a href="mailto:ajaygargnsit@gmail.com">ajaygargnsit@gmail.com</a>> wrote: > > The /etc/powerd/postresume.d/disable_mesh.sh doesn't work. > > So we need to understand why it does not work. Is it a race condition? > Perhaps it is better fixed as a udev script -- triggering when the > device appears. </div>i think it's almost a guaranteed race. that script essentially does this: while [ ! -f /sys/class/net/eth0/lbs_mesh ] do sleep 0.5 done echo 0 > /sys/class/net/eth0/lbs_mesh in other words -- the disable_mesh script will discover the disable node at just about exactly the time that NM discovers the interface. there's also the "lbs_disablemesh" module parameter, which could be supplied at initial module load. does that not work, for some reason? (i seem to recall there may be a problem with it.) paul <div class="HOEnZb"><div class="h5"> > > The step that disable_mesh performs is very important. If you don't > disable it at that level, you haven't disabled mesh at all and all the > problems persist. > > >> - disable mesh on boot > > Done. Added the 'echo 0' script in 'start()' method of NetworkManager, so > > that the effect takes place before NetworkManager starts up. Works like a > > charm. > > Ok. Maybe a udev script is a better place. > > >> - disable mesh on resume, from a powerd-triggered script > > Does not work, as explained above. > > Right but you MUST find a way to make it work. > > >> - blacklist the MAC address so NM ignores it > >> > >> you win. Yes, every XO has a different MAC address, but you can read > >> that on first boot of the OS, and write the NM configuration. See the > >> olpc-configure script for examples. > > > > > > Would be awesome. I believe this is the one and only complete solution > > possible :) > > Careful here! This only hides the device from NM so you don't race with NM. > > > Could you point me to the suitable (examples) link? I will be heartfully > > grateful. > > look at the latest olpc-configure in git://<a href="http://dev.laptop.org/projects/olpc-utils" target="_blank">dev.laptop.org/projects/olpc-utils</a> > > > > m > -- > <a href="mailto:martin.langhoff@gmail.com">martin.langhoff@gmail.com</a> > <a href="mailto:martin@laptop.org">martin@laptop.org</a> -- Software Architect - OLPC > - ask interesting questions > - don't get distracted with shiny stuff - working code first > - <a href="http://wiki.laptop.org/go/User:Martinlanghoff" target="_blank">http://wiki.laptop.org/go/User:Martinlanghoff</a> </div></div><div class="HOEnZb"><div class="h5"> > _______________________________________________ > Devel mailing list > <a href="mailto:Devel@lists.laptop.org">Devel@lists.laptop.org</a> > <a href="http://lists.laptop.org/listinfo/devel" target="_blank">http://lists.laptop.org/listinfo/devel</a> =--------------------- paul fox, <a href="mailto:pgf@laptop.org">pgf@laptop.org</a> </div></div></blockquote></div>