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.] two-radio nodes and alternative next hop
Date: Wed, 23 Apr 2008 09:54:37 +0200 [thread overview]
Message-ID: <200804230954.37620.axel@open-mesh.net> (raw)
In-Reply-To: <20080423000418.GA7368@apoderado.ometepe.net>
Hey,
> > 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!
Are you also specifying the bssid? Because in order to define different
cells in an ad-hoc network the ssid is almost useless in most adhoc
implementations. THe BSSID is much more important!
(E.g. use kamikaze-etc/config/wireless style: option bssid 44:ca:ff:ee:ba:be
or the command-line-style: iwconfig wlan0 ap 44:ca:ff:ee:ba:be )
Anyway, you mean a debug output on 3.16 like the following can not be correct?
Neighbor outgoingIF bestNextHop brc (rcvd knownSince lseq lvld rid sid ) [ viaIF RTQ RQ TQ]..
172.19.4.165 wlan0:bmx 172.19.4.165 55 ( 84 0:00:28:03 9777 1 1 4 ) [ wlan0:bmx 46 76 60]
Sorry for being stubborn: what makes you so sure that they cannot see each
other or that the driver does not mix things up?
At least from the madwifi driver (in ad-hoc mode) I know that it tends to
ignore its assigned *bssid* and channel and switches back and forth between the
assigned one and others.
Sometimes the driver hangs on a wrong bssid and
channel, forwards the wrong IP packets, and cannot receive any packets from
its originally assigned bssid/channel.
One way to verify this would be to run a tcpdump on interface 3.160/wlan0 and
see if it ever tracks a batman packet with a src address of e.g. 172.19.4.165
> i'll make some more logs when .3.137 is back up
ok.
ciao,
axel
next prev parent reply other threads:[~2008-04-23 7:54 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
2008-04-23 7:54 ` Axel Neumann [this message]
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=200804230954.37620.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