imac:

We see this on all 17.01.4 platforms we have tested (Archer C7, Archer C2600, WD N600, EA4500)

Standard images are used, with the following change:
opkg remove wpad-mini hostapd
opkg install hostapd-common wpad

In our case, our captive portal system sends CoA (Change of Authorization) requests to initiate VLAN changes after a station completes a registration process, and passes the VLAN via access-accept messages, which works well, except for that hostapd seems to have a 30s hold timer on each access-request/accept response.

What this means, is that when hostapd recieves a CoA, it will only re-evaluation the authorization if more than 30s has elapsed since the last Access-Request.

In theory, this means all CoA's are ignored if they are received within 30seconds of a client connecting. This is really problematic in Captive Portals where clients typically complete a registration process in under 30seconds and are then expected to land on an authorized network after a CoA is completed.

Below I have two examples that show how CoA's are being incorrectly ignored due to this internal hold timer.

Example A: Sunny Day Scenario

Here is a typical interaction, where a Client/Station connects to hostapd which connects them onto a VLAN to complete a network registration via a captive portal. The radius exchange between hostapd (10.2.1.11) and the radius server (10.2.1.2) is shown below using a tcpdump of packets.

1. Station/Client connects and hostapd generates an Access-Request to which the radius server responds with an Access-Accept indicating the VLAN; On the client side, due to the network on that new VLAN, WISPr kicks in and prompts the user to sign-in to the network.

12:03:58.157726 10.2.1.11.49281 > 10.2.1.2.1812: Access-Request (1)
12:03:58.211386 10.2.1.2.1812 > 10.2.1.11.49281: Access-Accept (2)
12:03:58.279846 10.2.1.11.45520 > 10.2.1.2.1813: Accounting-Request (4)
12:03:58.325525 10.2.1.2.1813 > 10.2.1.11.45520: Accounting-Response (5)

2)At some point in the future, the client completes the registration which causes the radius server to initiate an CoA/Disconnect Request, and Hostapd performs an Access-Request, which obtails the correct/new VLAN based on the Access-Accept message. Client is placed on the new VLAN and everything works as expected.

12:04:28.735459 10.2.1.2.60410 > 10.2.1.11.3799: Disconnect-Request (40)
12:04:28.736847 10.2.1.11.45520 > 10.2.1.2.1813: Accounting-Request (4)
12:04:28.737166 10.2.1.11.3799 > 10.2.1.2.60410: Disconnect-ACK (41)
12:04:28.762991 10.2.1.2.1813 > 10.2.1.11.45520: Accounting-Response (5)
12:04:30.717764 10.2.1.11.49281 > 10.2.1.2.1812: Access-Request (1)
12:04:30.782158 10.2.1.2.1812 > 10.2.1.11.49281: Access-Accept (2)
12:04:30.906401 10.2.1.11.45520 > 10.2.1.2.1813: Accounting-Request (4)
12:04:30.943903 10.2.1.2.1813 > 10.2.1.11.45520: Accounting-Response (5)

Note that there was approximately 30 seconds between when the Station/Client first connected, and the Disconnect-Request from the radius server.

Example B: The clicks through the captive portal in less than 30 seconds.

Here is a a more realistic interaction, where a Client/Station connects to hostapd which connects them onto a VLAN to complete a network registration via a captive portal. The radius exchange between hostapd (10.2.1.11) and the radius server (10.2.1.2) is shown below using a tcpdump of packets.

The problem arises here because the user only took 22 seconds to complete the registration process. In reality, I can complete the captive portal click through in just a few seconds.

1. Station/Client connects and hostapd generates an Access-Request to which the radius server responds with an Access-Accept indicating the VLAN; On the client side, due to the network on that new VLAN, WISPr kicks in and prompts the user to sign-in to the network.

15:11:35.269960 10.2.1.11.49281 > 10.2.1.2.1812: Access-Request (1)
15:11:35.326104 10.2.1.2.1812 > 10.2.1.11.49281: Access-Accept (2)
15:11:35.386984 10.2.1.11.45520 > 10.2.1.2.1813: Accounting-Request (4)
15:11:35.427652 10.2.1.2.1813 > 10.2.1.11.45520: Accounting-Response (5)

2. 22 seconds later, the client completes the registration which causes the radius server to initiate an CoA/Disconnect Request. Since it has been less than 30seconds since the last Access-Request/Access-Accept handshake, Hostapd does not performs an Access-Request, which causes the client to be associated with the OLD / Incorrect VLAN.

The failure of hostapd to do another Access-Request when the Change-of-Authorization/Disconnect-Request is received, is the issue.

15:11:57.417798 10.2.1.2.58842 > 10.2.1.11.3799: Disconnect-Request (40)
15:11:57.420730 10.2.1.11.45520 > 10.2.1.2.1813: Accounting-Request (4)
15:11:57.424759 10.2.1.11.3799 > 10.2.1.2.58842: Disconnect-ACK (41)
15:11:57.446361 10.2.1.2.1813 > 10.2.1.11.45520: Accounting-Response (5)
15:11:59.243604 10.2.1.11.45520 > 10.2.1.2.1813: Accounting-Request (4)
15:11:59.283332 10.2.1.2.1813 > 10.2.1.11.45520: Accounting-Response (5)

3)In this case the client gets another 'sign-in to network' prompt as the WISPr client detects it is still captured on the old VLAN. After another 30 seconds later, the client completes the registration a second time, which causes the radius server to initiate an CoA/Disconnect Request but this time, sice it has been more than 30 seconds since the last Access-Request/Access-Accept handshake, Hostapd performs the VLAN change as expected.

15:12:28.554417 10.2.1.2.41995 > 10.2.1.11.3799: Disconnect-Request (40)
15:12:28.557488 10.2.1.11.45520 > 10.2.1.2.1813: Accounting-Request (4)
15:12:28.561537 10.2.1.11.3799 > 10.2.1.2.41995: Disconnect-ACK (41)
15:12:28.580379 10.2.1.2.1813 > 10.2.1.11.45520: Accounting-Response (5)
15:12:30.262645 10.2.1.11.49281 > 10.2.1.2.1812: Access-Request (1)
15:12:30.322381 10.2.1.2.1812 > 10.2.1.11.49281: Access-Accept (2)
15:12:30.446732 10.2.1.11.45520 > 10.2.1.2.1813: Accounting-Request (4)
15:12:30.483542 10.2.1.2.1813 > 10.2.1.11.45520: Accounting-Response (5)

We can guess that having a 30s hold timer on Access-Requests could make sense in a scenario where a client was constantly disconnecting and re-connecting, whereby in order to cut down on radius handshakes, the last Access-Accept is used until the 30s timer expires. However, this does not make sense in consideration of a CoA/Disconnect request, which should immediately trigger an Access-Request for re-evaluation of authorization.

The other side effect of this issue, is that client access can not be revoked via radius (another common use of CoA) within 30 seconds of connecting due to the same issue.