[Chilli] Thoughts on making Chilli's DHCP network interface aware

[David Bird]

Hi Pieter,

You have all your EAP subscribers on one VLAN with UAM on the other? If
so, then that is how you should reliably know which network (EAP/UAM)
the user is on. If you are not getting any indication from the EAP NAS
about the subscriber disconnect, then I don't see how chilli would
otherwise know if that same client came back to UAM. It should work, but
as you noted, chilli doesn't really know (because EAP and UAM *can* work
together, of course). 

Perhaps what you want is a VLAN based option to not allow logout? 

I mentioned it before, but I personally think removing the logout
ability is one thing, but probably more important is just to remove the
LINK to the logout feature for these users. Another idea might be to add
a query string parameter indicating a "auth=eap" so your portal can know
not to show a logout link...

David


On Sat, 2010-05-22 at 22:27 +0200, IT-Systemmanagement Pieter Hollants
wrote:
> Hi all,
> 
> as you might have noticed I'm working for a customer on the
> implementation of a "neat" seperation between the different access
> methods provided by CoovaChili. The idea is to allow a user-induced
> logout (via "logout" host or "http://x.y.z:3990/logout") only on the
> WLAN protected via UAM, while the WLAN using WPA-EAP should not offer
> such a possibility.
> 
> While I have such functionality readily implemented, the problem with
> CoovaChilli's current connection handling is that it can not distinguish
> clients based on the network interface they're using. This means that a
> client who has authenticated to a WPA-EAP protected WLAN (we can
> detected he's using WPA-EAP because we act as radius proxy) correctly
> has a new "allow_logoff" flag set to 0. But when he switches to an
> ordinary WPA-PSK protected WLAN with UAM in the background, there is no
> way to detect this from within CoovaChilli: the client will obtain the
> same IP address via DHCP that he had on the WPA-EAP WLAN.
> 
> I'm now thinking of extending the hashtable functions in dhcp.c to
> include the network interface over which the request came in in the hash
> calculation. This would mean that a user gets a new, seperate IP address
> when he changes to the WPA-PSK/UAM WLAN, meaning I can set the new
> "allow_logoff" flag properly.
> 
> Naturally, this does not solve the problem when dhcpif and proxylisten
> use the same interface, but the way I see it such a setup would not make
> any sense: a WPA-PSK/UAM WLAN would use a seperate VLAN than the WPA-EAP
> protected WLAN, and as such a seperate local network interface.
> 
> But, before I dive into the code, any comments? Anything obvious I
> oversaw why this can't work out anyway?
>