Hi Philippe,<br><br>I very much like the idea of keeping almost all of the configuration options on the server side. This&nbsp; 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 &lt;<a href="mailto:isf_lists@philippeapril.com">isf_lists@philippeapril.com</a>&gt; wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Big email, watchout.<br>
This weekend, I spent quite a few hours working on a rewrite of<br>
wifidog gateway.<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>
Here&#39;s what I&#39;ve done so far, I started from scratch and kept and<br>
changed only the code I wanted:<br>
1. Removed a lot of the configuration variables. Right now, there&#39;s no<br>
more configuration file, everything is passed on the command line. If<br>
there&#39;s a need, we can go back to a configuration file easily.<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&#39;t give the config, it probably won&#39;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&#39;d rather start small and clean.<br>
People who want to use wifidog without an authentication? We&#39;ll see if<br>
we really want this, and if we do, maybe add code to support that as a<br>
The variables needed for startup:<br>
 &nbsp; &nbsp; &nbsp; &nbsp;--auth &lt;authserver_hostname&gt;<br>
 &nbsp; &nbsp; &nbsp; &nbsp;--lan &lt;lan interface&gt;<br>
If we can keep it this short, it&#39;ll be neat. There&#39;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&#39;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&#39;ll start with this.<br>
2. Once we got the configuration from the auth server, startup is<br>
initiated... Firewall rules, etc.<br>
3. The &quot;ping thread&quot; which was sending status information is renamed<br>
to a &quot;status thread&quot;. 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>
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>
This &quot;send status&quot; call is the connection that&#39;s initiated on startup<br>
(reusing code).<br>
I&#39;m thinking of doing basically a DIFF of what&#39;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 &quot;wdctl restart&quot;,<br>
which was quite a huge hack.<br>
This part is almost finished.<br>
4. I redid the way we block/allow traffic in iptables so it can be<br>
made &quot;per client&quot; (not with &quot;MARK&quot; anymore)<br>
5. There&#39;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&#39;ll need to research. If anybody can<br>
help, it&#39;d be great.<br>
6. There&#39;s no more linked list in memory that keeps who&#39;s connected,<br>
it&#39;s redundant information, as we can find everything from the auth<br>
server, or from the local firewall rules.<br>
7. For the protocol v2, I made my code clean enough so when the<br>
protocol v2 is defined and &quot;final&quot; 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&#39;s an easy parser and generator which is light, and works just<br>
like DOM pretty much, I would recommend using that.<br>
8. I made json-c included in the project and linked statically because<br>
it&#39;s light and it&#39;ll be easier to deploy on WRT54G&#39;s, there will just<br>
be a static wifidog library. I linked libhttpd statically too.<br>
I think that&#39;s all I&#39;ve done so far.<br>
If you&#39;re wondering, I&#39;m not working on it all alone. I&#39;ve talked to<br>
people already regarding the basic philosophy of the gateway to make<br>
sure I wasn&#39;t just thinking alone and coding scrap, but I&#39;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 &quot;activating&quot; the code... maybe plugins configured by ./<br>
configure switches...<br>
If anybody has requests/ideas/comments, QoS experience, etc. Please<br>
speak up!<br>
Philippe April<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