B.A.T.M.A.N June 2009

b.a.t.m.a.n@lists.open-mesh.org

14 participants
26 discussions

by Outback Dingo

see pastebin http://www.pastebin.ca/1194874 pertinent info dmesg | grep 'batgat loaded' batgat: [init_module:96] batgat loaded rv1025 uname -a Linux nightwing 2.6.23.16 #16 Tue Apr 22 20:00:17 ART 2008 mips unknown root@nightwing:~# batmand -v WARNING: You are using the unstable batman branch. If you are interested in *using* batman get the latest stable release ! B.A.T.M.A.N. 0.3-beta (compatibility version 5) lsmod Module Size Used by Tainted: P sch_htb 14048 2 ath_ahb 103616 0 wlan_xauth 480 0 wlan_wep 4000 0 wlan_tkip 9856 0 wlan_ccmp 5440 2 wlan_acl 1920 0 ath_rate_minstrel 8352 1 ath_hal 136832 3 ath_ahb,ath_rate_minstrel wlan_scan_sta 8768 1 wlan_scan_ap 6656 0 wlan 152464 10 ath_ahb,wlan_xauth,wlan_wep,wlan_tkip,wlan_ccmp,wlan_acl,ath_rate_minstrel,wlan_scan_sta,wlan_scan_ap batgat 10944 1 ipt_iprange 672 0 ipt_TOS 832 0 ipt_TTL 928 0 xt_MARK 960 3 ipt_ECN 1472 0 xt_CLASSIFY 640 0 ipt_ttl 704 0 ipt_tos 544 0 ipt_time 1568 0 xt_tcpmss 1088 0 xt_statistic 832 0 xt_mark 672 7 xt_mac 736 3 xt_length 736 0 ipt_ecn 1024 0 xt_DSCP 1056 0 xt_dscp 832 0 imq 2096 0 ipt_IMQ 672 2 xt_string 896 0 xt_layer7 9840 0 ipt_ipp2p 6784 0 ipt_LOG 4640 0 xt_CHAOS 1792 0 xt_DELUDE 2624 1 xt_TARPIT 2816 1 xt_quota 800 0 xt_portscan 2016 0 xt_pkttype 704 0 xt_physdev 1488 0 ipt_owner 800 0 iptable_raw 832 0 xt_NOTRACK 832 0 xt_CONNMARK 1088 0 ipt_recent 4992 0 xt_helper 992 0 xt_conntrack 1312 0 xt_connmark 832 0 xt_connbytes 1312 0 tun 6592 0

13 years, 10 months

[B.A.T.M.A.N.] originators says yes, batping says no

by Jacob Marble

