From: Sven Eckelmann <sven@narfation.org>
To: b.a.t.m.a.n@lists.open-mesh.org
Cc: "Karan, Cem F CIV (US)" <cem.f.karan.civ@mail.mil>
Subject: Re: [B.A.T.M.A.N.] Batman, TTL, broadcast, etc. (UNCLASSIFIED)
Date: Tue, 04 Sep 2012 15:05:27 +0200 [thread overview]
Message-ID: <1522799.RKjDCIBmI1@bentobox> (raw)
In-Reply-To: <A677A9FB362B2F499BEFD6F80687FE972AF159C4@umechphe.easf.csd.disa.mil>
[-- Attachment #1: Type: text/plain, Size: 2070 bytes --]
On Tuesday 04 September 2012 12:48:00 Karan, Cem F CIV wrote:
[...]
> 1) I'm guessing from the following pages (which only describe roaming and
> announcement behaviors) that the TTL field of all packets is decremented by
> 1. Is this true?
> http://www.open-mesh.org/projects/batman-adv/wiki/Client-roaming
> http://www.open-mesh.org/projects/batman-adv/wiki/Client-announcement
TTL fields of the batman-adv specific TTL fields are decremented by one for
each hop.
> 2) Follow up to question 1; are the TTL fields of Batman packets and IP
> packets linked in some way? The library I'm using (zeromq,
> http://www.zeromq.org/) has a reliable multicast transport built on top of
> OpenPGM (http://code.google.com/p/openpgm/). My plan is to simulate
> reliable 1-hop broadcast by using reliable multicast and setting the TTL
> field to 1. However, this will only affect the IP layer. Unless batman
> also decrements the TTL field of the IP packets traveling over it, I'm kind
> of stuck.
No, batman-adv is a distributed switch on layer 2. So it operates on a
different layer and has no knowledge of IP or its TTL field (please ignore the
gateway feature for now... this is the only exception were it accesses L3
stuff).
> 3) Finally, does batman have the equivalent of multicast or (better yet)
> broadcast for data packets? That is, if I send something to a multicast IP
> address which all of its 1-hop neighbors are listening to, will all of them
> listen to the packet simultaneously, or will it act like a series of unicast
> messages?
It currently has layer 2 broadcast support (it resents broadcast packets 3
times to increase the propability for a successful tx). Multicast is handled
as multicast. Linus Luessing has a patchset to implement optimized multicast
[1]. I am not sure about the current state. But maybe he can give more
detailed information about it. But you should know that the optimized
implementation may use unicast in some scenarios.
Kind regards,
Sven
[1] http://www.open-mesh.org/projects/batman-adv/wiki/Multicast-ideas
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2012-09-04 13:05 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-04 12:48 [B.A.T.M.A.N.] Batman, TTL, broadcast, etc. (UNCLASSIFIED) Karan, Cem F CIV (US)
2012-09-04 13:05 ` Sven Eckelmann [this message]
2012-09-05 13:32 ` Karan, Cem F CIV (US)
2012-09-08 15:37 ` Sven Eckelmann
2012-09-10 15:42 ` Karan, Cem F CIV (US)
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=1522799.RKjDCIBmI1@bentobox \
--to=sven@narfation.org \
--cc=b.a.t.m.a.n@lists.open-mesh.org \
--cc=cem.f.karan.civ@mail.mil \
/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