Hi,
I'm doing research on some freeradius stuff, but I can't quite seem to find the answer..
Long story short.

I've got 2 Ubiquiti UniFi AP's, 1 FreeRadius server, and 1 mikrotik router.
All radius accounts have got a Login-Time attribute set (e.g. Login is allowed from 8AM till 8PM)

The unifi APs do not support CoA or Disconnect-Request packets by default, which is something I need, because the clients need to be disconnected after their login-time expires.

I'd like to accomplish this by using OpenWrt.

But the wiki isn't really clear on how-to. I mean like: I've got enough networking and linux knowledge, but I'm fairly new to radius.

Could you guys tell me if this is indeed supported, and where I could find proper documentation on this.

Cheers!

This is probably more a function of your captive portal (probably on the Mikrotik router?) than of the AP itself; don't have details of your particular use case, but the most popular reason for doing this is usually to restrict Internet access - which tends to get enforced at the router.

If instead you're using 802.1X authentication (WPA Enterprise) for your wifi connections themselves and want to forcibly disconnect those... the best way I can think of is to set a "Session-Timeout" of a suitable value (say, 600 seconds) on the RADIUS attributes for the user with a "Termination-Action" value of "RADIUS-Request".  Have just Googled it and was pleased to find a very relevant discussion on it on the Ubiquiti forums:  https://community.ubnt.com/t5/airOS-Sof … d-p/374502

So yes it's possible with OpenWRT, but there certainly isn't a requirement for OpenWRT in order to get this to work as the actual config changes need to be implemented on your RADIUS server and/or the captive portal on the Mikrotik router.

I'm sorry, I should've mentioned.
I am indeed using 802.1x. And since the clients only have access to wireless, we figured it's the best option.
I've contacted UBNT about the Session-Timeout or the Reauthentication period.
They stated the last one is not included in the UniFi APs, they didn't mention anything on the Session-Timeout attribute though.

I flashed OpenWRT on the UAP now.. I'm going to give CoA a try there
Still not sure how to get started here though

Cheers!

You need something like this in /raddb/users:
DEFAULT Cleartext-Password := "mysecret", Max-Daily-Session :="58800"
        Idle-Timeout := 900,
        Session-Timeout := 7200

I'm not gonna use Max-Daily-Session. The client specificly wanted to set an timespan like 8 a.m. till 6 p.m. for example.
So login-time would be the best option imho

So: If I would set Session-Timeout to 600 it'd reautenticate to radius without the client being disconnected from the AP, right? (Unless his Login-Time expired ofc)

That's the theory yes; I think the client is actually forced to re-associate, but it isn't noticable to the end user.

I've used it successfully in the past with non-OpenWRT solutions.  It was common in the early days with WEP, where this was the only way to force the client to re-key in order to work around some of the weakneses that had been found.  I've used it subsequently to ensure that users with expired accounts don't maintain wireless sessions indefinitely.

The AP is supposed to see that there's a Session Timeout, then notice that the required "Termination-Action" is to do "RADIUS-Request."

(Last edited by atom on 4 May 2015, 08:35)

EDIT: THANX for clarification. Still learning :-)
You should look/google for the various rules, available for freeradius, to check
Probably you need to write some small LUA-script, to check the actual login time against the allowed period, and then set up max. session time to (6PM-actual time).

(Last edited by augustus_meyer on 4 May 2015, 13:37)

Per RFC3580, if Session-Timeout expires and Termination-Action is set to "RADIUS-Request", behaviour will be different from when it is unspecified or not set to "RADIUS-Request".  https://tools.ietf.org/html/rfc3580#section-3.19

I've used this quite successfully on both wired and wireless 802.1X connections.  Whether or not it's correctly implemented in Uni-Fi APs is up for debate, though.  Per link posted earlier there was a stage where this was problematic, but (according to the discussion thread) it seems it was fixed at some point.

Well, I've got OpenWrt flashed on the UniFi APs now (since Ubnt's firmware doesn't support anything but normal authorization)
So, I've been running into a few problems:
My users are managed in MySQL, so I've got the radcheck & radreply tables.
Got 1 user in them, which is setup as follows:

Radcheck:
username: test
Cleartext-Password := test123
Login-Time := Al1500-1800

