commits July 2017

commits@lists.open-mesh.org

1 participants
1317 discussions

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/ELP (591ddf82)
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 591ddf825f9ff139a01fb4ee043f55c41192b2f1 Author: Linus Lüssing <linus.luessing(a)c0d3.blue> Date: Tue Jul 5 01:33:32 2011 +0000 doc: batman-adv/ELP >--------------------------------------------------------------- 591ddf825f9ff139a01fb4ee043f55c41192b2f1 batman-adv/ELP.textile | 37 ++++++++++++++++++++++++++++--------- 1 file changed, 28 insertions(+), 9 deletions(-) diff --git a/batman-adv/ELP.textile b/batman-adv/ELP.textile index c90d61c0..b8054e11 100644 --- a/batman-adv/ELP.textile +++ b/batman-adv/ELP.textile @@ -49,7 +49,7 @@ Each node periodically (ELP interval) generates and broadcasts ELP messages for * 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. -* Interval: Set to the current ELP interval of this interface in milli seconds. +* Interval: Set to the current ELP interval of this interface in milli seconds. The default interval is 500ms and it may be reconfigured during run-time. * 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. @@ -100,7 +100,7 @@ Upon receiving an ELP packet a node must perform the following preliminary check * If the sender address of the ELP message is an ethernet multicast (including broadcast) address the message must be silently dropped. * If the destination address of the ELP message is a unicast address the message must be silently dropped. * If the originator address of the ELP message is our own the message must be silently dropped as this ELP message originated from this node. -* If the ELP message does not contain a newer sequence number (duplicate, out-of-order or out-of-range) the message must be silently dropped. +* If the ELP message has not been received from a out-of-sync neighbor interface (see section 3.5) and if the ELP message does not contain a newer sequence number (duplicate, out-of-order or out-of-range) the message must be silently dropped. h4. 3.2.1. Duplicate @@ -123,6 +123,7 @@ An ELP packet is considered out-of-range if: * The received sequence number is smaller than the current window sequence number. * The received sequence number is greater than the current window sequence number minus 2^31. + h3. 3.3. Neighbor Ranking @@ -155,26 +156,44 @@ asym_penalty = 1 - (1 - link RQ)^3 h3. 3.4. Time-based Window Adjustment -At least once per second all ELP windows must be shifted to the expected current sequence number. This needs to be done to avoid that the OGM protocol picks up too high link quality values from ELP which do very likely not represent the current link quality anymore. +Periodically all ELP windows must be shifted to the expected current sequence number. This needs to be done to avoid that the OGM protocol picks up outdated and therefore too high link quality values from ELP which do might not represent the current link quality anymore. More precisely, for any interface of a node towards any according, stored neighbor interface check whether: -* The last updated time plus the ndp interval of this neighbor interface is higher than the current time. +* The last updated time plus the ndp interval times of this neighbor interface times two is higher than the current time. If so, the following actions must be performed: -* The last updated time of this neighbor interface needs to be set to the current time. -* The current window sequence number of this neighbor needs to be set to the expected sequence number (= current window sequence number + rounded-down( (current time - last updated time) / neighbor interface's ndp interval). +* The last updated time of this neighbor interface needs to be set to the current time minus the neighbor interface's ELP interval. +* The current window sequence number of this neighbor needs to be set to the expected sequence number (based on the current sequence number, the current time, the last updated time as well as the neighbor interface's ndp interval) minus one. The result always needs to be rounded down. * The sliding window of the ELP message must be shifted (purged) to reflect the new upper and lower boundaries of the ranking range. -* 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 resulting link RQ value is calculated by counting all sequence numbers that are to be found in the adjusted sliding window. +* The best link TQ needs to be updated. + +The period for checking and possible updating of the ELP windows should be chosen low enough to have an ELP window outdated for OUTDATED_MAX sequence numbers maximum. + +Batman-adv periodically checks all ELP windows in the interval of the neighbor interface with the lowest ELP interval. + +h3. 3.5. Detecting Out-of-sync Neighbor Interfaces + +The sequence number based sliding window together with time-based window adjustment face two difficulties: For one thing a node may have rebooted. In that case the rebooted node might suddenly have a sequence number slightly smaller than it had before the reboot. Or for another thing, a node may have been out of sight for a longer time and due to slightly different clocks on the nodes the expected sequence number might have increased too quickly. + +In both cases the ELP sequence numbers which are smaller than the expected sequence number would not be accepted and the ELP messages dropped, possibly for a very long time. + +To overcome this issue a node is considered out-of-sync if: +* Last Seen + 2 * neighbor interface's ELP interval * WINDOW_SIZE < Current Time. + +For the default ELP interval of 0.5s this would result in a 64s wait time in the worst case. -h3. 3.5. Neighbor Interface Purging Recommendations +h3. 3.6. Neighbor Interface Purging Recommendations A node may purge a neighbor interface from its neighbor list when its RQ value reaches 0. However a node with RQ 0 may be kept in the list as long as desired, as it does not make a difference for the routing decisions because of the asymmetric link penalty (see [ogm|OGM protocol] for details). h2. 4. Proposed Values for Constants -* _WINDOW_SIZE_: 2^32 +* _WINDOW_SIZE_: 64 +* _SEQNO_SIZE_: 2^32 +* _OUTDATED_MAX_: 4 ----

1 0

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

14 Jul '17

1 0

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

14 Jul '17

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Uevent (3e3eadc3)
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 3e3eadc3f5304f41f1445d1d76db108105d8cafd Author: Marek Lindner <mareklindner(a)neomailbox.ch> Date: Mon Jul 4 15:48:31 2011 +0000 doc: batman-adv/Uevent >--------------------------------------------------------------- 3e3eadc3f5304f41f1445d1d76db108105d8cafd batman-adv/Uevent.textile | 66 ++++++++++++++++++++++++++++++----------------- 1 file changed, 42 insertions(+), 24 deletions(-) diff --git a/batman-adv/Uevent.textile b/batman-adv/Uevent.textile index 82d1b34e..d9722ff7 100644 --- a/batman-adv/Uevent.textile +++ b/batman-adv/Uevent.textile @@ -1,38 +1,56 @@ h1. Uevent -B.A.T.M.A.N.-Advanced can now throw uevents (asynchronous signals sent by the kernel to the userspace - CHECK). +B.A.T.M.A.N.-Advanced can throw uevents (asynchronous signals sent by the kernel to the user space) to inform the user space about certain events happening in the mesh. User space applications can listen to these messages and take action depending on the event, thus allowing a tight interaction between the kernel mesh and all sorts of applications. -Thanks to this new feature it is possible to advertise any kind of message to the usespace. -This will probably enable several user applications to interact with B.A.T.M.A.N.-Advanced and obtain results different to achieve before. -In the code a new function has been defined that can be used for the purpose above. +h2. How to capture uevents ? -*Function prototype:* -<pre>int throw_uevent(struct bat_priv *bat_priv, enum uev_type type, - enum uev_action action, const char *data);</pre> +A various tools exist which allow to capture events generated by the kernel, for example udev, udev_adm or hotplug. These tools listen to all incoming uevents and often offer a scriptable interface to parse the messages. A batman-adv generated event could looks like this: -*Arguments explained:* -* type: is the class the uevent belongs to. It is possible to specify new classes into B.A.T.M.A.N. to distinguish between not related uevents -* action: is the class related event that has to be signaled -* data: any meaningful payload that need to be sent to the userspace +<pre> +ACTION = change +DEVPATH = /devices/virtual/net/bat0 +DEVICENAME = bat0 +SUBSYSTEM = net +BATTYPE = gw +BATACTION = del +INTERFACE = bat0 +IFINDEX = 6 +SEQNUM = 613 +</pre> -*Example:* -* type: GW -* action: ADD/CHANGE/DEL -* data: the gateway MAC address +Each event comes with an automatically created sequence number (SEQNUM). The batman-adv module always sets the ACTION parameter to "change" and the SUBSYSTEM to "net". DEVPATH, DEVICENAME, INTERFACE and IFINDEX point to the corresponding batX interface. Next to these standard uevent values which are part of every uevent message, batman-adv adds its own parameters with the prefix "BAT". Details regarding these parameters can be found below. + + +h2. Gateway uevents -This is an example of a class of possible uevents to throw to userspace. In case of default gateway change, a uevent is triggered and sent to the userspace with all the needed data. The action field, in this case, represent the event related to the gateway (e.g. ADD: a default gateway for B.A.T.M.A.N. has been found). +When a batman-adv node is in gateway client mode (searching for gateway servers - check [[Gateways|the gateway documentation]] for thorough explanations) it will inform the user space about its gateway mode state changes: Sending an "add message" when the first gateway is chosen, a "change message" when a better gateway was found and a "delete message" when the currently selected gateway vanished and no alternative was available. -*Userspace interaction:* +In detail: +* BATTYPE: Always set to "GW" for gateway related messages. +* BATACTION: Set to "ADD", "CHANGE" or "DEL". +* BATDATA: When BATACTION is set to ADD or CHANGE it contains the mac address of the selected gateway otherwise the parameter is not sent. -Uevents are thown by means of the already existent mesh kobject which usually resides at the path: +A script running in user space could start a dhcp client as soon as an "add message" comes in and make the dhcp client request a new IP address when a "change message" is received to ensure it always uses the currently selected batman-adv gateway. -<pre>/sys/class/net/${SOFT_IFACE}</pre> -Each event will carry three variables which represents the arguments passed to the _throw_uevent()_ function in the batman-adv code. In particular the variables are: -* BATTYPE - containing the string corresponding to the value of _enum uev_type type_ -* BATACTION - containing the string corresponding to the value of _enum uev_action action_ -* BATDATA - containing the string _const char *data_ +h2. How to add my own uevents to batman-adv ? +The code contains a function to make adding new uevents as easy as possible. -The first two variables will contain the string defined respectively into _static char *uev_action_str[]_ and _static char *uev_type_str[]_ (decleared in bat_sysfs.h) while the last one will be directly passed as provided to the function. \ No newline at end of file +Function prototype: +<pre> +int throw_uevent(struct bat_priv *bat_priv, enum uev_type type, + enum uev_action action, const char *data); +</pre> + +Arguments explained: +* bat_priv: The pointer to the soft-interface structure holding all relevant batX information. +* type: Is the class the uevent belongs to (seen as BATTYPE in user space). +* action: Defines the event's action (seen as BATACTION in user space). +* data: Any meaningful payload that need to be sent to the userspace. + +Example: +* type: GW +* action: ADD/CHANGE/DEL +* data: the gateway MAC address

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Uevent (7b503d3f)
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 7b503d3f387a9adcd28165e7c31bac1fc6cbdc23 Author: Antonio Quartulli <a(a)unstable.cc> Date: Mon Jul 4 10:42:10 2011 +0000 doc: batman-adv/Uevent >--------------------------------------------------------------- 7b503d3f387a9adcd28165e7c31bac1fc6cbdc23 batman-adv/Uevent.textile | 1 + 1 file changed, 1 insertion(+) diff --git a/batman-adv/Uevent.textile b/batman-adv/Uevent.textile index 7aae960b..82d1b34e 100644 --- a/batman-adv/Uevent.textile +++ b/batman-adv/Uevent.textile @@ -34,4 +34,5 @@ Each event will carry three variables which represents the arguments passed to t * BATACTION - containing the string corresponding to the value of _enum uev_action action_ * BATDATA - containing the string _const char *data_ + The first two variables will contain the string defined respectively into _static char *uev_action_str[]_ and _static char *uev_type_str[]_ (decleared in bat_sysfs.h) while the last one will be directly passed as provided to the function. \ No newline at end of file

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/SubmittingLinux: Fix format bug (496cdd25)
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 496cdd25d3cc337c55d51e70b07f9c7ad4b5ea3f Author: Sven Eckelmann <sven(a)narfation.org> Date: Mon Jul 4 17:13:05 2011 +0000 doc: batman-adv/SubmittingLinux: Fix format bug >--------------------------------------------------------------- 496cdd25d3cc337c55d51e70b07f9c7ad4b5ea3f batman-adv/SubmittingLinux.textile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/batman-adv/SubmittingLinux.textile b/batman-adv/SubmittingLinux.textile index cec2c27e..ee156deb 100644 --- a/batman-adv/SubmittingLinux.textile +++ b/batman-adv/SubmittingLinux.textile @@ -297,7 +297,7 @@ Applying: batman-adv: Add include guards to all header files h2. check if all patches build again with linux next -It must be checked whether it builds with allnoconfig (+NET,+CRC16,+/-MODULES) as module/builtin and allyesconfig as module/builtin +It must be checked whether it builds with allnoconfig (@+NET@,@+CRC16@,@+/-MODULES@) as module/builtin and allyesconfig as module/builtin <pre> '-(%25)-(davem)> make

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/SubmittingLinux: add missing CONFIG_MODULES for linux-next test (1ac2555b)
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 1ac2555b043084a30ee866c878f01a8ea888058a Author: Sven Eckelmann <sven(a)narfation.org> Date: Mon Jul 4 17:16:26 2011 +0000 doc: batman-adv/SubmittingLinux: add missing CONFIG_MODULES for linux-next test >--------------------------------------------------------------- 1ac2555b043084a30ee866c878f01a8ea888058a batman-adv/SubmittingLinux.textile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/batman-adv/SubmittingLinux.textile b/batman-adv/SubmittingLinux.textile index ee156deb..b6cfe405 100644 --- a/batman-adv/SubmittingLinux.textile +++ b/batman-adv/SubmittingLinux.textile @@ -208,7 +208,7 @@ Successfully rebased and updated refs/heads/patches h2. check if all patches compile cleanly against the current version of linux-next and sparse (cgcc) -We assume that the linux-next tree was already build with @make allnoconfig@ and then enabling @CONFIG_NET=y@ and @CONFIG_CRC16=y@ +We assume that the linux-next tree was already build with @make allnoconfig@ and then enabling @CONFIG_NET=y@, @CONFIG_MODULES=y@ and @CONFIG_CRC16=y@ <pre> '-(%25)-(patches)> git rev-list --reverse origin/merge/master..

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Uevent (dda19f69)
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 dda19f692a3418e692c5af7414d6ac79f08f6f40 Author: Antonio Quartulli <a(a)unstable.cc> Date: Mon Jul 4 16:02:04 2011 +0000 doc: batman-adv/Uevent >--------------------------------------------------------------- dda19f692a3418e692c5af7414d6ac79f08f6f40 batman-adv/Uevent.textile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/batman-adv/Uevent.textile b/batman-adv/Uevent.textile index d9722ff7..92d8a309 100644 --- a/batman-adv/Uevent.textile +++ b/batman-adv/Uevent.textile @@ -5,7 +5,7 @@ B.A.T.M.A.N.-Advanced can throw uevents (asynchronous signals sent by the kernel h2. How to capture uevents ? -A various tools exist which allow to capture events generated by the kernel, for example udev, udev_adm or hotplug. These tools listen to all incoming uevents and often offer a scriptable interface to parse the messages. A batman-adv generated event could looks like this: +Various tools exist which allow to capture events generated by the kernel, for example udev, udev_adm or hotplug. These tools listen to all incoming uevents and often offer a scriptable interface to parse the messages. A batman-adv generated event could look like this: <pre> ACTION = change

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/OGM: One more description for the router purging part (6839813e)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/OGM (32fd2cb0)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

commits July 2017