b.a.t.m.a.n.lists.open-mesh.org archive mirror
 help / color / mirror / Atom feed
From: "Linus Lüssing" <linus.luessing@web.de>
To: The list for a Better Approach To Mobile Ad-hoc Networking
	<b.a.t.m.a.n@lists.open-mesh.org>
Subject: Re: [B.A.T.M.A.N.] slowpath warning
Date: Sun, 21 Feb 2010 14:10:41 +0100	[thread overview]
Message-ID: <20100221131041.GA31011@Linus-Debian> (raw)
In-Reply-To: <20100220180411.GA15286@lunn.ch>

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

On Sat, Feb 20, 2010 at 07:04:11PM +0100, Andrew Lunn wrote:
> On Fri, Feb 19, 2010 at 06:19:05PM +0100, Linus L??ssing wrote:
> > Hi Andrew,
> > 
> > Sorry, didn't have the time to try your patch any earlier, I'm
> > right in the middle of my exams :).
> 
> Hi Linus
> 
> Marek told me. No problems. I remember what its like studying for
> exams. However, it is nice to sometimes take a break and do something
> totally different. 
> 
> > Your patch already looks quite good, I couldn't reproduce any
> > memory leaks or crashes here (tried that with three routers and 1
> > or 2 vis servers activated, also activating/deactivating them a
> > lot, no problems with that). And yes, the slow-path warning has
> > gone with your patch.
> 
> Great. So we are on the right tracks.
> 
> > However, I'm having some weird output when connecting two routers
> > over wifi _and_ over ethernet cable. The setup:
> > 
> > Before plugging in the cable:
> > r1-ath1 <-- wifi --> r2-ath1
> > ------------
> > root@OpenWrt:~# batctl vd dot
> > digraph {
> >         "r1-ath1" -> "r2-ath1" [label="1.32"]
> >         "r1-ath1" -> "r1-hna" [label="HNA"]
> >         "r1-ath1" -> "5a:2e:1e:1f:64:6b" [label="HNA"]
> >         subgraph "cluster_r1-ath1" {
> >                 "r1-ath1" [peripheries=2]
> >         }
> >         "r2-ath1" -> "r1-ath1" [label="1.11"]
> >         "r2-ath1" -> "r2-hna" [label="HNA"]
> >         "r2-ath1" -> "82:31:95:f9:14:6f" [label="HNA"]
> >         subgraph "cluster_r2-ath1" {
> >                 "r2-ath1" [peripheries=2]
> >         }
> > }
> > ------------
> > After plugging in the cable:
> > r1-ath1 <-- wifi --> r2-ath1 +
> > r1-eth0.3 <-- cable --> r2-eth0.3
> > ------------
> > root@OpenWrt:~# batctl vd dot
> > digraph {
> >         "r1-ath1" -> "r2-ath1" [label="1.0"]
> >         "r1-ath1" -> "r2-eth0.3" [label="1.66"]
> >         "r1-ath1" -> "r1-hna" [label="HNA"]
> >         "r1-ath1" -> "5a:2e:1e:1f:64:6b" [label="HNA"]
> >         subgraph "cluster_r1-ath1" {
> >                 "r1-ath1" [peripheries=2]
> >                 "r1-eth0.3"
> >         }
> >         subgraph "cluster_r1-ath1" {
> >                 "r1-ath1" [peripheries=2]
> >         }
> >         "r2-ath1" -> "r1-ath1" [label="1.0"]
> >         "r2-ath1" -> "r1-eth0.3" [label="1.15"]
> >         "r2-ath1" -> "r2-hna" [label="HNA"]
> >         "r2-ath1" -> "82:31:95:f9:14:6f" [label="HNA"]
> >         subgraph "cluster_r2-ath1" {
> >                 "r2-ath1" [peripheries=2]
> >                 "r2-eth0.3"
> >         }
> >         subgraph "cluster_r2-ath1" {
> >                 "r2-ath1" [peripheries=2]
> >         }
> > }
> > root@OpenWrt:~# cat /proc/net/batman-adv/vis_data
> > 06:22:b0:98:87:dd,TQ 04:22:b0:98:87:fa 251, HNA 00:22:b0:98:87:dd, HNA 5a:2e:1e:1f:64:6b, PRIMARY, SEC 04:22:b0:98:87:de,
> > 06:22:b0:98:87:f9,TQ 06:22:b0:98:87:dd 255, TQ 04:22:b0:98:87:de 251, HNA 00:22:b0:98:87:f9, HNA 82:31:95:f9:14:6f, SEC 04:22:b0:98:87:fa, PRIMARY,
> 
> Actually, this vis_data to does not map to the dot above!  There are
> the wrong number of HNA, wrong order etc.
Hmm, just noticed, the output also seems to be flapping between
those two from time to time:
------------------
root@OpenWrt:~# cat /proc/net/batman-adv/vis
06:22:b0:98:87:dd,TQ 04:22:b0:98:87:fa 251, HNA 00:22:b0:98:87:dd, HNA f6:ae:97:b3:9a:5c, PRIMARY, SEC 04:22:b0:98:87:de,
06:22:b0:98:87:f9,TQ 04:22:b0:98:87:de 251, HNA da:3e:79:2c:d3:3e, HNA 00:22:b0:98:87:f9, PRIMARY, SEC 04:22:b0:98:87:fa,
root@OpenWrt:~# cat /proc/net/batman-adv/vis
06:22:b0:98:87:dd,TQ 04:22:b0:98:87:fa 251, HNA 00:22:b0:98:87:dd, HNA f6:ae:97:b3:9a:5c, PRIMARY, SEC 04:22:b0:98:87:de,
06:22:b0:98:87:f9,TQ 06:22:b0:98:87:dd 255, TQ 04:22:b0:98:87:de 251, HNA da:3e:79:2c:d3:3e, HNA 00:22:b0:98:87:f9, SEC 04:22:b0:98:87:fa, PRIMARY,
------------------

