commits July 2017

commits@lists.open-mesh.org

1 participants
1317 discussions

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Gateways: change path to manpage (f3ac645e)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

Repository : ssh://git@open-mesh.org/doc On branches: backup-redmine/2017-07-13,master >--------------------------------------------------------------- commit f3ac645e646c3005b2fc4c16af9202d815b3a324 Author: Sven Eckelmann <sven(a)narfation.org> Date: Tue Mar 22 12:09:31 2011 +0000 doc: batman-adv/Gateways: change path to manpage >--------------------------------------------------------------- f3ac645e646c3005b2fc4c16af9202d815b3a324 batman-adv/Gateways.textile | 50 ++++++++++++++++++++++++++------------------- 1 file changed, 29 insertions(+), 21 deletions(-) diff --git a/batman-adv/Gateways.textile b/batman-adv/Gateways.textile index 8c362e6b..0afa648c 100644 --- a/batman-adv/Gateways.textile +++ b/batman-adv/Gateways.textile @@ -1,16 +1,22 @@ -= Batman-adv gateways = -{{{ -#!div style="width: 46em; text-align: justify" +h1. Batman-adv gateways + + +<pre> +<code class="div"> Often batman-adv is used to cover a bigger area with wireless access to the internet where several nodes have internet access while the other nodes try to find the best route towards one of the gateways. In this case it is desirable that the routing protocol helps with the decision to find the best path since it already knows the topology of the network. -=== The default route === + +h3. The default route + The subject of manipulating the IP (layer 3) default route with a layer 2 routing protocol has stirred up controversy between those who believe in a clean network layer separation and those who need this functionality. The former claim that a well-designed protocol should not mess with other layers but instead collaborate with tools made for higher layers. The latter group has pointed out that the rule of network layer separation can be bent in real world applications and to improve usability. To achieve a compromise the gateway mechanism is disabled per default and only operates on top of DHCP (details below). Feel free to contact us in case you want to propose alternative ideas. -=== The concept === + +h3. The concept + As the whole gateway functionality is based on DHCP, the protocol assumes each gateway runs its own DHCP server and each client runs a DHCP client. When a DHCP client is started it will issue a DHCP request which is broadcasted in the entire network. Every DHCP server will send a reply via unicast back to the client which then has to choose one of the responding DHCP servers as its gateway. @@ -25,44 +31,46 @@ Once the gateway feature has been activated batman-adv floods the networks with The DHCP client will then select the gateway batman-adv prefers as only this gateway replied to the request. -=== The configuration === -'''gateway server''' +h3. The configuration + + +*gateway server* Activate the gateway announcements on a node that has a DHCP server running: -{{{ +<pre> batctl gw_mode server -}}} +</code></pre> Batman-adv always announces the gateway's internet bandwidth, so that clients can base their decision on the link quality towards the gateway as well as on the available bandwidth. Per default a bandwidth of 2048KBit/512KBit is assumed. To configure a download bandwidth of 5Mbit with an upload of 1Mbit run the following command: -{{{ +<pre> batctl gw_mode server 5mbit/1mbit -}}} +</code></pre> -Details regarding the syntax of the bandwidth setting can be found in the [http://downloads.open-mesh.org/batman/development/sources/batctl_devel-curr… batctl manpage]. +Details regarding the syntax of the bandwidth setting can be found in the "batctl manpage":http://downloads.open-mesh.org/batman/manpages/batctl.8.html. -'''gateway client''' +*gateway client* The client can be activated with the following command: -{{{ +<pre> batctl gw_mode client -}}} +</code></pre> If multiple gateways are available batman-adv selects its best gateway based on certain criteria such as link quality / bandwidth / etc. The selection algorithm can be changed by appending the appropriate gateway selection class to the aforementioned command. To let batman-adv switch the gateway as soon as any gateway becomes 20TQ points better than the currently selected gateway: -{{{ +<pre> batctl gw_mode client 20 -}}} +</code></pre> -All available gateway selection classes are thoroughly explained in the [http://downloads.open-mesh.org/batman/development/sources/batctl_devel-curr… batctl manpage]. +All available gateway selection classes are thoroughly explained in the "batctl manpage":http://downloads.open-mesh.org/batman/manpages/batctl.8.html. To see all available gateways and their announced throughput run: -{{{ +<pre> batctl gwl -}}} +</code></pre> -}}} \ No newline at end of file +</code></pre> \ No newline at end of file

1 0

[doc] backup-redmine/2017-07-13, master: doc: open-mesh/FFTrace (5b70c51f)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

Repository : ssh://git@open-mesh.org/doc On branches: backup-redmine/2017-07-13,master >--------------------------------------------------------------- commit 5b70c51fa1eada2c8ecb573689ab0c65b71067ad Author: Sven Eckelmann <sven(a)narfation.org> Date: Sun Mar 20 23:45:42 2011 +0000 doc: open-mesh/FFTrace >--------------------------------------------------------------- 5b70c51fa1eada2c8ecb573689ab0c65b71067ad open-mesh/FFTrace.textile | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/open-mesh/FFTrace.textile b/open-mesh/FFTrace.textile index e53c0002..dddc2dae 100644 --- a/open-mesh/FFTrace.textile +++ b/open-mesh/FFTrace.textile @@ -1,6 +1,8 @@ -= FFTrace freifunk-traceroute = -'''"fftrace"''' is a console-based olsr-route-link-quality monitor +h1. FFTrace freifunk-traceroute + + +*"fftrace"* is a console-based olsr-route-link-quality monitor Problem description: in OLSR mesh networks routing is very dynamic. Fine tools as traceroute give only a one-time impression, and mtr does not cope with routechanges as often as they happen. Both aim to measure and show the round trip times of packets as quality indicator. @@ -8,7 +10,7 @@ A wireless network consists of many diffrent-quality HF-connections, some with s The link-quality implementation of olsrd introduced a value do describe the quality of these connections. A tool to monitor the current route and the link-quality of its connections was missing. -'''"fftrace"''' aims to fill this gap. It lists the single nodes of a route and displays the quality of the connections in between. +*"fftrace"* aims to fill this gap. It lists the single nodes of a route and displays the quality of the connections in between. Finally it shows the needed effort to get a packet through the whole route. The program uses ttl-manipulatet icmp-echo-requests to find the intermediate nodes and reads the udp-messages used and generated by the olsr-deamons to gather present information about the link-quality and neighbor-link-quality of node-node-pairs in the watched route. Due to this structure there is no instant information on a new node-node-pair. Until the information is available it is left blank and unregarded by the whole-route-etx. @@ -17,4 +19,4 @@ an olsr-plugin or the screen-output in something that can be diplayed graphical - * Download: http://downloads.open-mesh.org/fftrace/ \ No newline at end of file +* Download: http://downloads.open-mesh.org/fftrace/ \ No newline at end of file

1 0

[doc] backup-redmine/2017-07-13, master: doc: open-mesh/FFTrace (7a672d7f)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

Repository : ssh://git@open-mesh.org/doc On branches: backup-redmine/2017-07-13,master >--------------------------------------------------------------- commit 7a672d7f4f45d7c49b3c6abeaf33f3b11a15773a Author: Sven Eckelmann <sven(a)narfation.org> Date: Sun Mar 20 23:45:42 2011 +0000 doc: open-mesh/FFTrace >--------------------------------------------------------------- 7a672d7f4f45d7c49b3c6abeaf33f3b11a15773a open-mesh/FFTrace.textile | 1 - 1 file changed, 1 deletion(-) diff --git a/open-mesh/FFTrace.textile b/open-mesh/FFTrace.textile index 169d4328..e53c0002 100644 --- a/open-mesh/FFTrace.textile +++ b/open-mesh/FFTrace.textile @@ -18,4 +18,3 @@ an olsr-plugin or the screen-output in something that can be diplayed graphical * Download: http://downloads.open-mesh.org/fftrace/ \ No newline at end of file - * Trac: https://dev.open-mesh.org/fftrace/ \ No newline at end of file

1 0

[doc] backup-redmine/2017-07-13, master: doc: attachments/vde2-2.3.1_colour.patch (5417ff74)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

