public inbox for b.a.t.m.a.n@lists.open-mesh.org
 help / color / mirror / Atom feed
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: Tue, 10 Jul 2007 11:10:37 +0200	[thread overview]
Message-ID: <200707101110.37087.axel@open-mesh.net> (raw)
In-Reply-To: <59806.85.41.146.90.1183999326.squirrel@krisma.oltrelinux.com>

Hello,

Before a batman configures a host route towards another node (and  
batmand -c -d 1 -b should tell you about all succesfull configured routes) it 
must learn about the existence of the other node via a bidirectional link.
Thus actually two things are checked:
1. the link (via which it received a message from the new node) must be 
bidirectional.
2. Receive an originator message from the new node (OGM).

In your case the node 6.17.190.172 (A) has not yet confirmed the first issue.
It received an OGM from node 6.17.0.1 (B) but not via a validated 
bidirectional link (not yet).
In order to consider a link bidirectional, node A checks if it has 
successfully received one of its self-initiated OGMs back from node B.
I suppose this has not happened so fare but (if the link between A and B is 
bidirectionsl) should happen within the next seconds. The line:
> ath0 Orginator timeout: originator 6.17.0.1, last_valid 0
which you are concerned about indicates exactly this fact. Recevied messages 
from another node are only valid if (besides other checks) they have been 
received via a bidirectional link. This one was not so its not valid. 
Otherwise last_valid should indicate the timestamp of the last validly 
recevied OGM from node B. 
Another line:
> Forward packet: rebroadcast neighbour packet with direct link and
> unidirectional flag
Indicates that node A rebroadcasts node Bs OGM anyway but with the 
unidirectional flag (UDF) set which tells all other neighbors except node B 
to ignore the message. Just node B now has the possibility to consider node A 
as a bidirectional neighbor because node A has successfully rebroadcasted its 
own OGM. Does that make sense?

ciao,
axel


On Monday 09 July 2007 18:42, a.anselmi@oltrelinux.com wrote:
> I'm testing batmand 0.2 in two hardware-different nodes:
> 6.17.0.1/8 is a Fonera running its standard firmware
> 6.17.190.172/8 is a Fonera running Kamikaze
>
> >From kamikaze(d) node I see:
>
> Received BATMAN packet via NB: 6.17.0.1, IF: ath0 6.17.190.172 (from OG:
> 6.17.0.1, seqno 926, TTL 50, V 3, UDF 0, IDF 0)
> Creating new originator: 6.17.0.1
> schedule_forward_packet():
> Forward packet: rebroadcast neighbour packet with direct link and
> unidirectional flag
> Forwarding packet (originator 6.17.0.1, seqno 926, TTL 49) on interface
> ath0 Orginator timeout: originator 6.17.0.1, last_valid 0
> update_routes()
>
> but the same node, issuing the command "batmand -c -d 1 -b" tells me "No
> batman nodes in range".
> I'm afraid of the message "Orginator timeout: originator 6.17.0.1" in the
> above lines... is this the problem?
>
> --
> Antonio
>
>
> _______________________________________________
> B.A.T.M.A.N mailing list
> B.A.T.M.A.N@open-mesh.net
> https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n

  reply	other threads:[~2007-07-10  9:10 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-09 16:42 [B.A.T.M.A.N.] originator timeout a.anselmi
2007-07-10  9:10 ` Axel Neumann [this message]
  -- strict thread matches above, loose matches on Subject: below --
2007-07-08  6:16 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
2007-07-08 15:34         ` 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=200707101110.37087.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