Arjen Smit | 26 Jan 21:35 2015

EAP identity request- EAP identiy response and there it stops..

Dear hostapd users,

I hope someone can help me with this issue. I have a setup on ubuntu 12.04 - hostapd v2.3 plus external radius server (freeradius). After associating to the AP with the wireless device only an EAP identiy request and EAP identity response can be seen on the radio interface (actually several times). From the hostapd towards the Radius server the accounting is exchanged but no authentication (EAPOL) communication whatsoever. (sniffing on loopback interface on port 1812 and 1813) .I would expect at some stage the hostapd to start a message exchange with the autentication Radius server. I tried with several settings on hostapd.conf and various versions of hostapd but the behaviour is similar

Any pointers to the right direction are highly appreciated.

Thanks in advance


I attached the relevant logging below:

nl80211: Set STA flags - ifname=wlan1 addr=20:02:af:0f:35:1c total_flags=0x6 flags_or=0x0 flags_and=0xfffffffe authorized=0

wlan1: STA 20:02:af:0f:35:1c IEEE 802.1X: unauthorizing port

IEEE 802.1X: 20:02:af:0f:35:1c AUTH_PAE entering state RESTART

EAP: EAP entering state INITIALIZE

wlan1: CTRL-EVENT-EAP-STARTED 20:02:af:0f:35:1c

EAP: EAP entering state SELECT_ACTION

EAP: getDecision: no identity known yet -> CONTINUE

EAP: EAP entering state PROPOSE_METHOD

EAP: getNextMethod: vendor 0 type 1

wlan1: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=1

EAP: EAP entering state METHOD_REQUEST

EAP: building EAP-Request: Identifier 198

EAP: EAP entering state SEND_REQUEST

EAP: EAP entering state IDLE

EAP: retransmit timeout 3 seconds (from dynamic back off; retransCount=0)

IEEE 802.1X: 20:02:af:0f:35:1c AUTH_PAE entering state CONNECTING

IEEE 802.1X: 20:02:af:0f:35:1c AUTH_PAE entering state AUTHENTICATING

IEEE 802.1X: 20:02:af:0f:35:1c BE_AUTH entering state REQUEST

wlan1: STA 20:02:af:0f:35:1c IEEE 802.1X: Sending EAP Packet (identifier 198)

nl80211: Event message available

nl80211: Drv Event 19 (NL80211_CMD_NEW_STATION) received for wlan1

nl80211: New station 20:02:af:0f:35:1c

wlan1: Event EAPOL_TX_STATUS (40) received

IEEE 802.1X: 20:02:af:0f:35:1c TX status - version=1 type=0 length=5 - ack=1

nl80211: Event message available

nl80211: BSS Event 59 (NL80211_CMD_FRAME) received for wlan1

nl80211: MLME event 59 (NL80211_CMD_FRAME) on wlan1(00:9a:90:00:37:df) A1=ff:ff:ff:ff:ff:ff A2=86:55:a5:99:60:20


























































wpa_pairwise=TKIP CCMP

HostAP mailing list
HostAP <at>
Sarah Thomas | 26 Jan 18:45 2015



When EAP Packet of type response is received, in handle_eap_response, the response data is copied to sm->eap_if->eapRespData and sm->eapolEap is set to TRUE and returned.

How is the response actually handled? Like how is it sent to radius server, if it has to be passed on to the external radius server. Is EAP state machine getting triggered and if so from where ?  I dont see anything on eapol state machine?

Basically, what is the code flow after EAP response data is received?


HostAP mailing list
HostAP <at>
Jonathan Bither | 26 Jan 17:05 2015

nl_socket_set_buffer_size usage

Hello Jouni,

I was unable to build hostapd this morning on CentOS6 again after commit 
"630b323 nl80211: Increase netlink receive buffer size".

libnl1 doesn't provide "nl_socket_set_buffer_size()" so I fixed my build 
with the change below. I'm not sure if it was the appropriate method so 
I just wanted to check with you if this was the correct fix.

Thanks again,

