Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Ajay Garg]

Thanks Martin and Jon for the replies.

On Sun, Apr 29, 2012 at 3:04 PM, Jon Nettleton <jon.nettleton at gmail.com>wrote:

> On Sun, Apr 29, 2012 at 10:04 AM, Martin Abente
> <martin.abente.lahaye at gmail.com> wrote:
> > Are you guys still using this?
> >
> http://git.sugarlabs.org/dextrose-platform/mainline/blobs/master/etc/powerd/postresume.d/disable_mesh.sh
> >
> > If so, you should remove it IF there is no way to guarantee that it will
> run
> > before NM picks up the device. At least it will avoid the crash...
> >
> > I would ask in the NM community if there is a better way to disable a
> > particular device, like banning a device(?).
>
> Edit /etc/NetworkManager/NetworkManager.conf
>
> Add a line to the [main] section like
>
> no-auto-default=xx:xx:xx:xx:xx (obviously replacing the x's with the
> mac-address of your mesh device.)
>


This should be a lot cleaner solution.
However, two queries ::


a)
Doing "ifconfig" on the XO-1, only shows information for "eth0" and "lo"
(no mesh device listed).
So, how can the mac address for the mesh device be found?


b)
Are mac address for XO-1s, EXACTLY same, for every XO-1 on this planet?


Looking forward to a reply.



Thanks and Regards,
Ajay



>
> This does not stop NM from managing your device, but does stop it from
> auto-connecting the device.  You would still be able to go into NM and
> manually enable the mesh network.   If you want NM to completely leave
> the device alone you can go one more step.
>
> Also in /etc/NetworkManager/NetworkManager.conf
>
> change the plugins line to
>
> plugins=ifcfg-rh,keyfile
>
> Then add a section that looks like this.
>
> [keyfile]
> unmanaged-devices=mac:xx:xx:xx:xx:xx:xx (Where X's are the mac address
> of the device you want to ignore)
>
>
> Hope that helps, let me know if you have further questions.
>
> -Jon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20120430/49b9bfce/attachment.html>