Ok. Hm. I'm seeing the same in hostap mode. I wonder if I broke something. I'll go do some further digging and let you know. You could try this:
wlandebug -i wlan0 +crypto +assoc see if it gives you any further useful debugging. Adrian On 25 March 2013 12:11, Mark Austin <ganth...@gmail.com> wrote: > Okay. I removed the line, killed off wpa_supplicant and started a new > daemon. Logging still drops: > > Trying to associate with 00:1f:6d:b8:c1:e1 (SSID='tea' freq=2422 MHz) > Associated with 00:1f:6d:b8:c1:e1 > WPA: Key negotiation completed with 00:1f:6d:b8:c1:e1 [PTK=TKIP GTK=TKIP] > CTRL-EVENT-CONNECTED - Connection to 00:1f:6d:b8:c1:e1 completed (reauth) > [id=0 id_str=] > WPA: Group rekeying completed with 00:1f:6d:b8:c1:e1 [GTK=TKIP] > WPA: Group rekeying completed with 00:1f:6d:b8:c1:e1 [GTK=TKIP] > CTRL-EVENT-DISCONNECTED bssid=00:1f:6d:b8:c1:e1 reason=0 > > > > Regards, > -Mark Austin > > All else is in doubt, so this is the truth that I cling to. > > My Website: http://www.silverdire.com > > > > On Mon, Mar 25, 2013 at 2:42 PM, Adrian Chadd <adr...@freebsd.org> wrote: > >> That's just due to channel scanning. It's harmless. >> >> Just remove the key_mgmt line, it's not needed for WPA/WPA2. >> >> >> >> Adrian >> >> >> On 25 March 2013 11:33, Mark Austin <ganth...@gmail.com> wrote: >> >>> In addition, the kernel outputs this a lot: >>> ath0: ath_edma_recv_proc_queue: handled npkts 0 >>> >>> >>> Regards, >>> -Mark Austin >>> >>> All else is in doubt, so this is the truth that I cling to. >>> >>> My Website: http://www.silverdire.com >>> >>> >>> >>> On Mon, Mar 25, 2013 at 2:32 PM, Mark Austin <ganth...@gmail.com> wrote: >>> >>>> ctrl_interface=/var/run/wpa_supplicant >>>> ctrl_interface_group=wheel >>>> update_config=1 >>>> >>>> network={ >>>> ssid="tea" >>>> psk="removed the password for obvious reasons" >>>> key_mgmt=WPA-PSK >>>> } >>>> >>>> >>>> >>>> Regards, >>>> -Mark Austin >>>> >>>> All else is in doubt, so this is the truth that I cling to. >>>> >>>> My Website: http://www.silverdire.com >>>> >>>> >>>> >>>> On Mon, Mar 25, 2013 at 2:31 PM, Mark Austin <ganth...@gmail.com>wrote: >>>> >>>>> wpa_supplicant logs: >>>>> >>>>> Trying to associate with 00:1f:6d:b8:c1:e1 (SSID='tea' freq=2422 MHz) >>>>> Associated with 00:1f:6d:b8:c1:e1 >>>>> *WPA: Key negotiation completed with 00:1f:6d:b8:c1:e1 [PTK=TKIP >>>>> GTK=TKIP]* >>>>> CTRL-EVENT-CONNECTED - Connection to 00:1f:6d:b8:c1:e1 completed >>>>> (reauth) [id=0 id_str=] >>>>> WPA: Group rekeying completed with 00:1f:6d:b8:c1:e1 [GTK=TKIP] >>>>> WPA: Group rekeying completed with 00:1f:6d:b8:c1:e1 [GTK=TKIP] >>>>> CTRL-EVENT-DISCONNECTED bssid=00:1f:6d:b8:c1:e1 *reason=0* >>>>> * >>>>> * >>>>> My test wpa_supplicant.conf file is: >>>>> >>>>> >>>>> >>>>> >>>>> Regards, >>>>> -Mark Austin >>>>> >>>>> All else is in doubt, so this is the truth that I cling to. >>>>> >>>>> My Website: http://www.silverdire.com >>>>> >>>>> >>>>> >>>>> On Mon, Mar 25, 2013 at 2:27 PM, Adrian Chadd <adr...@freebsd.org>wrote: >>>>> >>>>>> Ok, so hm. Try running wpa_supplicant manually. >>>>>> >>>>>> wpa_supplicant -i wlan0 -c /etc/wpa_supplicant.conf >>>>>> >>>>>> See if it throws errors. >>>>>> >>>>>> >>>>>> >>>>>> Adrian >>>>>> >>>>>> >>>>>> On 25 March 2013 11:17, Mark Austin <ganth...@gmail.com> wrote: >>>>>> >>>>>>> Great. >>>>>>> >>>>>>> Now, when I attempt to connect to a WPA2 encrypted network, I get >>>>>>> the following output on the device in the console: >>>>>>> >>>>>>> wlan0: flags=8c43<UP,BROADCAST,RUNNING,OACTIVE,SIMPLEX,MULTICAST> >>>>>>> metric 0 mtu 1500 >>>>>>> ether 84:4b:f5:2e:7e:2b >>>>>>> inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 >>>>>>> nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> >>>>>>> media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) >>>>>>> status: no carrier >>>>>>> ssid tea channel 9 (2452 MHz 11g) >>>>>>> regdomain 108 indoor ecm authmode WPA privacy ON deftxkey >>>>>>> UNDEF >>>>>>> txpower 20 bmiss 7 scanvalid 60 protmode CTS wme burst >>>>>>> roaming MANUAL >>>>>>> root@asher:/home/ganthore # >>>>>>> >>>>>>> DHCP appears to never pickup an ip address. (Tested on other >>>>>>> systems, works fine.) >>>>>>> >>>>>>> The ssid and authmode are correct... >>>>>>> >>>>>>> On /boot/loader.conf, I have if_ath_pci_load="YES" set. >>>>>>> >>>>>>> In /etc/rc.conf, I have the following params set: >>>>>>> >>>>>>> zfs_enable="YES" >>>>>>> ifconfig_bge0="inet 10.71.0.253 netmask 255.255.0.0" >>>>>>> defaultrouter="10.71.0.1" >>>>>>> wlans_ath0="wlan0" >>>>>>> ifconfig_wlan0="WPA DHCP" >>>>>>> >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> -Mark Austin >>>>>>> >>>>>>> All else is in doubt, so this is the truth that I cling to. >>>>>>> >>>>>>> My Website: http://www.silverdire.com >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, Mar 25, 2013 at 12:36 PM, Adrian Chadd >>>>>>> <adr...@freebsd.org>wrote: >>>>>>> >>>>>>>> Sweet. Looks good! >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Adrian >>>>>>>> >>>>>>>> >>>>>>>> On 25 March 2013 08:46, Mark Austin <ganth...@gmail.com> wrote: >>>>>>>> >>>>>>>>> Good news. I can see the device from the os tools now. It >>>>>>>>> registers as ath0, I also have a rule setup in my /etc/rc.conf to >>>>>>>>> have ath0 >>>>>>>>> identified as wlan0. >>>>>>>>> >>>>>>>>> The kernel message log shows: >>>>>>>>> ath0: <Atheros AR946x/AR948x> mem 0xc2400000-0xc247ffff irq 17 at >>>>>>>>> device 0.0 on pci3 >>>>>>>>> >>>>>>>>> ar9300_set_stub_functions: setting stub functions >>>>>>>>> >>>>>>>>> >>>>>>>>> ar9300_set_stub_functions: setting stub functions >>>>>>>>> >>>>>>>>> >>>>>>>>> ar9300_attach: calling ar9300_hw_attach >>>>>>>>> >>>>>>>>> >>>>>>>>> ar9300_hw_attach: calling ar9300_eeprom_attach >>>>>>>>> >>>>>>>>> >>>>>>>>> ar9300_flash_map: unimplemented for now >>>>>>>>> >>>>>>>>> >>>>>>>>> Restoring Cal data from DRAM >>>>>>>>> >>>>>>>>> >>>>>>>>> Restoring Cal data from EEPROM >>>>>>>>> >>>>>>>>> >>>>>>>>> Restoring Cal data from Flash >>>>>>>>> >>>>>>>>> >>>>>>>>> Restoring Cal data from Flash >>>>>>>>> >>>>>>>>> >>>>>>>>> Restoring Cal data from OTP >>>>>>>>> >>>>>>>>> >>>>>>>>> ar9300_hw_attach: ar9300_eeprom_attach returned 0 >>>>>>>>> ar9300_fill_capability_info: (MCI) MCI support = 1 >>>>>>>>> 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 >>>>>>>>> ar9300_freebsd_setup_x_tx_desc: called, 0x0/0, 0x0/0, 0x0/0 >>>>>>>>> ath_hal_init_channels: cc=0, regdmn=240 >>>>>>>>> getchannels: cc 0 regDmn 0xf0 mode 0xffffff ecm >>>>>>>>> getregstate: EEPROM cc 0 rd 0x10 >>>>>>>>> getregstate: EEPROM rd 0x6c >>>>>>>>> getchannels: !avail mode 0x1f800d (0x2) flags 0x2150 >>>>>>>>> getchannels: !avail mode 0x1f800d (0x20) flags 0xd0 >>>>>>>>> getchannels: !avail mode 0x1f800d (0x40) flags 0x150 >>>>>>>>> getchannels: !avail mode 0x1f800d (0x400) flags 0x8140 >>>>>>>>> getchannels: !avail mode 0x1f800d (0x200) flags 0x4140 >>>>>>>>> getchannels: !avail mode 0x1f800d (0x1000) flags 0x8480 >>>>>>>>> getchannels: !avail mode 0x1f800d (0x800) flags 0x4480 >>>>>>>>> ath_hal_init_channels: status=0, currentRD=108 >>>>>>>>> assignPrivateChannels: private[ 0] 5180/0x80340 -> channel 5180 >>>>>>>>> assignPrivateChannels: private[ 1] 5200/0x80340 -> channel 5200 >>>>>>>>> assignPrivateChannels: private[ 2] 5220/0x80340 -> channel 5220 >>>>>>>>> assignPrivateChannels: private[ 3] 5240/0x80340 -> channel 5240 >>>>>>>>> assignPrivateChannels: private[ 4] 5260/0x80340 -> channel 5260 >>>>>>>>> assignPrivateChannels: private[ 5] 5280/0x80340 -> channel 5280 >>>>>>>>> assignPrivateChannels: private[ 6] 5300/0x80340 -> channel 5300 >>>>>>>>> assignPrivateChannels: private[ 7] 5320/0x80340 -> channel 5320 >>>>>>>>> assignPrivateChannels: private[ 8] 5745/0x340 -> channel 5745 >>>>>>>>> assignPrivateChannels: private[ 9] 5765/0x340 -> channel 5765 >>>>>>>>> assignPrivateChannels: private[ 10] 5785/0x340 -> channel 5785 >>>>>>>>> assignPrivateChannels: private[ 11] 5805/0x340 -> channel 5805 >>>>>>>>> assignPrivateChannels: private[ 12] 5825/0x340 -> channel 5825 >>>>>>>>> assignPrivateChannels: private[ 13] 5500/0x80340 -> channel 5500 >>>>>>>>> assignPrivateChannels: private[ 14] 5520/0x80340 -> channel 5520 >>>>>>>>> assignPrivateChannels: private[ 15] 5540/0x80340 -> channel 5540 >>>>>>>>> assignPrivateChannels: private[ 16] 5560/0x80340 -> channel 5560 >>>>>>>>> assignPrivateChannels: private[ 17] 5580/0x80340 -> channel 5580 >>>>>>>>> assignPrivateChannels: private[ 18] 5600/0x80340 -> channel 5600 >>>>>>>>> assignPrivateChannels: private[ 19] 5620/0x80340 -> channel 5620 >>>>>>>>> assignPrivateChannels: private[ 20] 5640/0x80340 -> channel 5640 >>>>>>>>> assignPrivateChannels: private[ 21] 5660/0x80340 -> channel 5660 >>>>>>>>> assignPrivateChannels: private[ 22] 5680/0x80340 -> channel 5680 >>>>>>>>> assignPrivateChannels: private[ 23] 5700/0x80340 -> channel 5700 >>>>>>>>> assignPrivateChannels: private[ 24] 2412/0xa0 -> channel 2412 >>>>>>>>> assignPrivateChannels: private[ 25] 2417/0xa0 -> channel 2417 >>>>>>>>> assignPrivateChannels: private[ 26] 2422/0xa0 -> channel 2422 >>>>>>>>> assignPrivateChannels: private[ 27] 2427/0xa0 -> channel 2427 >>>>>>>>> assignPrivateChannels: private[ 28] 2432/0xa0 -> channel 2432 >>>>>>>>> assignPrivateChannels: private[ 29] 2437/0xa0 -> channel 2437 >>>>>>>>> assignPrivateChannels: private[ 30] 2442/0xa0 -> channel 2442 >>>>>>>>> assignPrivateChannels: private[ 31] 2447/0xa0 -> channel 2447 >>>>>>>>> assignPrivateChannels: private[ 32] 2452/0xa0 -> channel 2452 >>>>>>>>> assignPrivateChannels: private[ 33] 2457/0xa0 -> channel 2457 >>>>>>>>> assignPrivateChannels: private[ 34] 2462/0xa0 -> channel 2462 >>>>>>>>> assignPrivateChannels: private[ 35] 2467/0x2a0 -> channel 2467 >>>>>>>>> assignPrivateChannels: private[ 36] 2472/0x2a0 -> channel 2472 >>>>>>>>> assignPrivateChannels: 109 public, 37 private channels >>>>>>>>> ath_hal_init_channels: cc 0 >>>>>>>>> ath_hal_update_dfsdomain ah_dfsDomain: 2 >>>>>>>>> ath0: ath_edma_setup_rxfifo: type=0, FIFO depth = 16 entries >>>>>>>>> ath0: ath_edma_setup_rxfifo: type=1, FIFO depth = 128 entries >>>>>>>>> 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] 2 RX streams; 2 TX streams >>>>>>>>> ath0: AR9460 mac 640.2 RF5110 phy 3389.0 >>>>>>>>> ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0000 >>>>>>>>> wlan0: Ethernet address: 84:4b:f5:2e:7e:2b >>>>>>>>> >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> -Mark Austin >>>>>>>>> >>>>>>>>> All else is in doubt, so this is the truth that I cling to. >>>>>>>>> >>>>>>>>> My Website: http://www.silverdire.com >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Mon, Mar 25, 2013 at 11:05 AM, Mark Austin >>>>>>>>> <ganth...@gmail.com>wrote: >>>>>>>>> >>>>>>>>>> I didn't see any changes to the git tree. I updated my svn repo >>>>>>>>>> and rebuilding the kernel now. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> -Mark Austin >>>>>>>>>> >>>>>>>>>> All else is in doubt, so this is the truth that I cling to. >>>>>>>>>> >>>>>>>>>> My Website: http://www.silverdire.com >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Mon, Mar 25, 2013 at 10:59 AM, Mark Austin <ganth...@gmail.com >>>>>>>>>> > wrote: >>>>>>>>>> >>>>>>>>>>> This was added to the -HEAD code base? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> -Mark Austin >>>>>>>>>>> >>>>>>>>>>> All else is in doubt, so this is the truth that I cling to. >>>>>>>>>>> >>>>>>>>>>> My Website: http://www.silverdire.com >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Sun, Mar 24, 2013 at 12:43 AM, Adrian Chadd < >>>>>>>>>>> adr...@freebsd.org> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> I've just committed a new regulatory domain for you! >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Adrian >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 22 March 2013 14:05, Mark Austin <ganth...@gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Okay. I'll be available tonight and some parts over the >>>>>>>>>>>>> weekend in case you need any more testing. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> -Mark Austin >>>>>>>>>>>>> >>>>>>>>>>>>> All else is in doubt, so this is the truth that I cling to. >>>>>>>>>>>>> >>>>>>>>>>>>> My Website: http://www.silverdire.com >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Fri, Mar 22, 2013 at 3:12 PM, Adrian Chadd < >>>>>>>>>>>>> adr...@freebsd.org> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 22 March 2013 12:11, Mark Austin <ganth...@gmail.com>wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Okay. I made the 2 requested changes to the kernel source >>>>>>>>>>>>>>> code and changed my kenv var before reloading the module. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The kernel messages log shows (my emphasis in bold): >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ** >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> *Mar 22 19:02:49 asher kernel: ath_hal_init_channels: cc=0, >>>>>>>>>>>>>>> regdmn=240* >>>>>>>>>>>>>>> *Mar 22 19:02:49 asher kernel: getchannels: cc 0 regDmn >>>>>>>>>>>>>>> 0xf0 mode 0xffffff ecm* >>>>>>>>>>>>>>> *Mar 22 19:02:49 asher kernel: isEepromValid: invalid >>>>>>>>>>>>>>> regulatory domain/country code 0x6c* >>>>>>>>>>>>>>> *Mar 22 19:02:49 asher kernel: getregstate: invalid EEPROM >>>>>>>>>>>>>>> contents* >>>>>>>>>>>>>>> *Mar 22 19:02:49 asher kernel: ath_hal_init_channels: >>>>>>>>>>>>>>> status=16, currentRD=108* >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Right. I'm missing that regulatory domain. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'll have to go and look at what's missing and update the HAL >>>>>>>>>>>>>> regulatory domain. I'll start with that specific entry just so >>>>>>>>>>>>>> you can get >>>>>>>>>>>>>> working. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Adrian >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > _______________________________________________ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
