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.
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.
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.
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:
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(-)
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:
as well as prepackaged binaries in your distribution.
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
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 remains unchanged.
The B.A.T.M.A.N. team
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:
> 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?
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?
---------- 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
in my feeds.conf.default i have:
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.
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: Entering directory
>> 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 -
>> 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
>> atch! make: ***
> This is a patch for 2011.3.0 and not for 2011.2.0
>> Error 1
> This says 2011.2.0
> Kind regards,
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: Entering directory
> 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 -
> 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
> atch! make: ***
This is a patch for 2011.3.0 and not for 2011.2.0
> Error 1
This says 2011.2.0
after an ./script/feeds update when i try to build openwrt I get an
error on batman-adv package:
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
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:
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.
+45 61 65 54 61
Nordborggade 57, 2. tv
8000 Aarhus C