From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DC51CC43381 for ; Mon, 18 Mar 2019 14:50:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A02EA20850 for ; Mon, 18 Mar 2019 14:50:35 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="i0k2oW/L" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726973AbfCROue (ORCPT ); Mon, 18 Mar 2019 10:50:34 -0400 Received: from mail-ed1-f67.google.com ([209.85.208.67]:40514 "EHLO mail-ed1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726692AbfCROue (ORCPT ); Mon, 18 Mar 2019 10:50:34 -0400 Received: by mail-ed1-f67.google.com with SMTP id h22so3037405edw.7 for ; Mon, 18 Mar 2019 07:50:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VbX5iIrSm92kEtZV88iBUTN0wQvZxGvYEsFKhh3u8U4=; b=i0k2oW/LiglSVfuGdL1H9v2plDJi0AVhbKKMrvy1OCWu/d2s9YqLaY1EjuOxJz3VV+ UsAf1bwPweJDh+695+ot+3wHVJAdBZ0I3cld3udbiPF1lyX4wd/uSV6jNFoe6/t7VwfI 5XsD7cOCrE3qkFZgGDiq2vPvmRnc6/YBmTD0bKO5ZU8hsoBd9AqeCvgZQRvPP0oIJHTb qCTaFkAYVCIYz2FBqPUhc9w8BanXOLwsz1HRXr+D/S/AoLlKagfo5U+zL6mp7gkzGz3M hI8bIzkdleDhrTp3aSjdUteJ9fbGevNPToU6gVSvhmy9BbOtqATvWjAGa/a6ekxnlSxE hr7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VbX5iIrSm92kEtZV88iBUTN0wQvZxGvYEsFKhh3u8U4=; b=CbUBO6pxnjFFksB0vMsXVyT/YFsq24cLT6+ye0KK1RnHaq0AIWRO7KviRw5hZGBgYX J4Z8gcKw0Zy+FFScm7iMbl4Xqe0C3U6/z1VaL4fM5nhzF/Pppq/dQslGP/+WchqmOW0Q kNOG/5RfDdNYNvAHdxsvBP8d8DpKdnCx45uZpwFy2I6eQu0yOVVn/UKkY83Ep5qQcpkq 7iKOxbwe+2KOLxWlSNVaX1eoJUh7d5ZpfoUOnwN+Ot1qKHipu26hAdAlt8xmDNdAEp+y jP5n7x4/sHlZyQGSZiKhXkgPCFhNSwtSpLiPwADKh5C/G9IxplZLtoSbTN2jU3/cZEM3 Hi6w== X-Gm-Message-State: APjAAAW31tY13d6fxd3LpWxFb2XOxpLl1He4RlbJ4tcSbctMOzVMWDdt Jp/8KB8xln3DIvvaC1rhHxuW8BU87vx/dD4BgM4= X-Google-Smtp-Source: APXvYqw67LQA9Uqxo0aXVUevl/koVwiZ1wU+fAnhLU+ijCiSk5FPVE+WPiX8kVoK11/k0ECYobt1aICwKg94lYC+95g= X-Received: by 2002:a50:86c3:: with SMTP id 3mr9062722edu.143.1552920632231; Mon, 18 Mar 2019 07:50:32 -0700 (PDT) MIME-Version: 1.0 References: <20190318053952.115180-1-komachi.yoshiki@lab.ntt.co.jp> In-Reply-To: <20190318053952.115180-1-komachi.yoshiki@lab.ntt.co.jp> From: Willem de Bruijn Date: Mon, 18 Mar 2019 10:49:56 -0400 Message-ID: Subject: Re: [PATCH net] af_packet: fix the tx skb protocol in raw sockets with ETH_P_ALL To: Yoshiki Komachi Cc: "David S. Miller" , Network Development , Yoshiki Komachi , Maxim Mikityanskiy Content-Type: text/plain; charset="UTF-8" Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Mon, Mar 18, 2019 at 1:41 AM Yoshiki Komachi wrote: > > I am using "protocol ip" filters in TC to manipulate TC flower > classifiers, which are only available with "protocol ip". However, > I faced an issue that packets sent via raw sockets with ETH_P_ALL > did not match the ip filters even if they did satisfy the condition > (e.g., DHCP offer from dhcpd). > > I have determined that the behavior was caused by an unexpected > value stored in skb->protocol, namely, ETH_P_ALL instead of ETH_P_IP, > when packets were sent via raw sockets with ETH_P_ALL set. > > IMHO, storing ETH_P_ALL in skb->protocol is not appropriate for > packets sent via raw sockets because ETH_P_ALL is not a real ether > type used on wire, but a virtual one. > > This patch fixes the tx protocol selection in cases of transmission > via raw sockets created with ETH_P_ALL so that it asks the driver to > extract protocol from the Ethernet header. > > Signed-off-by: Yoshiki Komachi Acked-by: Willem de Bruijn The Fixes tag is missing. Calling sendmsg on a packet socket bound to ETH_P_ALL goes back a long way. It is a user, not kernel, bug to do so. But no more than sending on a socket bound to ETH_P_NONE (0), which was addressed in commit c72219b75fde ("packet: infer protocol from ethernet header if unset"). Probing with packet_parse_headers is available only as of commit 75c65772c3 ("net/packet: Ask driver for protocol if not provided by user") in v5.1-rc1. This fix does not need to go back further than that, imho.