Re: Need help with porting iwn driver

[David Young <dyoung%pobox.com@localhost>]

On Tue, Mar 30, 2010 at 09:43:36AM -0600, Sverre Froyen wrote:
> Hi,
> 
> I've been attempting to port the latest iwn driver from OpenBSD.  I have been 
> able to get it running but I'm having a couple of issues that I was hoping 
> somebody might have some insight into.

Is there any reason that you port from OpenBSD instead of from FreeBSD?

> The hardware is an Intel 5100 adapter connecting to a Linksys 11g
> access point. I'm using WAP2. This is on amd64/current.
>
> Immediately after boot and most of the time with only "normal" network
> activity, the adapter works fine.
>
> When I use it with a network TV tuner (HDHomeRun from Silicondust),
> however, the interface will sometimes get locked into what appears
> to be a slow-speed mode. When this happens, I can usually get the
> interface working again by doing "ifconfig iwn0 down/up". The TV tuner
> sends the video signal as a stream of UDP packets. When the interface
> is working correctly, I see around 1500 packets per second. When
> it is stuck, this drops to just over 75 packets per second. Since
> each packet is around 1400 bytes, the stuck mode might be DS1 (1
> Mb/s). I've noticed that "ifconfig iwn0" sometimes reports DS1 when
> this happens -- but not always.

It sounds to me like the AP sends the packets.  The AP and your NetBSD
box select the transmission rate independently of each other.

What rates do the AP and your NetBSD box negotiate? 'wlanctl iwn0' will
tell us.

You can find out the rate that the AP transmits at with 'tcpdump -nel -y
ieee802_11_radio -i iwn0'.

> The frequency of the interface getting stuck may depend on the wireness 
> activity in the neighborhood. I have also noticed that the channel setting on 
> the access point affects the speed.

Oftentimes tcpdump can show us the activity that is not on the same
network (i.e., same BSSID) but that is on the same channel.  That might
be worth a look.

> Sometimes when I attempt to clear the interface (doing the down/up), it fails 
> to associate and a I see a continuous set of scans. Only a reboot will clear 
> this up.
> 
> I do not recall seeing any memory allocation failures in the driver (unless I 
> force it by stopping the application that is receiving the data).
> 
> Questions:
> 
> Is there a  variable somewhere that contains the actual current interface 
> speed? Why does ifconfig iwn0 sometimes report a higher speed? I presume the 
> speed is chosen by the firmware.

In iwn(4), the transmission rate is chosen by a rate adaptation module
called "amrr" that runs on the host.  That module could use a lot of
improvement, but it sounds right now like the rate adaptation is not the
problem.

It looks to me like the rate reported by 'ifconfig iwn0' is faithful
to the current speed if the rate adaptation module is amrr, but in
general, you should not rely on it: some modules select the rate on a
packet-by-packet basis, depending on properties of the packet such as
its *length*.

> Would it make sense to try to attempt to detect the stuck state and force a 
> firmware reset (or reload) automatically?
> 
> Assuming that the down/up dance completely resets the driver state, where 
> could the failure to associate come from?

It's hard to say.  Send the information I ask for, and maybe we can get
to the bottom of it.

Dave

-- 
David Young             OJC Technologies
dyoung%ojctech.com@localhost      Urbana, IL * (217) 278-3933