Hi,
So, I've stumbled upon PF, and especially the work done around OOB for
the UniFi system back in late 2017/early 2018. Much of this was based on
the assumption on WPA2-PSK or WPA2-Ent (trying to work around the
caching, etc).
The solution also relies on the UniFi controller to be reachable (since
it utilizes the API to send the 'kick-sta' command). Not very optimal if
you have redundant RADIUS and/or PF, but no redundant UniFi controller
(which, AFAIK, is not possible yet, unless you have it as a VM). If you
have a central/cloud UniFi-controller, you're also entirely dependent on
Internet connectivity for this to work.
My question is; has anyone looked into doing the 'kick-sta' directly on
the AP? (i.e. try UniFi-controller, and if fail, try the 'kick-sta'
directly on the AP?).
Since the AP is the RADIUS client, PF should already know the IP for the
AP, and could do the required 'iwpriv'-commands via SSH. Some rare
race-conditions could occur, for example that the client roams before
you send the command (sending it to the old AP), but it would still be
better than nothing in the case of controller and/or Internet failure?
Added benefit would also be that you could do without the
UniFi-controller running 24/7 (f.ex. in home environments), as you'd
only rely on the controller for initial setup, and then only rely on the
APs and PF after that.
Any thoughts? Would this be too… MacGyvery? (-:
--
Joachim
_______________________________________________
PacketFence-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/packetfence-users