Repository : ssh://git@open-mesh.org/doc On branches: backup-redmine/2017-07-13,master >--------------------------------------------------------------- commit 5417ff74495af020f4f543a3f4c8847013ccf4de Author: Simon Wunderlich <sw(a)simonwunderlich.de> Date: Thu Mar 17 15:17:36 2011 +0000 doc: attachments/vde2-2.3.1_colour.patch >--------------------------------------------------------------- 5417ff74495af020f4f543a3f4c8847013ccf4de ...-2.2.3_colour.patch => vde2-2.3.1_colour.patch} | 80 +++++++++++----------- 1 file changed, 41 insertions(+), 39 deletions(-) diff --git a/attachments/vde2-2.2.3_colour.patch b/attachments/vde2-2.3.1_colour.patch similarity index 63% copy from attachments/vde2-2.2.3_colour.patch copy to attachments/vde2-2.3.1_colour.patch index 49e2c466..9aee63e0 100644 --- a/attachments/vde2-2.2.3_colour.patch +++ b/attachments/vde2-2.3.1_colour.patch @@ -1,16 +1,15 @@ -diff --git a/src/vde_switch/port.c b/src/vde_switch/port.c -index 00a60e6..5135db0 100644 ---- a/src/vde_switch/port.c -+++ b/src/vde_switch/port.c +diff -urp vde2-2.3.1-orig/src/vde_switch/port.c vde2-2.3.1/src/vde_switch/port.c +--- vde2-2.3.1-orig/src/vde_switch/port.c 2010-07-25 19:48:01.000000000 +0200 ++++ vde2-2.3.1/src/vde_switch/port.c 2011-03-17 11:54:46.000000000 +0100 @@ -91,6 +91,7 @@ struct port { int fd_data; struct endpoint *ep; int flag; -+ int colour; ++ int colour; /* sender is already inside ms, but it needs one more memaccess */ int (*sender)(int fd, int fd_ctl, void *packet, int len, void *data, int port); struct mod_support *ms; -@@ -148,6 +149,7 @@ static int alloc_port(unsigned int portno) +@@ -148,6 +149,7 @@ static int alloc_port(unsigned int portn EVENTOUT(DBGPORTNEW,i); portv[i]=port; @@ -18,7 +17,7 @@ index 00a60e6..5135db0 100644 port->fd_data=-1; port->ep=NULL; port->user=port->group=port->curuser=-1; -@@ -552,7 +554,7 @@ void handle_in_packet(int port, struct packet *packet, int len) +@@ -552,7 +554,7 @@ void handle_in_packet(int port, struct if (pflag & HUB_TAG) { /* this is a HUB */ register int i; for(i = 1; i < numports; i++) @@ -27,7 +26,7 @@ index 00a60e6..5135db0 100644 SEND_PACKET_PORT(portv[i],i,packet,len); } else { /* This is a switch, not a HUB! */ if (packet->header.proto[0] == 0x81 && packet->header.proto[1] == 0x00) { -@@ -595,17 +597,17 @@ void handle_in_packet(int port, struct packet *packet, int len) +@@ -595,17 +597,17 @@ void handle_in_packet(int port, struct if (tagged) { register int i; ba_FORALL(vlant[vlan].bctag,numports, @@ -49,37 +48,37 @@ index 00a60e6..5135db0 100644 } } else { -@@ -614,15 +616,21 @@ void handle_in_packet(int port, struct packet *packet, int len) - if (tarport==port) +@@ -615,17 +617,23 @@ void handle_in_packet(int port, struct return; /*do not loop!*/ if (tagged) { -- if (portv[tarport]->vlanuntag==vlan) /* TAG->UNTAG */ -- SEND_PACKET_PORT(portv[tarport],tarport,TAG2UNTAG(packet,len),len); -- else /* TAG->TAG */ + if (portv[tarport]->vlanuntag==vlan) { /* TAG->UNTAG */ +- packet = TAG2UNTAG(packet,len); - SEND_PACKET_PORT(portv[tarport],tarport,packet,len); -+ if (portv[tarport]->vlanuntag==vlan) { /* TAG->UNTAG */ -+ if (!(pflag & COLOURFUL_TAG) || portv[tarport]->colour != portv[port]->colour) -+ SEND_PACKET_PORT(portv[tarport],tarport,TAG2UNTAG(packet,len),len); -+ } else { /* TAG->TAG */ -+ if (!(pflag & COLOURFUL_TAG) || portv[tarport]->colour != portv[port]->colour) ++ if (!(pflag & COLOURFUL_TAG) || portv[tarport]->colour != portv[port]->colour) { ++ packet = TAG2UNTAG(packet,len); + SEND_PACKET_PORT(portv[tarport],tarport,packet,len); -+ } ++ } + } else { /* TAG->TAG */ +- SEND_PACKET_PORT(portv[tarport],tarport,packet,len); ++ if (!(pflag & COLOURFUL_TAG) || portv[tarport]->colour != portv[port]->colour) ++ SEND_PACKET_PORT(portv[tarport],tarport,packet,len); + } } else { -- if (portv[tarport]->vlanuntag==vlan) /* UNTAG->UNTAG */ + if (portv[tarport]->vlanuntag==vlan) { /* UNTAG->UNTAG */ - SEND_PACKET_PORT(portv[tarport],tarport,packet,len); -- else /* UNTAG->TAG */ -- SEND_PACKET_PORT(portv[tarport],tarport,UNTAG2TAG(packet,vlan,len),len); -+ if (portv[tarport]->vlanuntag==vlan) { /* UNTAG->UNTAG */ -+ if (!(pflag & COLOURFUL_TAG) || portv[tarport]->colour != portv[port]->colour) ++ if (!(pflag & COLOURFUL_TAG) || portv[tarport]->colour != portv[port]->colour) + SEND_PACKET_PORT(portv[tarport],tarport,packet,len); -+ } else { /* UNTAG->TAG */ -+ if (!(pflag & COLOURFUL_TAG) || portv[tarport]->colour != portv[port]->colour) -+ SEND_PACKET_PORT(portv[tarport],tarport,UNTAG2TAG(packet,vlan,len),len); -+ } + } else { /* UNTAG->TAG */ +- packet = UNTAG2TAG(packet,vlan,len); +- SEND_PACKET_PORT(portv[tarport],tarport,packet,len); ++ if (!(pflag & COLOURFUL_TAG) || portv[tarport]->colour != portv[port]->colour) { ++ packet = UNTAG2TAG(packet,vlan,len); ++ SEND_PACKET_PORT(portv[tarport],tarport,packet,len); ++ } + } } } /* if(BROADCAST) */ - } /* if(HUB) */ -@@ -635,6 +643,7 @@ static int showinfo(FILE *fd) +@@ -639,6 +647,7 @@ static int showinfo(FILE *fd) { printoutc(fd,"Numports=%d",numports); printoutc(fd,"HUB=%s",(pflag & HUB_TAG)?"true":"false"); @@ -87,7 +86,7 @@ index 00a60e6..5135db0 100644 #ifdef PORTCOUNTERS printoutc(fd,"counters=true"); #else -@@ -796,6 +805,18 @@ static int epclose(char *arg) +@@ -814,6 +823,19 @@ static int epclose(char *arg) return close_ep(port,id); } @@ -103,10 +102,11 @@ index 00a60e6..5135db0 100644 + portv[port]->colour= colour; + return 0; +} ++ static char *port_getuser(uid_t uid) { static char buf[6]; -@@ -846,6 +867,7 @@ static int print_port(FILE *fd,int i,int inclinactive) +@@ -864,6 +886,7 @@ static int print_port(FILE *fd,int i,int printoutc(fd," IN: pkts %10lld bytes %20lld",portv[i]->pktsin,portv[i]->bytesin); printoutc(fd," OUT: pkts %10lld bytes %20lld",portv[i]->pktsout,portv[i]->bytesout); #endif @@ -114,7 +114,7 @@ index 00a60e6..5135db0 100644 for (ep=portv[i]->ep; ep != NULL; ep=ep->next) printoutc(fd," -- endpoint ID %04d module %-12s: %s",ep->fd_ctl, portv[i]->ms->modname,(ep->descr)?ep->descr:"no endpoint description"); -@@ -930,6 +952,15 @@ static int portsethub(int val) +@@ -948,6 +971,15 @@ static int portsethub(int val) return 0; } @@ -130,14 +130,15 @@ index 00a60e6..5135db0 100644 static int portsetvlan(char *arg) { int port,vlan; -@@ -1184,12 +1215,14 @@ static struct comlist cl[]={ +@@ -1202,6 +1234,7 @@ static struct comlist cl[]={ {"port/setnumports","N","set the number of ports",portsetnumports,INTARG}, /*{"port/setmacaddr","MAC","set the switch MAC address",setmacaddr,STRARG},*/ {"port/sethub","0/1","1=HUB 0=switch",portsethub,INTARG}, + {"port/setcolourful","0/1","1=colourful 0=no colour",portsetcolourful,INTARG}, {"port/setvlan","N VLAN","set port VLAN (untagged)",portsetvlan,STRARG}, + {"port/createauto","","create a port with an automatically allocated id (inactive|notallocatable)",portcreateauto,NOARG|WITHFILE}, {"port/create","N","create the port N (inactive|notallocatable)",portcreate,INTARG}, - {"port/remove","N","remove the port N",portremove,INTARG}, +@@ -1209,6 +1242,7 @@ static struct comlist cl[]={ {"port/allocatable","N 0/1","Is the port allocatable as unnamed? 1=Y 0=N",portallocatable,STRARG}, {"port/setuser","N user","access control: set user",portsetuser,STRARG}, {"port/setgroup","N user","access control: set group",portsetgroup,STRARG}, @@ -145,10 +146,9 @@ index 00a60e6..5135db0 100644 {"port/epclose","N ID","remove the endpoint port N/id ID",epclose,STRARG}, #ifdef PORTCOUNTERS {"port/resetcounter","[N]","reset the port (N) counters",portresetcounters,STRARG}, -diff --git a/src/vde_switch/port.h b/src/vde_switch/port.h -index a65ad1d..57eeae1 100644 ---- a/src/vde_switch/port.h -+++ b/src/vde_switch/port.h +diff -urp vde2-2.3.1-orig/src/vde_switch/port.h vde2-2.3.1/src/vde_switch/port.h +--- vde2-2.3.1-orig/src/vde_switch/port.h 2010-07-25 19:48:01.000000000 +0200 ++++ vde2-2.3.1/src/vde_switch/port.h 2011-03-17 11:54:46.000000000 +0100 @@ -62,6 +62,7 @@ int portflag(int op, int f); #define P_CLRFLAG 3 @@ -157,3 +157,5 @@ index a65ad1d..57eeae1 100644 void port_init(int numports); +Only in vde2-2.3.1/src/vde_switch: port.h.orig +Only in vde2-2.3.1/src/vde_switch: port.o

