<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>
<br><div>Hello Guido,<br><div dir="ltr"><br>I'm glad you like it. Implementation-wise yaffmap may not satisfy the standards this interop project is aiming for. <br>But it hopefully gives some inspiration for things which at least I really wanted to see on a central map server. <br><br>Dennis<br><br><div><div id="ecxSkyDrivePlaceholder"></div>> Date: Wed, 25 Apr 2012 14:07:17 -0300<br>> Subject: Re: [Interop-dev] a crazy little thing called yaffmap<br>> From: guidoiribarren@buenosaireslibre.org<br>> To: dennis_bartsch@hotmail.com; interop-dev@lists.funkfeuer.at<br>> <br>> Absolutely amazing. I've had for the past few weeks a 'mental<br>> wishlist' of info / reports i'd like to get from nodes, and was about<br>> to improvise some crude scripts when i had time, but it seems you<br>> implemented them all and in a proper way!<br>> Will definitely check it out on spare time this weekend, ...and maybe<br>> even contribute back an agent script for batman-adv?<br>> <br>> Cheers!<br>> Free software is great :)<br>> <br>> guido<br>> <br>> On 4/25/12, Dennis Bartsch <dennis_bartsch@hotmail.com> wrote:<br>> ><br>> ><br>> ><br>> > Hello Community,<br>> ><br>> > I am from Freifunk Berlin and would like to introduce to you an<br>> > implementation of a node database I started with a friend we call yaffmap.<br>> > It got its name because at that time we have had many mapservers in Berlin<br>> > and so it started as yet another approach for a Freifunk map.<br>> ><br>> > The intention was to make a server that not just produces points and lines<br>> > (nodes and their links) but to gather all information that might<br>> > help to understand why a link is as bad as it is. This includes to gather<br>> > wireless scan results, the effective rate chosen/calculated by the<br>> > wireless driver to a specific neighbour and so on. Furthermore it had to be<br>> > independent from the routing-protocol and its daemons (but<br>> > needs it to gather useful info) and the IP version (or even no IP version<br>> > for RPs like batman) and had to be able to upload and store data<br>> > from multiple routing protocols on the same node. In order to sample so much<br>> > information we went the route of scripting an agent for the<br>> > map-server which runs on the nodes gathering the information and uploading<br>> > it through a JSON interface to the server. For link-state-protocols<br>> > like OLSR we even implemented the upload of the global topology to the<br>> > server, which gave us some headache. From the beginning on<br>> > I stressed the need for decentralized operation, so replication between the<br>> > servers was implemented and any community which wants can<br>> > have their own map data server. Moreover I cleary wanted the<br>> > datacollection/storage to be independent from the frontend the map user is<br>> > presented. In Berlin everytime a new map came along and an old one was gone<br>> > we saw huge ammounts of data simply disappear. So the<br>> > server only provides a SOAP interface for UIs and other services to use to<br>> > get map data. The representation of a node in the database ist<br>> > best seen on a graphic. I uploaded it to imageshack, see [1]. A little bit<br>> > of documentation is found under [2], but wasn't thoroughly updated<br>> > after we left concept stage.<br>> ><br>> > We got to the point where the agent (bunch of shell/AWK) for the nodes runs<br>> > on openWRT (best with madwifi and ath9k/ath5k) with olsrd<br>> > (other routing daemons simply need scripts for data gathering, agent is held<br>> > modular), uploades many useful information to the server (or<br>> > another if the first does not respond; multiple can be configured) using<br>> > JSON, where it gets stored correctly into a SQL database and replicated<br>> > to other servers and provided through a SOAP interface. The agent even is<br>> > already provided as a package in the respected PBerg Freifunk<br>> > Firmware. There also exists a 'proof-of-concept' implementation for a map<br>> > frontend, see [3]. The code is hosted on github as seen und [4].<br>> > Because of the frontend development got stuck the frontend SOAP interface is<br>> > not very sophisticated nor much tested as is the frontend itself.<br>> ><br>> > The result is a database which can answer more complex question to the mesh<br>> > engineer or software developer than every I took a look at.<br>> > Maybe you want to know the average effective rate on all 11n interfaces or<br>> > all 5GHz interfaces? Or you might be interested in the average<br>> > ETX on different channels in a certain geographic area. Or you want to<br>> > compare how different routing daemons evaluate the quality of a<br>> > certain link. Maybe you even want to draw a noise map. Or wouldn't it be<br>> > interesting to see the correlation between the effective rate of a<br>> > wifi link and the metrics which result in the routing daemons?<br>> ><br>> > Because the node data includes a 'misc' field through which any kind of node<br>> > id or statistics could be stored/sent this is can even be integrated<br>> > into existing community portals.<br>> ><br>> > Hope you find this interesting<br>> > Dennis<br>> ><br>> > [1] http://imageshack.us/f/21/bildschirmfotovom201204.png/<br>> > [2] http://wurststulle.dyndns.org/yaffmap/trac/wiki/DocumentationIndex (Be<br>> > patient. It is dripping through an ADSL upload)<br>> > [3] http://yaffmap.basicinside.de/vendor/yaffmap-map/<br>> > [4] https://github.com/wurststulle/yaffmap-backend<br>> > https://github.com/wurststulle/yaffmap-agent<br>> > https://github.com/wurststulle/yaffmap-map<br>> > [5] some statistics: http://wurststulle.dyndns.org/yaffmap/<br>> ><br></div> </div></div> </div></body>
</html>