B.A.T.M.A.N October 2011

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

14 participants
43 discussions

[B.A.T.M.A.N.] Fwd: angry batman after sleep

by Sven Eckelmann

Hi, following message was send to the mailing list, but exceeded the size limit (200KB vs. 1520KB). I've manipulated the mail to reduce the image quality. I hope that this is ok for the original author. Kind regards, Sven

11 years, 5 months

[B.A.T.M.A.N.] Warning - packet contains unknown ether type: 0x86dd

by Filippo Sallemi

Hi, I dont understand why but some time my nodes show msg: Warning - packet contains unknown ether type: 0x86dd when exec batctl td wlan0. Can anyone tell me what mean? and if it is as problem how to fix. Rgds -- Filippo Sallemi

11 years, 5 months

[B.A.T.M.A.N.] pull request: batman-adv 2011-10-18 (more regression fixes)

by Marek Lindner

Hi David, we have identified and fixed 2 more critical bugs in the linux-3.1 code base. We are somewhat late in the 3.1 release cycle but hoped to take advantage of the delayed release to get these patches included before the final version is out. If not I will have to send these patches to stable@ and would like to see these patches applied to net-next-2.6/3.2. No merge conflicts are to be expected. Let us know what works best for you. Thanks, Marek The following changes since commit 8b267b312df9343fea3bd679c509b36214b5a854: batman-adv: do_bcast has to be true for broadcast packets only (2011-09-22 20:27:10 +0200) are available in the git repository at: git://git.open-mesh.org/linux-merge.git batman-adv/maint Antonio Quartulli (2): batman-adv: fix tt_local_reset_flags() function batman-adv: correctly set the data field in the TT_REPONSE packet net/batman-adv/translation-table.c | 7 ++++++- 1 files changed, 6 insertions(+), 1 deletions(-)

11 years, 5 months

[B.A.T.M.A.N.] batman-adv 2011.3.1 released

by Marek Lindner

Today, the B.A.T.M.A.N. team releases an update for the 2011.3.0 release which corrects small but crucial bugs introduced within the last release. This is a pure bug fix release without any new features or protocol modifications. Everyone is strongly encouraged to upgrade to this version. As the kernel module always depends on the Linux kernel it was compiled against, it does not make sense to provide binaries on our website. As usual, you will find the signed tarballs in our download section: http://downloads.open-mesh.org/batman/releases/batman-adv-2011.3.1/ as well as prepackaged binaries in your distribution. Thanks ------ Thanks to all people sending in patches: * Antonio Quartulli <ordex(a)autistici.org> Special thanks go to: * TY Wu for isolating / debugging the packet latency bug * Junkeun Song for his help and ideas to find the translation table bugs * Marek Lindner for debugging support and suggestions batman-adv ---------- The high latency (4-5 times higher than usual) that could be observed when the gateway mode was activated because batman-adv broadcasted all packets instead of sending them via unicast, was fixed. The reported issues with non-mesh clients communicating with other clients have been addressed too: The translation tables were corrupted caused by uninitialized memory and invalid table sizes sent through client announcement mechanism. batctl ------ batctl remains unchanged. Happy routing, The B.A.T.M.A.N. team

11 years, 5 months

Re: [B.A.T.M.A.N.] batman-adv 2011.3.1 released

by Sven Eckelmann

Please always try to send your mails to the mailing list. Otherwise the person with the right knowledge may not be able to participate. On Wednesday 19 October 2011 11:15:51 Michael Stöcker wrote: [...] > its not "my" makefile, its the default openwrt-batman-adv-makefile... > then i have to wait till somebody who is better involved in > makefile-stuff makes a patch/new makefile ;) I just forward Mareks answer to the question: https://dev.openwrt.org/changeset/28490 > i just think that the current tarballnaming is inconsistent, i > personally expect in a folder named /releases/batman-adv-2011.3.1/ > tarballs of version 2011.3.1 ;) There is no 2011.3.1 version of batctl. We decided a long time ago that we want to mark compatible versions in the release folders and keep batctl and batman-adv separate. That means that we don't want to force 0-change releases of one tool. My initial idea was also to name the release folders only 2011.3 and only link the current stable releases into those folders. I don't know whether there were other opinions or we forgot to talk more about it. The reason why I asked about the x.org folks is the similarity between the strategies they use and the one we now try to follow (actually, I looked at their release style and kept it in some other open source projects). What is your opinion regarding the 2011.3 name for the release folder and would it help in understanding that batctl and batman-adv are separate parts which only get common releases from time to time? Kind regards, Sven

