Skip to main content
Raspberry Pi

Return to Answer

Added comparision of wpa_supplicant debug output
Source Link
Ingo
Ingo
  • 43.1k
  • 20
  • 87
  • 207

UPDATE with comparing the debug output from wpa_supplicant:
I have reactivated my old SAMSUNG GALAXY S II with Android 4.1.2. It also connects without any problems. Here are the part of your wpa_supplicant debug output where it differs from mine:

hostapd_logger: STA 6c:c7:ec:4c:3f:f0 - sending 3/4 msg of 4-Way Handshake WPA: Send EAPOL(version=2 secure=0 mic=1 ack=1 install=1 pairwise=1 kde_len=28 keyidx=0 encr=0) WPA: Replay Counter - hexdump(len=8): 00 00 00 00 00 00 00 02 WPA: EAPOL-Key MIC using HMAC-SHA1 WPA: Use EAPOL-Key timeout of 1000 ms (retry counter 1) hostapd_logger: STA 6c:c7:ec:4c:3f:f0 - EAPOL-Key timeout WPA: 6c:c7:ec:4c:3f:f0 WPA_PTK entering state PTKINITNEGOTIATING hostapd_logger: STA 6c:c7:ec:4c:3f:f0 - sending 3/4 msg of 4-Way Handshake WPA: Send EAPOL(version=2 secure=0 mic=1 ack=1 install=1 pairwise=1 kde_len=28 keyidx=0 encr=0) WPA: Replay Counter - hexdump(len=8): 00 00 00 00 00 00 00 03 WPA: EAPOL-Key MIC using HMAC-SHA1 WPA: Use EAPOL-Key timeout of 1000 ms (retry counter 2) hostapd_logger: STA 6c:c7:ec:4c:3f:f0 - EAPOL-Key timeout WPA: 6c:c7:ec:4c:3f:f0 WPA_PTK entering state PTKINITNEGOTIATING hostapd_logger: STA 6c:c7:ec:4c:3f:f0 - sending 3/4 msg of 4-Way Handshake WPA: Send EAPOL(version=2 secure=0 mic=1 ack=1 install=1 pairwise=1 kde_len=28 keyidx=0 encr=0) WPA: Replay Counter - hexdump(len=8): 00 00 00 00 00 00 00 04 WPA: EAPOL-Key MIC using HMAC-SHA1 WPA: Use EAPOL-Key timeout of 1000 ms (retry counter 3) hostapd_logger: STA 6c:c7:ec:4c:3f:f0 - EAPOL-Key timeout WPA: 6c:c7:ec:4c:3f:f0 WPA_PTK entering state PTKINITNEGOTIATING hostapd_logger: STA 6c:c7:ec:4c:3f:f0 - sending 3/4 msg of 4-Way Handshake WPA: Send EAPOL(version=2 secure=0 mic=1 ack=1 install=1 pairwise=1 kde_len=28 keyidx=0 encr=0) WPA: Replay Counter - hexdump(len=8): 00 00 00 00 00 00 00 05 WPA: EAPOL-Key MIC using HMAC-SHA1 WPA: Use EAPOL-Key timeout of 1000 ms (retry counter 4) hostapd_logger: STA 6c:c7:ec:4c:3f:f0 - EAPOL-Key timeout WPA: 6c:c7:ec:4c:3f:f0 WPA_PTK entering state PTKINITNEGOTIATING hostapd_logger: STA 6c:c7:ec:4c:3f:f0 - PTKINITNEGOTIATING: Retry limit 4 reached WPA: 6c:c7:ec:4c:3f:f0 WPA_PTK entering state DISCONNECT

But from my GALAXY S II it should look like this:

hostapd_logger: STA 98:0c:82:ba:7a:aa - sending 3/4 msg of 4-Way Handshake WPA: Send EAPOL(version=2 secure=0 mic=1 ack=1 install=1 pairwise=1 kde_len=28 keyidx=0 encr=0) WPA: Replay Counter - hexdump(len=8): 00 00 00 00 00 00 00 02 WPA: EAPOL-Key MIC using HMAC-SHA1 WPA: Use EAPOL-Key timeout of 1000 ms (retry counter 1) l2_packet_receive: src=98:0c:82:ba:7a:aa len=99 wlan0: RX EAPOL from 98:0c:82:ba:7a:aa IEEE 802.1X: 99 bytes from 98:0c:82:ba:7a:aa IEEE 802.1X: version=1 type=3 length=95 WPA: Received EAPOL-Key from 98:0c:82:ba:7a:aa key_info=0x10a type=254 mic_len=16 key_data_length=0 WPA: Received Key Nonce - hexdump(len=32): 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 00 00 00 00 00 00 00 WPA: Received Replay Counter - hexdump(len=8): 00 00 00 00 00 00 00 02 hostapd_logger: STA 98:0c:82:ba:7a:aa - received EAPOL-Key frame (4/4 Pairwise) WPA: EAPOL-Key MIC using HMAC-SHA1 WPA: 98:0c:82:ba:7a:aa WPA_PTK entering state PTKINITDONE

