Discussion:
Need help with porting iwn driver
(too old to reply)
Sverre Froyen
2010-03-30 15:43:36 UTC
Permalink
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.

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.

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.

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.

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?

Any other comments or ideas?

Thanks,
Sverre


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
David Young
2010-03-30 22:01:09 UTC
Permalink
Post by Sverre Froyen
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?
Post by Sverre Froyen
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'.
Post by Sverre Froyen
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.
Post by Sverre Froyen
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).
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*.
Post by Sverre Froyen
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
***@ojctech.com Urbana, IL * (217) 278-3933

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Sverre Froyen
2010-04-13 02:42:10 UTC
Permalink
Post by David Young
Post by Sverre Froyen
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?
Post by Sverre Froyen
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'.
Post by Sverre Froyen
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.
Here are results from the three commands when the interface if working
properly:

# ifconfig iwn0
iwn0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ssid fesk nwkey *****
powersave off
bssid 00:12:17:60:ba:43 chan 10
address: 00:16:ea:bb:89:c8
media: IEEE802.11 autoselect (OFDM18 mode 11g)
status: active
inet 192.168.2.5 netmask 0xffffff00 broadcast 192.168.2.255
inet6 fe80::216:eaff:febb:89c8%iwn0 prefixlen 64 scopeid 0x2
# wlanctl iwn0
iwn0: mac 00:12:17:60:ba:43 bss 00:12:17:60:ba:43
node flags 0005<bss,scan>
ess <fesk>
chan 10 freq 2457MHz flags 04e0<cck,ofdm,2.4GHz,dynamic cck-ofdm>
capabilities 0411<ess,privacy,short slot-time>
beacon-interval 100 TU tsft 136782234380 us
rates 1.0 2.0 5.5 6.0 9.0 11.0 12.0 [18.0] 24.0 36.0 48.0 54.0
assoc-id 49154 assoc-failed 0 inactivity 300s
rssi 215 txseq 26394 rxseq 42320
# tcpdump -nel -c 20 -y ieee802_11_radio -i iwn0
13:53:10.994504 136782253228us tsft 54.0 Mb/s 2457 MHz (0x04e0) -41dB signal
-87dB noise DA:00:16:ea:bb:89:c8 BSSID:00:12:17:60:ba:43 SA:00:18:dd:01:7b:2f
Data IV:4c6b Pad 20 KeyID 0
13:53:10.995231 136782253955us tsft 54.0 Mb/s 2457 MHz (0x04e0) -41dB signal
-87dB noise DA:00:16:ea:bb:89:c8 BSSID:00:12:17:60:ba:43 SA:00:18:dd:01:7b:2f
Data IV:4c6c Pad 20 KeyID 0
13:53:11.005090 136782263815us tsft 54.0 Mb/s 2457 MHz (0x04e0) -41dB signal
-87dB noise DA:00:16:ea:bb:89:c8 BSSID:00:12:17:60:ba:43 SA:00:18:dd:01:7b:2f
Data IV:4c6d Pad 20 KeyID 0
13:53:11.006150 136782264875us tsft 54.0 Mb/s 2457 MHz (0x04e0) -41dB signal
-87dB noise DA:00:16:ea:bb:89:c8 BSSID:00:12:17:60:ba:43 SA:00:18:dd:01:7b:2f
Data IV:4c6e Pad 20 KeyID 0
13:53:11.006570 136782265295us tsft 54.0 Mb/s 2457 MHz (0x04e0) -41dB signal
-87dB noise DA:00:16:ea:bb:89:c8 BSSID:00:12:17:60:ba:43 SA:00:18:dd:01:7b:2f
Data IV:4c6f Pad 20 KeyID 0
13:53:11.007458 136782266181us tsft 54.0 Mb/s 2457 MHz (0x04e0) -41dB signal
-87dB noise DA:00:16:ea:bb:89:c8 BSSID:00:12:17:60:ba:43 SA:00:18:dd:01:7b:2f
Data IV:4c70 Pad 20 KeyID 0
13:53:11.008181 136782266906us tsft 54.0 Mb/s 2457 MHz (0x04e0) -41dB signal
-87dB noise DA:00:16:ea:bb:89:c8 BSSID:00:12:17:60:ba:43 SA:00:18:dd:01:7b:2f
Data IV:4c71 Pad 20 KeyID 0
13:53:11.008475 136782267201us tsft 54.0 Mb/s 2457 MHz (0x04e0) -41dB signal
-87dB noise DA:00:16:ea:bb:89:c8 BSSID:00:12:17:60:ba:43 SA:00:18:dd:01:7b:2f
Data IV:4c72 Pad 20 KeyID 0
13:53:11.008770 136782267495us tsft 54.0 Mb/s 2457 MHz (0x04e0) -41dB signal
-87dB noise DA:00:16:ea:bb:89:c8 BSSID:00:12:17:60:ba:43 SA:00:18:dd:01:7b:2f
Data IV:4c73 Pad 20 KeyID 0
13:53:11.009067 136782267789us tsft 54.0 Mb/s 2457 MHz (0x04e0) -41dB signal
-87dB noise DA:00:16:ea:bb:89:c8 BSSID:00:12:17:60:ba:43 SA:00:18:dd:01:7b:2f
Data IV:4c74 Pad 20 KeyID 0
13:53:11.009359 136782268084us tsft 54.0 Mb/s 2457 MHz (0x04e0) -41dB signal
-87dB noise DA:00:16:ea:bb:89:c8 BSSID:00:12:17:60:ba:43 SA:00:18:dd:01:7b:2f
Data IV:4c75 Pad 20 KeyID 0
13:53:11.009906 136782268629us tsft 54.0 Mb/s 2457 MHz (0x04e0) -41dB signal
-87dB noise DA:00:16:ea:bb:89:c8 BSSID:00:12:17:60:ba:43 SA:00:18:dd:01:7b:2f
Data IV:4c76 Pad 20 KeyID 0
13:53:11.010199 136782268924us tsft 54.0 Mb/s 2457 MHz (0x04e0) -41dB signal
-87dB noise DA:00:16:ea:bb:89:c8 BSSID:00:12:17:60:ba:43 SA:00:18:dd:01:7b:2f
Data IV:4c77 Pad 20 KeyID 0
13:53:11.010496 136782269218us tsft 54.0 Mb/s 2457 MHz (0x04e0) -41dB signal
-87dB noise DA:00:16:ea:bb:89:c8 BSSID:00:12:17:60:ba:43 SA:00:18:dd:01:7b:2f
Data IV:4c78 Pad 20 KeyID 0
13:53:11.010923 136782269648us tsft 54.0 Mb/s 2457 MHz (0x04e0) -41dB signal
-87dB noise DA:00:16:ea:bb:89:c8 BSSID:00:12:17:60:ba:43 SA:00:18:dd:01:7b:2f
Data IV:4c79 Pad 20 KeyID 0
13:53:11.011217 136782269942us tsft 54.0 Mb/s 2457 MHz (0x04e0) -41dB signal
-87dB noise DA:00:16:ea:bb:89:c8 BSSID:00:12:17:60:ba:43 SA:00:18:dd:01:7b:2f
Data IV:4c7a Pad 20 KeyID 0
13:53:11.011513 136782270237us tsft 54.0 Mb/s 2457 MHz (0x04e0) -41dB signal
-87dB noise DA:00:16:ea:bb:89:c8 BSSID:00:12:17:60:ba:43 SA:00:18:dd:01:7b:2f
Data IV:4c7b Pad 20 KeyID 0
13:53:11.011890 136782270612us tsft 54.0 Mb/s 2457 MHz (0x04e0) -41dB signal
-87dB noise DA:00:16:ea:bb:89:c8 BSSID:00:12:17:60:ba:43 SA:00:18:dd:01:7b:2f
Data IV:4c7c Pad 20 KeyID 0
13:53:11.012183 136782270907us tsft 54.0 Mb/s 2457 MHz (0x04e0) -41dB signal
-87dB noise DA:00:16:ea:bb:89:c8 BSSID:00:12:17:60:ba:43 SA:00:18:dd:01:7b:2f
Data IV:4c7d Pad 20 KeyID 0
13:53:11.012478 136782271202us tsft 54.0 Mb/s 2457 MHz (0x04e0) -41dB signal
-87dB noise DA:00:16:ea:bb:89:c8 BSSID:00:12:17:60:ba:43 SA:00:18:dd:01:7b:2f
Data IV:4c7e Pad 20 KeyID 0

