commits July 2017

commits@lists.open-mesh.org

1 participants
1317 discussions

[doc] backup-redmine/2017-07-13, master: doc: attachments/vde2-2.3.1-wirefilter-ethertype.patch (323869ab)
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 323869ab3d0dbcd5fc4216cce0b48beae5cb4c21 Author: Antonio Quartulli <a(a)unstable.cc> Date: Mon Oct 24 20:10:47 2011 +0000 doc: attachments/vde2-2.3.1-wirefilter-ethertype.patch >--------------------------------------------------------------- 323869ab3d0dbcd5fc4216cce0b48beae5cb4c21 attachments/vde2-2.3.1-wirefilter-ethertype.patch | 111 ++++++++++++++++++++++ 1 file changed, 111 insertions(+) diff --git a/attachments/vde2-2.3.1-wirefilter-ethertype.patch b/attachments/vde2-2.3.1-wirefilter-ethertype.patch new file mode 100644 index 00000000..9874ea2e --- /dev/null +++ b/attachments/vde2-2.3.1-wirefilter-ethertype.patch @@ -0,0 +1,111 @@ +--- src/wirefilter.c.orig 2010-07-25 19:48:02.000000000 +0200 ++++ src/wirefilter.c 2011-10-24 18:21:01.122126068 +0200 +@@ -59,6 +59,9 @@ + char debuglevel[NPFD]; + char *progname; + char *mgmt; ++char ether_type[2]; ++unsigned char ether_num_bytes; ++char ether_bytes[10]; + int mgmtmode=0700; + #define LR 0 + #define RL 1 +@@ -524,13 +527,39 @@ + + void handle_packet(int dir,const unsigned char *buf,int size) + { ++ int i; ++ + /* MTU */ + /* if the packet is incosistent with the MTU of the line just drop it */ + if (min_wirevalue(markov_current,MTU,dir) > 0 && size > min_wirevalue(markov_current,MTU,dir)) + return; + ++ /* if the packet has the whitelisted ethertype or etherbytes just send it */ ++ if ((ether_type[0] == 0 && ether_type[1] == 0) || (size < 16)) ++ goto wire_check; ++ ++ if ((ether_type[0] != buf[14]) || (ether_type[1] != buf[15])) ++ goto wire_check; ++ ++ if (ether_num_bytes == 0) { ++ writepacket(dir,buf,size); ++ return; ++ } else { ++ if (size < 17) ++ goto wire_check; ++ ++ for (i = 0; i < ether_num_bytes; i++) { ++ if (ether_bytes[i] != buf[16]) ++ continue; ++ ++ writepacket(dir,buf,size); ++ return; ++ } ++ } ++ + /* LOSS */ + /* Total packet loss */ ++wire_check: + if (min_wirevalue(markov_current,LOSS,dir) >= 100.0) + return; + /* probabilistic loss */ +@@ -1391,6 +1420,7 @@ + "\t--pidfile pidfile\n" + "\t--blink blinksocket\n" + "\t--blinkid blink_id_string\n" ++ "\t--ether ether_type<:byte><:byte>\n" + ,progname); + exit (1); + } +@@ -1402,6 +1432,7 @@ + int option_index; + int mgmtindex=-1; + int consoleindex=-1; ++ char *ptr; + static struct option long_options[] = { + {"help",0 , 0, 'h'}, + {"rcfile", 1, 0, 'f'}, +@@ -1421,17 +1452,20 @@ + {"daemon",0 , 0, DAEMONIZEARG}, + {"pidfile", 1, 0, PIDFILEARG}, + {"blink",1,0,LOGSOCKETARG}, +- {"blinkid",1,0,LOGIDARG} ++ {"blinkid",1,0,LOGIDARG}, ++ {"ether", 1, 0, 'e'}, + }; + progname=basename(argv[0]); + markov_resize(1); + + setsighandlers(); + atexit(cleanup); ++ ether_num_bytes = 0; ++ memset(ether_bytes, 0, sizeof(ether_bytes)); + + while(1) { + int c; +- c = GETOPT_LONG (argc, argv, "hnl:d:M:D:m:b:s:c:v:L:f:", ++ c = GETOPT_LONG (argc, argv, "hnl:d:M:D:m:b:s:c:v:L:f:e:", + long_options, &option_index); + if (c<0) + break; +@@ -1475,6 +1509,19 @@ + case 'N': + nofifo=1; + break; ++ case 'e': ++ sscanf(optarg,"%2hhx%2hhx", &ether_type[0], &ether_type[1]); ++ ptr = optarg; ++ for (n = 0; n < sizeof(ether_bytes); n++) { ++ ptr = strchr(ptr, ':'); ++ if (!ptr) ++ break; ++ ++ ptr++; ++ sscanf(ptr, "%hhx", &ether_bytes[n]); ++ ether_num_bytes++; ++ } ++ break; + case 'v': + { + char *colon;

