Testing the Wireless driver changes

[Dan Williams]

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( <unfinished ...>
> ----------------
> 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 <kim at laptop.org> 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 at lists.laptop.org
> http://lists.laptop.org/listinfo/devel