1 0

[doc] backup-redmine/2017-07-13, master: doc: open-mesh/Download: Remove information regarding bmx (32593d33)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

Repository : ssh://git@open-mesh.org/doc On branches: backup-redmine/2017-07-13,master >--------------------------------------------------------------- commit 32593d330fc3d69bd73dea4083cb0a7d5929ef3a Author: Sven Eckelmann <sven(a)narfation.org> Date: Thu Mar 17 22:42:50 2011 +0000 doc: open-mesh/Download: Remove information regarding bmx >--------------------------------------------------------------- 32593d330fc3d69bd73dea4083cb0a7d5929ef3a open-mesh/Download.textile | 3 --- 1 file changed, 3 deletions(-) diff --git a/open-mesh/Download.textile b/open-mesh/Download.textile index 47f8f177..ee9a4f64 100644 --- a/open-mesh/Download.textile +++ b/open-mesh/Download.textile @@ -22,9 +22,6 @@ You can check out our SVN repository and the various batman branches * complete repository: [[BR]]''{{{svn co http://downloads.open-mesh.org/svn/batman/trunk/}}}'' * upcoming B.A.T.M.A.N. 0.4.0 branch '''(maintainer needed!)''': [[BR]]''{{{svn co http://downloads.open-mesh.org/svn/batman/trunk/batman/}}}'' * Visualization server for B.A.T.M.A.N.: check out the complete repository, cd into vis (we're using symlinks here ...): [[BR]]''{{{svn co http://downloads.open-mesh.org/svn/batman/trunk/}}}'' - * BMX-0.3.x branch: [[BR]]''{{{svn co http://downloads.open-mesh.org/svn/batman/branches/bmx-0.3.x/}}}'' and http://git.bmx6.net/?p=bmxd.git;a=summary - * upcoming BMX6-0.1 branch (unstable): [[BR]]''{{{svn co http://downloads.open-mesh.org/svn/batman/trunk/bmx/}}}'' also check new website at http://www.bmx6.net - === Git Repository Access === Since we started integrating the batman-adv kernel module into the mainline Linux tree, we also maintain a git repository which contains the batman-adv maintenance branches. More information can be found [wiki:UsingBatmanGit on our git page].

1 0

[doc] backup-redmine/2017-07-13, master: doc: open-mesh/Contribute: Remove information regarding bmx (9593d303)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

Repository : ssh://git@open-mesh.org/doc On branches: backup-redmine/2017-07-13,master >--------------------------------------------------------------- commit 9593d3037dcf7f23c8dd199f58427427ed4d93df Author: Sven Eckelmann <sven(a)narfation.org> Date: Thu Mar 17 22:43:40 2011 +0000 doc: open-mesh/Contribute: Remove information regarding bmx >--------------------------------------------------------------- 9593d3037dcf7f23c8dd199f58427427ed4d93df open-mesh/Contribute.textile | 91 +++++++++++++++++++------------------------- 1 file changed, 39 insertions(+), 52 deletions(-) diff --git a/open-mesh/Contribute.textile b/open-mesh/Contribute.textile index ca8a0b5e..3f82540e 100644 --- a/open-mesh/Contribute.textile +++ b/open-mesh/Contribute.textile @@ -1,79 +1,66 @@ += How to Contribute = -h1. How to Contribute +{{{ +#!div style="width: 46em; text-align: justify" - -<pre> -<code class="div"> - -Thanks for using B.A.T.M.A.N.! If you have suggestions, comments, want to tell us about your experiences or discuss problems the best thing is always to use the [[MailingList|Mailing List] You can always contact us via [wikiIRC IRC]]. +Thanks for using B.A.T.M.A.N.! If you have suggestions, comments, want to tell us about your experiences or discuss problems the best thing is always to use the [wiki:MailingList Mailing List]. You can always contact us via [wiki:IRC IRC]. If you like this project and you want to take part and/or give something back, here is a short list of starting points: +=== Reporting Bugs === -h3. Reporting Bugs - - -If you find a bug, please see if the problem is already known in the by "Reading the Tickets":https://dev.open-mesh.org/batman/report. - -If not, please "add a new Ticket":https://dev.open-mesh.org/batman/newticket. +If you find a bug, please see if the problem is already known in the by [https://dev.open-mesh.org/batman/report Reading the Tickets]. [[BR]] +If not, please [https://dev.open-mesh.org/batman/newticket add a new Ticket]. Please add as much information as possible. In particular interesting are: -* Which branch (batman, batctl, batman-adv) -* Which version (0.X, SVN/git revision number) -* kernel version, distribution (and version) -* machine type (PC, Linksys WRT, Fon, NS2, ...) -* command line parameters used -* iptables/firewall rules -* [[Coredump|get a coredump]] if you experience a segfault -* your guess what triggered the problem. ;) - - -h3. Documentation / Feedback + * Which branch (batman, batctl, batman-adv) + * Which version (0.X, SVN/git revision number) + * kernel version, distribution (and version) + * machine type (PC, Linksys WRT, Fon, NS2, ...) + * command line parameters used + * iptables/firewall rules + * [wiki:Coredump get a coredump] if you experience a segfault + * your guess what triggered the problem. ;) +=== Documentation / Feedback === Write an article about your experience with B.A.T.M.A.N. and have it published here or ask us to link to your site: -* How did you find us ? -* How does you setup look like ? -* Where are you building your mesh ? -* What problems did you encounter ? -* How did you debug / solve them ? -* What did you like / not like ? -* How can B.A.T.M.A.N. improve ? + * How did you find us ? + * How does you setup look like ? + * Where are you building your mesh ? + * What problems did you encounter ? + * How did you debug / solve them ? + * What did you like / not like ? + * How can B.A.T.M.A.N. improve ? There's lots of people that want to know about B.A.T.M.A.N. - help us to spread the word! You also can create a wiki account and improve the documentation. - -h3. Research - +=== Research === B.A.T.M.A.N. gives much room for research, especially the layer 2 implementation in the kernel. Get in touch with us to share your ideas. If you write papers we are happy to publish them here or link to your page. If you are looking for the right topic or mentorship feel free to contact us. We have more ideas than time to implement them. +=== Development === -h3. Development - - -You looked in the code ? Fixed bugs ? Added a cool new function ? Integrated B.A.T.M.A.N. in a distribution ? Don't hesitate to let us and others know! We can avoid duplicated work by publishing it here or linking to your page. Patches are always welcome and can be posted on the [[MailingList|mailing list]] to get integrated. We also hand out SVN/git access to people that want to get involved. - - -h3. Submitting patches +You looked in the code ? Fixed bugs ? Added a cool new function ? Integrated B.A.T.M.A.N. in a distribution ? Don't hesitate to let us and others know! We can avoid duplicated work by publishing it here or linking to your page. Patches are always welcome and can be posted on the [wiki:MailingList mailing list] to get integrated. We also hand out SVN/git access to people that want to get involved. +=== Submitting patches === If you intend to send us patches, please consider the following guidelines: -* Prefer small & digestible over long "all in one" patches. -* No MIME, no links, no compression, no attachments. Just plain text (patches are to be sent inline). -* Patches sent to the mailing list should include "PATCH" in the subject to make it easier to distinguish between patches and discussions. -* The mail's subject will become the first line in the commit message. The body contains the longer patch description and the patch (unified format) itself. Please also specify the target branch (e.g. batctl, batman-adv, etc) at the beginning of the subject line. See the "timeline":http://www.open-mesh.org/timeline for more examples. -* Add a "Signed-off-by: Your Name <!you(a)example.com>" line to the patch message to make the ownership of the patch clear. -* Patches for B.A.T.M.A.N. Advanced need to follow the linux kernel coding style closely (use checkpatch.pl to verify your patch) as well as the linux "how to submit patches" guidelines (search for the term SubmitPatches to find thorough documentation). -<pre> -* Patches against the batman-adv master branch must be formated using -<pre> + * Prefer small & digestible over long "all in one" patches. + * No MIME, no links, no compression, no attachments. Just plain text (patches are to be sent inline). + * Patches sent to the mailing list should include "PATCH" in the subject to make it easier to distinguish between patches and discussions. + * The mail's subject will become the first line in the commit message. The body contains the longer patch description and the patch (unified format) itself. Please also specify the target branch (e.g. batctl, batman-adv, etc) at the beginning of the subject line. See the [http://www.open-mesh.org/timeline timeline] for more examples. + * Add a "Signed-off-by: Your Name <!you(a)example.com>" line to the patch message to make the ownership of the patch clear. + * Patches for B.A.T.M.A.N. Advanced need to follow the linux kernel coding style closely (use checkpatch.pl to verify your patch) as well as the linux "how to submit patches" guidelines (search for the term !SubmitPatches to find thorough documentation). + * Patches must be against trunk and have an additional prefix before the actual project subdirectory. It must be possible to apply those patches on top of a checkout of the svn trunk directory using {{{patch -p1 -i $PATCH}}} + * Patches against the batman-adv master branch must be formated using +{{{ git format-patch -M --patience --src-prefix=a/batman-adv/ --dst-prefix=b/batman-adv/ $BASECOMMIT -</code></pre> -* An exemplary good submission you may want to look at can be found here: https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2009-December/002033.html +}}} + * An exemplary good submission you may want to look at can be found here: https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2009-December/002033.html -</code></pre> +}}}

