On Thu, Jan 03, 2019 at 07:48:41AM -0500, Su Yanjun wrote:In my option rp_filter should not affect the ip_vti functionality.
Recently we run a network test over ipcomp virtual tunnel.We find thatWhy not just leaving rp_filter disabled or in 'loose mode' if you use ipcomp?
if a ipv4 packet needs fragment, then the peer can't receive
it.
We deep into the code and find that when packet need fragment the smaller
fragment will be encapsulated by ipip not ipcomp. So when the ipip packet
goes into xfrm, it's skb->dev is not properly set. The ipv4 reassembly code
always set skb'dev to the last fragment's dev. After ipv4 defrag processing,
when the kernel rp_filter parameter is set, the skb will be drop by -EXDEV
error.
This code derives from xfrm4_tunnel and i just want the vti can handle ipip packet as xfrm4 tunnel does.This patch adds compatible support for the ipip process in ipcomp virtual tunnel.You use the src address as spi, how is this supposed to work?
Signed-off-by: Su Yanjun <suyj.fnst@xxxxxxxxxxxxxx>
---
net/ipv4/ip_vti.c | 25 ++++++++++++++++++++++++-
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/ip_vti.c b/net/ipv4/ip_vti.c
index de31b30..63de2f6 100644
--- a/net/ipv4/ip_vti.c
+++ b/net/ipv4/ip_vti.c
@@ -65,6 +65,9 @@ static int vti_input(struct sk_buff *skb, int nexthdr, __be32 spi,
XFRM_TUNNEL_SKB_CB(skb)->tunnel.ip4 = tunnel;
+ if (iph->protocol == IPPROTO_IPIP)
+ skb->dev = tunnel->dev;
+
return xfrm_input(skb, nexthdr, spi, encap_type);
}
@@ -76,10 +79,15 @@ static int vti_input(struct sk_buff *skb, int nexthdr, __be32 spi,
static int vti_rcv(struct sk_buff *skb)
{
+ __be32 spi = 0;
+
XFRM_SPI_SKB_CB(skb)->family = AF_INET;
XFRM_SPI_SKB_CB(skb)->daddroff = offsetof(struct iphdr, daddr);
+
+ if (ip_hdr(skb)->protocol == IPPROTO_IPIP)
+ spi = ip_hdr(skb)->saddr;
- return vti_input(skb, ip_hdr(skb)->protocol, 0, 0);
+ return vti_input(skb, ip_hdr(skb)->protocol, spi, 0);