[isf-wifidog] [AllianceCSF] postgresql vs mysql, get into the flamebait

[wlanmac]

The question becomes, where should it be optional? 

Optional in the way it is now where it is used by the portal to be
compatible on the roaming side,

AP/WiFiDog ---> <wifidog protocol> ---> WiFiDog Portal ---> RADIUS

or optional for access provisioning to the router, for device / access
controller compatibility? 

AP/NAS ---> <RADIUS> ---> <something?> ---> WiFiDog Portal

(Note: "NAS" for Network Access Server is a more generic term for access
controller in RADIUS documentation). 

A concept I have been thinking of would be something along the lines of
what Marc suggested. A proxy to map the AAA features of a NAS with the
WiFiDog HTTP protocol. 

Such that you might have:

AP/NAS/Proxy ---> <wifidog> ---> WiFiDog Portal (to support old-school
sites)

AP/NAS ---> <RADIUS> ---> Proxy/WiFiDog Portal (to support standard
access controllers)

AP/NAS ---> <RADIUS> ---> <FreeRADIUS/SuperProxy> ---> Multiple WiFiDog
Portals based on Realm (the future)

It's just an idea... but, could be a way of achieving the best of all
worlds, RADIUS-wise.

David


On Tue, 2009-05-26 at 11:49 -0400, Sylvain Carle wrote:
> > je ne suis même pas sûr qu'on ait besoin d'un BD dans wifidog. En tout
> > cas, pas besoin pour le côté opérationel: i.e. authentification,
> > service, usagers, etc...  tout devrait être géré par RADIUS.
> 
> I would say "all could be managed by Radius" but it should remain an 
> option, not the only way. Radius is great but it might be too much to 
> ask to some of the communities listed on 
> http://dev.wifidog.org/wiki/Community - we should not forget that some 
> organizations have less ressources, we shall not create a situation 
> where they can't use wifidog anymore.
> 
> --
> Sylvain Carle
> www.afroginthevalley.com
> _______________________________________________
> WiFiDog mailing list
> WiFiDog at listes.ilesansfil.org
> http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog