From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
To: David Miller <davem@davemloft.net>
Cc: yamahata@valinux.co.jp, netdev@vger.kernel.org,
murphy.mccauley@gmail.com, jasowang@redhat.com, mst@redhat.com,
edumazet@google.com, kaber@trash.net, honkiko@gmail.com,
ramirose@gmail.com, tparkin@katalix.com,
xiyou.wangcong@gmail.com, pshelar@nicira.com, jesse@nicira.com,
dev@openvswitch.org
Subject: Re: [PATCH] core/dev: set pkt_type after eth_type_trans() in dev_forward_skb()
Date: Wed, 03 Jul 2013 16:53:52 +0200 [thread overview]
Message-ID: <51D43B00.9030801@6wind.com> (raw)
In-Reply-To: <20130702.160005.59343488202291094.davem@davemloft.net>
Le 03/07/2013 01:00, David Miller a écrit :
> From: Isaku Yamahata <yamahata@valinux.co.jp>
> Date: Tue, 2 Jul 2013 20:30:10 +0900
>
>> The dev_forward_skb() assignment of pkt_type should be done
>> after the call to eth_type_trans().
>>
>> ip-encapsulated packets can be handled by localhost. But skb->pkt_type
>> can be PACKET_OTHERHOST when packet comes via veth into ip tunnel device.
>> In that case, the packet is dropped by ip_rcv().
>> Although this example uses gretap. l2tp-eth also has same issue.
>> For l2tp-eth case, add dummy device for ip address and ip l2tp command.
> ...
>> Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
>
> Applied, but I had to adjust the patch because in net-next we use
> a new helper function (skb_scrub_packet()) to clear things out from
> dev_forward_skb().
What about calling skb_scrub_packet() after eth_type_trans()?
I wonder if the same problem may happen the day gre will support x-netns,
because skb_scrub_packet() is also called before eth_type_trans() in
ip_tunnel_rcv().
next prev parent reply other threads:[~2013-07-03 14:53 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-02 11:30 [PATCH] core/dev: set pkt_type after eth_type_trans() in dev_forward_skb() Isaku Yamahata
2013-07-02 23:00 ` David Miller
2013-07-03 14:53 ` Nicolas Dichtel [this message]
2013-07-04 21:57 ` David Miller
2013-07-05 7:48 ` Nicolas Dichtel
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=51D43B00.9030801@6wind.com \
--to=nicolas.dichtel@6wind.com \
--cc=davem@davemloft.net \
--cc=dev@openvswitch.org \
--cc=edumazet@google.com \
--cc=honkiko@gmail.com \
--cc=jasowang@redhat.com \
--cc=jesse@nicira.com \
--cc=kaber@trash.net \
--cc=mst@redhat.com \
--cc=murphy.mccauley@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pshelar@nicira.com \
--cc=ramirose@gmail.com \
--cc=tparkin@katalix.com \
--cc=xiyou.wangcong@gmail.com \
--cc=yamahata@valinux.co.jp \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.