subject:"Wanting to know a bit of \(NetworkManager\) workflow upon resume\-from\-suspend"

On Wed, May 2, 2012 at 12:13 AM, Ajay Garg ajaygargn...@gmail.com wrote:
 Just that, we do not wish to set up a mesh-network, as per say.

I think you are missing the background reason here. AFAIK, reasons to
disable mesh network on XO-1:

 - Mesh can easily saturate RF, so dense usage scenarios (schools!)
benefit from switching it off.

 - Easier out-of-the-box interop with later XO-1.x models, where the
under a tree network uses ad-hoc 802.11g.

 By removing all references to the device, we could provide a soft solution

Nah, messing with Sugar code is the wrong solution.



m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- Software Architect - OLPC
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

On Wed, May 2, 2012 at 11:49 AM, Martin Langhoff
martin.langh...@gmail.comwrote:

 On Wed, May 2, 2012 at 12:13 AM, Ajay Garg ajaygargn...@gmail.com wrote:
  Just that, we do not wish to set up a mesh-network, as per say.

 I think you are missing the background reason here. AFAIK, reasons to
 disable mesh network on XO-1:

  - Mesh can easily saturate RF, so dense usage scenarios (schools!)
 benefit from switching it off.

  - Easier out-of-the-box interop with later XO-1.x models, where the
 under a tree network uses ad-hoc 802.11g.

  By removing all references to the device, we could provide a soft
 solution

 Nah, messing with Sugar code is the wrong solution.


I agree. But there is no working lower-level solution :\


Regards,
Ajay





 m
 --
  martin.langh...@gmail.com
  mar...@laptop.org -- Software Architect - OLPC
  - ask interesting questions
  - don't get distracted with shiny stuff  - working code first
  - http://wiki.laptop.org/go/User:Martinlanghoff

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

2012-05-02 Thread Anish Mangal

On Wed, May 2, 2012 at 11:49 AM, Martin Langhoff
martin.langh...@gmail.com wrote:
 On Wed, May 2, 2012 at 12:13 AM, Ajay Garg ajaygargn...@gmail.com wrote:
 Just that, we do not wish to set up a mesh-network, as per say.

 I think you are missing the background reason here. AFAIK, reasons to
 disable mesh network on XO-1:

  - Mesh can easily saturate RF, so dense usage scenarios (schools!)
 benefit from switching it off.

  - Easier out-of-the-box interop with later XO-1.x models, where the
 under a tree network uses ad-hoc 802.11g.


+1, this was the reason

 By removing all references to the device, we could provide a soft solution

 Nah, messing with Sugar code is the wrong solution.



 m
 --
  martin.langh...@gmail.com
  mar...@laptop.org -- Software Architect - OLPC
  - ask interesting questions
  - don't get distracted with shiny stuff  - working code first
  - http://wiki.laptop.org/go/User:Martinlanghoff
 ___
 Sugar-devel mailing list
 sugar-de...@lists.sugarlabs.org
 http://lists.sugarlabs.org/listinfo/sugar-devel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

On Wed, May 2, 2012 at 2:25 AM, Ajay Garg ajaygargn...@gmail.com wrote:
 I agree. But there is no working lower-level solution :\

Let's fix that. Messing with Sugar won't help you.

Earlier in the thread someone pointed to you the scripts to trigger on
resume (by powerd). Do those work? Not work? What's the problem there?

AIUI, if you

 - disable mesh on boot
 - disable mesh on resume, from a powerd-triggered script
 - 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.

cheers,



m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- Software Architect - OLPC
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

Thanks Martin (a ton !!)

On Wed, May 2, 2012 at 12:32 PM, Martin Langhoff
martin.langh...@gmail.comwrote:

 On Wed, May 2, 2012 at 2:25 AM, Ajay Garg ajaygargn...@gmail.com wrote:
  I agree. But there is no working lower-level solution :\

 Let's fix that.


Great !!!







 Messing with Sugar won't help you.

 Earlier in the thread someone pointed to you the scripts to trigger on
 resume (by powerd). Do those work? Not work? What's the problem there?


The /etc/powerd/postresume.d/disable_mesh.sh  doesn't work.
My belief is that there is the same problem - race condition between the
'echo 0' script, and NetworkManager. This causes the NetworkManager to
crash randomly.







 AIUI, if you

  - 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.







  - disable mesh on resume, from a powerd-triggered script


Does not work, as explained above.







  - 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 :)
Could you point me to the suitable (examples) link? I will be heartfully
grateful.




 cheers,



 m
 --
  martin.langh...@gmail.com
  mar...@laptop.org -- Software Architect - OLPC
  - ask interesting questions
  - don't get distracted with shiny stuff  - working code first
  - http://wiki.laptop.org/go/User:Martinlanghoff



Regards,
Ajay
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

On Wed, May 2, 2012 at 3:22 AM, Ajay Garg ajaygargn...@gmail.com 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.

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://dev.laptop.org/projects/olpc-utils



m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- Software Architect - OLPC
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

2012-05-02 Thread Martin Abente

I think (guessing by the responses) the original problem here is that, if
you disable the mesh AFTER NM has taken the device, NM crashes. This a
regression bug, considering that this didn't happened in fedora-11 based
builds.

So the solution here is to find another place to place the script, where it
guarantee that the script will be executed before NM does its job at resume
time.

Another solution is to find out why NM crashes now and why didn't before,
but I wouldn't go that way.

Cheers,


On Wed, May 2, 2012 at 3:28 AM, Martin Langhoff
martin.langh...@gmail.comwrote:

 On Wed, May 2, 2012 at 3:22 AM, Ajay Garg ajaygargn...@gmail.com 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.

 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://
 dev.laptop.org/projects/olpc-utils



 m
 --
  martin.langh...@gmail.com
  mar...@laptop.org -- Software Architect - OLPC
  - ask interesting questions
  - don't get distracted with shiny stuff  - working code first
  - http://wiki.laptop.org/go/User:Martinlanghoff
 ___
 Sugar-devel mailing list
 sugar-de...@lists.sugarlabs.org
 http://lists.sugarlabs.org/listinfo/sugar-devel

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

On Wed, May 2, 2012 at 4:07 AM, Martin Abente
martin.abente.lah...@gmail.com wrote:
 I think (guessing by the responses) the original problem here is that, if
 you disable the mesh AFTER NM has taken the device, NM crashes. This a
 regression bug, considering that this didn't happened in fedora-11 based
 builds.

The timings in F11 builds were completely different. Maybe you were
winning the race that you're now losing.

 So the solution here is to find another place to place the script, where it
 guarantee that the script will be executed before NM does its job at resume
 time.

udev script :-) -- I am pretty sure you can number yourself lower (to
run earlier) than the udev script that fires off the new device
event to NM.

 Another solution is to find out why NM crashes now and why didn't before,
 but I wouldn't go that way.

Making NM completely resilient to these race conditions is probably a hard task.

cheers,



m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- Software Architect - OLPC
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

2012-05-02 Thread Jon Nettleton

On Wed, May 2, 2012 at 10:42 AM, Martin Langhoff
martin.langh...@gmail.com wrote:
 On Wed, May 2, 2012 at 4:07 AM, Martin Abente
 martin.abente.lah...@gmail.com wrote:
 I think (guessing by the responses) the original problem here is that, if
 you disable the mesh AFTER NM has taken the device, NM crashes. This a
 regression bug, considering that this didn't happened in fedora-11 based
 builds.

 The timings in F11 builds were completely different. Maybe you were
 winning the race that you're now losing.

 So the solution here is to find another place to place the script, where it
 guarantee that the script will be executed before NM does its job at resume
 time.

 udev script :-) -- I am pretty sure you can number yourself lower (to
 run earlier) than the udev script that fires off the new device
 event to NM.

 Another solution is to find out why NM crashes now and why didn't before,
 but I wouldn't go that way.

 Making NM completely resilient to these race conditions is probably a hard 
 task.

This is also a temporary solution.  There is a kernel patch in 3.1 and
greater kernels that allows you to disable mesh as a kernel module
parameter.

I just played around with the udev script and there definitely seems
to be some timing issues even with that.

-Jon
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

2012-05-02 Thread Martin Abente

How hard and sensible do you think it could be to backport that patch? :D
(Assuming that touching the kernel is an option for someone, hehe)

