How to connect to a Wifi AP w/o much information from its provider
Hello, The school of my son offers Wifi to the pupil. The SSID is "Schueler" and each of the kids has a login and password assigned from the school. Not more information. An iPhone connects out of the box by just asking for the two values (login/password). With our wpa_supplicant I couldn't get how to set accepted values. I have here what the ifconfig command on my laptops says about the AP values: # ifconfig -v wlan0 list ap | egrep 'SSID/MESH|Schueler' Schueler 20:a6:cd:04:d8:636 54M -73:-96 100 EPS SSID RATES DSPARMS<6> TIM<05040001> ERP<0x0> RSN HTCAP HTINFO ???<7f0804000840> WME VEN Schueler 48:4a:e9:fd:dd:c31 54M -88:-96 100 EPS SSID RATES DSPARMS<1> ERP<0x0> RSN HTCAP HTINFO ???<7f0804000840> WME Schueler 20:a6:cd:04:d8:73 64 54M -68:-96 100 EP SSID RATES DSPARMS<64> TIM<05040001> RSN HTCAP HTINFO ???<7f0804000840> VHTCAP VHTOPMODE WME VEN Schueler e8:26:89:45:38:33 36 54M -91:-96 100 EP SSID RATES DSPARMS<36> TIM<05040001> RSN HTCAP HTINFO ???<7f0804000840> VHTCAP VHTOPMODE WME VEN Schueler 48:4a:e9:fd:dd:d3 124 54M -90:-96 100 EP SSID RATES DSPARMS<124> TIM<05040001> RSN HTCAP HTINFO ???<7f0804000840> VHTCAP VHTOPMODE WME VEN Schueler 48:4a:e9:6f:40:c3 11 54M -92:-96 100 EPS SSID RATES DSPARMS<11> ERP<0x0> RSN HTCAP HTINFO ???<7f0804000840> WME Schueler e8:26:89:45:38:231 54M -85:-96 100 EPS SSID RATES DSPARMS<1> ERP<0x0> RSN HTCAP HTINFO ???<7f0804000840> WME Schueler 48:4a:e9:6d:b8:c31 54M -91:-96 100 EPS SSID RATES DSPARMS<1> ERP<0x0> RSN HTCAP HTINFO ???<7f0804000840> WME Has someone an idea how to make a wpa_supplicant.conf entry for this SSID? Thanks matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub Без книги нет знания, без знания нет коммунизма (Влaдимир Ильич Ленин) Without books no knowledge - without knowledge no communism (Vladimir Ilyich Lenin) Sin libros no hay saber - sin saber no hay comunismo. (Vladimir Ilich Lenin) ___ freebsd-wireless@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: debugging a Wifi association problem
El día jueves, julio 18, 2019 a las 12:41:42p. m. +0200, Matthias Apitz escribió: > I compiled net/tcpdump to look into that and it supports: > > # /usr/local/sbin/tcpdump -ni wlan0 -y IEEE802_11_RADIO > > and the OpenBSD man page explains what IEEE802_11_RADIO is. I think, > ... This morning I captured the IEEE802_11_RADIO traffic with the above tcpdump cmd and used wireshark to filter out the trafic for the connecting phone. Details below. There are only "Probe Request" broadcasts or "Authentication" requests to the my AP (MAC addr 00:1c:4a:06:17:f5) from the phone, but the AP never answers. Only sometimes another AP (SSID=FRITZ!Box 7530) gives an answer which the phone ignores. Why the AP with MAC addr 00:1c:4a:06:17:f5 does not answer? Any ideas? matthias remarks to the capture file IEEE802_11_RADIO.out time of capture: 07:57:00 T+00 start of capture 07:57:10 T+10 Wifi enabled in phone (i.e. SSID tarara "green") 07:57:38 T+38 network manager asks again for psk 07:58:00 T+60 psk entered and pressed "connect" 07:58:30 T+90 network manager asks again for psk AP SSID: tarara, MAC: 00:1c:4a:06:17:f5 MAC addr of phone: 4c:74:03:65:46:a9 filter: wlan_radio contains 65:46:a9 1754 38.060131 Bq_65:46:a9 Broadcast 802.11 74 Probe Request, SN=3, FN=0, Flags=, SSID=Broadcast 1758 38.149385 Bq_65:46:a9 Broadcast 802.11 74 Probe Request, SN=10, FN=0, Flags=, SSID=Broadcast 1759 38.149399 Bq_65:46:a9 Broadcast 802.11 74 Probe Request, SN=11, FN=0, Flags=, SSID=Broadcast 1760 38.159666 98:9b:cb:0c:47:1a Bq_65:46:a9 802.11 455 Probe Response, SN=3623, FN=0, Flags=R..., BI=100, SSID=FRITZ!Box 7530 OK 1767 38.276541 Bq_65:46:a9 Broadcast 802.11 74 Probe Request, SN=20, FN=0, Flags=, SSID=Broadcast 1768 38.277267 Bq_65:46:a9 Broadcast 802.11 74 Probe Request, SN=21, FN=0, Flags=, SSID=Broadcast 1770 38.301422 Bq_65:46:a9 Broadcast 802.11 74 Probe Request, SN=22, FN=0, Flags=, SSID=Broadcast 1771 38.301433 Bq_65:46:a9 Broadcast 802.11 74 Probe Request, SN=23, FN=0, Flags=, SSID=Broadcast 1773 38.345753 Bq_65:46:a9 Broadcast 802.11 74 Probe Request, SN=24, FN=0, Flags=, SSID=Broadcast 1774 38.346243 Bq_65:46:a9 Broadcast 802.11 74 Probe Request, SN=25, FN=0, Flags=, SSID=Broadcast 1906 41.638487 Bq_65:46:a9 Avm_06:17:f5 802.11 62 Authentication, SN=26, FN=0, Flags=R... 1907 41.639535 Bq_65:46:a9 Avm_06:17:f5 802.11 62 Authentication, SN=26, FN=0, Flags=R... 1908 41.640593 Bq_65:46:a9 Avm_06:17:f5 802.11 62 Authentication, SN=26, FN=0, Flags=R... 1909 41.641950 Bq_65:46:a9 Avm_06:17:f5 802.11 62 Authentication, SN=26, FN=0, Flags=R... 1910 41.647066 Bq_65:46:a9 Avm_06:17:f5 802.11 62 Authentication, SN=26, FN=0, Flags=R... 1911 41.656295 Bq_65:46:a9 Avm_06:17:f5 802.11 62 Authentication, SN=26, FN=0, Flags=R... 1912 41.663298 Bq_65:46:a9 Avm_06:17:f5 802.11 62 Authentication, SN=26, FN=0, Flags=R... 1913 41.663832 Bq_65:46:a9 Avm_06:17:f5 802.11 62 Authentication, SN=27, FN=0, Flags= 1914 41.665392 Bq_65:46:a9 Avm_06:17:f5 802.11 62 Authentication, SN=27, FN=0, Flags=R... 1915 41.667056 Bq_65:46:a9 Avm_06:17:f5 802.11 62 Authentication, SN=27, FN=0, Flags=R... 1916 41.667621 Bq_65:46:a9 Avm_06:17:f5 802.11 62 Authentication, SN=27, FN=0, Flags=R... 1917 41.669059 Bq_65:46:a9 Avm_06:17:f5 802.11 62 Authentication, SN=27, FN=0, Flags=R... 1918 41.670645 Bq_65:46:a9 Avm_06:17:f5 802.11 62 Authentication, SN=27, FN=0, Flags=R... 1920 41.677283 Bq_65:46:a9 Avm_06:17:f5 802.11 62 Authentication, SN=27, FN=0, Flags=R... 1921 41.678070 Bq_65:46:a9 Avm_06:17:f5 802.11 62 Authentication, SN=28, FN=0, Flags= 1922 41.678655 Bq_65:46:a9 Avm_06:17:f5 802.11 62 Authentication, SN=28, FN=0, Flags=R... 1923 41.679609 Bq_65:46:a9 Avm_06:17:f5 802.11 62 Authentication, SN=28, FN=0, Flags=R... 1924 41.681081 Bq_65:46:a9 Avm_06:17:f5 802.11 6
Re: debugging a Wifi association problem
El día jueves, julio 18, 2019 a las 12:04:27p. m. +0200, Matthias Apitz escribió: > El día miércoles, julio 17, 2019 a las 11:45:49p. m. -0700, Adrian Chadd > escribió: > > > Hi! > > > > So, you don't set the monitor flag like you do on linux. you create a > > monitor VAP instead or you just use tcpdump with the right flags. > > > > Try: > > > > tcpdump -ni wlan0 -y IEEE802_11_PROTO > > > > That'll put the NIC into monitor mode on the current channel, even in > > station mode, and let you do normalt raffic as well as get promiscuous > > traffic into tcpdump. > > Thanks, but: > > root@c720-r342378:~ # uname -a > FreeBSD c720-r342378 13.0-CURRENT FreeBSD 13.0-CURRENT GENERIC amd64 > root@c720-r342378:~ # tcpdump -ni wlan0 -y IEEE802_11_PROTO > tcpdump: invalid data link type IEEE802_11_PROTO I compiled net/tcpdump to look into that and it supports: # /usr/local/sbin/tcpdump -ni wlan0 -y IEEE802_11_RADIO and the OpenBSD man page explains what IEEE802_11_RADIO is. I think, Adrian, this was what you have in mind, correct? matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub ___ freebsd-wireless@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: debugging a Wifi association problem
El día miércoles, julio 17, 2019 a las 11:13:14p. m. +0200, Vladimir Botka escribió: > > I only have FreeBSD laptops (and an older Ubuntu) and the question was > > not if FreeBSD is needed, but if FreeBSD is *able* to capture Wifi. > > Thanks > > matthias > > Yes. FreeBSD is able to capture Wifi. Find below the link to the BSD chapter. > https://wiki.wireshark.org/CaptureSetup/WLAN#A.2ABSD > When I start capturing with # wireshark -i wlan0 -I it says: The capture session could not be initiated on interface 'wlan0' (That device doesn't support monitor mode). Please check that you have the proper interface or pipe specified. also setting before # ifconfig wlan0 monitor does not help and does nos say anything. # ifconfig wlan0 wlan0: flags=48843 metric 0 mtu 1500 ether 90:48:9a:92:9e:43 inet 192.168.2.105 netmask 0xff00 broadcast 192.168.2.255 groups: wlan ssid tarara channel 6 (2437 MHz 11g) bssid 00:1c:4a:06:17:f5 regdomain 108 indoor ecm authmode WPA2/802.11i privacy ON deftxkey UNDEF TKIP 2:128-bit TKIP 3:128-bit txpower 20 bmiss 7 scanvalid 60 protmode CTS wme burst roaming MANUAL media: IEEE 802.11 Wireless Ethernet OFDM/54Mbps mode 11g status: associated nd6 options=2b # pciconf -lv ... ath0@pci0:1:0:0:class=0x028000 card=0xe058105b chip=0x0034168c rev=0x01 hdr=0x00 vendor = 'Qualcomm Atheros' device = 'AR9462 Wireless Network Adapter' class = network Any ideas? matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub ___ freebsd-wireless@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: debugging a Wifi association problem
El día miércoles, julio 17, 2019 a las 08:26:02p. m. +0200, Vladimir Botka escribió: > > I installed wireshark-2.6.5_2 in my FreeBSD (CURRENT from December last > > year). I tried to enable from > > View --> [x] Wireless Toolbar > > but this gives an error about "Failed to initialize ws80211" in the GUI > > and I can not set the channel or Frequency. Is this not possible with > > FreeBSD? > > FreeBSD is not needed to analyse the the problem. I only have FreeBSD laptops (and an older Ubuntu) and the question was not if FreeBSD is needed, but if FreeBSD is *able* to capture Wifi. > Use whatever system is able > to set wifi card into the "monitor" mode and sniff the packets first. The > link below is complete how to do it > https://wiki.wireshark.org/CaptureSetup/WLAN > When you got the data analyse it with wireshark. The captured data might grow > fast. Thanks matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub ___ freebsd-wireless@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: debugging a Wifi association problem
El día miércoles, julio 17, 2019 a las 09:05:43a. m. +0200, Vladimir Botka escribió: > Hello, > > On Wed, 17 Jul 2019 07:38:26 +0200 > Matthias Apitz wrote: > > > ... The association requests are always rejected with a package > > CTRL-EVENT-ASSOC-REJECT with 'status_code=1'... > > Do we have any tool in FreeBSD to monitor/debug this problem between the > > device in question and the AP? Any other ideas? > > Best practice is to sniff packets and see what's going on. > http://www.wireless-nets.com/resources/tutorials/sniff_packets_wireshark.html > Hello Vladimir, I installed wireshark-2.6.5_2 in my FreeBSD (CURRENT from December last year). I tried to enable from View --> [x] Wireless Toolbar but this gives an error about "Failed to initialize ws80211" in the GUI and I can not set the channel or Frequency. Is this not possible with FreeBSD? In this case I'd have to look for a Linux laptop or even a Windows one (which I'd hate). Thanks for a hint. matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub ___ freebsd-wireless@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
debugging a Wifi association problem
e=0xd0 (WLAN_FC_STYPE_ACTION) nl_handle=0xb8a160b8 match=0a11 1548368341.389614: nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) nl_handle=0xb8a160b8 match=1101 1548368341.389695: nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) nl_handle=0xb8a160b8 match=1102 1548368341.389776: nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) nl_handle=0xb8a160b8 match=0505 1548368341.389868: nl80211: Key management set PSK 1548368341.389897: nl80211: Connect (ifindex=10) 1548368341.389929: * bssid_hint=00:1c:4a:06:17:f5 1548368341.389959: * freq_hint=2422 1548368341.389985: * SSID - hexdump_ascii(len=6): 74 61 72 61 72 61 tarara 1548368341.390044: * IEs - hexdump(len=22): 30 14 01 00 00 0f ac 02 01 00 00 0f ac 04 01 00 00 0f ac 02 00 00 1548368341.390090: * WPA Versions 0x2 1548368341.390115: * pairwise=0xfac04 1548368341.390139: * group=0xfac02 1548368341.390163: * akm=0xfac02 1548368341.390188: * htcaps - hexdump(len=26): 63 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1548368341.390236: * htcaps_mask - hexdump(len=26): 63 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1548368341.390286: * vhtcaps - hexdump(len=12): 00 00 00 00 00 00 00 00 00 00 00 00 1548368341.390321: * vhtcaps_mask - hexdump(len=12): 00 00 00 00 00 00 00 00 00 00 00 00 1548368341.390357: * Auth Type 0 1548368341.410056: nl80211: Connect request send successfully 1548368341.410178: wlan0: Setting authentication timeout: 10 sec 0 usec 1548368341.410219: EAPOL: External notification - EAP success=0 1548368341.410251: EAPOL: External notification - EAP fail=0 1548368341.410278: EAPOL: External notification - portControl=Auto 1548368341.410450: dbus: flush_object_timeout_handler: Timeout - sending changed properties of object /fi/w1/wpa_supplicant1/Interfaces/1 1548368341.541040: nl80211: Event message available 1548368341.541434: nl80211: Drv Event 46 (NL80211_CMD_CONNECT) received for wlan0 1548368341.541556: nl80211: Connect event (status=1 ignore_next_local_disconnect=0) 1548368341.541637: wlan0: Event ASSOC_REJECT (13) received 1548368341.541719: wlan0: CTRL-EVENT-ASSOC-REJECT bssid=00:1c:4a:06:17:f5 status_code=1 1548368341.541799: wlan0: Radio work 'connect'@0xb8a29310 done in 0.169226 seconds 1548368341.541860: Added BSSID 00:1c:4a:06:17:f5 into blacklist 1548368341.541925: Continuous association failures - consider temporary network disabling 1548368341.542001: wlan0: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="tarara" auth_failures=2 duration=20 reason=CONN_FAILED 1548368341.542068: wlan0: Blacklist count 11 --> request scan in 1 ms 1548368341.542134: wlan0: Setting scan request: 10.00 sec 1548368341.542205: wlan0: State: ASSOCIATING -> DISCONNECTED 1548368341.542260: nl80211: Set wlan0 operstate 0->0 (DORMANT) 1548368341.542318: netlink: Operstate: ifindex=10 linkmode=-1 (no change), operstate=5 (IF_OPER_DORMANT) 1548368341.543474: EAPOL: External notification - portEnabled=0 1548368341.543583: EAPOL: External notification - portValid=0 1548368341.543641: EAPOL: External notification - EAP success=0 1548368341.548586: dbus: flush_object_timeout_handler: Timeout - sending changed properties of object /fi/w1/wpa_supplicant1/Interfaces/1 -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub ___ freebsd-wireless@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: Atheros AR5B22 WLAN+Bluetooth support on FreeBSD
El día sábado, abril 20, 2019 a las 02:16:49p. m. +0300, Serge Semenenko
escribió:
> Hi
>
> It works for me with such section in devd.conf
>
> attach 200 {
>device-name "ubt[0-9]+";
>match "vendor" "0x0cf3";
>match "product" "0xe006";
>action "sleep 2 && /usr/sbin/ath3kfw -d $ugen && sleep 2 &&
> /etc/rc.d/bluetooth quietstart $device-name";
> };
I have added the above lines to /etc/devd.conf, ofc with the vendor and
product ID of my chip:
$ usbconfig
...
ugen0.3: at usbus0, cfg=0 md=HOST spd=FULL
(12Mbps) pwr=ON (100mA)
and place the firmware in the directory where /usr/sbin/ath3kfw is
looking for it, into /usr/share/firmware/ath3k/ar3k/
The problem remains: no device /dev/ubt0 gets created (and the attach
rule does not apply.
When I change 'attach 200' to 'notify 100', /usr/sbin/ath3kfw gets
called and the firmware gets loaded into the chip. But nothing of BT does work.
I think some of the nd_*.ko modules do not attach and due to this the
device is not created.
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
N € I N zur EU!
"Gegen das EU-Europa der Banken, Konzerne und Kriegstreiber.
Für ein soziales und friedliches Europa der Völker." DKP
___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: Atheros AR5B22 WLAN+Bluetooth support on FreeBSD
El día Thursday, April 18, 2019 a las 07:02:38PM +0200, Matthias Apitz escribió: > El día Thursday, April 18, 2019 a las 08:05:53AM -0700, Adrian Chadd escribió: > > > that means it SHOULD be ready for normal HCI operation. bcdDevice=1 is what > > the driver uses to determine if it's only in the boot ROM. Yours either got > > it in a previous boot, or it has a ROM with the full firmware. > > btw: I switched from ChromeOS in developer mode to boot FreeBSD from USB by > 'reboot' and not by power-cycle. Maybe that's the reason why the > firmware is still loaded. Yes, when I do a power-off boot the result of loading the firmware is: # ./ath3kfw -D -d ugen0.4 -f ~guru/ath3k/share/firmware/ath3k -I 2>&1 | tee log ath3kfw: opening dev 0.4 ath3k_is_3012: found AR3012 main: state=0x0e ath3k_load_fwfile: file=/home/guru/ath3k/share/firmware/ath3k/ar3k/AthrBT_0x1102.dfu, size=36828 ath3k_load_fwfile: transferring 4096 bytes, offset 20 ath3k_load_fwfile: transferring 4096 bytes, offset 4116 ath3k_load_fwfile: transferring 4096 bytes, offset 8212 ath3k_load_fwfile: transferring 4096 bytes, offset 12308 ath3k_load_fwfile: transferring 4096 bytes, offset 16404 ath3k_load_fwfile: transferring 4096 bytes, offset 20500 ath3k_load_fwfile: transferring 4096 bytes, offset 24596 ath3k_load_fwfile: transferring 4096 bytes, offset 28692 ath3k_load_fwfile: transferring 4040 bytes, offset 32788 ath3k_load_fwfile: file=/home/guru/ath3k/share/firmware/ath3k/ar3k/ramps_0x1102_40.dfu, size=1796 ath3k_load_fwfile: transferring 1776 bytes, offset 20 ROM version: 285343744, build version: 155, ram version: 155, ref clock=1 ath3k_load_patch: file /home/guru/ath3k/share/firmware/ath3k/ar3k/AthrBT_0x1102.dfu: rom_ver=285343744, build_ver=370 LIBUSB_FUNCTION: libusb_bulk_transfer enter LIBUSB_FUNCTION: libusb_submit_transfer enter LIBUSB_FUNCTION: libusb_submit_transfer leave 0 LIBUSB_FUNCTION: libusb_handle_events_timeout_completed enter LIBUSB_FUNCTION: libusb10_handle_events_sub enter LIBUSB_FUNCTION: libusb_handle_events_timeout_completed exit LIBUSB_FUNCTION: libusb_handle_events_timeout_completed enter LIBUSB_FUNCTION: libusb10_handle_events_sub enter LIBUSB_TRANSFER: sync I/O done LIBUSB_FUNCTION: libusb_handle_events_timeout_completed exit LIBUSB_FUNCTION: libusb_bulk_transfer leave LIBUSB_FUNCTION: libusb_bulk_transfer enter LIBUSB_FUNCTION: libusb_submit_transfer enter LIBUSB_FUNCTION: libusb_submit_transfer leave 0 LIBUSB_FUNCTION: libusb_handle_events_timeout_completed enter LIBUSB_FUNCTION: libusb10_handle_events_sub enter LIBUSB_TRANSFER: sync I/O done LIBUSB_FUNCTION: libusb_handle_events_timeout_completed exit LIBUSB_FUNCTION: libusb_bulk_transfer leave LIBUSB_FUNCTION: libusb_bulk_transfer enter LIBUSB_FUNCTION: libusb_submit_transfer enter LIBUSB_FUNCTION: libusb_submit_transfer leave 0 LIBUSB_FUNCTION: libusb_handle_events_timeout_completed enter LIBUSB_FUNCTION: libusb10_handle_events_sub enter LIBUSB_TRANSFER: sync I/O done LIBUSB_FUNCTION: libusb_handle_events_timeout_completed exit LIBUSB_FUNCTION: libusb_bulk_transfer leave LIBUSB_FUNCTION: libusb_bulk_transfer enter LIBUSB_FUNCTION: libusb_submit_transfer enter LIBUSB_FUNCTION: libusb_submit_transfer leave 0 LIBUSB_FUNCTION: libusb_handle_events_timeout_completed enter LIBUSB_FUNCTION: libusb10_handle_events_sub enter LIBUSB_TRANSFER: sync I/O done LIBUSB_FUNCTION: libusb_handle_events_timeout_completed exit LIBUSB_FUNCTION: libusb_bulk_transfer leave LIBUSB_FUNCTION: libusb_bulk_transfer enter LIBUSB_FUNCTION: libusb_submit_transfer enter LIBUSB_FUNCTION: libusb_submit_transfer leave 0 LIBUSB_FUNCTION: libusb_handle_events_timeout_completed enter LIBUSB_FUNCTION: libusb10_handle_events_sub enter LIBUSB_TRANSFER: sync I/O done LIBUSB_FUNCTION: libusb_handle_events_timeout_completed exit LIBUSB_FUNCTION: libusb_bulk_transfer leave LIBUSB_FUNCTION: libusb_bulk_transfer enter LIBUSB_FUNCTION: libusb_submit_transfer enter LIBUSB_FUNCTION: libusb_submit_transfer leave 0 LIBUSB_FUNCTION: libusb_handle_events_timeout_completed enter LIBUSB_FUNCTION: libusb10_handle_events_sub enter LIBUSB_TRANSFER: sync I/O done LIBUSB_FUNCTION: libusb_handle_events_timeout_completed exit LIBUSB_FUNCTION: libusb_bulk_transfer leave LIBUSB_FUNCTION: libusb_bulk_transfer enter LIBUSB_FUNCTION: libusb_submit_transfer enter LIBUSB_FUNCTION: libusb_submit_transfer leave 0 LIBUSB_FUNCTION: libusb_handle_events_timeout_completed enter LIBUSB_FUNCTION: libusb10_handle_events_sub enter LIBUSB_TRANSFER: sync I/O done LIBUSB_FUNCTION: libusb_handle_events_timeout_completed exit LIBUSB_FUNCTION: libusb_bulk_transfer leave LIBUSB_FUNCTION: libusb_bulk_transfer enter LIBUSB_FUNCTION: libusb_submit_transfer enter LIBUSB_FUNCTION: libusb_submit_transfer leave 0 LIBUSB_FUNCTION: libusb_handle_events_timeout_completed enter LIBUSB_FUNCTION: libusb10_handle_events_sub enter LIBUSB_TRANSFER: sync I/O done LIBUSB_FUNCTION: libusb_handle_ev
Re: Atheros AR5B22 WLAN+Bluetooth support on FreeBSD
El día Thursday, April 18, 2019 a las 08:05:53AM -0700, Adrian Chadd escribió: > that means it SHOULD be ready for normal HCI operation. bcdDevice=1 is what > the driver uses to determine if it's only in the boot ROM. Yours either got > it in a previous boot, or it has a ROM with the full firmware. btw: I switched from ChromeOS in developer mode to boot FreeBSD from USB by 'reboot' and not by power-cycle. Maybe that's the reason why the firmware is still loaded. > Try starting bluetooth now and do an inquiry. # grep ubt0 /var/log/messages Apr 18 14:29:46 c720-r342378-usb kernel: ubt0 on uhub1 Apr 18 14:29:46 c720-r342378-usb kernel: ubt0: on usbus0 # service bluetooth start ubt0 /etc/rc.d/bluetooth: ERROR: Unable to setup Bluetooth stack for device ubt0 # /etc/rc.d/hcsecd onestart Starting hcsecd. # service bluetooth start ubt0 ng_hci_process_command_timeout: ubt0hci - unable to complete HCI command OGF=0x3, OCF=0x3. Timeout /etc/rc.d/bluetooth: ERROR: Unable to setup Bluetooth stack for device ubt0 anything else to test? matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub 70 years of NATO - 70 years of wars (Jugoslavia, Afghanistan, Syria, ...) and 70 years of war preparation against Russia. -- PEACE instead of NATO ! ___ freebsd-wireless@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: Atheros AR5B22 WLAN+Bluetooth support on FreeBSD
I have booted the other C720 from USB and here are the results: root@c720-r342378-usb:~guru/ath3k/src/usr.bin/ath3k # grep ath dmesg* ath0: mem 0xe040-0xe047 at device 0.0 on pci1 ath0: Enabling WB222 BTCOEX ath0: [HT] enabling HT modes ath0: [HT] enabling short-GI in 20MHz mode ath0: [HT] 1 stream STBC receive enabled ath0: [HT] 1 stream STBC transmit enabled ath0: [HT] LDPC transmit/receive enabled ath0: [HT] 2 RX streams; 2 TX streams ath0: AR9460 mac 640.2 RF5110 phy 1638.6 ath0: 2GHz radio: 0x; 5GHz radio: 0x root@c720-r342378-usb:~guru/ath3k/src/usr.bin/ath3k # usbconfig ugen1.1: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen0.1: <0x8086 XHCI root HUB> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE (0mA) ugen0.2: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (200mA) ugen1.2: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen0.3: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA) ugen0.4: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA) root@c720-r342378-usb:~guru/ath3k/src/usr.bin/ath3k # ./ath3kfw -D -d ugen0.4 -I ath3kfw: opening dev 0.4 ath3k_is_3012: found AR3012 main: AR3012; bcdDevice=2, exiting attached is the full output of 'dmesg' And now? matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub 70 years of NATO - 70 years of wars (Jugoslavia, Afghanistan, Syria, ...) and 70 years of war preparation against Russia. -- PEACE instead of NATO ! ---<>--- Copyright (c) 1992-2018 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 13.0-CURRENT GENERIC amd64 FreeBSD clang version 7.0.1 (tags/RELEASE_701/final 349250) (based on LLVM 7.0.1) WARNING: WITNESS option enabled, expect reduced performance. VT(vga): resolution 640x480 CPU: Intel(R) Celeron(R) 2955U @ 1.40GHz (1396.80-MHz K8-class CPU) Origin="GenuineIntel" Id=0x40651 Family=0x6 Model=0x45 Stepping=1 Features=0xbfebfbff Features2=0x4ddaebbf AMD Features=0x2c100800 AMD Features2=0x21 Structured Extended Features=0x2603 XSAVE Features=0x1 VT-x: (disabled in BIOS) PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics real memory = 4301258752 (4102 MB) avail memory = 1917231104 (1828 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) random: unblocking device. ioapic0 irqs 0-39 on motherboard Launching APs: 1 Timecounter "TSC" frequency 1396798980 Hz quality 1000 Cuse v0.1.35 @ /dev/cuse random: entropy device external interface [ath_hal] loaded kbd1 at kbdmux0 module_register_init: MOD_LOAD (vesa, 0x81124550, 0) error 19 random: registering fast source Intel Secure Key RNG random: fast provider: "Intel Secure Key RNG" 000.52 [4184] netmap_init netmap: loaded module nexus0 vtvga0: on motherboard cryptosoft0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) hpet0: iomem 0xfed0-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 550 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 Event timer "HPET4" frequency 14318180 Hz quality 440 Event timer "HPET5" frequency 14318180 Hz quality 440 Event timer "HPET6" frequency 14318180 Hz quality 440 cpu0: on acpi0 atrtc0: port 0x70-0x77 on acpi0 atrtc0: registered as a time-of-day clock, resolution 1.00s Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: irq 37 on acpi0 acpi_button2: irq 38 on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0x1800-0x183f mem 0xe000-0xe03f,0xd000-0xdfff at device 2.0 on pci0 vgapci0: Boot video device hdac0: mem 0xe051-0xe0513fff at device 3.0 on pci0 xhci0: mem 0xe050-0xe050 at device 20.0 on pci0 xhci0: 32 bytes context size, 64-bit DMA xhci0: Port routing mask set to 0x usbus0 on xhci0 usbus0: 5.0Gbps Super Speed USB v3.0 pci0: at device 21.0 (no driver attached) ig4iic_pci0: mem 0xe051a000-0xe051afff,0xe051b000-0xe051bfff
Re: Atheros AR5B22 WLAN+Bluetooth support on FreeBSD
Am Mittwoch, 17. April 2019 19:59:17 CEST schrieb Adrian Chadd : no flashing occurs. it's running out of ram on the chip. -a So, what do you want me to test exactly? ma -- Sent from my Ubuntu phone http://www.unixarea.de/ ___ freebsd-wireless@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: Atheros AR5B22 WLAN+Bluetooth support on FreeBSD
Am Mittwoch, 17. April 2019 18:59:08 CEST schrieb Adrian Chadd : Did you copy it into /usr/share/ or did you pass the command line arg in to set the base directory? :) I was aware of the flag -f to specify the dir or file of the firmware to use. I did not set this by intention to *not* flash the firmware into the chip. I misinterpreted the flag -I thinking that this is only for read and not flash. But it is meant like verbose what the tool is doing. Meanwhile I produced already a system on an USB key and when I have time on Eastern I will test the tool on the other C720 I have and which at the moment is only collecting dust. Stay tuned for the result or more questions. matthias -- Sent from my Ubuntu phone http://www.unixarea.de/ ___ freebsd-wireless@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: Atheros AR5B22 WLAN+Bluetooth support on FreeBSD
El día Wednesday, April 17, 2019 a las 02:35:51PM +, Alexey Dokuchaev escribió: > On Tue, Apr 16, 2019 at 12:34:12PM +0200, Matthias Apitz wrote: > > # ./ath3kfw -D -d ugen0.3 -I > > ath3kfw: opening dev 0.3 > > ath3k_is_3012: found AR3012 > > main: state=0x0e > > ROM version: 285343744, build version: 155, ram version: 155, ref clock=1 > > ath3kfw: ath3k_fw_read: open: > > /usr/share/firmware/ath3k//ar3k/AthrBT_0x1102.dfu: No such file or > > directory > > OK, so the file is not in the right place (as indicated by this message). > > > ath3k_load_patch: ath3k_fw_read() failed > > Loading patch file failed > > > > The ROM version: 285343744 does not look like something meaningful, > > maybe the tool reads the wrong place. > > It is meaningful and correct, it is just printed in decimal which is > probably bogus: > > $ echo 16 o 285343744 p | dc > 1102 Yep. The printf should be corrected to something like %08x. > > Which file I should use from ath3k/share/firmware/ath3k > > # ls -C1 > > ar3k > > ath3k-1.fw > > LICENCE.atheros_firmware > > > > below ar3k/ are a lot more files > > Is there AthrBT_0x1102.dfu amongst them? Try placing it under > /usr/share/firmware/ath3k/ar3k/ and repeat the procedure. We have the following files there: $ find firmware/ firmware/ath3k firmware/ath3k/LICENCE.atheros_firmware firmware/ath3k/ar3k firmware/ath3k/ar3k/1020200 firmware/ath3k/ar3k/1020200/PS_ASIC.pst firmware/ath3k/ar3k/1020200/RamPatch.txt firmware/ath3k/ar3k/1020200/ar3kbdaddr.pst firmware/ath3k/ar3k/1020201 firmware/ath3k/ar3k/1020201/PS_ASIC.pst firmware/ath3k/ar3k/1020201/RamPatch.txt firmware/ath3k/ar3k/3 firmware/ath3k/ar3k/3/PS_ASIC.pst firmware/ath3k/ar3k/3/RamPatch.txt firmware/ath3k/ar3k/3/ar3kbdaddr.pst firmware/ath3k/ar3k/30101 firmware/ath3k/ar3k/30101/PS_ASIC.pst firmware/ath3k/ar3k/30101/RamPatch.txt firmware/ath3k/ar3k/30101/ar3kbdaddr.pst firmware/ath3k/ar3k/30101coex firmware/ath3k/ar3k/30101coex/PS_ASIC.pst firmware/ath3k/ar3k/30101coex/PS_ASIC_aclHighPri.pst firmware/ath3k/ar3k/30101coex/PS_ASIC_aclLowPri.pst firmware/ath3k/ar3k/30101coex/RamPatch.txt firmware/ath3k/ar3k/30101coex/ar3kbdaddr.pst firmware/ath3k/ar3k/AthrBT_0x01020001.dfu firmware/ath3k/ar3k/AthrBT_0x01020200.dfu firmware/ath3k/ar3k/AthrBT_0x01020201.dfu firmware/ath3k/ar3k/AthrBT_0x1102.dfu<*** !!! firmware/ath3k/ar3k/AthrBT_0x3101.dfu firmware/ath3k/ar3k/ramps_0x01020001_26.dfu firmware/ath3k/ar3k/ramps_0x01020200_26.dfu firmware/ath3k/ar3k/ramps_0x01020200_40.dfu firmware/ath3k/ar3k/ramps_0x01020201_26.dfu firmware/ath3k/ar3k/ramps_0x01020201_40.dfu firmware/ath3k/ar3k/ramps_0x1102_40.dfu firmware/ath3k/ar3k/ramps_0x3101_40.dfu firmware/ath3k/ath3k-1.fw -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub 70 years of NATO - 70 years of wars (Jugoslavia, Afghanistan, Syria, ...) and 70 years of war preparation against Russia. -- PEACE instead of NATO ! ___ freebsd-wireless@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: Atheros AR5B22 WLAN+Bluetooth support on FreeBSD
El día lunes, abril 15, 2019 a las 12:26:52p. m. +, Alexey Dokuchaev
escribió:
> I've posted exact instructions how to use it and debug log earlier in
> this thread, you being CC'ed, I don't understand how could you've missed
> those emails.
I have not missed (or deleted) any mail in this thread of 24++ mails. But as
Adrian
said "Does ath3k load OK?" I was confused and thinking in a loadable
kernel module. Sorry.
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
70 years of NATO - 70 years of wars (Jugoslavia, Afghanistan, Syria, ...) and
70 years
of war preparation against Russia. -- PEACE instead of NATO !!!
___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: Atheros AR5B22 WLAN+Bluetooth support on FreeBSD
El día domingo, abril 14, 2019 a las 09:42:46a. m. -0700, Adrian Chadd escribió: > no, it's the userland ath3kfw tool from my git (github.com/erikarn/ath3k) > > Those NICs need firmware/config squirted onto them after ath(4) loads and > sets up the btcoex. > > I git cloned it and built it, but this does not give any kernel module to load: $ ls -ltr total 208 -rw-r--r-- 1 guru wheel164 15 abr. 06:27 Makefile -rw-r--r-- 1 guru wheel 1828 15 abr. 06:27 ath3k_dbg.h -rw-r--r-- 1 guru wheel 2857 15 abr. 06:27 ath3k_fw.c -rw-r--r-- 1 guru wheel 2066 15 abr. 06:27 ath3k_fw.h -rw-r--r-- 1 guru wheel 7928 15 abr. 06:27 ath3k_hw.c -rw-r--r-- 1 guru wheel 2641 15 abr. 06:27 ath3k_hw.h -rw-r--r-- 1 guru wheel 10183 15 abr. 06:27 main.c -rw-r--r-- 1 guru wheel 21856 15 abr. 06:29 main.o -rw-r--r-- 1 guru wheel 9824 15 abr. 06:29 ath3k_fw.o -rw-r--r-- 1 guru wheel 18592 15 abr. 06:29 ath3k_hw.o -rwxr-xr-x 1 guru wheel 52096 15 abr. 06:29 ath3kfw.full -rwxr-xr-x 1 guru wheel 31312 15 abr. 06:29 ath3kfw.debug -rwxr-xr-x 1 guru wheel 27648 15 abr. 06:29 ath3kfw $ ./ath3kfw Usage: ath3kfw (-D) -d ugenX.Y (-f firmware path) (-I) -D: enable debugging -d: device to operate upon -f: firmware path, if not default -I: enable informational output What next? Will it brick my Wifi chip? I need this C720 for work. :-) -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub 70 years of NATO - 70 years of wars (Jugoslavia, Afghanistan, Syria, ...) and 70 years of war preparation against Russia. -- PEACE instead of NATO !!! signature.asc Description: PGP signature
Re: Atheros AR5B22 WLAN+Bluetooth support on FreeBSD
El día domingo, abril 14, 2019 a las 09:18:18a. m. -0700, Adrian Chadd escribió: > ok, so you've added the WB222 coex bits. Does ath3k load OK? > I do not have this module: root@c720-r342378:/home/guru # uname -a FreeBSD c720-r342378 13.0-CURRENT FreeBSD 13.0-CURRENT GENERIC amd64 root@c720-r342378:/home/guru # find /boot/ | grep -i ath3 root@c720-r342378:/home/guru # matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub 70 years of NATO - 70 years of wars (Jugoslavia, Afghanistan, Syria, ...) and 70 years of war preparation against Russia. -- PEACE instead of NATO !!! signature.asc Description: PGP signature
Re: Atheros AR5B22 WLAN+Bluetooth support on FreeBSD
El día domingo, abril 14, 2019 a las 08:56:52a. m. -0700, Adrian Chadd escribió: > hi! > > Ok, so there's two parts: > > * loading in the firmware and/or bt nic setup (clock rate, etc) via > ath3kfw; and > * bluetooth coex/antenna setup in ath(4). > > The latter I can do. The former may require USB stack debugging. > > Which NIC is in the C720? Ar9485, right? $ dmesg | grep ath0 ath0: mem 0xe040-0xe047 at device 0.0 on pci1 ath0: Enabling WB222 BTCOEX ath0: [HT] enabling HT modes ath0: [HT] enabling short-GI in 20MHz mode ath0: [HT] 1 stream STBC receive enabled ath0: [HT] 1 stream STBC transmit enabled ath0: [HT] LDPC transmit/receive enabled ath0: [HT] 2 RX streams; 2 TX streams ath0: AR9460 mac 640.2 RF5110 phy 2456.12 ath0: 2GHz radio: 0x; 5GHz radio: 0x matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub 70 years of NATO - 70 years of wars (Jugoslavia, Afghanistan, Syria, ...) and 70 years of war preparation against Russia. -- PEACE instead of NATO !!! signature.asc Description: PGP signature
Re: Atheros AR5B22 WLAN+Bluetooth support on FreeBSD
El día sábado, abril 13, 2019 a las 02:20:06p. m. +, Alexey Dokuchaev escribió: > On Fri, Apr 12, 2019 at 05:12:18PM +, Alexey Dokuchaev wrote: > > I've then rebooted back into FreeBSD. Apparently, this AR3012 hardware > > is very fragile, it can be easily left in confused state and won't accept > > further commands, "usbconfig reset" does not help. To avoid this, it is > > better run ./ath3kfw as root, after powercycling machine (to reset the > > card). This got me further: > > I booted my Acer C720 from an external USB disk with an Ubuntu 18.04 ; below is the output of the following grep (I can provide the full file if it is of interest); BlueTooth was working fine out of the box and pairing with my Ubuntu mobile phone $ egrep -i 'e056|blue|ath3' syslog Apr 13 19:22:47 aurora systemd[1]: Starting Bluetooth service... Apr 13 19:22:47 aurora kernel: [3.378263] usb 2-4: New USB device found, idVendor=0489, idProduct=e056, bcdDevice= 0.02 Apr 13 19:22:47 aurora kernel: [ 16.176818] Bluetooth: Core ver 2.22 Apr 13 19:22:47 aurora kernel: [ 16.176840] Bluetooth: HCI device and connection manager initialized Apr 13 19:22:47 aurora kernel: [ 16.176845] Bluetooth: HCI socket layer initialized Apr 13 19:22:47 aurora kernel: [ 16.176848] Bluetooth: L2CAP socket layer initialized Apr 13 19:22:47 aurora kernel: [ 16.176858] Bluetooth: SCO socket layer initialized Apr 13 19:22:47 aurora kernel: [ 17.403429] usbcore: registered new interface driver ath3k Apr 13 19:22:51 aurora bluetoothd[719]: Bluetooth daemon 5.48 Apr 13 19:22:51 aurora systemd[1]: Started Bluetooth service. Apr 13 19:22:51 aurora systemd[1]: Reached target Bluetooth. Apr 13 19:22:51 aurora bluetoothd[719]: Starting SDP server Apr 13 19:22:51 aurora bluetoothd[719]: Bluetooth management interface 1.14 initialized Apr 13 19:22:51 aurora kernel: [ 30.609088] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 Apr 13 19:22:51 aurora kernel: [ 30.609090] Bluetooth: BNEP filters: protocol multicast Apr 13 19:22:51 aurora kernel: [ 30.609096] Bluetooth: BNEP socket layer initialized Apr 13 19:22:51 aurora dbus-daemon[740]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service' requested by ':1.11' (uid=0 pid=719 comm="/usr/lib/bluetooth/bluetoothd " label="unconfined") Apr 13 19:22:54 aurora NetworkManager[797]: [1555176174.1461] Loaded device plugin: NMBluezManager (/usr/lib/x86_64-linux-gnu/NetworkManager/libnm-device-plugin-bluetooth.so) Apr 13 19:22:54 aurora NetworkManager[797]: [1555176174.4358] bluez: use BlueZ version 5 Apr 13 19:22:54 aurora NetworkManager[797]: [1555176174.4421] bluez5: NAP: added interface 90:48:9A:92:9E:44 Apr 13 19:23:23 aurora /usr/lib/gdm3/gdm-x-session[1324]: (II) modeset(0): blueX: 0.160 blueY: 0.144 whiteX: 0.313 whiteY: 0.329 Apr 13 19:23:29 aurora bluetoothd[719]: Endpoint registered: sender=:1.80 path=/MediaEndpoint/A2DPSource Apr 13 19:23:29 aurora bluetoothd[719]: Endpoint registered: sender=:1.80 path=/MediaEndpoint/A2DPSink Apr 13 19:23:29 aurora kernel: [ 68.884106] Bluetooth: RFCOMM TTY layer initialized Apr 13 19:23:29 aurora kernel: [ 68.884115] Bluetooth: RFCOMM socket layer initialized Apr 13 19:23:29 aurora kernel: [ 68.884122] Bluetooth: RFCOMM ver 1.11 Apr 13 19:24:01 aurora kernel: [ 100.963505] Bluetooth: hci0: last event is not cmd complete (0x0f) Apr 13 19:24:02 aurora dbus-daemon[1340]: [session uid=1000 pid=1340] Activating via systemd: service name='org.bluez.obex' unit='dbus-org.bluez.obex.service' requested by ':1.58' (uid=1000 pid=1823 comm="gnome-control-center bluetooth " label="unconfined") Apr 13 19:24:02 aurora systemd[1306]: Starting Bluetooth OBEX service... Apr 13 19:24:02 aurora dbus-daemon[1340]: [session uid=1000 pid=1340] Successfully activated service 'org.bluez.obex' Apr 13 19:24:02 aurora systemd[1306]: Started Bluetooth OBEX service. Apr 13 19:24:17 aurora kernel: [ 116.965447] Bluetooth: hci0: last event is not cmd complete (0x0f) -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub 70 years of NATO - 70 years of wars (Jugoslavia, Afghanistan, Syria, ...) and 70 years of war preparation against Russia. -- PEACE instead of NATO !!! signature.asc Description: PGP signature
Re: Atheros AR5B22 WLAN+Bluetooth support on FreeBSD
On Thu, 11 Apr 2019 14:23:50 +, Alexey Dokuchaev wrote: > On Thu, Apr 11, 2019 at 06:36:26AM -0700, Adrian Chadd wrote: >> I have a tool to upload firmware -- github.com/erikarn/ath3k. >> See if that helps! > > Something's wrong: > > $ git clone https://github.com/erikarn/ath3k.git > $ cd ath3k/src/usr.bin/ath3k > $ make > $ usbconfig list | grep 0x0930 > ugen2.2: at usbus2 <...> > $ ./ath3kfw -D -d ugen2.2 -I > ath3kfw: opening dev 2.2 > ath3k_get_state: libusb_control_transfer() failed: code=-4 > main: ath3k_get_state() failed! > > USB device permissions are fine. > Is this on CURRENT? matthias -- Sent using Dekko from my Ubuntu device http://www.unixarea.de/+49 176 38902045 ___ freebsd-wireless@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: Atheros AR5B22 WLAN+Bluetooth support on FreeBSD
El día jueves, abril 11, 2019 a las 12:52:42p. m. +, Alexey Dokuchaev
escribió:
> > ath0: Enabling WB222 BTCOEX
> > ...
> >
> > But I don't know how to further enable any BT device.
>
> What does "usbconfig list" say about your BT device? Mine is
> 0x0930:0x021c, which is AR3012 with sflash firmware according to
> the Linux' drivers/bluetooth/ath3k.c. Ubuntu users had reported*
> similar problems:
# usbconfig list
ugen0.1: <0x8086 XHCI root HUB> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps)
pwr=SAVE (0mA)
ugen1.1: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps)
pwr=SAVE (0mA)
ugen0.2: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps)
pwr=ON (500mA)
ugen1.2: at usbus1, cfg=0 md=HOST spd=HIGH
(480Mbps) pwr=SAVE (0mA)
ugen0.3: at usbus0, cfg=0 md=HOST spd=FULL
(12Mbps) pwr=ON (100mA)
The later vendor 0x0489 product 0xe056 seems to be:
https://cateee.net/lkddb/web-lkddb/BT_ATH3K.html
...
Numeric ID (from LKDDb) and names (from usb.ids) of recognized devices:
vendor: 03f0 ("HP, Inc"), product: 311d ("Atheros AR9285 Malbec Bluetooth
Adapter")
vendor: 0489 ("Foxconn / Hon Hai"), product: e027
vendor: 0489 ("Foxconn / Hon Hai"), product: e02c ("Atheros AR5BBU12
Bluetooth Device")
vendor: 0489 ("Foxconn / Hon Hai"), product: e036
vendor: 0489 ("Foxconn / Hon Hai"), product: e03c
vendor: 0489 ("Foxconn / Hon Hai"), product: e03d
vendor: 0489 ("Foxconn / Hon Hai"), product: e04d ("Atheros AR3012
Bluetooth")
vendor: 0489 ("Foxconn / Hon Hai"), product: e04e
vendor: 0489 ("Foxconn / Hon Hai"), product: e056
vendor: 0489 ("Foxconn / Hon Hai"), product: e057
...
--
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: Atheros AR5B22 WLAN+Bluetooth support on FreeBSD
El día jueves, abril 11, 2019 a las 09:27:58a. m. +, Alexey Dokuchaev escribió: > On Wed, Apr 10, 2019 at 03:22:50PM +, Alexey Dokuchaev wrote: > > On Tue, Apr 09, 2019 at 04:03:44PM +, Alexey Dokuchaev wrote: > > > On Sun, Jun 02, 2013 at 09:59:05AM -0700, Adrian Chadd wrote: > > > > Hi, > > > > > > > > It's supported in -HEAD. > > > > Driver attaches correctly if I move module loading to loader.conf(5): > > > > if_ath_load="YES" > > if_ath_pci_load="YES" > > > > Bluetooth still doesn't work though. > > I've just stumbled upon this email* of Adrian's that tells how to enable > Bluetooth Coexistence by adding ``hint.ath.0.btcoex_profile="wb222"'' to > /boot/device.hints (for AR9462 cards). I've done that, and logs tell me > it is enabled, but Bluetooth still does not work: > > % dmesg | grep -i coex > ath0: Enabling WB222 BTCOEX > # hccontrol inquiry > ... repeated attempts, plenty of devices around ... > Inquiry complete. Status: No error [00] I own an Acer C720 and set the same in /boot/device.hints. After boot it says in dmesg: $ dmesg | grep ath ath0: mem 0xe040-0xe047 at device 0.0 on pci1 ath0: RX status length: 48 ath0: RX buffer size: 4096 ath0: TX descriptor length: 128 ath0: TX status length: 36 ath0: TX buffers per descriptor: 4 ath0: ath_edma_setup_rxfifo: type=0, FIFO depth = 16 entries ath0: ath_edma_setup_rxfifo: type=1, FIFO depth = 128 entries ath0: Enabling WB222 BTCOEX ... But I don't know how to further enable any BT device. The above hcccontrol just says: # hccontrol inquiry hccontrol: Could not create socket: Address family not supported by protocol family What in addition I should load or do to get BT working? Thanks matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub ___ freebsd-wireless@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
DHCP problems while connecting with a Wifi AP
Hello, I'm using my (Ubuntu) mobile device as AP to connect my FreeBSD laptop to the Internet. While this is working fine most of the times, I encounter in some situation problems getting an IP addr with DHCP from the mobile. It looks somehow like a race condition between WPA associating and DHCP (dhclient) asking to early (and giving up). Here is a typical situation when it does not work: Dec 27 11:58:25 c720-r314251 kernel: ifa_maintain_loopback_route: insertion failed for interface wlan0: 17 Dec 27 11:59:22 c720-r314251 wpa_supplicant[7871]: wlan0: Trying to associate with 4e:74:03:65:46:a9 (SSID='UbuntuBQ' freq=2412 MHz) Dec 27 11:59:32 c720-r314251 wpa_supplicant[7871]: wlan0: Authentication with 4e:74:03:65:46:a9 timed out. Dec 27 11:59:32 c720-r314251 wpa_supplicant[7871]: wlan0: CTRL-EVENT-DISCONNECTED bssid=4e:74:03:65:46:a9 reason=3 locally_generated=1 Dec 27 11:59:52 c720-r314251 wpa_supplicant[7871]: wlan0: Trying to associate with 4e:74:03:65:46:a9 (SSID='UbuntuBQ' freq=2412 MHz) Dec 27 11:59:52 c720-r314251 wpa_supplicant[7871]: wlan0: Associated with 4e:74:03:65:46:a9 Dec 27 11:59:52 c720-r314251 kernel: wlan0: link state changed to UP Dec 27 11:59:52 c720-r314251 dhclient[7941]: send_packet: No buffer space available Dec 27 11:59:53 c720-r314251 wpa_supplicant[7871]: wlan0: WPA: Key negotiation completed with 4e:74:03:65:46:a9 [PTK=CCMP GTK=CCMP] Dec 27 11:59:53 c720-r314251 wpa_supplicant[7871]: wlan0: CTRL-EVENT-CONNECTED - Connection to 4e:74:03:65:46:a9 completed [id=1 id_str=] As you can see, the 'dhclient[7941]: send_packet: No buffer space available' comes *before* the connection to the AP is completed. A tcpdump shows in such a situation that the device is not answering: root@c720-r314251:/var/db # tcpdump -n -i wlan0 port 67 09:52:45.426053 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 90:48:9a:92:9e:43, length 300 09:52:45.426926 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 90:48:9a:92:9e:43, length 300 09:52:46.465668 EAPOL key (3) v2, len 95 09:52:46.466180 EAPOL key (3) v1, len 117 09:52:46.472944 EAPOL key (3) v2, len 151 09:52:46.473183 EAPOL key (3) v1, len 95 09:52:52.429945 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 90:48:9a:92:9e:43, length 300 09:53:02.438749 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 90:48:9a:92:9e:43, length 300 09:53:19.446098 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 90:48:9a:92:9e:43, length 300 09:53:40.455949 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 90:48:9a:92:9e:43, length 300 It seems that the BOOTP/DHCP requests are not really sent to the AP because they are not visible with tcpdump in the Ubuntu device. At the same time, they are not logged by the ipfilter firewall on my laptop. The rules in question are: pass out quick log on wlan0 proto tcp from any to any port = 53 flags S keep state pass out quick log on wlan0 proto udp from any to any port = 53 keep state pass out quick log on wlan0 proto udp from any to any port = 67 keep state pass out quick log on wlan0 proto udp from any to any port = 68 keep state Any ideas re/ the following question: 1. How could I delay the dhclient until connection is fine? 2. Why the BOOTP/DHCP are not logged by the ipfilter? This could smell as a problem caused by the AP, but any other device (for example an iPhone) connects fine and gets an IP addr. Thanks matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub October, 7 -- The GDR was different: Peace instead of Bundeswehr and wars, Druschba instead of Nazis, to live instead of to survive. ___ freebsd-wireless@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: poor WLAN throughput in only one direction
El día lunes, abril 17, 2017 a las 08:49:37a. m. -0700, Adrian Chadd escribió: > Can you paste in a few lines? I'm on my cell phone atm > Here are some line que show the picture: Apr 17 17:23:36 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR: current rate 108, txcnt=11, retrycnt=0 Apr 17 17:23:37 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR: current rate 108, txcnt=43, retrycnt=4 Apr 17 17:23:37 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR: current rate 108, txcnt=44, retrycnt=11 Apr 17 17:23:38 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR: current rate 108, txcnt=43, retrycnt=10 Apr 17 17:23:38 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR: current rate 108, txcnt=45, retrycnt=7 Apr 17 17:23:39 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR: current rate 108, txcnt=44, retrycnt=6 Apr 17 17:23:39 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR: current rate 108, txcnt=44, retrycnt=10 Apr 17 17:23:40 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR: current rate 108, txcnt=43, retrycnt=20 Apr 17 17:23:40 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR decreasing rate 96 (txcnt=43 retrycnt=20) Apr 17 17:23:40 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR: current rate 96, txcnt=42, retrycnt=10 ... Apr 17 17:23:49 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR decreasing rate 48 (txcnt=46 retrycnt=20) Apr 17 17:23:49 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR: current rate 48, txcnt=43, retrycnt=8 Apr 17 17:23:50 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR: current rate 48, txcnt=44, retrycnt=7 ... Apr 17 17:24:09 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR decreasing rate 4 (txcnt=43 retrycnt=17) Apr 17 17:24:09 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR: current rate 4, txcnt=47, retrycnt=8 Apr 17 17:24:10 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR: current rate 4, txcnt=42, retrycnt=9 Apr 17 17:24:18 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR: current rate 4, txcnt=29, retrycnt=11 ... Apr 17 17:24:18 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR decreasing rate 2 (txcnt=29 retrycnt=11) -- Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/ ☎ +49-176-38902045 ___ freebsd-wireless@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: poor WLAN throughput in only one direction
El día lunes, abril 17, 2017 a las 08:20:01a. m. -0700, Adrian Chadd escribió: > Sorry I meant wlandebug +rate and check dmesg > Hi, tail of /var/log/messages attached; matthias -- Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/ ☎ +49-176-38902045 Apr 17 17:23:36 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR: current rate 108, txcnt=11, retrycnt=0 Apr 17 17:23:37 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR: current rate 108, txcnt=43, retrycnt=4 Apr 17 17:23:37 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR: current rate 108, txcnt=44, retrycnt=11 Apr 17 17:23:38 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR: current rate 108, txcnt=43, retrycnt=10 Apr 17 17:23:38 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR: current rate 108, txcnt=45, retrycnt=7 Apr 17 17:23:39 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR: current rate 108, txcnt=44, retrycnt=6 Apr 17 17:23:39 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR: current rate 108, txcnt=44, retrycnt=10 Apr 17 17:23:40 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR: current rate 108, txcnt=43, retrycnt=20 Apr 17 17:23:40 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR decreasing rate 96 (txcnt=43 retrycnt=20) Apr 17 17:23:40 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR: current rate 96, txcnt=42, retrycnt=10 Apr 17 17:23:41 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR: current rate 96, txcnt=45, retrycnt=7 Apr 17 17:23:42 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR: current rate 96, txcnt=44, retrycnt=9 Apr 17 17:23:42 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR: current rate 96, txcnt=44, retrycnt=10 Apr 17 17:23:43 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR: current rate 96, txcnt=46, retrycnt=23 Apr 17 17:23:43 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR decreasing rate 72 (txcnt=46 retrycnt=23) Apr 17 17:23:43 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR: current rate 72, txcnt=44, retrycnt=9 Apr 17 17:23:44 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR: current rate 72, txcnt=44, retrycnt=5 Apr 17 17:23:44 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR: current rate 72, txcnt=44, retrycnt=9 Apr 17 17:23:45 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR: current rate 72, txcnt=45, retrycnt=10 Apr 17 17:23:45 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR: current rate 72, txcnt=44, retrycnt=13 Apr 17 17:23:46 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR: current rate 72, txcnt=41, retrycnt=10 Apr 17 17:23:46 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR: current rate 72, txcnt=41, retrycnt=5 Apr 17 17:23:47 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR: current rate 72, txcnt=44, retrycnt=7 Apr 17 17:23:47 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR: current rate 72, txcnt=44, retrycnt=7 Apr 17 17:23:48 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR: current rate 72, txcnt=44, retrycnt=6 Apr 17 17:23:48 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR: current rate 72, txcnt=44, retrycnt=13 Apr 17 17:23:49 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR: current rate 72, txcnt=46, retrycnt=20 Apr 17 17:23:49 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR decreasing rate 48 (txcnt=46 retrycnt=20) Apr 17 17:23:49 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR: current rate 48, txcnt=43, retrycnt=8 Apr 17 17:23:50 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR: current rate 48, txcnt=44, retrycnt=7 Apr 17 17:23:50 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR: current rate 48, txcnt=44, retrycnt=21 Apr 17 17:23:50 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR decreasing rate 36 (txcnt=44 retrycnt=21) Apr 17 17:23:51 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR: current rate 36, txcnt=44, retrycnt=13 Apr 17 17:23:51 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR: current rate 36, txcnt=45, retrycnt=7 Apr 17 17:23:52 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR: current rate 36, txcnt=43, retrycnt=13 Apr 17 17:23:52 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR: current rate 36, txcnt=43, retrycnt=9 Apr 17 17:23:53 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR: current rate 36, txcnt=44, retrycnt=12 Apr 17 17:23:53 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR: current rate 36, txcnt=44, retrycnt=11 Apr 17 17:23:54 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR: current rate 36, txcnt=43, retrycnt=4 Apr 17 17:23:54 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR: current rate 36, txcnt=44, retrycnt=11 Apr 17 17:23:55 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR: current rate 36, txcnt=44, retrycnt=17 Apr 17 17:23:55 e6330-r314251 kernel: wlan0: [00:1c:4a:06:17:f5] AMRR decreasing rate 24 (txcnt=44 retrycnt=17) Apr 17 17:23:55 e6330-r314251 kernel: wlan0: [00
Re: poor WLAN throughput in only one direction
El día domingo, abril 16, 2017 a las 01:11:51p. m. -0700, Adrian Chadd escribió:
> hi, sorry, was on my phone
>
> * recompile with IEEE80211_DEBUG
Hello,
It seems that the option is already enabled in the CURRENT kernel:
[root@e6330-r314251 /usr/src]# grep IEEE80211_DEBUG ./sys/amd64/conf/GENERIC
options IEEE80211_DEBUG # enable debug msgs
> * then compile src/tools/tools/net80211, (cd in there, type 'make')
> and it'll build wlanstats. Then run that. :)
I made the tool and run it parralel to the SCP (from the rtwn0 to the ath0)
which is going dowm from around 2MB/s to some 100KB/s; see below;
>
> wlanstats +rate will log rate control statistics, which hopefully for
> rtwn will tell us what's going on.
# /usr/src/tools/tools/net80211/wlanstats/wlanstats -i wlan0 +rate
input mgmt output rxkid ascan bgscn bmiss rssi noiserate
7036 745813354 0 1 0 0 22.5 -956.0M
0 100 0 0 0 0 23.0 -956.0M
090 0 0 0 0 23.0 -956.0M
11 10 12 0 0 0 0 25.5 -959.0M
828 179 0 0 0 0 25.5 -959.0M
989 199 0 0 0 0 26.5 -959.0M
122 10 250 0 0 0 0 26.0 -959.0M
888 177 0 0 0 0 26.0 -959.0M
897 178 0 0 0 0 26.5 -959.0M
95 10 191 0 0 0 0 26.5 -95 11.0M
98 10 198 0 0 0 0 26.5 -95 11.0M
1259 250 0 0 0 0 26.0 -95 11.0M
1239 246 0 0 0 0 26.0 -956.0M
869 172 0 0 0 0 26.0 -956.0M
997 198 0 0 0 0 26.0 -955.5M
548 110 0 0 0 0 26.0 -952.0M
48 10 94 0 0 0 0 25.5 -955.5M
647 131 0 0 0 0 25.5 -951.0M
219 42 0 0 0 0 25.0 -951.0M
31 10 63 0 0 0 0 24.5 -951.0M
369 69 0 0 0 0 25.0 -951.0M
input mgmt output rxkid ascan bgscn bmiss rssi noiserate
8430 764516159 0 1 0 0 25.0 -951.0M
328 65 0 0 0 0 25.0 -951.0M
229 43 0 0 0 0 25.0 -952.0M
60 10 121 0 0 0 0 25.0 -952.0M
37 10 73 0 0 0 0 25.0 -952.0M
368 72 0 0 0 0 25.0 -952.0M
759 151 0 0 0 0 24.5 -955.5M
697 136 0 0 0 0 26.0 -955.5M
809 159 0 0 0 0 25.5 -955.5M
757 151 0 0 0 0 26.0 -955.5M
658 128 0 0 0 0 25.0 -952.0M
529 107 0 0 0 0 25.5 -955.5M
618 121 0 0 0 0 26.0 -952.0M
447 88 0 0 0 0 26.0 -952.0M
548 107 0 0 0 0 26.0 -952.0M
40 10 80 0 0 0 0 25.5 -952.0M
509 100 0 0 0 0 25.5 -952.0M
529 103 0 0 0 0 25.5 -952.0M
699 120 0 0 0 0 26.0 -952.0M
249 24 0 0 0 0 25.0 -952.0M
0 100 0 0 0 0 24.0 -952.0M
Anything else?
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/ ☎
+49-176-38902045
___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
poor WLAN throughput in only one direction
Hello, I have some laptops and servers in my WLAN/LAN, all connected to the same router and same subnet 192.168.2.x; they all run the same 12.0-CURRENT r314251 amd64: The following NICs are involved: Acer C720: WLAN ath0: AR9460 mac 640.2 RF5110 phy 2456.12 Dell e6330: WLAN rtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R Dell r210: LAN bce0: C7201.7MB/s e6330 --> r2101.8MB/s but: e6330 --> C720120KB/s, ... 30KB/s What can I check to resolve the poor rate from the e6330 to the C720? The other direction i.e. from C720 to e6330 is fine. Thanks matthias -- Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/ ☎ +49-176-38902045 ___ freebsd-wireless@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: CURRENT && BCM4312
Hello, The old chip now works fine after compiling the bcm.ko with special options and installing a port for the firmware blob. A big thanks to Adrian for this work. What I'm still struggling with, is put a static IP addr, and not DHCP in the interface like ifconfig_wlan0="WPA inet 192.168.2.3 netmask ." This worked before with the USB Wifi card but does not work now anymore with the bwn card. But this is something to solve in userland ... Thanks again, Adrian matthias -- Sent from my Ubuntu tablet http://www.unixarea.de/ ___ freebsd-wireless@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
CURRENT && BCM4312
Hello, I have updated an older Acer Aspire One laptop to a recent CURRENT r300951. Should the BCM4312 now working? It says in dmesg: $ dmesg | fgrep bwn0 siba_bwn0: mem 0x5710-0x57103fff irq 16 at device 0.0 on pci1 bwn0 on siba_bwn0 bwn0: WLAN (chipid 0x4312 rev 15) PHY (analog 6 type 5 rev 1) RADIO (manuf 0x17f ver 0x2062 rev 2) bwn0: DMA (64 bits) bwn0: Using 1 MSI messages $ ifconfig wlan0 wlan0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500 ether 90:4c:e5:00:06:ce nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier ssid "" channel 1 (2412 MHz 11b) regdomain FCC country US authmode OPEN privacy OFF txpower 30 bmiss 7 scanvalid 60 wme bintval 0 groups: wlan in /etc/rc.conf I have: wlans_bwn0="wlan0" ifconfig_wlan0="WPA DHCP" Do I miss anything? Thanks matthias -- Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/ ☎ +49-176-38902045 "Die Verkaufsschlager des Buchmarkts geben Auskunft über den Zustand einer Gesellschaft bzw. sind, was diese Zeiten angeht, Gradmesser fortschreitenden Schwachsinns. ..." (jW 19.05.2016) ___ freebsd-wireless@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: Broadcom BCM4318
El día Monday, April 20, 2015 a las 12:04:43PM +0430, Mohammad BadieZadegan escribió: Dear Felix Friedlander, Thanks for following my issue. I copied and reinstall your new bwn-kmod-firmware (0.2.0). I think that my state is better than but still I do not get any IP. PS: My WiFi LED turned on but it has not get any IP address. ** My dmesg *** siba_bwn0: Broadcom BCM4318 802.11b/g Wireless mem 0xd0204000-0xd0205fff irq 20 at device 2.0 on pci5 bwn0 on siba_bwn0 bwn0: WLAN (chipid 0x4318 rev 9) PHY (analog 3 type 2 rev 7) RADIO (manuf 0x17f ver 0x2050 rev 8) bwn0: DMA (32 bits) bwn0: firmware version (rev 666 patch 2 date 0xb217 time 0x9e7) bwn0: warn: firmware state (0) bwn0: warn: firmware state (0) bwn0: warn: firmware state (0) bwn0: warn: firmware state (0) ** My ifconfig bwn0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 2290 ether 00:14:a5:63:39:e5 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated wlan0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 00:14:a5:63:39:e5 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier ssid channel 4 (2427 MHz 11g) country US authmode WPA2/802.11i privacy ON deftxkey UNDEF txpower 30 bmiss 7 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS wme roaming MANUAL ** The interface wlan0 is not associated with any AP (and so it can not get any IP addr). Do you run wpa_supplicant(8) daemon with a correct configuration matching your air radio APs? Btw: Please, do not top post and trim your replies. matthias -- Matthias Apitz, g...@unixarea.de, http://www.unixarea.de/ +49-170-4527211 +49-176-38902045 Wenn der Mensch von den Umständen gebildet wird, so muß man die Umstände menschlich bilden. Si el hombre es formado por las circunstancias entonces es necesario formar humanamente las circunstancias, Karl Marx in Die heilige Familie / La sagrada familia (MEW 2, 138) ___ 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
problems associating to an AP
Dec 22 11:39:43 unixarea kernel: wlan0: ieee80211_scanreq: flags 0x20052 duration 0x7fff mindwell 0 maxdwell 0 nssid 1 Dec 22 11:39:43 unixarea kernel: wlan0: ieee80211_check_scan: active scan, append, nojoin, once Dec 22 11:39:43 unixarea kernel: wlan0: macaddr bssid chan rssi rate flag wep essid Dec 22 11:39:43 unixarea kernel: - bc:05:43:f6:da:65 bc:05:43:f6:da:651 62 54M ess wep FRITZ!Box WLAN 3370! Dec 22 11:39:43 unixarea kernel: - 00:1b:11:e4:98:b4 00:1b:11:e4:98:b46 62 54M ess wep DLINK! Dec 22 11:39:43 unixarea kernel: wlan0: start_scan_locked: active scan, duration 2147483647 mindwell 0 maxdwell 0, desired mode auto, append, nojoin, once Dec 22 11:39:43 unixarea kernel: wlan0: scan set 1g, 6g, 11g, 7g, 2g, 3g, 4g, 5g, 8g, 9g, 10g dwell min 20ms max 200ms Dec 22 11:39:43 unixarea kernel: wlan0: scan_task: chan 1g - 1g [active, dwell min 20ms max 200ms] Dec 22 11:39:43 unixarea kernel: [00:26:0b:4b:b8:44] new probe_resp on chan 1 (bss chan 1) OCLCPublic rssi 60 Dec 22 11:39:43 unixarea kernel: [00:26:0b:4b:b8:44] caps 0x431 bintval 100 erp 0x100 country [NL 1-13,23] Dec 22 11:39:43 unixarea kernel: [bc:05:43:f6:da:65] new probe_resp on chan 1 (bss chan 1) FRITZ!Box WLAN 3370 rssi 60 Dec 22 11:39:43 unixarea kernel: [bc:05:43:f6:da:65] caps 0x431 bintval 100 erp 0x100 country [DE 1-13,20] Dec 22 11:39:43 unixarea kernel: [bc:05:43:f6:da:65] new beacon on chan 1 (bss chan 1) FRITZ!Box WLAN 3370 rssi 60 Dec 22 11:39:43 unixarea kernel: [bc:05:43:f6:da:65] caps 0x431 bintval 100 erp 0x100 country [DE 1-13,20] Dec 22 11:39:43 unixarea kernel: [00:26:0b:4b:b8:42] new beacon on chan 1 (bss chan 1) 0x00 rssi 64 Dec 22 11:39:43 unixarea kernel: [00:26:0b:4b:b8:42] caps 0x431 bintval 100 erp 0x100 country [NL 1-13,23] Dec 22 11:39:43 unixarea kernel: wlan0: ieee80211_add_scan: chan 1g min dwell met (16281574 16281565) Dec 22 11:39:43 unixarea kernel: wlan0: scan_task: chan 1g - 6g [active, dwell min 20ms max 200ms] Dec 22 11:39:43 unixarea kernel: [00:1b:11:e4:98:b4] new beacon on chan 6 (bss chan 6) DLINK rssi 58 Dec 22 11:39:43 unixarea kernel: [00:1b:11:e4:98:b4] caps 0x411 bintval 100 erp 0x102 Dec 22 11:39:43 unixarea kernel: wlan0: ieee80211_add_scan: chan 6g min dwell met (16281636 16281598) Dec 22 11:39:43 unixarea kernel: wlan0: scan_task: chan 6g - 11g [active, dwell min 20ms max 200ms] Dec 22 11:39:43 unixarea kernel: wlan0: scan_task: chan 11g - 7g [active, dwell min 20ms max 200ms] Dec 22 11:39:43 unixarea kernel: wlan0: scan_task: chan 7g - 2g [active, dwell min 20ms max 200ms] Dec 22 11:39:43 unixarea kernel: wlan0: scan_task: chan 2g - 3g [active, dwell min 20ms max 200ms] Dec 22 11:39:44 unixarea kernel: wlan0: scan_task: chan 3g - 4g [active, dwell min 20ms max 200ms] Dec 22 11:39:44 unixarea kernel: wlan0: scan_task: chan 4g - 5g [active, dwell min 20ms max 200ms] Dec 22 11:39:44 unixarea kernel: wlan0: scan_task: chan 5g - 8g [active, dwell min 20ms max 200ms] Dec 22 11:39:44 unixarea kernel: wlan0: scan_task: chan 8g - 9g [active, dwell min 20ms max 200ms] Dec 22 11:39:44 unixarea kernel: wlan0: scan_task: chan 9g - 10g [active, dwell min 20ms max 200ms] Dec 22 11:39:45 unixarea wpa_supplicant[2787]: wlan0: Trying to associate with 00:26:0b:4b:b8:44 (SSID='OCLCPublic' freq=2412 MHz) Dec 22 11:39:45 unixarea kernel: wlan0: macaddr bssid chan rssi rate flag wep essid Dec 22 11:39:45 unixarea kernel: - bc:05:43:f6:da:65 bc:05:43:f6:da:651 61 54M ess wep FRITZ!Box WLAN 3370! Dec 22 11:39:45 unixarea kernel: - 00:1b:11:e4:98:b4 00:1b:11:e4:98:b46 62 54M ess wep DLINK! Dec 22 11:39:45 unixarea kernel: - 00:26:0b:4b:b8:44 00:26:0b:4b:b8:441 60 54M ess wep OCLCPublic! Dec 22 11:39:45 unixarea kernel: - 00:26:0b:4b:b8:42 00:26:0b:4b:b8:421 64 54M ess wep 0x00! Dec 22 11:39:45 unixarea kernel: wlan0: scan_task: done, [ticks 16283470, dwell min 20 scanend 2163765188] Dec 22 11:39:45 unixarea kernel: wlan0: notify scan done Dec 22 11:39:45 unixarea wpa_supplicant[2787]: FT: Invalid key management type (2) Dec 22 11:39:45 unixarea wpa_supplicant[2787]: wlan0: Associated with 00:26:0b:4b:b8:44 Dec 22 11:39:45 unixarea kernel: wlan0: [00:26:0b:4b:b8:44] ieee80211_scan_assoc_success Dec 22 11:39:45 unixarea kernel: wlan0: link state changed to UP Dec 22 11:39:45 unixarea wpa_supplicant[2787]: wlan0: WPA: Key negotiation completed with 00:26:0b:4b:b8:44 [PTK=CCMP GTK=CCMP] Dec 22 11:39:45 unixarea wpa_supplicant[2787]: wlan0: CTRL-EVENT-CONNECTED - Connection to 00:26:0b:4b:b8:44 completed [id=2 id_str=] Dec 22 11:40:01 unixarea kernel: wlan0: link state changed to DOWN Dec 22 11:40:00 unixarea wpa_supplicant[2787]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:26:0b:4b:b8:44 reason=0 -- Matthias Apitz, g...@unixarea.de, http://www.unixarea.de/ +49-170-4527211 1989-2014: The Wall was torn down so
Re: Issues with urtwn
El día Saturday, December 20, 2014 a las 11:41:43AM -0800, Adrian Chadd escribió: It's a race condition in the scan handling. :( When scan is cancelled (eg because something cancels it, or the state transitions to IDLE or something because the VAP resets) then it should be setting a flag to cancel things and the VAP should come out of powerstate. However, there seems to be some conditions where the scan is coming out of that loop because it's been aborted/stopped, so it's not complete - but then it stays in powersave mode because whatever's supposed to either change it (eg a state change, a received becaon, TIM coming in, etc) doesn't follow. So it stays in power save. The driver routines are called without the comlock held, so that's a small, narrow window for some state change to come through that doesn't trigger the scan code to see the scan is canceled and finish the scan (which would reset the vap powersave state.) I've added another cancel check in scan_task(). Please update this and see what happens! Hi Adrian, It works fine now, see the attached log. Thanks and ¡Feliz Navidad! matthias -- Matthias Apitz, g...@unixarea.de, http://www.unixarea.de/ +49-170-4527211 1989-2014: The Wall was torn down so that we go to war together again. El Muro ha sido derribado para que nos unimos en ir a la guerra otra vez. Diese Grenze wurde aufgehoben damit wir gemeinsam wieder in den Krieg ziehen. Dec 21 10:15:41 unixarea kernel: ugen4.3: vendor 0x7392 at usbus4 Dec 21 10:15:41 unixarea kernel: urtwn0: vendor 0x7392 product 0x7811, class 0/0, rev 2.00/2.00, addr 3 on usbus4 Dec 21 10:15:41 unixarea kernel: urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R Dec 21 10:15:41 unixarea kernel: wlan0: Ethernet address: 80:1f:02:ee:16:37 Dec 21 10:15:42 unixarea wpa_supplicant[929]: Successfully initialized wpa_supplicant Dec 21 10:15:46 unixarea wpa_supplicant[930]: wlan0: Trying to associate with 00:13:f7:0d:08:48 (SSID='tarara' freq=2442 MHz) Dec 21 10:15:46 unixarea wpa_supplicant[930]: wlan0: Associated with 00:13:f7:0d:08:48 Dec 21 10:15:46 unixarea kernel: wlan0: link state changed to UP Dec 21 10:15:46 unixarea dhclient[995]: send_packet: No buffer space available Dec 21 10:15:51 unixarea wpa_supplicant[930]: wlan0: WPA: Key negotiation completed with 00:13:f7:0d:08:48 [PTK=CCMP GTK=CCMP] Dec 21 10:15:51 unixarea wpa_supplicant[930]: wlan0: CTRL-EVENT-CONNECTED - Connection to 00:13:f7:0d:08:48 completed [id=1 id_str=] Dec 21 10:15:52 unixarea dhclient: New IP Address (wlan0): 192.168.2.101 Dec 21 10:15:52 unixarea dhclient: New Subnet Mask (wlan0): 255.255.255.0 Dec 21 10:15:52 unixarea dhclient: New Broadcast Address (wlan0): 192.168.2.255 Dec 21 10:15:52 unixarea dhclient: New Routers (wlan0): 192.168.2.1 Dec 21 10:16:33 unixarea ipmon[518]: missed 1 ipf log entries: 0 1 Dec 21 10:16:33 unixarea ipmon[518]: 10:16:33.246627 wlan0 @0:3 p 192.168.2.101 - 193.149.48.8 PR icmp len 20 84 icmp echo/0 K-S OUT Dec 21 10:17:02 unixarea ipmon[518]: 10:17:02.758277 wlan0 @0:14 p 192.168.2.101,32308 - 178.254.11.41,80 PR tcp len 20 60 -S K-S OUT ... Dec 21 10:20:43 unixarea ipmon[518]: 10:20:43.551190 wlan0 @0:14 p 192.168.2.101,17676 - 178.254.11.41,80 PR tcp len 20 60 -S K-S OUT Dec 21 10:20:46 unixarea kernel: wlan0: ieee80211_bg_scan: active scan, ticks 351546 duration 150 Dec 21 10:20:46 unixarea kernel: wlan0: scan_task: chan 7g - 1g [active, dwell min 20ms max 150ms] Dec 21 10:20:46 unixarea kernel: wlan0: scan_task: stopped, [ticks 351715, dwell min 20 scanend 351698] Dec 21 10:20:46 unixarea kernel: wlan0: ieee80211_bg_scan: active scan, ticks 351751 duration 150 Dec 21 10:20:46 unixarea kernel: wlan0: scan_task: chan 7g - 6g [active, dwell min 20ms max 150ms] Dec 21 10:20:46 unixarea kernel: wlan0: scan_task: stopped, [ticks 351919, dwell min 20 scanend 351902] Dec 21 10:20:46 unixarea kernel: wlan0: ieee80211_bg_scan: active scan, ticks 351956 duration 150 Dec 21 10:20:46 unixarea kernel: wlan0: scan_task: chan 7g - 11g [active, dwell min 20ms max 150ms] Dec 21 10:20:46 unixarea kernel: wlan0: scan_task: stopped, [ticks 352124, dwell min 20 scanend 352107] Dec 21 10:20:46 unixarea kernel: wlan0: ieee80211_bg_scan: active scan, ticks 352161 duration 150 Dec 21 10:20:46 unixarea kernel: wlan0: scan_task: chan 7g - 7g [active, dwell min 20ms max 150ms] Dec 21 10:20:46 unixarea kernel: [00:13:f7:0d:08:48] new probe_resp on chan 7 (bss chan 7) tarara rssi 84 Dec 21 10:20:46 unixarea kernel: [00:13:f7:0d:08:48] caps 0x431 bintval 100 erp 0x100 country [NL 1-13,20] Dec 21 10:20:46 unixarea kernel: [00:13:f7:0d:08:48] new probe_resp on chan 7 (bss chan 7) tarara rssi 84 Dec 21 10:20:46 unixarea kernel: [00:13:f7:0d:08:48] caps 0x431 bintval 100 erp 0x100 country [NL 1-13,20] Dec 21 10:20:46 unixarea kernel: wlan0: ieee80211_cancel_anyscan: cancel active scan Dec 21 10:20:46 unixarea kernel: wlan0: scan_task: done, [ticks 352209, dwell min 20
Re: BUG: run0 wifi driver
El día Saturday, December 20, 2014 a las 02:42:18PM -0800, solarflow99 escribió: Since this seems to be a BSD problem, I just wanted to report this as a possible bug and see if anyone else has a rt3072 driver working successfully? It used to work as run0 interface , but recently it doesn't work at all with the latest snapshots. Here are the details: https://forum.pfsense.org/index.php?topic=84481.0 There are no details in this thread. Enable debugging with 'wlandebug +...' and check /var/log/messages for the results. HIH matthias -- Matthias Apitz, g...@unixarea.de, http://www.unixarea.de/ +49-170-4527211 1989-2014: The Wall was torn down so that we go to war together again. El Muro ha sido derribado para que nos unimos en ir a la guerra otra vez. Diese Grenze wurde aufgehoben damit wir gemeinsam wieder in den Krieg ziehen. ___ 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: BUG: run0 wifi driver
El día Sunday, December 21, 2014 a las 10:18:11AM -0800, solarflow99 escribió: I can't get any debug info because it just hangs at boot up, or endlessly reboots (+Cc: freebsd-wireless, please keep it Cc'ed to get more/better help) Is this an USB Wifi dongle? If so, you plug it in later after boot. If not, you could compile a kernel enabling debugging and could boot with verbose messages matthias On Dec 21, 2014 2:43 AM, Matthias Apitz g...@unixarea.de wrote: El día Saturday, December 20, 2014 a las 02:42:18PM -0800, solarflow99 escribió: Since this seems to be a BSD problem, I just wanted to report this as a possible bug and see if anyone else has a rt3072 driver working successfully? It used to work as run0 interface , but recently it doesn't work at all with the latest snapshots. Here are the details: https://forum.pfsense.org/index.php?topic=84481.0 There are no details in this thread. Enable debugging with 'wlandebug +...' and check /var/log/messages for the results. HIH matthias -- Matthias Apitz, g...@unixarea.de, http://www.unixarea.de/ +49-170-4527211 1989-2014: The Wall was torn down so that we go to war together again. El Muro ha sido derribado para que nos unimos en ir a la guerra otra vez. Diese Grenze wurde aufgehoben damit wir gemeinsam wieder in den Krieg ziehen. -- Matthias Apitz, g...@unixarea.de, http://www.unixarea.de/ +49-170-4527211 1989-2014: The Wall was torn down so that we go to war together again. El Muro ha sido derribado para que nos unimos en ir a la guerra otra vez. Diese Grenze wurde aufgehoben damit wir gemeinsam wieder in den Krieg ziehen. ___ 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: Asus USB-N10 NANO
El día Wednesday, November 26, 2014 a las 02:14:14PM +0100, Idwer Vollering escribió: What should I do to get a USB Wifi card supported by the rsu(4) driver. Hi, I bought another one which was selled by Am* as: W-LAN 300 MBit USB 2.0 Adapter wifi Realtek Chipsatz RTL8191SU it arrived today and on plug-in it attaches the rsu(4) driver as: Dec 1 08:59:38 unixarea kernel: ugen4.4: vendor 0x0bda at usbus4 Dec 1 08:59:38 unixarea kernel: rsu0: vendor 0x0bda product 0x8172, class 0/0, rev 2.00/2.00, addr 4 on usbus4 Dec 1 08:59:38 unixarea kernel: rsu0: MAC/BB RTL8712 cut 3 Dec 1 08:59:39 unixarea kernel: wlan0: Ethernet address: 00:0d:09:a1:2e:16 and 'usbconfig dump_device_desc' says: ugen4.4: product 0x8172 vendor 0x0bda at usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA) bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0200 bDeviceClass = 0x bDeviceSubClass = 0x bDeviceProtocol = 0x bMaxPacketSize0 = 0x0040 idVendor = 0x0bda idProduct = 0x8172 bcdDevice = 0x0200 iManufacturer = 0x0001 Manufacturer Realtek iProduct = 0x0002 RTL8191S WLAN Adapter iSerialNumber = 0x0003 00e04c01 bNumConfigurations = 0x0001 Is there any diff between 'RTL8191S' and 'RTL8191SU'? Why the rsu(4) says: rsu0: MAC/BB RTL8712 cut 3? Thanks matthias -- Matthias Apitz, g...@unixarea.de, http://www.unixarea.de/ +49-170-4527211 1989-2014: The Wall was torn down so that we go to war together again. El Muro ha sido derribado para que nos unimos en ir a la guerra otra vez. Diese Grenze wurde aufgehoben damit wir gemeinsam wieder in den Krieg ziehen. ___ 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
Asus USB-N10 NANO
Hello, I purchased the above USB Wifi adapter in the hope it will attach to the rsu(4) driver because its man page says: ... The rsu driver provices support for Realtek RTL8188SU/RTL8192SU USB IEEE 802.11b/g/n wireless network adapters, including: ASUS USB-N10 Belkin F7D1101 v1 D-Link DWA-131 A1 ... Today the parcel arrived and on plug'in it is seen as: Nov 26 13:09:36 unixarea kernel: ugen4.4: vendor 0x0b05 at usbus4 Nov 26 13:09:36 unixarea kernel: urtwn0: vendor 0x0b05 product 0x17ba, class 0/0, rev 2.00/2.00, addr 4 on usbus4 Nov 26 13:09:36 unixarea kernel: urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R Nov 26 13:09:37 unixarea kernel: wlan0: Ethernet address: 10:c3:7b:cc:e6:46 and attaches ti the urtwn(4) driver :-( If I kldunload the if_urtwn it is not seen by the rsu(4) driver either. # kldstat ... 141 0xc85ea000 1f000rsu-rtl8712fw.ko 151 0xc7219000 a000 if_rsu.ko 161 0xc860b000 11000if_urtwn.ko RTL8188CUS is mentioned in the urtwn(4) page, and not in rsu(4) page. What should I do to get a USB Wifi card supported by the rsu(4) driver. I wanted to have a adapter supported by rsu(4) because the urtwn(4) has an issue in the every 5 minute bgscan and I wanted to make sure that this is also (or not) with rsu(4). All this is in 11-CURRENT. See also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195348 Thanks matthias -- Matthias Apitz, g...@unixarea.de, http://www.unixarea.de/ +49-170-4527211 1989-2014: The Wall was torn down so that we go to war together again. El Muro ha sido derribado para que nos unimos en ir a la guerra otra vez. Diese Grenze wurde aufgehoben damit wir gemeinsam wieder in den Krieg ziehen. ___ 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: Issues with urtwn
El día Monday, November 03, 2014 a las 09:43:14AM -0800, Adrian Chadd escribió: Ah, chances are it's being loaded automatically at startup when devd loads your USB wifi module. Just make sure you've commented out the wlan devices (but not options!) and rebuilt your kernel to not have wlan included. The problem is reproducible fine: I'm running in a loop SCP traffic up and down to my ISP host; when the background scan every five minutes takes place the traffic gets STALLED and IP comes not to work again: Nov 23 17:13:33 unixarea dhclient: New Broadcast Address (wlan0): 192.168.2.255 Nov 23 17:13:33 unixarea dhclient: New Routers (wlan0): 192.168.2.1 Nov 23 17:18:33 unixarea kernel: wlan0: ieee80211_bg_scan: active scan, ticks 36537257 duration 150 Nov 23 17:18:33 unixarea kernel: wlan0: [00:13:f7:0d:08:48] sta power save mode on Nov 23 17:18:33 unixarea kernel: wlan0: scan_task: chan 7g - 1g [active, dwell min 20ms max 150ms] Nov 23 17:18:33 unixarea kernel: wlan0: scan_task: stopped, [ticks 36537415, dwell min 20 scanend 36537408] from now the interface does not let pass frames anymore Nov 23 17:18:33 unixarea kernel: wlan0: ieee80211_sta_tim_notify: TIM=1 Nov 23 17:18:34 unixarea last message repeated 3 times Nov 23 17:18:34 unixarea kernel: wlan0: [00:13:f7:0d:08:48] save frame with age 40, 1 now queued Nov 23 17:18:34 unixarea kernel: wlan0: [00:13:f7:0d:08:48] save frame with age 0, 2 now queued Nov 23 17:18:34 unixarea kernel: wlan0: ieee80211_sta_tim_notify: TIM=1 Nov 23 17:18:35 unixarea last message repeated 14 times Nov 23 17:18:35 unixarea kernel: wlan0: [00:13:f7:0d:08:48] save frame with age 0, 3 now queued Nov 23 17:18:35 unixarea kernel: wlan0: ieee80211_sta_tim_notify: TIM=1 ... I tested the same in an older 10-ALPHA4 laptop (running r255948 from October 2013) with the same physical WLAN card; there is no problem with the bg scans every 5 minutes, it just goes ahead after any scan; this is an issue in head. matthias -- Matthias Apitz, g...@unixarea.de, http://www.unixarea.de/ +49-170-4527211 1989-2014: The Wall was torn down so that we go to war together again. El Muro ha sido derribado para que nos unimos en ir a la guerra otra vez. Diese Grenze wurde aufgehoben damit wir gemeinsam wieder in den Krieg ziehen. ___ 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: Issues with urtwn
El día Monday, November 03, 2014 a las 09:43:14AM -0800, Adrian Chadd escribió: Ah, chances are it's being loaded automatically at startup when devd loads your USB wifi module. Just make sure you've commented out the wlan devices (but not options!) and rebuilt your kernel to not have wlan included. I commented out only the 'device wlan' but this gives errors on linkage of the kernel, like: if_ath.o: In function `ath_ioctl_ratestats': /usr/src/sys/dev/ath/if_ath.c:6381: undefined reference to `ieee80211_find_node' if_ath.o: In function `ath_chan_change': /usr/src/sys/dev/ath/if_ath.c:5306: undefined reference to `ieee80211_chan2mode' if_ath.o: In function `ath_init': /usr/src/sys/dev/ath/if_ath.c:2455: undefined reference to `ieee80211_start_all' if_ath.o: In function `ath_vap_create': (many) Thx matthias -- Matthias Apitz | /\ ASCII Ribbon Campaign: E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X- No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign ___ 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: Issues with urtwn
El día Monday, November 03, 2014 a las 06:46:33AM +0100, Matthias Apitz escribió: El día Sunday, November 02, 2014 a las 10:46:13AM -0800, Adrian Chadd escribió: It's not forcing the adapter itself into ps mode - it's just net80211 doing an off-channel scan thing. Someone has to debug/fix this scan hang thing, I'm out of energy atm :( I'm willing to dig into this and will start with instrumenting net80211/ieee80211_scan.c with more debug messages; from there the power save is activated: ... While I can compile sys/modules/wlan/wlan.ko, I do not see how to make it undload / loadable from there; is it essential that it is loaded at boot time? The man page has no information about this :-( matthias -- Matthias Apitz | /\ ASCII Ribbon Campaign: E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X- No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign ___ 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: Issues with urtwn
Hi,
I do not understand why I have these 'powersave on/off' transitions:
Nov 2 09:01:06 unixarea kernel: wlan0: [00:13:f7:0d:08:48] sta power save mode
on
Nov 2 09:01:08 unixarea kernel: wlan0: [00:13:f7:0d:08:48] sta power save mode
off
Nov 2 09:06:08 unixarea kernel: wlan0: [00:13:f7:0d:08:48] sta power save mode
on
Nov 2 09:06:10 unixarea kernel: wlan0: [00:13:f7:0d:08:48] sta power save mode
off
Nov 2 09:11:11 unixarea kernel: wlan0: [00:13:f7:0d:08:48] sta power save mode
on
Nov 2 09:11:12 unixarea kernel: wlan0: [00:13:f7:0d:08:48] sta power save mode
off
# ifconfig wlan0 -powersave
# ifconfig -v wlan0 | fgrep power
AES-CCM 3:128-bit powersavemode OFF powersavesleep 100 txpower 0
i.e. it seems to be OFF, I even can not set it to on:
# ifconfig wlan0 powersave
ifconfig: SIOCS80211: Operation not supported
What I do can set is the powersavesleep interval to zero:
# ifconfig wlan0 powersavesleep 0
# ifconfig -v wlan0 | fgrep power
AES-CCM 3:128-bit powersavemode OFF powersavesleep 0 txpower 0
But this does not help either.
I fgrep'ed throu the src/sys and it seems that the power save mode
on/off message comes out from
/usr/src/sys/net80211/ieee80211_power.c
/*
* Handle power-save state change in station mode.
*/
void
ieee80211_sta_pwrsave(struct ieee80211vap *vap, int enable)
{
struct ieee80211_node *ni = vap-iv_bss;
if (!((enable != 0) ^ ((ni-ni_flags IEEE80211_NODE_PWR_MGT) != 0)))
return;
IEEE80211_NOTE(vap, IEEE80211_MSG_POWER, ni,
sta power save mode %s, enable ? on : off);
but this does not answer the question why is switching it on/off.
Is it worth to compile a hard change an let return
ieee80211_sta_pwrsave() without doing anything?
Any ideas?
matthias
--
Matthias Apitz | /\ ASCII Ribbon Campaign:
E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail
WWW: http://www.unixarea.de/ | X- No proprietary attachments
phone: +49-170-4527211 | / \ - Respect for open standards
| en.wikipedia.org/wiki/ASCII_Ribbon_Campaign
___
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: Issues with urtwn
El día Sunday, November 02, 2014 a las 07:24:02AM -0800, Nathan Whitehorn escribió: Are you running wpa_supplicant? If you can connect to a plain network with ifconfig, these will stop. -Nathan I do run wpa_supplicant. But I don't understand what you mean with If you can connect to a plain network with ifconfig ... wlan0 has an IP addr (via DHCP from the AP) and I can connect. What do you mean with to a plain network with ifconfig ...? Thx matthias -- Matthias Apitz | /\ ASCII Ribbon Campaign: E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X- No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign ___ 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: Issues with urtwn
El día Sunday, November 02, 2014 a las 10:46:13AM -0800, Adrian Chadd escribió:
It's not forcing the adapter itself into ps mode - it's just net80211
doing an off-channel scan thing.
Someone has to debug/fix this scan hang thing, I'm out of energy atm :(
I'm willing to dig into this and will start with instrumenting
net80211/ieee80211_scan.c with more debug messages; from there the power
save is activated:
scan_task(void *arg, int pending)
...
if (vap-iv_opmode == IEEE80211_M_STA
vap-iv_state == IEEE80211_S_RUN) {
if ((vap-iv_bss-ni_flags IEEE80211_NODE_PWR_MGT) == 0) {
/* Enable station power save mode */
vap-iv_sta_ps(vap, 1);
Or any other idea? Can you guide me through this?
Thx
matthias
--
Matthias Apitz | /\ ASCII Ribbon Campaign:
E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail
WWW: http://www.unixarea.de/ | X- No proprietary attachments
phone: +49-170-4527211 | / \ - Respect for open standards
| en.wikipedia.org/wiki/ASCII_Ribbon_Campaign
___
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: Issues with urtwn
El día Sunday, October 26, 2014 a las 08:36:05AM +0100, Matthias Apitz escribió: # ifconfig wlan0 list sta ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG 00:13:f7:0d:08:4827 54M 35.50 1219 64016 EPS AE RSN the kernel is 11-CURRENT (r269739) and I have IEEE80211_DEBUG enabled: # fgrep IEEE80211_DEBUG sys/i386/conf/GENERIC options IEEE80211_DEBUG # enable debug msgs # wlandebug -i wlan0 +state +power net.wlan.0.debug: 0x0 = 0xcstate,power I have had another look up with these messages in /var/log/messages: Nov 1 08:44:39 unixarea kernel: wlan0: Ethernet address: 80:1f:02:ee:16:37 Nov 1 08:44:44 unixarea kernel: wlan0: link state changed to UP Nov 1 08:49:44 unixarea kernel: wlan0: [00:13:f7:0d:08:48] sta power save mode on Nov 1 08:49:46 unixarea kernel: wlan0: [00:13:f7:0d:08:48] sta power save mode off Nov 1 08:54:46 unixarea kernel: wlan0: [00:13:f7:0d:08:48] sta power save mode on Nov 1 08:54:46 unixarea kernel: wlan0: [00:13:f7:0d:08:48] save frame with age 40, 1 now queued Nov 1 08:54:46 unixarea kernel: wlan0: [00:13:f7:0d:08:48] sta power save mode off Nov 1 08:54:46 unixarea kernel: wlan0: [00:13:f7:0d:08:48] flush ps queue, 1 packets queued Nov 1 08:54:47 unixarea kernel: wlan0: [00:13:f7:0d:08:48] sta power save mode on Nov 1 08:54:48 unixarea kernel: wlan0: [00:13:f7:0d:08:48] sta power save mode off Nov 1 08:59:48 unixarea kernel: wlan0: [00:13:f7:0d:08:48] sta power save mode on Nov 1 08:59:48 unixarea kernel: wlan0: [00:13:f7:0d:08:48] save frame with age 40, 1 now queued Nov 1 08:59:50 unixarea kernel: wlan0: [00:13:f7:0d:08:48] sta power save mode off Nov 1 08:59:50 unixarea kernel: wlan0: [00:13:f7:0d:08:48] flush ps queue, 1 packets queued Nov 1 09:03:40 unixarea kernel: wlan0: beacon miss, mode STA state RUN Nov 1 09:03:41 unixarea kernel: wlan0: beacon miss, mode STA state RUN Nov 1 09:03:41 unixarea kernel: wlan0: ieee80211_new_state_locked: RUN - SCAN (nrunning 0 nscanning 0) Nov 1 09:03:41 unixarea kernel: wlan0: ieee80211_newstate_cb: RUN - SCAN arg 0 Nov 1 09:03:41 unixarea kernel: wlan0: sta_newstate: RUN - SCAN (0) Nov 1 09:03:41 unixarea kernel: wlan0: link state changed to DOWN Nov 1 09:03:44 unixarea kernel: wlan0: [00:13:f7:0d:08:48] station assoc via MLME Nov 1 09:03:44 unixarea kernel: wlan0: ieee80211_new_state_locked: SCAN - AUTH (nrunning 0 nscanning 0) Nov 1 09:03:44 unixarea kernel: wlan0: ieee80211_newstate_cb: SCAN - AUTH arg 192 Nov 1 09:03:44 unixarea kernel: wlan0: sta_newstate: SCAN - AUTH (192) Nov 1 09:03:46 unixarea kernel: wlan0: ieee80211_new_state_locked: AUTH - SCAN (nrunning 0 nscanning 0) Nov 1 09:03:46 unixarea kernel: wlan0: ieee80211_newstate_cb: AUTH - SCAN arg 1 Nov 1 09:03:46 unixarea kernel: wlan0: sta_newstate: AUTH - SCAN (1) Nov 1 09:03:54 unixarea kernel: wlan0: [00:13:f7:0d:08:48] station deauth via MLME (reason 3) Nov 1 09:03:54 unixarea kernel: wlan0: ieee80211_new_state_locked: SCAN - INIT (nrunning 0 nscanning 0) Nov 1 09:03:54 unixarea kernel: wlan0: ieee80211_newstate_cb: SCAN - INIT arg 3 Nov 1 09:03:54 unixarea kernel: wlan0: sta_newstate: SCAN - INIT (3) Nov 1 09:03:55 unixarea kernel: wlan0: ieee80211_new_state_locked: INIT - SCAN (nrunning 0 nscanning 0) Nov 1 09:03:55 unixarea kernel: wlan0: ieee80211_newstate_cb: INIT - SCAN arg 0 Nov 1 09:03:55 unixarea kernel: wlan0: sta_newstate: INIT - SCAN (0) -- Matthias Apitz | /\ ASCII Ribbon Campaign: E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X- No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign ___ 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: Issues with urtwn
El día Monday, September 08, 2014 a las 03:17:08PM -0700, Adrian Chadd escribió: Please compile your kernel with IEEE80211_DEBUG, then enable debugging - wlandebug +state +power You can disable powersave with 'ifconfig wlan0 -powersave', but it shouldn't be enabled by default. Hi, I was to fast when saying in September that I do not have any issue with this NIC: under havy SCP traffic (let's say some GByte) the connection locks and I have to run 'netif restart' to wake it up; it seems that powersave is off: # ifconfig wlan0 list sta ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG 00:13:f7:0d:08:4827 54M 35.50 1219 64016 EPS AE RSN the kernel is 11-CURRENT (r269739) and I have IEEE80211_DEBUG enabled: # fgrep IEEE80211_DEBUG sys/i386/conf/GENERIC options IEEE80211_DEBUG # enable debug msgs # wlandebug -i wlan0 +state +power net.wlan.0.debug: 0x0 = 0xcstate,power In /var/log/messages I see now lines like this: # fgrep kernel /var/log/messages Oct 26 08:22:44 unixarea kernel: wlan0: [00:13:f7:0d:08:48] sta power save mode on Oct 26 08:22:46 unixarea kernel: wlan0: [00:13:f7:0d:08:48] sta power save mode off Oct 26 08:27:46 unixarea kernel: wlan0: [00:13:f7:0d:08:48] sta power save mode on Oct 26 08:27:48 unixarea kernel: wlan0: [00:13:f7:0d:08:48] sta power save mode off Oct 26 08:32:48 unixarea kernel: wlan0: [00:13:f7:0d:08:48] sta power save mode on Oct 26 08:32:50 unixarea kernel: wlan0: [00:13:f7:0d:08:48] sta power save mode off every 5 minutes... Who is switching this on/off? thx matthias -- Matthias Apitz | /\ ASCII Ribbon Campaign: E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X- No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign ___ 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: Issues with urtwn
El día Monday, September 08, 2014 a las 08:19:45AM +0200, Vladimir Botka
escribió:
Hi Vladimir,
maybe the wpa_passphrase utility could help you to create the config.
In this particular case:
$ wpa_passphrase Naturhotel Wieserhof N@tur%Wieser
network={
ssid=Naturhotel Wieserhof
#psk=N@tur%Wieser
psk=b853709a9edcd50edf0835f68bf099255cb32fc462e492117fe3c42ab2a387cb
}
What is the benefit of coding the PSK? I have never used it; the
wpa_supplicant.conf file tested was:
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=wheel
eapol_version=1
ap_scan=1
fast_reauth=1
# Hotel Wieserhof
#
network={
ssid=Naturhotel Wieserhof
scan_ssid=1
# key_mgmt=WPA-PSK WPA-EAP IEEE8021X
key_mgmt=WPA-PSK
# key_mgmt=WPA-PSK WPA-EAP
psk=N@tur%Wieser
# key_mgmt=NONE
# wep_tx_keyidx=0
# wep_key0=N@tur%Wieser
}
as you see in the comments, I tested a lot of different key_mgmt=
values; the one shown active, gave the best results (but only in my
hotel room, not in the lobby);
,or you might want to try wpa_gui.
I have never used it, but will install the port and give it a try next
time.
Thx
matthias
PD: To Adrian, I'm willing to file a PR, but the problem is, I will not
return to this hotel and can not provide more information or tests.
--
Matthias Apitz | /\ ASCII Ribbon Campaign:
E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail
WWW: http://www.unixarea.de/ | X- No proprietary attachments
phone: +49-170-4527211 | / \ - Respect for open standards
| en.wikipedia.org/wiki/ASCII_Ribbon_Campaign
___
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: Broadcom BCM4312 802.11b/g in 11-CURRENT r269739
El día Saturday, August 16, 2014 a las 05:25:09PM +0200, Matthias Apitz escribió: Hello, I have a 11-CURRENT from August 8, and ports from the day after: FreeBSD tiny-r269739 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r269739M: Fri Aug 15 18:07:41 CEST 2014 guru@vm-tiny-r269739:/usr/obj/usr/src/sys/GENERIC i386 The configuration used for the Wifi card is: rc.conf: wlans_bwn0=wlan0 ifconfig_wlan0=WPA DHCP loader.conf if_bwn_load=YES bwn_v4_lp_ucode_load=YES The Wifi comes up fine on boot with WPA and DHCP assigns IP addr and routing: wlan0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 90:4c:e5:00:06:ce inet 192.168.2.100 netmask 0xff00 broadcast 192.168.2.255 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: IEEE 802.11 Wireless Ethernet OFDM/54Mbps mode 11g status: associated ssid tarara channel 7 (2442 MHz 11g) bssid 00:13:f7:0d:08:48 country US authmode WPA2/802.11i privacy ON deftxkey UNDEF AES-CCM 4:128-bit txpower 30 bmiss 7 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS wme roaming MANUAL I even can do a DNS lookup and transfer some ~10 PING to Internet, but after this it gets stuck. Below is a 'dmesg | fgrep -i bwn'. Let me know if someone needs a complete dmesg output. I have recompiled if_bwn.c with -DBWN_DEBUG and set hw.bwn.debug=15 in /boot/loader.conf; an output of 'dmesg | fgrep bwn' is attached. IP addr gets assigned via DHCP and some 20 IMCP packages can be sent. After this, the traffic gets stuck. If someone (the author of the driver or the port of net/bwn*) is willing to guide my through the debugging, here I am. Thanks matthias Preloaded elf module /boot/kernel/if_bwn.ko at 0xc183d8e8. Preloaded elf module /boot/kernel/siba_bwn.ko at 0xc183dc6c. Preloaded elf module /boot/modules/bwn_v4_lp_ucode.ko at 0xc183e01c. firmware: 'bwn_v4_lp_ucode' version 0: 0 bytes loaded at 0xc1811084 firmware: 'bwn_v4_lp_ucode5' version 0: 22264 bytes loaded at 0xc1811084 firmware: 'bwn_v4_lp_ucode11' version 0: 32776 bytes loaded at 0xc181677c firmware: 'bwn_v4_lp_ucode13' version 0: 31440 bytes loaded at 0xc181e784 firmware: 'bwn_v4_lp_ucode14' version 0: 31000 bytes loaded at 0xc1826254 firmware: 'bwn_v4_lp_ucode15' version 0: 34672 bytes loaded at 0xc182db6c firmware: 'bwn_v4_lp_pcm5' version 0: 1320 bytes loaded at 0xc18362dc firmware: 'bwn_v4_lp_a0g1initvals5' version 0: 1848 bytes loaded at 0xc1836804 firmware: 'bwn_v4_lp_a0g0initvals5' version 0: 1848 bytes loaded at 0xc1836f3c firmware: 'bwn_v4_lp_b0g0initvals5' version 0: 1848 bytes loaded at 0xc1837674 firmware: 'bwn_v4_lp_b0g0initvals13' version 0: 2126 bytes loaded at 0xc1837dac firmware: 'bwn_v4_lp_a0g1bsinitvals5' version 0: 178 bytes loaded at 0xc18385fa firmware: 'bwn_v4_lp_a0g0bsinitvals5' version 0: 178 bytes loaded at 0xc18386ac firmware: 'bwn_v4_lp_b0g0bsinitvals5' version 0: 178 bytes loaded at 0xc183875e firmware: 'bwn_v4_lp_lp0initvals13' version 0: 3664 bytes loaded at 0xc1838810 firmware: 'bwn_v4_lp_lp0initvals14' version 0: 2110 bytes loaded at 0xc1839660 firmware: 'bwn_v4_lp_lp0initvals15' version 0: 2282 bytes loaded at 0xc1839e9e firmware: 'bwn_v4_lp_lp0bsinitvals13' version 0: 178 bytes loaded at 0xc183a788 firmware: 'bwn_v4_lp_lp0bsinitvals14' version 0: 178 bytes loaded at 0xc183a83a firmware: 'bwn_v4_lp_lp0bsinitvals15' version 0: 178 bytes loaded at 0xc183a8ec firmware: 'bwn_v4_lp_n0bsinitvals11' version 0: 178 bytes loaded at 0xc183a99e siba_bwn0: Broadcom BCM4312 802.11b/g Wireless mem 0x5710-0x57103fff irq 16 at device 0.0 on pci1 bwn0 on siba_bwn0 bwn0: WLAN (chipid 0x4312 rev 15) PHY (analog 6 type 5 rev 1) RADIO (manuf 0x17f ver 0x2062 rev 2) bwn0: DMA (64 bits) bwn0: MSI count : 1 siba_bwn0: attempting to allocate 1 MSI vectors (1 supported) siba_bwn0: using IRQ 257 for MSI bwn0: Using 1 MSI messages bwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps bwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps bwn_init: if_flags 0x8803 bwn0: firmware version (rev 478 patch 104 date 0x8701 time 0x657) bwn_newstate: INIT - SCAN bwn_newstate: SCAN - AUTH bwn_newstate: AUTH - ASSOC bwn_newstate: ASSOC - RUN bwn0: need multicast update callback bwn0: RX decryption attempted (old 0 keyidx 0x2) bwn0: RX decryption attempted (old 0 keyidx 0x2) bwn0: need multicast update callback bwn0: need multicast update callback bwn0: RX decryption attempted (old 0 keyidx 0x2) bwn0: RX decryption attempted (old 0 keyidx 0x2) bwn0: RX decryption attempted (old 0 keyidx 0x2) bwn0: RX decryption attempted (old 0 keyidx 0x2) bwn0: RX decryption attempted (old 0 keyidx 0x2) bwn0: RX decryption attempted (old 0 keyidx 0x2) bwn0: RX decryption attempted (old 0 keyidx 0x2) bwn0: RX decryption attempted (old 0 keyidx 0x2) bwn0: RX decryption attempted (old 0 keyidx 0x2) bwn0: RX decryption attempted
Re: [rfc] removing the NDISulator
El día Friday, October 18, 2013 a las 02:19:42PM -0700, Adrian Chadd escribió: I'd really like to see bwi/bwn maintained and have support added for the later hardware. Hi Adrian, $ pciconf -vl ndis0@pci0:1:0:0: class=0x028000 card=0xe01b105b chip=0x431514e4 rev=0x01 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM4312 802.11b/g LP-PHY' class = network I'm using NDIS as well in r250588. Is bwi/bwn the point to start to look into for this chip? Thanks matthias -- Matthias Apitz | /\ ASCII Ribbon Campaign: www.asciiribbon.org E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards ___ 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: Q: support for Broadcom BCM4312 802.11b/g Wireless
El día Thursday, May 16, 2013 a las 11:28:07PM -0700, Adrian Chadd escribió: There's unfortunately no active bwn driver maintainer. What is/was the state of this? Has it worked once and only needs now debugging and/or updating? Thx matthias -- Sent from my FreeBSD netbook Matthias Apitz | - No system with backdoors like Apple/Android E-mail: g...@unixarea.de | - Never being an iSlave WWW: http://www.unixarea.de/ | - No proprietary attachments, no HTML/RTF in E-mail phone: +49-170-4527211 | - Respect for open standards ___ 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
