[B.A.T.M.A.N.] batman-adv use in Manchester NH

[B.A.T.M.A.N.] batman-adv use in Manchester NH

[Arc Riley]

[-- Attachment #1: Type: text/plain, Size: 1282 bytes --]

We're setting up batman-adv on open-mesh.com OM1P routers and unidirectional
antennas to connect homes and businesses across the city.

I've read the protocol docs, but a few key questions about the current
kernel implementation;

Is there currently a multicast protocol or method for a node on the network
to get local link stats from every other node on the network?  We're looking
at this for a GUI desktop diagnostics tool which shows the current 1-hop
link states for all nodes on the network

Is there a layer 3 solution for routing each end user to the nearest IP
gateway that works well on top of a batman-adv network?

Does batman-adv currently support "bonding"; ie, will it route all packets
through the best connection until it's saturated, or will it spread packets
across connections (especially that are near the same quality) for optimal
speed?

What kind of traffic throughput is the kernel module capable of?  Does the
module multithread properly for multicore utilization?  Would a FPGA variant
be needed to have a "mesh switch" or would a high-end multicore ARM be
reasonably able to handle say an 8-port gigabit mesh switch?

These questions are less to evaluate batman-adv for our uses than looking
forward at what we'll need to develop as we expand.

Thanks!

[-- Attachment #2: Type: text/html, Size: 1415 bytes --]

Re: [B.A.T.M.A.N.] batman-adv use in Manchester NH

[Marek Lindner]

On Tuesday 05 May 2009 22:08:44 Arc Riley wrote:
> We're setting up batman-adv on open-mesh.com OM1P routers and
> unidirectional antennas to connect homes and businesses across the city.

Cool ! May I ask who "we" is and how you would describe the current status ?


> Is there currently a multicast protocol or method for a node on the network
> to get local link stats from every other node on the network?  We're
> looking at this for a GUI desktop diagnostics tool which shows the current
> 1-hop link states for all nodes on the network

If you want to assemble a view of the whole topology the built-in vis server 
might be what you are looking for. I think the 24C3 video that you can find on 
our website describes how it works.


> Is there a layer 3 solution for routing each end user to the nearest IP
> gateway that works well on top of a batman-adv network?

Actually, this gateway question puzzles us as well. We did not find a very good 
solution for this problem yet. Batman-adv knows the best route towards the 
gateway - no problem here. But how can we propate that upwards ? Setting a 
route (which would be layer 3) ? We could even create an API that allows other 
processes to retrieve the best gateway but we "just" have a mac address no IP 
address.


> Does batman-adv currently support "bonding"; ie, will it route all packets
> through the best connection until it's saturated, or will it spread packets
> across connections (especially that are near the same quality) for optimal
> speed?

As soon as a link is used its link quality will go down as well but I think 
you are referring to a feature known as "Multipath Routing" 
(http://en.wikipedia.org/wiki/Multipath_routing) ?! Currently, batman does not 
have this feature. I'm not aware of any implementation that does as it is 
quite tricky. If you know some let me know.  :-)

On the other hand Simon is working on "short distance" bonding (which 
simplifies the task a lot). So far we have no working code.


> What kind of traffic throughput is the kernel module capable of?  Does the
> module multithread properly for multicore utilization?  Would a FPGA
> variant be needed to have a "mesh switch" or would a high-end multicore ARM
> be reasonably able to handle say an 8-port gigabit mesh switch?

I'm not the right guy to answer the "how much power do we need for an 8-port 
gigabit switch". This is not directly related to batman. I hope someone else 
can jump in.

Batman-adv is fully multithreaded as every reasonable linux module should be. 
Thats one of the main reasons that make it quite time consuming to debug - 
every little race condition leads to crashes and then you look for the needle 
in the haystack. :-)


> These questions are less to evaluate batman-adv for our uses than looking
> forward at what we'll need to develop as we expand.

Sounds great - we are looking forward to all kind of feedback / contributions. 
Let us know if you have more questions.

Regards,
Marek

Re: [B.A.T.M.A.N.] batman-adv use in Manchester NH

[Arc Riley]

[-- Attachment #1: Type: text/plain, Size: 3964 bytes --]

> Cool ! May I ask who "we" is and how you would describe the current status
> ?


We're a new cooperative, the status is primarily planning with a few nodes
on the mesh and test builds.  We're hopefully going to merge the previous
effort from DynDNS to build a layer 3 mesh using Meraki Minis into one
network.

Our goal is just layer 2, allowing any member to provide layer 3 services
(free or commercial) over the mesh.


If you want to assemble a view of the whole topology the built-in vis server
> might be what you are looking for. I think the 24C3 video that you can find
> on
> our website describes how it works.


I haven't found any such video on the website.  Is the vis server setup for
batman-adv or just the layer 3 batman?  Is the protocol used for nodes to
announce their status documented?

We're building a desktop/mobile app using OpenStreetMap data and Mapnik, we
don't want to require Internet access to view available nodes from any
user's connection to the mesh so that it can be used to view and diagnose
the network in any situation.  If that software could listen to the node
status announcements ("I have X quality link with node A, Y quality link
with node B, Z quality link with node C"), along with nodes announcing other
properties including long/lat, wifi protocol and signal, etc, this should be
very easy to show colored links indicating their quality.

Since we need local link status from nodes, and not the compiled quality to
route to any node, listening to OGM frames is not enough.


Actually, this gateway question puzzles us as well. We did not find a very
> good
> solution for this problem yet. Batman-adv knows the best route towards the
> gateway - no problem here. But how can we propate that upwards ? Setting a
> route (which would be layer 3) ? We could even create an API that allows
> other
> processes to retrieve the best gateway but we "just" have a mac address no
> IP
> address.


How about running this as a custom DHCP server which uses the above
mentioned data to determine the "best" gateway on that network and return
the relevant information (IP, netmask, gateway IP) to each client with a
timeout sufficient for dealing with mobile users in a reasonable amount of
time.

This would be a fun project to work on.


On the other hand Simon is working on "short distance" bonding (which
> simplifies the task a lot). So far we have no working code.


Bonding as in when two nodes have multiple direct connections to each other,
dividing frames accordingly rather than continually switching all traffic to
the highest quality link.

This would be very useful for multi-radio routers operating multiple links
on different channels (or even 802.11G vs 802.11A) between the same set of
nodes.  Standard ethernet bonding is not preferable since you'd want the
mesh protocol to use lower TQ links (ie, channel 6 gets periodic high
interferance) less than higher TQ links (ie, 802.11A often has little
interferance).

Also, it would be interesting to see frame duplication for redundancy (and
thus lower packet loss) over multiple links, removing duplicates on the
other side of each link, though that's obviously more challenging for
duplicate removal.  Could have a floating window on each side for frame CRCs
or even full frame headers to detect dups.



On Tue, May 5, 2009 at 1:26 PM, Dennis Bartsch
<dennis_bartsch@hotmail.com>wrote:

> What for does one want an 8-port gigabit mesh-switch?
> meshing with batman-adv is a totally decentral thing.
>

An 8-port gigabit switch is an extreme case, a 3-port gigabit fiber + 5 port
100m copper switch would be more reasonable.

I'm refering to fiber switch connecting a small group of open-mesh routers
with redundant fiber and wifi connections on either side, a small piece of a
mesh spanning potentially thousands of nodes.  Obviously at this size we'd
have to start making changes to the batman-adv settings to avoid having the
network flooded with OGMs.

[-- Attachment #2: Type: text/html, Size: 5080 bytes --]

Re: [B.A.T.M.A.N.] batman-adv use in Manchester NH

[Marek Lindner]

On Wednesday 06 May 2009 02:11:57 Arc Riley wrote:
> I haven't found any such video on the website.  Is the vis server setup for
> batman-adv or just the layer 3 batman?  Is the protocol used for nodes to
> announce their status documented?
>
> We're building a desktop/mobile app using OpenStreetMap data and Mapnik, we
> don't want to require Internet access to view available nodes from any
> user's connection to the mesh so that it can be used to view and diagnose
> the network in any situation.  If that software could listen to the node
> status announcements ("I have X quality link with node A, Y quality link
> with node B, Z quality link with node C"), along with nodes announcing
> other properties including long/lat, wifi protocol and signal, etc, this
> should be very easy to show colored links indicating their quality.
>
> Since we need local link status from nodes, and not the compiled quality to
> route to any node, listening to OGM frames is not enough.

What you want is the vis server that does all that for you. In the /proc 
filesystem you will find a file called "vis" which outputs all the data you want 
in the well-known dot draw format. You can use any dot draw parser to generate 
a map for your mesh.
Basically, this vis server is quite similar to the layer 3 vis server but it 
is integrated into the module (no additional programs needed - just activate 
it). 
Once your network grows you will appreciate the vis server sync feature.  :-)

The video can be downloaded here:
http://downloads.open-mesh.net/batman/misc/24C3-Wireless_Kernel_Tweaking.mkv
and other documentation can be found here:
http://open-mesh.net/wiki/UserDocs


> How about running this as a custom DHCP server which uses the above
> mentioned data to determine the "best" gateway on that network and return
> the relevant information (IP, netmask, gateway IP) to each client with a
> timeout sufficient for dealing with mobile users in a reasonable amount of
> time.

We thought about a modified client which would query the local module for the 
link quality information before accepting DHCP answers. Implementing a client 
might be easier than the server.


> Bonding as in when two nodes have multiple direct connections to each
> other, dividing frames accordingly rather than continually switching all
> traffic to the highest quality link.
>
> This would be very useful for multi-radio routers operating multiple links
> on different channels (or even 802.11G vs 802.11A) between the same set of
> nodes.  Standard ethernet bonding is not preferable since you'd want the
> mesh protocol to use lower TQ links (ie, channel 6 gets periodic high
> interferance) less than higher TQ links (ie, 802.11A often has little
> interferance).

Thats what we mean with "short distance" bonding. I agree with you - it could 
be very valuable.

Regards,
Marek

Re: [B.A.T.M.A.N.] batman-adv use in Manchester NH

[Antoine van Gelder]

On 06 May 2009, at 07:15 , Marek Lindner wrote:

> On Wednesday 06 May 2009 02:11:57 Arc Riley wrote:
>> I haven't found any such video on the website.  Is the vis server  
>> setup for
>> batman-adv or just the layer 3 batman?  Is the protocol used for  
>> nodes to
>> announce their status documented?
>>
>> We're building a desktop/mobile app using OpenStreetMap data and  
>> Mapnik, we
>> don't want to require Internet access to view available nodes from  
>> any
>> user's connection to the mesh so that it can be used to view and  
>> diagnose
>> the network in any situation.  If that software could listen to the  
>> node
>> status announcements ("I have X quality link with node A, Y quality  
>> link
>> with node B, Z quality link with node C"), along with nodes  
>> announcing
>> other properties including long/lat, wifi protocol and signal, etc,  
>> this
>> should be very easy to show colored links indicating their quality.
>>
>> Since we need local link status from nodes, and not the compiled  
>> quality to
>> route to any node, listening to OGM frames is not enough.
>
> What you want is the vis server that does all that for you. In the / 
> proc
> filesystem you will find a file called "vis" which outputs all the  
> data you want
> in the well-known dot draw format. You can use any dot draw parser  
> to generate
> a map for your mesh.
> Basically, this vis server is quite similar to the layer 3 vis  
> server but it
> is integrated into the module (no additional programs needed - just  
> activate
> it).


Hi Arc,

If you'd like you can also take look at:

   http://code.google.com/p/afrimesh/

The project is very young and still under heavy development but it  
does have working code using client-side Javascript & the  
OpenStreetMap libraries to draw mesh maps from the vis server.

A couple of caveats though:

   1) My development environment is running layer-3 B.A.T.M.A.N.
      and I haven't even thought yet about any potential issues
      running layer-2.

   2) I've patched the layer-3 vis daemon with a command-line
      option to output the mesh map in JSON format rather than
      dot as I found it a tad more amenable to abuse. (Btw, is
      this something anyone else would find useful? I'd be happy
      to clean up & contribute the patch!)

  - antoine



--
http://7degrees.co.za
"Libré software for human education."

Re: [B.A.T.M.A.N.] batman-adv use in Manchester NH

[Marek Lindner]

On Wednesday 06 May 2009 13:48:03 Antoine van Gelder wrote:
>    http://code.google.com/p/afrimesh/
>
> The project is very young and still under heavy development but it
> does have working code using client-side Javascript & the
> OpenStreetMap libraries to draw mesh maps from the vis server.

Very nice project!
I think it would be a good idea to add a link and a short project description 
on open-mesh.net to point people to your project. What do you think ?


>    2) I've patched the layer-3 vis daemon with a command-line
>       option to output the mesh map in JSON format rather than
>       dot as I found it a tad more amenable to abuse. (Btw, is
>       this something anyone else would find useful? I'd be happy
>       to clean up & contribute the patch!)

Yes, I'm interested.  :-)
JSON sounds like a good alternative to dot draw. If you bring your patch into 
shape I will commit it. May be you add an option to switch between dot draw 
and JSON ?

Regards,
Marek

[B.A.T.M.A.N.] [PATCH] Add switch for vis daemon to serve mesh topology in JSON format

[Antoine van Gelder]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Patch attached for review.

NOTES

* -j turns on JSON mode and closes the socket after serving the  
browser request.

* Data is served in the format

     [ { router : "d.d.d.d", neighbour|gateway : "d.d.d.d", label :  
d.dd|"HNA" }, ... ]

   e.g.

     HTTP/1.0 200 OK
     Content-type: application/json

     [
         { router : "10.0.0.5", neighbour : "10.0.0.3", label : 1.01 },
         { router : "10.0.0.5", neighbour : "10.0.0.6", label : 1.00 },
         { router : "10.0.0.5", neighbour : "10.0.0.1", label : 1.00 },
         { router : "10.0.0.3", neighbour : "10.0.0.5", label : 1.00 },
         { router : "10.0.0.3", neighbour : "10.0.0.1", label : 1.00 },
         { router : "10.0.0.3", neighbour : "10.0.0.6", label : 1.00 },
         { router : "10.0.0.6", neighbour : "10.0.0.5", label : 1.00 },
         { router : "10.0.0.6", neighbour : "10.0.0.3", label : 1.00 },
         { router : "10.0.0.6", neighbour : "10.0.0.1", label : 1.00 },
         { router : "10.0.0.1", neighbour : "10.0.0.3", label : 1.00 },
         { router : "10.0.0.1", neighbour : "10.0.0.5", label : 1.00 },
         { router : "10.0.0.1", neighbour : "10.0.0.6", label : 1.03 },
         { router : "10.0.0.1", gateway : "0.0.0.0/0.0.0.0", label :  
"HNA" }
     ]


Thank you Marek!

  - antoine


- --

diff --git a/vis.c b/vis.c
index 4b8a5df..9b6aeaa 100644
- --- a/vis.c
+++ b/vis.c
@@ -58,6 +58,8 @@ buffer_t *fillme = NULL;
  static int8_t stop;
  uint8_t debug_level = 0;

+formats output_format = dot;
+
  struct hashtable_t *node_hash;
  struct hashtable_t *secif_hash;

@@ -328,7 +330,7 @@ void write_data_in_buffer() {
  	struct list_head *list_pos, *list_pos_tmp, *prev_list_head;
  	struct hash_it_t *hashit = NULL;
  	char from_str[16], to_str[16], hna_str[16], tmp[100];
- -
+  char first = 1;

  	memset( tmp, 0, sizeof(tmp) );

@@ -384,7 +386,15 @@ void write_data_in_buffer() {

  						}

- -						snprintf( tmp, sizeof( tmp ), "\"%s\" -> \"%s\"[label=\"%.2f\"] 
\n", from_str, to_str, (float)( orig_node->tq_max / (float)neigh- 
 >tq_avg ) );
+            if ( output_format == json ) {
+              snprintf( tmp, sizeof( tmp ),
+                        "%s\t{ router : \"%s\", neighbour : \"%s\",  
label : %.2f }",
+                        (first ? "" : ",\n"), from_str, to_str,  
(float)( orig_node->tq_max / (float)neigh->tq_avg ) );
+              first = 0;
+            } else {
+              snprintf( tmp, sizeof( tmp ), "\"%s\" -> \"%s\"[label= 
\"%.2f\"]\n", from_str, to_str, (float)( orig_node->tq_max /  
(float)neigh->tq_avg ) );
+            }
+
  						fillme->buffer = (char *)debugRealloc( fillme->buffer,  
strlen( tmp ) + strlen( fillme->buffer ) + 1, 408 );

  						strncat( fillme->buffer, tmp, strlen( tmp ) );
@@ -400,7 +410,16 @@ void write_data_in_buffer() {
  					addr_to_string( hna->addr, to_str, sizeof( to_str ) );
  					addr_to_string( ( hna->netmask == 32 ? 0xffffffff : htonl( ~  
( 0xffffffff >> hna->netmask ) ) ), hna_str, sizeof( hna_str ) );

- -					snprintf( tmp, sizeof( tmp ), "\"%s\" -> \"%s/%s\"[label=\"HNA\"] 
\n", from_str, to_str, hna_str );
+          if ( output_format == json ) {
+            snprintf( tmp, sizeof( tmp ),
+                      "%s\t{ router : \"%s\", gateway : \"%s/%s\",  
label : \"HNA\" }",
+                      (first ? "" : ",\n"), from_str, to_str,  
hna_str );
+            first = 0;
+          } else {
+            snprintf( tmp, sizeof( tmp ), "\"%s\" -> \"%s/%s\"[label= 
\"HNA\"]\n", from_str, to_str, hna_str );
+          }
+
+
  					fillme->buffer = (char *)debugRealloc( fillme->buffer,  
strlen( tmp ) + strlen( fillme->buffer ) + 1, 409 );

  					strncat( fillme->buffer, tmp, strlen( tmp ) );
@@ -410,7 +429,14 @@ void write_data_in_buffer() {
  				/*printf("gw_class %d\n",(unsigned int)orig_node->gw_class);*/
  				if ( orig_node->gw_class != 0 ) {

- -					snprintf( tmp, sizeof( tmp ), "\"%s\" ->  
\"0.0.0.0/0.0.0.0\"[label=\"HNA\"]\n", from_str );
+          if ( output_format == json ) {
+            snprintf( tmp, sizeof( tmp ),
+                      "%s\t{ router : \"%s\", gateway : \"%s\",  
label : \"%s\" }",
+                      (first ? "" : ",\n"), from_str,  
"0.0.0.0/0.0.0.0", "HNA" );
+            first = 0;
+          } else {
+            snprintf( tmp, sizeof( tmp ), "\"%s\" ->  
\"0.0.0.0/0.0.0.0\"[label=\"HNA\"]\n", from_str );
+          }
  					fillme->buffer = (char *)debugRealloc( fillme->buffer,  
strlen( tmp ) + strlen( fillme->buffer ) + 1, 410 );
  					strncat( fillme->buffer, tmp, strlen( tmp ) );

@@ -541,7 +567,7 @@ void *tcp_server( void *arg ) {

  	struct thread_data *thread_data = ((struct thread_data*) arg);
  	buffer_t *last_send = NULL;
- -	ssize_t ret;
+	size_t ret;


  	while ( !is_aborted() ) {
@@ -552,9 +578,8 @@ void *tcp_server( void *arg ) {
  			current->counter = current->counter == -1 ? 1 : current->counter  
+ 1;
  			pthread_mutex_unlock( &current->mutex );
  			ret = write( thread_data->socket, current->buffer,  
strlen( current->buffer ) );
- -			if( ret != strlen( current->buffer ) )
+      if ( ret != strlen( current->buffer ) || (output_format ==  
json) )
  			{
- -
  				pthread_mutex_lock( &current->mutex );
  				current->counter--;
  				pthread_mutex_unlock( &current->mutex );
@@ -586,8 +611,16 @@ void *tcp_server( void *arg ) {
  void *master() {

  	buffer_t *new, *tmp;
- -	char begin[] = "digraph topology\n{\n";
- -	char end[] = "}\n";
+	char* begin;
+	char* end;
+  if ( output_format == json ) {
+    begin = "HTTP/1.0 200 OK\nContent-type: application/json\n\n[\n";
+    end = "\n]\n";
+  } else {
+    begin = "digraph topology\n{\n";
+    end = "}\n";
+  }
+

  	while ( !is_aborted() ) {

@@ -643,6 +676,7 @@ void print_usage() {

  	printf( "B.A.T.M.A.N. visualisation server %s\n", SOURCE_VERSION );
  	printf( "Usage: vis <interface(s)> \n" );
+  printf( "\t-j output mesh topology as json\n" );
  	printf( "\t-d debug level\n" );
  	printf( "\t-h help\n" );
  	printf( "\t-v Version\n\n" );
@@ -669,7 +703,7 @@ int main( int argc, char **argv ) {
  	pthread_t tcp_server_thread;


- -	while ( ( optchar = getopt ( argc, argv, "d:hv" ) ) != -1 ) {
+	while ( ( optchar = getopt ( argc, argv, "jd:hv" ) ) != -1 ) {

  		switch( optchar ) {

@@ -700,6 +734,11 @@ int main( int argc, char **argv ) {
  				exit(EXIT_SUCCESS);
  				break;

+      case 'j':
+        output_format = json;
+        found_args++;
+        break;
+
  			default:
  				print_usage();
  				exit(EXIT_SUCCESS);
diff --git a/vis.h b/vis.h
index f082700..bae6220 100644
- --- a/vis.h
+++ b/vis.h
@@ -64,7 +64,8 @@ extern struct hashtable_t *secif_hash;

  extern uint8_t debug_level;

- -
+typedef enum { dot, json } formats;
+extern formats output_format;

  struct thread_data {
  	int socket;









-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkoBXS0ACgkQ1/FpN9xKmv4K5ACfVTt0ypJac1hO05nxhHzbJFJI
3d4An19JVsrD8571XfiVU7G5+eQZnv8Y
=BwCW
-----END PGP SIGNATURE-----

Re: [B.A.T.M.A.N.] batman-adv use in Manchester NH

[Antoine van Gelder]

[-- Attachment #1: Type: text/plain, Size: 1483 bytes --]


On 06 May 2009, at 09:18 , Marek Lindner wrote:

> On Wednesday 06 May 2009 13:48:03 Antoine van Gelder wrote:
>>  http://code.google.com/p/afrimesh/
>>
>> The project is very young and still under heavy development but it
>> does have working code using client-side Javascript & the
>> OpenStreetMap libraries to draw mesh maps from the vis server.
>
> Very nice project!
> I think it would be a good idea to add a link and a short project  
> description
> on open-mesh.net to point people to your project. What do you think ?


Tx Marek, yes please!



>>  2) I've patched the layer-3 vis daemon with a command-line
>>     option to output the mesh map in JSON format rather than
>>     dot as I found it a tad more amenable to abuse. (Btw, is
>>     this something anyone else would find useful? I'd be happy
>>     to clean up & contribute the patch!)
>
> Yes, I'm interested.  :-)
> JSON sounds like a good alternative to dot draw. If you bring your  
> patch into
> shape I will commit it. May be you add an option to switch between  
> dot draw
> and JSON ?


-j turns on JSON output and closes the socket after serving the  
browser request.

Speaking of... If I were to run two vis daemons on the mesh would they  
synchronize with each other so that - in theory - one of them could  
serve dot format and the other JSON ?

Patch to follow :)

- antoine



--
http://7degrees.co.za
"Libré software for human education."


[-- Attachment #2: Type: text/html, Size: 3585 bytes --]

[B.A.T.M.A.N.] [PATCH] Add switch for vis daemon to serve mesh topology in JSON format - TAKE 2

[Antoine van Gelder]

[-- Attachment #1: Type: text/plain, Size: 1366 bytes --]


Apologies, I'm not sure why that got mangled, let's try that again.

  - antoine

--

Patch attached for review.

NOTES

* -j turns on JSON mode and closes the socket after serving the  
browser request.

* Data is served in the format

    [ { router : "d.d.d.d", neighbour|gateway : "d.d.d.d", label :  
d.dd|"HNA" }, ... ]

  e.g.

    HTTP/1.0 200 OK
    Content-type: application/json

    [
        { router : "10.0.0.5", neighbour : "10.0.0.3", label : 1.01 },
        { router : "10.0.0.5", neighbour : "10.0.0.6", label : 1.00 },
        { router : "10.0.0.5", neighbour : "10.0.0.1", label : 1.00 },
        { router : "10.0.0.3", neighbour : "10.0.0.5", label : 1.00 },
        { router : "10.0.0.3", neighbour : "10.0.0.1", label : 1.00 },
        { router : "10.0.0.3", neighbour : "10.0.0.6", label : 1.00 },
        { router : "10.0.0.6", neighbour : "10.0.0.5", label : 1.00 },
        { router : "10.0.0.6", neighbour : "10.0.0.3", label : 1.00 },
        { router : "10.0.0.6", neighbour : "10.0.0.1", label : 1.00 },
        { router : "10.0.0.1", neighbour : "10.0.0.3", label : 1.00 },
        { router : "10.0.0.1", neighbour : "10.0.0.5", label : 1.00 },
        { router : "10.0.0.1", neighbour : "10.0.0.6", label : 1.03 },
        { router : "10.0.0.1", gateway : "0.0.0.0/0.0.0.0", label :  
"HNA" }
    ]


Thank you Marek!

- antoine



[-- Attachment #2: vis.diff --]
[-- Type: application/octet-stream, Size: 5411 bytes --]

diff --git a/vis.c b/vis.c
index 4b8a5df..9b6aeaa 100644
--- a/vis.c
+++ b/vis.c
@@ -58,6 +58,8 @@ buffer_t *fillme = NULL;
 static int8_t stop;
 uint8_t debug_level = 0;
 
+formats output_format = dot;
+
 struct hashtable_t *node_hash;
 struct hashtable_t *secif_hash;
 
@@ -328,7 +330,7 @@ void write_data_in_buffer() {
 	struct list_head *list_pos, *list_pos_tmp, *prev_list_head;
 	struct hash_it_t *hashit = NULL;
 	char from_str[16], to_str[16], hna_str[16], tmp[100];
-
+  char first = 1;
 
 	memset( tmp, 0, sizeof(tmp) );
 
@@ -384,7 +386,15 @@ void write_data_in_buffer() {
 
 						}
 
-						snprintf( tmp, sizeof( tmp ), "\"%s\" -> \"%s\"[label=\"%.2f\"]\n", from_str, to_str, (float)( orig_node->tq_max / (float)neigh->tq_avg ) );
+            if ( output_format == json ) {
+              snprintf( tmp, sizeof( tmp ),
+                        "%s\t{ router : \"%s\", neighbour : \"%s\", label : %.2f }",
+                        (first ? "" : ",\n"), from_str, to_str, (float)( orig_node->tq_max / (float)neigh->tq_avg ) );
+              first = 0;
+            } else {
+              snprintf( tmp, sizeof( tmp ), "\"%s\" -> \"%s\"[label=\"%.2f\"]\n", from_str, to_str, (float)( orig_node->tq_max / (float)neigh->tq_avg ) );
+            }
+
 						fillme->buffer = (char *)debugRealloc( fillme->buffer, strlen( tmp ) + strlen( fillme->buffer ) + 1, 408 );
 
 						strncat( fillme->buffer, tmp, strlen( tmp ) );
@@ -400,7 +410,16 @@ void write_data_in_buffer() {
 					addr_to_string( hna->addr, to_str, sizeof( to_str ) );
 					addr_to_string( ( hna->netmask == 32 ? 0xffffffff : htonl( ~ ( 0xffffffff >> hna->netmask ) ) ), hna_str, sizeof( hna_str ) );
 
-					snprintf( tmp, sizeof( tmp ), "\"%s\" -> \"%s/%s\"[label=\"HNA\"]\n", from_str, to_str, hna_str );
+          if ( output_format == json ) {
+            snprintf( tmp, sizeof( tmp ),
+                      "%s\t{ router : \"%s\", gateway : \"%s/%s\", label : \"HNA\" }",
+                      (first ? "" : ",\n"), from_str, to_str, hna_str );
+            first = 0;
+          } else {
+            snprintf( tmp, sizeof( tmp ), "\"%s\" -> \"%s/%s\"[label=\"HNA\"]\n", from_str, to_str, hna_str );
+          }
+
+
 					fillme->buffer = (char *)debugRealloc( fillme->buffer, strlen( tmp ) + strlen( fillme->buffer ) + 1, 409 );
 
 					strncat( fillme->buffer, tmp, strlen( tmp ) );
@@ -410,7 +429,14 @@ void write_data_in_buffer() {
 				/*printf("gw_class %d\n",(unsigned int)orig_node->gw_class);*/
 				if ( orig_node->gw_class != 0 ) {
 
-					snprintf( tmp, sizeof( tmp ), "\"%s\" -> \"0.0.0.0/0.0.0.0\"[label=\"HNA\"]\n", from_str );
+          if ( output_format == json ) {
+            snprintf( tmp, sizeof( tmp ),
+                      "%s\t{ router : \"%s\", gateway : \"%s\", label : \"%s\" }",
+                      (first ? "" : ",\n"), from_str, "0.0.0.0/0.0.0.0", "HNA" );
+            first = 0;
+          } else {
+            snprintf( tmp, sizeof( tmp ), "\"%s\" -> \"0.0.0.0/0.0.0.0\"[label=\"HNA\"]\n", from_str );
+          }
 					fillme->buffer = (char *)debugRealloc( fillme->buffer, strlen( tmp ) + strlen( fillme->buffer ) + 1, 410 );
 					strncat( fillme->buffer, tmp, strlen( tmp ) );
 
@@ -541,7 +567,7 @@ void *tcp_server( void *arg ) {
 
 	struct thread_data *thread_data = ((struct thread_data*) arg);
 	buffer_t *last_send = NULL;
-	ssize_t ret;
+	size_t ret;
 
 
 	while ( !is_aborted() ) {
@@ -552,9 +578,8 @@ void *tcp_server( void *arg ) {
 			current->counter = current->counter == -1 ? 1 : current->counter + 1;
 			pthread_mutex_unlock( &current->mutex );
 			ret = write( thread_data->socket, current->buffer, strlen( current->buffer ) );
-			if( ret != strlen( current->buffer ) )
+      if ( ret != strlen( current->buffer ) || (output_format == json) ) 
 			{
-
 				pthread_mutex_lock( &current->mutex );
 				current->counter--;
 				pthread_mutex_unlock( &current->mutex );
@@ -586,8 +611,16 @@ void *tcp_server( void *arg ) {
 void *master() {
 
 	buffer_t *new, *tmp;
-	char begin[] = "digraph topology\n{\n";
-	char end[] = "}\n";
+	char* begin;
+	char* end;
+  if ( output_format == json ) {
+    begin = "HTTP/1.0 200 OK\nContent-type: application/json\n\n[\n";
+    end = "\n]\n";
+  } else {
+    begin = "digraph topology\n{\n";
+    end = "}\n";
+  }
+
 
 	while ( !is_aborted() ) {
 
@@ -643,6 +676,7 @@ void print_usage() {
 
 	printf( "B.A.T.M.A.N. visualisation server %s\n", SOURCE_VERSION );
 	printf( "Usage: vis <interface(s)> \n" );
+  printf( "\t-j output mesh topology as json\n" );
 	printf( "\t-d debug level\n" );
 	printf( "\t-h help\n" );
 	printf( "\t-v Version\n\n" );
@@ -669,7 +703,7 @@ int main( int argc, char **argv ) {
 	pthread_t tcp_server_thread;
 
 
-	while ( ( optchar = getopt ( argc, argv, "d:hv" ) ) != -1 ) {
+	while ( ( optchar = getopt ( argc, argv, "jd:hv" ) ) != -1 ) {
 
 		switch( optchar ) {
 
@@ -700,6 +734,11 @@ int main( int argc, char **argv ) {
 				exit(EXIT_SUCCESS);
 				break;
 
+      case 'j':
+        output_format = json;
+        found_args++;
+        break;
+
 			default:
 				print_usage();
 				exit(EXIT_SUCCESS);
diff --git a/vis.h b/vis.h
index f082700..bae6220 100644
--- a/vis.h
+++ b/vis.h
@@ -64,7 +64,8 @@ extern struct hashtable_t *secif_hash;
 
 extern uint8_t debug_level;
 
-
+typedef enum { dot, json } formats;
+extern formats output_format;
 
 struct thread_data {
 	int socket;

Re: [B.A.T.M.A.N.] batman-adv use in Manchester NH

[Dennis Bartsch]

[-- Attachment #1: Type: text/plain, Size: 511 bytes --]


Hello,

> From: arcriley@gmail.com
> [...]  Would a FPGA variant be needed to have a "mesh switch" or would 
> a high-end multicore ARM be reasonably able to handle say an 8-port gigabit mesh switch?
> [...]

What for does one want an 8-port gigabit mesh-switch? 
meshing with batman-adv is a totally decentral thing.

cheers
dennis bartsch

_________________________________________________________________
http://redirect.gimas.net/?n=M0905xFTP_SpringCampaign2
--> Für Fotos hier abdrücken <-

[-- Attachment #2: Type: text/html, Size: 777 bytes --]

Re: [B.A.T.M.A.N.] batman-adv use in Manchester NH

[Charles Wyble]

Some folks want to deploy a centralized architecture. :)

There are many many uses for technology. That's the beauty of it.

I'm guessing that the goal of the deployment is for an ISP type 
architecture.

Dennis Bartsch wrote:
> Hello,
> 
>  > From: arcriley@gmail.com
>  > [...]  Would a FPGA variant be needed to have a "mesh switch" or would
>  > a high-end multicore ARM be reasonably able to handle say an 8-port 
> gigabit mesh switch?
>  > [...]
> 
> What for does one want an 8-port gigabit mesh-switch?
> meshing with batman-adv is a totally decentral thing.
> 
> cheers
> dennis bartsch
> 
> ------------------------------------------------------------------------
> Die virtuelle Festplatte im Netz - 25 GB für deine Bilder, Musikfiles 
> und Dateien! Jetzt kostenlos sichern! 
> <http://redirect.gimas.net/?n=M0905WLPhotos>
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> B.A.T.M.A.N mailing list
> B.A.T.M.A.N@open-mesh.net
> https://lists.open-mesh.net/mm/listinfo/b.a.t.m.a.n

Re: [B.A.T.M.A.N.] batman-adv use in Manchester NH

[Carcellelist]

Hi Arc,

> What kind of traffic throughput is the kernel module capable of?  Does the
> module multithread properly for multicore utilization?  Would a FPGA
> variant be needed to have a "mesh switch" or would a high-end multicore ARM
> be reasonably able to handle say an 8-port gigabit mesh switch?

Concerning the multithreading of the batman daemon, if batman supports multi-
threads, you can distribute this on different cores definitely:

Concerning FPGA and the batman daemon (both userspace and kernelspace), it 
will depend on the FPGA you want to use (FPGAs from the two major vendors, 
Xilinx and Altera, are divided into two families based on the number of 
logical gates they have - huge Xilinx VIRTEX5 and coming 6 are even embarking 
one or event 2 PowerPCs next to the FPGA gates). Large FPGAs could embark part 
of the daemon in the CPU hardwired in the chip and the rest (for instance 
intensive functions like packet routing and filtering). Small FPGAs would run 
the daemon in the softcore (OpenRISC, Microblaze, aEMB) either "userspace" or 
"kernelspace" in the softcore or directly with the daemon in low level langage 
(VHDL or VERILOG) after porting the C code into this HDL langages. Core-
networking routers from CISCO, JUNIPER are loaded with FPGAs to process the 
packet filtering and routing the closest from the physical layer.

Concerning ARM and 8-port gigabit mesh switch, the power of even a coming 
multicore ARM13 would not be sufficient to run the packet routing and 
filtering for the 8xGigabits ports. ARM had been primarly developed for 
embedded devices and not for powerful applications such as switching and 
routing.

Xavier.

Re: [B.A.T.M.A.N.] batman-adv use in Manchester NH

[Charles Wyble]

Arc Riley wrote:
> We're setting up batman-adv on open-mesh.com <http://open-mesh.com> OM1P 
> routers and unidirectional antennas to connect homes and businesses 
> across the city.

Excellent! Is there a website for your project?

I am the founder and CTO of the socalwifi.net project. We are currently 
evaluating Batman and OLSRd for a major roll out across the southland.

Are you fully committed to Batman or still in the evaluation phases?

> 
> I've read the protocol docs, but a few key questions about the current 
> kernel implementation;
> 
> 
> Is there a layer 3 solution for routing each end user to the nearest IP 
> gateway that works well on top of a batman-adv network?

OSPF perhaps? :)

> Thanks!
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> B.A.T.M.A.N mailing list
> B.A.T.M.A.N@open-mesh.net
> https://lists.open-mesh.net/mm/listinfo/b.a.t.m.a.n

Re: [B.A.T.M.A.N.] batman-adv use in Manchester NH

[Arc Riley]

[-- Attachment #1: Type: text/plain, Size: 1449 bytes --]

> Excellent! Is there a website for your project?


Not yet, in the next two weeks.


Are you fully committed to Batman or still in the evaluation phases?


There's room to be swayed, but batman-adv seems to be the best suited for
our needs right now.  The primary concern is that the layer 2 branch isn't
old enough to guarentee that it'll last - but it's free software so if it
fizzles and is useful, someone will pick it up.


OSPF perhaps? :)


As I understand it, OSPF is designed for layer 3 networks.  There is no
layer 3 routing going on within this network, to layer 3 protocols the
entire mesh appears to be locally accessable.

We really need something that directs users to use the gateway with the
highest TQ.

One method I just thought of; each gateway runs a DHCP server.  When a
broadcast request is received, each gateway announces to the others their TQ
to the requesting node, and after a brief timeout, the gateway with the
highest TQ responds to the requesting node.

This raises a question however.  After reading the protocol document, I do
not understand how the nodes on a network know which node to route frames
which are destined for a MAC not belonging to a node, ie, a standard laptop
connected to the mesh.  The above scenario would require knowing which node
a non-node MAC is connected through.


As a completely unrelated question, how does the batman-adv 0.1 kernel
module currently handle multicast frame routing?

[-- Attachment #2: Type: text/html, Size: 2016 bytes --]

Re: [B.A.T.M.A.N.] batman-adv use in Manchester NH

[Simon Wunderlich]

[-- Attachment #1: Type: text/plain, Size: 2443 bytes --]

Hey Arc,

On Tue, May 05, 2009 at 02:53:56PM -0400, Arc Riley wrote:
> > Excellent! Is there a website for your project?
> 
> 
> Not yet, in the next two weeks.
> 
> 
> Are you fully committed to Batman or still in the evaluation phases?
> 
> 
> There's room to be swayed, but batman-adv seems to be the best suited for
> our needs right now.  The primary concern is that the layer 2 branch isn't
> old enough to guarentee that it'll last - but it's free software so if it
> fizzles and is useful, someone will pick it up.
> 
> 
> OSPF perhaps? :)
> 
> 
> As I understand it, OSPF is designed for layer 3 networks.  There is no
> layer 3 routing going on within this network, to layer 3 protocols the
> entire mesh appears to be locally accessable.
> 
> We really need something that directs users to use the gateway with the
> highest TQ.
> 
> One method I just thought of; each gateway runs a DHCP server.  When a
> broadcast request is received, each gateway announces to the others their TQ
> to the requesting node, and after a brief timeout, the gateway with the
> highest TQ responds to the requesting node.
> 
> This raises a question however.  After reading the protocol document, I do
> not understand how the nodes on a network know which node to route frames
> which are destined for a MAC not belonging to a node, ie, a standard laptop
> connected to the mesh.  The above scenario would require knowing which node
> a non-node MAC is connected through.


Each node collects the local MAC-addresses by reading the source-MAC from 
the Payload Ethernet Frames. These collected MAC addresses are then announced
over the mesh by attaching the list to the BATMAN packets (we call this HNA). 

For example, a standard laptop would send frames to its AP A. A will have
a linux-bridge over the wifi interface and the mesh interface. The mesh interface
reads the laptop MAC and knows that its local. This laptop MAC will then be
announced with the BATMAN packets. Another mesh node B will receive the 
BATMAN packet and knows that frames for the laptop are to be passed to A.

Hope this explanation was clear enough, if not please ask. :)
> 
> 
> As a completely unrelated question, how does the batman-adv 0.1 kernel
> module currently handle multicast frame routing?

We have no special care for multicast currently, we just detect it and 
broadcast it.

best regards,
	Simon

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [B.A.T.M.A.N.] batman-adv use in Manchester NH

[Marek Lindner]

On Wednesday 06 May 2009 02:29:01 Charles Wyble wrote:
> I am the founder and CTO of the socalwifi.net project. We are currently
> evaluating Batman and OLSRd for a major roll out across the southland.

That sounds interesting. Please let us know about the outcome and the 
reasoning no matter what your decision might be. We are very much into all 
kind of feedback (positive & negative) to further improve the project.

Regards,
Marek