Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1605232
| From | Linus Lüssing <linus.luessing@c0d3.blue> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [Bridge] [PATCH net] bridge: ebtables: fix reception of frames DNAT-ed to bridge device |
| Date | 2017-03-21 02:20 +0100 |
| Message-ID | <tngCR-4AF-15@gated-at.bofh.it> (permalink) |
| References | (4 earlier) <tllGG-2YN-23@gated-at.bofh.it> <tlouR-4Xh-17@gated-at.bofh.it> <tlphg-5w5-9@gated-at.bofh.it> <tlZXr-6X4-15@gated-at.bofh.it> <tmMEN-tl-15@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Sun, Mar 19, 2017 at 05:55:06PM +0100, Linus Lüssing wrote:
> On Fri, Mar 17, 2017 at 02:10:44PM +0100, Pablo Neira Ayuso wrote:
> > Wait.
> >
> > May this break local multicast listener that are bound to the bridge
> > interface? Assuming the bridge interface got an IP address, and that
> > there is local multicast listener.
> >
> > Missing anything here?
>
> Hm, for multicast packets usually the code path a few lines
> later in br_handle_frame_finish() should be taken instead.
>
> But you might be right for IP multicast packets with a unicast MAC
> destination (due to whatever reason, for instance via DNAT'ing
> again).
>
> Will check that - thanks!
Ok, I tested DNAT'ing an IP multicast packet to the unicast MAC address
of the bridge interface.
Both ping-ing to an IPv4 and IPv6 multicast listener on br0 worked
and was replied to fine, both with or without changing skb->pkt_type
from PACKET_MULTICAST to PACKET_HOST.
("$ ping 224.1.0.123" and "$ ping6 ff02::1:ff40:707c%in0" from a
network namespace, tied into the bridge via veth)
Also, a DNAT'ed PACKET_BROADCAST worked, with or without changing
it to PACKET_HOST.
I also checked via tcpdump that the destination MAC was changed
successfully.
So, so far I wasn't able to find any bugs with the current
patch. But I think I like the idea of leaving the skb->pkt_type
unaltered for PACKET_MULTICAST and PACKET_BROADCAST, seems cleaner.
I'd just add an "if (skb->pkt_type == PACKET_OTHERHOST)" check
then and resend a PATCH v2.
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH net] bridge: ebtables: fix reception of frames DNAT-ed to bridge device Linus Lüssing <linus.luessing@c0d3.blue> - 2017-03-15 04:20 +0100
Re: [PATCH net] bridge: ebtables: fix reception of frames DNAT-ed to bridge device Florian Westphal <fw@strlen.de> - 2017-03-15 11:30 +0100
Re: [PATCH net] bridge: ebtables: fix reception of frames DNAT-ed to bridge device Pablo Neira Ayuso <pablo@netfilter.org> - 2017-03-15 11:50 +0100
Re: [PATCH net] bridge: ebtables: fix reception of frames DNAT-ed to bridge device Linus Lüssing <linus.luessing@c0d3.blue> - 2017-03-15 15:50 +0100
Re: [PATCH net] bridge: ebtables: fix reception of frames DNAT-ed to bridge device Pablo Neira Ayuso <pablo@netfilter.org> - 2017-03-15 19:20 +0100
Re: [PATCH net] bridge: ebtables: fix reception of frames DNAT-ed to bridge device Linus Lüssing <linus.luessing@c0d3.blue> - 2017-03-15 22:20 +0100
Re: [PATCH net] bridge: ebtables: fix reception of frames DNAT-ed to bridge device Pablo Neira Ayuso <pablo@netfilter.org> - 2017-03-15 23:10 +0100
Re: [PATCH net] bridge: ebtables: fix reception of frames DNAT-ed to bridge device Pablo Neira Ayuso <pablo@netfilter.org> - 2017-03-17 14:20 +0100
Re: [PATCH net] bridge: ebtables: fix reception of frames DNAT-ed to bridge device Linus Lüssing <linus.luessing@c0d3.blue> - 2017-03-19 18:20 +0100
Re: [Bridge] [PATCH net] bridge: ebtables: fix reception of frames DNAT-ed to bridge device Linus Lüssing <linus.luessing@c0d3.blue> - 2017-03-21 02:20 +0100
Re: [Bridge] [PATCH net] bridge: ebtables: fix reception of frames DNAT-ed to bridge device Pablo Neira Ayuso <pablo@netfilter.org> - 2017-03-21 11:20 +0100
Re: [PATCH net] bridge: ebtables: fix reception of frames DNAT-ed to bridge device Pablo Neira Ayuso <pablo@netfilter.org> - 2017-03-15 11:40 +0100
csiph-web