radreply:
username: test
Session-Timeout := 60 (just for testing purposes ofcourse)
Acct-Interim-Interval := 60

So, if I read correctly, above settings should check the login every 60 seconds, correct?
Because, watching freeradiusd output does not show any of this

Also, I'm working with CoA, to be able to force disconnects, this doesn't seem to work either.

/etc/config/wireless

config wifi-device 'radio0'
        option type 'mac80211'
        option channel '11'
        option hwmode '11g'
        option path 'pci0000:00/0000:00:00.0'
        option htmode 'HT20'
        option txpower '30'
        option country 'US'

config wifi-iface
        option device 'radio0'
        option mode 'ap'
        option ssid 'OpenWrt'
        option network 'vlan30'
        option encryption 'wpa2'
        option auth_server '172.16.0.247'
        option acct_server '172.16.0.247'
        option acct_secret 'testing123'
        option auth_secret 'testing123'
        option acct_interval '60'
        option port '1812'
        option ownip '172.16.0.249'
        option dae_port '3799'
        option dae_client '172.16.0.247'
        option radius_das_port '3799'
        option radius_das_client '172.16.0.247 testing1234'

This should get CoA to work, but the CoA port sends back an ICMP port-unreachable when watching the wireshark output.. (testing from radius server with radclient).
I've read a similar topic about it here: https://forum.openwrt.org/viewtopic.php?id=50026 which has no solution posted unfortunaly.

An ICMP port-unreachable usually indicates a firewall rule preventing access. Do you need to accept some ports / protocols?

First, are you running hostapd instead of wpad-mini? hostapd is needed for most 802.1x functionality.

Second, the 802.1x support in OpenWRT is not fully implemented as I discovered when working on some 802.1x dynamic VLAN assignment issues. What you should probably do is find the correct settings to make it work with hostapd. You can then add support for any required modules so that UCI (the OpenWRT configuration files) will generate an appropriate hostapd configuration. If you're really going to contribute back you would then want to make and submit a patch so that future OpenWRT versions will include that support out of the box. I'm willing to help with that part if I can find the time to do so.

I've checked that already, I turned the firewall off, but got the same result.
It's like theres nothing listening on that port

Yes, I'm running the full hostapd.
And according to the documentation it should support CoA/PoD, just can't seem to find what causes it not to be listening on the assigned port

freeradius setup looks OK. Smart solution :-)
But now you need to look at/setup choova-chilli, the captive portal SW.
coova-chilli supports CoA and session control/radius accounting. Which is, what you need.
Be warned, just in case: A lot of outdated docs floating around on the web. And a lot of old versions of coova-chilli.

Why coovachilli, I read about it, I know what is does. But if I understand correctly OpenWrt + Freeradius + WPA2 Enterprise shoud suffice.
If not, why?

coova-chilli commmunicates with freeradius, to block unauthorized (wireless) clients, and to allow access for authorized clients.
Authorization can be local, or, like in your case, in coop with freeradius.
coova also gathers the accounting info on the AP, to transmit it in intervals to freeradius.
Which then MAY deauth the client, in case volume limit is exceeded, for example. Or, in case the session tmo occures.
Coova receives the freeradius info  (port 3990), to disconnect the client (or receives the CoA) and manages the client accordingly.

coova also controls the clients bandwidth, if instructed from freeradius to do so.
It is the middleware, between your login-script (or captive portal), freeradius, and the wireless client.
WPA (Enterprise) manages access control to the wireless interface of the AP, to associate a client to the AP.
But that does NOT include session management, based on traffic volume or airtime etc. Or user management, based on user/pwd or allowed MACs etc.

But, in case you use Mikrotiks hotspot functions, and your APs are running in strict bridge mode, then you have coova "under  cover" running on the MT. And a problem, because MT-hotspot does not support the CoA, at least, AFAIK.

Whre is your actual login-script running ?

(Last edited by augustus_meyer on 4 May 2015, 21:29)

Thanks for the clarification!
I've got a mikrotik router as gateway for this setup. Using it's built-in hotspot feature could do this as well if I understand correctly. gonna give it a shot

CoA could be a problem on the MT.

