From: Axel Neumann <axel@open-mesh.net>
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 12:37:13 +0200 [thread overview]
Message-ID: <200707081237.14412.axel@open-mesh.net> (raw)
In-Reply-To: <2bda28cd0707080231g763465b3la57e0dbbf1d966ab@mail.gmail.com>
Hi,
thanks!
still
> > one observation according to your log files:
> > node2 (interface 10.1.1.1) never gets any of its own originator messages
> > back (rebroadcasted) from node6. Despite node2 receives OGMs from node6.
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.
> > I assume that node6 simply can not hear node2 (and maybe also others) and
> > therefore node6 can not rebroadcast OGMs from node2 (which is necessary
> > for the bidirectional link check). One reason for that might be, that the
> > netmask and broadcast address of the (alias) interfaces batman is using
> > on node2 and node6 are not identical. can you check that?
>
> node2:
> eth0.0 inet addr:10.0.1.3 Bcast:10.0.1.255 Mask:255.255.255.0
> wl0 inet addr:10.1.1.1 Bcast:10.1.1.255 Mask:255.255.255.0
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?
>
> node6:
> wl0 inet addr:10.1.1.33 Bcast:10.1.1.255 Mask:255.255.255.0
>
> node2 and node6 speak very well in wireless channel
ciao,
axel
next prev parent reply other threads:[~2007-07-08 10:37 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 [this message]
2007-07-08 12:03 ` Stefano Scipioni
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=200707081237.14412.axel@open-mesh.net \
--to=axel@open-mesh.net \
--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