Re: kern/175870: [iwn] /etc/rc.d/netif restart cause system crash
The following reply was made to PR kern/175870; it has been noted by GNATS. From: hiren panchasara To: bug-follo...@freebsd.org, giep...@gmail.com Cc: Subject: Re: kern/175870: [iwn] /etc/rc.d/netif restart cause system crash Date: Tue, 19 Mar 2013 06:47:43 -0700 Did you get a coredump on crash? Can you share that if you did? I could not reproduce it on CURRENT on my T420 with Centrino Advanced-N 6205. cheers, Hiren ___ 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/175870: [iwn] /etc/rc.d/netif restart cause system crash
The following reply was made to PR kern/175870; it has been noted by GNATS. From: hiren panchasara To: bug-follo...@freebsd.org, giep...@gmail.com Cc: Subject: Re: kern/175870: [iwn] /etc/rc.d/netif restart cause system crash Date: Wed, 10 Apr 2013 10:11:03 -0700 Talked to the submitter offline and it seems that his virtualbox was causing these issues. After removing following entries from rc.conf, the issue disappears. vboxdrv_enable=YES vboxnet_enable=YES We should close this bug. Chiang: If you wish, you can open a bug for virtualbox port with all relevant details. Thanks, Hiren ___ 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/176104: [iwn] iwn0: iwn_intr: fatal firmware error
The following reply was made to PR kern/176104; it has been noted by GNATS. From: hiren panchasara To: bug-follo...@freebsd.org, me...@bristol.ac.uk Cc: Subject: Re: kern/176104: [iwn] iwn0: iwn_intr: fatal firmware error Date: Mon, 24 Jun 2013 11:09:18 -0700 Assuming you have 4965 chipset, this seems to be some weird firmware error. I see many users (including linux) reporting similar issues but could not find any definitive solution. At most you can try getting the latest firmware for your chipset and try it out. Probably from http://wireless.kernel.org/en/users/Drivers/iwlegacy Good luck, Hiren ___ 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/176104: [iwn] iwn0: iwn_intr: fatal firmware error
The following reply was made to PR kern/176104; it has been noted by GNATS. From: hiren panchasara To: mexas Cc: bug-follo...@freebsd.org Subject: Re: kern/176104: [iwn] iwn0: iwn_intr: fatal firmware error Date: Tue, 25 Jun 2013 08:52:43 -0700 On Tue, Jun 25, 2013 at 4:48 AM, Anton Shterenlikht wrote: > From hiren.panchas...@gmail.com Mon Jun 24 19:31:55 2013 > > Assuming you have 4965 chipset, > > yes, I do: > > iwn0@pci0:3:0:0:class=0x028000 card=0x11108086 chip=0x42308086 > rev=0x61 hdr=0x00 > vendor = 'Intel Corporation' > device = 'PRO/Wireless 4965 AG or AGN [Kedron] Network Connection' > class = network > > iwn0: mem 0xdf2fe000-0xdf2f irq 17 at > device 0.0 on pci3 > > and I have: > > device iwn # Intel 4965/1000/5000/6000 wireless NICs. > device iwn4965fw > > in the kernel config. > > this seems to be some weird firmware > error. I see many users (including linux) reporting similar issues > but > could not find any definitive solution. > > At most you can try getting the latest firmware for your chipset and > try it out. > Probably from http://wireless.kernel.org/en/users/Drivers/iwlegacy > > # cat /usr/src/sys/modules/iwnfw/iwn4965/Makefile > # $FreeBSD: head/sys/modules/iwnfw/iwn4965/Makefile 201209 2009-12-29 > 19:47:34Z rpaulo $ > > KMOD= iwn4965fw > IMG=iwlwifi-4965-228.61.2.24 > > .include > # > > According to your link, this is the latest version. > However, there is a question mark (?) against it. > I don't know what it means, perhaps that they are > not sure if it works correctly. > I wonder if an earlier version should be used instead? Yeah, no harm in trying. :-) cheers, Hiren > > Thanks > > Anton > > ___ 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/176104: [iwn] iwn0: iwn_intr: fatal firmware error
On Wed, Jun 26, 2013 at 7:10 PM, Anton Shterenlikht wrote: > The following reply was made to PR kern/176104; it has been noted by GNATS. > > From: Anton Shterenlikht > To: bug-follo...@freebsd.org > Cc: > Subject: RE: kern/176104: [iwn] iwn0: iwn_intr: fatal firmware error > Date: Tue, 25 Jun 2013 14:28:51 +0100 (BST) > > One thing I noticed is that this problem occurs > more often when running on battery, and less > frequently when running from mains. Could this > be related to some energy saving code? AFAIK, no. Hiren > ___ > 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: kern/180094: [iwn] Incorrect id for Intel Centrino Wireless-N 130
The following reply was made to PR kern/180094; it has been noted by GNATS.
From: hiren panchasara
To: Cedric
Cc: freebsd-gnats-sub...@freebsd.org
Subject: Re: kern/180094: [iwn] Incorrect id for Intel Centrino Wireless-N 130
Date: Sat, 29 Jun 2013 11:00:59 -0700
On Sat, Jun 29, 2013 at 8:52 AM, Cedric wrote:
>
>>Number: 180094
>>Category: kern
>>Synopsis: [iwn] Incorrect id for Intel Centrino Wireless-N 130
>>Confidential: no
>>Severity: non-critical
>>Priority: low
>>Responsible:freebsd-bugs
>>State: open
>>Quarter:
>>Keywords:
>>Date-Required:
>>Class: sw-bug
>>Submitter-Id: current-users
>>Arrival-Date: Sat Jun 29 16:00:00 UTC 2013
>>Closed-Date:
>>Last-Modified:
>>Originator: Cedric
>>Release:9.1-release-p4
>>Organization:
>>Environment:
> FreeBSD Test.RP614v4 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0 r252335: Fri
> Jun 28 19:04:30 CEST 2013
> root@Test.RP614v4:/usr/obj/amd64.amd64/usr/src/sys/GENERIC amd64
>>Description:
> iwn_ident_table indicate a wrong id for Intel Centrino Wireless-N 130.
>
> In /head/sys/dev/iwn/if_iwn.c :
> { 0x8086, 0x0887, "Intel Centrino Wireless-N 130" }
>
> 0x0887 is wrong. Must be 0x0897.
> Cf. : http://pci-ids.ucw.cz/read/PC/8086
Looks correct.
Will patch it.
Thanks,
Hiren
>
>
>>How-To-Repeat:
>
>>Fix:
>
>
>>Release-Note:
>>Audit-Trail:
>>Unformatted:
> ___
> freebsd-b...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
> To unsubscribe, send any mail to "freebsd-bugs-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: CFT: wpa_supplicant/hostapd import patch
After this change I've started getting following messages:
flymockour-l7% grep rekeying /var/log/messages | less
Jul 6 12:09:52 flymockour-l7 wpa_supplicant[1153]: wlan0: WPA: Group
rekeying completed with 00:24:b2:50:7c:38 [GTK=TKIP]
Jul 6 12:19:52 flymockour-l7 wpa_supplicant[1153]: wlan0: WPA: Group
rekeying completed with 00:24:b2:50:7c:38 [GTK=TKIP]
Jul 6 12:29:52 flymockour-l7 wpa_supplicant[1153]: wlan0: WPA: Group
rekeying completed with 00:24:b2:50:7c:38 [GTK=TKIP]
Jul 6 12:39:50 flymockour-l7 wpa_supplicant[1153]: wlan0: WPA: Group
rekeying completed with 00:24:b2:50:7c:38 [GTK=TKIP]
so, every 10 mins I am getting these messages.
I am not sure if this (rekeying) is something wpa2 is enforcing. Is
anyone else getting such messages?
Does it make sense to move this message from MSG_INFO to MSG_DEBUG?
cheers,
Hiren
flymockour-l7% svn diff
Index: contrib/wpa/src/rsn_supp/wpa.c
===
--- contrib/wpa/src/rsn_supp/wpa.c (revision 252757)
+++ contrib/wpa/src/rsn_supp/wpa.c (working copy)
@@ -1348,7 +1348,7 @@
goto failed;
if (rekey) {
- wpa_msg(sm->ctx->msg_ctx, MSG_INFO, "WPA: Group rekeying "
+ wpa_msg(sm->ctx->msg_ctx, MSG_DEBUG, "WPA: Group rekeying "
"completed with " MACSTR " [GTK=%s]",
MAC2STR(sm->bssid), wpa_cipher_txt(sm->group_cipher));
wpa_sm_cancel_auth_timeout(sm);
___
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: CFT: wpa_supplicant/hostapd import patch
On Sun, Jul 7, 2013 at 7:16 AM, Adrian Chadd wrote: > > Yup, commit away! > > > > -adrian > > > Feel free to commit this. > > -- > Rui Paulo Will commit it. Thanks, Hiren > > ___ > 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"
ath0 "monitor mode" mystery
I am trying to enable (what I think is) monitor mode on PicoStation M2HP. I am confused though. "man ifconfig" is also showing 2 different "monitor" things. I tried both below: # ifconfig wlan0 create wlandev ath0 wlan0: Ethernet address: dc:9f:db:6a:3e:9e # ifconfig wlan0 down # ifconfig wlan0 monitor # ifconfig wlan0 channel 4 # ifconfig wlan0 up # # ifconfig wlan0 wlan0: flags=48843 metric 0 mtu 1500 ether dc:9f:db:6a:3e:9e media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier ssid "" channel 4 (2427 MHz 11g) regdomain FCC3 country US indoor ecm authmode OPEN privacy OFF txpower 30 bmiss 7 scanvalid 60 protmode CTS wme burst bintval 0 # And now I get things via: # tcpdump -ni wlan0 -y IEEE802_11_RADIO wlan0: promiscuous mode enabled wlan0: promiscuous mode disabled wlan0: promiscuous mode enabled tcpdump: data link type IEEE802_11_RADIO tcpdump: WARNING: wlan0: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on wlan0, link-type IEEE802_11_RADIO (802.11 plus radiotap header), capture size 65535 bytes 18:56:23.803065 9838362989us tsft 1.0 Mb/s 60dBm tx power antenna 0 2427 MHz 11g Probe Request () [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit] 18:56:23.994159 9838553735us tsft 1.0 Mb/s -75dB signal -96dB noise antenna 1 2427 MHz 11g Probe Request () [1.0 2.0 5.5 11.0 6.0 9.0 12.0 18.0 Mbit] 18:56:23.995089 9838554678us tsft 1.0 Mb/s -75dB signal -96dB noise antenna 1 2427 MHz 11g Probe Request (Y!Office) [1.0 2.0 5.5 11.0 6.0 9.0 12.0 18.0 Mbit] 18:56:23.995979 983875us tsft 1.0 Mb/s -75dB signal -96dB noise antenna 1 2427 MHz 11g Probe Request () [1.0 2.0 5.5 11.0 6.0 9.0 12.0 18.0 Mbit] 18:56:24.002484 9838562077us tsft 1.0 Mb/s -76dB signal -96dB noise antenna 1 2427 MHz 11g Probe Request () [1.0 2.0 5.5 11.0 6.0 9.0 12.0 18.0 Mbit] 18:56:24.016082 9838576006us tsft 1.0 Mb/s 60dBm tx power antenna 0 2427 MHz 11g ht/40+ Probe Request () [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit] But is this really a monitor mode? Not according to tcpdump. What we are seeing above are beacons sent out by APs? How do we get probe requests sent to APs by devices? man tcpdump says: -I Put the interface in "monitor mode"; this is supported only on IEEE 802.11 Wi-Fi interfaces, and supported only on some operat- ing systems. Note that in monitor mode the adapter might disassociate from the network with which it's associated, so that you will not be able to use any wireless networks with that adapter. This could prevent accessing files on a network server, or resolving host names or network addresses, if you are capturing in monitor mode and are not connected to another network with another adapter. This flag will affect the output of the -L flag. If -I isn't specified, only those link-layer types available when not in monitor mode will be shown; if -I is specified, only those link- layer types available when in monitor mode will be shown. So I tried -I, # tcpdump -Ii wlan0 -y IEEE802_11_RADIO tcpdump: wlan0 is not a monitor mode VAP To create a new monitor mode VAP use: ifconfig wlan1 create wlandev ath0 wlanmode monitor and use wlan1 as the tcpdump interface # Okay, lets create wlan1 as suggested: # ifconfig wlan1 create wlandev ath0 wlanmode monitor wlan1: Ethernet address: dc:9f:db:6a:3e:9e # ifconfig wlan1 wlan1: flags=8802 metric 0 mtu 1500 ether dc:9f:db:6a:3e:9e media: IEEE 802.11 Wireless Ethernet autoselect (autoselect ) status: no carrier ssid "" channel 4 (2427 MHz 11g) regdomain FCC3 country US indoor ecm authmode OPEN privacy OFF txpower 30 scanvalid 60 protmode CTS wme burst bintval 0 # See subtle difference between wlan0 and wlan1. Still no success (but new error): # tcpdump -Ii wlan1 -y IEEE802_11_RADIO wlan1: promiscuous mode enabled tcpdump: data link type IEEE802_11_RADIO tcpdump: WARNING: wlan1: no IPv4 address assigned ar5416StopDmaReceive: dma failed to stop in 10ms AR_CR=0x0024 AR_DIAG_SW=0x4220 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on wlan1, link-type IEEE802_11_RADIO (802.11 plus radiotap header), capture size 65535 bytes ar5416StopDmaReceive: dma failed to stop in 10ms AR_CR=0x0024 AR_DIAG_SW=0x4220 ar5416StopDmaReceive: dma failed to stop in 10ms AR_CR=0x0024 AR_DIAG_SW=0x4220 ar5416StopDmaReceive: dma failed to stop in 10ms AR_CR=0x0024 AR_DIAG_SW=0x4220 ar5416StopDmaReceive: dma failed to stop in 10ms AR_CR=0x0024 AR_DIAG_SW=0x4220 ar5416StopDmaReceive: dma failed to stop in 10ms AR_CR=0x0024 AR_DIAG_SW=0x4220 ar5416StopDmaReceive: dma failed to stop in 10ms AR_CR=0x0024 AR_DIAG_SW=0x4220 ar5416StopDmaRece
Re: ath0 "monitor mode" mystery
On Mon, Sep 23, 2013 at 5:14 AM, Mark Moes wrote: > > 18:56:23.803065 9838362989us tsft 1.0 Mb/s 60dBm tx power antenna 0 2427 > > MHz 11g Probe Request () [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit] > > That's what you're gonna see if it captures 802.11 frames; you already had > it working :) > I think you are right :-) I got confused with the tcpdump terminology. Just to conclude, for me, specifying flag MONITOR mode worked. But creating monitor mode vap did not. > > And a Probe Request is not a Beacon frame, it is sent by a device > (laptop/smartphone) when it actively scans for APs. See > http://www.wi-fiplanet.com/tutorials/print.php/1447501 > Thanks a lot! Cheers, Hiren ___ 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] my first attempt at porting cedric's hardware update patches over
On Tue, Nov 5, 2013 at 5:15 PM, Adrian Chadd wrote: > Hi, > > So: > > http://people.freebsd.org/~adrian/iwn/20131105-iwn-update-works-full-5100-5.diff > I'd appreciate some testing of this. It's against -HEAD, so yes, > you'll have to run -HEAD. Seems to be doing alright on my Centrino Advanced-N 6205. I will report back if things go sideways. Thank you for your work, Hiren ___ 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] Cedric's stuff is in -HEAD
On Mon, Nov 11, 2013 at 10:21 PM, Adrian Chadd wrote: > Hi, > > I've just committed Cedric's stuff to -HEAD. I also fixed the MRR stuff to > work. With latest everything + http://people.freebsd.org/~adrian/iwn/2013-iwn-linkq-2stream-ant-fix-1.diff flymockour-l7% sysctl dev.iwn.0 dev.iwn.0.%desc: Intel Centrino Advanced-N 6205 dev.iwn.0.%driver: iwn dev.iwn.0.%location: slot=0 function=0 dev.iwn.0.%pnpinfo: vendor=0x8086 device=0x0085 subvendor=0x8086 subdevice=0x1311 class=0x028000 dev.iwn.0.%parent: pci3 dev.iwn.0.debug: 1 It stayed up for good 15 mins and then I saw this: Nov 12 10:25:47 flymockour-l7 kernel: iwn5000_tx_done: qid 0 idx 114 retries 0 nkill 0 rate 8000e10d duration 139 status 201 Nov 12 10:25:48 flymockour-l7 kernel: iwn_tx_rate_to_linkq_offset: idx 0: nr=16, rate=0x8d, rateentry=0x8f Nov 12 10:25:48 flymockour-l7 kernel: iwn_tx_rate_to_linkq_offset: idx 1: nr=16, rate=0x8d, rateentry=0x8e Nov 12 10:25:48 flymockour-l7 kernel: iwn_tx_rate_to_linkq_offset: idx 2: nr=16, rate=0x8d, rateentry=0x8d Nov 12 10:25:48 flymockour-l7 kernel: iwn_tx_data: qid 0 idx 115 len 108 nsegs 2 rate 008d plcp 0xe10d Nov 12 10:25:48 flymockour-l7 kernel: iwn5000_tx_done: qid 0 idx 115 retries 0 nkill 0 rate 8000e10d duration 139 status 201 Nov 12 10:25:49 flymockour-l7 kernel: iwn_tx_rate_to_linkq_offset: idx 0: nr=16, rate=0x8d, rateentry=0x8f Nov 12 10:25:49 flymockour-l7 kernel: iwn_tx_rate_to_linkq_offset: idx 1: nr=16, rate=0x8d, rateentry=0x8e Nov 12 10:25:49 flymockour-l7 kernel: iwn_tx_rate_to_linkq_offset: idx 2: nr=16, rate=0x8d, rateentry=0x8d Nov 12 10:25:49 flymockour-l7 kernel: iwn_tx_data: qid 0 idx 116 len 0 nsegs 0 rate 008d plcp 0xe10d Nov 12 10:25:49 flymockour-l7 kernel: iwn5000_tx_done: qid 0 idx 116 retries 0 nkill 0 rate 8000e10d duration 132 status 201 Nov 12 10:25:49 flymockour-l7 kernel: iwn_notif_intr: scanning channel 1 status 1 Nov 12 10:25:49 flymockour-l7 kernel: iwn_notif_intr: scanning channel 6 status 1 Nov 12 10:25:49 flymockour-l7 kernel: iwn_notif_intr: scanning channel 11 status 1 Nov 12 10:25:49 flymockour-l7 kernel: iwn_notif_intr: scanning channel 7 status 1 Nov 12 10:25:49 flymockour-l7 kernel: iwn_notif_intr: scanning channel 13 status 1 Nov 12 10:25:49 flymockour-l7 kernel: iwn_tx_rate_to_linkq_offset: idx 0: nr=16, rate=0x8d, rateentry=0x8f Nov 12 10:25:49 flymockour-l7 kernel: iwn_tx_rate_to_linkq_offset: idx 1: nr=16, rate=0x8d, rateentry=0x8e Nov 12 10:25:49 flymockour-l7 kernel: iwn_tx_rate_to_linkq_offset: idx 2: nr=16, rate=0x8d, rateentry=0x8d Nov 12 10:25:49 flymockour-l7 kernel: iwn_tx_data: qid 0 idx 117 len 0 nsegs 0 rate 008d plcp 0xe10d Nov 12 10:25:49 flymockour-l7 kernel: iwn_tx_rate_to_linkq_offset: idx 0: nr=16, rate=0x8d, rateentry=0x8f Nov 12 10:25:49 flymockour-l7 kernel: iwn_tx_rate_to_linkq_offset: idx 1: nr=16, rate=0x8d, rateentry=0x8e Nov 12 10:25:49 flymockour-l7 kernel: iwn_tx_rate_to_linkq_offset: idx 2: nr=16, rate=0x8d, rateentry=0x8d Nov 12 10:25:49 flymockour-l7 kernel: iwn_tx_data: qid 0 idx 118 len 108 nsegs 2 rate 008d plcp 0xe10d Nov 12 10:25:49 flymockour-l7 kernel: iwn5000_tx_done: qid 0 idx 117 retries 0 nkill 0 rate 8000e10d duration 132 status 201 Nov 12 10:25:49 flymockour-l7 kernel: iwn5000_tx_done: qid 0 idx 118 retries 0 nkill 0 rate 8000e10d duration 139 status 201 Nov 12 10:25:50 flymockour-l7 kernel: iwn_notif_intr: scanning channel 13 status 1 Nov 12 10:25:50 flymockour-l7 kernel: received statistics without RSSI Nov 12 10:25:50 flymockour-l7 wpa_supplicant[8743]: wlan0: Trying to associate with 6c:f3:7f:4d:88:27 (SSID='Y!Office' freq=2437 MHz) Nov 12 10:25:50 flymockour-l7 kernel: iwn_tx_rate_to_linkq_offset: idx 0: nr=16, rate=0x8d, rateentry=0x8f Nov 12 10:25:50 flymockour-l7 kernel: iwn_tx_rate_to_linkq_offset: idx 1: nr=16, rate=0x8d, rateentry=0x8e Nov 12 10:25:50 flymockour-l7 kernel: iwn_tx_rate_to_linkq_offset: idx 2: nr=16, rate=0x8d, rateentry=0x8d Nov 12 10:25:50 flymockour-l7 kernel: iwn_tx_data: qid 0 idx 119 len 0 nsegs 0 rate 008d plcp 0xe10d Nov 12 10:25:50 flymockour-l7 kernel: iwn5000_tx_done: qid 0 idx 119 retries 0 nkill 0 rate 8000e10d duration 132 status 201 Nov 12 10:25:50 flymockour-l7 kernel: iwn_tx_rate_to_linkq_offset: idx 0: nr=16, rate=0x8d, rateentry=0x8f Nov 12 10:25:50 flymockour-l7 kernel: iwn_tx_rate_to_linkq_offset: idx 1: nr=16, rate=0x8d, rateentry=0x8e Nov 12 10:25:50 flymockour-l7 kernel: iwn_tx_rate_to_linkq_offset: idx 2: nr=16, rate=0x8d, rateentry=0x8d Nov 12 10:25:50 flymockour-l7 kernel: iwn_tx_data: qid 0 idx 120 len 0 nsegs 0 rate 008d plcp 0xe10d Nov 12 10:25:50 flymockour-l7 kernel: iwn5000_tx_done: qid 0 idx 120 retries 0 nkill 0 rate 8000e10d duration 132 status 201 Nov 12 10:25:50 flymockour-l7 kernel: wlan0: link state changed to DOWN Nov 12 10:25:50 flymockour-l7 wpa_supplicant[8743]: ioctl[SIOCS80211, op=20, val=0, arg_len=7]: Can't assign requested address Nov 12 10:25:50 flymockour-l7 wpa_supplicant[8743]: wlan0: CTRL-EVENT-DISC
Re: [iwn] Cedric's stuff is in -HEAD
On Tue, Nov 12, 2013 at 10:45 AM, Adrian Chadd wrote: > Run with wlandebug +assoc +state +debug +output +scan +crypto http://people.freebsd.org/~hiren/20131112_iwnfail_atwork.txt Thanks a bunch Adrian! ___ 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] Cedric's stuff is in -HEAD
On Tue, Nov 12, 2013 at 12:19 PM, Adrian Chadd wrote: > On 12 November 2013 11:13, hiren panchasara > wrote: >> On Tue, Nov 12, 2013 at 10:45 AM, Adrian Chadd wrote: >>> Run with wlandebug +assoc +state +debug +output +scan +crypto >> >> http://people.freebsd.org/~hiren/20131112_iwnfail_atwork.txt > > What's this showing? What was going on at this time? I keep pings going on another window just to see when it stops. It was doing alright (pings going through) and suddenly "stops working" around following lines in logs: Nov 12 10:59:51 flymockour-l7 kernel: wlan0: ieee80211_bg_scan: active scan, ticks 7165936 duration 150 Nov 12 10:59:51 flymockour-l7 kernel: wlan0: [6c:f3:7f:4d:88:47] send QoS null data frame on channel 1, pwr mgt ena and then it tries scanning and what not but never recovers. Funny (read annoying) thing is, its not failing in the same way every time it disconnects. I do not see the same pattern. And by "stops working" I see, it still has ip and ssid but "status: no carrier" in ifconfig. > >> Thanks a bunch Adrian! > > so, I have a feeling that for "best" iwn(4) behaviour, we should > likely extend net80211 to not do its own scan stuff (by putting the > VAP into power save mode whilst doing scanning) but just to fire off a > scan request. I _think_ iwn(4) will do it itself. > > We should however still fix the scan code to not be a racy, unpredictable > thing. I am not sure if I follow. Any more clues you can throw based on the logs? Thanks again, Hiren ___ 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: Cannot get wireless to work
On Fri, Jan 24, 2014 at 10:09 PM, Harshad D wrote: > hello! > > Hi all, first post here. > Installed FreeBSD for the first time on my laptop. Have followed the > Handbook and got most things like X, XFCE, X config etc working. > > However, I am really having trouble trying to get wireless working. I have > tried the following till now: > > This is an extract about the wireless hardware from [cmd]pciconf[/cmd]: > > vendor = 'Broadcom Corporation' > device = 'BCM4312 802.11b/g LP-PHY' > class = network > > > So, as per the Handbook, I should use the bwn (4) driver. > > i have done the following till now: > > > Installed [file]bwn-firmware-kmod[/file] from ports > Added the following to [file]/boot/loader.conf[/file] > if_bwn_load="YES" > bwn_v4__lp_ucode_load="YES" Is this just a typo in email? (the double underscores) Should be bwn_v4_lp_ucode_load="YES" Also, once you boot up, what do you see when you do "kldstat"? cheers, Hiren > # if_bwi_load="YES" > wlan_scan_ap_load="YES" >wlan_scan_sta_load="YES" >wlan_wep_load="YES" >wlan_ccmp_load="YES" >wlan_tkip_load="YES"[/code] > > added this to rc.conf > wlans_bwn0="wlan0" > ifconfig_wlan0="ssid HSD DHCP" > > I am not sure about the DHCP part here. just something I have tried. > > And tried all that's shown here [url] > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-wireless.html[/url] > . > > But still it doesn't work. ifconfig wlan0 up scan gives nothing: > root@BSDbox:~ # ifconfig wlan0 scan > root@BSDbox:~ # > > > dmesg output is: > > root@BSDbox:~ # dmesg|tail > bwn0: the fw file(bwn_v4_lp_ucode15) not found > bwn-open_v4_lp_ucode15: could not load firmware image, error 2 > bwn0: the fw file(bwn-open_v4_lp_ucode15) not found > ubt0: 2> on usbus0 > WARNING: attempt to domain_add(bluetooth) after domainfinalize() > WARNING: attempt to domain_add(netgraph) after domainfinalize() > bwn_v4_lp_ucode15: could not load firmware image, error 2 > bwn0: the fw file(bwn_v4_lp_ucode15) not found > bwn-open_v4_lp_ucode15: could not load firmware image, error 2 > bwn0: the fw file(bwn-open_v4_lp_ucode15) not found > > > ifconfig output: > > root@BSDbox:~ # ifconfig > bwn0: flags=8803 metric 0 mtu 2290 > ether 00:26:5e:46:3e:ba > nd6 options=29 > media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) > status: no carrier > re0: flags=8843 metric 0 mtu 1500 > options=8209b > ether 00:23:5a:c6:da:5b > inet6 fe80::223:5aff:fec6:da5b%re0 prefixlen 64 scopeid 0x2 > inet 192.168.0.104 netmask 0xff00 broadcast 192.168.0.255 > nd6 options=23 > media: Ethernet autoselect (100baseTX ) > status: active > lo0: flags=8049 metric 0 mtu 16384 > options=63 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 > inet 127.0.0.1 netmask 0xff00 > nd6 options=21 > wlan0: flags=8802 metric 0 mtu 1500 > ether 00:26:5e:46:3e:ba > nd6 options=29 > media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) > status: no carrier > ssid HSD channel 1 (2412 MHz 11b) > country US authmode WPA1+WPA2/802.11i privacy OFF txpower 30 bmiss 7 > scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 > roam:rate 1 wme bintval 0 > > > I can see that the firmware file is not being loaded. How do I get it to > load? I checked the /boot/firmware folder and it's empty. So I manually > copied.fw files from the bwn ports directory, but that didn't work either. > I tried renaming the module files (.ko) in /boot/modules to what the OS is > looking for, but that failed too. I am almost at my wit's end now, and > don't know how to go on from here. What do I need to do? > ___ > 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: FreeBSD 10.0: hostapd crash with Ralink 3070
On Mon, Jan 27, 2014 at 2:16 PM, Pedro Flynn wrote: > I can provide information as needed. Sharing lots of kernel debug messages that you are seeing might be a good start :-) cheers, Hiren ___ 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: CAMBRIA and more than one atheros card
On Mon, Jul 7, 2014 at 11:31 AM, Adrian Chadd wrote: > On 7 July 2014 11:28, John Hay wrote: >> On Mon, Jul 07, 2014 at 11:22:46AM -0700, Adrian Chadd wrote: >>> On 7 July 2014 10:12, Ian Lepore wrote: >>> > On Mon, 2014-07-07 at 09:25 -0700, Adrian Chadd wrote: >>> >> hi, >>> >> >>> >> That call is returning ENOMEM. I'm not sure why. It allocated an mbuf >>> >> fine, but it couldn't allocate the DMA map. >>> >> >>> >> What's the output of "vmstat -z" ? I wonder if it's failing an >>> >> allocation. >>> >> >>> >> >>> >> >>> >> -a >>> > >>> > Lack of bounce buffers is a posibility that won't show up in vmstat >>> > output. >>> >>> right, but there's a bunch of already failing vmstat entries. >>> >>> >>> John - there's a vmscale parameter somewhere. Hiren had to drop it >>> down for his APs to work in 64MB of RAM. I think it's >>> vm.kmem_size_scale . What's it say for you? >>> >> >> :~ # sysctl vm.kmem_size_scale >> vm.kmem_size_scale: 3 > > Ok. Search the archives for an email from Hiren titled "mbuf autotuning > effect". > > TL;DR - set it to 1 and recompile. There's a kernel option somewhere > to do exactly that. Yes. http://lists.freebsd.org/pipermail/freebsd-mips/2013-September/003081.html I went through this for my tplink. John, can you show o/p of: sysctl -a | grep hw | grep mem and sysctl -a | grep maxmbuf Cheers, Hiren ___ 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: CAMBRIA and more than one atheros card
On Tue, Jul 8, 2014 at 9:54 AM, John Hay wrote: > On Mon, Jul 07, 2014 at 12:43:17PM -0700, Adrian Chadd wrote: >> Sweet! >> >> Can you run the same commands above on the Avila board? > > :~ # uname -a > FreeBSD broken-2 11.0-CURRENT FreeBSD 11.0-CURRENT #74 r267954M: Fri Jun 27 > 14:40:34 SAST 2014 > j...@dolphin.meraka.csir.co.za:/usr/obj/arm.armeb/snaps/arm/11-tst/src/sys/SMALL-AVILA > arm > :~ # sysctl -a | grep hw | grep mem > hw.physmem: 61087744 > hw.usermem: 41558016 > hw.realmem: 67104768 > :~ # sysctl -a | grep maxmbuf > kern.ipc.maxmbufmem: 9934848 > > I'm still confused that the Avila with half the RAM does not exhibit the > same problem. Try to compare both KERNCONFs to see if you've anything special for Avila. (I assume that you are doing same things with both boards wrt your experimentation.) cheers, Hiren > >> >> Would you mind filing a PR to ensure we get that option into the >> relevant kernel(s) ? > > Sure, give me a day or two. > > John > ___ 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: Recommend Off the Shelf USB Wireless N - FreeBSD 9.3/10.0
On Tue, Aug 12, 2014 at 11:29 AM, Patrick Powell wrote: > Could anybody please please recommend a USB adapter for Wireless N that: > > a) works with the current set of drivers for FreeBSD 9.3-RELEASE or > 10.0-RELEASE I think Edimax EW-7811Un - http://www.amazon.com/Edimax-EW-7811Un-Adapter-Raspberry-Supports/dp/B003MTTJOY/ref=sr_1_1?ie=UTF8&qid=1407874904&sr=8-1&keywords=Edimax+EW-7811Un should work on 10.0-RELEASE. 'man 4 urtwn' for more details. [skip] > > I'll bet there are other folks besides myself who would be grateful for such > a posting. > > Also, this would be an opportunity to update the FreeBSD USB Adapter list. > If there are responses to this posting, I would suggest that a summary be > posted to one of the more general FreeBSD mailing lists. fwiw, http://www.freebsd.org/relnotes/CURRENT/hardware/support.html mentions urtwn and the chipset. cheers, Hiren ___ 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: FreeBSD wireless support is lacking; needs better documentation
On Aug 30, 2014 9:39 AM, "Dirk E" wrote: > > Hello guys, > > I wrote to the freebsd-wireless@ list on 12 August, looking for a working USB wireless adapter that can work on HOSTAP mode. There was no reply on my message and so far i have been unsuccessful in finding any device that works without some kind of limitation. > > The problems are: > > 1) FreeBSD supports only a limited range of wireless adapters, mostly older products that are not sold anymore or are hard to come by > > 2) FreeBSD has limitations on supported products, such as no working HOSTAP or no working 11n (only 11a/b/g) or no proper power-save features > > 3) FreeBSD lacks up-to-date information about actual supported products; many products have newer revisions which use different chipsets > > 4) Documentation is not complete; for example the urtwn manpage does not specify that HOSTAP is not supported under the CAVEATS section > > 5) Products are sold with different chipsets under the same name, products sold in the USA may work while the same product sold in the EU does not work > > 6) It is generally very hard to find out what chipset a product uses > > > I've been trying for weeks to find a working solution. I have given up on 11n support, i just want things to work. I got fed up after trying two devices which should be supported but didn't work in the end, so i bought a bunch of devices and hoped that one would work: > > Asus WL-167 (supported by rum driver; because of missing power-save in HOSTAP mode it only works with some clients; andriod phones for example don't seem to work; they can connect but not perform any IP traffic) > TP-LINK TL-WN822N (supported by urtwn, but despite manpage not mentioning this, HOSTAP mode is not supported; 11n not supported but documented) > TP-LINK TL-WN821N > TP-LINK TL-WN722N > TP-LINK TL-WN725N (should be supported by urtwn, but only the USA versions; the EU version appears not to be supported by this driver at all; not documented) > EnGenius EUB9707 (only device that actually works in HOSTAP mode; but without 11n support) > Dlink GO-USB-N150 > Eminent EM4579 (no info about this device) > > > It appears the lack of HOSTAP-mode in the urtwn-driver was known by OpenBSD, from which the driver was imported. So then, why is this information not shared with us by including it in the urtwn manpage? There is a patch for the OpenBSD driver to add HOSTAP mode for this driver; i am not sure whether it can be applied to FreeBSD. > Thanks for doing this detailed analysis of various issues. Whenever possible, please submit manpage update fixes via bugzilla. And I'll work with you to get them reviewed/committed. > Long story short; FreeBSD's wireless support is lacking. It's almost a complete mess. It takes many time and frustration for a user to get a working product that works decently with FreeBSD. And even then, it often works without features like 11n and proper power save features. It's one of the areas that FreeBSD is much behind in terms of hardware support compared to virtually every other operating system out there. That's a shame; FreeBSD would be an excellent wireless access point when paired with pf-firewall. > Yes. It needs a lot of love (work). > I propose the following: create a wiki with a list of known working wireless products. Each product should note which chipset it uses, what driver it connects to, what features are suported (i.e. HOSTAP), what FreeBSD versions are supported, whether it is open source / binary blob, any license requirements (like Realtek) and a dmesg snippet where the driver is detected. It can be managed by a maintainer that accepts email reports from users who provide the required information. That way, we get a list of hardware that is known to work with FreeBSD that people can actually buy. Even a NewEgg-link or something to that effect can be provided. > > This website was a lot of help to me in figuring out what chipset a wireless product uses: https://wikidevi.com/wiki/Main_Page > I propose something simpler for FreeBSD; just a single wiki page that lists products that either work or do not work. > > With very limited hardware support for wireless devices, such a list is needed very badly, to prevent other people from going through the same hellhound that i've gone through. If even just a handful of wireless devices that are still being sold are known to be working with FreeBSD, this list would be very helpful i would presume. > > Anyone who likes this idea? Yes. I like this idea. But more important thing is who is willing to drive this? If you are, I'll have you setup with a wiki account :) Thanks again for your interest and such diligence. Cheers, Hiren ___ 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"