diff --git a/src/drivers/driver_nl80211.c b/src/drivers/driver_nl80211.c
index f955ee4..a29037f 100644
--- a/src/drivers/driver_nl80211.c
+++ b/src/drivers/driver_nl80211.c
 <at>  <at>  -132,6 +132,7  <at>  <at>  static void nl80211_register_eloop_read(struct 
nl_handle **handle,
  					eloop_sock_handler handler,
  					void *eloop_data)
  	 * libnl uses a pretty small buffer (32 kB that gets converted to 64 kB)
  	 * by default. It is possible to hit that limit in some cases where
 <at>  <at>  -145,6 +146,7  <at>  <at>  static void nl80211_register_eloop_read(struct 
nl_handle **handle,
  		/* continue anyway with the default (smaller) buffer */

  	eloop_register_read_sock(nl_socket_get_fd(*handle), handler,
Sarah Thomas | 26 Jan 12:49 2015



Since  IEEE802_1X_TYPE_EAPOL_KEY is getting AND'ed with EAPOL_KEY_TYPE_WPA and EAPOL_KEY_TYPE_RSN, this(whole concept of EAPOL key) is not applicable for wired configuration?

if (datalen >= sizeof(struct ieee802_1x_eapol_key) && hdr->type = IEEE802_1X_TYPE_EAPOL_KEY &&    (key->type == EAPOL_KEY_TYPE_WPA ||  key->type == EAPOL_KEY_TYPE_RSN)) {
        wpa_receive(hapd->wpa_auth, sta->wpa_sm, (u8 *) hdr,
                sizeof(*hdr) + datalen);

HostAP mailing list
HostAP <at>
Ben Greear | 23 Jan 22:33 2015

Can we disable UAPSD for stations?

Someone requested that I be able to disable UAPSD on ath10k stations.

So first of all, does wpa_supplicant (and nl80211) have the ability to do this?



Ben Greear <greearb <at>>
Candela Technologies Inc
Harm Verhagen | 23 Jan 08:38 2015

Re: mix AP and wireless client

On Thu, Jan 22, 2015 at 9:31 PM, Dan Williams <dcbw <at>> wrote:
On Thu, 2015-01-22 at 20:44 +0100, Harm Verhagen wrote:

> Yes, that makes sense.
> So at least I need 3.7 kernel, but even then, my current hardware may not
> support it. (as it is not advertising "valid interface combinations")

The rt2x00 driver in 3.1 didn't know about interface combinations at
all, even though the kernel frameworks supported it.  So there's a good
chance that a 3.7+ kernel rt2x00 driver *would* show that support for
your device.  But of course, there's only one easy way to find out...


I'll give that a try.  (might take a while though)

HostAP mailing list
HostAP <at>
Ben Greear | 23 Jan 02:57 2015

VHT mode for IBSS?

Does current upstream wpa_supplicant support VHT mode for IBSS?

I've tried to patch in the appropriate kernel patches to enable this
for ath10k, but the beacons show up as HT instead of VHT, and
stations do not show up as have vht_capa in debugfs.

It does appear to be doing HT, though performance is still poor
(about 11Mbps UDP throughput from one IBSS device to another.



Ben Greear <greearb <at>>
Candela Technologies Inc
Jouni Malinen | 23 Jan 00:42 2015

Re: P2P Persistent Group Revoke Methods

On Tue, Jan 13, 2015 at 04:21:11AM +0000, KUMAR AMIT SINGH wrote:
> <HTML><HEAD><TITLE>Samsung Enterprise Portal mySingle</TITLE>

Please send plaintext messages to this mailing list..

> <P>You have mentioned the 2-case in which persistent revoke request receiving device may join
automatically OR in other case user want to accept the connection</P>
> <P>I have been trying the 2nd case in which "user want to accept the connection". For that I am trying below steps:</P>
> <P>&nbsp;</P>
> <P>Device-A
persistent=2 peer=02:90:4c:c5:12:38</P>
> <P>Device-B
(Request):&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;set persistent_reconnect 1<BR></P>

Setting persistent_reconnect to 1 is not for the case you are
interesting in. It is only for the purpose of configuring the device to
allow persistent group reinvocation without user interaction.

> <P>Ideally, Device-B should be able to join the persistent group. But it is not happening. It only SUCCEED
when the Device-B has done&nbsp;"set persistent_reconnect 1"&nbsp;&nbsp;Before the Invitation
started from Device-A.</P>

That is exactly how persistent_reconnect=1 is supposed to work.. You
need to leave it to 0 if you want user to acknowledge the connection.

> <P>I have also tried "P2P-CONNECT" on Device-B after "P2P-INVITATION-RECEIVED" Event Received but
that also seems not working.</P>

P2P_CONNECT is for negotiating a new P2P group or joining an already
operating group, not for reinvoking a persistent group. You would issue
P2P_INVITE on the device to start another invitation exchange after the
user has accepted the connection. In other words, wait for this event:

P2P-INVITATION-RECEIVED sa=02:00:00:00:01:00 persistent=1 freq=2462

and issue this once user accepts:

P2P_INVITE persistent=1 peer=02:00:00:00:01:00 freq=2462

(the arguments copied from the event message assuming you do not have a
need to try to enforce different operating frequency)


Jouni Malinen                                            PGP id EFC895FA
Ben | 22 Jan 18:02 2015

Hostapd + OpenSSL support


I would like to force using a specific cipher suite to enforce EAP-TLS but I got an error message when I uncomment "openssl_ciphers" option.
Is it because hostapd is built by default without openssl support? (does it use internal ssl engine?)

If it is the case, if anyone has an how-to to build hostapd with openssl on!

I am on Archlinux, perhaps an easy way using ABS?


HostAP mailing list
HostAP <at>
Chrishanton Vethanayagam | 22 Jan 03:06 2015

hostapd: RADIUS client does not reattempt connection to external RADIUS server after hostapd startup first attempt connection fails.

I have faced the above subject matter when using the latest git sources and built hostapd.
This issue is not a problem in hostapd stable release versions 2.1 and earlier.

Is there intention to reattempt connection to RADIUS server after start-up first attempt connection fail?
If so, the below is an analysis of what changed from stable release 2.2 onwards.

Steps to reproduce failure environment:
1. Start-up hostapd which is configured to connect to a single external RADIUS server IP address.
2. In the case when system has no network connection to said IP address (be it the necessary network interface to access the RADIUS server is not up yet, or relevant routing is not up yet, etc.), system will fail to connect at startup initialisation. (hostapd log output at this point: ' connect[radius]: Network is unreachable ' )
3. Subsequent attempts by hostapd to send radius packets out when WiFi clients associate & negotiate security would continuously fail, even though RADIUS server is now pingable by system. (hostapd log output at this point: ' RADIUS No authentication server configured. ' )

After reviewing the src/radius/radius_client.c file, the following are my findings:
a) In step 2 above, startup initialisation would run into the radius_change_server() function which would attempt to make connect to RADIUS server but fail in the fail case environment of step 2 above. The code would then exit the function at an earlier point, without setting the radius->auth_sock which occurs at tail end of radius_change_server().
b) In step 3 above, hostapd would send out RADIUS packets to RADIUS server in radius_client_send() function when a WiFi client is in security negotiation, but fails and generates the log message in step 3 above which originates from this function. This is due to a conditional check on the same radius->auth_sock which did not get populated at startup as explained in step a)

Comparing the radius_client.c code between releases 2.1 & 2.2 shows that 2.2 adds this conditional check on radius->auth_sock in radius_client_send().

This is the point which causes the re-connection attempt failure as  the code does not proceed further down the function radius_client_send() to fail at sending packets through the socket, thus triggering radius_client_handle_send_error() to run, which would then trigger radius_change_server() to run again (successfully as and when RADIUS server is pingable), and things will then work when the next time the radius packet is retransmitted (I believe this was how it worked in stable release 2.1 and earlier).

I have tried removing the radius->auth_sock conditional check from latest git code, and tested it to work successfully, similar to releases 2.1 & earlier with respect to RADIUS server reconnection attempt.
The below is the patch which was used (basically reverting the radius->auth_sock & radius->acct_sock condition check):

diff --git a/src/radius/radius_client.c b/src/radius/radius_client.c
index 34f5685..9694cb6 100644
--- a/src/radius/radius_client.c
+++ b/src/radius/radius_client.c
<at> <at> -658,7 +658,7 <at> <at> int radius_client_send(struct radius_client_data *radius,

        if (msg_type == RADIUS_ACCT || msg_type == RADIUS_ACCT_INTERIM) {
-               if (conf->acct_server == NULL || radius->acct_sock < 0 ||
+               if (conf->acct_server == NULL ||
                    conf->acct_server->shared_secret == NULL) {
                        hostapd_logger(radius->ctx, NULL,
<at> <at> -673,7 +673,7 <at> <at> int radius_client_send(struct radius_client_data *radius,
                s = radius->acct_sock;
        } else {
-               if (conf->auth_server == NULL || radius->auth_sock < 0 ||
+               if (conf->auth_server == NULL ||
                    conf->auth_server->shared_secret == NULL) {
                        hostapd_logger(radius->ctx, NULL,

There may be more behind the introduction of this conditional check from release 2.2 onwards (certainly the radius client code is more consolidated) and perhaps there are some plans/provisions to handle this in a more elegant manner (granted that the mechanism to attempt re-connection previously was through a failed attempt at sending a packet through the socket with the initial invalid socket descriptor).
Or perhaps there is no intention to reattempt connection to RADIUS server altogether?

Just wanted to bring notice to this RADIUS client behavioural difference from stable release 2.2 onwards, and leave it to the good judgement of hostapd developers.
HostAP mailing list
HostAP <at>
Stefano Cappa | 21 Jan 16:30 2015

how can i use wlan0 and p2p0 for p2p operations without new virtual interfaces?


this message is a consequence of another previous question.

I'm always at the same point, i mean, i want to have an android device with 2 p2p interfaces.

I tried with driver_param=use_p2p_group_interface=1 without success, because i can create only one interface for p2p operations and i really don't understand the reason.

But remove everything that i said before, i've a general question, non connected to android.

Suppose that i have limitations about the total number of interfaces that i can create, for example 3. There is a way to use p2p-p2p0-0 and directly p2p0, instead of p2p-p2p0-1? Or p2p-p2p0-0 and wlan0? Or p2p0 and wlan0, directly?

And, if the answer is yes, how can i achieve this with wpa_supplicant + wpa_cli?

Thank u very much,

Stefano Cappa

HostAP mailing list
HostAP <at>