On Wed, May 2, 2012 at 5:21 AM, Jon Nettleton jon.nettle...@gmail.comwrote:

 On Wed, May 2, 2012 at 10:42 AM, Martin Langhoff
 martin.langh...@gmail.com wrote:
  On Wed, May 2, 2012 at 4:07 AM, Martin Abente
  martin.abente.lah...@gmail.com wrote:
  I think (guessing by the responses) the original problem here is that,
 if
  you disable the mesh AFTER NM has taken the device, NM crashes. This a
  regression bug, considering that this didn't happened in fedora-11 based
  builds.
 
  The timings in F11 builds were completely different. Maybe you were
  winning the race that you're now losing.
 
  So the solution here is to find another place to place the script,
 where it
  guarantee that the script will be executed before NM does its job at
 resume
  time.
 
  udev script :-) -- I am pretty sure you can number yourself lower (to
  run earlier) than the udev script that fires off the new device
  event to NM.
 
  Another solution is to find out why NM crashes now and why didn't
 before,
  but I wouldn't go that way.
 
  Making NM completely resilient to these race conditions is probably a
 hard task.

 This is also a temporary solution.  There is a kernel patch in 3.1 and
 greater kernels that allows you to disable mesh as a kernel module
 parameter.

 I just played around with the udev script and there definitely seems
 to be some timing issues even with that.

 -Jon

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

Martin, just one small query :

In one of the earlier mails, it was said that the mac address for msh0 is
the same as eth0.
So, would blacklisting the (same) device, be feasible? I mean, would that
not _also_ disable general wifi network detections?


Regards,
Ajay

On Wed, May 2, 2012 at 12:58 PM, Martin Langhoff
martin.langh...@gmail.comwrote:

 On Wed, May 2, 2012 at 3:22 AM, Ajay Garg ajaygargn...@gmail.com 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.

 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://
 dev.laptop.org/projects/olpc-utils



 m
 --
  martin.langh...@gmail.com
  mar...@laptop.org -- Software Architect - OLPC
  - ask interesting questions
  - don't get distracted with shiny stuff  - working code first
  - http://wiki.laptop.org/go/User:Martinlanghoff

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

On Wed, May 2, 2012 at 5:32 AM, Ajay Garg ajaygargn...@gmail.com wrote:
 In one of the earlier mails, it was said that the mac address for msh0 is
 the same as eth0.

Ah, sorry, you're correct, that won't help.

So your options are

 - a kernel module parameter, as Jon proposes, in modprobe.d/ or in
the boot commandline

 - udev rule / script that triggers before the event is sent to NM




m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- Software Architect - OLPC
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

2012-05-02 Thread Paul Fox

martin wrote:
  On Wed, May 2, 2012 at 3:22 AM, Ajay Garg ajaygargn...@gmail.com 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.

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

  
  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://dev.laptop.org/projects/olpc-utils
  
  
  
  m
  -- 
   martin.langh...@gmail.com
   mar...@laptop.org -- Software Architect - OLPC
   - ask interesting questions
   - don't get distracted with shiny stuff  - working code first
   - http://wiki.laptop.org/go/User:Martinlanghoff
  ___
  Devel mailing list
  Devel@lists.laptop.org
  http://lists.laptop.org/listinfo/devel

=-
 paul fox, p...@laptop.org
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

Good News.

I managed to get this working (albeit via changes in sugar).

The details are at ::
http://git.sugarlabs.org/dextrose/mainline/commit/4ac1a5300f4c43608b0f009a23d966d404a15632

Regards,
Ajay

On Wed, May 2, 2012 at 6:02 PM, Paul Fox p...@laptop.org wrote:

martin wrote:
On Wed, May 2, 2012 at 3:22 AM, Ajay Garg ajaygargn...@gmail.com
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.

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

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://
dev.laptop.org/projects/olpc-utils

m
--
martin.langh...@gmail.com
mar...@laptop.org -- Software Architect - OLPC
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

=-
paul fox, p...@laptop.org

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

2012-05-02 Thread Kevin Gordon

On Wed, May 2, 2012 at 10:18 AM, Ajay Garg ajaygargn...@gmail.com wrote:

Good News.

I managed to get this working (albeit via changes in sugar).

The details are at ::

http://git.sugarlabs.org/dextrose/mainline/commit/4ac1a5300f4c43608b0f009a23d966d404a15632

I have a couple of minor observations from the great unwashed - yes me.
One is that this solution perhaps wont have any effect when one boots to
the Gnome side. Two, this may be build version dependent, as there would
appear from some of the discussions in the group that there is an effort
for the 12.1.0 builds to more closely link the NM functions on Sugar and
Gnome so that settings are identical when restarting the other
environment. The echo script in boot startup and the corresponding entry
powerd resume , on the other hand, might handle both. Not sure yet, as I'm
still playing with WAP variants, and also, I am the newbie :-)

Regards,
Ajay

On Wed, May 2, 2012 at 6:02 PM, Paul Fox p...@laptop.org wrote:

martin wrote:
On Wed, May 2, 2012 at 3:22 AM, Ajay Garg ajaygargn...@gmail.com
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.

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

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://
dev.laptop.org/projects/olpc-utils

=-
paul fox, p...@laptop.org

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

On Wed, May 2, 2012 at 7:57 PM, Kevin Gordon kgordon...@gmail.com wrote:

On Wed, May 2, 2012 at 10:18 AM, Ajay Garg ajaygargn...@gmail.com wrote:

Good News.

I managed to get this working (albeit via changes in sugar).

The details are at ::

http://git.sugarlabs.org/dextrose/mainline/commit/4ac1a5300f4c43608b0f009a23d966d404a15632

I have a couple of minor observations from the great unwashed - yes me.
One is that this solution perhaps wont have any effect when one boots to
the Gnome side.

What could be the difference therein? (I could change to one, that could
work in both) :)

Regards,
Ajay

Two, this may be build version dependent, as there would appear from
some of the discussions in the group that there is an effort for the 12.1.0
builds to more closely link the NM functions on Sugar and Gnome so that
settings are identical when restarting the other environment. The echo
script in boot startup and the corresponding entry powerd resume , on the
other hand, might handle both. Not sure yet, as I'm still playing with WAP
variants, and also, I am the newbie :-)

Regards,
Ajay

On Wed, May 2, 2012 at 6:02 PM, Paul Fox p...@laptop.org wrote:

martin wrote:
On Wed, May 2, 2012 at 3:22 AM, Ajay Garg ajaygargn...@gmail.com
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.

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

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://
dev.laptop.org/projects/olpc-utils

=-
paul fox, p...@laptop.org

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

On Wed, May 2, 2012 at 10:18 AM, Ajay Garg ajaygargn...@gmail.com wrote:
 Good News.

 I managed to get this working (albeit via changes in sugar).

 The details are at ::
 http://git.sugarlabs.org/dextrose/mainline/commit/4ac1a5300f4c43608b0f009a23d966d404a15632

The patch seems fairly wrong to me. You are hiding the mesh icons in
sugar, but the mesh is active. Packet forwarding is still happening.

One of the top reasons we stopped using mesh is because it saturates
the RF spectrum, which is a bad thing to do when you have many users
in a small space (ie: in a school).

You had the mesh disable trick working on F11, and (I assume) happy
users of that feature. With this, the feature is broken, but you're
making the UI look right...

cheers,



m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- Software Architect - OLPC
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

2012-05-02 Thread Samuel Greenfeld

It's worth noting that half the battle can be won by overriding the
following XO-1 specific line in OLPC OS Builder's kspost.50.xo1-tweaks.inc:

gconftool-2 --direct --config-source
xml:readwrite:/etc/gconf/gconf.xml.defaults --type bool --set
/desktop/sugar/network/adhoc false

Setting this to true, or letting it default to such will show the Ad-hoc
networks by default on XO-1. It also will cause XO-1's to default to
Ad-hoc if no preferred network is found.

The mesh networks will still be there for manual use; but right now they
seem semi-broken anyway on 12.1.0 as we attempt to connect to Mesh Network
0 and don't set a channel on the Interface.

On Wed, May 2, 2012 at 10:29 AM, Martin Langhoff
martin.langh...@gmail.comwrote:

On Wed, May 2, 2012 at 10:18 AM, Ajay Garg ajaygargn...@gmail.com wrote:
Good News.

I managed to get this working (albeit via changes in sugar).

The details are at ::

http://git.sugarlabs.org/dextrose/mainline/commit/4ac1a5300f4c43608b0f009a23d966d404a15632

The patch seems fairly wrong to me. You are hiding the mesh icons in
sugar, but the mesh is active. Packet forwarding is still happening.

One of the top reasons we stopped using mesh is because it saturates
the RF spectrum, which is a bad thing to do when you have many users
in a small space (ie: in a school).

You had the mesh disable trick working on F11, and (I assume) happy
users of that feature. With this, the feature is broken, but you're
making the UI look right...

