public inbox for b.a.t.m.a.n@lists.open-mesh.org
 help / color / mirror / Atom feed
From: Jan Hetges <tran@ms20.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.] two-radio nodes and alternative next hop
Date: Tue, 22 Apr 2008 18:04:18 -0600	[thread overview]
Message-ID: <20080423000418.GA7368@apoderado.ometepe.net> (raw)
In-Reply-To: <200804221601.57318.axel@open-mesh.net>

[-- Attachment #1: Type: text/plain, Size: 3738 bytes --]

On Tue, Apr 22, 2008 at 04:01:57PM +0200, Axel Neumann wrote:
> Hi Jan,
> 
> On Montag 21 April 2008, Jan Hetges wrote:
> > On Mon, Apr 21, 2008 at 02:57:44PM +0200, Benjamin Henrion wrote:
> > > On Mon, Apr 21, 2008 at 2:39 PM, Jan Hetges <tran@ms20.net> wrote:
> > > >  what i recognized lately, on two nodes (the ones with more than
> > > >  one bmx interface), show alternativeNextHops, which are *NO*
> > > >  alternative. It seems there gets some 'information' lost between
> > > >  the two IFs. I suppose that's a known issue ;-), 
> It is NOT a known issue (at least not to me) and if its a bug it should be fixed.
so, let's fix it then ;-)
> > > Can you describe a little more extensively your network configuration?
> > x.x.0.0/24---x.x.0.1/x.x.3.1---x.x.3.0/24---x.x.3.160/x.x.4.1---x.x.4.0/24
> One general questions: do all your interfaces operate on the same frequency?
no
> Then, I am unsure about the netmasks you are using. The above line I 
> understand that you are using x.x.3.0/24 and x.x.4.0/24 netmasks. 
sorry, the /24 only specifys the netrange for the ssid it belongs to 
> Generally, It is strongly recommended to always use the same netmask 
> on ALL batman interfaces !
i know, you helped me fixing that :-)
and if you look again into my previous mail, i also wrote:
batman network x.x.0.0/20.
so, ALL batman broadcasting to x.x.15.255, 

> But according to the debug output there is a direct link to x.x.4.165/24 
> (which I guess has broadcast address of x.x.4.255) and therefore the two 
> interfaces should not see each other!!??
there are direct links always only in the according /24 netrange,
because they are on different channels/ssids, so .3.160 and .4.1 cannot
"see" each other. 
Note, NO .4.x node cannot see ANY .3.x node, even if they
would be on the same channel/ssid!
>Can you verify that (note that the 
> "ifconfig dev ip/netmask" command is buggy and does not always produce 
> corresponding netmask and broadcast addresses and that the interfaces MUST be 
> configured appropriately before the daemon is started. !!!)
i recognized the buggy ifconfig and ALWAYS set netmask and broadcast
addresses.
> 
> > .0.1/.3.1 is one node with two radios, and .3.160/.4.1 the other one.
> > and, .3.160/.4.1 lists .4.162 as alternativeNextHop to .3.128.
> > where .3.1 and .3.137 can see .3.128, but .4.162 can not. 
> 
> An alternativeNextHop to a specific node must not necessarily be a direct neighbor of 
> that node. For example in the following scenario:
claro
> 
> A---B---D
> |       |
> +---E---+
> 
> >From As' point of view B and E may both be potential next hops towards D. But only E 
> can directly see D.
> 
> Is it possible to generate (almost simultaneously) -cbd8 logs from the involved 
> nodes, especially 3.1, 3.160, 4.162, 3.128. 
attached, note that .3.137 is down due to power issues, and the link
between .3.140 and .3.160 is not usable, but you should see the issue.
> 
> > So, there is a 
> > real alternativeNextHop to .3.128 ... .3.137, which is listed after .4.162
> > on .3.160/.4.1. I attach the output of bmxd -cbd8.
> 
> The attached debug log shows:
> 172.19.3.128    wlan0:bmx       172.19.3.1  80 (  97  1:01:20:33 15813    0 100 1012  
> 18   2      1 )    172.19.4.162  67    172.19.3.140   2 
right, but it SHOULD show .3.137, and NOT .4.162 at all. The ONLY link
between .4.x and .3.x IS .4.1/.3.160 (that's the reason for having a
repeater there :)
> 
> At least this line does not show 3.137 listed after .4.162 on .3.160/.4.1
> Has it been truncated ??
i don't think so, i'll make some more logs when .3.137 is back up
> 
> Looking forward to solve this...

cheers

  --Jan


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2008-04-23  0:04 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-21 12:39 [B.A.T.M.A.N.] two radio nodes and alternative next hop Jan Hetges
2008-04-21 12:57 ` Benjamin Henrion
2008-04-21 20:30   ` [B.A.T.M.A.N.] two-radio " Jan Hetges
2008-04-22 14:01     ` Axel Neumann
2008-04-23  0:04       ` Jan Hetges [this message]
2008-04-23  7:54         ` Axel Neumann
2008-04-23 23:02           ` Jan Hetges
2008-04-24  7:33             ` Axel Neumann
2008-04-24  3:55           ` Jan Hetges
2008-04-24  8:09             ` Axel Neumann
2008-04-21 20:33   ` [B.A.T.M.A.N.] two radio " Jan Hetges

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=20080423000418.GA7368@apoderado.ometepe.net \
    --to=tran@ms20.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