11 years, 5 months

[B.A.T.M.A.N.] batman-adv 2011.2.0 hop somtimes does not work

by Tobias

Hi all, i have setup a mesh-network with batman-adv running on about 10 Foneras and 4 TP-Link on OpenWRT. At first everything seemed to work. A node on the one end could ping a node on the other end over the mesh-network. The ping was hopping from node to node as expected. But sometimes some paths do not work anymore. Some nodes can only reach their direct neighbors via a "normal ping". A ping to a node via one hop does not work. A "batctl ping" does work! This only happens to parts of the network and is not permanent. If i wait it will recover, but then the problem appears at another node. dmesg or the syslog does not report any errors. Can anyone give me a hint where to look? Tobias

11 years, 5 months

Re: [B.A.T.M.A.N.] Compile error on openwrt with new patch

by Sven Eckelmann

---------- Forwarded Message ---------- Subject: Re: Re: [B.A.T.M.A.N.] Compile error on openwrt with new patch Date: Tuesday 18 October 2011, 21:11:51 From: Filippo Sallemi <tonyputi(a)gmail.com> To: Sven Eckelmann <sven(a)narfation.org> Ok but i'm using backfire 10.03 with "package" url of feeds.default.conf and in this version the makefile is for batman-adv 2011.2.0. in my feeds.conf.default i have: src-svn packages svn://svn.openwrt.org/openwrt/branches/packages_10.03.1 svn://svn.openwrt.org/openwrt/packages and in svn://svn.openwrt.org/openwrt/branches/packages_10.03.1 there is batman-adv 2011.2.0 package. It is a openwrt problem? my feeds.conf.default is the original openwrt conf. Rgds 2011/10/18 Sven Eckelmann <sven(a)narfation.org>: > On Tuesday 18 October 2011 20:57:53 Filippo Sallemi wrote: > [...] >> > Please create a new checkout of openwrt, add the feed, add batman-adv to >> > the config and build it with V=99 (the clean checkout not an old one). >> > Add the .config and the log to you mail. >> > >> > Thanks, >> > Sven >> >> This is my make V=99 output after make distclean and however a fresh >> checkout of openwrt. > > No, that wasn't what I asked for. > >> >> make[3]: Entering directory >> `/home/fsallemi/Develop/backfire/feeds/packages/net/batman-adv' >> gzip -dc /home/fsallemi/Develop/backfire/dl/batman-adv-2011.2.0.tar.gz > > What is that? 2011.3.0 with patches from 2011.3.0... this will _not_ work. > >> >> | /bin/tar -C >> | /home/fsallemi/Develop/backfire/build_dir/target-mips_r2_uClibc-0.9.30. >> | 1/batman-adv/batman-adv-2011.2.0/.. >> >> -xf - >> >> Applying >> ./patches/batman-adv_correctly_set_the_data_field_in_the_TT_REPONSE_packet. >> patch using plaintext: >> patching file translation-table.c >> Hunk #1 FAILED at 1054. >> Hunk #2 succeeded at 632 with fuzz 2 (offset -448 lines). >> 1 out of 2 hunks FAILED -- saving rejects to file translation-table.c.rej >> Patch failed! Please fix >> ./patches/batman- adv_correctly_set_the_data_field_in_the_TT_REPONSE_packet.p >> atch! make[3]: *** > > This is a patch for 2011.3.0 and not for 2011.2.0 > >> [/home/fsallemi/Develop/backfire/build_dir/target-mips_r2_uClibc-0.9.30.1/b >> atman-adv/batman-adv-2011.2.0/.prepared_d634b3efc2524a3909e7512491480870] >> Error 1 > > This says 2011.2.0 > > [,,,] > > Kind regards, > Sven -- Filippo Sallemi -----------------------------------------

11 years, 5 months

Re: [B.A.T.M.A.N.] Compile error on openwrt with new patch

by Sven Eckelmann

On Tuesday 18 October 2011 20:57:53 Filippo Sallemi wrote: [...] > > Please create a new checkout of openwrt, add the feed, add batman-adv to > > the config and build it with V=99 (the clean checkout not an old one). > > Add the .config and the log to you mail. > > > > Thanks, > > Sven > > This is my make V=99 output after make distclean and however a fresh > checkout of openwrt. No, that wasn't what I asked for. > > make[3]: Entering directory > `/home/fsallemi/Develop/backfire/feeds/packages/net/batman-adv' > gzip -dc /home/fsallemi/Develop/backfire/dl/batman-adv-2011.2.0.tar.gz What is that? 2011.3.0 with patches from 2011.3.0... this will _not_ work. > > | /bin/tar -C > | /home/fsallemi/Develop/backfire/build_dir/target-mips_r2_uClibc-0.9.30. > | 1/batman-adv/batman-adv-2011.2.0/.. > > -xf - > > Applying > ./patches/batman-adv_correctly_set_the_data_field_in_the_TT_REPONSE_packet. > patch using plaintext: > patching file translation-table.c > Hunk #1 FAILED at 1054. > Hunk #2 succeeded at 632 with fuzz 2 (offset -448 lines). > 1 out of 2 hunks FAILED -- saving rejects to file translation-table.c.rej > Patch failed! Please fix > ./patches/batman-adv_correctly_set_the_data_field_in_the_TT_REPONSE_packet.p > atch! make[3]: *** This is a patch for 2011.3.0 and not for 2011.2.0 > [/home/fsallemi/Develop/backfire/build_dir/target-mips_r2_uClibc-0.9.30.1/b > atman-adv/batman-adv-2011.2.0/.prepared_d634b3efc2524a3909e7512491480870] > Error 1 This says 2011.2.0 [,,,] Kind regards, Sven