1 0

[doc] backup-redmine/2017-07-13, master: doc: open-mesh/Emulation (855d0b36)
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 855d0b36d34eeaef9bce9cae0c65673d69804614 Author: Antonio Quartulli <a(a)unstable.cc> Date: Mon Oct 24 20:32:03 2011 +0000 doc: open-mesh/Emulation >--------------------------------------------------------------- 855d0b36d34eeaef9bce9cae0c65673d69804614 open-mesh/Emulation.textile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/open-mesh/Emulation.textile b/open-mesh/Emulation.textile index b7de6305..6c6d4209 100644 --- a/open-mesh/Emulation.textile +++ b/open-mesh/Emulation.textile @@ -70,9 +70,9 @@ In this concept, the host port can have colour 1 while the interconnection ports !vde_switch.png! -You can find the patch against vde2-2.2.3 (current latest stable version) to add this colour patch here: +You can find the patch against vde2-2.3.1 (current latest stable version) to add this colour patch here: -* attachment:vde2-2.2.3_colour.patch +* attachment:vde2-2.3.1_colour.patch h3. wirefilter

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Bridge-loop-avoidance-II (6aaa2c09)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

1 0

[doc] backup-redmine/2017-07-13, master: doc: open-mesh/Emulation (c996f5ed)
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 c996f5ed4d019da29c0fcdeb684bd18108a4c872 Author: Antonio Quartulli <a(a)unstable.cc> Date: Mon Oct 24 20:10:46 2011 +0000 doc: open-mesh/Emulation >--------------------------------------------------------------- c996f5ed4d019da29c0fcdeb684bd18108a4c872 open-mesh/Emulation.textile | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/open-mesh/Emulation.textile b/open-mesh/Emulation.textile index 20354a64..b7de6305 100644 --- a/open-mesh/Emulation.textile +++ b/open-mesh/Emulation.textile @@ -103,11 +103,8 @@ This patch also allows to filter batman-adv packet types. To apply a packet loss wirefilter --ether 4305:02 -l 50 </pre> -You can specify up to 10 packet types (separated by colon). The patch against vde2-2.2.3 (current latest stable version) can be found here: -* attachment:vde2-2.2.3-wirefilter-ethertype.patch - -Patch for vde2-2.3.1 can be found here: -* attachment:wirefilter-ethertype_2.3.1.patch +You can specify up to 10 packet types (separated by colon). The patch against vde2-2.3.1 (current latest stable version) can be found here: +* attachment:vde2-2.3.1-wirefilter-ethertype.patch h2. Scripts

1 0

