[isf-wifidog] Wifidog rewrite and protocol v2

berry groenendijk berry.groenendijk at gmail.com
Mar 25 Mar 16:00:03 EDT 2008

Hi Philippe,

I very much like the idea of keeping almost all of the configuration options
on the server side. This  simplifies the management of the routers immensly.

I maintain a network of Freifunk routers (a OLSR mesh network). And the only
way I could get the network to function is when all wifidog gateways have
each others MAC address in the TrustedMACList. Till now this causes a lot of
maintenance when the network expands. By keeping the configuration on the
server it makes the maintenance of this routers much easier. But what if I
run several networks with different configs? Is that supported? Or should I
configure different authentication servers for different networks? Can the
startup parameter for the gateway, --auth, be a complete url? So, a
different url for each network?

Another possible solution is this. Each wifidog router could notify its
neighbour routers that they should trust each other. Perhaps this could be a
plugin. There is this script:
http://dev.wifidog.org/wiki/doc/gateway-server/WifiDogAndOlsr. But, it never
worked for me. If there is more stable solution for Wifidog in a mesh
network, that would be great.

Another option I really would like to see is that the gateway would support
multiple interfaces. That is the wifi interface AND the lan interface. I
would like to present a login/splash page for the wifi interface and the lan
interface at the same time.

Please also do NOT forget to keep supporting the functionality of sending
the MAC address as the GatewayID to the authentication server on login. It
allows use to have a central database with all the routers and their GPS
locations and thus enables us to present localized splash or login pages.

One other remark: stick with JSON. It works like a charm and is very
lightweight with a lot of language support.

I am very glad to see that there is some new development on the wifidog
gateway software. Keep up the good work!

Berry Groenendijk

On Tue, Mar 25, 2008 at 4:20 PM, Philippe April <isf_lists at philippeapril.com>

> 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

Berry Groenendijk
Skype: berryg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listes.ilesansfil.org/pipermail/wifidog/attachments/20080325/c3237b97/attachment.htm 

Plus d'informations sur la liste de diffusion WiFiDog