cheers,

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

On Wed, May 2, 2012 at 7:59 PM, Martin Langhoff
martin.langh...@gmail.comwrote:

 On Wed, May 2, 2012 at 10:18 AM, Ajay Garg ajaygargn...@gmail.com wrote:
  Good News.
 
  I managed to get this working (albeit via changes in sugar).
 
  The details are at ::
 
 http://git.sugarlabs.org/dextrose/mainline/commit/4ac1a5300f4c43608b0f009a23d966d404a15632

 The patch seems fairly wrong to me. You are hiding the mesh icons in
 sugar, but the mesh is active. Packet forwarding is still happening.



Hmm, ok (didn't know this).

I believe that the number of packets being forwarded in this, would be
(much) less than in the scenario when the users are actually connected to a
mesh-network-channel.
Kindly affirm/reject my above notion :)


Regards,
Ajay




 One of the top reasons we stopped using mesh is because it saturates
 the RF spectrum, which is a bad thing to do when you have many users
 in a small space (ie: in a school).

 You had the mesh disable trick working on F11, and (I assume) happy
 users of that feature. With this, the feature is broken, but you're
 making the UI look right...

 cheers,



 m
 --
  martin.langh...@gmail.com
  mar...@laptop.org -- Software Architect - OLPC
  - ask interesting questions
  - don't get distracted with shiny stuff  - working code first
  - http://wiki.laptop.org/go/User:Martinlanghoff

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

2012-05-02 Thread Anish Mangal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/02/2012 07:59 PM, Martin Langhoff wrote:
On Wed, May 2, 2012 at 10:18 AM, Ajay Garg ajaygargn...@gmail.com
wrote:
Good News.

I managed to get this working (albeit via changes in sugar).

The details are at ::
http://git.sugarlabs.org/dextrose/mainline/commit/4ac1a5300f4c43608b0f009a23d966d404a15632

The patch seems fairly wrong to me. You are hiding the mesh icons
in sugar, but the mesh is active. Packet forwarding is still
happening.

One of the top reasons we stopped using mesh is because it
saturates the RF spectrum, which is a bad thing to do when you have
many users in a small space (ie: in a school).

You had the mesh disable trick working on F11, and (I assume)
happy users of that feature. With this, the feature is broken, but
you're making the UI look right...

I agree.

The *problem* we are trying to solve is not to have a pretty
mesh-icon-free-UI (which is a side effect), but disable the mesh at a
hardware level.

This patch *won't* solve the problem, as it will still flood the air
with packet forwarding.

- From the discussion, it seems to me that the kernel level switch is
present in 12.x.x onwards, but not so for 11.3.x.

In 10.3.x(f11) we got lucky as we were able to avoid the race condition.

I suggest we keep looking for a proper solution:
* Can the kernel fix be backported (might require a lot of work)
* Can we tinker with the udev, postresume scripts to have it 'just'
working

I have reverted the commit:

http://git.sugarlabs.org/dextrose/mainline/commit/20ef9a14dd55908aec6c04cf3edddc51004aabb0

cheers,

- --
Anish
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPoU9PAAoJEBoxUdDHDZVp+DAH/j/RUl6AarwSlz0oUGIuPa5b
FxpFOwO6edA0Avd4Zv0/0x3FWlaAEHwkkyz6Vcsq3Px0lxecX0JgYrEgaXWJP4l0
YRBqROOBCzkVKxk7dEWZ003igZSGKbSmuRMlj4v4Qpv0yU9Tfi/GS3T1Q+r02B0o
igF9XjmLT5lFcZ4U1e7vE/foU4f7Y5ugg/TON6u/Oh0GNF8bDdOSkY/xKhGlAkIf
72d1pSt03ypcQgUHy7mRhORj1rc1d1YCWiyZLv2iUXdR2OyR8qjukw2HjQ2Gu5ts
DwTeumIy+QSF7fDIZkE83dErrmLJLUGvQ/4oqT50zhgI63o+/v8qBpa40XRo3bc=
=KMS0
-END PGP SIGNATURE-
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

Well, could someone point me to the kernel fix, which could solve the
problem by backporting.
That should be an interesting exercise.

Regards,
Ajay

On Wed, May 2, 2012 at 8:44 PM, Anish Mangal an...@activitycentral.comwrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/02/2012 07:59 PM, Martin Langhoff wrote:
On Wed, May 2, 2012 at 10:18 AM, Ajay Garg ajaygargn...@gmail.com
wrote:
Good News.

I managed to get this working (albeit via changes in sugar).

The details are at ::

http://git.sugarlabs.org/dextrose/mainline/commit/4ac1a5300f4c43608b0f009a23d966d404a15632

The patch seems fairly wrong to me. You are hiding the mesh icons
in sugar, but the mesh is active. Packet forwarding is still
happening.

One of the top reasons we stopped using mesh is because it
saturates the RF spectrum, which is a bad thing to do when you have
many users in a small space (ie: in a school).

You had the mesh disable trick working on F11, and (I assume)
happy users of that feature. With this, the feature is broken, but
you're making the UI look right...

I agree.

The *problem* we are trying to solve is not to have a pretty
mesh-icon-free-UI (which is a side effect), but disable the mesh at a
hardware level.

This patch *won't* solve the problem, as it will still flood the air
with packet forwarding.

- From the discussion, it seems to me that the kernel level switch is
present in 12.x.x onwards, but not so for 11.3.x.

In 10.3.x(f11) we got lucky as we were able to avoid the race condition.

I suggest we keep looking for a proper solution:
* Can the kernel fix be backported (might require a lot of work)
* Can we tinker with the udev, postresume scripts to have it 'just'
working

I have reverted the commit:

http://git.sugarlabs.org/dextrose/mainline/commit/20ef9a14dd55908aec6c04cf3edddc51004aabb0

cheers,

- --
Anish
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

On Wed, May 2, 2012 at 11:07 AM, Ajay Garg ajaygargn...@gmail.com wrote:
 I believe that the number of packets being forwarded in this, would be
 (much) less than in the scenario when the users are actually connected to a
 mesh-network-channel.
 Kindly affirm/reject my above notion :)

I am a very pragmatic man, I would not waste your time if it was a maybe.

There is no much less packet forwarding. You get 100% packet forwarding.

