Finished: CALL FOR TESTERS Intel wireless 5100/5300 iwn(4) driver for FreeBSD

LesJen said:
Yesterday I saw that the newest version is 39. I was on 33 with the rekey.diff. I upgraded to 39 and the disconnections are back. Do I have to apply the rekey.diff even to the latest version?

Thanks

The patch is for the kernel not for the iwn driver. If you did just update iwn and not the kernel, there is no need to apply the patch again.

Use # wlandebug +crypto to see if it is again the rekeying issue.
 
bschmidt said:
$ uname -a please, including SVN revision.

YuriS said:
Hello!
Recently upgrade my FreeNAS by Intel 5100 ABG mini PCI-e WLAN card. But in FreeNas system I haven't any compiler, and I need precompiled (Intel 64) drivers iwn5000fw.ko and if_iwn.ko
Can anyone help me?
Thanks.
Yuri.

Code:
FreeBSD freenas.local 7.2-RELEASE-p4 FreeBSD 7.2-RELEASE-p4 #0: Fri Oct 16 16:53:48 UTC 2009     root@vmbsd72amd64:/usr/obj/freenas/usr/src/sys/FREENAS-amd64  amd64
PS,
Sorry forr delayed response :)
Yuri.
 
YuriS said:
Code:
FreeBSD freenas.local 7.2-RELEASE-p4 FreeBSD 7.2-RELEASE-p4 #0: Fri Oct 16 16:53:48 UTC 2009     root@vmbsd72amd64:/usr/obj/freenas/usr/src/sys/FREENAS-amd64  amd64
PS,
Sorry forr delayed response :)
Yuri.

The driver is only for 8.0 and later, there have been to many changes in net80211 to simply backport it. If you can't get Freenas to use a newer kernel you are out of luck with that Intel card.
 
They said, that 0.7 version is last. :( . And I don't know about the plans of future development & support FreeNAS. I try to change my card by older Intel 3945abg. Thank you anyway!
Yuri.
 
comfortableodo said:
Hello bschmidt,

if I am not mistaken, you became a new comitter for src?! Congratulations!!
Thanks for the driver by the way! Works like a charm.

Thanks and you are welcome ;)
 
bschmidt said:
It might be as easy as replacing DHCP with SYNCDHCP in /etc/rc.conf

Now after installing ver 39 it takes so long that I get a "giving up" message when booting. It takes about another 10 sec. before the wlan is up. I liked it when it waited to aquire an IP-address. Any chance it can be fixed?

Thanks :)
 
LesJen said:
Now after installing ver 39 it takes so long that I get a "giving up" message when booting. It takes about another 10 sec. before the wlan is up. I liked it when it waited to aquire an IP-address. Any chance it can be fixed?

Thanks :)

I expect that to be related with scanning. It doesn't find the desired AP on the first few tries, can you confirm that?
 
bschmidt said:
I expect that to be related with scanning. I doesn't find the desired AP on the first few tries, can you confirm that?

What I've done is waiting some seconds before I turn on the PC. I have one power switch that used to start everything at the same time. After I changed my rutine I usually get link and DHCP offer. It has failed a few times but I'm not sure if it's the scanning or just a time out that's to short!

Thanks :)
 
LesJen said:
What I've done is waiting some seconds before I turn on the PC. I have one power switch that used to start everything at the same time. After I changed my rutine I usually get link and DHCP offer. It has failed a few times but I'm not sure if it's the scanning or just a time out that's to short!

Thanks :)

"Everything" as in both computer and the AP? Ok.. as of the lag of information I assume the AP is not yet up when the computer tries to associate.

On a site note, I've noticed that (at least with wpa_supplicant) the first scan barely returns scan results. I believe that is related with way to short dwell times. Looking into that..
 
bschmidt said:
"Everything" as in both computer and the AP? Ok.. as of the lag of information I assume the AP is not yet up when the computer tries to associate.