I have three nodes running OpenWrt r16484 (SVN) and batman-advanced r1298. All nodes show each other in originators. batping gets host unreachable for all relationships, and the host unreachable messages come very quickly, maybe 1000/second. Here is a log sample, log_level 4. log_level 11 doesn't show anything. The setup I'm using worked fine with r1176. Using ahdemo. [ 42949625] Received BATMAN packet via NB: 00:15:6d:a7:6a:9e, IF: ath0 [00:15:6d:a7:6a:9c] (from OG: 00:15:6d:a7:6a:9e, via old OG: 00:15:6d:a7:6a:9e, seqno 214, tq 255, TTL 50, V 7, IDF 0) [ 42949625] updating last_seqno: old 213, new 214 [ 42949625] bidirectional: orig = 00:15:6d:a7:6a:9e neigh = 00:15:6d:a7:6a:9e => own_bcast = 64, real recv = 64, local tq: 255, asym_penality: 255, total tq: 255 [ 42949625] update_originator(): Searching and updating originator entry of received packet [ 42949625] Updating existing last-hop neighbour of originator [ 42949625] Forwarding packet: tq_orig: 255, tq_avg: 255, tq_forw: 250, ttl_orig: 49, ttl_forw: 49 [ 42949625] Forwarding packet: rebroadcast neighbour packet with direct link flag [ 42949625] Sending own packet (originator 00:15:6d:a7:6a:9c, seqno 216, TQ 255, TTL 50, IDF off) on interface ath0 [00:15:6d:a7:6a:9c] [ 42949625] Received BATMAN packet via NB: 00:15:6d:a7:6a:14, IF: ath0 [00:15:6d:a7:6a:9c] (from OG: 00:15:6d:a7:6a:9e, via old OG: 00:15:6d:a7:6a:9e, seqno 214, tq 240, TTL 49, V 7, IDF 1) [ 42949625] bidirectional: orig = 00:15:6d:a7:6a:9e neigh = 00:15:6d:a7:6a:14 => own_bcast = 63, real recv = 64, local tq: 251, asym_penality: 255, total tq: 236 [ 42949625] update_originator(): Searching and updating originator entry of received packet [ 42949625] Updating existing last-hop neighbour of originator [ 42949625] Drop packet: duplicate packet received [ 42949625] Forwarding packet (originator 00:15:6d:a7:6a:9e, seqno 214, TQ 240, TTL 49, IDF on) on interface ath0 [00:15:6d:a7:6a:9c] [ 42949625] Received BATMAN packet via NB: 00:15:6d:a7:6a:9e, IF: ath0 [00:15:6d:a7:6a:9c] (from OG: 00:15:6d:a7:6a:9c, via old OG: 00:15:6d:a7:6a:9c, seqno 216, tq 236, TTL 49, V 7, IDF 1) [ 42949625] Drop packet: originator packet from myself (via neighbour) [ 42949625] Received BATMAN packet via NB: 00:15:6d:a7:6a:14, IF: ath0 [00:15:6d:a7:6a:9c] (from OG: 00:15:6d:a7:6a:9c, via old OG: 00:15:6d:a7:6a:9c, seqno 216, tq 240, TTL 49, V 7, IDF 1) [ 42949625] Drop packet: originator packet from myself (via neighbour) [ 42949625] Received BATMAN packet via NB: 00:15:6d:a7:6a:14, IF: ath0 [00:15:6d:a7:6a:9c] (from OG: 00:15:6d:a7:6a:14, via old OG: 00:15:6d:a7:6a:14, seqno 205, tq 255, TTL 50, V 7, IDF 0) [ 42949625] updating last_seqno: old 204, new 205 [ 42949625] bidirectional: orig = 00:15:6d:a7:6a:14 neigh = 00:15:6d:a7:6a:14 => own_bcast = 64, real recv = 64, local tq: 255, asym_penality: 255, total tq: 255 [ 42949625] update_originator(): Searching and updating originator entry of received packet [ 42949625] Updating existing last-hop neighbour of originator [ 42949625] Forwarding packet: tq_orig: 255, tq_avg: 254, tq_forw: 250, ttl_orig: 49, ttl_forw: 49 [ 42949625] Forwarding packet: rebroadcast neighbour packet with direct link flag [ 42949625] Received BATMAN packet via NB: 00:15:6d:a7:6a:9e, IF: ath0 [00:15:6d:a7:6a:9c] (from OG: 00:15:6d:a7:6a:14, via old OG: 00:15:6d:a7:6a:14, seqno 205, tq 240, TTL 49, V 7, IDF 1) [ 42949625] bidirectional: orig = 00:15:6d:a7:6a:14 neigh = 00:15:6d:a7:6a:9e => own_bcast = 64, real recv = 64, local tq: 255, asym_penality: 255, total tq: 240 [ 42949625] update_originator(): Searching and updating originator entry of received packet [ 42949625] Updating existing last-hop neighbour of originator [ 42949625] Drop packet: duplicate packet received [ 42949625] Forwarding packet (originator 00:15:6d:a7:6a:14, seqno 205, TQ 240, TTL 49, IDF on) on interface ath0 [00:15:6d:a7:6a:9c]

13 years, 11 months

[B.A.T.M.A.N.] about: BATMAN algorithm ?

by linuxer

hello, at http://www.open-mesh.net/wiki/BranchesExplained you say, batman 0.3 is the latest stable implementation, using a new version of the algorithm known as the BATMAN IV/TQ algorithm. Where is the document which describes the BATMAN IV/TQ algorithm in detail?