And as Sam points out, the UI part of it can be set already with a
gconf setting, via OOB. Unfortunatley, I have to agree with Anish's
revert :-(

Don't have the kernel patch info. Maybe look in git for changes in the
libertas driver. It's a pretty low traffic driver, so you'll find it
quick.

cheers,



m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- Software Architect - OLPC
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

2012-05-02 Thread Mikus Grinbergs


Another comment from the unwashed:

Years back, I used only ethernet to connect my XOs.  Nowadays, I'm using 
both wired and wireless to connect between XOs.  [By the way, I normally 
run my XOs with suspend disabled - so I have not paid much attention to 
problems associated with 'resume'.]


For about the last year, Network Manager has become super bossy:

It used to be that if I had an XO on ethernet, Network Manager might 
intervene after some 10+ hours - breaking that ethernet connection.  I 
did not mind occasionally having to reconnect the ethernet (I just 
invoke a script that re-issues the necessary commands).


But the current Network Manager intervenes in less than ten SECONDS - it 
breaks the connection on the ethernet (eth1) interface - presumably to 
set up the wireless (eth0) interface (to listen for radio signals).


Bottom line - these days, in order to use ethernet on an XO, I need to 
__disable__ Network Manager.


mikus

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

Martin,

just out of curiosity .. a logical query comes to my mind.


Why, and to whom, are packets forwarded, even though no user has joined any
channel?

Please do not take this as arrogance; I just wish to clear up some logical
mind-blocks :D
More importantly, this would clear up some of my networking concepts as
well :D


Thanks in advance for being my teacher :D


Thanks and Regards,
Ajay

On Wed, May 2, 2012 at 9:27 PM, Martin Langhoff
martin.langh...@gmail.comwrote:

 On Wed, May 2, 2012 at 11:07 AM, Ajay Garg ajaygargn...@gmail.com wrote:
  I believe that the number of packets being forwarded in this, would be
  (much) less than in the scenario when the users are actually connected
 to a
  mesh-network-channel.
  Kindly affirm/reject my above notion :)

 I am a very pragmatic man, I would not waste your time if it was a maybe.

 There is no much less packet forwarding. You get 100% packet forwarding.

 And as Sam points out, the UI part of it can be set already with a
 gconf setting, via OOB. Unfortunatley, I have to agree with Anish's
 revert :-(

 Don't have the kernel patch info. Maybe look in git for changes in the
 libertas driver. It's a pretty low traffic driver, so you'll find it
 quick.

 cheers,



 m
 --
  martin.langh...@gmail.com
  mar...@laptop.org -- Software Architect - OLPC
  - ask interesting questions
  - don't get distracted with shiny stuff  - working code first
  - http://wiki.laptop.org/go/User:Martinlanghoff

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

2012-05-02 Thread Paul Fox

martin wrote:
  On Wed, May 2, 2012 at 11:07 AM, Ajay Garg ajaygargn...@gmail.com wrote:
   I believe that the number of packets being forwarded in this, would be
   (much) less than in the scenario when the users are actually connected to a
   mesh-network-channel.
   Kindly affirm/reject my above notion :)
  
  I am a very pragmatic man, I would not waste your time if it was a maybe.
  
  There is no much less packet forwarding. You get 100% packet forwarding.
  
  And as Sam points out, the UI part of it can be set already with a
  gconf setting, via OOB. Unfortunatley, I have to agree with Anish's
  revert :-(
  
  Don't have the kernel patch info. Maybe look in git for changes in the
  libertas driver. It's a pretty low traffic driver, so you'll find it
  quick.

i've cherry-picked 65a5f2b3 onto olpc-2.6.35, and the autobuilder
did the rest.  this implements a new libertas_disablemesh module
parameter which should keep mesh from being enabled.  please test:


http://rpmdropbox.laptop.org/f14-xo1/kernel-2.6.35.13_xo1-20120502.1603.olpc.bde819f.i586.rpm

paul

  
  cheers,
  
  
  
  m
  -- 
   martin.langh...@gmail.com
   mar...@laptop.org -- Software Architect - OLPC
   - ask interesting questions
   - don't get distracted with shiny stuff  - working code first
   - http://wiki.laptop.org/go/User:Martinlanghoff

=-
 paul fox, p...@laptop.org
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

Thanks Paul.
I will test this, and get back to you once done.

Thanks a ton

Regards,
Ajay

On Thu, May 3, 2012 at 2:21 AM, Paul Fox p...@laptop.org wrote:
martin wrote:
On Wed, May 2, 2012 at 11:07 AM, Ajay Garg ajaygargn...@gmail.com wrote:
I believe that the number of packets being forwarded in this, would be
(much) less than in the scenario when the users are actually connected
to a
mesh-network-channel.
Kindly affirm/reject my above notion :)
I am a very pragmatic man, I would not waste your time if it was a maybe.
There is no much less packet forwarding. You get 100% packet forwarding.
And as Sam points out, the UI part of it can be set already with a
gconf setting, via OOB. Unfortunatley, I have to agree with Anish's
revert :-(
Don't have the kernel patch info. Maybe look in git for changes in the
libertas driver. It's a pretty low traffic driver, so you'll find it
quick.

i've cherry-picked 65a5f2b3 onto olpc-2.6.35, and the autobuilder
did the rest. this implements a new libertas_disablemesh module
parameter which should keep mesh from being enabled. please test:

http://rpmdropbox.laptop.org/f14-xo1/kernel-2.6.35.13_xo1-20120502.1603.olpc.bde819f.i586.rpm

paul

cheers,
m
--
martin.langh...@gmail.com
mar...@laptop.org -- Software Architect - OLPC
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff

=-
paul fox, p...@laptop.org
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

Hi all.

One generic query (not necessarily related to NM crash during
resume-upon-suspend) ::

I cannot seem to find any grub.conf on my XO-1, wherein I could add
the kernel boot parameter.
So, does XO-1 have any alternative to grub.conf ?

Regards,
Ajay

On Thu, May 3, 2012 at 2:24 AM, Ajay Garg ajaygargn...@gmail.com wrote:
Thanks Paul.
I will test this, and get back to you once done.

Thanks a ton

Regards,
Ajay

i've cherry-picked 65a5f2b3 onto olpc-2.6.35, and the autobuilder
did the rest. this implements a new libertas_disablemesh module
parameter which should keep mesh from being enabled. please test:

http://rpmdropbox.laptop.org/f14-xo1/kernel-2.6.35.13_xo1-20120502.1603.olpc.bde819f.i586.rpm

paul

=-
paul fox, p...@laptop.org
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

2012-05-02 Thread Paul Fox

ajay wrote:
  Hi all.
  
  One generic query (not necessarily related to NM crash during
  resume-upon-suspend) ::
  
  I cannot seem to find any grub.conf on my XO-1, wherein I could add
  the kernel boot parameter.
  So, does XO-1 have any alternative to grub.conf ?

look at olpc.fth.   in /bootpart/boot/olpc.fth.

if this is for libertas_disablemesh, i'd suggest adding that
in modprobe.conf (or whatever the right file is under modprobe*/*
these days).

paul

  
  
  Regards,
  Ajay
  
  On Thu, May 3, 2012 at 2:24 AM, Ajay Garg ajaygargn...@gmail.com wrote:
   Thanks Paul.
   I will test this, and get back to you once done.
  
   Thanks a ton 
  
  
   Regards,
   Ajay
  
   On Thu, May 3, 2012 at 2:21 AM, Paul Fox p...@laptop.org wrote:
   martin wrote:
 On Wed, May 2, 2012 at 11:07 AM, Ajay Garg ajaygargn...@gmail.com 
   wrote:
  I believe that the number of packets being forwarded in this, would 
   be
  (much) less than in the scenario when the users are actually 
   connected 
  to a
  mesh-network-channel.
  Kindly affirm/reject my above notion :)

 I am a very pragmatic man, I would not waste your time if it was a 
   maybe.

 There is no much less packet forwarding. You get 100% packet 
   forwarding.

 And as Sam points out, the UI part of it can be set already with a
 gconf setting, via OOB. Unfortunatley, I have to agree with Anish's
 revert :-(

 Don't have the kernel patch info. Maybe look in git for changes in the
 libertas driver. It's a pretty low traffic driver, so you'll find it
 quick.
  
   i've cherry-picked 65a5f2b3 onto olpc-2.6.35, and the autobuilder
   did the rest.  this implements a new libertas_disablemesh module
   parameter which should keep mesh from being enabled.  please test:
  
  
  http://rpmdropbox.laptop.org/f14-xo1/kernel-2.6.35.13_xo1-20120502.1603.olpc.bde
  819f.i586.rpm
  
   paul
  

 cheers,



 m
 --
  martin.langh...@gmail.com
  mar...@laptop.org -- Software Architect - OLPC
  - ask interesting questions
  - don't get distracted with shiny stuff  - working code first
  - http://wiki.laptop.org/go/User:Martinlanghoff
  
   =-
paul fox, p...@laptop.org

=-
 paul fox, p...@laptop.org
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

Paul, here are the test results ::


== USE-CASE 1 ==

a)
Created file '/etc/modprobe.d/libertas.conf'.


b)
Ensured that '/etc/modprobe.d/libertas.conf' contained only the
following line ::

  options libertas libertas_disablemesh=1


c)
Ensured that there is no echo 0  /sys/class/net/eth0/lbs_mesh
script, anywhere on the XO-1.
This also meant, that there was no '/etc/powerd/postresume.d/disable_mesh.sh'.


d)
Rebooted.


e)
Wifi icons were visible in Neighborhood-View, but no mesh-icons were visible.


f)
Upon resume-from-suspend, wifi icons were visible in
Neighborhood-View, but no mesh-icons were visible.


g)
Observations e) and f) were observed, _every single time_.



=



== USE-CASE 2 ==

a)
Created file '/etc/modprobe.d/libertas.conf'.


b)
Ensured that '/etc/modprobe.d/libertas.conf' contained only the
following line ::

  options libertas libertas_disablemesh=0


c)
Ensured that there is no echo 0  /sys/class/net/eth0/lbs_mesh
script, anywhere on the XO-1.
This also meant, that there was no '/etc/powerd/postresume.d/disable_mesh.sh'.


d)
Rebooted.


e)
Wifi icons, and mesh-icons were visible in Neighborhood-View.


f)
Upon resume-from-suspend, NO ICONS COULD BE SEEN IN NEIGHBORHOOD VIEW.


g)
Observations e) and f) were observed, _every single time_.




=



== USE-CASE 3 ==

a)
Ensured that there was no such file, that contained the following line ::

  options libertas libertas_disablemesh


b)
Ensured that there is no echo 0  /sys/class/net/eth0/lbs_mesh
script, anywhere on the XO-1.
This also meant, that there was no '/etc/powerd/postresume.d/disable_mesh.sh'.


c)
Rebooted.


d)
Wifi icons, and mesh-icons were visible in Neighborhood-View.


e)
Upon resume-from-suspend, wifi-icons and mesh-icons were visible in
Neighborhood-View.


f)
Observations d) and e) were observed, _every single time_.






== SUMMARY==

Barring use-case 2 (which looks a bit odd), use-cases 1 and 3 worked
perfectly as expected.
Thanks Paul for your prompt effort in generating the new kernel, with
the patch. Thanks again.





== JUST ONE LAST QUERY ==

Is the disable-mesh-patch the only difference between the following ::


  kernel-2.6.35.13_xo1-20120502.1603.olpc.bde819f.i586
(kernel generated by you)
  kernel-2.6.35.13_xo1-20111005.1403.olpc.c2bd7b9.i586
(original kernel present on XO-1)





Thanks again.
The issue stands resolved :)


The new kernel could be deployed, provided the answer to the (last,
only) query is a yes. :)


Regards,
Ajay





On Thu, May 3, 2012 at 2:21 AM, Paul Fox p...@laptop.org wrote:
 martin wrote:
   On Wed, May 2, 2012 at 11:07 AM, Ajay Garg ajaygargn...@gmail.com wrote:
    I believe that the number of packets being forwarded in this, would be
    (much) less than in the scenario when the users are actually connected 
 to a
    mesh-network-channel.
    Kindly affirm/reject my above notion :)
  
   I am a very pragmatic man, I would not waste your time if it was a maybe.
  
   There is no much less packet forwarding. You get 100% packet forwarding.
  
   And as Sam points out, the UI part of it can be set already with a
   gconf setting, via OOB. Unfortunatley, I have to agree with Anish's
   revert :-(
  
   Don't have the kernel patch info. Maybe look in git for changes in the
   libertas driver. It's a pretty low traffic driver, so you'll find it
   quick.

 i've cherry-picked 65a5f2b3 onto olpc-2.6.35, and the autobuilder
 did the rest.  this implements a new libertas_disablemesh module
 parameter which should keep mesh from being enabled.  please test:

    
 http://rpmdropbox.laptop.org/f14-xo1/kernel-2.6.35.13_xo1-20120502.1603.olpc.bde819f.i586.rpm

 paul

  
   cheers,
  
  
  
   m
   --
    martin.langh...@gmail.com
    mar...@laptop.org -- Software Architect - OLPC
    - ask interesting questions
    - don't get distracted with shiny stuff  - working code first
    - http://wiki.laptop.org/go/User:Martinlanghoff

 =-
  paul fox, p...@laptop.org
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

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

Any ideas please, regarding the two latest queries :) ?

Regards,
Ajay

On Mon, Apr 30, 2012 at 1:00 PM, Ajay Garg a...@activitycentral.com wrote:

Thanks Martin and Jon for the replies.

On Sun, Apr 29, 2012 at 3:04 PM, Jon Nettleton jon.nettle...@gmail.comwrote:

On Sun, Apr 29, 2012 at 10:04 AM, Martin Abente
martin.abente.lah...@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

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

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

2012-05-01 Thread Paul Fox

ajay wrote:
  Any ideas please, regarding the two latest queries :) ?
  
  Regards,
  Ajay
  
  On Mon, Apr 30, 2012 at 1:00 PM, Ajay Garg a...@activitycentral.com wrote:
  
   Thanks Martin and Jon for the replies.
  
   On Sun, Apr 29, 2012 at 3:04 PM, Jon Nettleton 
   jon.nettle...@gmail.comwrote:
  
   On Sun, Apr 29, 2012 at 10:04 AM, Martin Abente
   martin.abente.lah...@gmail.com wrote:
Are you guys still using this?
   
   
  http://git.sugarlabs.org/dextrose-platform/mainline/blobs/master/etc/powerd/post
  resume.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?

it's the same as that for eth0.

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

of course not.  how would they tell one another apart?

paul

  
  
   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
  
  
  
  part 2 text/plain 129
  ___
  Devel mailing list
  Devel@lists.laptop.org
  http://lists.laptop.org/listinfo/devel

=-
 paul fox, p...@laptop.org
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

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

Thanks Paul.

On Tue, May 1, 2012 at 8:03 PM, Paul Fox p...@laptop.org wrote:

 ajay wrote:
   Any ideas please, regarding the two latest queries :) ?
  
   Regards,
   Ajay
  
   On Mon, Apr 30, 2012 at 1:00 PM, Ajay Garg a...@activitycentral.com
 wrote:
  
Thanks Martin and Jon for the replies.
   
On Sun, Apr 29, 2012 at 3:04 PM, Jon Nettleton 
 jon.nettle...@gmail.comwrote:
   
On Sun, Apr 29, 2012 at 10:04 AM, Martin Abente
martin.abente.lah...@gmail.com wrote:
 Are you guys still using this?

   
  
 http://git.sugarlabs.org/dextrose-platform/mainline/blobs/master/etc/powerd/post
   resume.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?

 it's the same as that for eth0.


Does that mean, that banning eth0-mac-address prevent the loading of
wifi-hardware-device as well (in obvious addition to mesh) ?
This seems very pricky.






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

 of course not.  how would they tell one another apart?


Alright.
But my first doubt (same mac address for mesh-hardware and wifi-hardware)
has put me in topspin :~



Regards,
Ajay






 paul

   
   
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
   
   
   
   part 2 text/plain 129
   ___
   Devel mailing list
   Devel@lists.laptop.org
   http://lists.laptop.org/listinfo/devel

 =-
  paul fox, p...@laptop.org

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

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

which actually brings me back to my original question ::


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?



Regards,
Ajay

On Tue, May 1, 2012 at 8:07 PM, Ajay Garg a...@activitycentral.com wrote:

 Thanks Paul.

 On Tue, May 1, 2012 at 8:03 PM, Paul Fox p...@laptop.org wrote:

 ajay wrote:
   Any ideas please, regarding the two latest queries :) ?
  
   Regards,
   Ajay
  
   On Mon, Apr 30, 2012 at 1:00 PM, Ajay Garg a...@activitycentral.com
 wrote:
  
Thanks Martin and Jon for the replies.
   
On Sun, Apr 29, 2012 at 3:04 PM, Jon Nettleton 
 jon.nettle...@gmail.comwrote:
   
On Sun, Apr 29, 2012 at 10:04 AM, Martin Abente
martin.abente.lah...@gmail.com wrote:
 Are you guys still using this?

   
  
 http://git.sugarlabs.org/dextrose-platform/mainline/blobs/master/etc/powerd/post
   resume.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?

 it's the same as that for eth0.


 Does that mean, that banning eth0-mac-address prevent the loading of
 wifi-hardware-device as well (in obvious addition to mesh) ?
 This seems very pricky.






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

 of course not.  how would they tell one another apart?


 Alright.
 But my first doubt (same mac address for mesh-hardware and wifi-hardware)
 has put me in topspin :~



 Regards,
 Ajay






 paul

   
   
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
   
   
   
   part 2 text/plain 129
   ___
   Devel mailing list
   Devel@lists.laptop.org
   http://lists.laptop.org/listinfo/devel

 =-
  paul fox, p...@laptop.org



___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

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

2012-05-01 Thread Paul Fox

ajay wrote:
  Thanks Paul.
  
  On Tue, May 1, 2012 at 8:03 PM, Paul Fox p...@laptop.org wrote:
  
   ajay wrote:
 Any ideas please, regarding the two latest queries :) ?

 Regards,
 Ajay

 On Mon, Apr 30, 2012 at 1:00 PM, Ajay Garg a...@activitycentral.com
   wrote:

  Thanks Martin and Jon for the replies.
 
  On Sun, Apr 29, 2012 at 3:04 PM, Jon Nettleton 
   jon.nettle...@gmail.comwrote:
 
  On Sun, Apr 29, 2012 at 10:04 AM, Martin Abente
  martin.abente.lah...@gmail.com wrote:
   Are you guys still using this?
  
 

   
  http://git.sugarlabs.org/dextrose-platform/mainline/blobs/master/etc/powerd/post
 resume.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?
  
   it's the same as that for eth0.
  
  
  Does that mean, that banning eth0-mac-address prevent the loading of
  wifi-hardware-device as well (in obvious addition to mesh) ?
  This seems very pricky.

i don't know.  i'm unfamiliar with NM config.  it doesn't sound too
hard to try.

paul

  
  
  
  
  
  
  b)
  Are mac address for XO-1s, EXACTLY same, for every XO-1 on this
   planet?
  
   of course not.  how would they tell one another apart?
  
  
  Alright.
  But my first doubt (same mac address for mesh-hardware and wifi-hardware)
  has put me in topspin :~
  
  
  
  Regards,
  Ajay
  
  
  
  
  
  
   paul
  
 
 
  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
 
 
 
 part 2 text/plain 129
 ___
 Devel mailing list
 Devel@lists.laptop.org
 http://lists.laptop.org/listinfo/devel
  
   =-
paul fox, p...@laptop.org
  

=-
 paul fox, p...@laptop.org
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

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

Thanks Paul.

I will give it a try myself.

Just one last question ::
I suppose that 'echo 0  /sys/class/net/eth0/lbs_mesh' is a hack that is
olpc-customised. So, I will be really grateful if you could point me to
some docs (a wiki page may be), that provide information as to how this
hack affects, and is affected.


Thanks for your help.

Regards,
Ajay

On Tue, May 1, 2012 at 8:36 PM, Paul Fox p...@laptop.org wrote:

 ajay wrote:
   Thanks Paul.
  
   On Tue, May 1, 2012 at 8:03 PM, Paul Fox p...@laptop.org wrote:
  
ajay wrote:
  Any ideas please, regarding the two latest queries :) ?
 
  Regards,
  Ajay
 
  On Mon, Apr 30, 2012 at 1:00 PM, Ajay Garg 
 a...@activitycentral.com
wrote:
 
   Thanks Martin and Jon for the replies.
  
   On Sun, Apr 29, 2012 at 3:04 PM, Jon Nettleton 
jon.nettle...@gmail.comwrote:
  
   On Sun, Apr 29, 2012 at 10:04 AM, Martin Abente
   martin.abente.lah...@gmail.com wrote:
Are you guys still using this?
   
  
 
   
  
 http://git.sugarlabs.org/dextrose-platform/mainline/blobs/master/etc/powerd/post
  resume.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?
   
it's the same as that for eth0.
   
  
   Does that mean, that banning eth0-mac-address prevent the loading of
   wifi-hardware-device as well (in obvious addition to mesh) ?
   This seems very pricky.

 i don't know.  i'm unfamiliar with NM config.  it doesn't sound too
 hard to try.

 paul

  
  
  
  
  
   
   b)
   Are mac address for XO-1s, EXACTLY same, for every XO-1 on this
planet?
   
of course not.  how would they tell one another apart?
   
  
   Alright.
   But my first doubt (same mac address for mesh-hardware and
 wifi-hardware)
   has put me in topspin :~
  
  
  
   Regards,
   Ajay
  
  
  
  
  
   
paul
   
  
  
   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
  
  
  
  part 2 text/plain 129
  ___
  Devel mailing list
  Devel@lists.laptop.org
  http://lists.laptop.org/listinfo/devel
   
=-
 paul fox, p...@laptop.org
   

 =-
  paul fox, p...@laptop.org

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

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

2012-05-01 Thread Jerry Vonau

On Tue, 2012-05-01 at 20:50 +0530, Ajay Garg wrote:
Thanks Paul.

I will give it a try myself.

Just one last question ::
I suppose that 'echo 0 /sys/class/net/eth0/lbs_mesh' is a hack
that is olpc-customised. So, I will be really grateful if you could
point me to some docs (a wiki page may be), that provide information
as to how this hack affects, and is affected.

Ajay:

http://wiki.laptop.org/go/Mesh_Network_Details
http://wiki.laptop.org/go/Wireless_Driver_README

Are installing the dextrose-platform rpm?
http://download.sugarlabs.org/dextrose/testing/dx3/rpms/source/dextrose-platform-2-2.fc14.src.rpm

Jerry

Thanks for your help.

Regards,
Ajay

On Tue, May 1, 2012 at 8:36 PM, Paul Fox p...@laptop.org wrote:
ajay wrote:
Thanks Paul.

On Tue, May 1, 2012 at 8:03 PM, Paul Fox p...@laptop.org
wrote:

ajay wrote:
Any ideas please, regarding the two latest
queries :) ?

Regards,
Ajay

On Mon, Apr 30, 2012 at 1:00 PM, Ajay Garg
a...@activitycentral.com
wrote:

Thanks Martin and Jon for the replies.

On Sun, Apr 29, 2012 at 3:04 PM, Jon Nettleton
jon.nettle...@gmail.comwrote:

On Sun, Apr 29, 2012 at 10:04 AM, Martin Abente
martin.abente.lah...@gmail.com wrote:
Are you guys still using this?

http://git.sugarlabs.org/dextrose-platform/mainline/blobs/master/etc/powerd/post
resume.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?

it's the same as that for eth0.

Does that mean, that banning eth0-mac-address prevent the
loading of
wifi-hardware-device as well (in obvious addition to
mesh) ?
This seems very pricky.

i don't know. i'm unfamiliar with NM config. it doesn't
sound too
hard to try.

paul

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

of course not. how would they tell one another apart?

Alright.
But my first doubt (same mac address for mesh-hardware and
wifi-hardware)
has put me in topspin :~

Regards,
Ajay

paul

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)

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

2012-05-01 Thread Peter Robinson

On Tue, May 1, 2012 at 3:55 PM, Ajay Garg a...@activitycentral.com wrote:
 which actually brings me back to my original question ::

 
 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?
 

Because on suspend/resume the NetworkManager service isn't
started/restarted so the script in /etc/init.d isn't run where as on
reboot it is. There's means though to run specific scripts on
suspend/resume if that sort of thing is necessary.

Peter
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

Hi all.

I'll ask this straight ::


Is there an already tested-cum-recommended method, that could disable
mesh-network, both during reboots and resume-from-suspend?


Possible options (not tested by me) ::


a)
A driver,  encapsulating the patch at
http://lists.infradead.org/pipermail/libertas-dev/2007-June/000448.html
(as per http://dev.laptop.org/pub/firmware/libertas/RELEASE_NOTES)


Query : How can I ascertain if this patch is present on a particular XO-1?





b)
(For Reboot) ::
Add the bootstrap script 'echo 0  /sys/class/net/eth0/lbs_mesh' in
'/etc/init.d/NetworkMaanager'.

(For Resume-Upon-Suspend) ::
Add the disable_mesh.sh script (at
http://download.sugarlabs.org/dextrose/testing/dx3/rpms/source/dextrose-platform-2-2.fc14.src.rpm)
in /etc/powerd/postresume.d.


Query : While the (For Reboot) case is guaranteed to work stably every
single time, can the same be said about (For Resume-Upon-Suspend) ?




c) Any other unknown in-the-dark hack.



Regards,
Ajay



On Tue, May 1, 2012 at 9:36 PM, Peter Robinson pbrobin...@gmail.com wrote:

 On Tue, May 1, 2012 at 3:55 PM, Ajay Garg a...@activitycentral.com
 wrote:
  which actually brings me back to my original question ::
 
  
  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?
  

 Because on suspend/resume the NetworkManager service isn't
 started/restarted so the script in /etc/init.d isn't run where as on
 reboot it is. There's means though to run specific scripts on
 suspend/resume if that sort of thing is necessary.

 Peter

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

Just an updated version ::


Hi all.

I'll ask this straight ::


Is there an already tested-cum-recommended method, that could disable
mesh-network, both during reboots and resume-from-suspend?


Possible options (not tested by me) ::


a)
A driver,  encapsulating the patch at
http://lists.infradead.org/pipermail/libertas-dev/2007-June/000448.html
(as per http://dev.laptop.org/pub/firmware/libertas/RELEASE_NOTES)


Query : How can I ascertain if this patch is present on a particular XO-1?





b)
(For Reboot) ::
Add the bootstrap script 'echo 0  /sys/class/net/eth0/lbs_mesh' in
'/etc/init.d/NetworkMaanager'.

(For Resume-Upon-Suspend) ::
Add the disable_mesh.sh script (at
http://download.sugarlabs.org/dextrose/testing/dx3/rpms/source/dextrose-platform-2-2.fc14.src.rpm)
in /etc/powerd/postresume.d.


Query   : While the (For Reboot) case is guaranteed to work stably every
single time, can the same be said about (For Resume-Upon-Suspend) ?
Answer : No. The (Resume-Upon-Suspend) case does not work. So, this
solution is rejected.




c) Any other unknown in-the-dark hack.



Regards,
Ajay

On Wed, May 2, 2012 at 9:10 AM, Ajay Garg a...@activitycentral.com wrote:

 Hi all.

 I'll ask this straight ::

 
 Is there an already tested-cum-recommended method, that could disable
 mesh-network, both during reboots and resume-from-suspend?
 

 Possible options (not tested by me) ::


 a)
 A driver,  encapsulating the patch at
 http://lists.infradead.org/pipermail/libertas-dev/2007-June/000448.html
 (as per http://dev.laptop.org/pub/firmware/libertas/RELEASE_NOTES)


 Query : How can I ascertain if this patch is present on a particular XO-1?





 b)
 (For Reboot) ::
 Add the bootstrap script 'echo 0  /sys/class/net/eth0/lbs_mesh' in
 '/etc/init.d/NetworkMaanager'.

 (For Resume-Upon-Suspend) ::
 Add the disable_mesh.sh script (at
 http://download.sugarlabs.org/dextrose/testing/dx3/rpms/source/dextrose-platform-2-2.fc14.src.rpm)
 in /etc/powerd/postresume.d.


 Query : While the (For Reboot) case is guaranteed to work stably every
 single time, can the same be said about (For Resume-Upon-Suspend) ?




 c) Any other unknown in-the-dark hack.



 Regards,
 Ajay




 On Tue, May 1, 2012 at 9:36 PM, Peter Robinson pbrobin...@gmail.comwrote:

 On Tue, May 1, 2012 at 3:55 PM, Ajay Garg a...@activitycentral.com
 wrote:
  which actually brings me back to my original question ::
 
  
  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?
  

 Because on suspend/resume the NetworkManager service isn't
 started/restarted so the script in /etc/init.d isn't run where as on
 reboot it is. There's means though to run specific scripts on
 suspend/resume if that sort of thing is necessary.

 Peter



___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

On Wed, May 02, 2012 at 09:14:26AM +0530, Ajay Garg wrote:
 Is there an already tested-cum-recommended method, that could disable
 mesh-network, both during reboots and resume-from-suspend?

Not that I know of.

But I'm curious, why do you need to do this?  Is there some other
problem you think you will solve with this?  There might be an alternate
solution.

-- 
James Cameron
http://quozl.linux.org.au/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

Thanks James for the reply.

On Wed, May 2, 2012 at 9:21 AM, James Cameron qu...@laptop.org wrote:

 On Wed, May 02, 2012 at 09:14:26AM +0530, Ajay Garg wrote:
  Is there an already tested-cum-recommended method, that could disable
  mesh-network, both during reboots and resume-from-suspend?

 Not that I know of.

 But I'm curious, why do you need to do this?  Is there some other
 problem you think you will solve with this?  There might be an alternate
 solution.


No, nothing of that sort.
Just wish to remove the mesh-icons from Neighborhood-View.

Right now, we were trying the disable-mesh-script (''echo 0 
/sys/class/net/eth0/lbs_mesh) for our purpose.
Now, I am thinking of removing all references to devices of type
DEVICE_TYPE_802_11_OLPC_MESH from sugar-code. I think that should do it.

Thanks to all for your quick responses.

Thanks and Regards,
Ajay




 --
 James Cameron
 http://quozl.linux.org.au/
 ___
 Sugar-devel mailing list
 sugar-de...@lists.sugarlabs.org
 http://lists.sugarlabs.org/listinfo/sugar-devel

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

On Wed, May 02, 2012 at 09:33:36AM +0530, Ajay Garg wrote:
 Thanks James for the reply.
 
 On Wed, May 2, 2012 at 9:21 AM, James Cameron qu...@laptop.org wrote:
 
 On Wed, May 02, 2012 at 09:14:26AM +0530, Ajay Garg wrote:
  Is there an already tested-cum-recommended method, that could disable
  mesh-network, both during reboots and resume-from-suspend?
 
 Not that I know of.
 
 But I'm curious, why do you need to do this?  Is there some other
 problem you think you will solve with this?  There might be an alternate
 solution.
 
 
 No, nothing of that sort.
 Just wish to remove the mesh-icons from Neighborhood-View.

But why?

 Right now, we were trying the disable-mesh-script (''echo 0  /sys/class/net/
 eth0/lbs_mesh) for our purpose.
 Now, I am thinking of removing all references to devices of type
 DEVICE_TYPE_802_11_OLPC_MESH from sugar-code. I think that should do it.

Yes, that should do it.

-- 
James Cameron
http://quozl.linux.org.au/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

On Wed, May 2, 2012 at 9:39 AM, James Cameron qu...@laptop.org wrote:

 On Wed, May 02, 2012 at 09:33:36AM +0530, Ajay Garg wrote:
  Thanks James for the reply.
 
  On Wed, May 2, 2012 at 9:21 AM, James Cameron qu...@laptop.org wrote:
 
  On Wed, May 02, 2012 at 09:14:26AM +0530, Ajay Garg wrote:
   Is there an already tested-cum-recommended method, that could
 disable
   mesh-network, both during reboots and resume-from-suspend?
 
  Not that I know of.
 
  But I'm curious, why do you need to do this?  Is there some other
  problem you think you will solve with this?  There might be an
 alternate
  solution.
 
 
  No, nothing of that sort.
  Just wish to remove the mesh-icons from Neighborhood-View.

 But why?


Just that, we do not wish to set up a mesh-network, as per say.
By removing all references to the device, we could provide a soft
solution :)

Thanks again.

Regards,
Ajay



  Right now, we were trying the disable-mesh-script (''echo 0 
 /sys/class/net/
  eth0/lbs_mesh) for our purpose.
  Now, I am thinking of removing all references to devices of type
  DEVICE_TYPE_802_11_OLPC_MESH from sugar-code. I think that should do
 it.

 Yes, that should do it.

 --
 James Cameron
 http://quozl.linux.org.au/

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

2012-05-01 Thread Anish Mangal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed 02 May 2012 09:39:50 AM IST, James Cameron wrote:
 On Wed, May 02, 2012 at 09:33:36AM +0530, Ajay Garg wrote:
 Thanks James for the reply.

 On Wed, May 2, 2012 at 9:21 AM, James Cameron qu...@laptop.org wrote:

 On Wed, May 02, 2012 at 09:14:26AM +0530, Ajay Garg wrote:
  Is there an already tested-cum-recommended method, that could disable
  mesh-network, both during reboots and resume-from-suspend?

 Not that I know of.

 But I'm curious, why do you need to do this?  Is there some other
 problem you think you will solve with this?  There might be an alternate
 solution.


 No, nothing of that sort.
 Just wish to remove the mesh-icons from Neighborhood-View.

 But why?


Because it isn't really used much. Sugar supports adhoc networking
(since 0.88, IIRC) and that is used instead (atleast in dextrose
builds).

So, its better to make the mesh functionality disabled/invisible to the
user.

 Right now, we were trying the disable-mesh-script (''echo 0  
 /sys/class/net/
 eth0/lbs_mesh) for our purpose.
 Now, I am thinking of removing all references to devices of type
 DEVICE_TYPE_802_11_OLPC_MESH from sugar-code. I think that should do it.

 Yes, that should do it.




- --
Anish
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPoLT8AAoJEBoxUdDHDZVpC1QH/0ukS8tfT0IejDCczQkT7SCp
fiAuifIh8JCayK7j3CAY5BMUHoGlL8IRxw/xKqAxF+OZLKklb9GiFIok+5UJHC2o
S2HAHVe/MCHbmcL1npV2qvlSnzVpEIXFtbQvjasX0IGJx6rC5RBDO5cKOXbbKAII
QLwCwBgJmEbRLa5G+2ji++g21Y6OD6WL34ilSwLArcyEwgfozZlP1en0BAStCw1i
543yfN91f72KGNU4hNfa6LlR4GLhcjemLN2TLFB/rgliPF7VEFc77O25Y+YvKnZ8
7A8ZtBvbTt8F5eKGfbzJhfUVYCatTU9gD0H9w3DX/fdQ76+ySxGDrmBBnCsJwbY=
=GKXZ
-END PGP SIGNATURE-

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

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

2012-05-01 Thread Chris Ball

Hi,

On Wed, May 02 2012, Ajay Garg wrote:
 Just wish to remove the mesh-icons from Neighborhood-View.

Have you considered just removing the icons directly?

diff --git a/src/jarabe/desktop/meshbox.py b/src/jarabe/desktop/meshbox.py
index 20dc413..0aa8c7f 100644
--- a/src/jarabe/desktop/meshbox.py
+++ b/src/jarabe/desktop/meshbox.py
@@ -635,9 +635,9 @@ class MeshBox(gtk.VBox):
 
 def enable_olpc_mesh(self, mesh_device):
 mesh_mgr = OlpcMeshManager(mesh_device)
-self._add_olpc_mesh_icon(mesh_mgr, 1)
-self._add_olpc_mesh_icon(mesh_mgr, 6)
-self._add_olpc_mesh_icon(mesh_mgr, 11)
+#self._add_olpc_mesh_icon(mesh_mgr, 1)
+#self._add_olpc_mesh_icon(mesh_mgr, 6)
+#self._add_olpc_mesh_icon(mesh_mgr, 11)
 
 # the OLPC mesh can be recognised as a normal wifi network. remove
 # any such normal networks if they have been created

-- 
Chris Ball   c...@laptop.org   http://printf.net/
One Laptop Per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

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

Yes Chris, that certainly is an option.
But removing the references to the device itself, would clean up both the
model and the view; whereas this (as I think) only removes the view.

Regards,
Ajay

On Wed, May 2, 2012 at 10:18 AM, Chris Ball c...@laptop.org wrote:

 Hi,

 On Wed, May 02 2012, Ajay Garg wrote:
  Just wish to remove the mesh-icons from Neighborhood-View.

 Have you considered just removing the icons directly?

 diff --git a/src/jarabe/desktop/meshbox.py b/src/jarabe/desktop/meshbox.py
 index 20dc413..0aa8c7f 100644
 --- a/src/jarabe/desktop/meshbox.py
 +++ b/src/jarabe/desktop/meshbox.py
 @@ -635,9 +635,9 @@ class MeshBox(gtk.VBox):

 def enable_olpc_mesh(self, mesh_device):
 mesh_mgr = OlpcMeshManager(mesh_device)
 -self._add_olpc_mesh_icon(mesh_mgr, 1)
 -self._add_olpc_mesh_icon(mesh_mgr, 6)
 -self._add_olpc_mesh_icon(mesh_mgr, 11)
 +#self._add_olpc_mesh_icon(mesh_mgr, 1)
 +#self._add_olpc_mesh_icon(mesh_mgr, 6)
 +#self._add_olpc_mesh_icon(mesh_mgr, 11)

 # the OLPC mesh can be recognised as a normal wifi network.
 remove
 # any such normal networks if they have been created

 --
 Chris Ball   c...@laptop.org   http://printf.net/
 One Laptop Per Child

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

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

If all you wish to do is remove the mesh icons from the network
neighbourhood, why would you also want to clean up the model?

On Wed, May 02, 2012 at 10:29:45AM +0530, Ajay Garg wrote:
 Yes Chris, that certainly is an option.
 But removing the references to the device itself, would clean up both the 
 model
 and the view; whereas this (as I think) only removes the view.
 
 Regards,
 Ajay
 
 On Wed, May 2, 2012 at 10:18 AM, Chris Ball c...@laptop.org wrote:
 
 Hi,
 
 On Wed, May 02 2012, Ajay Garg wrote:
  Just wish to remove the mesh-icons from Neighborhood-View.
 
 Have you considered just removing the icons directly?
 
 diff --git a/src/jarabe/desktop/meshbox.py b/src/jarabe/desktop/meshbox.py
 index 20dc413..0aa8c7f 100644
 --- a/src/jarabe/desktop/meshbox.py
 +++ b/src/jarabe/desktop/meshbox.py
 @@ -635,9 +635,9 @@ class MeshBox(gtk.VBox):
 
 def enable_olpc_mesh(self, mesh_device):
 mesh_mgr = OlpcMeshManager(mesh_device)
 -self._add_olpc_mesh_icon(mesh_mgr, 1)
 -self._add_olpc_mesh_icon(mesh_mgr, 6)
 -self._add_olpc_mesh_icon(mesh_mgr, 11)
 +#self._add_olpc_mesh_icon(mesh_mgr, 1)
 +#self._add_olpc_mesh_icon(mesh_mgr, 6)
 +#self._add_olpc_mesh_icon(mesh_mgr, 11)
 
 # the OLPC mesh can be recognised as a normal wifi network.
 remove
 # any such normal networks if they have been created

 --
 Chris Ball   c...@laptop.org   http://printf.net/
 One Laptop Per Child
 
 

-- 
James Cameron
http://quozl.linux.org.au/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

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

Well.. Hmm.. So that it could mean less (leftover-half-bits) bugs to play
with :P

Regards,
Ajay

On Wed, May 2, 2012 at 10:42 AM, James Cameron qu...@laptop.org wrote:

 If all you wish to do is remove the mesh icons from the network
 neighbourhood, why would you also want to clean up the model?

 On Wed, May 02, 2012 at 10:29:45AM +0530, Ajay Garg wrote:
  Yes Chris, that certainly is an option.
  But removing the references to the device itself, would clean up both
 the model
  and the view; whereas this (as I think) only removes the view.
 
  Regards,
  Ajay
 
  On Wed, May 2, 2012 at 10:18 AM, Chris Ball c...@laptop.org wrote:
 
  Hi,
 
  On Wed, May 02 2012, Ajay Garg wrote:
   Just wish to remove the mesh-icons from Neighborhood-View.
 
  Have you considered just removing the icons directly?
 
  diff --git a/src/jarabe/desktop/meshbox.py
 b/src/jarabe/desktop/meshbox.py
  index 20dc413..0aa8c7f 100644
  --- a/src/jarabe/desktop/meshbox.py
  +++ b/src/jarabe/desktop/meshbox.py
  @@ -635,9 +635,9 @@ class MeshBox(gtk.VBox):
 
  def enable_olpc_mesh(self, mesh_device):
  mesh_mgr = OlpcMeshManager(mesh_device)
  -self._add_olpc_mesh_icon(mesh_mgr, 1)
  -self._add_olpc_mesh_icon(mesh_mgr, 6)
  -self._add_olpc_mesh_icon(mesh_mgr, 11)
  +#self._add_olpc_mesh_icon(mesh_mgr, 1)
  +#self._add_olpc_mesh_icon(mesh_mgr, 6)
  +#self._add_olpc_mesh_icon(mesh_mgr, 11)
 
  # the OLPC mesh can be recognised as a normal wifi network.
  remove
  # any such normal networks if they have been created
 
  --
  Chris Ball   c...@laptop.org   http://printf.net/
  One Laptop Per Child
 
 

 --
 James Cameron
 http://quozl.linux.org.au/

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

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

Okay.  Take care not to add any when you change all those lines of code.
;-)

On Wed, May 02, 2012 at 10:47:41AM +0530, Ajay Garg wrote:
 Well.. Hmm.. So that it could mean less (leftover-half-bits) bugs to play with
 :P
 
 Regards,
 Ajay
 
 On Wed, May 2, 2012 at 10:42 AM, James Cameron qu...@laptop.org wrote:
 
 If all you wish to do is remove the mesh icons from the network
 neighbourhood, why would you also want to clean up the model?
 
 On Wed, May 02, 2012 at 10:29:45AM +0530, Ajay Garg wrote:
  Yes Chris, that certainly is an option.
  But removing the references to the device itself, would clean up both 
 the
 model
  and the view; whereas this (as I think) only removes the view.
 
  Regards,
  Ajay
 
  On Wed, May 2, 2012 at 10:18 AM, Chris Ball c...@laptop.org wrote:
 
  Hi,
 
  On Wed, May 02 2012, Ajay Garg wrote:
   Just wish to remove the mesh-icons from Neighborhood-View.
 
  Have you considered just removing the icons directly?
 
  diff --git a/src/jarabe/desktop/meshbox.py b/src/jarabe/desktop/
 meshbox.py
  index 20dc413..0aa8c7f 100644
  --- a/src/jarabe/desktop/meshbox.py
  +++ b/src/jarabe/desktop/meshbox.py
  @@ -635,9 +635,9 @@ class MeshBox(gtk.VBox):
 
  def enable_olpc_mesh(self, mesh_device):
  mesh_mgr = OlpcMeshManager(mesh_device)
  -self._add_olpc_mesh_icon(mesh_mgr, 1)
  -self._add_olpc_mesh_icon(mesh_mgr, 6)
  -self._add_olpc_mesh_icon(mesh_mgr, 11)
  +#self._add_olpc_mesh_icon(mesh_mgr, 1)
  +#self._add_olpc_mesh_icon(mesh_mgr, 6)
  +#self._add_olpc_mesh_icon(mesh_mgr, 11)
 
  # the OLPC mesh can be recognised as a normal wifi 
 network.
  remove
  # any such normal networks if they have been created
 
  --
  Chris Ball   c...@laptop.org   http://printf.net/
  One Laptop Per Child
 
 
 
 --
 James Cameron
 http://quozl.linux.org.au/
 
 

-- 
James Cameron
http://quozl.linux.org.au/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

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