and here are the results when it is stuck in "slow" mode.

# ifconfig iwn0
iwn0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
ssid fesk nwkey *****
powersave off
bssid 00:12:17:60:ba:43 chan 10
address: 00:16:ea:bb:89:c8
media: IEEE802.11 autoselect (DS1 mode 11g)
status: active
inet 192.168.2.5 netmask 0xffffff00 broadcast 192.168.2.255
inet6 fe80::216:eaff:febb:89c8%iwn0 prefixlen 64 scopeid 0x2
# wlanctl iwn0
iwn0: mac 00:12:17:60:ba:43 bss 00:12:17:60:ba:43
node flags 0005<bss,scan>
ess <fesk>
chan 10 freq 2457MHz flags 04e0<cck,ofdm,2.4GHz,dynamic cck-ofdm>
capabilities 0411<ess,privacy,short slot-time>
beacon-interval 100 TU tsft 154313728782 us
rates [1.0] 2.0 5.5 6.0 9.0 11.0 12.0 18.0 24.0 36.0 48.0 54.0
assoc-id 49154 assoc-failed 0 inactivity 300s
rssi 212 txseq 3244 rxseq 52080
# tcpdump -nel -c 20 -y ieee802_11_radio -i iwn0
18:45:22.603187 154313916853us tsft 1.0 Mb/s 2457 MHz (0x04e0) -44dB signal
-77dB noise DA:00:16:ea:bb:89:c8 BSSID:00:12:17:60:ba:43 SA:00:18:dd:01:7b:2f
Data IV:99ed Pad 20 KeyID 0
18:45:22.614992 154313928661us tsft 1.0 Mb/s 2457 MHz (0x04e0) -45dB signal
-77dB noise DA:00:16:ea:bb:89:c8 BSSID:00:12:17:60:ba:43 SA:00:18:dd:01:7b:2f
Data IV:99ee Pad 20 KeyID 0
18:45:22.630507 154313944175us tsft 1.0 Mb/s 2457 MHz (0x04e0) -45dB signal
-77dB noise DA:00:16:ea:bb:89:c8 BSSID:00:12:17:60:ba:43 SA:00:18:dd:01:7b:2f
Data IV:99ee Pad 20 KeyID 0
18:45:22.670821 154313984490us tsft 1.0 Mb/s 2457 MHz (0x04e0) -44dB signal
-77dB noise DA:00:16:ea:bb:89:c8 BSSID:00:12:17:60:ba:43 SA:00:18:dd:01:7b:2f
Data IV:99ee Pad 20 KeyID 0
18:45:22.682718 154313996388us tsft 1.0 Mb/s 2457 MHz (0x04e0) -43dB signal
-77dB noise DA:00:16:ea:bb:89:c8 BSSID:00:12:17:60:ba:43 SA:00:18:dd:01:7b:2f
Data IV:99ef Pad 20 KeyID 0
18:45:22.720347 154314034015us tsft 1.0 Mb/s 2457 MHz (0x04e0) -45dB signal
-77dB noise DA:00:16:ea:bb:89:c8 BSSID:00:12:17:60:ba:43 SA:00:18:dd:01:7b:2f
Data IV:99ef Pad 20 KeyID 0
18:45:22.721513 154314045904us tsft 1.0 Mb/s 2457 MHz (0x04e0) -44dB signal
-77dB noise BSSID:00:12:17:60:ba:43 DA:ff:ff:ff:ff:ff:ff SA:00:12:17:60:ba:43
Beacon[|802.11]
18:45:22.733401 154314047072us tsft 1.0 Mb/s 2457 MHz (0x04e0) -43dB signal
-87dB noise DA:00:16:ea:bb:89:c8 BSSID:00:12:17:60:ba:43 SA:00:18:dd:01:7b:2f
Data IV:99f0 Pad 20 KeyID 0
18:45:22.770667 154314084335us tsft 1.0 Mb/s 2457 MHz (0x04e0) -45dB signal
-87dB noise DA:00:16:ea:bb:89:c8 BSSID:00:12:17:60:ba:43 SA:00:18:dd:01:7b:2f
Data IV:99f0 Pad 20 KeyID 0
18:45:22.782597 154314096269us tsft 1.0 Mb/s 2457 MHz (0x04e0) -44dB signal
-87dB noise DA:00:16:ea:bb:89:c8 BSSID:00:12:17:60:ba:43 SA:00:18:dd:01:7b:2f
Data IV:99f1 Pad 20 KeyID 0
18:45:22.914118 154314227788us tsft 1.0 Mb/s 2457 MHz (0x04e0) -45dB signal
-87dB noise DA:00:16:ea:bb:89:c8 BSSID:00:12:17:60:ba:43 SA:00:18:dd:01:7b:2f
Data IV:99f2 Pad 20 KeyID 0
18:45:22.930183 154314243854us tsft 1.0 Mb/s 2457 MHz (0x04e0) -44dB signal
-87dB noise DA:00:16:ea:bb:89:c8 BSSID:00:12:17:60:ba:43 SA:00:18:dd:01:7b:2f
Data IV:99f2 Pad 20 KeyID 0
18:45:22.945893 154314259562us tsft 1.0 Mb/s 2457 MHz (0x04e0) -42dB signal
-87dB noise DA:00:16:ea:bb:89:c8 BSSID:00:12:17:60:ba:43 SA:00:18:dd:01:7b:2f
Data IV:99f2 Pad 20 KeyID 0
18:45:22.982936 154314296606us tsft 1.0 Mb/s 2457 MHz (0x04e0) -45dB signal
-87dB noise DA:00:16:ea:bb:89:c8 BSSID:00:12:17:60:ba:43 SA:00:18:dd:01:7b:2f
Data IV:99f3 Pad 20 KeyID 0
18:45:23.000499 154314314169us tsft 1.0 Mb/s 2457 MHz (0x04e0) -45dB signal
-87dB noise DA:00:16:ea:bb:89:c8 BSSID:00:12:17:60:ba:43 SA:00:18:dd:01:7b:2f
Data IV:99f3 Pad 20 KeyID 0
18:45:23.025844 154314350234us tsft 1.0 Mb/s 2457 MHz (0x04e0) -45dB signal
-87dB noise BSSID:00:12:17:60:ba:43 DA:ff:ff:ff:ff:ff:ff SA:00:12:17:60:ba:43
Beacon[|802.11]
18:45:23.087033 154314400702us tsft 1.0 Mb/s 2457 MHz (0x04e0) -43dB signal
-87dB noise DA:00:16:ea:bb:89:c8 BSSID:00:12:17:60:ba:43 SA:00:18:dd:01:7b:2f
Data IV:99f4 Pad 20 KeyID 0
18:45:23.125389 154314449782us tsft 1.0 Mb/s 2457 MHz (0x04e0) -43dB signal
-87dB noise BSSID:00:12:17:60:ba:43 DA:ff:ff:ff:ff:ff:ff SA:00:12:17:60:ba:43
Beacon[|802.11]
18:45:23.436860 154314750530us tsft 1.0 Mb/s 2457 MHz (0x04e0) -42dB signal
-89dB noise DA:00:16:ea:bb:89:c8 BSSID:00:12:17:60:ba:43 SA:00:18:dd:01:7b:2f
Data IV:99f8 Pad 20 KeyID 0
18:45:23.438028 154314762419us tsft 1.0 Mb/s 2457 MHz (0x04e0) -42dB signal
-89dB noise BSSID:00:12:17:60:ba:43 DA:ff:ff:ff:ff:ff:ff SA:00:12:17:60:ba:43
Beacon[|802.11]

I don't see anything obvious differences except for the much lower speed in the
second trace. ifconfig iwn0 shows the interface in promiscuous mode. that is
because I was running a second tcpdump command searching for packets from
another BSSID. There were none. (The second tcpdump had been running for a
*long* time before the interface slowed and is therefore not likely to be part
of the problem.)

Any ideas?

Thanks,
Sverre

PS The hard lockup problem that I decribed in my initial email has been
resolved. See the thread beginning with http://mail-index.netbsd.org/tech-
net/2010/04/05/msg002001.html

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Loading...