Until step 3 of the 4-Way Handshake there is no difference but then receiving an EAPOL-Key timed out on your RasPi. It retried 4 times and then entered state DISCONNECT, never reaching state PTKINITDONE. Timeout is set to 1000 ms. I have looked at /usr/share/doc/wpa_supplicant/examples/wpa_supplicant.conf and asked google if there is a way to increase this timeout without success. All what I have found was that this could be a driver problem so an idea was to use the older wext driver but this doesn't support AP mode (mode=2). I don't really belief it's a hardware or firmware problem. I guess it is an issue with an app or driver that you only run on your android devices. Have a look at it.

UPDATE with comparing the debug output from wpa_supplicant:
I have reactivated my old SAMSUNG GALAXY S II with Android 4.1.2. It also connects without any problems. Here are the part of your wpa_supplicant debug output where it differs from mine:

hostapd_logger: STA 6c:c7:ec:4c:3f:f0 - sending 3/4 msg of 4-Way Handshake WPA: Send EAPOL(version=2 secure=0 mic=1 ack=1 install=1 pairwise=1 kde_len=28 keyidx=0 encr=0) WPA: Replay Counter - hexdump(len=8): 00 00 00 00 00 00 00 02 WPA: EAPOL-Key MIC using HMAC-SHA1 WPA: Use EAPOL-Key timeout of 1000 ms (retry counter 1) hostapd_logger: STA 6c:c7:ec:4c:3f:f0 - EAPOL-Key timeout WPA: 6c:c7:ec:4c:3f:f0 WPA_PTK entering state PTKINITNEGOTIATING hostapd_logger: STA 6c:c7:ec:4c:3f:f0 - sending 3/4 msg of 4-Way Handshake WPA: Send EAPOL(version=2 secure=0 mic=1 ack=1 install=1 pairwise=1 kde_len=28 keyidx=0 encr=0) WPA: Replay Counter - hexdump(len=8): 00 00 00 00 00 00 00 03 WPA: EAPOL-Key MIC using HMAC-SHA1 WPA: Use EAPOL-Key timeout of 1000 ms (retry counter 2) hostapd_logger: STA 6c:c7:ec:4c:3f:f0 - EAPOL-Key timeout WPA: 6c:c7:ec:4c:3f:f0 WPA_PTK entering state PTKINITNEGOTIATING hostapd_logger: STA 6c:c7:ec:4c:3f:f0 - sending 3/4 msg of 4-Way Handshake WPA: Send EAPOL(version=2 secure=0 mic=1 ack=1 install=1 pairwise=1 kde_len=28 keyidx=0 encr=0) WPA: Replay Counter - hexdump(len=8): 00 00 00 00 00 00 00 04 WPA: EAPOL-Key MIC using HMAC-SHA1 WPA: Use EAPOL-Key timeout of 1000 ms (retry counter 3) hostapd_logger: STA 6c:c7:ec:4c:3f:f0 - EAPOL-Key timeout WPA: 6c:c7:ec:4c:3f:f0 WPA_PTK entering state PTKINITNEGOTIATING hostapd_logger: STA 6c:c7:ec:4c:3f:f0 - sending 3/4 msg of 4-Way Handshake WPA: Send EAPOL(version=2 secure=0 mic=1 ack=1 install=1 pairwise=1 kde_len=28 keyidx=0 encr=0) WPA: Replay Counter - hexdump(len=8): 00 00 00 00 00 00 00 05 WPA: EAPOL-Key MIC using HMAC-SHA1 WPA: Use EAPOL-Key timeout of 1000 ms (retry counter 4) hostapd_logger: STA 6c:c7:ec:4c:3f:f0 - EAPOL-Key timeout WPA: 6c:c7:ec:4c:3f:f0 WPA_PTK entering state PTKINITNEGOTIATING hostapd_logger: STA 6c:c7:ec:4c:3f:f0 - PTKINITNEGOTIATING: Retry limit 4 reached WPA: 6c:c7:ec:4c:3f:f0 WPA_PTK entering state DISCONNECT