On a site note, I've noticed that (at least with wpa_supplicant) the first scan barely returns scan results. I believe that is related with way to short dwell times. Looking into that..

Your assumption is correct, the AP was probaly not ready. But as I mentioned before, I started seeing this when I went from r33 to r39.

I look forward to your findings concerning the scan results.

/Leslie
 
LesJen said:
Your assumption is correct, the AP was probaly not ready. But as I mentioned before, I started seeing this when I went from r33 to r39.

I look forward to your findings concerning the scan results.

/Leslie

Would you try that again with r33? I can't point my finger on a change which might cause the issue.
 
bschmidt said:
Would you try that again with r33? I can't point my finger on a change which might cause the issue.

This is what I've done. Reverted to r33 and rebooted, then r34, r35 and r36 I did not see the giving up message. With r37 I saw it once, r38 more than once (2 out of three reboots) with r39 it's more often than not that I get the giving up message, 5 out of 6 reboots. AP was powered on all the time!

/L
 
LesJen said:
This is what I've done. Reverted to r33 and rebooted, then r34, r35 and r36 I did not see the giving up message. With r37 I saw it once, r38 more than once (2 out of three reboots) with r39 it's more often than not that I get the giving up message, 5 out of 6 reboots. AP was powered on all the time!

/L

Ok, thanks. The only thing worth investigating is that starting with r37 there is support for HT channels. But those are only read from the EEPROM, that shouldn't be an issue.. I'll look into that.
 
I need your input on this. Today for some reason my wlan would not connect. I tried to rebuild the driver but it did not help. One thing that I don't believe should affect is that I have the following line in my system /etc/crontab
@daily root freebsd-update cron
I got a message from this job that it had downloaded patches for
8.0-RELEASE-p2 which my system already is and it also said that the files on my system where manually changed, which is correct, that's the rekey.diff.
I've tried to revert back through the versions but it did not help either. By chance I gave the command wlandebug +crypto to follow what was happening, see below.
Within one minute of issuing the wlandebug command it connected! I thought it was by chance so I rebooted and did it all over again and the same behaviour after the command wlandebug it connected shortly after. Please comment because I do not understand this.


Code:
Feb 17 19:19:02  wpa_supplicant[411]: WPA: Key negotiation completed with 00:21:91:02:e9:13 [PTK=TKIP GTK=TKIP]
Feb 17 19:19:02  kernel: wlan0: ieee80211_crypto_newkey: cipher 1 flags 0x3 keyix 65535
Feb 17 19:19:02  kernel: wlan0: ieee80211_crypto_newkey: no h/w support for cipher TKIP, falling back to s/w
Feb 17 19:19:02  kernel: wlan0: ieee80211_crypto_newkey: no h/w support for TKIP MIC, falling back to s/w
Feb 17 19:19:02  kernel: wlan0: ieee80211_crypto_setkey: TKIP keyix 0 flags 0x1f3 mac 00:21:91:02:e9:13 rsc 0 tsc 0 len 16
Feb 17 19:19:02  kernel: wlan0: ieee80211_crypto_newkey: cipher 1 flags 0x6 keyix 2
Feb 17 19:19:02  kernel: wlan0: ieee80211_crypto_newkey: no h/w support for cipher TKIP, falling back to s/w
Feb 17 19:19:02  kernel: wlan0: ieee80211_crypto_newkey: no h/w support for TKIP MIC, falling back to s/w
Feb 17 19:19:02  kernel: wlan0: ieee80211_crypto_setkey: TKIP keyix 2 flags 0x1f6 mac ff:ff:ff:ff:ff:ff rsc 7 tsc 0 len 16
Feb 17 19:19:02  wpa_supplicant[411]: CTRL-EVENT-CONNECTED - Connection to 00:21:91:02:e9:13 completed (auth) [id=0 id_str=]
Feb 17 19:19:06  dhclient: New IP Address (wlan0): 172.17.0.140
Feb 17 19:19:06  dhclient: New Subnet Mask (wlan0): 255.255.255.0
Feb 17 19:19:06  dhclient: New Broadcast Address (wlan0): 172.17.0.255
Feb 17 19:19:06  dhclient: New Routers (wlan0): 172.17.0.1
 
