All of lore.kernel.org
 help / color / mirror / Atom feed
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: Network Development <netdev@vger.kernel.org>
Subject: Re: BUG?: receiving on a packet socket with .sll_protocoll and bridging
Date: Sun, 6 May 2018 18:58:34 +0200	[thread overview]
Message-ID: <CAF=yD-KBf20Gfpm6KwM_QbcBurCVmWg+MOChKEnD5hqt1u7e=A@mail.gmail.com> (raw)
In-Reply-To: <20180505085700.25vuy44mjpamuot2@pengutronix.de>

On Sat, May 5, 2018 at 10:57 AM, Uwe Kleine-König
<u.kleine-koenig@pengutronix.de> wrote:
> Hello,
>
> my eventual goal is to implement MRP and for that I started to program a
> bit and stumbled over a problem I don't understand.
>
> For testing purposes I created a veth device pair (veth0 veth1), open a
> socket for each of the devices and send packets around between them. In
> tcpdump a typical package looks as follows:
>
> 10:36:34.755208 ae:a9:da:50:48:db (oui Unknown) > 01:15:e4:00:00:01 (oui Unknown), ethertype Unknown (0x88e3), length 58:
>         0x0000:  0001 0212 8000 aea9 da50 48db 0000 0000  .........PH.....
>         0x0010:  0000 0589 40f2 6574 6800 0000 0000 0000  ....@.eth.......
>         0x0020:  0000 0100 0a80 3d38 4c5e 0000            ......=8L^..
>
> The socket to receive these packages is opened using:
>
>         #define ETH_P_MRP 0x88e3
>
>         struct sockaddr_ll sa_ll = {
>                 .sll_family = AF_PACKET,
>                 .sll_protocol = htons(ETH_P_MRP),
>                 .sll_ifindex = if_nametoindex("veth0")
>         };
>
>         fd = socket(AF_PACKET, SOCK_RAW, htons(ETH_P_MRP));
>         bind(fd, (struct sockaddr *)&sa_ll, sizeof(sa_ll));
>
> So far everything works fine and I can receive the packets I send.
>
> If now I add veth0 to a bridge (e.g.
>
>         ip link add br0 type bridge
>         ip link set dev veth0 master br0
>
> ) and continue to send on veth1 and receive on veth0 I don't receive
> the packets any more. The other direction (veth0 sending, veth1
> receiving) still works fine.
>
> Each of the following changes allow to
> receive again:
>
>  a) take veth0 out of the bridge
>  b) bind(2) the receiving socket to br0 instead of veth0
>  c) use .sll_protocol = htons(ETH_P_ALL) for bind(2)
>
> In the end only c) could be sensible (because I need to know the port
> the packet entered the stack and that might well be bridged), but I
> wonder why .sll_protocol = htons(ETH_P_MRP) seems to do the right thing
> for an unbridged device but not for a bridged one.
>
> Is this a bug or a feature I don't understand?

Packets are redirected to the bridge device in __netif_receive_skb_core
at the rx_handler hook.

This happens after packets are passed to packet types attached to
list ptype_all, which includes packet sockets with protocol ETH_P_ALL.
But before packets are passed to protocol specific packet types (and
sockets) attached to ptype_base[].

  reply	other threads:[~2018-05-06 16:59 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-05  8:57 BUG?: receiving on a packet socket with .sll_protocoll and bridging Uwe Kleine-König
2018-05-06 16:58 ` Willem de Bruijn [this message]
2018-05-06 19:14   ` Uwe Kleine-König
2018-05-06 19:22     ` Willem de Bruijn

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='CAF=yD-KBf20Gfpm6KwM_QbcBurCVmWg+MOChKEnD5hqt1u7e=A@mail.gmail.com' \
    --to=willemdebruijn.kernel@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=u.kleine-koenig@pengutronix.de \
    /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.