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

[David Bird]

Hi Pieter,

When using a VLAN, I don't think you'll have to create another ip space
or another interface (unless you want to). If you can split your network
up into VLANs on eth0, for example, then you can run chilli on dhcpif
eth0 with --ieee8021q. Then chilli will detect and note the VLAN of each
session (and it doesn't even really care what VLAN that is). Now, your
no-logout feature can be linked to the VLAN, I'd imagine. 

Also, if you plan on submitting your feature to chilli, could you please
make it a compile time option too? 

A couple notes:

- Refer to configure.in for adding compile time options. Use an existing
example. 

- To add run-time options, see cmdline.ggo and try not to waste your
time editing cmdline.[ch] by hand. (pretty much everyone misses the fact
that cmdline.[ch] are generated files by gengetopt). 



On Sun, 2010-05-23 at 23:21 +0200, IT-Systemmanagement Pieter Hollants
wrote:
> Hi David,
> 
> Am 23.05.2010 06:40, schrieb David Bird:
> > 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). 
> 
> Exactly there was the mistake in my thinking. First of all, I've read
> through IEEE 802.11i and IEEE 802.1x and there simply is no such thing
> as a disconnect indication from the access point to the RADIUS server.
> The AP simply doesn't share its state, so all CoovaChilli can see at any
> time is a request to "open the gate". Which is logical, since both
> standards don't want the RADIUS server (or a proxy such as CoovaChilli)
> to track state.
> 
> Second, I was under the misconception that the two WLANs end up in
> different VLANs, which they actually do not currently -- I explicitly
> routed the EAP VLAN through CoovaChilli as well since I wanted to reuse
> the same IP network independent of the WLAN chosen and it doesn't hurt
> if CoovaChilli implements a "second switch" behind the AP, considering
> it acts as Radiusproxy.
> 
> Now you got me thinking, however. Either use a seperate VLAN for EAP,
> then I'd have to assign a second IP net, or extend CoovaChilli so it can
> do "dhcpif" on two interfaces at once. Running two Chilli instances
> doesn't make much sense in this scenario, I guess.
> 
> > 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...
> 
> In the patch I developed so far I did something similar: I added a
> "allow_logoff" parameter so the portal knows whether it should show a
> link or not. Independently, I also had to consider the case where users
> enter the word "logout" because it's advertised all over the portal. So
> it makes sense to do both: indicate to the portal not to show the link
> but also disable the two ways the user has (http://IP/logout and "logout").
>