Bschmidt, I wanted to let you know that I built and installed your driver for the Intel 5100 on my Thinkpad x201s (I pulled from SVN about a week ago) and it has been working great. Thank you!
 
chess said:
Bschmidt, I wanted to let you know that I built and installed your driver for the Intel 5100 on my Thinkpad x201s (I pulled from SVN about a week ago) and it has been working great. Thank you!

You're welcome ;)
 
LesJen said:
Within one minute of issuing the wlandebug command it connected! I thought it was by chance so I rebooted and did it all over again and the same behaviour after the command wlandebug it connected shortly after. Please comment because I do not understand this.

That really sounds like the scanning issue I was talking about. The card will not "find" an AP because of really short hardcoded dwell times. Dwell times define how long to stay on a channel before considering it as "quiet" without an AP and switching to the next one. Also once a assoc/auth attempt is made, the driver uses even shorter dwell times for backgrounds scans. Because I missed that part initially, the driver does not clean up dwell times correctly on connection loss and sticks to using those short dwell times with almost no way to get a scan result.

I'm working on that one. Especially using dynamic dwell times provides by net80211, it will take a another couple of days of testing before I consider it worth committing though.

You can verify that with # wlandebug +scan +state which will print the scanning process and results.
 
Thanks work.
I had been update system source code, complier, install, and use it(intel 5100agn in Toshiba M800.
But I haven't AccessPoint, So I can't test it.
Anyway... I saw boot message(dmesg), iwn0 output have 802.11abg support message.
But haven't 802.11n support, Is it iwn driver or FreeBSD issue?
Thanks you very much.
 
epopen said:
Thanks work.
I had been update system source code, complier, install, and use it(intel 5100agn in Toshiba M800.
But I haven't AccessPoint, So I can't test it.
Anyway... I saw boot message(dmesg), iwn0 output have 802.11abg support message.
But haven't 802.11n support, Is it iwn driver or FreeBSD issue?
Thanks you very much.

The driver does currently not have any kind of 11n support. This is still on my TODO list.
 
I'm trying to upgrade my iwn/iwnfw using the method described bellow;

Code:
svn co http://svn.techwires.net/svn/projects/freebsd
cd freebsd/sys/modules/iwnfw
make
make install
cd ../iwn
env CFLAGS=-I$PWD/../../ make
make install

And it gives the following warning when i run env CFLAGS=-I$PWD/../../ make;

Code:
pandora# env CFLAGS=-I$PWD/../../ make
===> iwn1000 (all)
Warning: Object directory not changed from original /root/freebsd/sys/modules/iwnfw/iwn1000
===> iwn4965 (all)
Warning: Object directory not changed from original /root/freebsd/sys/modules/iwnfw/iwn4965
===> iwn5000 (all)
Warning: Object directory not changed from original /root/freebsd/sys/modules/iwnfw/iwn5000
===> iwn5150 (all)
Warning: Object directory not changed from original /root/freebsd/sys/modules/iwnfw/iwn5150
===> iwn6000 (all)
Warning: Object directory not changed from original /root/freebsd/sys/modules/iwnfw/iwn6000

Is this the reason that after updating the driver and rebooting, i can no longer get online?

Thanks
Bit
 
bschmidt said:
That really sounds like the scanning issue I was talking about. The card will not "find" an AP because of really short hardcoded dwell times. Dwell times define how long to stay on a channel before considering it as "quiet" without an AP and switching to the next one. Also once a assoc/auth attempt is made, the driver uses even shorter dwell times for backgrounds scans. Because I missed that part initially, the driver does not clean up dwell times correctly on connection loss and sticks to using those short dwell times with almost no way to get a scan result.

I'm working on that one. Especially using dynamic dwell times provides by net80211, it will take a another couple of days of testing before I consider it worth committing though.

You can verify that with # wlandebug +scan +state which will print the scanning process and results.

I've had other things to do so sorry for the delay! Here's the output on a working connection. I'm still on -r 41.


Code:
Feb 23 23:10:01  kernel: wlan0: ieee80211_bg_scan: active scan, ticks 641239 duration 150
Feb 23 23:10:01  kernel: wlan0: scan_task: chan   1g ->   1g [active, dwell min 20ms max 150ms]
Feb 23 23:10:01  kernel: wlan0: scan_task: chan   1g ->   6g [active, dwell min 20ms max 139ms]
Feb 23 23:10:01  kernel: [00:19:cb:4d:93:48] new beacon on chan 6 (bss chan 6) "peter" rssi 11
Feb 23 23:10:01  kernel: [00:19:cb:4d:93:48] caps 0x431 bintval 100 erp 0x100
Feb 23 23:10:01  kernel: wlan0: scan_task: chan   6g ->  11g [active, dwell min 20ms max 123ms]
Feb 23 23:10:01  kernel: [00:22:6b:7a:18:89] new beacon on chan 11 (bss chan 11) "linksys" rssi 9
Feb 23 23:10:01  kernel: [00:22:6b:7a:18:89] caps 0x411 bintval 100 erp 0x104
Feb 23 23:10:01  kernel: wlan0: scan_task: chan  11g ->   7g [active, dwell min 20ms max 106ms]
Feb 23 23:10:01  kernel: wlan0: scan_task: chan   7g ->  13g [passive, dwell min 20ms max 90ms]
Feb 23 23:10:01  kernel: wlan0: ieee80211_cancel_anyscan: cancel active scan
Feb 23 23:10:01  kernel: wlan0: scan_task: done, [ticks 641304, dwell min 20 scanend 641392]
Feb 23 23:10:02  kernel: wlan0: ieee80211_bg_scan: active scan, ticks 642058 duration 150
Feb 23 23:10:02  kernel: wlan0: scan_task: chan   1g ->  52a [passive, dwell min 20ms max 150ms]
Feb 23 23:10:02  kernel: wlan0: scan_task: chan  52a ->  56a [passive, dwell min 20ms max 65ms]
Feb 23 23:10:02  kernel: wlan0: scan_task: stopped, [ticks 642246, dwell min 20 scanend 642210]
Feb 23 23:10:02  kernel: wlan0: ieee80211_bg_scan: active scan, ticks 642263 duration 150
Feb 23 23:10:02  kernel: wlan0: scan_task: chan   1g ->  60a [passive, dwell min 20ms max 150ms]
Feb 23 23:10:03  kernel: wlan0: scan_task: chan  60a ->  64a [passive, dwell min 20ms max 65ms]
Feb 23 23:10:03  kernel: wlan0: ieee80211_cancel_anyscan: cancel active scan
Feb 23 23:10:03  kernel: wlan0: scan_task: done, [ticks 642349, dwell min 20 scanend 642413]
Feb 23 23:10:03  kernel: wlan0: ieee80211_bg_scan: active scan, ticks 642672 duration 150
Feb 23 23:10:03  kernel: wlan0: scan_task: chan   1g ->  36a [passive, dwell min 20ms max 150ms]
Feb 23 23:10:03  kernel: wlan0: scan_task: chan  36a ->  40a [passive, dwell min 20ms max 65ms]
Feb 23 23:10:03  kernel: wlan0: scan_task: stopped, [ticks 642860, dwell min 20 scanend 642824]
Feb 23 23:10:03  kernel: wlan0: ieee80211_bg_scan: active scan, ticks 642877 duration 150
Feb 23 23:10:03  kernel: wlan0: scan_task: chan   1g ->  44a [passive, dwell min 20ms max 150ms]
Feb 23 23:10:03  kernel: wlan0: scan_task: chan  44a ->  48a [passive, dwell min 20ms max 65ms]
Feb 23 23:10:03  kernel: wlan0: scan_task: stopped, [ticks 643064, dwell min 20 scanend 643027]
Feb 23 23:10:03  kernel: wlan0: ieee80211_bg_scan: active scan, ticks 643082 duration 150
Feb 23 23:10:03  kernel: wlan0: scan_task: chan   1g ->   2g [active, dwell min 20ms max 150ms]
Feb 23 23:10:03  kernel: wlan0: scan_task: chan   2g ->   3g [active, dwell min 20ms max 134ms]
Feb 23 23:10:03  kernel: wlan0: scan_task: chan   3g ->   4g [active, dwell min 20ms max 118ms]
Feb 23 23:10:03  kernel: wlan0: scan_task: chan   4g ->   5g [active, dwell min 20ms max 101ms]
Feb 23 23:10:03  kernel: wlan0: scan_task: chan   5g ->   8g [active, dwell min 20ms max 85ms]
Feb 23 23:10:03  kernel: wlan0: scan_task: chan   8g ->   9g [active, dwell min 20ms max 32ms]
Feb 23 23:10:03  kernel: wlan0: scan_task: stopped, [ticks 643217, dwell min 20 scanend 643232]
Feb 23 23:10:03  kernel: wlan0: ieee80211_bg_scan: active scan, ticks 643286 duration 150
Feb 23 23:10:03  kernel: wlan0: scan_task: chan   1g ->  10g [active, dwell min 20ms max 150ms]
Feb 23 23:10:03  kernel: wlan0: scan_task: chan  10g ->  12g [passive, dwell min 20ms max 133ms]
Feb 23 23:10:04  kernel: wlan0: scan_task: stopped, [ticks 643466, dwell min 20 scanend 643436]
Feb 23 23:10:04  kernel: wlan0: ieee80211_bg_scan: active scan, ticks 643491 duration 150
Feb 23 23:10:04  kernel: wlan0: scan_task: chan   1g -> 149a [passive, dwell min 20ms max 150ms]
Feb 23 23:10:04  kernel: wlan0: scan_task: chan 149a -> 153a [passive, dwell min 20ms max 65ms]
Feb 23 23:10:04  kernel: wlan0: ieee80211_cancel_anyscan: cancel active scan
Feb 23 23:10:04  kernel: wlan0: scan_task: done, [ticks 643647, dwell min 20 scanend 643641]
Feb 23 23:10:04  kernel: wlan0: ieee80211_bg_scan: active scan, ticks 644105 duration 150
Feb 23 23:10:04  kernel: wlan0: scan_task: chan   1g -> 157a [passive, dwell min 20ms max 150ms]
Feb 23 23:10:04  kernel: wlan0: scan_task: chan 157a -> 161a [passive, dwell min 20ms max 65ms]
Feb 23 23:10:04  kernel: wlan0: scan_task: stopped, [ticks 644293, dwell min 20 scanend 644258]
Feb 23 23:10:04  kernel: wlan0: ieee80211_bg_scan: active scan, ticks 644310 duration 150
Feb 23 23:10:04  kernel: wlan0: scan_task: chan   1g -> 165a [passive, dwell min 20ms max 150ms]
Feb 23 23:10:05  kernel: wlan0: scan_task: chan 165a -> 100a [passive, dwell min 20ms max 65ms]
Feb 23 23:10:05  kernel: wlan0: scan_task: stopped, [ticks 644497, dwell min 20 scanend 644460]
Feb 23 23:10:05  kernel: wlan0: ieee80211_bg_scan: active scan, ticks 644515 duration 150
Feb 23 23:10:05  kernel: wlan0: scan_task: chan   1g -> 104a [passive, dwell min 20ms max 150ms]
Feb 23 23:10:05  kernel: wlan0: scan_task: chan 104a -> 108a [passive, dwell min 20ms max 65ms]
Feb 23 23:10:05  kernel: wlan0: scan_task: stopped, [ticks 644702, dwell min 20 scanend 644665]
Feb 23 23:10:05  kernel: wlan0: ieee80211_bg_scan: active scan, ticks 644719 duration 150
Feb 23 23:10:05  kernel: wlan0: scan_task: chan   1g -> 112a [passive, dwell min 20ms max 150ms]
Feb 23 23:10:05  kernel: wlan0: scan_task: chan 112a -> 116a [passive, dwell min 20ms max 64ms]
Feb 23 23:10:05  kernel: wlan0: scan_task: stopped, [ticks 644907, dwell min 20 scanend 644869]
Feb 23 23:10:05  kernel: wlan0: ieee80211_bg_scan: active scan, ticks 644924 duration 150
Feb 23 23:10:05  kernel: wlan0: scan_task: chan   1g -> 120a [passive, dwell min 20ms max 150ms]
Feb 23 23:10:05  kernel: wlan0: scan_task: chan 120a -> 124a [passive, dwell min 20ms max 65ms]
Feb 23 23:10:05  kernel: wlan0: scan_task: stopped, [ticks 645111, dwell min 20 scanend 645074]
Feb 23 23:10:05  kernel: wlan0: ieee80211_bg_scan: active scan, ticks 645129 duration 150
Feb 23 23:10:05  kernel: wlan0: scan_task: chan   1g -> 128a [passive, dwell min 20ms max 150ms]
Feb 23 23:10:05  kernel: wlan0: scan_task: chan 128a -> 132a [passive, dwell min 20ms max 65ms]
Feb 23 23:10:05  kernel: wlan0: scan_task: stopped, [ticks 645316, dwell min 20 scanend 645279]
Feb 23 23:10:05  kernel: wlan0: ieee80211_bg_scan: active scan, ticks 645333 duration 150
Feb 23 23:10:05  kernel: wlan0: scan_task: chan   1g -> 136a [passive, dwell min 20ms max 150ms]
Feb 23 23:10:06  wpa_supplicant[411]: CTRL-EVENT-SCAN-RESULTS 
Feb 23 23:10:06  kernel: wlan0: scan_task: chan 136a -> 140a [passive, dwell min 20ms max 64ms]
Feb 23 23:10:06  kernel: wlan0: scan_task: done, [ticks 645521, dwell min 20 scanend 645483]
Feb 23 23:10:06  kernel: wlan0: notify scan done


I'll get back to you when/if the problem will reocour.
 
I've committed an update to scanning in general recently r42, it should now be much more reliable. And also be able to scan *all* 5GHz by now.

LesJen said:
I've had other things to do so sorry for the delay! Here's the output on a working connection. I'm still on -r 41.

No problem.

LesJen said:
Code:
Feb 23 23:10:01  kernel: wlan0: ieee80211_bg_scan: active scan, ticks 641239 duration 150
Feb 23 23:10:01  kernel: wlan0: scan_task: chan   1g ->   1g [active, dwell min 20ms max 150ms]
..
Feb 23 23:10:06  kernel: wlan0: scan_task: done, [ticks 645521, dwell min 20 scanend 645483]
Feb 23 23:10:06  kernel: wlan0: notify scan done


I'll get back to you when/if the problem will reocour.

Thx, though, I missed giving you another command to set, sry.

Code:
# wlandebug +scan +state
# sysctl dev.iwn.0.debug=0x2000
 
I'm using -r 43 now and it behaves very well. I've not seen any problems with getting a link from the AP. When a rescan is done it's very quick and the log just confirms that it has taken place. To me this was a very big step forward, the driver seems stable, so once again Thank you :)
/L
 
Back
Top