[isf-wifidog] Wifidog rewrite and protocol v2

[Philippe April]

Hi Dana,

1. This is more of an authentication server issue, but I'll make sure  
to check.

2. I just put it in the "todo" document. The goal would be to define a  
policy per node. Either allow when auth is down, or deny (with error  
message explaining why).

On 25-Mar-08, at 12:21 PM, Dana Spiegel wrote:

> 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
>
> _______________________________________________
> WiFiDog mailing list
> WiFiDog at listes.ilesansfil.org
> http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog