[isf-wifidog] Wifidog rewrite and protocol v2

[Philippe April]

I just created this page:

http://dev.wifidog.org/wiki/doc/developer/WiFiDog_V2

For documenting the new architecture. I consider all my code done so  
far just proof of concept code, I'll keep/propose the good stuff, and  
leave the bad stuff out!

We need to define everything, including (and most importantly) the  
protocol which is at:

http://dev.wifidog.org/wiki/doc/developer/WiFiDogProtocol_V2

We need to brainstorm, agree/disagree about things, propose solutions,  
better solutions, say why something won't work, etc. so we get the  
best architecture in the end. If you experienced code, post it.

Especially QoS since there seems to be so many ways of doing it. I  
tried "HTB" (whatever that is) to limit connections to 100k/sec  
download and 10k/sec upload globally THEN limit only one person (all  
by mac address, using the cls_u32 module and negative offsets, will  
document tomorrow)... it worked, but I'm sure there are better ways to  
share the bandwidth.

I'd like to organize a "work/hack day" (in montreal...) very very soon  
with people who are interested, and document the day enough so  
external people can read the discussions and see what we talked about,  
etc. I'm eager to have a v2 going soon and the architecture well  
defined...

Talk to you all soon

On 25-Mar-08, 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