Re: [iwn] 6235 support, initial patch
Hi. On 07.12.2013 22:21, Adrian Chadd wrote: Here's some fixes from mav, shoehorned into the current driver framework. Mav - where'd you get your changes from? It was long ago. I would guess that from you. :) http://people.freebsd.org/~adrian/iwn/20131207-iwn-6235-1.diff This enables the 6235. It now doesn't firmware panic upon startup. I've passed _no_ traffic through it though - I don't have pigtails for the connectors on my NIC. Sorry :( I've added in mav's changes but I've done it by adding a new 6235 config / limits section rather than hacking up the existing 6000g2b section. I don't know what effect it'll have on the existing NICs. So I didn't want to change that behaviour. This is against the latest -HEAD. I've updated to the latest HEAD including only your patch and immediately got firmware crash during boot: firmware: 'iwn6000g2bfw' version 0: 460912 bytes loaded at 0x81a120c0 iwn0: iwn_intr: fatal firmware error firmware error log: error type = UNKNOWN (0x19B6) program counter = 0x00014DD0 source line = 0x02E2 error data = 0x0001008C branch link = 0x00014DC200014DC2 interrupt link = 0xCFE2 time= 26892 driver status: tx ring 0: qid=0 cur=0 queued=0 tx ring 1: qid=1 cur=0 queued=0 tx ring 2: qid=2 cur=0 queued=0 tx ring 3: qid=3 cur=0 queued=0 tx ring 4: qid=4 cur=0 queued=0 tx ring 5: qid=5 cur=0 queued=0 tx ring 6: qid=6 cur=0 queued=0 tx ring 7: qid=7 cur=0 queued=0 tx ring 8: qid=8 cur=0 queued=0 tx ring 9: qid=9 cur=2 queued=0 tx ring 10: qid=10 cur=0 queued=0 tx ring 11: qid=11 cur=0 queued=0 tx ring 12: qid=12 cur=0 queued=0 tx ring 13: qid=13 cur=0 queued=0 tx ring 14: qid=14 cur=0 queued=0 tx ring 15: qid=15 cur=0 queued=0 tx ring 16: qid=16 cur=0 queued=0 tx ring 17: qid=17 cur=0 queued=0 tx ring 18: qid=18 cur=0 queued=0 tx ring 19: qid=19 cur=0 queued=0 rx ring: cur=2 iwn0: iwn5000_post_alive: crystal calibration failed, error 35 iwn0: iwn_init_locked: could not initialize hardware, error 35 firmware: 'iwn6000g2bfw' version 0: 460912 bytes loaded at 0x81a120c0 iwn0: iwn_intr: fatal firmware error firmware error log: error type = UNKNOWN (0x19B6) program counter = 0x00014DD0 source line = 0x02E2 error data = 0x0001008C branch link = 0x00014DC200014DC2 interrupt link = 0xCFE2 time= 26907 driver status: tx ring 0: qid=0 cur=0 queued=0 tx ring 1: qid=1 cur=0 queued=0 tx ring 2: qid=2 cur=0 queued=0 tx ring 3: qid=3 cur=0 queued=0 tx ring 4: qid=4 cur=0 queued=0 tx ring 5: qid=5 cur=0 queued=0 tx ring 6: qid=6 cur=0 queued=0 tx ring 7: qid=7 cur=0 queued=0 tx ring 8: qid=8 cur=0 queued=0 tx ring 9: qid=9 cur=2 queued=0 tx ring 10: qid=10 cur=0 queued=0 tx ring 11: qid=11 cur=0 queued=0 tx ring 12: qid=12 cur=0 queued=0 tx ring 13: qid=13 cur=0 queued=0 tx ring 14: qid=14 cur=0 queued=0 tx ring 15: qid=15 cur=0 queued=0 tx ring 16: qid=16 cur=0 queued=0 tx ring 17: qid=17 cur=0 queued=0 tx ring 18: qid=18 cur=0 queued=0 tx ring 19: qid=19 cur=0 queued=0 rx ring: cur=2 iwn0: iwn5000_post_alive: crystal calibration failed, error 35 iwn0: iwn_init_locked: could not initialize hardware, error 35 Adding usual -ht40 option didn't change anything. Then I switched from default 6000g2b firmware 17.168.5.2 to 18.168.6.1, which I was using before. With -ht40 flag am able to connect and write this letter. Without the flag card can't associate with AP: Dec 9 10:43:37 mavbook wpa_supplicant[467]: wlan0: Authentication with 56:04:a6:d3:65:30 timed out. Dec 9 10:43:37 mavbook wpa_supplicant[467]: wlan0: CTRL-EVENT-DISCONNECTED bssid=56:04:a6:d3:65:30 reason=3 locally_generated=1 Dec 9 10:43:41 mavbook wpa_supplicant[467]: wlan0: Trying to associate with 56:04:a6:d3:65:30 (SSID='mavhome5' freq=5180 MHz) Dec 9 10:43:41 mavbook wpa_supplicant[467]: wlan0: Associated with 56:04:a6:d3:65:30 Dec 9 10:43:41 mavbook kernel: wlan0: link state changed to UP Dec 9 10:43:41 mavbook dhclient[1313]: send_packet: No buffer space available Dec 9 10:43:42 mavbook wpa_supplicant[467]: wlan0: CTRL-EVENT-DISCONNECTED bssid=56:04:a6:d3:65:30 reason=0 Dec 9 10:43:42 mavbook kernel: wlan0: link state changed to DOWN Dec 9 10:43:45 mavbook dhclient[1313]: send_packet: Invalid argument Dec 9 10:43:47 mavbook wpa_supplicant[467]: wlan0: Trying to associate with 56:04:a6:d3:65:30 (SSID='mavhome5' freq=5180 MHz) Dec 9 10:43:55 mavbook dhclient[1313]: send_packet: Network is down Dec 9 10:43:57 mavbook wpa_supplicant[467]: wlan0: Authentication with 56:04:a6:d3:65:30 timed out. Dec 9 10:43:57 mavbook wpa_supplicant[467]: wlan0: CTRL-EVENT-DISCONNECTED bssid=56:04:a6:d3:65:30 reason=3 locally_generated=1 Dec 9 10:43:57
Current problem reports assigned to freebsd-wireless@FreeBSD.org
Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description o kern/183759 wireless [iwn] [wlan] Interface dies, OACTIVE set on wlan0 o kern/183727 wireless [wlan] ENOBUFFS incorrectly returned when tx packet is o kern/183644 wireless [ath] [patch] ath(4) stops working o kern/183430 wireless [iwn] latest change to the rate code setup uses 11n ra o kern/183428 wireless [net80211] [iwn] Some APs seem to announce HT but no H o kern/181898 wireless [iwn] [patch] Centrino Advanced-N 6235 with latest iwn o kern/181694 wireless [iwn] [patch] Initialize hardware in iwn(4) resume cod o kern/181161 wireless [wl] config a old compaq wl-110 wireless card make ker o kern/181132 wireless [iwn] stream calculation is wrong for the Intel 4965 o kern/181100 wireless [bwi] Turning up bwi0 crashes / deadlocks the kernel o kern/180816 wireless [iwl] Intel Centrino Wireless-N 2200 not supported o kern/179847 wireless [ath] [patch] Update regdomain in ath drivers includin o kern/179709 wireless [ath] Atheros 5212 does not work: stuck beacon; resett o kern/179547 wireless [ath] Add AR9485 custom board fixes (CUS198) o kern/179482 wireless [ath] [patch] Fix AR9462 external LNA configuration o kern/179269 wireless [ath] [AR9285] RX antenna diversity is not functioning o kern/179232 wireless [ath] panic in ath o kern/178986 wireless [ath] Change mac address of ath(4) is not reflected wh o kern/178492 wireless [ath] ath0 (AR9287) panic o kern/178491 wireless [ath] ath0 (AR9287) stuck beacon o kern/178477 wireless [ath] missed beacon / soft reset in STA mode results i o kern/178470 wireless [panic][ath] bss vap can and does change o kern/178411 wireless [ral] [panic] FreeBSD kernel crash in rt2860 o kern/178379 wireless [net80211] [ath] WPA rekey on the STA side fails when o kern/178378 wireless [net80211] crypto state isn't reset during a reassocia o kern/178263 wireless [ath] review the use of ic_freq / ic_ieee / ic_flags / o kern/177847 wireless [ath] With TPC enabled, TX power values aren't clamped o kern/177846 wireless [ath] [net80211] net80211 TX power limit isn't correct o conf/177688 wireless WiFi regodmains information is inconsistent between e o kern/177530 wireless [ath] ath driver isn't 32 bit int clean o kern/177465 wireless [iwn] 20%-100% packet loss with iwn driver o kern/177451 wireless [ieee80211] page fault in ieee80211_tx_mgt_timeout o kern/176238 wireless [ath] [patch] Correct buffer size calculation and simp o kern/176201 wireless [net80211] [patch] 11n station includes unrelated ht p o kern/176104 wireless [iwn] iwn0: iwn_intr: fatal firmware error o kern/175722 wireless [ath]lot of bad seriesx hwrate in kernel messages o kern/175446 wireless [ath] high volumes of PHY errors lead to BB/MAC hangs o kern/175227 wireless [ath] beacon timers aren't necessarily reprogrammed af o kern/175183 wireless [iwn] iwn(4) becomes unresponsive during initial confi o kern/175053 wireless [iwn] iwn firmware error on 9-stable with Ultimate-N 6 o kern/174891 wireless [ieee80211] struct ieee80211_node is freed during acti o kern/174722 wireless [wlan] can't use channel 12 and 13 (14) with my wifi i o kern/174661 wireless [wlan] lost alias on wlan interface o kern/174283 wireless [net80211] panics in ieee80211_ff_age() and ieee80211_ o kern/174276 wireless [ath] if_ath memory modified after free o kern/174273 wireless [net80211] taking down a net80211 node with active fas o kern/173917 wireless [iwn] wpa-supplicant issues on iwn o kern/173898 wireless [iwn] [patch] iwn(4) DOES support 6235 chip. o kern/173883 wireless [ath] ath0: unable to attach - pci issue? o kern/173711 wireless [ath] powerd kills ath on the Asus EeePC 1005HA o kern/173342 wireless PS-Poll isn't working o kern/173336 wireless [ath] Atheros card improper device poweroff handling o o kern/172955 wireless [ath] 11n does not work in adhoc mode o kern/172706 wireless [wpi] wpi0 fails to load firmware when using country o kern/172672 wireless [ubt] Bluetooth device recognised but not working o kern/172661 wireless hostapd(8) securing wireless adapter in HostAP mode is o kern/172338 wireless [ath] [net80211] CCMP IV transmit counters are not cor o kern/171598 wireless [ath] TP-Link TL-WN951N W-LAN PCI Adapter 300 MBit stu o kern/171235 wireless [ath] ath loses connection, system freezes on netif re o kern/170889 wireless [ath] ath driver uses some uninitilized memory o kern/170620 wireless [ath] LOR and deadlock when multiple vaps are used o
WDS and WPA
Greetings!
Over the weekend I attempted to extend my existing wireless network
(an AP running FreeBSD with an ath card (AR5212) and WPA-PSK) using
DWDS without much success.
I followed the scripts in tools/tools/net80211/scripts/ but never saw
anything about DWDS show up in the logs (with wlandebug
state+scan+assoc+auth+wds+11n) on the main AP -- just the normal
association messages when the relay node connects.
The additional nodes have very similar hardware (ath cards) and all
are running recent 10-stable i386 builds.
So my first question is whether DWDS is supposed to work at all in
combination with WPA? (I have not yet tried it without auth/privacy.)
I'm also not sure I understand the intended topology in the scripts
setup.wds{main,relay}. In that scenario, would normal clients only
connect directly to the relays? Can multiple relays use the exact
same config such as in setup.wdsrelay or should they present unique
SSIDs? (I thought the point of WDS was to use the same SSID for
seamless roaming between APs.)
Can relays be chained or does each need to associate directly with the
main AP? Does each relay perform need to perform its own
authentication for client stations or is that supposed to get handed
over to the main AP?
thanks!
Steven.
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: WDS and WPA
Hi,
I've not played with DWDS at all, I'm sorry. I was hoping that someone
else would sit down and make all of that work better. I have no idea
how it is supposed to sit down and work.
Sorry!
-a
On 9 December 2013 06:14, Steven Lawrance s...@koffein.net wrote:
Greetings!
Over the weekend I attempted to extend my existing wireless network
(an AP running FreeBSD with an ath card (AR5212) and WPA-PSK) using
DWDS without much success.
I followed the scripts in tools/tools/net80211/scripts/ but never saw
anything about DWDS show up in the logs (with wlandebug
state+scan+assoc+auth+wds+11n) on the main AP -- just the normal
association messages when the relay node connects.
The additional nodes have very similar hardware (ath cards) and all
are running recent 10-stable i386 builds.
So my first question is whether DWDS is supposed to work at all in
combination with WPA? (I have not yet tried it without auth/privacy.)
I'm also not sure I understand the intended topology in the scripts
setup.wds{main,relay}. In that scenario, would normal clients only
connect directly to the relays? Can multiple relays use the exact
same config such as in setup.wdsrelay or should they present unique
SSIDs? (I thought the point of WDS was to use the same SSID for
seamless roaming between APs.)
Can relays be chained or does each need to associate directly with the
main AP? Does each relay perform need to perform its own
authentication for client stations or is that supposed to get handed
over to the main AP?
thanks!
Steven.
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: [iwn] 6235 support, initial patch
Oh wait, I'm still using 17.x firmware? Let me fix that. I must not have committed it. -a On 9 December 2013 01:03, Alexander Motin m...@freebsd.org wrote: Hi. On 07.12.2013 22:21, Adrian Chadd wrote: Here's some fixes from mav, shoehorned into the current driver framework. Mav - where'd you get your changes from? It was long ago. I would guess that from you. :) http://people.freebsd.org/~adrian/iwn/20131207-iwn-6235-1.diff This enables the 6235. It now doesn't firmware panic upon startup. I've passed _no_ traffic through it though - I don't have pigtails for the connectors on my NIC. Sorry :( I've added in mav's changes but I've done it by adding a new 6235 config / limits section rather than hacking up the existing 6000g2b section. I don't know what effect it'll have on the existing NICs. So I didn't want to change that behaviour. This is against the latest -HEAD. I've updated to the latest HEAD including only your patch and immediately got firmware crash during boot: firmware: 'iwn6000g2bfw' version 0: 460912 bytes loaded at 0x81a120c0 iwn0: iwn_intr: fatal firmware error firmware error log: error type = UNKNOWN (0x19B6) program counter = 0x00014DD0 source line = 0x02E2 error data = 0x0001008C branch link = 0x00014DC200014DC2 interrupt link = 0xCFE2 time= 26892 driver status: tx ring 0: qid=0 cur=0 queued=0 tx ring 1: qid=1 cur=0 queued=0 tx ring 2: qid=2 cur=0 queued=0 tx ring 3: qid=3 cur=0 queued=0 tx ring 4: qid=4 cur=0 queued=0 tx ring 5: qid=5 cur=0 queued=0 tx ring 6: qid=6 cur=0 queued=0 tx ring 7: qid=7 cur=0 queued=0 tx ring 8: qid=8 cur=0 queued=0 tx ring 9: qid=9 cur=2 queued=0 tx ring 10: qid=10 cur=0 queued=0 tx ring 11: qid=11 cur=0 queued=0 tx ring 12: qid=12 cur=0 queued=0 tx ring 13: qid=13 cur=0 queued=0 tx ring 14: qid=14 cur=0 queued=0 tx ring 15: qid=15 cur=0 queued=0 tx ring 16: qid=16 cur=0 queued=0 tx ring 17: qid=17 cur=0 queued=0 tx ring 18: qid=18 cur=0 queued=0 tx ring 19: qid=19 cur=0 queued=0 rx ring: cur=2 iwn0: iwn5000_post_alive: crystal calibration failed, error 35 iwn0: iwn_init_locked: could not initialize hardware, error 35 firmware: 'iwn6000g2bfw' version 0: 460912 bytes loaded at 0x81a120c0 iwn0: iwn_intr: fatal firmware error firmware error log: error type = UNKNOWN (0x19B6) program counter = 0x00014DD0 source line = 0x02E2 error data = 0x0001008C branch link = 0x00014DC200014DC2 interrupt link = 0xCFE2 time= 26907 driver status: tx ring 0: qid=0 cur=0 queued=0 tx ring 1: qid=1 cur=0 queued=0 tx ring 2: qid=2 cur=0 queued=0 tx ring 3: qid=3 cur=0 queued=0 tx ring 4: qid=4 cur=0 queued=0 tx ring 5: qid=5 cur=0 queued=0 tx ring 6: qid=6 cur=0 queued=0 tx ring 7: qid=7 cur=0 queued=0 tx ring 8: qid=8 cur=0 queued=0 tx ring 9: qid=9 cur=2 queued=0 tx ring 10: qid=10 cur=0 queued=0 tx ring 11: qid=11 cur=0 queued=0 tx ring 12: qid=12 cur=0 queued=0 tx ring 13: qid=13 cur=0 queued=0 tx ring 14: qid=14 cur=0 queued=0 tx ring 15: qid=15 cur=0 queued=0 tx ring 16: qid=16 cur=0 queued=0 tx ring 17: qid=17 cur=0 queued=0 tx ring 18: qid=18 cur=0 queued=0 tx ring 19: qid=19 cur=0 queued=0 rx ring: cur=2 iwn0: iwn5000_post_alive: crystal calibration failed, error 35 iwn0: iwn_init_locked: could not initialize hardware, error 35 Adding usual -ht40 option didn't change anything. Then I switched from default 6000g2b firmware 17.168.5.2 to 18.168.6.1, which I was using before. With -ht40 flag am able to connect and write this letter. Without the flag card can't associate with AP: Dec 9 10:43:37 mavbook wpa_supplicant[467]: wlan0: Authentication with 56:04:a6:d3:65:30 timed out. Dec 9 10:43:37 mavbook wpa_supplicant[467]: wlan0: CTRL-EVENT-DISCONNECTED bssid=56:04:a6:d3:65:30 reason=3 locally_generated=1 Dec 9 10:43:41 mavbook wpa_supplicant[467]: wlan0: Trying to associate with 56:04:a6:d3:65:30 (SSID='mavhome5' freq=5180 MHz) Dec 9 10:43:41 mavbook wpa_supplicant[467]: wlan0: Associated with 56:04:a6:d3:65:30 Dec 9 10:43:41 mavbook kernel: wlan0: link state changed to UP Dec 9 10:43:41 mavbook dhclient[1313]: send_packet: No buffer space available Dec 9 10:43:42 mavbook wpa_supplicant[467]: wlan0: CTRL-EVENT-DISCONNECTED bssid=56:04:a6:d3:65:30 reason=0 Dec 9 10:43:42 mavbook kernel: wlan0: link state changed to DOWN Dec 9 10:43:45 mavbook dhclient[1313]: send_packet: Invalid argument Dec 9 10:43:47 mavbook wpa_supplicant[467]: wlan0: Trying to associate with 56:04:a6:d3:65:30 (SSID='mavhome5' freq=5180 MHz) Dec 9 10:43:55 mavbook dhclient[1313]: send_packet: Network is down Dec
Link aggregation over wired/wireless with different networks
Per http://www.freebsd.org/doc/handbook/network-aggregation.html I'm considering setting up link aggregation between my laptop's wired and wireless interfaces. What I don't understand is how link aggregation works when the subnets for the wired and wireless interfaces are different. Both my corporate and home networks tree wireless as it's own separate network from wired. How does the link aggregation code mitigate (if at all) the difference? What about a difference in DNS servers? Any/all information you folks might have would be helpful :) Cheers - R. Tyler Croy -- Code: https://github.com/rtyler Chatter: https://twitter.com/agentdero rty...@jabber.org pgpbDpYBuQRMe.pgp Description: PGP signature
Re: Link aggregation over wired/wireless with different networks
Hi, They can't be separate L2 domains. So no, you can't link aggregate in that situation. Yes, we don't have a way of doing seamless failover between multiple different L2 domains. I'm sure many people would like that. -a ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Transitioning between multiple APs with iwn(4)
I've been experimenting today with using my iwn(4) (PRO/Wireless 5100 AGN [Shiloh]) based wireless card, moving around the office. Overall we probably have 30 APs floating around, all broadcasting the same essid, which uses WPA2 with TKIP/PEAP. I find that my wlan0 device falls into a no-carrier status when I move too far away from the AP I origianlly connected too. I'm wondering if there's something specific with wpa_supplicant that needs to be done to maintain connections, or if the wireless driver itself is not properly identifying duplicate AP names and switching when I move around. Any suggestions for improving my in-office wireless experience? Cheers - R. Tyler Croy -- Code: https://github.com/rtyler Chatter: https://twitter.com/agentdero rty...@jabber.org pgpx4QZ7Wwsmy.pgp Description: PGP signature
Re: Transitioning between multiple APs with iwn(4)
Unfortunately our WPA supplicant isn't doing pre auth or implementing the roaming logic fully. It would be nice for someone to fill in that gap. adrian On Dec 9, 2013 2:00 PM, R. Tyler Croy ty...@monkeypox.org wrote: I've been experimenting today with using my iwn(4) (PRO/Wireless 5100 AGN [Shiloh]) based wireless card, moving around the office. Overall we probably have 30 APs floating around, all broadcasting the same essid, which uses WPA2 with TKIP/PEAP. I find that my wlan0 device falls into a no-carrier status when I move too far away from the AP I origianlly connected too. I'm wondering if there's something specific with wpa_supplicant that needs to be done to maintain connections, or if the wireless driver itself is not properly identifying duplicate AP names and switching when I move around. Any suggestions for improving my in-office wireless experience? Cheers - R. Tyler Croy -- Code: https://github.com/rtyler Chatter: https://twitter.com/agentdero rty...@jabber.org ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: kern/184626: [wlan] wlan0 missing some ifmib(4) data
Old Synopsis: wlan0 missing some ifmib(4) data New Synopsis: [wlan] wlan0 missing some ifmib(4) data Responsible-Changed-From-To: freebsd-bugs-freebsd-wireless Responsible-Changed-By: linimon Responsible-Changed-When: Tue Dec 10 02:04:28 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=184626 ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