[doc] backup-redmine/2017-07-13, master: doc: open-mesh/Emulation (eca047b0)
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 eca047b0873d67e0aea416935fff74dcddaea3e3 Author: Antonio Quartulli <a(a)unstable.cc> Date: Mon Oct 24 18:27:04 2011 +0000 doc: open-mesh/Emulation >--------------------------------------------------------------- eca047b0873d67e0aea416935fff74dcddaea3e3 open-mesh/Emulation.textile | 3 +++ 1 file changed, 3 insertions(+) diff --git a/open-mesh/Emulation.textile b/open-mesh/Emulation.textile index 9177e78f..20354a64 100644 --- a/open-mesh/Emulation.textile +++ b/open-mesh/Emulation.textile @@ -106,6 +106,9 @@ wirefilter --ether 4305:02 -l 50 You can specify up to 10 packet types (separated by colon). The patch against vde2-2.2.3 (current latest stable version) can be found here: * attachment:vde2-2.2.3-wirefilter-ethertype.patch +Patch for vde2-2.3.1 can be found here: +* attachment:wirefilter-ethertype_2.3.1.patch + h2. Scripts

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Bridge-loop-avoidance-II (1844f4ea)
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 1844f4ea7598220f016cc61b25a5b30e2f0413b8 Author: Simon Wunderlich <sw(a)simonwunderlich.de> Date: Mon Oct 24 00:02:50 2011 +0000 doc: batman-adv/Bridge-loop-avoidance-II >--------------------------------------------------------------- 1844f4ea7598220f016cc61b25a5b30e2f0413b8 batman-adv/Bridge-loop-avoidance-II.textile | 116 +++++++++++++++++----------- 1 file changed, 73 insertions(+), 43 deletions(-) diff --git a/batman-adv/Bridge-loop-avoidance-II.textile b/batman-adv/Bridge-loop-avoidance-II.textile index 5b24207f..fe561b96 100644 --- a/batman-adv/Bridge-loop-avoidance-II.textile +++ b/batman-adv/Bridge-loop-avoidance-II.textile @@ -4,32 +4,35 @@ This page contains a concept in progress, it is not implemented yet, but feel fr h2. Situation -This is the example we will use to discuss the concept: multiple gateways are connected to a big, single backbone. There are also some more mesh nodes which are not connected to the LAN. LAN connections are drawn with solid lines, mesh connections with dotted lines. You can see an internet gateway connected through the LAN (this could be any other network device as well) at the top and a client (e.g. your laptop) connected/bridged through a mesh node in the bottom. +!situation.dia.png! -h2. Goals: +This is the example we will use to discuss the concept: multiple meshnodes (called backbone gateways in the further text) are connected to a big, single backbone. There are also some more mesh nodes which are not connected to the LAN. LAN connections are drawn with solid lines, mesh connections with dotted lines. You can see an internet gateway connected through the LAN (this could be any other network device as well) at the top and a client (e.g. your laptop) connected/bridged through a mesh node in the bottom. - * Should be able to scale - * Communication between meshnodes and LAN should be via the best gateway - * Minimize Broadcast Traffic in the LAN - * Roaming should still be possible h2. Definitions: - * Gateway: A mesh node which is conncted to both a mesh and a LAN + * backbone gateway: A mesh node which is conncted to both a mesh and a LAN * Client: A non-mesh network participant which is sending data via the mesh. The Client is always identified by the Source MAC address of the payload Ethernet header. +h2. Goals: + + * Should be able to scale + * Communication between meshnodes and LAN should be via the best backbone gateway + * Minimize Broadcast Traffic in the LAN + * Roaming should still be possible + h2. Key Concepts: h3. Claims: -Only one gateway (out of possibly many gateways) should serve a client from the mesh for the LAN. This is announced by sending "claim packets" on the soft-interface bat0. A "claim packet" contains a list of MAC addresses the gateway feels responsible for. Each gateway will save the claim list of other gateways. By doing this, it can: +Only one backbone gateway (out of possibly many gateways) should serve a client from the mesh for the LAN. This is announced by sending "claim frames" on the soft-interface bat0. A "claim frames" contains a MAC address the backbone gateway feels responsible for. Each backbone gateway will save a claim list of other backbone gateways. By doing this, it can: * see which clients are already tracked (claimed) - * see which other gateways exist in the LAN + * see which other backbone gateways exist in the LAN -Note that gateways may overwrite a claim of another gateway by simply claiming the same client. In this case, the newest claim wins, and local databases are updated accordingly. +Note that backbone gateways may overwrite a claim of another backbone gateway by simply claiming the same client. In this case, the newest claim wins, and local databases are updated accordingly. -Gateways can also "unclaim" their own clients. After doing this, the client is not claimed anymore for this LAN. +Backbone gateways can also "unclaim" their own clients. After doing this, the client is not claimed anymore for this LAN. h2. Details and Cases: @@ -38,75 +41,82 @@ and mesh->LAN->mesh. Furthermore, roaming is discussed when a client changes fro h3. Broadcast, mesh->LAN: +!mesh_LAN.dia.png! If the originator of the broadcast is not known (not in the originator table), drop it. -If the originator of the broadcast is another gateway from the same LAN, drop it. - -If a gateway has already claimed the client, only the resposible gateway will deliver the frame to the bridge. Other gateways will discard the packet. - -If no gateway has claimed the client, the gateway(s) will race for the claim: +If the originator of the broadcast is another backbone gateway from the same LAN, drop it. - * check if a claim is present (we assumed there is none) - * wait for a short, random time - * check again if any other gateway has claimed in the meantime. If yes, drop it. - * send a claim packet including the new client - * deliver the Broadcast frame to the soft-interface +If a backbone gateway has already claimed the client, only the resposible backbone gateway will deliver the frame to the backbone/LAN. Other backbone gateways will discard the packet. -The random backoff is used to avoid the race conditions when the packet is delivered from the mesh by multiple gateways at the same time. - -For every broadcast frame delivered into the LAN, add an entry in the LAN duplicate list. This is used for loop detection and roaming. +If no backbone gateway has claimed the client, the first client receiving the broadcast will claim it in the backbone by sending a claim frame, and send the actual broadcast frame. h3. Unicast, mesh->LAN: -If the client is not claimed by the gateway receiving the unicast, a claim packet is sent out first. This gateway is now the (new) responsible gateway for this client. +!mesh_LAN_unicast.dia.png! + +If the client is not claimed by the backbone gateway receiving the unicast, a claim packet is sent out first. This backbone gateway is now the (new) responsible backbone gateway for this client. Then, the unicast packet is delivered to the soft interface. h3. Broadcast, LAN->mesh: +!LAN_mesh.dia.png! + If a claim for the mesh-client exists: - * all not responsible gateways should discard the frame - this might be a loop. - * if the responsible gateway (which claimed this client) also receives the packet, "unclaim" this client by sending an according un-claim packet, and forward the packet into the mesh. This should only happen in the roaming case, but not in normal situations. + * all not responsible backbone gateways should discard the frame - this might be a loop. + * if the responsible backbone gateway (which claimed this client) also receives the packet, "unclaim" this client by sending an according un-claim packet, and forward the packet into the mesh. This should only happen in the roaming case, but not in normal situations. -If the client is not claimed, only the gateway with the numerically lowest MAC address will forward the frame into the mesh. +If the client is not claimed, all backbone gateways will send the broadcast into the mesh. The mesh nodes will avoid duplicates by using the duplicate lists (see optimizations below) h3. Unicast, LAN->mesh: +!LAN_mesh_unicast .dia.png! + Nothing fancy should happen here, as a switch should do the right thing. If the client is not claimed, the frame is simply sent into the mesh. -However, when using hubs (or broken switches), also unicast packets might loop. Therefore, if the client (source of the Ethernet frame) is claimed by any gateway, drop it. +However, when using hubs (or broken switches), also unicast packets might loop. Therefore, if the client (source of the Ethernet frame) is claimed by any backbone gateway, drop it. h3. mesh->LAN->mesh loop: -A broadcast frame is only sent to LAN by the (yet to be) responsible gateway. Back from the LAN to the mesh, all not responsible gateway will drop the frame. The responsible gateway should not receive it on normal switched networks. +!mesh_LAN_mesh.dia.png! + +A broadcast frame is only sent to LAN by the (yet to be) responsible backbone gateway. Back from the LAN to the mesh, all not responsible backbone gateways will drop the frame. The responsible backbone gateway should not receive it on normal switched networks. To avoid loops for hubs, unicast packets are dropped from LAN to mesh if the client is claimed. h3. LAN->mesh->LAN loop: -Although a broadcast frame is sent into the mesh, it won't loop back into the LAN as a gateway will drop it if was sent from another gateway (from the same LAN). +!LAN_mesh_LAN.dia.png! + +Although a broadcast frame is sent into the mesh, it won't loop back into the LAN as a backbone gateway will drop it if was sent from another backbone gateway (from the same LAN). h3. LAN->mesh Roaming: +(TODO: illustration) + This is the easy case: Sooner or later, a claim will be added for the roamed client. h3. mesh->LAN Roaming: -We assume that the client was already claimed by a gateway before, otherwise there is nothing to consider. +(TODO: illustration) -When a broadcast frame is sent, the responsible gateway can detect the roam: The frames checksum should not be in the "LAN duplicate list", as the frame is new and has not been sent by this gateway. The client will therefore be unclaimed. This first broadcast will only be broadcasted by the (previously) responsible gateway into the mesh, later broadcasts will be sent by all gateways again. +We assume that the client was already claimed by a backbone gateway before, otherwise there is nothing to consider. -Unicast frames are dropped, and the clients roaming will not be known as long as no broadcast frame is sent. This is a limitation. :( +When a broadcast frame is sent, the responsible backbone gateway can detect the roam and will unclaim the client. This first broadcast will only be broadcasted by the (previously) responsible backbone gateway into the mesh, later broadcasts will be sent by all backbone gateways again. h3. Gateway selection: +!gateway_selection.dia.png! + All gateways announce the clients within their LAN and ignore roaming messages from other gateways on the same LAN. Other non-gateway meshnodes may select their best gateway to the LAN based on the TQ value. h3. Claim packets +TODO: rework this with the new packet defintions + To claim a packet, a gratious ARP packet may be used with the following settings: * SRC IP: 0.0.0.0, SRC HW: [Originator-MAC of the Gateway] @@ -142,7 +152,7 @@ self announcement packets are also sent as gratious arp packets with the follow Note: the SRC HW address is a "locally administered address" group address which should not be used by any NIC or protocol, but is not registered with the IEEE +Full claim table update+ -TODO: specify table updates. Should be very similar to the TT full table request/reply mechanism. +TODO: specify table updates. this is done with request claim packets and the normal claim/unclaim packets h2. Discussion: @@ -157,24 +167,45 @@ h3. Features: h3. Limitations: - * Roaming to the LAN with multiple gateways is slow when only unicast packets are used * other things I might have missed ... h2. Further Optimizations -h3. Broadcasting by all gateways +h3. Broadcasting by all backbone gateways -Instead of letting only one gateway emit the packets to the mesh, all gateways may send them instead. In this case, we have to make sure that the duplicates are recognized and ignored to deliver the broadcast packets only once to the users. +Instead of letting only one backbone gateway emit the packets to the mesh, all backbone gateways may send them instead. In this case, we have to make sure that the duplicates are recognized and ignored to deliver the broadcast packets only once to the users. -To do this, we use a "mesh duplicate list": This list is kept for every gateway mesh node which is connected to a LAN with multiple gateways. It checks broadcast packets which are sent from the LAN into the mesh through multiple gateways (and thus multiple times). +To do this, we use a "mesh duplicate list": This list is kept for every backbone gateway mesh node which is connected to a LAN with multiple backbone gateways. It checks broadcast packets which are sent from the LAN into the mesh through multiple backbone gateways (and thus multiple times). -If the client is not claimed by any gateway, every gateway shall forward the packet into the mesh. This will lead to duplicates of the broadcast with different meta information (different originators, different sequence numbers). To avoid duplicates within the mesh, every mesh node will use the "mesh duplicate list": +If the client is not claimed by any backbone gateway, every backbone gateway shall forward the packet into the mesh. This will lead to duplicates of the broadcast with different meta information (different originators, different sequence numbers). To avoid duplicates within the mesh, every mesh node will use the "mesh duplicate list": - * after the (old) seqno window check: match the frame to the "mesh duplicate list" of other gateways to see if another gateway from the same LAN has sent a broadcast with the same payload checksum. + * after the (old) seqno window check: match the frame to the "mesh duplicate list" of other backbone gateways to see if another backbone gateway from the same LAN has sent a broadcast with the same payload checksum. * if true, drop the packet. Otherwise, add the checksum to the entries and re-forward it. (Note that it might be neccesary to connect the checksums to sequence numbers to allow intentionally sent duplicate payload broadcasts) +h3. backbone gateway grouping + +TODO: explain groups +h2. Test Cases + +h3. TODO: Define Roaming Test Cases (LAN -> mesh, mesh -> LAN) +h3. TODO: Define gateway selection test cases (switch gateways) + +h3. Two LANs connected by one mesh + +!Test_2xLAN.dia.png! + +Two LANs are connected by one mesh. The backbone gateways of each LAN should find each other and claim only packets from each LAN. +Every node should be able to reach every other node. + +h3. Two meshes connected by one LAN + +!Test_2xmesh.dia.png! + +Two meshes are connected to one LAN. The backbone gateways of each mesh should find themselves and share their claims, but should disregard claims for backbone gateways they are not part of (only possible with the backbone gateway grouping optimization) +Every node should be able to reach every other node. + h2. Further ideas h3. from discussion on 2011-06-08: @@ -199,5 +230,4 @@ h3. Agenda/Comments for next discussion Please add any comments for the next discussion here: - * Discuss Claims - * VLANs should be handled too \ No newline at end of file + * \ No newline at end of file

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/NetworkCoding-technical (d42af5f1)
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 d42af5f1eecbb7aef7b49c66527548cc3f11ff0e Author: Martin Hundebøll <martin(a)hundeboll.net> Date: Wed Oct 19 18:05:08 2011 +0000 doc: batman-adv/NetworkCoding-technical >--------------------------------------------------------------- d42af5f1eecbb7aef7b49c66527548cc3f11ff0e batman-adv/NetworkCoding-technical.textile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/batman-adv/NetworkCoding-technical.textile b/batman-adv/NetworkCoding-technical.textile index 0a9dcedd..13ceafa0 100644 --- a/batman-adv/NetworkCoding-technical.textile +++ b/batman-adv/NetworkCoding-technical.textile @@ -29,7 +29,7 @@ To make the implementation of catwoman complete, the following features must be * Support fragmented unicast packets. * -Use the link quality of overhearing links when looking for coding opportunities.- * Support configuration with batctl. -* Use bat_dbg instead of printk. +* -Use bat_dbg instead of printk.- * Support setups with multiple interfaces. * Maintain ref-counters for struct orig_node. * -Refactor code into three files: catwoman.c, coding.c, and decoding.c-

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Bridge-loop-avoidance-II (8a1c18e9)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Bridge-loop-avoidance-II (54f51c39)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/NetworkCoding-technical (67a64580)
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 67a645800b18cbf85c1ec178c4204a4fe532ed26 Author: Martin Hundebøll <martin(a)hundeboll.net> Date: Tue Oct 18 12:17:07 2011 +0000 doc: batman-adv/NetworkCoding-technical >--------------------------------------------------------------- 67a645800b18cbf85c1ec178c4204a4fe532ed26 batman-adv/NetworkCoding-technical.textile | 1 + 1 file changed, 1 insertion(+) diff --git a/batman-adv/NetworkCoding-technical.textile b/batman-adv/NetworkCoding-technical.textile index 6ceeadd7..6c8e3c82 100644 --- a/batman-adv/NetworkCoding-technical.textile +++ b/batman-adv/NetworkCoding-technical.textile @@ -33,6 +33,7 @@ To make the implementation of catwoman complete, the following features must be * Support setups with multiple interfaces. * Maintain ref-counters for struct orig_node. * Refactor code into three files: catwoman.c, coding.c, and decoding.c +* Remove coding_path after a certain timeout. h2. Ideas

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

commits July 2017