From: Simon Wunderlich <sw@simonwunderlich.de>
To: Andreas Pape <APape@phoenixcontact.com>
Cc: 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.] Antwort: [PATCH-maintv2] batman-adv: replace WARN with rate limited output on non-existing VLAN
Date: Fri, 20 May 2016 12:34:19 +0200 [thread overview]
Message-ID: <2389731.VthjvnFTt3@prime> (raw)
In-Reply-To: <OFA25ED025.C66D5F5E-ONC1257FB9.00376293-C1257FB9.003771B4@phoenixcontact.com>
[-- Attachment #1: Type: text/plain, Size: 1896 bytes --]
Hi Andreas,
On Friday 20 May 2016 12:05:35 Andreas Pape wrote:
> Hi,
>
> this is a point I also stumbled across. In my use case the problem is a
> little bit
> more difficult.
> I use a setup with bat interfaces bridged to ethernet interfaces and my
> mesh nodes
> shall forward layer2 transparently network traffic from the wired network
> into the
> mesh.
>
> My problem now is that among the layer2 traffic there are also vlan tagged
> frames
> whereas the bat interface isn't member of the vlan to be forwarded itself.
>
> More specific in my case the frames use vlan id 0 and are tagged mainly
> due to the
> reason to guarantee some QoS in the wired network.
>
> Yes, I know one might argue what reason QoS priority tagging has in mesh
> setups, but
> these frames are not generated by my devices but I have to forward them
> "as they are".
>
> As far as I understood the code, these frames do not only lead to the WARN
> messages
> (and there I welcome Simon's patch) but also lead to a drop of the tagged
> packets
> (correct ?). If I understood this correctly I would prefer that batman
> would handle
> vlan tagged packets on layer 2 like an unmanaged switch does: still
> forward such
> packets according to the mac header.
>
> What do you think?
I completely agree, this is what I'd expect from batman-adv to do. However,
currently this isn't the case as you have noticed already.
As a workaround, you could create vlan interfaces like bat0.0 and eth0.0 and
bridge those.
However in the long run, I think we should change the TT/VLAN code to create
vlan objects on the fly when we get packets and remove those vlan objects when
the corresponding TT local entries are gone (and no VLAN is actually
configured). I've put this on my list of things I'll try to work on at some
point, if anyone wants to prepare a patch before me please go ahead ... :)
Cheers,
Simon
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
prev parent reply other threads:[~2016-05-20 10:34 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-12 16:52 [B.A.T.M.A.N.] [PATCH-maintv2] batman-adv: replace WARN with rate limited output on non-existing VLAN Simon Wunderlich
2016-05-17 9:12 ` Marek Lindner
2016-05-20 10:05 ` [B.A.T.M.A.N.] Antwort: " Andreas Pape
2016-05-20 10:34 ` Simon Wunderlich [this message]
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=2389731.VthjvnFTt3@prime \
--to=sw@simonwunderlich.de \
--cc=APape@phoenixcontact.com \
--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