[PATCH] brouted packet identified as PACKET_OTHERHOST blocked by higher protocol

[PATCH] brouted packet identified as PACKET_OTHERHOST blocked by higher protocol

[Yigal Reiss (yreiss)]

The problem I'm trying to solve is that when packets being sent from one bridged interface to the other are "brouted" they get dropped by the IP layer. The reason is that the packet being raised has pkt_type of type PACKET_OTHERHOST.

The semantics of "brouting" a packet is that it is sent up to higher network layers. Problem is that when the pkt_type of the packet is 
PACKET_OTHERHOST it (at least for IP) gets dropped. (e.g. dropping OTHERHOST packets is the first thing ip_rcv() does).

The suggested patch below changes the packet type to PACKET_HOST which fixes the problem. This is a bit of a cheat but I didn't find any side effects and couldn't find a better way w/o defining a new packet type. 

Also removed " dest = eth_hdr(skb)->h_dest;" which does nothing as far as I can see as it is already assigned the same value before.

diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
index f921a5d..2cae324 100644
--- a/net/bridge/br_input.c
+++ b/net/bridge/br_input.c
@@ -291,12 +291,11 @@ forward:
        switch (p->state) {
        case BR_STATE_FORWARDING:
                rhook = rcu_dereference(br_should_route_hook);
-               if (rhook) {
-                       if ((*rhook)(skb)) {
-                               *pskb = skb;
-                               return RX_HANDLER_PASS;
-                       }
-                       dest = eth_hdr(skb)->h_dest;
+               if (rhook && (*rhook)(skb)) {
+                   if (skb->pkt_type == PACKET_OTHERHOST)
+                       skb->pkt_type = PACKET_HOST; /* so it does not get rejected by higher protocol receiver, e.g. by ip_rcv()  */
+                   *pskb = skb;
+                   return RX_HANDLER_PASS;
                }
                /* fall through */
        case BR_STATE_LEARNING:

Re: [PATCH] brouted packet identified as PACKET_OTHERHOST blocked by higher protocol

[Florian Westphal]

Yigal Reiss (yreiss) <yreiss@cisco.com> wrote:
> The problem I'm trying to solve is that when packets being sent from one bridged interface to the other are "brouted" they get dropped by the IP layer. The reason is that the packet being raised has pkt_type of type PACKET_OTHERHOST.

No, thats not the problem you're trying to solve.

If you want to move OTHERHOST skbs, don't (b)route them?

Whats the real issue that you're trying to solve?

RE: [PATCH] brouted packet identified as PACKET_OTHERHOST blocked by higher protocol

[Yigal Reiss (yreiss)]

Florian Westphal <fw@strlen.de> wrote:
> Yigal Reiss (yreiss) <yreiss@cisco.com> wrote:
> > The problem I'm trying to solve is that when packets being sent from
> one bridged interface to the other are "brouted" they get dropped by the
> IP layer. The reason is that the packet being raised has pkt_type of
> type PACKET_OTHERHOST.
> 
> No, thats not the problem you're trying to solve.
> 
> If you want to move OTHERHOST skbs, don't (b)route them?
> 
> Whats the real issue that you're trying to solve?

I want to (b)route them because I want to be able to inspect the packets in higher levels
(through iptables or user space IPS).

Once I do that (i.e. (b)route by applying an appropriate ebtables rule), the corresponding
packets get dropped unless I apply the patch.

Re: [PATCH] brouted packet identified as PACKET_OTHERHOST blocked by higher protocol

[Florian Westphal]

Yigal Reiss (yreiss) <yreiss@cisco.com> wrote:
> > No, thats not the problem you're trying to solve.
> > 
> > If you want to move OTHERHOST skbs, don't (b)route them?
> > 
> > Whats the real issue that you're trying to solve?
> 
> I want to (b)route them because I want to be able to inspect the packets in higher levels
> (through iptables or user space IPS).

For nfqueue via iptables, use call-iptables sysctl?

Alternatively, implement NFQUEUE support for NF_BRIDGE family,
we'll need this eventually for nftables bridge family anyway.

AF_PACKET should just 'work' without brouting.

> Once I do that (i.e. (b)route by applying an appropriate ebtables rule), the corresponding
> packets get dropped unless I apply the patch.

Maybe, but if you broute everything you might as well just remove the
bridge...

You can use -j redirect in ebtables broute table to force local MAC dnat (this also
'fixes' the pkttype to _HOST) if you really want to broute.

RE: [PATCH] brouted packet identified as PACKET_OTHERHOST blocked by higher protocol

[Yigal Reiss (yreiss)]

Florian Westphal [mailto:fw@strlen.de] wrote:
> Maybe, but if you broute everything you might as well just remove the
> bridge...
I want to be selective. My setup is a home router. So I can have ebtables rules for 
which traffic to (b)route and which to bridge, based on security/performance criteria.

> You can use -j redirect in ebtables broute table to force local MAC dnat
> (this also 'fixes' the pkttype to _HOST) if you really want to broute.
I may be missing something obvious, but what is the normal case where using an 
ebtables 'broute' "-j DROP" rule does work? It seemed to me that without the 
fix all (b)routed packets would get lost in IP layer
(unless also dnat or something is done in addition which changes the pkt_type value). 
What is the original intention of this table/chain if not pulling packets between 
"other hosts" out of the bridge and passing them through the IP and higher layers?

Re: [PATCH] brouted packet identified as PACKET_OTHERHOST blocked by higher protocol

[Florian Westphal]

Yigal Reiss (yreiss) <yreiss@cisco.com> wrote:
> Florian Westphal [mailto:fw@strlen.de] wrote:
> > Maybe, but if you broute everything you might as well just remove the
> > bridge...
> I want to be selective. My setup is a home router. So I can have ebtables rules for 
> which traffic to (b)route and which to bridge, based on security/performance criteria.

This usually doesn't work since you can only safely use L3 headers
(unless you disallow ip fragmentation to occur -- else first fragment
 will be brouted, rest is bridged).

> > You can use -j redirect in ebtables broute table to force local MAC dnat
> > (this also 'fixes' the pkttype to _HOST) if you really want to broute.
> I may be missing something obvious, but what is the normal case where using an 
> ebtables 'broute' "-j DROP" rule does work?

It doesn't, (for ip protocols), as you discovered.
But there are other protocols too, so I'm not sure its good idea to
uncoditionally reset pkttype.

(It also changes long-standing behaviour).

Note that broute only "works" in some cases, such as brouting a specific
host.

'Sometimes bridged, sometimes routed' usually causes various issues,
such as ip addresses seemingly 'moving' to different host.

> What is the original intention of this table/chain if not pulling packets between 
> "other hosts" out of the bridge and passing them through the IP and higher layers?

No idea, I did not add this feature.