Re: Testing the Wireless driver changes
David,
There are a couple of issues i would like to address, mostly related to the
new wireless driver.
First, the netstat command:
About 50% of the time it becomes very slow(practically freezes) and spews a
"getnameinfo error".
The result from strace is:
---
.
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("
172.18.0.1")}, 28) = 0
fcntl64(4, F_GETFL) = 0x2 (flags O_RDWR)
fcntl64(4, F_SETFL, O_RDWR|O_NONBLOCK) = 0
gettimeofday({1200442106, 340565}, NULL) = 0
poll([{fd=4, events=POLLOUT, revents=POLLOUT}], 1, 0) = 1
send(4, "\270\227\1\0\0\1\0\0\0\0\0\0\1e\0017\1c\1e\1c\0010\1e\1f\1f\1f"...,
90, MSG_NOSIGNAL) = 90
poll(
It seems(according to Bernie)..that netstat makes queries to the DNS server
but it is temporarily down. Still if you execute the command a couple of
time it works again, but is a very regular phenomenon. This should be a
network issue, and not a driver issue, but can you confirm that?
Also, the msh0 interface is named after msh0_rename. Is there a reason for
that? Will this change back to normal in the future? How will it be in
Update1?. This inconsistency causes some issues in the olpc-netstatus
command utility.
Can you also please describe the changes from the user's perspective that
are changed/improved in the new driver. So we know were to start testing
from.
For example,
what is the situation with mesh on or off
is the mesh-start file still in use
are improvements related to 4470
thanx,
yani
On Jan 15, 2008 6:40 PM, Kim Quirk <[EMAIL PROTECTED]> wrote:
> David,
> Yani is back from his time off and finished with his exams (at least for
> now). Before the new year break, he had been working on testing, documenting
> and debugging issues mostly associated with avahi and telepathy, but also
> with wireless. He and Ricardo have been our wireless test experts.
>
> Now that he is back, it would be great if you and Michail can provide some
> thoughts on the highest priority testing that we should do here or at
> Michail's house (for a little more controlled RF setting); so we can try to
> find bugs as quickly as possible.
>
> Also - Ricardo, you might be able to give us some indication of your
> availability for testing and how many laptops you have in Brazil, etc.
>
>
> Thanks,
> Kim
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
Yani,
On the msh0_rename interface:
http://dev.laptop.org/ticket/5746
-- RC
On Jan 15, 2008 10:29 PM, Giannis Galanis <[EMAIL PROTECTED]> wrote:
> David,
>
> There are a couple of issues i would like to address, mostly related to
> the new wireless driver.
>
> First, the netstat command:
> About 50% of the time it becomes very slow(practically freezes) and spews
> a "getnameinfo error".
> The result from strace is:
> ---
> .
> socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
> connect(4, {sa_family=AF_INET, sin_port=htons(53),
> sin_addr=inet_addr("172.18.0.1
> ")}, 28) = 0
> fcntl64(4, F_GETFL) = 0x2 (flags O_RDWR)
> fcntl64(4, F_SETFL, O_RDWR|O_NONBLOCK) = 0
> gettimeofday({1200442106, 340565}, NULL) = 0
> poll([{fd=4, events=POLLOUT, revents=POLLOUT}], 1, 0) = 1
> send(4,
> "\270\227\1\0\0\1\0\0\0\0\0\0\1e\0017\1c\1e\1c\0010\1e\1f\1f\1f"..., 90,
> MSG_NOSIGNAL) = 90
> poll(
>
> It seems(according to Bernie)..that netstat makes queries to the DNS
> server but it is temporarily down. Still if you execute the command a couple
> of time it works again, but is a very regular phenomenon. This should be a
> network issue, and not a driver issue, but can you confirm that?
>
> Also, the msh0 interface is named after msh0_rename. Is there a reason for
> that? Will this change back to normal in the future? How will it be in
> Update1?. This inconsistency causes some issues in the olpc-netstatus
> command utility.
>
> Can you also please describe the changes from the user's perspective that
> are changed/improved in the new driver. So we know were to start testing
> from.
> For example,
> what is the situation with mesh on or off
> is the mesh-start file still in use
> are improvements related to 4470
>
> thanx,
>
> yani
>
>
>
>
> On Jan 15, 2008 6:40 PM, Kim Quirk <[EMAIL PROTECTED] > wrote:
>
> > David,
> > Yani is back from his time off and finished with his exams (at least for
> > now). Before the new year break, he had been working on testing, documenting
> > and debugging issues mostly associated with avahi and telepathy, but also
> > with wireless. He and Ricardo have been our wireless test experts.
> >
> > Now that he is back, it would be great if you and Michail can provide
> > some thoughts on the highest priority testing that we should do here or at
> > Michail's house (for a little more controlled RF setting); so we can try to
> > find bugs as quickly as possible.
> >
> > Also - Ricardo, you might be able to give us some indication of your
> > availability for testing and how many laptops you have in Brazil, etc.
> >
> >
> > Thanks,
> > Kim
> >
>
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
On Tue, 2008-01-15 at 19:29 -0500, Giannis Galanis wrote:
> David,
>
> There are a couple of issues i would like to address, mostly related
> to the new wireless driver.
>
> First, the netstat command:
> About 50% of the time it becomes very slow(practically freezes) and
> spews a "getnameinfo error".
> The result from strace is:
> ---
> .
> socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
> connect(4, {sa_family=AF_INET, sin_port=htons(53),
> sin_addr=inet_addr("172.18.0.1")}, 28) = 0
> fcntl64(4, F_GETFL) = 0x2 (flags O_RDWR)
> fcntl64(4, F_SETFL, O_RDWR|O_NONBLOCK) = 0
> gettimeofday({1200442106, 340565}, NULL) = 0
> poll([{fd=4, events=POLLOUT, revents=POLLOUT}], 1, 0) = 1
> send(4, "\270\227\1\0\0\1\0\0\0\0\0\0\1e\0017\1c\1e\1c\0010\1e\1f\1f
> \1f"..., 90, MSG_NOSIGNAL) = 90
> poll(
>
> It seems(according to Bernie)..that netstat makes queries to the DNS
> server but it is temporarily down. Still if you execute the command a
> couple of time it works again, but is a very regular phenomenon. This
> should be a network issue, and not a driver issue, but can you confirm
> that?
>
> Also, the msh0 interface is named after msh0_rename. Is there a reason
> for that? Will this change back to normal in the future? How will it
> be in Update1?. This inconsistency causes some issues in the
> olpc-netstatus command utility.
>
> Can you also please describe the changes from the user's perspective
> that are changed/improved in the new driver. So we know were to start
> testing from.
The original problem the rewrite was fixing was hanging in the driver.
There's a long explanation for that, but the short one is that the
driver should no longer periodically run around in circles screaming,
then have an arterial hemorrhage, and collapse on the ground spurting
blood from it's ears. You may have noticed this when doing iwconfig
commands that just never completed, or took 2 or 3 minutes to complete,
during which time the driver was in the afore-mentioned state.
This state could manifest itself as weird NetworkManager errors, network
dropouts, and just plain unexplained network flakiness.
> For example,
> what is the situation with mesh on or off
There isn't any user-facing control for that at this time AFAIK.
mbletsas wanted some user knob for this. The situation I'd expect is
that the mesh device would go away (a device hotplug event) and
NetworkManager wouldn't expose the mesh device at all. When the mesh
was turned back on, the mesh device would be hotplugged back and NM
would magically notice it just like it does when you plug in some other
USB network device.
There's no way that NetworkManager is going to poll the mesh device with
iwpriv for whether it's on or off (that's just so wrong), so mbletsas
and woodhouse have to find a method they agree on that doesn't require
polling to figure out if mesh is on or off. That may mean having the
iwpriv mesh on/off knob also apply to the eth device, so that you can
turn mesh off by doing:
iwpriv eth0 mesh off
iwpriv msh0 mesh off
and you'll get the same behavior, and then you do
iwpriv eth0 mesh on
to turn it back on, and using the normal Linux device hotplug stuff. I
think mbletsas has historically disliked having to manipulate other
devices than the mesh device to actually affect changes on the mesh
device, but that's life.
> is the mesh-start file still in use
Yes, since the mesh-start file is something from NetworkManager and not
driver related.
Dan
> are improvements related to 4470
>
> thanx,
>
> yani
>
>
>
> On Jan 15, 2008 6:40 PM, Kim Quirk <[EMAIL PROTECTED]> wrote:
> David,
> Yani is back from his time off and finished with his exams (at
> least for now). Before the new year break, he had been working
> on testing, documenting and debugging issues mostly associated
> with avahi and telepathy, but also with wireless. He and
> Ricardo have been our wireless test experts.
>
> Now that he is back, it would be great if you and Michail can
> provide some thoughts on the highest priority testing that we
> should do here or at Michail's house (for a little more
> controlled RF setting); so we can try to find bugs as quickly
> as possible.
>
> Also - Ricardo, you might be able to give us some indication
> of your availability for testing and how many laptops you have
> in Brazil, etc.
>
>
> Thanks,
> Kim
>
> ___
> Devel mailing list
> Devel@lists.laptop.org
> http://lists.laptop.org/listinfo/devel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
IMHO, there is no point in investing time in mesh stop/start now (or any
time in the future unless there is a strong reason for that - which we lack
now).
On Jan 16, 2008 1:48 PM, Dan Williams <[EMAIL PROTECTED]> wrote:
> On Tue, 2008-01-15 at 19:29 -0500, Giannis Galanis wrote:
> > David,
> >
> > There are a couple of issues i would like to address, mostly related
> > to the new wireless driver.
> >
> > First, the netstat command:
> > About 50% of the time it becomes very slow(practically freezes) and
> > spews a "getnameinfo error".
> > The result from strace is:
> > ---
> > .
> > socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
> > connect(4, {sa_family=AF_INET, sin_port=htons(53),
> > sin_addr=inet_addr("172.18.0.1")}, 28) = 0
> > fcntl64(4, F_GETFL) = 0x2 (flags O_RDWR)
> > fcntl64(4, F_SETFL, O_RDWR|O_NONBLOCK) = 0
> > gettimeofday({1200442106, 340565}, NULL) = 0
> > poll([{fd=4, events=POLLOUT, revents=POLLOUT}], 1, 0) = 1
> > send(4, "\270\227\1\0\0\1\0\0\0\0\0\0\1e\0017\1c\1e\1c\0010\1e\1f\1f
> > \1f"..., 90, MSG_NOSIGNAL) = 90
> > poll(
> >
> > It seems(according to Bernie)..that netstat makes queries to the DNS
> > server but it is temporarily down. Still if you execute the command a
> > couple of time it works again, but is a very regular phenomenon. This
> > should be a network issue, and not a driver issue, but can you confirm
> > that?
> >
> > Also, the msh0 interface is named after msh0_rename. Is there a reason
> > for that? Will this change back to normal in the future? How will it
> > be in Update1?. This inconsistency causes some issues in the
> > olpc-netstatus command utility.
> >
> > Can you also please describe the changes from the user's perspective
> > that are changed/improved in the new driver. So we know were to start
> > testing from.
>
> The original problem the rewrite was fixing was hanging in the driver.
> There's a long explanation for that, but the short one is that the
> driver should no longer periodically run around in circles screaming,
> then have an arterial hemorrhage, and collapse on the ground spurting
> blood from it's ears. You may have noticed this when doing iwconfig
> commands that just never completed, or took 2 or 3 minutes to complete,
> during which time the driver was in the afore-mentioned state.
>
> This state could manifest itself as weird NetworkManager errors, network
> dropouts, and just plain unexplained network flakiness.
>
> > For example,
> > what is the situation with mesh on or off
>
> There isn't any user-facing control for that at this time AFAIK.
> mbletsas wanted some user knob for this. The situation I'd expect is
> that the mesh device would go away (a device hotplug event) and
> NetworkManager wouldn't expose the mesh device at all. When the mesh
> was turned back on, the mesh device would be hotplugged back and NM
> would magically notice it just like it does when you plug in some other
> USB network device.
>
> There's no way that NetworkManager is going to poll the mesh device with
> iwpriv for whether it's on or off (that's just so wrong), so mbletsas
> and woodhouse have to find a method they agree on that doesn't require
> polling to figure out if mesh is on or off. That may mean having the
> iwpriv mesh on/off knob also apply to the eth device, so that you can
> turn mesh off by doing:
>
> iwpriv eth0 mesh off
> iwpriv msh0 mesh off
>
> and you'll get the same behavior, and then you do
>
> iwpriv eth0 mesh on
>
> to turn it back on, and using the normal Linux device hotplug stuff. I
> think mbletsas has historically disliked having to manipulate other
> devices than the mesh device to actually affect changes on the mesh
> device, but that's life.
>
> > is the mesh-start file still in use
>
> Yes, since the mesh-start file is something from NetworkManager and not
> driver related.
>
> Dan
>
> > are improvements related to 4470
> >
> > thanx,
> >
> > yani
> >
> >
> >
> > On Jan 15, 2008 6:40 PM, Kim Quirk <[EMAIL PROTECTED]> wrote:
> > David,
> > Yani is back from his time off and finished with his exams (at
> > least for now). Before the new year break, he had been working
> > on testing, documenting and debugging issues mostly associated
> > with avahi and telepathy, but also with wireless. He and
> > Ricardo have been our wireless test experts.
> >
> > Now that he is back, it would be great if you and Michail can
> > provide some thoughts on the highest priority testing that we
> > should do here or at Michail's house (for a little more
> > controlled RF setting); so we can try to find bugs as quickly
> > as possible.
> >
> > Also - Ricardo, you might be able to give us some indication
> > of your availability for testing and how many laptops you have
> > in Brazil, etc.
> >
> >
> > Thanks,
> > Kim
> >
> > __
Re: Testing the Wireless driver changes
Dan Williams <[EMAIL PROTECTED]> wrote on 01/16/2008 10:48:13 AM: > There's a long explanation for that, but the short one is that the > driver should no longer periodically run around in circles screaming, > then have an arterial hemorrhage, and collapse on the ground spurting > blood from it's ears. Dude! I sense some Woodhousian-Shakespearian inspiration in you today...;-) M. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
On Wed, 2008-01-16 at 15:11 -0500, Michail Bletsas wrote: > Dan Williams <[EMAIL PROTECTED]> wrote on 01/16/2008 10:48:13 AM: > > > > There's a long explanation for that, but the short one is that the > > driver should no longer periodically run around in circles screaming, > > then have an arterial hemorrhage, and collapse on the ground spurting > > blood from it's ears. > > Dude! > > I sense some Woodhousian-Shakespearian inspiration in you today...;-) Woodhousian is a good way to put it, certainly. That adjective should be added to the OED :) Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
2008/1/16 Ricardo Carrano <[EMAIL PROTECTED]>: > IMHO, there is no point in investing time in mesh stop/start now (or any > time in the future unless there is a strong reason for that - which we lack > now). The stated reason for wanting this feature is to easily disable wireless before getting on an airplane. There is a way to do it at the command line, but I don't see government ministers and education officials doing that with any reliability. If all you want is transport, you can take out the battery pack, but if the mesh is not disabled, it will come alive when the battery pack is inserted, long before you can boot and get to a command line to turn it off. I am quite certain that some of the aforementioned ministers and officials will want to show off their new toyz on planes just like the rest of us. Or we could just wait until there is sufficient public pressure to allow XOs to mesh on airplanes so that the rules are changed. Hey, who wants to make the movie Toyz on a Plane? %-] -- Edward Cherlin End Poverty at a Profit by teaching children business http://www.EarthTreasury.org/ "The best way to predict the future is to invent it."--Alan Kay ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
I believe what you want is "radio off", not "mesh stop". On Jan 16, 2008 8:01 PM, Edward Cherlin <[EMAIL PROTECTED]> wrote: > 2008/1/16 Ricardo Carrano <[EMAIL PROTECTED]>: > > IMHO, there is no point in investing time in mesh stop/start now (or any > > time in the future unless there is a strong reason for that - which we > lack > > now). > > The stated reason for wanting this feature is to easily disable > wireless before getting on an airplane. There is a way to do it at the > command line, but I don't see government ministers and education > officials doing that with any reliability. > > If all you want is transport, you can take out the battery pack, but > if the mesh is not disabled, it will come alive when the battery pack > is inserted, long before you can boot and get to a command line to > turn it off. I am quite certain that some of the aforementioned > ministers and officials will want to show off their new toyz on planes > just like the rest of us. > > Or we could just wait until there is sufficient public pressure to > allow XOs to mesh on airplanes so that the rules are changed. Hey, who > wants to make the movie Toyz on a Plane? %-] > > -- > Edward Cherlin > End Poverty at a Profit by teaching children business > http://www.EarthTreasury.org/ > "The best way to predict the future is to invent it."--Alan Kay > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
On Wed, 2008-01-16 at 20:22 -0200, Ricardo Carrano wrote: > I believe what you want is "radio off", not "mesh stop". "radio off" == iwconfig eth0 txpower off that's always been around from day #1. > On Jan 16, 2008 8:01 PM, Edward Cherlin <[EMAIL PROTECTED]> wrote: > 2008/1/16 Ricardo Carrano <[EMAIL PROTECTED]>: > > IMHO, there is no point in investing time in mesh stop/start > now (or any > > time in the future unless there is a strong reason for that > - which we lack > > now). > > > The stated reason for wanting this feature is to easily > disable > wireless before getting on an airplane. There is a way to do > it at the > command line, but I don't see government ministers and > education > officials doing that with any reliability. > > If all you want is transport, you can take out the battery > pack, but > if the mesh is not disabled, it will come alive when the > battery pack > is inserted, long before you can boot and get to a command > line to > turn it off. I am quite certain that some of the > aforementioned > ministers and officials will want to show off their new toyz > on planes > just like the rest of us. > > Or we could just wait until there is sufficient public > pressure to > allow XOs to mesh on airplanes so that the rules are changed. > Hey, who > wants to make the movie Toyz on a Plane? %-] > > -- > Edward Cherlin > End Poverty at a Profit by teaching children business > http://www.EarthTreasury.org/ > "The best way to predict the future is to invent it."--Alan > Kay > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
On Wed, 2008-01-16 at 14:01 -0800, Edward Cherlin wrote: > 2008/1/16 Ricardo Carrano <[EMAIL PROTECTED]>: > > IMHO, there is no point in investing time in mesh stop/start now (or any > > time in the future unless there is a strong reason for that - which we lack > > now). > > The stated reason for wanting this feature is to easily disable > wireless before getting on an airplane. There is a way to do it at the > command line, but I don't see government ministers and education > officials doing that with any reliability. I've been working with Simon on this for the past week or so. It's almost there on the backend, just needs testing and GUI bits from Simon before it gets pushed to joyride builds. Dan > If all you want is transport, you can take out the battery pack, but > if the mesh is not disabled, it will come alive when the battery pack > is inserted, long before you can boot and get to a command line to > turn it off. I am quite certain that some of the aforementioned > ministers and officials will want to show off their new toyz on planes > just like the rest of us. > > Or we could just wait until there is sufficient public pressure to > allow XOs to mesh on airplanes so that the rules are changed. Hey, who > wants to make the movie Toyz on a Plane? %-] > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
On Jan 16, 2008 2:46 PM, Dan Williams <[EMAIL PROTECTED]> wrote: > On Wed, 2008-01-16 at 20:22 -0200, Ricardo Carrano wrote: > > I believe what you want is "radio off", not "mesh stop". > > "radio off" == iwconfig eth0 txpower off > > that's always been around from day #1. That turns off the radio for this session. How do you disable it so it doesn't come on at the next boot? -- Edward Cherlin End Poverty at a Profit by teaching children business http://www.EarthTreasury.org/ "The best way to predict the future is to invent it."--Alan Kay ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
Is this related to Wodehousian? :) - Jim On Wed, 2008-01-16 at 15:15 -0500, Dan Williams wrote: > On Wed, 2008-01-16 at 15:11 -0500, Michail Bletsas wrote: > > Dan Williams <[EMAIL PROTECTED]> wrote on 01/16/2008 10:48:13 AM: > > > > > > > There's a long explanation for that, but the short one is that the > > > driver should no longer periodically run around in circles screaming, > > > then have an arterial hemorrhage, and collapse on the ground spurting > > > blood from it's ears. > > > > Dude! > > > > I sense some Woodhousian-Shakespearian inspiration in you today...;-) > > Woodhousian is a good way to put it, certainly. That adjective should > be added to the OED :) > > Dan > > > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel -- Jim Gettys One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
> When it comes to our radio - we *designed it* to start forward frames > soon after you initialize it and keep doing it regardless of what the > host interface does. In the context of making the radio safe to use on airplanes... Does the firmware turn the radio on at boot time? Does your "initialize" above mean firmware level or OS level? -- These are my opinions, not necessarily my employer's. I hate spam. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
Hal Murray <[EMAIL PROTECTED]> wrote on 01/17/2008 12:55:47 PM: > > > When it comes to our radio - we *designed it* to start forward frames > > soon after you initialize it and keep doing it regardless of what the > > host interface does. > > In the context of making the radio safe to use on airplanes... > > Does the firmware turn the radio on at boot time? > > Does your "initialize" above mean firmware level or OS level? > > > Initialize means loading the wireless firmware on the radio's ARM core and start running it. If you want to make sure that the radio never transmits a single bit, then preventing that (loading the wireless firmware) is what you need right now. There is explicit mesh start/stop in the plans (already implemented in the firmware but not in place yet since the driver people didn't like it). M. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
Hal Murray wrote: >> When it comes to our radio - we *designed it* to start forward frames >> soon after you initialize it and keep doing it regardless of what the >> host interface does. >> > > In the context of making the radio safe to use on airplanes... > > Does the firmware turn the radio on at boot time? > OFW turns on the radio only if the need arises, i.e. if you are trying to boot from the wireless network. > Does your "initialize" above mean firmware level or OS level? > > > > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
On Thu, 2008-01-17 at 17:06 -0200, Ricardo Carrano wrote: > Indeed we had this airplane mode discussion two weeks ago: > Why don't we? > --- This is the correct sledgehammer approach as mbletsas has consistently pointed out. For a more user-friendly solution, (short of a hardware rfkill switch) put a toggle somewhere in the control panel for "Don't turn the radio on automatically" that is _UN_checked by default, and a wireless enabled/disabled button there too. Then (see my other mail in this thread) ensure that the driver starts with the radio off, and that the first time the mesh or eth device is brought up that it turns the radio on. Then ensure that NetworkManager is clued into the preference value above, and that NM sets it's initial wireless-enabled state coherently with the preference value above as well. Were these things done, by default the behavior would be the same as it is now, but those people who wish insane amounts of control over the TX power state can have their fluffy white cake and eat it too. The trick is to prioritize this feature request relative to the other important bugs that must be fixed, since it affects multiple items from the bottom to the top of the stack. Dan > To completely silence the radio: > > #!/bin/bash > rmmod usb8xxx > mv /lib/firmaware/usb8883.bin /lib/firmaware/usb8883.bin.quiet > > It will survive reboots. > > --- > > To bring it back: > > #!/bin/bash > mv /lib/firmaware/usb8883.bin.quiet /lib/firmaware/usb8883.bin > rmmod usb8xxx; sleep1; modprobe usb8xxx > > No reboot necessary. > > --- > Tested in build 684, > Do I miss something? > > On Jan 17, 2008 4:30 PM, Michail Bletsas <[EMAIL PROTECTED]> wrote: > Hal Murray <[EMAIL PROTECTED]> wrote on 01/17/2008 > 12:55:47 PM: > > > > > > When it comes to our radio - we *designed it* to start > forward frames > > > soon after you initialize it and keep doing it regardless > of what the > > > host interface does. > > > > In the context of making the radio safe to use on > airplanes... > > > > Does the firmware turn the radio on at boot time? > > > > Does your "initialize" above mean firmware level or OS > level? > > > > > > > > Initialize means loading the wireless firmware on the radio's > ARM core and > start running it. > > If you want to make sure that the radio never transmits a > single bit, then > preventing that (loading the wireless firmware) is what you > need right > now. There is explicit mesh start/stop in the plans (already > implemented > in the firmware but not in place yet since the driver people > didn't like > it). > > > M. > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > > > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
I apologize if I am over simplifying: - mesh stop was considered when we had compatibility issues with lazy-wds routers. We addressed this, right? Do we still need this feature? Michail? - For airplane mode or relatives, we need to shut up radio (any traffic). On Jan 17, 2008 5:05 PM, Dan Williams <[EMAIL PROTECTED]> wrote: > On Thu, 2008-01-17 at 13:30 -0500, Michail Bletsas wrote: > > Hal Murray <[EMAIL PROTECTED]> wrote on 01/17/2008 12:55:47 PM: > > > > > > > > > When it comes to our radio - we *designed it* to start forward > frames > > > > soon after you initialize it and keep doing it regardless of what > the > > > > host interface does. > > > > > > In the context of making the radio safe to use on airplanes... > > > > > > Does the firmware turn the radio on at boot time? > > > > > > Does your "initialize" above mean firmware level or OS level? > > > > > > > > > > > Initialize means loading the wireless firmware on the radio's ARM core > and > > start running it. > > > > If you want to make sure that the radio never transmits a single bit, > then > > preventing that (loading the wireless firmware) is what you need right > > now. There is explicit mesh start/stop in the plans (already > implemented > > in the firmware but not in place yet since the driver people didn't like > > it). > > Sigh. There are two issues that you're not sufficiently separating: > > 1) Whether the mesh is enabled/disabled at Layer 2. This has nothing to > do with the ethX device and is a completely orthogonal problem. (or if > it _does_ have any user-visible interaction with the ethX device that's > a total layering violation, and somebody needs to be taken behind the > woodshed and shot) > > 2) Whether the radio is on/off at Layer 1. This affects _both_ the ethX > device and the mshX device. > > There are acceptable, upstreamable solutions for both of these problems. > > Solution for #1: up/down on the mshX device; if the mshX device is > marked !IFF_UP, the mesh functionality should probably be disabled. The > 8388 can keep the state and forwarding/blinding tables around until > poweroff/reset, but it should simply stop handling any mesh frames at > this point. This can certainly be implemented with a > CMD_802_11_MESH_CONTROL firmware command _in_the_driver_, but there's no > need for another iwpriv just to achieve the same thing that up/down > already can do. Then modify NM and system scripts to never down the > mesh device except in correct circumstances. > > Solution for #2: already exists with 'iwconfig txpower off' and > 'iwconfig txpower auto'. > > -- > > The other discussion to have is what should the default radio state be > in. If the default state is OFF until it's explicitly turned on by > NetworkManager or the user, then: > > a) it should be verified that the firmware doesn't turn the radio on > until told to do so > b) it should be verified that the driver doesn't turn the radio on until > the device is brought up (ifconfig eth0 up) > c) it should be verified that nothing in the host OS (startup scripts > like the 'network' service calling ifup or NetworkManager bring the > device up) until the point at which the user has explicit control > > Note that this approach would not be conducive to a nice exploratory > out-of-box experience (hence I don't really condone this approach > wholeheartedly) where access points and friends are immediately visible > from the Mesh view, until you explain to 5 year olds what the heck > wireless is and why it's off-by-default in the first place. > > People traveling in RF-prohibited environments should be the ones who > bear the burden of turning off the RF, since not too many of the target > audience is going to ever be flying on a plane or driving by a blasting > site. Plus those people who are flying on planes likely already know > that they _need_ to turn off the wireless component, which isn't likely > to be known by the 5 - 10 year old children in Peru who may never been > near an airplane anyway. > > Dan > > > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
There is quite a bit of important history removed from this discussion. We designed the laptop to be able to do mesh forwarding *all the time*. This was a fundamental decision because it affected every other choice that we made in the wireless subsystem. One of the issues that it introduced is that it makes the radio deviate from what "proper" radio behavior is supposed to be under Linux these days: when you bring an interface down (ifconfig eth0 down), its radio should be disabled. If you don't bring the interface up on boot, the radio should stay off. Pretty clean and simple. When it comes to our radio - we *designed it* to start forward frames soon after you initialize it and keep doing it regardless of what the host interface does. That's why we used a radio with its own CPU and memory. So things like "iwconfig eth0 txpower off" might be doing the right thing, however they do so (if they do**) indirectly, by controlling the host interface. There is an "iwpriv eth0 radiooff/radioon" IOCTL hook in the firmware which was meant to control the radio power directly - it was removed a few months ago since it wasn't considered to its thing in the "proper" linux manner. And ever since we keep having this "airplane mode" discussion. M. ** I don't know how "iwconfig eth0 txpower off" is implemented, if it uses the same IOCTL with "iwpriv eth0 radiooff", then it is doing the right thing. "Edward Cherlin" <[EMAIL PROTECTED]> wrote on 01/16/2008 06:56:17 PM: > On Jan 16, 2008 2:46 PM, Dan Williams <[EMAIL PROTECTED]> wrote: > On Wed, 2008-01-16 at 20:22 -0200, Ricardo Carrano wrote: > > I believe what you want is "radio off", not "mesh stop". > "radio off" == iwconfig eth0 txpower off > > that's always been around from day #1. > > That turns off the radio for this session. How do you disable it so > it doesn't come on at the next boot? > > -- > Edward Cherlin > End Poverty at a Profit by teaching children business > http://www.EarthTreasury.org/ > "The best way to predict the future is to invent it."--Alan Kay ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
Indeed we had this airplane mode discussion two weeks ago: Why don't we? --- To completely silence the radio: #!/bin/bash rmmod usb8xxx mv /lib/firmaware/usb8883.bin /lib/firmaware/usb8883.bin.quiet It will survive reboots. --- To bring it back: #!/bin/bash mv /lib/firmaware/usb8883.bin.quiet /lib/firmaware/usb8883.bin rmmod usb8xxx; sleep1; modprobe usb8xxx No reboot necessary. --- Tested in build 684, Do I miss something? On Jan 17, 2008 4:30 PM, Michail Bletsas <[EMAIL PROTECTED]> wrote: > Hal Murray <[EMAIL PROTECTED]> wrote on 01/17/2008 12:55:47 PM: > > > > > > When it comes to our radio - we *designed it* to start forward frames > > > soon after you initialize it and keep doing it regardless of what the > > > host interface does. > > > > In the context of making the radio safe to use on airplanes... > > > > Does the firmware turn the radio on at boot time? > > > > Does your "initialize" above mean firmware level or OS level? > > > > > > > Initialize means loading the wireless firmware on the radio's ARM core and > start running it. > > If you want to make sure that the radio never transmits a single bit, then > preventing that (loading the wireless firmware) is what you need right > now. There is explicit mesh start/stop in the plans (already implemented > in the firmware but not in place yet since the driver people didn't like > it). > > M. > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
On Thu, 2008-01-17 at 13:30 -0500, Michail Bletsas wrote: > Hal Murray <[EMAIL PROTECTED]> wrote on 01/17/2008 12:55:47 PM: > > > > > > When it comes to our radio - we *designed it* to start forward frames > > > soon after you initialize it and keep doing it regardless of what the > > > host interface does. > > > > In the context of making the radio safe to use on airplanes... > > > > Does the firmware turn the radio on at boot time? > > > > Does your "initialize" above mean firmware level or OS level? > > > > > > > Initialize means loading the wireless firmware on the radio's ARM core and > start running it. > > If you want to make sure that the radio never transmits a single bit, then > preventing that (loading the wireless firmware) is what you need right > now. There is explicit mesh start/stop in the plans (already implemented > in the firmware but not in place yet since the driver people didn't like > it). Sigh. There are two issues that you're not sufficiently separating: 1) Whether the mesh is enabled/disabled at Layer 2. This has nothing to do with the ethX device and is a completely orthogonal problem. (or if it _does_ have any user-visible interaction with the ethX device that's a total layering violation, and somebody needs to be taken behind the woodshed and shot) 2) Whether the radio is on/off at Layer 1. This affects _both_ the ethX device and the mshX device. There are acceptable, upstreamable solutions for both of these problems. Solution for #1: up/down on the mshX device; if the mshX device is marked !IFF_UP, the mesh functionality should probably be disabled. The 8388 can keep the state and forwarding/blinding tables around until poweroff/reset, but it should simply stop handling any mesh frames at this point. This can certainly be implemented with a CMD_802_11_MESH_CONTROL firmware command _in_the_driver_, but there's no need for another iwpriv just to achieve the same thing that up/down already can do. Then modify NM and system scripts to never down the mesh device except in correct circumstances. Solution for #2: already exists with 'iwconfig txpower off' and 'iwconfig txpower auto'. -- The other discussion to have is what should the default radio state be in. If the default state is OFF until it's explicitly turned on by NetworkManager or the user, then: a) it should be verified that the firmware doesn't turn the radio on until told to do so b) it should be verified that the driver doesn't turn the radio on until the device is brought up (ifconfig eth0 up) c) it should be verified that nothing in the host OS (startup scripts like the 'network' service calling ifup or NetworkManager bring the device up) until the point at which the user has explicit control Note that this approach would not be conducive to a nice exploratory out-of-box experience (hence I don't really condone this approach wholeheartedly) where access points and friends are immediately visible from the Mesh view, until you explain to 5 year olds what the heck wireless is and why it's off-by-default in the first place. People traveling in RF-prohibited environments should be the ones who bear the burden of turning off the RF, since not too many of the target audience is going to ever be flying on a plane or driving by a blasting site. Plus those people who are flying on planes likely already know that they _need_ to turn off the wireless component, which isn't likely to be known by the 5 - 10 year old children in Peru who may never been near an airplane anyway. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
On Thu, 2008-01-17 at 12:32 -0500, Michail Bletsas wrote: > There is quite a bit of important history removed from this discussion. > > We designed the laptop to be able to do mesh forwarding *all the time*. > This was a fundamental decision because it affected every other choice > that we made in the wireless subsystem. > > One of the issues that it introduced is that it makes the radio deviate > from what "proper" radio behavior is supposed to be under Linux these > days: when you bring an interface down (ifconfig eth0 down), its radio > should be disabled. If you don't bring the interface up on boot, the radio > should stay off. Pretty clean and simple. > > When it comes to our radio - we *designed it* to start forward frames soon > after you initialize it and keep doing it regardless of what the host > interface does. > That's why we used a radio with its own CPU and memory. > > So things like "iwconfig eth0 txpower off" might be doing the right thing, > however they do so (if they do**) indirectly, by controlling the host > interface. > > There is an "iwpriv eth0 radiooff/radioon" IOCTL hook in the firmware > which was meant to control the radio power directly - it was removed a few > months ago since it wasn't considered to its thing in the "proper" linux > manner. > > And ever since we keep having this "airplane mode" discussion. > > M. > > ** I don't know how "iwconfig eth0 txpower off" is implemented, if it uses > the same IOCTL with "iwpriv eth0 radiooff", then it is doing the right > thing. Yes. iwconfig eth0 txpower off -> lbs_radio_ioctl(priv, RADIO_OFF); which does CMD_802_11_RADIO_CONTROL (control = !TURN_ON_RF) iwconfig eth0 txpower auto > lbs_radio_ioctl(priv, RADIO_ON); which does CMD_802_11_RADIO_CONTROL (control = TURN_ON_RF) then does CMD_802_11_RF_TX_POWER (dbm = 0x) which is what I understood the radioon/radiooff stuff to do anyway, hence the objection to another non-standard ioctl. Dan > > > "Edward Cherlin" <[EMAIL PROTECTED]> wrote on 01/16/2008 06:56:17 PM: > > > On Jan 16, 2008 2:46 PM, Dan Williams <[EMAIL PROTECTED]> wrote: > > On Wed, 2008-01-16 at 20:22 -0200, Ricardo Carrano wrote: > > > I believe what you want is "radio off", not "mesh stop". > > > "radio off" == iwconfig eth0 txpower off > > > > that's always been around from day #1. > > > > That turns off the radio for this session. How do you disable it so > > it doesn't come on at the next boot? > > > > -- > > Edward Cherlin > > End Poverty at a Profit by teaching children business > > http://www.EarthTreasury.org/ > > "The best way to predict the future is to invent it."--Alan Kay ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
On Thu, 2008-01-17 at 09:51 -1000, Mitch Bradley wrote: > I suppose that OFW could reset the wireless to turn it off and then do > some chipset configuration hack that would make that USB port > disappear. I'm just guessing though; I haven't studied the 5536 manual > with this possibility in mind. > > That seems like a fairly horrible way to solve a Linux problem. My thoughts precisely. Fix it where it should be fixed, not by playing russian roulette with a shotgun in a pitch-black room full of cute, cuddly, mewing kittens stacked from floor to ceiling. I've already outlined (twice! if my mails get through moderation on networking@) proposed changes to make "airplane" mode happen. Dan > I'm not volunteering to study this possibility right now; I have other > fish to fry. > > Bennett Todd wrote: > > For "airplane mode", is there some command OFW can run to make > > the whole eth/msh device poweroff and disappear until the next > > powercycle? If so, maybe we could hook another key check into > > /boot/olpc.fth? > > > > -Bennett > > > > > > > > ___ > > Devel mailing list > > Devel@lists.laptop.org > > http://lists.laptop.org/listinfo/devel > > > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
For "airplane mode", is there some command OFW can run to make the whole eth/msh device poweroff and disappear until the next powercycle? If so, maybe we could hook another key check into /boot/olpc.fth? -Bennett pgps5csES4LCD.pgp Description: PGP signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
I suppose that OFW could reset the wireless to turn it off and then do some chipset configuration hack that would make that USB port disappear. I'm just guessing though; I haven't studied the 5536 manual with this possibility in mind. That seems like a fairly horrible way to solve a Linux problem. I'm not volunteering to study this possibility right now; I have other fish to fry. Bennett Todd wrote: > For "airplane mode", is there some command OFW can run to make > the whole eth/msh device poweroff and disappear until the next > powercycle? If so, maybe we could hook another key check into > /boot/olpc.fth? > > -Bennett > > > > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
>> To completely silence the radio: >> #!/bin/bash >> rmmod usb8xxx >> mv /lib/firmaware/usb8883.bin /lib/firmaware/usb8883.bin.quiet > For a more user-friendly solution, (short of a hardware rfkill switch) > put a toggle somewhere in the control panel for "Don't turn the radio on > automatically" that is _UN_checked by default, and a wireless > enabled/disabled button there too. ... > Then ensure that NetworkManager is clued into the preference value > above, and that NM sets it's initial wireless-enabled state coherently > with the preference value above as well. > > Were these things done, by default the behavior would be the same as it > is now, but those people who wish insane amounts of control over the TX > power state can have their fluffy white cake and eat it too. I'm one of those who wishes for control. The G1G1 offering has set up a user population different from the education design of the OLPC project. I live in the boonies, have no wireless, and there are no other radios within range. My connection is by wired ethernet. Took me a while to find out that NetworkManager would set up my wired connection, if I provided a DHCP server. However, if I happen to unplug my ethernet cable for a while, NetworkManager reverts eth0 back to radio (and I need to reboot to reconnect as wired). What I wish for is a user toggle that when I'm at home will inhibit NetworkManager from supplanting the wired connection. (But I do want to restore radio function when I take my XO to a cafe.) mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
On Thu, 2008-01-17 at 14:18 -0500, Mikus Grinbergs wrote: > >> To completely silence the radio: > >> #!/bin/bash > >> rmmod usb8xxx > >> mv /lib/firmaware/usb8883.bin /lib/firmaware/usb8883.bin.quiet > > > For a more user-friendly solution, (short of a hardware rfkill switch) > > put a toggle somewhere in the control panel for "Don't turn the radio on > > automatically" that is _UN_checked by default, and a wireless > > enabled/disabled button there too. ... > > Then ensure that NetworkManager is clued into the preference value > > above, and that NM sets it's initial wireless-enabled state coherently > > with the preference value above as well. > > > > Were these things done, by default the behavior would be the same as it > > is now, but those people who wish insane amounts of control over the TX > > power state can have their fluffy white cake and eat it too. > > I'm one of those who wishes for control. The G1G1 offering has set > up a user population different from the education design of the OLPC > project. I live in the boonies, have no wireless, and there are no > other radios within range. My connection is by wired ethernet. > > Took me a while to find out that NetworkManager would set up my > wired connection, if I provided a DHCP server. However, if I happen > to unplug my ethernet cable for a while, NetworkManager reverts eth0 > back to radio (and I need to reboot to reconnect as wired). > > > What I wish for is a user toggle that when I'm at home will inhibit > NetworkManager from supplanting the wired connection. (But I do > want to restore radio function when I take my XO to a cafe.) NetworkManager has functionality to enable/disable the wireless, it's just not exposed from the user interface yet. I believe Simon has been looking into this. In the mean-time, you can disable wireless by running: dbus-send --system \ --dest=org.freedesktop.NetworkManager \ /org/freedesktop/NetworkManager \ org.freedesktop.NetworkManager.setWirelessEnabled boolean:false and NetworkManager won't try to use either of the 802.11bg or the mesh interfaces until the next reboot. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
On Thu, 2008-01-17 at 12:32 -0500, Michail Bletsas wrote: > There is an "iwpriv eth0 radiooff/radioon" IOCTL hook in the firmware > which was meant to control the radio power directly - it was removed a few > months ago since it wasn't considered to its thing in the "proper" linux > manner. I looked for it and I couldn't find it. Please could you point me at the commit in which it was removed? I'm not entirely sure it ever made it into our driver. Certainly it never made it into the upstream driver, and the upstream driver is all that really matters, in the long term. > ** I don't know how "iwconfig eth0 txpower off" is implemented, if it > uses the same IOCTL with "iwpriv eth0 radiooff", then it is doing the > right thing. It uses CMD_802_11_RADIO_CONTROL with the RADIO_OFF argument, which I believe is the correct thing to do. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
On Thu, 2008-01-17 at 19:16 -0500, Giannis Galanis wrote: > It must be noted that the important issue of this discussion is how to have > the radio blocked from BEFORE the XO boots, so as not to be conflicting with > the airline regulations. We should change the firmware so that it isn't active automatically as soon as it's loaded -- let the driver activate it when it's appropriate. Then the decision as to whether the radio is blocked can properly be handled in userspace, and the device can be left quiescent if appropriate. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
It is included in http://wiki.laptop.org/go/Wireless_Driver_README and if it helps i believe it was removed around september i believe. It was definitely an active ioctl. It must be noted that the important issue of this discussion is how to have the radio blocked from BEFORE the XO boots, so as not to be conflicting with the airline regulations. Renaming usb8388.bin works fine, and as expected is kept even after the reboot(just checked to be sure). We just need to include it in sugar-control-panel or smth. When testing in the lab, it is not important which method is the more appropriate since all cover our need of a turned off radio. But, still this involves "only documenting" a method for silencing the radio, so we are legally covered. In fact, the FAA has a law only on operating in the 800mhz band on an airplane. The airlines, based on that law, developed regulations that cover all mobile phones/ wireless devices for reasons of simplification. What i wanna say, is that as far as we are concerned it perfectly safe and lawful to use an XO with mesh on, chat and any other stuff on a plane. And if we wanna play "extra safe" we simply turn the radio off after the reboot. On Jan 17, 2008 6:26 PM, David Woodhouse <[EMAIL PROTECTED]> wrote: > > On Thu, 2008-01-17 at 12:32 -0500, Michail Bletsas wrote: > > There is an "iwpriv eth0 radiooff/radioon" IOCTL hook in the firmware > > which was meant to control the radio power directly - it was removed a > few > > months ago since it wasn't considered to its thing in the "proper" linux > > manner. > > I looked for it and I couldn't find it. Please could you point me at the > commit in which it was removed? I'm not entirely sure it ever made it > into our driver. Certainly it never made it into the upstream driver, > and the upstream driver is all that really matters, in the long term. > > > ** I don't know how "iwconfig eth0 txpower off" is implemented, if it > > uses the same IOCTL with "iwpriv eth0 radiooff", then it is doing the > > right thing. > > It uses CMD_802_11_RADIO_CONTROL with the RADIO_OFF argument, which I > believe is the correct thing to do. > > -- > dwmw2 > > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
I see. But i hope this is not done only because of the airline issue, and that there are other reasons that it useful to boot with firmware unloaded. Because as far as the airline issue is concerned, we should not take it tooo seriously. As long as we have a working solution it is fine. Not many people will use it anyway. U see my point? Also, if it is smth simple we can quickly implement is for Update.1. On Jan 17, 2008 7:36 PM, David Woodhouse <[EMAIL PROTECTED]> wrote: > > On Thu, 2008-01-17 at 19:16 -0500, Giannis Galanis wrote: > > It must be noted that the important issue of this discussion is how to > have > > the radio blocked from BEFORE the XO boots, so as not to be conflicting > with > > the airline regulations. > > We should change the firmware so that it isn't active automatically as > soon as it's loaded -- let the driver activate it when it's appropriate. > Then the decision as to whether the radio is blocked can properly be > handled in userspace, and the device can be left quiescent if > appropriate. > > -- > dwmw2 > > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
Let's not forget the dongles that act as dumb repeaters on their own, based on their firmware. Are they gonna use a different firmware instead? p. David Woodhouse wrote: > We should change the firmware so that it isn't active automatically as > soon as it's loaded -- let the driver activate it when it's appropriate. > Then the decision as to whether the radio is blocked can properly be > handled in userspace, and the device can be left quiescent if > appropriate. > > -- Polychronis Ypodimatopoulos Graduate student Viral Communications MIT Media Lab Tel: +1 (617) 459-6058 http://www.mit.edu/~ypod/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
David Woodhouse <[EMAIL PROTECTED]> wrote on 01/17/2008 06:26:38 PM: > > It uses CMD_802_11_RADIO_CONTROL with the RADIO_OFF argument, which I > believe is the correct thing to do. > If that's the case then it does the right thing - no need to worry with the earlier iwpriv call. M.___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
[EMAIL PROTECTED] wrote on 01/17/2008 02:17:44 PM: > I apologize if I am over simplifying: > > - mesh stop was considered when we had compatibility issues with > lazy-wds routers. We addressed this, right? Do we still need this > feature? Michail? The only reason to have this, is for debugging puproses > - For airplane mode or relatives, we need to shut up radio (any traffic). and to be able to completely silence the radio in airplane mode. M. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
On Fri, 2008-01-18 at 10:33 -0500, Michail Bletsas wrote: > Dan Williams <[EMAIL PROTECTED]> wrote on 01/18/2008 10:08:09 AM: > > > On Fri, 2008-01-18 at 08:36 +0800, David Woodhouse wrote: > > > On Thu, 2008-01-17 at 19:16 -0500, Giannis Galanis wrote: > > > > It must be noted that the important issue of this discussion is > > how to have > > > > the radio blocked from BEFORE the XO boots, so as not to be > > conflicting with > > > > the airline regulations. > > > > > > We should change the firmware so that it isn't active automatically as > > > soon as it's loaded -- let the driver activate it when it's > appropriate. > > > Then the decision as to whether the radio is blocked can properly be > > > handled in userspace, and the device can be left quiescent if > > > appropriate. > > > > Yes. The active antennas firmware would need to be slightly altered to > > start on firmware boot, but the normal XO firmware should certainly be > > radio-off-until-driver-enabled (by setting IFF_UP or device open). > > > So let's alter a fundamental design principle so that the XO doesn't > transmit a single frame when riding an airplane... ?? > > I don't think so. If people feel so strong about this they can always > block firmware loading. > Mesh forwarding will go on when you initialize the adapter and it is up to > the user to turn it off if they feel that they have too. We're not really arguing here, we agree. Everyone agrees that wireless +mesh should start automatically by default after bootup. What David (and I in like 3 mails yesterday in this thread already) had proposed was that the XO firmware should disable the radio _until_Linux_loads_ and the driver tells it to enable the radio. When Linux loads, the driver (or NetworkManager, or whatever) starts the radio. That way, the user at least has a change to at some point say "no, don't turn on the radio by default" if they want to. _Nothing_ would change for users who do not want/care/need to touch the radio in this scenario, everything would continue to work as it currently does. I'm not sure where you get the idea that we're saying it should all be in airplane mode all the time unless the child explicitly turns the radio on. We're saying exactly the opposite of that. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
On Fri, 2008-01-18 at 10:08 -0500, Dan Williams wrote: > Yes. The active antennas firmware would need to be slightly altered to > start on firmware boot, but the normal XO firmware should certainly be > radio-off-until-driver-enabled (by setting IFF_UP or device open). Let us make a clear distinction between the two types of 'active antenna' here. The ones which are actually attached to servers and acting as wireless devices for a computer, we want to act like in the XO. When they come up automatically into mesh repeater mode, that's actually a complete PITA -- and it means we can't reboot the servers because then the driver can't initialise the wireless because it's in mesh repeater mode and doesn't respond properly to being reset. Only for the standalone devices which we're going to hang in a corridor and feed 5v do we want _any_ kind of automatic network operation. And then it needs to be configurable -- we have to set the channel. Since we need a way to configure the channel on the active antennae, let's use channel zero to indicate 'no automatic mesh'. And please can we have that firmware by tomorrow, Ulan Bator time -- so that I can actually set up the school server so that it's rebootable without subsequently having to disconnect and reconnect the firmware? I'd do it myself, but bug #429 bites again... -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
Michail, This would be 3107, right ? 3109 is when we started seeing the auto-update mode. John On Jan 18, 2008, at 4:22 PM, David Woodhouse wrote: > > On Fri, 2008-01-18 at 15:50 -0500, Michail Bletsas wrote: >>> Ideally, we want to just kill the auto-mesh-repeater mode, where >>> boot2 >>> times out after 5 seconds and loads the firmware from the >>> internal flash >>> (which is obviously larger on these devices than on the XO). Can we >>> achieve that just by updating to a 'normal' Boot2 version from >>> the XO? >>> >> Yes, that is all that is needed to disable autoboot on the active >> antennas. > > OK, that's the plan for the Mongolia deployment then. Wad, please can > you confirm (with libertas-flash.py) and forward me the current (XO) > version of Boot2, so I can do that? > > Thanks. > > -- > dwmw2 > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
John Watlington <[EMAIL PROTECTED]> wrote on 01/18/2008 04:56:26 PM: > > Michail, > This would be 3107, right ? > 3109 is when we started seeing the auto-update mode. > Yes, M. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
On Fri, 2008-01-18 at 16:56 -0500, John Watlington wrote: > > Michail, > This would be 3107, right ? > 3109 is when we started seeing the auto-update mode. OK, so can we go between 3109 and 3107 in both directions using libertas-flash.py or did the protocol get changed without telling us? We never did get Marvell's 'firmware update' patch for the driver to apply to the kernel they claim it applies to, did we? -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
On Fri, 2008-01-18 at 15:50 -0500, Michail Bletsas wrote: > > Ideally, we want to just kill the auto-mesh-repeater mode, where boot2 > > times out after 5 seconds and loads the firmware from the internal flash > > (which is obviously larger on these devices than on the XO). Can we > > achieve that just by updating to a 'normal' Boot2 version from the XO? > > > Yes, that is all that is needed to disable autoboot on the active > antennas. OK, that's the plan for the Mongolia deployment then. Wad, please can you confirm (with libertas-flash.py) and forward me the current (XO) version of Boot2, so I can do that? Thanks. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
David Woodhouse <[EMAIL PROTECTED]> wrote on 01/18/2008 03:31:08 PM: > > Ideally, we want to just kill the auto-mesh-repeater mode, where boot2 > times out after 5 seconds and loads the firmware from the internal flash > (which is obviously larger on these devices than on the XO). Can we > achieve that just by updating to a 'normal' Boot2 version from the XO? > Yes, that is all that is needed to disable autoboot on the active antennas. M. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
On Fri, 2008-01-18 at 14:47 -0500, Dan Williams wrote: > So wait, what's going on here? I thought the devices attached to school > servers were just run-of-the-mill USB 8388 devices like the 8388 > daughterboard of the XO, but different connector, right? > > What is the post-boot firmware flash functionality supposed to apply to, > the host-less active antenna? (which is what I heretofore had > understood). These two are the same device (active antenna). The device behaves differently depending on whether it detects a USB link on startup. --Ben ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
On Fri, 2008-01-18 at 14:47 -0500, Dan Williams wrote: > What is the post-boot firmware flash functionality supposed to apply to, > the host-less active antenna? (which is what I heretofore had > understood). As Ben says, they're the same thing. If you don't load the firmware within 5 seconds of the boot2 code starting up, the thing loads its own firmware from the internal flash. Yes, it's horrid. It doesn't even preserve the boot2 version, because we did some stupid hack to preserve that in the _driver_ rather than keeping it internal, so when we send the CMD_802_11_RESET command to kick the device back into boot2, we get 'device firmware changed' from the kernel and it appears as a completely new device... Ideally, we want to just kill the auto-mesh-repeater mode, where boot2 times out after 5 seconds and loads the firmware from the internal flash (which is obviously larger on these devices than on the XO). Can we achieve that just by updating to a 'normal' Boot2 version from the XO? (Yes, I should be sleeping. No, I have no idea what timezone I'm in). -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
On Fri, 2008-01-18 at 08:36 +0800, David Woodhouse wrote: > On Thu, 2008-01-17 at 19:16 -0500, Giannis Galanis wrote: > > It must be noted that the important issue of this discussion is how to have > > the radio blocked from BEFORE the XO boots, so as not to be conflicting with > > the airline regulations. > > We should change the firmware so that it isn't active automatically as > soon as it's loaded -- let the driver activate it when it's appropriate. > Then the decision as to whether the radio is blocked can properly be > handled in userspace, and the device can be left quiescent if > appropriate. Yes. The active antennas firmware would need to be slightly altered to start on firmware boot, but the normal XO firmware should certainly be radio-off-until-driver-enabled (by setting IFF_UP or device open). Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
Dan Williams <[EMAIL PROTECTED]> wrote on 01/18/2008 10:08:09 AM: > On Fri, 2008-01-18 at 08:36 +0800, David Woodhouse wrote: > > On Thu, 2008-01-17 at 19:16 -0500, Giannis Galanis wrote: > > > It must be noted that the important issue of this discussion is > how to have > > > the radio blocked from BEFORE the XO boots, so as not to be > conflicting with > > > the airline regulations. > > > > We should change the firmware so that it isn't active automatically as > > soon as it's loaded -- let the driver activate it when it's appropriate. > > Then the decision as to whether the radio is blocked can properly be > > handled in userspace, and the device can be left quiescent if > > appropriate. > > Yes. The active antennas firmware would need to be slightly altered to > start on firmware boot, but the normal XO firmware should certainly be > radio-off-until-driver-enabled (by setting IFF_UP or device open). > So let's alter a fundamental design principle so that the XO doesn't transmit a single frame when riding an airplane... ?? I don't think so. If people feel so strong about this they can always block firmware loading. Mesh forwarding will go on when you initialize the adapter and it is up to the user to turn it off if they feel that they have too. M. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
On Sat, 2008-01-19 at 01:38 +0800, David Woodhouse wrote: > On Fri, 2008-01-18 at 10:08 -0500, Dan Williams wrote: > > Yes. The active antennas firmware would need to be slightly altered to > > start on firmware boot, but the normal XO firmware should certainly be > > radio-off-until-driver-enabled (by setting IFF_UP or device open). > > Let us make a clear distinction between the two types of 'active > antenna' here. The ones which are actually attached to servers and > acting as wireless devices for a computer, we want to act like in the > XO. When they come up automatically into mesh repeater mode, that's > actually a complete PITA -- and it means we can't reboot the servers > because then the driver can't initialise the wireless because it's in > mesh repeater mode and doesn't respond properly to being reset. So wait, what's going on here? I thought the devices attached to school servers were just run-of-the-mill USB 8388 devices like the 8388 daughterboard of the XO, but different connector, right? What is the post-boot firmware flash functionality supposed to apply to, the host-less active antenna? (which is what I heretofore had understood). Dan > Only for the standalone devices which we're going to hang in a corridor > and feed 5v do we want _any_ kind of automatic network operation. And > then it needs to be configurable -- we have to set the channel. > > Since we need a way to configure the channel on the active antennae, > let's use channel zero to indicate 'no automatic mesh'. And please can > we have that firmware by tomorrow, Ulan Bator time -- so that I can > actually set up the school server so that it's rebootable without > subsequently having to disconnect and reconnect the firmware? > > I'd do it myself, but bug #429 bites again... > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
On Sat, 2008-01-19 at 04:31 +0800, David Woodhouse wrote: > On Fri, 2008-01-18 at 14:47 -0500, Dan Williams wrote: > > What is the post-boot firmware flash functionality supposed to apply to, > > the host-less active antenna? (which is what I heretofore had > > understood). > > As Ben says, they're the same thing. If you don't load the firmware > within 5 seconds of the boot2 code starting up, the thing loads its own > firmware from the internal flash. Hmm, ok... So all the external USB 8388 dongles have a larger SPI flash to contain both the Boot2 code and the 100K thick firmware? Dan > Yes, it's horrid. It doesn't even preserve the boot2 version, because we > did some stupid hack to preserve that in the _driver_ rather than > keeping it internal, so when we send the CMD_802_11_RESET command to > kick the device back into boot2, we get 'device firmware changed' from > the kernel and it appears as a completely new device... > > Ideally, we want to just kill the auto-mesh-repeater mode, where boot2 > times out after 5 seconds and loads the firmware from the internal flash > (which is obviously larger on these devices than on the XO). Can we > achieve that just by updating to a 'normal' Boot2 version from the XO? > > (Yes, I should be sleeping. No, I have no idea what timezone I'm in). > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
Dan Williams <[EMAIL PROTECTED]> wrote on 01/19/2008 12:48:06 PM: > > Hmm, ok... So all the external USB 8388 dongles have a larger SPI flash > to contain both the Boot2 code and the 100K thick firmware? > yes, M.___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
On Sat, 2008-01-19 at 13:05 -0500, Michail Bletsas wrote: > > > Dan Williams <[EMAIL PROTECTED]> wrote on 01/19/2008 12:48:06 PM: > > > > > > Hmm, ok... So all the external USB 8388 dongles have a larger SPI > flash > > to contain both the Boot2 code and the 100K thick firmware? > > > yes, Does the Boot2 code take care of figuring out the correct address to write the thick firmware to, or does the flash tool have to figure out the address to write it to? Normally this address is embedded in the firmware flash file header, is there an address the tool should check for to verify, or is that address completely irrelevant because the boot2 code is smart enough to figure out where to put it? Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
> > Does the Boot2 code take care of figuring out the correct address to > write the thick firmware to, or does the flash tool have to figure out > the address to write it to? Normally this address is embedded in the > firmware flash file header, is there an address the tool should check > for to verify, or is that address completely irrelevant because the > boot2 code is smart enough to figure out where to put it? > Dan, You have to ask Ronak that. Right now the flash writing logic lives in the firmware. M. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
RE: Testing the Wireless driver changes
After downloading the firmware, the ARM is told by the boot2 to jump to a specific location of the internal memory. If the firmware is not downloaded, the boot2 starts the grab the firmware from the Flash and jumps to the same location of the internal memory once that is done. The flash tool does not figure out anything here. The boot2 code is smart enough to figure that out. Best Regards, Ronak From: Michail Bletsas [mailto:[EMAIL PROTECTED] Sent: Saturday, January 19, 2008 10:23 AM To: Dan Williams; Ronak Chokshi Cc: Ricardo Carrano; devel; David Woodhouse; Giannis Galanis; [EMAIL PROTECTED] Subject: Re: Testing the Wireless driver changes > > Does the Boot2 code take care of figuring out the correct address to > write the thick firmware to, or does the flash tool have to figure out > the address to write it to? Normally this address is embedded in the > firmware flash file header, is there an address the tool should check > for to verify, or is that address completely irrelevant because the > boot2 code is smart enough to figure out where to put it? > Dan, You have to ask Ronak that. Right now the flash writing logic lives in the firmware. M. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
Dan, Do we have a description of the dbus API for the XO NM implementation somewhere? [Like the one in: http://people.redhat.com/dcbw/NetworkManager/NetworkManager%20DBUS%20API.txt ] Thank you! Carrano On Jan 17, 2008 6:24 PM, Dan Williams <[EMAIL PROTECTED]> wrote: > On Thu, 2008-01-17 at 14:18 -0500, Mikus Grinbergs wrote: > > >> To completely silence the radio: > > >> #!/bin/bash > > >> rmmod usb8xxx > > >> mv /lib/firmaware/usb8883.bin /lib/firmaware/usb8883.bin.quiet > > > > > For a more user-friendly solution, (short of a hardware rfkill switch) > > > put a toggle somewhere in the control panel for "Don't turn the radio > on > > > automatically" that is _UN_checked by default, and a wireless > > > enabled/disabled button there too. ... > > > Then ensure that NetworkManager is clued into the preference value > > > above, and that NM sets it's initial wireless-enabled state coherently > > > with the preference value above as well. > > > > > > Were these things done, by default the behavior would be the same as > it > > > is now, but those people who wish insane amounts of control over the > TX > > > power state can have their fluffy white cake and eat it too. > > > > I'm one of those who wishes for control. The G1G1 offering has set > > up a user population different from the education design of the OLPC > > project. I live in the boonies, have no wireless, and there are no > > other radios within range. My connection is by wired ethernet. > > > > Took me a while to find out that NetworkManager would set up my > > wired connection, if I provided a DHCP server. However, if I happen > > to unplug my ethernet cable for a while, NetworkManager reverts eth0 > > back to radio (and I need to reboot to reconnect as wired). > > > > > > What I wish for is a user toggle that when I'm at home will inhibit > > NetworkManager from supplanting the wired connection. (But I do > > want to restore radio function when I take my XO to a cafe.) > > NetworkManager has functionality to enable/disable the wireless, it's > just not exposed from the user interface yet. I believe Simon has been > looking into this. In the mean-time, you can disable wireless by > running: > > dbus-send --system \ > --dest=org.freedesktop.NetworkManager \ > /org/freedesktop/NetworkManager \ > org.freedesktop.NetworkManager.setWirelessEnabled boolean:false > > and NetworkManager won't try to use either of the 802.11bg or the mesh > interfaces until the next reboot. > > Dan > > > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