13 years, 11 months

[B.A.T.M.A.N.] [PATCH] [batman-adv] Convert to new net_device_ops

by Sven Eckelmann

The current version of batman-adv-kernelland uses the netdevice structure instead of netdevice ops introduced by v2.6.28-rc5-510-gd314774. The compatibility version was removed in v2.6.30-rc6-851-ge3804cb. We need to change now change to this new structure to be able to compile it against linux-2.6.31. Signed-off-by: Sven Eckelmann <sven.eckelmann(a)gmx.de> --- batman-adv-kernelland/soft-interface.c | 17 +++++++++++++++++ 1 files changed, 17 insertions(+), 0 deletions(-) diff --git a/batman-adv-kernelland/soft-interface.c b/batman-adv-kernelland/soft-interface.c index bb95501..4600017 100644 --- a/batman-adv-kernelland/soft-interface.c +++ b/batman-adv-kernelland/soft-interface.c @@ -31,6 +31,7 @@ #include "hash.h" #include <linux/ethtool.h> #include <linux/etherdevice.h> +#include "compat.h" @@ -98,6 +99,18 @@ int my_skb_push(struct sk_buff *skb, unsigned int len) return 0; } +#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 29) +static const struct net_device_ops bat_netdev_ops = { + .ndo_open = interface_open, + .ndo_stop = interface_release, + .ndo_get_stats = interface_stats, + .ndo_set_mac_address = interface_set_mac_addr, + .ndo_change_mtu = interface_change_mtu, + .ndo_start_xmit = interface_tx, + .ndo_validate_addr = eth_validate_addr +}; +#endif /* LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 29) */ + void interface_setup(struct net_device *dev) { struct bat_priv *priv = netdev_priv(dev); @@ -105,12 +118,16 @@ void interface_setup(struct net_device *dev) ether_setup(dev); +#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 29) dev->open = interface_open; dev->stop = interface_release; dev->get_stats = interface_stats; dev->set_mac_address = interface_set_mac_addr; dev->change_mtu = interface_change_mtu; dev->hard_start_xmit = interface_tx; +#else + dev->netdev_ops = &bat_netdev_ops; +#endif /* LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 29) */ dev->destructor = free_netdev; dev->features |= NETIF_F_NO_CSUM; -- 1.6.3.1

13 years, 11 months

Re: [B.A.T.M.A.N.] originator tq_avg oscilations

by Andrew Lunn

> If you are willing to test a few things to reduce the effect we can > start right away. You could set TQ_GLOBAL_WINDOW_SIZE to 1 in order > to deactivate the averaging of the TQ values. Aslo, some people > reported that reducing the hop penalty also will increase the speed. I already tried changing TQ_GLOBAL_WINDOW_SIZE to 5 instead of 10 and that helped. Changing it to one is interesting. I've not tried it yet, but i would of thought some ring buffer was needed to handle the 0s which are added when originator messages are received for other neighbors. I already tried reducing the hop penalty. However testing showed it behaved worse. This i don't understand. So i'm guessing my test setup changed between my different tests. So i need to run the test again, both the control and the modified hop penalty. What ideas do you have for improving the algorithms. Depending on the scale of work needed i might have some time to do some coding. Andrew

13 years, 11 months

[B.A.T.M.A.N.] Recommended Reading for those that want to get involved with B.A.T.M.A.N.

by Andrew de Andrade

Dear all, I've been signed up to the list for a few weeks now and I was wondering if you guys could recommend a reading list for those who would like to get involved with B.A.T.M.A.N. I'm currently halfway through "Computer Networking: A Top Down Approach" by James F. Kurose and Keith W. Ross, however it is only provides a general theoretical overview of networking as it exists today. Mesh networking is something far more advanced, so I was wondering if there were particular textbooks, journal articles and other material that members of this list could recommend. Recommend anything and everything that you guys think is relevant, both directly and indirectly. thx! Andrew

13 years, 11 months

[B.A.T.M.A.N.] ring buffer average function...

