[isf-wifidog] Wifidog rewrite and protocol v2

[Philippe April]

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