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

[Stelio Gouveia]

Hi Pieter

Can you make this patch publicly available.

I assume this makes it possible to change the query string parameters
depending on
which wireless network a client is connected to?

- Stelio

On Sun, May 23, 2010 at 11:21 PM, IT-Systemmanagement Pieter Hollants <
pieter at hollants.com> 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").
>
> --
> Dipl.-Wirtsch.-Inform. Pieter Hollants
> IT-Systemmanagement Pieter Hollants          Tel. : (+49) (0)6192-910717
> Rossertstraße 80                             Fax  : (+49) (0)6192-910713
> 65830 Kriftel                                eMail: pieter at hollants.com
>
> _______________________________________________
> Chilli mailing list
> Chilli at coova.org
> http://lists.coova.org/cgi-bin/mailman/listinfo/chilli
>

--
Skyrove Software Engineer,
Skyrove (Pty) Ltd
Technology Top 100 Award Winner (2006)
Mobile: +27 82 34 09 120
Tel: +27 861 ROVERS (0861 768 377)
Fax: +27 86 6204077
Email & Gtalk: stelio at skyrove.com
Web:   www.skyrove.com

This message contains confidential information. If you are not the intended
recipient you are notified that disclosing, copying, distributing or taking
any action in reliance on the contents of this information is strictly
prohibited. E-mail transmission cannot be guaranteed to be secure or
error-free as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses. The sender therefore does not
accept liability for any errors or omissions in the contents of this
message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.coova.org/pipermail/chilli/attachments/20100524/502790f7/attachment.htm>