Yup, I went there, and my idea failed
Still weird I can't send Disconnect-Request to the AP though

This for example wont work:

root@radius:~# echo User-Name=test,Framed-IP-Address=172.16.3.3 | radclient -x 172.16.0.249:3799 disconnect testing1234
Sending Disconnect-Request of id 179 to 172.16.0.249 port 3799
        User-Name = "test"
        Framed-IP-Address = 172.16.3.3

(I just keep getting ICMP port unreachables)

See the link to a topic I posted in one of the previous posts.
Any thoughts on this?

(Last edited by aTastyAim on 4 May 2015, 23:52)

I'm going to ask a stupid question and ask you to verify that you don't have any firewall rules blocking incoming traffic to the router on that port, from that network, interface, etc.

Nope, firewall is disabled (was mentioned in post #10/#11).
Also netstat shows nothing listening on the port for some reason

Update: Above issue is fixed, the documentation I was reading seemed to be incorrect.
However, the next issue presented itself (yay :c )

It's a rather interesting one though.
I'm using radclient to send a 'test' disconnect request packet.

For example:

root@radius:~#  echo "User-Name=test,NAS-IP-Address=172.16.0.249,Acct-Session-Id                                                                                                                                                             =55482341-00000000" | radclient -x 172.16.0.249:3799 disconnect testing123

Sending Disconnect-Request of id 31 to 172.16.0.249 port 3799
        User-Name = "test"
        NAS-IP-Address = 172.16.0.249
        Acct-Session-Id = "55482341-00000000"
rad_recv: Disconnect-ACK packet from host 172.16.0.249 port 3799, id=31, length=                                                                                                                                                             44
rad_verify: Received packet from 172.16.0.249 with invalid Message-Authenticator                                                                                                                                                             !  (Shared secret is incorrect.)
^C

So the output claims the secret is incorrect, however if I change the secret to ' testing1234'  for example, I'll simply get no reply at all.

I verified the secret, hostapd's running config shows the correct secret

root@ap01:~# cat /var/run/hostapd-phy0.conf
driver=nl80211
logger_syslog=127
logger_syslog_level=0
logger_stdout=127
logger_stdout_level=0
country_code=US
ieee80211d=1
hw_mode=g
channel=11

ieee80211n=1
ht_capab=[SHORT-GI-20][SHORT-GI-40][TX-STBC][RX-STBC1][DSSS_CCK-40]

interface=wlan0
ctrl_interface=/var/run/hostapd
disassoc_low_ack=1
preamble=1
wmm_enabled=1
ignore_broadcast_ssid=0
auth_server_addr=172.16.0.247
auth_server_port=1812
auth_server_shared_secret=testing123
acct_server_addr=172.16.0.247
acct_server_port=1813
acct_server_shared_secret=testing123
radius_das_port=3799
radius_das_client=172.16.0.249 testing123
nas_identifier=
own_ip_addr=172.16.0.249
eapol_key_index_workaround=1
ieee8021x=1
wpa_key_mgmt=WPA-EAP
auth_algs=1
wpa=2
wpa_pairwise=CCMP
ssid=OpenWrt
bridge=br-vlan30
okc=0
disable_pmksa_caching=1
bssid=04:18:d6:4f:b7:b8

Any thoughts on this?

(Last edited by aTastyAim on 5 May 2015, 03:13)

What software are you using to generate the deauth?

This one
https://forum.openwrt.org/viewtopic.php?id=50026
indicates, that coova-chilli is in use, somewhere. Most likely on the Ubiquiti AP.

To analyze, whats going on there, needs some testing, and info about coova-version in use. And about net-setup.

(Last edited by augustus_meyer on 5 May 2015, 09:08)

Radclient on the radius server (debian)

That issue is resolved already turned out to be wrong documentation, changed a variable, rebooted, and hey, it works

Only problem now is the 'shared secret incorrect' message (see previous post)

On "normal" RADIUS (not the CoA bit which I'm following with significant interest!) I've on occasion seen "invalid message authenticator" if the client IP is not deemed a valid one.  You're confident the packet is originating from 172.16.0.247, as the AP is set up to expect?  Any chance your Debian box is multi-homed and sending it from a different IP?