But from my GALAXY S II it should look like this:

hostapd_logger: STA 98:0c:82:ba:7a:aa - sending 3/4 msg of 4-Way Handshake WPA: Send EAPOL(version=2 secure=0 mic=1 ack=1 install=1 pairwise=1 kde_len=28 keyidx=0 encr=0) WPA: Replay Counter - hexdump(len=8): 00 00 00 00 00 00 00 02 WPA: EAPOL-Key MIC using HMAC-SHA1 WPA: Use EAPOL-Key timeout of 1000 ms (retry counter 1) l2_packet_receive: src=98:0c:82:ba:7a:aa len=99 wlan0: RX EAPOL from 98:0c:82:ba:7a:aa IEEE 802.1X: 99 bytes from 98:0c:82:ba:7a:aa IEEE 802.1X: version=1 type=3 length=95 WPA: Received EAPOL-Key from 98:0c:82:ba:7a:aa key_info=0x10a type=254 mic_len=16 key_data_length=0 WPA: Received Key Nonce - hexdump(len=32): 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 00 00 00 00 00 00 00 WPA: Received Replay Counter - hexdump(len=8): 00 00 00 00 00 00 00 02 hostapd_logger: STA 98:0c:82:ba:7a:aa - received EAPOL-Key frame (4/4 Pairwise) WPA: EAPOL-Key MIC using HMAC-SHA1 WPA: 98:0c:82:ba:7a:aa WPA_PTK entering state PTKINITDONE

Until step 3 of the 4-Way Handshake there is no difference but then receiving an EAPOL-Key timed out on your RasPi. It retried 4 times and then entered state DISCONNECT, never reaching state PTKINITDONE. Timeout is set to 1000 ms. I have looked at /usr/share/doc/wpa_supplicant/examples/wpa_supplicant.conf and asked google if there is a way to increase this timeout without success. All what I have found was that this could be a driver problem so an idea was to use the older wext driver but this doesn't support AP mode (mode=2). I don't really belief it's a hardware or firmware problem. I guess it is an issue with an app or driver that you only run on your android devices. Have a look at it.

Bounty Awarded with 50 reputation awarded by ThePunisher
Source Link
Ingo
Ingo
  • 43.1k
  • 20
  • 87
  • 207

I have tested the setup with a Huawai smartphone Android version 4.0.3 and a FAIRPHONE Android version 9. Both phones connected without any problems so it is difficult for me to debug an error that isn't present. Here are some ideas:

From your tests the problem seems to be WiFi asoziation, the step before getting an ip address. So you should focus on wpa_supplicant. The first test could be to explecitely define the encryption method. This was in the past WPA but nowadays improved to WPA2 or also named RSN. But WPA is sometimes still used. Check with both settings. In /etc/wpa_supplicant/wpa_supplicant-wlan0.conf add the option proto=RSN WPA (will first use RSN then WPA) and both single settings. Have also an attention to your correct country= setting so it looks similar to this:

rpi ~$ sudo cat /etc/wpa_supplicant/wpa_supplicant-wlan0.conf ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev update_config=1 country=nn network={ ssid="RPiNet" mode=2 key_mgmt=WPA-PSK proto=RSN WPA # proto=RSN # proto=WPA psk="verySecretPassword" frequency=2412 }

If this doesn't help then use a very simple stand alone access point with latest configuration updates to reduce side effects. Setup it as shown in Setting up a Raspberry Pi as an access point - the easy way in section ♦ Setting up a stand alone access point.

After a fresh flashed Raspbian Buster image and update/full-upgrade you should first do sudo apt install tcpdump. Maybe you will look at the traffic on the interfaces. Later you don't have an internet connection for installations. After setup you should add option DNSSEC=no to /etc/systemd/resolved.conf and reboot to disable DNS record signing. There is a known bug as shown in Sporadic "DNSSEC validation failed" — "no-signature" #12388.

Now try connecting your Android phones. If it fails then start wpa_supplicant in foreground debug mode and inspect its output.

rpi ~$ sudo systemctl stop [email protected] rpi ~$ sudo /sbin/wpa_supplicant -d -c/etc/wpa_supplicant/wpa_supplicant-wlan0.conf -Dnl80211,wext -iwlan0

If wpa_supplicant has started with a bunch of detailed low level messages, then try to connect a phone. Take time for inspecting the verbose output from the connection attempt, look for failing messages and it lines before.