From: "Stefano Scipioni" <stefano@one-b.it>
To: The list for a Better Approach To Mobile Ad-hoc Networking
<b.a.t.m.a.n@open-mesh.net>
Subject: Re: [B.A.T.M.A.N.] originator timeout
Date: Sun, 8 Jul 2007 14:03:38 +0200 [thread overview]
Message-ID: <2bda28cd0707080503l202ce059j335115cfd2fcc52e@mail.gmail.com> (raw)
In-Reply-To: <200707081237.14412.axel@open-mesh.net>
> according to the log file node2 behaves correct (despite the thing that node2
> generates a route to node6 within the first two seconds). At some point in
> time node2 purges node6 from its routing table because it could never
> validate the link between interface 10.1.1.1 and 10.1.1.33 as a bidirectional
> link. Can you generate another set of log files at node2 and node6
> simultaneously? So that we can identify whether node2 simply does not hear or
> node6 never re-broadcasts any originator messages (OGMs) send by node2.
They are in http://wifi.one-b.it/download/
> Hmm... actually another thing but:
> I see that on node2 the netmask and broadcast addresses for the two interfaces
> used by batman are different. I've never tried nor considered it that way -
> might work - but it is (imho) not the intended setup. With batman you
> can/should use the same netmask (and broadcast addresses) for all interfaces
> participating in the batman mesh. Otherwise you can get topology
> fractionation with which the protocol can not deal with automatically.
> Perhaps you can try to give ALL interfaces a 255.255.255.0 netmask and a
> 10.255.255.255 broadcast address?
I have disabled eth0.0 (batman only on interface wl0) on node2 and
same behavior: after a while route to node6 disappear.
I make another test with only 3 nodes: node2 with one interface (wl0),
node6 and node3
node2 (10.1.1.1) ------ node6 (10.1.1.33)
\
\--- node3 (10.1.1.10)
After 2 minutes with "batmand -g 0 -r 2 -d 1 wl0" on all 3 nodes:
node2
10.1.1.10 10.1.1.10 ( 67): 10.1.1.10 ( 67)
10.1.1.33 10.1.1.33 ( 21): 10.1.1.33 ( 21)
node6
10.1.1.10 10.1.1.1 ( 66): 10.1.1.1 ( 66)
10.1.1.1 10.1.1.1 (120): 10.1.1.1 (120)
node3
10.1.1.33 10.1.1.1 ( 20): 10.1.1.1 ( 20)
10.1.1.1 10.1.1.1 (121): 10.1.1.1 (121)
I suspect that batman does not hear some packets, maybe for wireless problems?
next prev parent reply other threads:[~2007-07-08 12:03 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-08 6:16 [B.A.T.M.A.N.] originator timeout Stefano Scipioni
2007-07-08 8:43 ` Axel Neumann
2007-07-08 9:31 ` Stefano Scipioni
2007-07-08 10:37 ` Axel Neumann
2007-07-08 12:03 ` Stefano Scipioni [this message]
2007-07-08 15:34 ` Axel Neumann
2007-07-15 12:43 ` [B.A.T.M.A.N.] B.A.T.M.A.N. in Mikrotik Router OS 3.0 - Meshing Made Easy elektra
2007-07-15 14:36 ` Alexander Morlang
2007-07-15 15:54 ` Daniel Poelzleithner
2007-07-16 7:06 ` Acinonyx
-- strict thread matches above, loose matches on Subject: below --
2007-07-09 16:42 [B.A.T.M.A.N.] originator timeout a.anselmi
2007-07-10 9:10 ` Axel Neumann
2007-07-08 6:06 Stefano Scipioni
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2bda28cd0707080503l202ce059j335115cfd2fcc52e@mail.gmail.com \
--to=stefano@one-b.it \
--cc=b.a.t.m.a.n@open-mesh.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox