Thanks Martin.<br><br>This REALLY is a useful mail. Thanks.<br><br>My comments inline.<br><br><br><div class="gmail_quote">On Tue, May 1, 2012 at 8:50 PM, Martin Abente <span dir="ltr"><<a href="mailto:martin.abente.lahaye@gmail.com" target="_blank">martin.abente.lahaye@gmail.com</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">Probably the answer is that the start() method is not executed, which means there are different execution paths between reboot and resume.<br>
</blockquote><div><br>Me thought the same. Thanks for the affirmation.<br><br><br><br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>Same happened with powerd, we had to include the script I mentioned in the previous response, _maybe_ there is something similar to the powerd postresume.d in NM...<br>
</blockquote><div><br>Thanks a ton for this light.<br>I will look up into it; and will get back to you.<br><br><br><br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<br>In any case, IIRC there was supposed to be a driver patch that would replace all these hacks for disabling the mesh (for good). Any clue what happened with it?<br></blockquote><div> </div><div>Well, that would be the ultimate cleanest solution.<br>
However, I believe that is not present, since the issue is happening anyways.<br><br><br>Ccing dextrose.<br><br><br>Thanks again.<br><br><br>Thanks and Regards,<br>Ajay<br><br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br><div class="gmail_quote"><div><div class="h5">On Tue, May 1, 2012 at 4:55 PM, Ajay Garg <span dir="ltr"><<a href="mailto:ajay@activitycentral.com" target="_blank">ajay@activitycentral.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="h5">which actually brings me back to my original question ::<br><br>"""<br>
Why is it so that putting the 'disable-mesh-script' in the 'start()' method of '/etc/init.d/Networkmanager' works (always) for (re)boot; but never works for resume-upon-suspend?<br>

"""<br><br><br>Regards,<br>Ajay<div><div><br><br><div class="gmail_quote">On Tue, May 1, 2012 at 8:07 PM, Ajay Garg <span dir="ltr"><<a href="mailto:ajay@activitycentral.com" target="_blank">ajay@activitycentral.com</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">Thanks Paul.<br><br><div class="gmail_quote"><div><div>On Tue, May 1, 2012 at 8:03 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><div>ajay wrote:<br>
 > Any ideas please, regarding the two latest queries :) ?<br>
 ><br>
 > Regards,<br>
 > Ajay<br>
 ><br>
 > On Mon, Apr 30, 2012 at 1:00 PM, Ajay Garg <<a href="mailto:ajay@activitycentral.com" target="_blank">ajay@activitycentral.com</a>> wrote:<br>
 ><br>
 > > Thanks Martin and Jon for the replies.<br>
 > ><br>
 > > On Sun, Apr 29, 2012 at 3:04 PM, Jon Nettleton <<a href="mailto:jon.nettleton@gmail.com" target="_blank">jon.nettleton@gmail.com</a>>wrote:<br>
 > ><br>
 > >> On Sun, Apr 29, 2012 at 10:04 AM, Martin Abente<br>
 > >> <<a href="mailto:martin.abente.lahaye@gmail.com" target="_blank">martin.abente.lahaye@gmail.com</a>> wrote:<br>
 > >> > Are you guys still using this?<br>
 > >> ><br>
 > >><br>
 > <a href="http://git.sugarlabs.org/dextrose-platform/mainline/blobs/master/etc/powerd/post" target="_blank">http://git.sugarlabs.org/dextrose-platform/mainline/blobs/master/etc/powerd/post</a><br>
 > resume.d/disable_mesh.sh<br>
 > >> ><br>
 > >> > If so, you should remove it IF there is no way to guarantee that it<br>
 > >> will run<br>
 > >> > before NM picks up the device. At least it will avoid the crash...<br>
 > >> ><br>
 > >> > I would ask in the NM community if there is a better way to disable a<br>
 > >> > particular device, like banning a device(?).<br>
 > >><br>
 > >> Edit /etc/NetworkManager/NetworkManager.conf<br>
 > >><br>
 > >> Add a line to the [main] section like<br>
 > >><br>
 > >> no-auto-default=xx:xx:xx:xx:xx (obviously replacing the x's with the<br>
 > >> mac-address of your mesh device.)<br>
 > >><br>
 > ><br>
 > ><br>
 > > This should be a lot cleaner solution.<br>
 > > However, two queries ::<br>
 > ><br>
 > ><br>
 > > a)<br>
 > > Doing "ifconfig" on the XO-1, only shows information for "eth0" and "lo"<br>
 > > (no mesh device listed).<br>
 > > So, how can the mac address for the mesh device be found?<br>
<br>
</div></div>it's the same as that for eth0.<br></blockquote></div></div><div><br>Does that mean, that banning eth0-mac-address prevent the loading of wifi-hardware-device as well (in obvious addition to mesh) ?<br>This seems very pricky.<br>



<br><br><br> </div><div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div><br>
 > > b)<br>
 > > Are mac address for XO-1s, EXACTLY same, for every XO-1 on this planet?<br>
<br>
</div>of course not.  how would they tell one another apart?<br></blockquote></div><div><br>Alright.<br>But my first doubt (same mac address for mesh-hardware and wifi-hardware) has put me in topspin :~<br><br><br><br>Regards,<br>



Ajay<br><br> </div><div><div><br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
paul<br>
<div><br>
 > ><br>
 > ><br>
 > > Looking forward to a reply.<br>
 > ><br>
 > ><br>
 > ><br>
 > > Thanks and Regards,<br>
 > > Ajay<br>
 > ><br>
 > ><br>
 > ><br>
 > >><br>
 > >> This does not stop NM from managing your device, but does stop it from<br>
 > >> auto-connecting the device.  You would still be able to go into NM and<br>
 > >> manually enable the mesh network.   If you want NM to completely leave<br>
 > >> the device alone you can go one more step.<br>
 > >><br>
 > >> Also in /etc/NetworkManager/NetworkManager.conf<br>
 > >><br>
 > >> change the plugins line to<br>
 > >><br>
 > >> plugins=ifcfg-rh,keyfile<br>
 > >><br>
 > >> Then add a section that looks like this.<br>
 > >><br>
 > >> [keyfile]<br>
 > >> unmanaged-devices=mac:xx:xx:xx:xx:xx:xx (Where X's are the mac address<br>
 > >> of the device you want to ignore)<br>
 > >><br>
 > >><br>
 > >> Hope that helps, let me know if you have further questions.<br>
 > >><br>
 > >> -Jon<br>
 > >><br>
 > ><br>
 > ><br>
</div> > part 2     text/plain                 129<br>
<div> > _______________________________________________<br>
 > Devel mailing list<br>
 > <a href="mailto:Devel@lists.laptop.org" target="_blank">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>
</div>=---------------------<br>
 paul fox, <a href="mailto:pgf@laptop.org" target="_blank">pgf@laptop.org</a><br>
</blockquote></div></div><br>
</blockquote></div><br>
</div></div><br></div></div>_______________________________________________<br>
Sugar-devel mailing list<br>
<a href="mailto:Sugar-devel@lists.sugarlabs.org" target="_blank">Sugar-devel@lists.sugarlabs.org</a><br>
<a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a><br>
<br></blockquote></div><br>
</blockquote></div><br>