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