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