Well, seems colmena is the uncooperative bathost another log: http://pastebin.com/FMD9Lieq that can be summarized as follows ### From COLMENA-CASA, can ping bochita but not ana ### From PEREYRA, can ping bochita but not ana ### From COLMENA, works perfect to both destinations colmena-casa and pereyra must pass through colmena, which is for some reason allowing batctl pings , ogms , and whatnot passthrough in its way to ana, but no ICMP echo requests, or tcp traffic whatsoever if it's final destination is ana. if final destination is bochita, everything works as expected. Any ideas? I'm going to delay rebooting colmena as long as i can, in case someone comes up with an insightful test to run :)

Gui

Recently we fixed a bug that which fix has not been released yet. If we are sure that this is the cause, you could eventually try an upgrade to a more recente dev-version. But let's see the log first (if possible)

Hi Marek! Just to confirm and avoid useless compiling PKG_VERSION:=2012.2.0 BATCTL_VERSION:=2012.2.0 PKG_MD5SUM:=68967ed1df709de18ab795722dde9341 BATCTL_MD5SUM:=7abd284098c514d3f2858e8a956c495e ~/trunk/feeds/packages/net/batman-adv$ svn info . Path: . URL: svn://svn.openwrt.org/openwrt/packages/net/batman-adv Repository Root: svn://svn.openwrt.org/openwrt Repository UUID: 3c298f89-4303-0410-b956-a3cf2f4a3e73 Revision: 32578 Node Kind: directory Schedule: normal Last Changed Author: marek Last Changed Rev: 32578 Last Changed Date: 2012-07-02 12:51:27 -0300 (Mon, 02 Jul 2012) Given the date and the author ;) I assume this rev should do the trick, right?

Resurrecting thread... On Mon, Jul 2, 2012 at 11:36 AM, Antonio Quartulli <ordex(a)autistici.org> wrote: Ah, I should have re-read this before :( Last week I came across this bug again, with the latest firm which includes the fixes mentioned, pushed by Marek. We were kinda in a hurry so i didn't have much time to check it thoroughly, so there's a *slim* chance it was just a coincidence, such as very poor signal giving erratic results. But if I recall correctly Nico Echaniz did stump on this too, using the latest firm.

So, although i can't confirm it 100%, it seems so far the fixes didn't help :( We'll keep an eye on it and try a "batctl l"

This time it solved itself after some brief time (a minute) but the symptoms were the same. So I could catch some logs, http://pastebin.com/MEENj94i sadly, i wasn't fast enough to get a live log from the node involved in the inconsistency as you suggested, so the report might be pretty useless.

On Sun, Jul 22, 2012 at 08:20:21AM -0300, Guido Iribarren wrote: Exactly! If the neighbour has the needed information, the node can directly get answered without bothering the real destination ;) Well, the log you posted is perfectly correct. You missed some OGMs, therefore the node is asking for an update that he missed. it would be interesting to run batctl ll tt; batctl l all the time on the node that usually experiences the "problem". The log should be not so big, unless the bug happens.

On Mon, Jul 02, 2012 at 06:39:49PM +0200, Gioacchino Mazzurco wrote: yeah, it was pretty much the same! I hope Guido can give us good results after testing the new patches :-) You may want to give them a try too?? :):)

Admittedly, using the older version, In my 25 node mesh, I have also wondered why nodes seemingly disappear without trace when doing a nmap. As L2 throughput still works I haven't bothered to investigate. On the upgrade note, Is there a way to upgrade to 2012 without reflashing the node?

Thanks Marek, Unfortunately all my nodes run one or other default openwrt version depending on ubnt/Mp/wrt driver compat . Would it maybe be viable to add a package to older versions of openwrt repo's i.e. Batman-adv-new_stable?

Same bug today in ninux pisa after a node was turned off the entire network became crazy for 2 hours, to solve i had to restart a lot of nodes... :|

On 07/02/12 15:30, Guido Iribarren wrote: > (which roughly translates as "batman gone nuts?") > Hey great devs! > we've been having a particular issue in deltalibre and quintanalibre > (local WCN) with batman-adv, but so far we haven't found a precise way > to reproduce it. > The symptom is that (after some reboots or physical displacements?) > one batman-adv host becomes unreachable on layer3, although it is seen > on originators table, and can be batctl ping'ed or batctl tracerout'ed > with no problem whatsoever. > > Even more, it not unreachable from the whole network, but instead from > just a few other nodes. So, let's say that the nearer nodes can layer3 > ping it , but some others farther away cannot (although i can't assure > it depends on the hop distance) > All of them can batctl ping it (layer2) > A hard reboot of all the nodes solves it, connectivity is restored in > all directions. > > Thing is, I've just came across it again, and managed to do some tests > to aid in description / debugging > As an aid in understanding network topology, > I'm attaching the wonderful output of "batctl vd dot |grep -v TT" for > your viewing delight > > problem node is ana > it can be reached from ruth and hquilla (direct neighbours) > but arping behaves erratically from colmena or charly > and normal ping (v4 or v6) doesn't receive any reply at all when run > from colmena or charly > > I used arping, with and without -b , and seemed like i could narrow > the problem down to incoming broadcast packet handling, but further > tests just left me more puzzled! > > all nodes are tl-mr3220 running openwrt trunk r31316 with batman-adv > 2012.2.0 , driver ath9k > secondary interfaces named _wlan1 are all tl-wn722n which uses driver ath9k_htc > nodes are around 100meters (+/-50mts) apart from each other > > this behaviour has been observed (but not reported) in dissimilar > setups, using ubnt bullet2 mixed with mr3220, running r29936 with > batman-adv 2011.4.0 , with nodes 1 or 2km apart from each other. > > Tests are the combined crude output of batctl td and arping, so to > make this email ease on the eye, i'm publishing them elsewhere: > http://pastebin.com/6PPwN3PS > > The live openwrt configuration can be analysed in detail at > https://bitbucket.org/guidoi/deltalibre-configs/src > (it's a free, open network after all! :D ) > in particular: > ana -> https://bitbucket.org/guidoi/deltalibre-configs/src/6de4ce970fe2/mac/54_E6_… > hquilla -> https://bitbucket.org/guidoi/deltalibre-configs/src/6de4ce970fe2/mac/54_E6_… > colmena -> https://bitbucket.org/guidoi/deltalibre-configs/src/6de4ce970fe2/mac/54_E6_… > > Thanks a lot for the attention, > Hope that you are having fun, and that I'm not spoiling it :) > > Cheers! > > Gui