netdev - Re: [PATCH net 3/3] gre: receive also TEB packets for lwtunnels

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 22 Apr 2016 23:27:32 +0200
From:	Jiri Benc <jbenc@...hat.com>
To:	pravin shelar <pshelar@....org>
Cc:	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	Pravin B Shelar <pshelar@...ira.com>,
	Thomas Graf <tgraf@...g.ch>,
	Simon Horman <simon.horman@...ronome.com>
Subject: Re: [PATCH net 3/3] gre: receive also TEB packets for lwtunnels

On Fri, 22 Apr 2016 14:07:01 -0700, pravin shelar wrote:
> On Fri, Apr 22, 2016 at 10:44 AM, Jiri Benc <jbenc@...hat.com> wrote:
> > For ipgre interfaces in collect metadata mode, receive also traffic with
> > encapsulated Ethernet headers. The lwtunnel users are supposed to sort this
> > out correctly. This allows to have mixed Ethernet + L3-only traffic on the
> > same lwtunnel interface.
> >
> How user is suppose to sort out the type of packet? whether it is L2 or L3.

By skb->protocol, of course. Will be ETH_P_TEB if the inner packet was
Ethernet. There's no problem with this, for lwtunnels used with encap
routes, such packets are just discarded (which is the expected
behavior), as there's no protocol handler for ETH_P_TEB. More clever
lwtunnel users (such as openvswitch) can process the packets. This is
important in order to have a single tunnel interface for everything.

> Is it fine to receive L2 packet over L3 device?
> At least ip_tunnel_rcv() is not ready to handle such packet.

I don't see why. Could you please elaborate? Seems safe to me. The
desired result is skb->protocol == htons(ETH_P_TEB), network header(!)
pointing to the start of the Ethernet frame (because we're tunneling
Ethernet via ARPHRD_IPGRE interface, there's no L2 header to have), mac
header not being set.

 Jiri