by Andrew Lunn

Hi Folks Can somebody explain why this function works the way it does: uint8_t ring_buffer_avg(uint8_t lq_recv[]) { uint8_t *ptr; uint16_t count = 0, i = 0, sum = 0; ptr = lq_recv; while (i < TQ_GLOBAL_WINDOW_SIZE) { if (*ptr != 0) { count++; sum += *ptr; } i++; ptr++; } if (count == 0) return 0; return (uint8_t)(sum / count); } It only averages over the none zero values. The code filling these ring buffer puts a zero in whenever an originator message is received from another neighbor. When the originator message is from this neighbor, the tq in the originator message is put in. When a neighbor is dead, the ring slowly fills with 0's, whenever there is an originator message from one of the other neighbors. However since the 0 are ignored when calculating the average, we tend to have a cliff effect for dead neighbors. There tq_avg stays about the same for quite a while, and then plummets to 0. For faster detecting dead neighbors, it would be better if the 0 were included in the average. The tv_avg would then drop more linearly, not cliff like, so it is likely to cross below another neighbors tv_avg earlier, so re-routing around the dead node faster. Before i change this function, i just want to understand why it is like this, and what i'm likely to break :-( Thanks Andrew

13 years, 11 months

[B.A.T.M.A.N.] originator tq_avg oscilations

by Andrew Lunn

Hi Folks I've been playing with B.A.T.M.A.N advanced for a few weeks now. One of the scenarios where we might want to use it is nomadic vehicles. Each vehicle has a wifi radio which is used to build a mesh between the vehicles when the vehicles are parked together at a location. I said the vehicles are nomadic. By that i mean they tend to stay in one place for a while, and then move on. They can move individually, or in groups. For the moment we are not interested in meshing while on the move. I've run into a "problem" when one vehicle/node moves away from the rest of the vehicles/nodes. It is taking a long time for the mesh to realize the node has gone and rebuild the mesh. With a 500ms orig_interval in our little test network, pings get lost for an average of 26 seconds. The variation is great, sometimes it reroutes in 10 seconds, sometimes in 50 seconds. So i want to improve this. The first thing i did was make some plots of the tq_avg value, as shown in /proc/net/batman-adv/originators. I look at one particular originator and plot the different tq_avg values for the list of neighbors. Attaches is a png image showing this. I was surprised to see that its unstable and oscillating. The different tq_avg values mostly oscillate together, as shown in the figure, but i've also seen cases when they oscillate 180 degrees out of phase. In that case, the routing flips on the cross overs. Is this normal? Is it expected behavior? Has anybody worked on making re-routing around disappears nodes faster? Thanks Andrew

13 years, 11 months

[B.A.T.M.A.N.] Oscilations....

by Andrew Lunn

Ups, forgot the attachment with the plot :-( Andrew

13 years, 11 months

[B.A.T.M.A.N.] Clarification of version number in batctl/main.h

by Sven Eckelmann

Hi, I just wanted to ask how to interpret the current version number of batctl. Does it mean that the current version in svn is before or after a possible 0.2-beta release? Is it important for me because debian differentiates between before and after something. For example 0.2~beta would mean that there is a beta version before the 0.2 release. So I wanted to know if should call a svn snapshot of the current batctl 0.2~beta~svn1317 (svn1317 snapshot before a possible 0.2~beta release) or 0.2~beta+svn1317 (svn1317 snapshot after the beta phase has started - no beta version will ever be made available or has been released already). It seems that the 0.2~beta~svn1317 is the more "correct" version as it has less extra rules than 0.2~beta+svn1317. For example there must not be an extra rule for events like the release of 0.3.1 of batman when Simon changed the version string to 0.3.1 in 1177 which was before the release of 0.3.1 and thus shouldn't be called 0.3.1+svn1177. Can this be interpreted the same way for all other on open-mesh.net published hosted projects? So if I would create a snapshot version of batman it would have the version number 0.4~beta~svn1309? Regards, Sven

13 years, 11 months

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

B.A.T.M.A.N June 2009