1 0

[doc] backup-redmine/2017-07-13, master: doc: open-mesh/Contribute: Remove information regarding bmx (19bc5bd7)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

Repository : ssh://git@open-mesh.org/doc On branches: backup-redmine/2017-07-13,master >--------------------------------------------------------------- commit 19bc5bd73c7401d978e723f372bf68a0449c363b Author: Sven Eckelmann <sven(a)narfation.org> Date: Thu Mar 17 22:43:40 2011 +0000 doc: open-mesh/Contribute: Remove information regarding bmx >--------------------------------------------------------------- 19bc5bd73c7401d978e723f372bf68a0449c363b open-mesh/Contribute.textile | 91 +++++++++++++++++++++++++------------------- 1 file changed, 52 insertions(+), 39 deletions(-) diff --git a/open-mesh/Contribute.textile b/open-mesh/Contribute.textile index 0eb56988..ca8a0b5e 100644 --- a/open-mesh/Contribute.textile +++ b/open-mesh/Contribute.textile @@ -1,66 +1,79 @@ -= How to Contribute = -{{{ -#!div style="width: 46em; text-align: justify" +h1. How to Contribute -Thanks for using B.A.T.M.A.N.! If you have suggestions, comments, want to tell us about your experiences or discuss problems the best thing is always to use the [wiki:MailingList Mailing List]. You can always contact us via [wiki:IRC IRC]. + +<pre> +<code class="div"> + +Thanks for using B.A.T.M.A.N.! If you have suggestions, comments, want to tell us about your experiences or discuss problems the best thing is always to use the [[MailingList|Mailing List] You can always contact us via [wikiIRC IRC]]. If you like this project and you want to take part and/or give something back, here is a short list of starting points: -=== Reporting Bugs === -If you find a bug, please see if the problem is already known in the by [https://dev.open-mesh.org/batman/report Reading the Tickets]. [[BR]] -If not, please [https://dev.open-mesh.org/batman/newticket add a new Ticket]. +h3. Reporting Bugs + + +If you find a bug, please see if the problem is already known in the by "Reading the Tickets":https://dev.open-mesh.org/batman/report. + +If not, please "add a new Ticket":https://dev.open-mesh.org/batman/newticket. Please add as much information as possible. In particular interesting are: - * Which branch (batman, bmx, batman-advanced) - * Which version (0.X, SVN/git revision number) - * kernel version, distribution (and version) - * machine type (PC, Linksys WRT, Fon, NS2, ...) - * command line parameters used - * iptables/firewall rules - * [wiki:Coredump get a coredump] if you experience a segfault - * your guess what triggered the problem. ;) +* Which branch (batman, batctl, batman-adv) +* Which version (0.X, SVN/git revision number) +* kernel version, distribution (and version) +* machine type (PC, Linksys WRT, Fon, NS2, ...) +* command line parameters used +* iptables/firewall rules +* [[Coredump|get a coredump]] if you experience a segfault +* your guess what triggered the problem. ;) + + +h3. Documentation / Feedback -=== Documentation / Feedback === Write an article about your experience with B.A.T.M.A.N. and have it published here or ask us to link to your site: - * How did you find us ? - * How does you setup look like ? - * Where are you building your mesh ? - * What problems did you encounter ? - * How did you debug / solve them ? - * What did you like / not like ? - * How can B.A.T.M.A.N. improve ? +* How did you find us ? +* How does you setup look like ? +* Where are you building your mesh ? +* What problems did you encounter ? +* How did you debug / solve them ? +* What did you like / not like ? +* How can B.A.T.M.A.N. improve ? There's lots of people that want to know about B.A.T.M.A.N. - help us to spread the word! You also can create a wiki account and improve the documentation. -=== Research === + +h3. Research + B.A.T.M.A.N. gives much room for research, especially the layer 2 implementation in the kernel. Get in touch with us to share your ideas. If you write papers we are happy to publish them here or link to your page. If you are looking for the right topic or mentorship feel free to contact us. We have more ideas than time to implement them. -=== Development === -You looked in the code ? Fixed bugs ? Added a cool new function ? Integrated B.A.T.M.A.N. in a distribution ? Don't hesitate to let us and others know! We can avoid duplicated work by publishing it here or linking to your page. Patches are always welcome and can be posted on the [wiki:MailingList mailing list] to get integrated. We also hand out SVN/git access to people that want to get involved. +h3. Development + + +You looked in the code ? Fixed bugs ? Added a cool new function ? Integrated B.A.T.M.A.N. in a distribution ? Don't hesitate to let us and others know! We can avoid duplicated work by publishing it here or linking to your page. Patches are always welcome and can be posted on the [[MailingList|mailing list]] to get integrated. We also hand out SVN/git access to people that want to get involved. + + +h3. Submitting patches -=== Submitting patches === If you intend to send us patches, please consider the following guidelines: - * Prefer small & digestible over long "all in one" patches. - * No MIME, no links, no compression, no attachments. Just plain text (patches are to be sent inline). - * Patches sent to the mailing list should include "PATCH" in the subject to make it easier to distinguish between patches and discussions. - * The mail's subject will become the first line in the commit message. The body contains the longer patch description and the patch (unified format) itself. Please also specify the target branch (e.g. batctl, batman-adv, etc) at the beginning of the subject line. See the [http://www.open-mesh.org/timeline timeline] for more examples. - * Add a "Signed-off-by: Your Name <!you(a)example.com>" line to the patch message to make the ownership of the patch clear. - * Patches for B.A.T.M.A.N. Advanced need to follow the linux kernel coding style closely (use checkpatch.pl to verify your patch) as well as the linux "how to submit patches" guidelines (search for the term !SubmitPatches to find thorough documentation). - * Patches must be against trunk and have an additional prefix before the actual project subdirectory. It must be possible to apply those patches on top of a checkout of the svn trunk directory using {{{patch -p1 -i $PATCH}}} - * Patches against the batman-adv master branch must be formated using -{{{ +* Prefer small & digestible over long "all in one" patches. +* No MIME, no links, no compression, no attachments. Just plain text (patches are to be sent inline). +* Patches sent to the mailing list should include "PATCH" in the subject to make it easier to distinguish between patches and discussions. +* The mail's subject will become the first line in the commit message. The body contains the longer patch description and the patch (unified format) itself. Please also specify the target branch (e.g. batctl, batman-adv, etc) at the beginning of the subject line. See the "timeline":http://www.open-mesh.org/timeline for more examples. +* Add a "Signed-off-by: Your Name <!you(a)example.com>" line to the patch message to make the ownership of the patch clear. +* Patches for B.A.T.M.A.N. Advanced need to follow the linux kernel coding style closely (use checkpatch.pl to verify your patch) as well as the linux "how to submit patches" guidelines (search for the term SubmitPatches to find thorough documentation). +<pre> +* Patches against the batman-adv master branch must be formated using +<pre> git format-patch -M --patience --src-prefix=a/batman-adv/ --dst-prefix=b/batman-adv/ $BASECOMMIT -}}} - * An exemplary good submission you may want to look at can be found here: https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2009-December/002033.html +</code></pre> +* An exemplary good submission you may want to look at can be found here: https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2009-December/002033.html -}}} +</code></pre>