> 
> Here is what i think your bat-host file contains:
> 06:22:b0:98:87:dd r1-ath1
> 06:22:b0:98:87:f9 r2-ath1
> 00:22:b0:98:87:dd r1-hna
> 04:22:b0:98:87:de r1-eth0.3
> 00:22:b0:98:87:f9 r2-hna
> 04:22:b0:98:87:fa r2-eth0.3
> 
> and this is what i get, assuming i got the MAC->name mapping correct:
Yes, correct mapping :).

> 
> digraph {
> 	"r1-ath1" -> "r2-eth0.3" [label="1.15"]
> 	"r1-ath1" -> "r1-hna" [label="HNA"]
> 	"r1-ath1" -> "5a:2e:1e:1f:64:6b" [label="HNA"]
> 	subgraph "cluster_r1-ath1" {
> 		"r1-ath1" [peripheries=2]
> 	}
> 	subgraph "cluster_r1-ath1" {
> 		"r1-ath1" [peripheries=2]
> 		"r1-eth0.3"
> 	}
> 	"r2-ath1" -> "r1-ath1" [label="1.0"]
> 	"r2-ath1" -> "r1-eth0.3" [label="1.15"]
> 	"r2-ath1" -> "r2-hna" [label="HNA"]
> 	"r2-ath1" -> "82:31:95:f9:14:6f" [label="HNA"]
> 	subgraph "cluster_r2-ath1" {
> 		"r2-ath1" [peripheries=2]
> 		"r2-eth0.3"
> 	}
> 	subgraph "cluster_r2-ath1" {
> 		"r2-ath1" [peripheries=2]
> 	}
> }
> 
> batctl parses top-to-bottom, left-to-right. It does not consolidate
> the PRIMARY and the SECONDARY into one cluster. It leaves DOT to do
> that. Hence there are two cluster statements for each cluster actually
> drawn.
> 
> > So the second 'subgraph "cluster_r1-ath1"' is obviously
> > unnecessary.
> 
> Yes, unnecessary, but makes the batctl code easier.
> 
>  Also "r1-ath1" -> "r2-eth0.3" looks wrong, should be
> > "r1-eth0.3" -> "r2-eth0.3" instead (and the same with r2 a few
> > lines later).
> 
> These comments i agree with. A wireless and a wired device should not
> be neighbours. We don't have any records which originate from the
> secondary MAC address. That is guess is the major problem here.
> 
> So, did my/Mareks patch break it, or was it broken before?
> 
> First i suggest you go back to just before Simon's patch which
> introduced receiving using skbufs:
> 
> http://open-mesh.org/changeset/1517
> 
> That will tell us if we need to go back further, or our patch broke
> it. 
> 
> If you need to go back further, i would suggest just before:
> 
> http://open-mesh.org/changeset/1510
Okay, just checked, this got introduced with 1510 already, yes. I
might have a closer look at this next week.

Cheers, Linus

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

  reply	other threads:[~2010-02-21 13:10 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-23 17:46 [B.A.T.M.A.N.] bat_events: page allocation failure (batman-adv maint) Linus Lüssing
2010-01-23 18:10 ` Andrew Lunn
2010-01-23 23:30   ` Linus Lüssing
2010-01-24 20:42   ` Linus Lüssing
2010-01-24 21:00     ` Andrew Lunn
2010-01-25  6:46       ` Andrew Lunn
2010-01-25  6:47     ` Andrew Lunn
2010-01-25  8:21       ` Marek Lindner
2010-01-26  1:48       ` Linus Lüssing
2010-01-24  4:24 ` Linus Lüssing
2010-01-26  6:13 ` [B.A.T.M.A.N.] slowpath warning Linus Lüssing
2010-01-26  7:16   ` Marek Lindner
2010-01-27  0:10     ` Linus Lüssing
2010-01-28  0:09       ` Marek Lindner
2010-01-28  6:29         ` Andrew Lunn
2010-01-29  8:25   ` Andrew Lunn
2010-01-29  8:59     ` Marek Lindner
2010-01-30 16:50       ` Andrew Lunn
2010-01-31 19:37         ` Linus Lüssing
2010-01-31 20:56           ` Andrew Lunn
2010-02-11  9:46         ` Andrew Lunn
2010-02-11 10:01           ` Andrew Lunn
2010-02-19 17:19             ` Linus Lüssing
2010-02-20 18:04               ` Andrew Lunn
2010-02-21 13:10                 ` Linus Lüssing [this message]
2010-02-28 16:34             ` Simon Wunderlich
2010-03-01  5:59               ` Andrew Lunn
2010-03-01 16:57                 ` Simon Wunderlich
2010-03-02  6:43                   ` Andrew Lunn
2010-03-02 21:13                     ` Simon Wunderlich
2010-03-02 21:26                       ` elektra
2010-03-02 21:44                       ` Linus Lüssing
2010-03-04  0:26                         ` Linus Lüssing
2010-03-04  8:57                           ` Andrew Lunn
2010-03-04  9:19                             ` Marek Lindner
2010-03-04  9:49                               ` Andrew Lunn
2010-03-04 10:00                                 ` Marek Lindner

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=20100221131041.GA31011@Linus-Debian \
    --to=linus.luessing@web.de \
    --cc=b.a.t.m.a.n@lists.open-mesh.org \
    /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;
as well as URLs for NNTP newsgroup(s).