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
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
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
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?
On Tue, May 1, 2012 at 11:29 AM, Daniel Drake d...@laptop.org wrote:
In Nicaragua we are seeing cases where XOs have no hostname set, both
on XO-1 and XO-1.5. On XO-1 this is presumably because libertas
usb8388 init was never 100% reliable, and on XO-1.5 its presumably
because the wireless
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
On May 1, 2012, at 6:49 PM, John Gilmore wrote:
Currently, XO hostnames are set on first boot in the following format:
xo-A-B-C
Where A, B and C are the last 3 bytes of the MAC address expressed in hex.
In Nicaragua we are seeing cases where XOs have no hostname set, both
on XO-1 and
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
Using the wireless device MAC address as the basis of the hostname seems
wrong to me. It is an overload of meaning. It also has an impact if
the wireless device is changed.
I'm also amused that the hostname needs to be unique, but that is
probably a different issue.
If the need for it to be
On Wed, May 2, 2012 at 3:28 AM, John Watlington w...@laptop.org wrote:
I second this recommendation. While the MAC address in the manufacturing
data may not be correct (if the WLAN card has been changed), it is guaranteed
to be as unique as the laptop serial number.
Talking with Wad about
On Sun, Apr 29, 2012 at 8:18 PM, David Leeming
da...@leeming-consulting.com wrote:
I’ll do some work when I get a chance to replicate and isolate the issue and
get some data as you suggest.
Quick question, is it possible to transfer the database and Moodle history
(users, etc) from one XS
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,
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
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
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
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
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
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
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
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
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 ::
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
On Tue, May 1, 2012 at 4:49 PM, John Gilmore g...@toad.com wrote:
Currently, XO hostnames are set on first boot in the following format:
xo-A-B-C
Where A, B and C are the last 3 bytes of the MAC address expressed in hex.
In Nicaragua we are seeing cases where XOs have no hostname set, both
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
On Wed, May 2, 2012 at 10:52 AM, Daniel Drake d...@laptop.org wrote:
On Tue, May 1, 2012 at 4:49 PM, John Gilmore g...@toad.com wrote:
Currently, XO hostnames are set on first boot in the following format:
xo-A-B-C
Where A, B and C are the last 3 bytes of the MAC address expressed in
hex.
kevin wrote:
On Wed, May 2, 2012 at 10:52 AM, Daniel Drake d...@laptop.org wrote:
On Tue, May 1, 2012 at 4:49 PM, John Gilmore g...@toad.com wrote:
Currently, XO hostnames are set on first boot in the following format:
xo-A-B-C
Where A, B and C are the last 3 bytes of the MAC
On Wed, May 2, 2012 at 1:18 AM, Martin Langhoff
martin.langh...@gmail.com wrote:
On Tue, May 1, 2012 at 11:29 AM, Daniel Drake d...@laptop.org wrote:
In Nicaragua we are seeing cases where XOs have no hostname set, both
on XO-1 and XO-1.5. On XO-1 this is presumably because libertas
usb8388
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 ::
-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 ::
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
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
On Wed, May 2, 2012 at 11:05 AM, Daniel Drake d...@laptop.org wrote:
1 - the code to setup /etc/sysconfig/network is in the wrong place --
it should trigger boot that /etc/sysconfig/network is missing
Yes, we can improve the code that handles this case.
That'll be great :-)
2 - yes,
On Wed, May 2, 2012 at 10:05 AM, Martin Langhoff
martin.langh...@gmail.com wrote:
Yep. In genral, a modprobe/udevtrigger/waitforpath approach seems to work.
I am a bit annoyed that systemd/udev doesn't provide some useful
facilities for this. We are early users, and as such we hit all the
On Wed, May 2, 2012 at 12:14 PM, Daniel Drake d...@laptop.org wrote:
I think they would just point out that the solution we're working
towards is the wrong approach. That is, we're requiring the hardware
to be connected at boot for it to be used. If you connect it after
boot, nothing happens.
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'.]
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
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
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
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
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
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
ok dir u: says Can't open directory
In case it matters, this USB drive is old, old, old... 16 MB. :)
I took the discussion with James Cameron off-list to reduce clutter.
For the archives and/or in case anybody is curious.
The problem turned out to be that dir u: doesn't support USB 1.1
The concerns I was told about have nothing to do with anything technical.
They are more along the lines of supporting XS users. If someone wants to
install XS in a VM, there is often a presumption that we are experts in
their virtual server software and how it is setup, even if they want to
43 matches
Mail list logo
