[B.A.T.M.A.N.] [PATCH-maintv2] batman-adv: replace WARN with rate limited output on non-existing VLAN

[B.A.T.M.A.N.] [PATCH-maintv2] batman-adv: replace WARN with rate limited output on non-existing VLAN

[Simon Wunderlich]

If a VLAN tagged frame is received and the corresponding VLAN is not
configured on the soft interface, it will splat a WARN on every packet
received. This is a quite annoying behaviour for some scenarios, e.g. if
bat0 is bridged with eth0, and there are arbitrary VLAN tagged frames
from Ethernet coming in without having any VLAN configuration on bat0.

The code should probably create vlan objects on the fly and
transparently transport these VLAN-tagged Ethernet frames, but until
this is done, at least the WARN splat should be replaced by a rate
limited output.

Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
---
Changes to PATCH-maint:
 * added newline to output
---
 net/batman-adv/translation-table.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/net/batman-adv/translation-table.c b/net/batman-adv/translation-table.c
index 9b4551a..48adb91 100644
--- a/net/batman-adv/translation-table.c
+++ b/net/batman-adv/translation-table.c
@@ -650,8 +650,10 @@ bool batadv_tt_local_add(struct net_device *soft_iface, const u8 *addr,
 
 	/* increase the refcounter of the related vlan */
 	vlan = batadv_softif_vlan_get(bat_priv, vid);
-	if (WARN(!vlan, "adding TT local entry %pM to non-existent VLAN %d",
-		 addr, BATADV_PRINT_VID(vid))) {
+	if (!vlan) {
+		net_ratelimited_function(batadv_info, soft_iface,
+					 "adding TT local entry %pM to non-existent VLAN %d\n",
+					 addr, BATADV_PRINT_VID(vid));
 		kfree(tt_local);
 		tt_local = NULL;
 		goto out;
-- 
2.8.1

Re: [B.A.T.M.A.N.] [PATCH-maintv2] batman-adv: replace WARN with rate limited output on non-existing VLAN

[Marek Lindner]

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

On Thursday, May 12, 2016 18:52:03 Simon Wunderlich wrote:
> If a VLAN tagged frame is received and the corresponding VLAN is not
> configured on the soft interface, it will splat a WARN on every packet
> received. This is a quite annoying behaviour for some scenarios, e.g. if
> bat0 is bridged with eth0, and there are arbitrary VLAN tagged frames
> from Ethernet coming in without having any VLAN configuration on bat0.
> 
> The code should probably create vlan objects on the fly and
> transparently transport these VLAN-tagged Ethernet frames, but until
> this is done, at least the WARN splat should be replaced by a rate
> limited output.
> 
> Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
> ---
> Changes to PATCH-maint:
>  * added newline to output
> ---
>  net/batman-adv/translation-table.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)

Applied in revision 0479211.

Thanks,
Marek

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[B.A.T.M.A.N.] Antwort: [PATCH-maintv2] batman-adv: replace WARN with rate limited output on non-existing VLAN

[Andreas Pape]

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?

Kind regards,
Andreas


..................................................................
PHOENIX CONTACT ELECTRONICS GmbH

Sitz der Gesellschaft / registered office of the company: 31812 Bad Pyrmont
USt-Id-Nr.: DE811742156
Amtsgericht Hannover HRB 100528 / district court Hannover HRB 100528
Geschäftsführer / Executive Board: Roland Bent, Dr. Martin Heubeck
___________________________________________________________________
Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren, jegliche anderweitige Verwendung sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.
----------------------------------------------------------------------------------------------------
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure, distribution or other use of the material or parts thereof is strictly forbidden.
___________________________________________________________________

Re: [B.A.T.M.A.N.] Antwort: [PATCH-maintv2] batman-adv: replace WARN with rate limited output on non-existing VLAN

[Simon Wunderlich]

[-- 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 --]