1 0

[doc] backup-redmine/2017-07-13, master: doc: open-mesh/Experience (bc6217b8)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

Repository : ssh://git@open-mesh.org/doc On branches: backup-redmine/2017-07-13,master >--------------------------------------------------------------- commit bc6217b8557a0041e59e978a4056e863445b207c Author: Marek Lindner <mareklindner(a)neomailbox.ch> Date: Wed Mar 16 22:20:42 2011 +0000 doc: open-mesh/Experience >--------------------------------------------------------------- bc6217b8557a0041e59e978a4056e863445b207c open-mesh/Experience.textile | 44 +++++++++++++++++++++----------------------- 1 file changed, 21 insertions(+), 23 deletions(-) diff --git a/open-mesh/Experience.textile b/open-mesh/Experience.textile index edcdd060..c6fdde16 100644 --- a/open-mesh/Experience.textile +++ b/open-mesh/Experience.textile @@ -1,30 +1,28 @@ += Experience = -h1. Experience +{{{ +#!div style="width: 40em; text-align: justify" +This page aims to provide a collection of links towards press reviews & papers related to B.A.T.M.A.N. as well as projects using the B.A.T.M.A.N. protocol in real live scenarios. This collection only reflects a small percentage of the things out there because not everybody contacts us to share his experience. If you have made some experience or even setup a B.A.T.M.A.N. mesh network at someplace in this universe please feel urged to [wiki:MailingList tell us] or drop us a link! -<pre> -<code class="div"> +__Projects:__ + * building mesh potatoes with B.A.T.M.A.N.: http://villagetelco.org + * powerful mesh nodes with batman-adv inside: http://www.saxnet.de + * B.A.T.M.A.N. with dashboard integration: http://www.open-mesh.com + * The Batphone (VOIP + Mesh on your device): http://www.servalproject.org -This page aims to provide a collection of links towards press reviews & papers related to B.A.T.M.A.N. as well as projects using the B.A.T.M.A.N. protocol in real live scenarios. This collection only reflects a small percentage of the things out there because not everybody contacts us to share his experience. If you have made some experience or even setup a B.A.T.M.A.N. mesh network at someplace in this universe please feel urged to [[MailingList|tell us]] or drop us a link! +__Press:__ + * [http://kernelnewbies.org/Linux_2_6_38#head-17577655766f585c3c47df886fe91dba… Linux 2.6.38 release notes], kernelnewbies.org (March 2011) + * [http://www.h-online.com/open/features/Kernel-Log-Coming-in-2-6-38-Part-3-Ne… Kernel Log: Network drivers and infrastructure], The H Open (February 2011) + * [http://lwn.net/Articles/426947/ Mesh networking with batman-adv], LWN.net (February 2011) + * [http://www.h-online.com/open/features/What-s-new-in-Linux-2-6-37-1163376.ht… Kernel Trends: Outlook on 2.6.38], The H Open (January 2011) + * [http://www.h-online.com/open/news/item/Kernel-Log-Coming-in-2-6-33-Part-5-D… Kernel Log: Coming in 2.6.33 - Drivers], The H Open (February 2010) + * [http://www.linuxjournal.com/magazine/mesh-potato The Mesh Potato], Linux Journal (December 2009) -+Projects:+ -* building mesh potatoes with B.A.T.M.A.N.: http://villagetelco.org -* powerful mesh nodes with batman-adv inside: http://www.saxnet.de -* B.A.T.M.A.N. with dashboard integration: http://www.open-mesh.com -* The Batphone (VOIP + Mesh on your device): http://www.servalproject.org +__Papers:__ -+Press:+ -* "Linux 2.6.38 release notes":http://kernelnewbies.org/Linux_2_6_38#head-17577655766f585c3c47df886fe91dba276f4c3f, kernelnewbies.org (March 2011) -* "Kernel Log: Network drivers and infrastructure":http://www.h-online.com/open/features/Kernel-Log-Coming-in-2-6-38-Part-3-Network-drivers-and-infrastructure-1197480.html, The H Open (February 2011) -* "Mesh networking with batman-adv":http://lwn.net/Articles/426947/, LWN.net (February 2011) -* "Kernel Trends: Outlook on 2.6.38":http://www.h-online.com/open/features/What-s-new-in-Linux-2-6-37-1163376.html?page=6, The H Open (January 2011) -* "Kernel Log: Coming in 2.6.33 - Drivers":http://www.h-online.com/open/news/item/Kernel-Log-Coming-in-2-6-33-Part-5-Drivers-931993.html, The H Open (February 2010) -* "The Mesh Potato":http://www.linuxjournal.com/magazine/mesh-potato, Linux Journal (December 2009) - -+Papers:+ - -* "B.A.T.M.A.N. performance comparison paper":http://wirelessafrica.meraka.org.za/wiki/images/9/98/Batman_ifip.pdf -* "B.A.T.M.A.N. / BABEL / OLSR performance comparison":http://ro.uow.edu.au/cgi/viewcontent.cgi?article=1747&context=infopapers -* "mesh performance analysis with B.A.T.M.A.N.":http://users.ece.gatech.edu/~cortes/files/Wi-Me.pdf -</code></pre> + * [http://wirelessafrica.meraka.org.za/wiki/images/9/98/Batman_ifip.pdf B.A.T.M.A.N. performance comparison paper] + * [http://ro.uow.edu.au/cgi/viewcontent.cgi?article=1747&context=infopapers B.A.T.M.A.N. / BABEL / OLSR performance comparison] + * [http://users.ece.gatech.edu/~cortes/files/Wi-Me.pdf mesh performance analysis with B.A.T.M.A.N.] +}}}

1 0

[doc] backup-redmine/2017-07-13, master: doc: open-mesh/WikiStart (7288d49a)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

