Hi, I'm using freeradius 3.17 with unifi APs[1] to provide authentication and accounting. I'm currently using 3 APs. I've run into a problem: radwho will only ever display one user per AP at max. I've run radiusd -X and also looked into the source code that handles radutmp. It seems that the NAS-Port value needs to be unique per user. The APs, however, always supply a NAS-Port of 0. I've looked a bit into the hostapd that unifi is using, and it seems it is a (heavily) patched version, so no chance to get a standard hostapd running. I've tested with standard hostapd: This does use a unique NAS-Port value when sending accounting packets to the radius server, so all concurrently logged in users per AP are shown correctly by radwho. My question is: Is there any way to get radwho/radutmp accounting to work correctly even with the NAS-Port always set to 0? Thanks, HC [1] https://www.ubnt.com/unifi/unifi-ap/
On Sep 8, 2018, at 1:25 AM, Hans-Christian Esperer <hc@hcesperer.org> wrote:
I've run into a problem: radwho will only ever display one user per AP at max. I've run radiusd -X and also looked into the source code that handles radutmp. It seems that the NAS-Port value needs to be unique per user. The APs, however, always supply a NAS-Port of 0. I've looked a bit into the hostapd that unifi is using, and it seems it is a (heavily) patched version, so no chance to get a standard hostapd running.
I've tested with standard hostapd: This does use a unique NAS-Port value when sending accounting packets to the radius server, so all concurrently logged in users per AP are shown correctly by radwho.
My question is: Is there any way to get radwho/radutmp accounting to work correctly even with the NAS-Port always set to 0?
Put the data into an SQL table. The SQL module supports this. Also, the radutmp file is not scalable. It requires a linear search to find a user. Given that it's 2018 and sqlite exists, everyone is much better off using that. If you don't want to do that, you can edit the NAS-Port attribute. If the NAS always sends it as zero, why not change it to something else? You'll need to change it consistently, i.e. not via a random number. Perhaps changing it to an MD5 hash of the username might be OK... ... if (NAS-Port == 0) { update request { Tmp-Octets-0 := "%{md5:%{User-Name}}" } update request { NAS-Port := "%{unpack:&Tmp-Octets-0 1 integer}" } } That's a little weird, but it should work. Alan DeKok.
Hi, On Sat, Sep 08, 2018 at 08:56:45AM -0400, Alan DeKok wrote:
If you don't want to do that, you can edit the NAS-Port attribute. If the NAS always sends it as zero, why not change it to something else? You'll need to change it consistently, i.e. not via a random number. Perhaps changing it to an MD5 hash of the username might be OK...
Thank you *very much* for the suggestion! That does solve the issue! :-) I've opened a bug report with the vendor a couple weeks ago, but so far they didn't change the hostapd...
Also, the radutmp file is not scalable. It requires a linear search to find a user. Given that it's 2018 and sqlite exists, everyone is much better off using that.
Migrating to SQL eventually sounds good; I didn't even know it was possible to use SQL for concurrency checks. I don't have that many users atm, though, so doing a linear search is probably causing less overhead than using a b-tree =) Cheers, HC
Hi, Small update on this old issue: On Sat, Sep 08, 2018 at 08:56:45AM -0400, Alan DeKok wrote: [...]
if (NAS-Port == 0) { [...]
The manufacturer never got back to me on my issue report, but: The newer firmwares don't send the NAS-Port attribute at all (before, it was set to 0). So the above line of unlang fails to evaulate and thus the NAS-Port is never updated to the hash of the username. Since I use only NASes of the same type, I've simply removed the conditional statement and always calculate the NAS-Port based on the user name's hash now. Cheers HC
participants (2)
-
Alan DeKok -
Hans-Christian Esperer