Connection Problems with on QCA9880-BR4A

[Michal Kazior]

On 15 November 2016 at 13:59, Felix <kramerfe at gmail.com> wrote:
[...]
>>> cat /etc/wpa_supplicant/wpa_supplicant.conf
> ctrl_interface=/var/run/wpa_supplicant
> network={
>     ssid="eduroam"
>     proto=RSN
>     pairwise=CCMP
>     group=CCMP
>     key_mgmt=WPA-EAP
>     eap=TTLS
>     domain_suffix_match="XXX"
>     phase1="peaplabel=0"
>     anonymous_identity="anonymous at XXX"
>     phase2="auth=PAP"
>     ca_cert="XXX"
>     identity="XXX"
>     password="XXX"
> }
>
>>> wpa_supplicant -i wlan0 -D nl80211 -c
>>> /etc/wpa_supplicant/wpa_supplicant.conf
> Successfully initialized wpa_supplicant
> wlan0: SME: Trying to authenticate with XXX (SSID='eduroam' freq=5240 MHz)
> wlan0: Trying to associate with XXX (SSID='eduroam' freq=5240 MHz)
> wlan0: Associated with XXX
> wlan0: CTRL-EVENT-EAP-STARTED EAP authentication started
> wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=21
> wlan0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 21 (TTLS) selected
> wlan0: CTRL-EVENT-REGDOM-CHANGE init=COUNTRY_IE type=COUNTRY alpha2=XXX
> wlan0: CTRL-EVENT-EAP-PEER-CERT depth=3 subject='XXX'
> wlan0: CTRL-EVENT-EAP-PEER-CERT depth=2 subject='XXX'
> wlan0: CTRL-EVENT-EAP-PEER-CERT depth=1 subject='XXX'
> wlan0: CTRL-EVENT-EAP-PEER-CERT depth=0 subject='XXX'
> wlan0: CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully
> wlan0: WPA: Key negotiation completed with XXX [PTK=CCMP GTK=CCMP]
> wlan0: CTRL-EVENT-CONNECTED - Connection to XXX completed [id=0 id_str=]
> wlan0: CTRL-EVENT-DISCONNECTED bssid=XXX reason=2

How long is CONNECTED away from DISCONNECTED? Running with "-t" should
add timestamps. At this point I would suggest "-ddd" to get verbose
logs.


>>> cat /etc/dhcp/dhclient.conf
> option rfc3442-classless-static-routes code 121 = array of unsigned integer
> 8;
> supersede dhcp-server-identifier 255.255.255.255;
> request subnet-mask, broadcast-address, time-offset, routers, interface-mtu,
> rfc3442-classless-static-routes;
> timeout 30;
> retry 30;
>
>>> journalctl -b | grep dhclient
> Nov 15 12:32:57 android10278 dhclient[852]: DHCPREQUEST on wlan0 to
> 255.255.255.255 port 67
[...]
>
>>> tcpdump -i wlan0
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on wlan0, link-type EN10MB (Ethernet), capture size 262144 bytes
> 12:26:31.765188 ARP, Request who-has 8.8.8.8 tell 192.168.0.1, length 28
> 12:26:31.765227 ARP, Request who-has 8.8.4.4 tell 192.168.0.1, length 28
[...]
> 12:26:57.181480 EAP packet (0) v2, len 6
> 12:26:57.192997 EAP packet (0) v2, len 1024
> 12:26:57.193250 EAP packet (0) v2, len 6
> 12:26:57.203442 EAP packet (0) v2, len 1024
> 12:26:57.203690 EAP packet (0) v2, len 6
> 12:26:57.214876 EAP packet (0) v2, len 461
> 12:26:57.228167 EAP packet (0) v2, len 140
> 12:26:57.238101 EAP packet (0) v2, len 69
> 12:26:57.239395 EAP packet (0) v2, len 144
> 12:26:57.309948 EAP packet (0) v2, len 4
> 12:26:57.310261 EAPOL key (3) v2, len 117
> 12:26:57.314455 EAPOL key (3) v2, len 117
> 12:26:57.316151 EAPOL key (3) v2, len 151
> 12:26:57.316485 EAPOL key (3) v2, len 95

This suggests key exchange has completed.


> 12:26:57.379388 IP XXX.152.54.netbios-ns > XXX.155.255.netbios-ns: NBT UDP
> PACKET(137): QUERY; REQUEST; BROADCAST
> 12:26:57.388661 IP XXX.154.22.netbios-ns > XXX.155.255.netbios-ns: NBT UDP
> PACKET(137): QUERY; REQUEST; BROADCAST
[...]
> 452 packets captured
> 8348 packets received by filter
> 7896 packets dropped by kernel#

What happened to all the packets? Are you really running just
"tcpdump" or are you applying pcap filters that you didn't mention?

There are no DHCP requests so either firmware is refusing to transmit
them OTA, have been filtered by kernel/tcpdump or you have some
firewall rule that drops the packets. Tcpdump does report some traffic
which I infer is just Rx suggesting crypto is (at least partially) set
up. Is there something you're not telling about your setup?

Can you load ath10k_core with debug_mask=0xffffff3f and provide logs?


Michał