Repository : ssh://git@open-mesh.org/doc On branches: backup-redmine/2017-07-13,master >--------------------------------------------------------------- commit 7288d49ad6f635bd982272dcc7bf16ec2e95887e Author: Marek Lindner <mareklindner(a)neomailbox.ch> Date: Thu Mar 17 03:58:40 2011 +0000 doc: open-mesh/WikiStart >--------------------------------------------------------------- 7288d49ad6f635bd982272dcc7bf16ec2e95887e open-mesh/WikiStart.textile | 62 +++++++++++++++++++++++++++------------------ 1 file changed, 37 insertions(+), 25 deletions(-) diff --git a/open-mesh/WikiStart.textile b/open-mesh/WikiStart.textile index b23f21ee..06b6b68d 100644 --- a/open-mesh/WikiStart.textile +++ b/open-mesh/WikiStart.textile @@ -1,29 +1,41 @@ -= Welcome to Open Mesh = -'''This page serves as development platform for a collection of tools to build free and open mesh networks.''' + +h1. Welcome to Open Mesh + +*This page serves as development platform for a collection of tools to build free and open mesh networks.* ---- -= B.A.T.M.A.N. = + +h1. B.A.T.M.A.N. + B.A.T.M.A.N. (better approach to mobile ad-hoc networking) is a routing protocol for multi-hop ad-hoc mesh networks. This is the main development website, we have source code, binary packages, documentation and further information available: -== News == - * '''29.Jan. 2011''' [wiki:2011-01-29-batman-adv-2011-0-0-release Batman-adv 2011.0.0 released] - * '''18.Jan. 2011''' [wiki:2011-01-18-wbmv4-announcement WBMv4 Announcement] - * '''12.Dec. 2010''' [wiki:2010-12-12-batman-v-status-update B.A.T.M.A.N. V status update] - * '''22.Nov. 2010''' [wiki:2010-11-21-batman-adv-2010-2-0-release Batman-adv 2010.2.0 released] - * '''04.Sep. 2010''' [wiki:2010-09-04-batman-adv-2010-1-0-release Batman-adv 2010.1.0 released] - - * [wiki:news-archive news archive] -== Getting Started == - * [wiki:Download Download] - Get our latest releases, get access to our SVN repository - * [wiki:Contribute How to contribute] - How to report bugs, send comments, patches or suggestions -== Documentation == - * [wiki:BranchesExplained Branches explained] - learn about the B.A.T.M.A.N. flavours - * [wiki:UserDocs UserDocs] - understand how B.A.T.M.A.N. works - * [wiki:FAQ FAQ] - Frequently Asked Questions - * [wiki:Experience Experience] - Collection of links to B.A.T.M.A.N. press reviews, papers and projects using B.A.T.M.A.N. - * [wiki:Patches Patches] - contribution from others related to B.A.T.M.A.N. - * [wiki:batman-adv B.A.T.M.A.N. Advanced] - information about the Layer 2 version of B.A.T.M.A.N. - * [wiki:MailingList Mailing List]/[wiki:IRC IRC] - contact us + +h2. News + +* *17.Mar. 2011* [[2011-03-17-batman-adv-and-the-penguin|Batman-adv and the Penguin join forces]] +* *29.Jan. 2011* [[2011-01-29-batman-adv-2011-0-0-release|Batman-adv 201100 released]] +* *18.Jan. 2011* [[2011-01-18-wbmv4-announcement|WBMv4 Announcement]] +* *12.Dec. 2010* [[2010-12-12-batman-v-status-update|BATMAN V status update]] +* *22.Nov. 2010* [[2010-11-21-batman-adv-2010-2-0-release|Batman-adv 201020 released]] + +* [[news-archive|news archive]] + +h2. Getting Started + +* [[Download|Download]] - Get our latest releases, get access to our SVN repository +* [[Contribute|How to contribute]] - How to report bugs, send comments, patches or suggestions + +h2. Documentation + +* [[BranchesExplained|Branches explained]] - learn about the B.A.T.M.A.N. flavours +* [[UserDocs|UserDocs]] - understand how B.A.T.M.A.N. works +* [[FAQ|FAQ]] - Frequently Asked Questions +* [[Experience|Experience]] - Collection of links to B.A.T.M.A.N. press reviews, papers and projects using B.A.T.M.A.N. +* [[Patches|Patches]] - contribution from others related to B.A.T.M.A.N. +* [[batman-adv|BATMAN Advanced]] - information about the Layer 2 version of B.A.T.M.A.N. +* [[MailingList|Mailing List][wikiIRC IRC]] - contact us ---- -== Other Projects on open-mesh.org == - * [wiki:FFTrace FFTrace] - freifunk traceroute tool - * [wiki:MeshLinux MeshLinux] - Linux distribution geared to build mesh supernodes \ No newline at end of file + +h2. Other Projects on open-mesh.org + +* [[FFTrace|FFTrace]] - freifunk traceroute tool +* [[MeshLinux|MeshLinux]] - Linux distribution geared to build mesh supernodes \ No newline at end of file

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/ELP: some more specific questions (ea375a53)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

