[isf-wifidog] Wifidog rewrite and protocol v2

[Dana Spiegel]

Philippe,

This is great news. All of this functionality are things we have been  
wanting for some time (especially the rules/qos kept serverside).

2 additional things to think about:

1) right now, I can authenticate twice (or more) with the same user on  
the same gateway. The server now things that there are 2 of me on the  
local network. I don't know if this can be adjusted (since there may  
well be 2 devices that I am authenticating), but if not, the gateway  
doesn't clean out the old login even if the new one is using the same  
MAC address.

2) Really Important: we need to fail gracefully if the auth server  
becomes unavailable (offline, network outage somewhere else other than  
the local DSL line, etc). Right now, if the auth server was available,  
but is no longer, people get blocked out. Instead, people should be  
able to get through the gateway without authentication. When the  
server comes back online, they should be required to reauthenticate.

-- 
Dana Spiegel
Executive Director
NYCwireless
dana at NYCwireless.net
www.NYCwireless.net
+1 917 402 0422

Read the Wireless Community blog: http://www.wirelesscommunity.info

On Mar 25, 2008, at 11:20 AM, Philippe April wrote:
> Hi,
>
> Big email, watchout.
>
> This weekend, I spent quite a few hours working on a rewrite of
> wifidog gateway.
>
> My personal goal for this is to make the gateway even more generic and
> dumb than it was, and implement new ideas and concepts, including the
> v2 protocol.
>
> Here's what I've done so far, I started from scratch and kept and
> changed only the code I wanted:
>
> 1. Removed a lot of the configuration variables. Right now, there's no
> more configuration file, everything is passed on the command line. If
> there's a need, we can go back to a configuration file easily.
>
> The thinking behind this is: wifidog needs an auth server, so it could
> get all its config from the auth server, on initialisation. So right
> now, on startup, I connect to the auth server and ask for the
> configuration (which could include firewall rules, global QoS
> settings, etc.). Once the configuration has been gotten, I startup. If
> the auth server doesn't give the config, it probably won't
> authenticate anyway. That part is well implemented and works so far.
> If we feel the need, we can go back to a complex configuration file,
> but I'd rather start small and clean.
>
> People who want to use wifidog without an authentication? We'll see if
> we really want this, and if we do, maybe add code to support that as a
> plugin.
>
> The variables needed for startup:
> 	--auth <authserver_hostname>
> 	--lan <lan interface>
>
> If we can keep it this short, it'll be neat. There's a lot we need to
> look at regarding the paths for wifidog to work, if we go RESTful or
> not, etc. and make sure it's not all hardcoded (unless the naming is
> so great we never feel the need to change it). Again, to keep the code
> base clean and short, I'll start with this.
>
> 2. Once we got the configuration from the auth server, startup is
> initiated... Firewall rules, etc.
>
> 3. The "ping thread" which was sending status information is renamed
> to a "status thread". The status thread will also send all statistics,
> etc, so only one big/bigger packet instead of Y connections for Y
> clients connected.
>
> The status thread will communicate statistics, connected clients,
> uptime, etc. Thoughts: the auth server could reply with configuration
> changes, deny clients, change QoS rules for a particular person, etc.
> Basically, flexibility.
>
> This "send status" call is the connection that's initiated on startup
> (reusing code).
>
> I'm thinking of doing basically a DIFF of what's pushed from the auth
> server with what we have local. That way, on startup we can resume
> where we were, since the auth server KNOWS who should be connected.
> That removes all the code that was there for support "wdctl restart",
> which was quite a huge hack.
>
> This part is almost finished.
>
> 4. I redid the way we block/allow traffic in iptables so it can be
> made "per client" (not with "MARK" anymore)
>
> 5. There's basic QoS support. The auth server can push limits (max
> incoming kbps, max outgoing kbps) and limit clients too, but I lack
> experience with QoS support so I'll need to research. If anybody can
> help, it'd be great.
>
> 6. There's no more linked list in memory that keeps who's connected,
> it's redundant information, as we can find everything from the auth
> server, or from the local firewall rules.
>
> 7. For the protocol v2, I made my code clean enough so when the
> protocol v2 is defined and "final" we can put it in easily. I know
> that for now we had talking about XML, or YAML, but I tried to find
> parsers (light ones), but nothing worked easily. I went for JSON,
> there's an easy parser and generator which is light, and works just
> like DOM pretty much, I would recommend using that.
>
> 8. I made json-c included in the project and linked statically because
> it's light and it'll be easier to deploy on WRT54G's, there will just
> be a static wifidog library. I linked libhttpd statically too.
>
> I think that's all I've done so far.
>
> If you're wondering, I'm not working on it all alone. I've talked to
> people already regarding the basic philosophy of the gateway to make
> sure I wasn't just thinking alone and coding scrap, but I'd really
> like to keep the gateway super clean, and as small as possible, and
> make it easy to customize if people have specific needs without
> necessarily "activating" the code... maybe plugins configured by ./
> configure switches...
>
> If anybody has requests/ideas/comments, QoS experience, etc. Please
> speak up!
>
> Philippe April
>
> _______________________________________________
> WiFiDog mailing list
> WiFiDog at listes.ilesansfil.org
> http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog