[isf-wifidog] Future Idea Dump

Benoit Grégoire bock at step.polymtl.ca
Lun 15 Mai 10:27:00 EDT 2006


> Thoughts
>
> 1) Separate out wifidog and auth server and publish messaging
> protocols. I think this will give people the option of developing
> their our auth-servers/content servers etc, and allow a shared wifidog
> distribution.

That will happen with the protocol redesign, but there is otherwise very 
little incentive to spend any time on it. As far as I remember, the only 
patch to the gateway to ever to come from outsite ISF so far was from 
wireless london.  If the groups using forked/alternate auth service want it 
faster, they will probably need to write the first draft of the document 
themselves on the wiki. 

> 2) User Mac. Is this sent with the login/auth requests ? It would be
> handy to have it passed to the auth server

It is, and it is used by the auth server.

> 3) Login options. LW has various options and control levels given the
> possible parameters of user+pass+mac.
> a) Splash only - no login, just terms
> b) User+pass
> c) mac only - whitelist, auto login (staff perhaps)
> d) user+pass+mac (locked down) - admin user

a and b are already supported.  c is only supported by specifying it on the 
gateway side.  Moving it to the server is ticked 
http://dev.wifidog.org/ticket/76, but will require a protocol redesign and 
major gateway surgery.  The problem is that MAC-whitelisted addresses need to 
be whitelisted for all ports, so they must be permanently included in the 
firewall, they cannot wait until an http connection triggers wifidog into 
asking the server.  So they will have to be updated on a regular basis when 
the counters are updated.  As the list could get quite long, we should 
probably hash it, send the hash and send an update request only if the hash 
changes.

> 4) User realm/dimension. A gateway is a node, and belongs to a
> network. A user belongs to a network, but a network can be affiliate
> with other networks to allow user account sharing. Makes the admin
> reporting more complex, but may increase take up with business. i.e.
> coffee shop is a node, coffee chain is a network, it may affiliate
> with book shop chain network.

These are actually two different features.  One is network peering, which is 
planned for (the auth server was designed with it in mind, reporting would 
already work out of the box).  The second is node groups, allowing treating a 
group of nodes as an administrative entity.

> 5) Walled garden.
>
> Users are allowed to visit without logging. Means user traffic is not
> logged (no connection id), but allows a network to give user access to
> its own sites etc without login.
>
> LW does this with a 15 minute cron job that sets up the walled list as
> IP chain.

No need for that, it's already supported by the gateway.  Moving it to the 
auth server will be done with the previously mentioned protocol redesign.

> 6) Throttle.
>
> While you can build a real complex system, the actual requirement is
> throttle heavy users, or the whole system when its under load. A
> secondary pitch is for community meshes where business hosts nodes and
> throttle access during the day and then open it up when they don't use
> it.
>
> In reality I think you only need three bands high,med,low , and then
> assign a user to one of them. LW gets the band during login, but with
> wifidog, you could use it a part of the auth update to reallocate a
> user to a new band. If you wanted to get really techie, then the auth
> server could auto manage it.

See tickets 24 to 27.  We spent a lot of time thinking this over, and the 
multi-band idea simply doesn't solve (or even help) the problems in our case.  
While it may solve it for some other cases, implementing it if ticket 27 is 
implemented is trivial on the auth server.  Doing it without ticket 27 pretty 
ties us to the multi-band way of doing things, unless it's an optionally 
compilable gateway module. 

> 7) Tickets.
>
> Public ip sets up tick users with time limits or download limits, you
> should be able to monitor this, and use the auth server to remove the
> user.

That's very easy to add on the auth server, but no current group using wifidog 
expressed a need for this functionality or interest in implementing it.  
Quite frankly it's mostly usefull in commercial contexts, making it somewhat 
unlikely someone would implement it on their free time.

> 8) MyStatus/Messaging.
>
> PublicIp does use windows messaging to sent time left/node messages to
> the user, but this relies on the user having windows.
>
> If would be nice if with a DNS redirect the user types
> http://wifistatus/ , and gets their stats, login times, node closure
> time. I can't think of any other way of informing a user when they are
> going to be kicked off due to node opening hours etc.

Captive DNS is part of a branch of the gateway, but was never merged back in.  
However, it probably wouldn't solve your problem.  Your user would still have 
to take active action to get the information, which is useless to tell him he 
is about to get kicked out.
Three things are related to this:
-Allow the user to easily come back to the portal (ticket 4) (captive dns 
would help with this)
-Getting self-statistics, which should be done as part of my work on profiles.
-User messaging
-User intrusive messaging

Intrusive messaging (I'd like to keep the name, it reminds whoever uses it of 
what it actually does...) could be implemented as a new token 
state "USER_HAS_INTRUSIVE_MESSAGE".  Upon receiving this, the gateway 
wouldn't remove net access from the firewall, but would re-activate the http 
redirect, redirecting to the message on the auth server (a simple page with a 
continue button that would clear the toke state using the same flow as the 
login process, and then redirect to the user's original http request.

I hope to continue this really interesting discussion!


More information about the WiFiDog mailing list