11 years, 5 months

[B.A.T.M.A.N.] Compile error on openwrt with new patch

by Filippo Sallemi

Hi all, after an ./script/feeds update when i try to build openwrt I get an error on batman-adv package: Applying ./patches/batman-adv_correctly_set_the_data_field_in_the_TT_REPONSE_packet.patch using plaintext: patching file translation-table.c Hunk #1 FAILED at 1054. Hunk #2 succeeded at 632 with fuzz 2 (offset -448 lines). 1 out of 2 hunks FAILED -- saving rejects to file translation-table.c.rej Patch failed! Please fix ./patches/batman-adv_correctly_set_the_data_field_in_the_TT_REPONSE_packet.patch! Rgds -- Filippo Sallemi

11 years, 5 months

[B.A.T.M.A.N.] Unused structs in Catwoman packet buffers

by Martin Hundebøll

Hi all, I trying to figure out when to free an unused struct in the catwoman (network coding) packet buffer. Below I will try to describe the principal question, but it all comes down to: Should I use a timeout or just remove it right away. Heres a short description of the buffering in catwoman: When a packet arrive at a node and is to be forwarded, catwoman searches a hash-table for packets that can be combined with the just arrived packet. If a match is found, the two packets are combined and transmitted as one; if not, the just arrived packet is added to the buffer, so that the next arriving packet might be combined with it. To reduce the complexity when searching for packets in the hash table, hash indexes are generated from a key consisting of a mac-source XOR'ed with a mac-destination like this: int i; uint8_t key[ETH_ALEN]; for (i = 0; i < ETH_ALEN; i++) key[i] = src[i] ^ dst[ETH_ALEN-1-i]; This reduces complexity because catwoman needs only to search a few paths (src-dst-pairs) for possible matching packets. The reverse order of dst makes the key direction-specific. Each entry in a hash-bin-hlist is denoted a coding_path, which contains the src and dst of the path i question and a reference to list of packets. This list of packets, is where packets are buffered when waiting for a coding opportunity as described above. Every 10 ms, the hash table is traversed and packets that have been buffered for more than 10 ms are transmitted without being coded. (This gives an avarage buffer time of 15 ms, I know...) Now here's the question: When a list of a certain coding_path becomes empty, should I free the coding_path right away, or should I timestamp it and mark it for removal at a later time. The thing is that I don't know whether a new packet for the same coding_path will arrive in a short moment. If I have just freed the coding_path struct, I would have to spend ressources to initialize it again... It is probably a micro-optimiziation and the simplest solution would be to just free it right away, but I would like to have your comments anyways. -- Kind regards Martin Hundebøll +45 61 65 54 61 martin(a)hundeboll.net Nordborggade 57, 2. tv 8000 Aarhus C Denmark

11 years, 5 months

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

B.A.T.M.A.N October 2011