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!
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
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.comwrote:
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.
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
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."
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 ?
- 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
-----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( ¤t->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( ¤t->mutex ); current->counter--; pthread_mutex_unlock( ¤t->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;
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!
- 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."
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
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 <-
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
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.
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
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?
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
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
b.a.t.m.a.n@lists.open-mesh.org
-
Antoine van Gelder -
Arc Riley -
Carcellelist -
Charles Wyble -
Dennis Bartsch -
Marek Lindner -
Simon Wunderlich