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 20:40:13 -0700
From:	pravin shelar <pshelar@....org>
To:	Jiri Benc <jbenc@...hat.com>
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, Apr 22, 2016 at 2:27 PM, Jiri Benc <jbenc@...hat.com> wrote:
> 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.
>

But skb->protocol is not set to ETH_P_TEB anywhere in ip-gre module.
Am I missing something?


>> 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.
>

ip_tunnel_rcv() checks device type (tunnel->dev->type) to perform
ethernet specific processing on packet. I think that should be changed
to check packet type.