Repository : ssh://git@open-mesh.org/doc On branches: backup-redmine/2017-07-13,master >--------------------------------------------------------------- commit ea375a53ff93d78e2b33b08746c1fd267e12e236 Author: Linus Lüssing <linus.luessing(a)c0d3.blue> Date: Wed Mar 16 22:41:33 2011 +0000 doc: batman-adv/ELP: some more specific questions >--------------------------------------------------------------- ea375a53ff93d78e2b33b08746c1fd267e12e236 batman-adv/ELP.textile | 219 ++++++++++++++++++++----------------------------- 1 file changed, 88 insertions(+), 131 deletions(-) diff --git a/batman-adv/ELP.textile b/batman-adv/ELP.textile index 40e97423..cbc4ef9a 100644 --- a/batman-adv/ELP.textile +++ b/batman-adv/ELP.textile @@ -1,50 +1,42 @@ += Neighborhood Discovery Protocol (NDP) = -h1. Neighborhood Discovery Protocol (NDP) +{{{ +#!div style="width: 46em; text-align: justify" - -<pre> -<code class="div"> - -The B.A.T.M.A.N. protocol originally only used a single message type (called OGM) to determine the link qualities to the direct neighbors and spreading these link quality information through the whole mesh. This procedure is summarized on the [[BATMANConcept|BATMAN concept page]] and explained in details in "the RFC draft":http://tools.ietf.org/html/draft-wunderlich-openmesh-manet-routing-00 published in 2008. +The B.A.T.M.A.N. protocol originally only used a single message type (called OGM) to determine the link qualities to the direct neighbors and spreading these link quality information through the whole mesh. This procedure is summarized on the [wiki:BATMANConcept B.A.T.M.A.N. concept page] and explained in details in [http://tools.ietf.org/html/draft-wunderlich-openmesh-manet-routing-00 the RFC draft] published in 2008. This approach was chosen for its simplicity during the protocol design phase and the implementation. However, it also bears some drawbacks: -* Wireless interfaces usually come with some packet loss, therefore a higher broadcast rate is desirable to allow a fast reaction on flaky connections. Other interfaces of the same host might be connected to Ethernet LANs / VPNs / etc which rarely exhibit packet loss would benefit from a lower broadcast rate to reduce overhead. -* It generally is more desirable to detect local link quality changes at a faster rate than propagating all these changes through the entire mesh (the far end of the mesh does not need to care about local link quality changes that much). Other optimizations strategies, like reducing overhead, might be possible if OGMs weren't used for all tasks in the mesh at the same time. + * Wireless interfaces usually come with some packet loss, therefore a higher broadcast rate is desirable to allow a fast reaction on flaky connections. Other interfaces of the same host might be connected to Ethernet LANs / VPNs / etc which rarely exhibit packet loss would benefit from a lower broadcast rate to reduce overhead. + * It generally is more desirable to detect local link quality changes at a faster rate than propagating all these changes through the entire mesh (the far end of the mesh does not need to care about local link quality changes that much). Other optimizations strategies, like reducing overhead, might be possible if OGMs weren't used for all tasks in the mesh at the same time. As a result detecting local link qualities shall be handled by an independent message type, NDP, whereas the OGM message type remains responsible for flooding the mesh with these link quality information and determening the overall path transmit qualities. +=== Definitions === -h3. Definitions - - -* node - A mesh router which utilizes the B.A.T.M.A.N. protocol as specified in this document on at least one network interface. A node consists of one or more originators. -* originator - An addressable entity within one mesh network routing layer. An originator's address has to be unique within a mesh network routing layer and unique on a node. A node's hard-interface may only be utilized by zero or one originator. -* B.A.T.M.A.N./hard interface - Network interface utilized by B.A.T.M.A.N. for its own ethernet frames. -* sliding window - Sequence numbers are recorded in dedicated sliding windows until they are considered out-of range. Thus, such a sliding window always contains the set of recently received sequence numbers. The amount of sequence numbers recorded in the sliding window is used as a metric for the quality of detected links and paths. -* duplicate - A received NDP message from a neighbor containing an already received sequence number. -* out of order - A received NDP message from a neighbor containing a sequence number that is older than the newest sequence number ever received from this neighbor. - - -h3. Protocol Procedure + * node - A mesh router which utilizes the B.A.T.M.A.N. protocol as specified in this document on at least one network interface. A node consists of one or more originators. + * originator - An addressable entity within one mesh network routing layer. An originator's address has to be unique within a mesh network routing layer and unique on a node. A node's hard-interface may only be utilized by zero or one originator. + * B.A.T.M.A.N./hard interface - Network interface utilized by B.A.T.M.A.N. for its own ethernet frames. + * sliding window - Sequence numbers are recorded in dedicated sliding windows until they are considered out-of range. Thus, such a sliding window always contains the set of recently received sequence numbers. The amount of sequence numbers recorded in the sliding window is used as a metric for the quality of detected links and paths. + * duplicate - A received NDP message from a neighbor containing an already received sequence number. + * out of order - A received NDP message from a neighbor containing a sequence number that is older than the newest sequence number ever received from this neighbor. +=== Protocol Procedure === - -h4. Broadcasting own Neighborhood Discovery Protocol (NDP) Messages - +==== Broadcasting own Neighborhood Discovery Protocol (NDP) Messages ==== Each node periodically (NDP interval) generates and broadcasts NDP messages for each interface B.A.T.M.A.N. is running on. A jitter may be applied to avoid collisions. -+The Neighborhood Discovery Protocol (NDP) Format:+ +__The Neighborhood Discovery Protocol (NDP) Format:__ -* Packet type: Initialize this field with the NDP packet type. -* Version: Set your internal compatibility version. -* Originator Address: Set this field to the primary MAC address of this B.A.T.M.A.N. node. -* Sequence number: On first broadcast set the sequence number to an arbitrary value and increment the field by one for each following broadcast. -* Num Neigh: The number of neighbors that are announced with this message. + * Packet type: Initialize this field with the NDP packet type. + * Version: Set your internal compatibility version. + * Originator Address: Set this field to the primary MAC address of this B.A.T.M.A.N. node. + * Sequence number: On first broadcast set the sequence number to an arbitrary value and increment the field by one for each following broadcast. + * Num Neigh: The number of neighbors that are announced with this message. If this B.A.T.M.A.N. interface wants to announce neighboring nodes it should append a neighbor entry message for each neighbor to be announced and fill the "number of neighbors" field accordingly. -<pre> +{{{ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -56,16 +48,16 @@ If this B.A.T.M.A.N. interface wants to announce neighboring nodes it should app +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Num Neigh | Alignment | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -</code></pre> +}}} -+The Neighbor Entry Format:+ +__The Neighbor Entry Format:__ -* Neighbor Address: This field contains the MAC address of the neighbor to be announced. -* Link RQ: Fill this field with the total of the received sequence numbers (in percent) within the sliding sequence number window from this neighbor. + * Neighbor Address: This field contains the MAC address of the neighbor to be announced. + * Link RQ: Fill this field with the total of the received sequence numbers (in percent) within the sliding sequence number window from this neighbor. Note: See 'Neighbor Ranking' to get a detailed description of how to count/obtain the RQ value. Neighbors with an RQ value of 0 are not to be appended. -<pre> +{{{ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -73,126 +65,93 @@ Note: See 'Neighbor Ranking' to get a detailed description of how to count/obtai +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor Address | Link RQ | Alignment | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -</code></pre> - - -h4. Receiving Neighborhood Discovery Messages (NDP) +}}} +==== Receiving Neighborhood Discovery Messages (NDP) ==== Upon receiving a NDP packet a node must perform the following preliminary checks before the packet is further processed: -* If the NDP contains a version which is different to the own internal version the message must be silently dropped (thus, it must not be further processed). -* If the sender address of the NDP message belongs to one of the B.A.T.M.A.N. interfaces the message must be silently dropped as this NDP message originated from this node. -* If the sender address of the NDP message is an ethernet multicast (including broadcast) address the message must be silently dropped. -* If the NDP message is a duplicate or does not contain a newer sequence number (out-of-order) the message must be silently dropped. - - -h4. Neighbor Ranking + * If the NDP contains a version which is different to the own internal version the message must be silently dropped (thus, it must not be further processed). + * If the sender address of the NDP message belongs to one of the B.A.T.M.A.N. interfaces the message must be silently dropped as this NDP message originated from this node. + * If the sender address of the NDP message is an ethernet multicast (including broadcast) address the message must be silently dropped. + * If the NDP message is a duplicate or does not contain a newer sequence number (out-of-order) the message must be silently dropped. +==== Neighbor Ranking ==== For each NDP message having passed the preliminary checks the following must be performed: -* The sliding window to the sender of the NDP message must be updated (purged) to reflect the new upper and lower boundaries of the ranking range. The sequence number of the received NDP message must be added to the sliding window representing the link via which the NDP message has been received. -* The new resulting link RQ value is calculated by counting all sequence numbers that are to be found in the recently adjusted sliding window. -* The new current sequence number must be set to the sequence number contained in the received NDP message. -* All appended neighbor entries must be parsed to search for all MAC addresses belonging to one of the B.A.T.M.A.N. interfaces. If a match is found then save the received link RQ value towards that neighbor as link TQ value. - - - -h4. Questions - - -* checks whether the NDP packet is too old? (TODO: Simon, add/describe the protected window mechanism) -* Shall we add "neighbor" interface addresses, which are our own to the NDP packet? (e.g., if one node has two interfaces which share the same broadcast domain) -* Shall we process one of our own NDP packets which we received over one of our other interfaces? (e.g. if one node has two interfaces which share the same broadcast domain) -* Shall we scan a NDP packet received from one of our neighbors only for an entry matching the incoming interface? (e.g. if one node has two interfaces which share the same broadcast domain) -* What to do if there are multiple entries with the matching mac address(es)? Only use the first and ignore the other matches? -* If a match has been found, do not further procede the traversal of neighbor entries -* Are NDP entries with a RQ of 0 allowed? -* What to do if RQ reaches 0 due to automatic sliding window? -* What to do if receiving an NDP packet which does not have the nodes own interface mac? Treating it as RQ of 0? Or keeping old value? + * The sliding window to the sender of the NDP message must be updated (purged) to reflect the new upper and lower boundaries of the ranking range. The sequence number of the received NDP message must be added to the sliding window representing the link via which the NDP message has been received. + * The new resulting link RQ value is calculated by counting all sequence numbers that are to be found in the recently adjusted sliding window. + * The new current sequence number must be set to the sequence number contained in the received NDP message. + * All appended neighbor entries must be parsed to search for all MAC addresses belonging to one of the B.A.T.M.A.N. interfaces. If a match is found then save the received link RQ value towards that neighbor as link TQ value. -h2. Extensions == - Threshholds === +==== Questions ==== -h3. EWMA === - Weighted Window === - -h3. Auto RQ window sliding === - Fixed minimum NDP packet size? === - -h3. Sometimes maximum packet size packets? + * checks whether the NDP packet is too old? (TODO: Simon, add/describe the protected window mechanism) + * Shall we add "neighbor" interface addresses, which are our own to the NDP packet? (e.g., if one node has two interfaces which share the same broadcast domain) + * Shall we process one of our own NDP packets which we received over one of our other interfaces? (e.g. if one node has two interfaces which share the same broadcast domain) + * Shall we scan a NDP packet received from one of our neighbors only for an entry matching the incoming interface? (e.g. if one node has two interfaces which share the same broadcast domain) + * What to do if there are multiple entries with the matching mac address(es)? Only use the first and ignore the other matches? + * If a match has been found, do not further procede the traversal of neighbor entries + * Are NDP entries with a RQ of 0 allowed? + * What to do if RQ reaches 0 due to automatic sliding window? + * What to do if receiving an NDP packet which does not have the nodes own interface mac? Treating it as RQ of 0? Or keeping old value? +== Extensions == +=== Threshholds === +=== EWMA === +=== Weighted Window === +=== Auto RQ window sliding === +=== Fixed minimum NDP packet size? === +=== Sometimes maximum packet size packets? === ---- +== examples of NDP advantages == + * Modularization of the code + * The delta changes between two OGMs can be increased with an NDP interval faster than the OGM interval, resulting in a higher influence of a single OGM. + * Separate optimization strategies can be used for NDP and OGMs individually then. + * The more sparse the network is (number of single hop neighbors significantly smaller than the number of all nodes), the faster the NDP interval can be chosen relative to the OGM interval, resulting in major convergence speed improvements in sparse networks. + * As NDP messages are never rebroadcasted it also helps to reduce the overhead in dense networks (many single hop neighbors). + * (Mobile nodes can chose a faster OGM + NDP interval then. It directly improves their transmit path - which was not the case with the OGM LQ measurements due to the echo-quality dependency, and indirectly improves their receive path a little, due to the asymmetric penalty) + * Less overhead: With the classic LQ measurements with NDP, the overhead increases in a squared way immediately due to the OGM rebroadcast mechanism. The squared factor in NDP has a very low base however, therefore it only applies at a large amount of neighbors. This means, that when having i.e. 10 neighbors (or probably even 50), you can select a 10 (or 50x) faster NDP interval compared to the LQ measurements with the classic OGMs. + * More accuracy in case of medium/bad links: The EQ mechanism "reduces" the effective window for the EQ measurements. So when having a TQ of 50%25, the effective EQ window will be only ~32 bits large instead of the 64, leading to many more TQ/RQ fluctuations on links with a low transmit quality. -h2. examples of NDP advantages - -* Modularization of the code -* The delta changes between two OGMs can be increased with an NDP interval faster than the OGM interval, resulting in a higher influence of a single OGM. -* Separate optimization strategies can be used for NDP and OGMs individually then. -* The more sparse the network is (number of single hop neighbors significantly smaller than the number of all nodes), the faster the NDP interval can be chosen relative to the OGM interval, resulting in major convergence speed improvements in sparse networks. -* As NDP messages are never rebroadcasted it also helps to reduce the overhead in dense networks (many single hop neighbors). -* (Mobile nodes can chose a faster OGM + NDP interval then. It directly improves their transmit path - which was not the case with the OGM LQ measurements due to the echo-quality dependency, and indirectly improves their receive path a little, due to the asymmetric penalty) -* Less overhead: With the classic LQ measurements with NDP, the overhead increases in a squared way immediately due to the OGM rebroadcast mechanism. The squared factor in NDP has a very low base however, therefore it only applies at a large amount of neighbors. This means, that when having i.e. 10 neighbors (or probably even 50), you can select a 10 (or 50x) faster NDP interval compared to the LQ measurements with the classic OGMs. -* More accuracy in case of medium/bad links: The EQ mechanism "reduces" the effective window for the EQ measurements. So when having a TQ of 50%25, the effective EQ window will be only ~32 bits large instead of the 64, leading to many more TQ/RQ fluctuations on links with a low transmit quality. - -* You usually should set the originator interval to a value suiting the most mobile node on all nodes, having a homogeneous interval. This means, that even if you have a very static neighborhood with lots of nodes (so resulting to a lot of rebroadcasts, which can be the case on VPN- or ethernet interfaces used by batman-adv), you can't lower the interval for that one because very mobile nodes far away might than not be able to reach you anymore. -* A OGM should not be rebroadcasted by the same node more than once because that could falsify the link-quality calculations. However you might want to do this to speed the convergence at more distant and/or weaker links. - - -h2. RQ calculation + * You usually should set the originator interval to a value suiting the most mobile node on all nodes, having a homogeneous interval. This means, that even if you have a very static neighborhood with lots of nodes (so resulting to a lot of rebroadcasts, which can be the case on VPN- or ethernet interfaces used by batman-adv), you can't lower the interval for that one because very mobile nodes far away might than not be able to reach you anymore. + * A OGM should not be rebroadcasted by the same node more than once because that could falsify the link-quality calculations. However you might want to do this to speed the convergence at more distant and/or weaker links. +== RQ calculation == In periodic intervals, customizable per interface, a ndp packet gets broadcasted on each interface. As it has been done with the normal OGMs before, the rq-value is being calculated with a sliding window and counting the number of received ndp packets, but on a per interface basis now. - -h2. local TQ propagation - +== local TQ propagation == Additionally, a 2-tupel of neighbor-adresses and rq-values of neighbors on a certain interface will be attached to each ndp packet of the according interface. A neighbor will then pick the rq-value which the other node determined from the received ndp packets and insert this value as its own tq-value towards that node. - -h2. global TQ propagation - +== global TQ propagation == A node receiving an OGM will reduce its global TQ field by the local TQ fitting the neighbor and interface before processing/rebroadcasting (but after validation/duplicate checks). - -h2. Data packet forwarding - +== Data packet forwarding == This will still be done according to the received global TQ. ---- +== Further optimizations == -h2. Further optimizations - - - -h3. Consider local-TQ for a final forwarding - +=== Consider local-TQ for a final forwarding === It might happen, that a node rapidly moves towards the sender of a data packet. If so, a forwarding node can notice, that the local TQ value towards the final destination of the data packet is suddenly better than the global TQ via another hop. This forwarding node can then forward the packet to its final destination instead of forwarding it to the other next-hop according to the global TQ. - -h3. Rebroadcast OGM X times instead of once - +=== Rebroadcast OGM X times instead of once === Every node could rebroadcast an OGM i.e. 3 times instead of just once to increase the probability of an OGM reaching every node in the mesh, resulting in a much better convergence speed (getting closer to linear convergence speed) for the trade-off of control overhead (getting closer to squared). - -h3. Unscheduled OGM rebroadcasts - - +=== Unscheduled OGM rebroadcasts === -h3. Adaptive ndp interval - - - -h3. Probablistic flooding +=== Adaptive ndp interval === +=== Probablistic flooding === Although this does not optimize the convergence speed, it could greatly increase the efficiency of the flooding of broadcast/mulitcast-data packets. With ndp we now also know our neighbors' TQ-values on the same interface. With this information a node A can determine the probability, that a broadcast of node B has already reached all of A's neighbors: P(|N| = |N^+^|) = ∏_{n ∈ N} TQ(B, iface, n) with N being the set of A's neighbors and N^+^ the set of neighbors successfully receiving the broadcast. @@ -202,32 +161,30 @@ A node could then either decide with a threshold, if it might not rebroadcast (r ---- +==== Looping problems ==== -h4. Looping problems - - -_Not an NDP issue, also present for current OGM mechanism - moved it to a different page later_ +''Not an NDP issue, also present for current OGM mechanism - moved it to a different page later'' However, there seems to be a looping problem? (or do sequence numbers or global TQ window fix this?) In the following 4 node scenario, the parameters are as follows: -* OGM interval: 1000 -* NDP interval: ε (very fast) + * OGM interval: 1000 + * NDP interval: ε (very fast) Now node R moves from B to A within the first second, so he'll arrive at B before it schedules its next OGM. Also this next OGM after this first second already uses the new link qualities due to the fast NDP interval. -*t = 0:* +'''t = 0:''' [[Image(NDP-mobile-loop-0s.png, 20%25)]] -*t = 1:* +'''t = 1:''' [[Image(NDP-mobile-loop-1s.png, 20%25)]] After about 10 seconds average, there will be a loop with S sending packets to B, and B sending them back to S. This loop will last for about 3.3 seconds average. -The following [[table]] will hold some more in detail information with the times and events that will change BATMAN nodes topology knowledge. It holds the following information: -* The times t in the table are the average times of arrival of an OGM at a node in seconds. -* The table shows the TQ values towards R. The first six of these rows are from a nodes perspective, the last two ones the actual, real TQ values for the chosen path. -* Time span with loops is marked with YES in the 'loops' row. +The following [[http://x-realis.dyndns.org/freifunk/scan.pdf table]] will hold some more in detail information with the times and events that will change BATMAN nodes topology knowledge. It holds the following information: + * The times t in the table are the average times of arrival of an OGM at a node in seconds. + * The table shows the TQ values towards R. The first six of these rows are from a nodes perspective, the last two ones the actual, real TQ values for the chosen path. + * Time span with loops is marked with YES in the 'loops' row. -_Result:_ In this quite typical and small-scale scenario, we already have an average time with looping packets of *3.3* seconds. -</code></pre> +''Result:'' In this quite typical and small-scale scenario, we already have an average time with looping packets of '''3.3''' seconds. +}}}

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

commits July 2017