net: reset MAC header consistently across L3 virtual devices
Subsystems (4)
cover net: reset MAC header consistently across L3 virtual devices
Some virtual L3 devices, like vxlan-gpe and gre (in collect_md mode), reset the MAC header pointer after they parsed the outer headers. This accurately reflects the fact that the decapsulated packet is pure L3 packet, as that makes the MAC header 0 bytes long (the MAC and network header pointers are equal).
However, many L3 devices only adjust the network header after decapsulation and leave the MAC header pointer to its original value. This can confuse other parts of the networking stack, like TC, which then considers the outer headers as one big MAC header.
This patch series makes the following L3 tunnels behave like VXLAN-GPE:
bareudp, ipip, sit, gre, ip6gre, ip6tnl, gtp.
The case of gre is a bit special. It already resets the MAC header pointer in collect_md mode, so only the classical mode needs to be adjusted. However, gre also has a special case that expects the MAC header pointer to keep pointing to the outer header even after decapsulation. Therefore, patch 4 keeps an exception for this case.
Ideally, we'd centralise the call to skb_reset_mac_header() in ip_tunnel_rcv(), to avoid manual calls in ipip (patch 2), sit (patch 3) and gre (patch 4). That's unfortunately not feasible currently, because of the gre special case discussed above that precludes us from resetting the MAC header unconditionally.
The original motivation is to redirect bareudp packets to Ethernet devices (as described in patch 1). The rest of this series aims at bringing consistency across all L3 devices (apart from gre's special case unfortunately).
Note: the gtp patch results from pure code inspection and has been compiled tested only.
Guillaume Nault (6):
bareudp: allow redirecting bareudp packets to eth devices
ipip: allow redirecting ipip and mplsip packets to eth devices
sit: allow redirecting ip6ip, ipip and mplsip packets to eth devices
gre: let mac_header point to outer header only when necessary
ip6_tunnel: allow redirecting ip6gre and ipxip6 packets to eth devices
gtp: reset mac_header after decap
drivers/net/bareudp.c | 1 + drivers/net/gtp.c | 1 + net/ipv4/ip_gre.c | 7 ++++++- net/ipv4/ipip.c | 2 ++ net/ipv6/ip6_tunnel.c | 1 + net/ipv6/sit.c | 4 ++++ 6 files changed, 15 insertions(+), 1 deletion(-)
Signature · 1 line
2.21.3
PATCH 1/6 bareudp: allow redirecting bareudp packets to eth devices
Even though bareudp transports L3 data (typically IP or MPLS), it needs to reset the mac_header pointer, so that other parts of the stack don't mistakenly access the outer header after the packet has been decapsulated.
This allows to push an Ethernet header to bareudp packets and redirect them to an Ethernet device:
$ tc filter add dev bareudp0 ingress matchall \
action vlan push_eth dst_mac 00:00:5e:00:53:01 \
src_mac 00:00:5e:00:53:00 \
action mirred egress redirect dev eth0Without this patch, push_eth refuses to add an ethernet header because the skb appears to already have a MAC header.
--- drivers/net/bareudp.c | 1 + 1 file changed, 1 insertion(+)
drivers/net/bareudp.c +1 -0
@@ -133,6 +133,7 @@ static int bareudp_udp_encap_recv(struct sock *sk, struct sk_buff *skb) skb->dev = bareudp->dev; oiph =skb_network_header (skb);skb_reset_network_header (skb); +skb_reset_mac_header (skb);if (!IS_ENABLED (CONFIG_IPV6 ) || family ==AF_INET ) err =IP_ECN_decapsulate (oiph, skb);
Signature · 1 line
2.21.3
PATCH 2/6 ipip: allow redirecting ipip and mplsip packets to eth devices
In reply to Guillaume NaultEven though ipip transports IPv4 or MPLS packets, it needs to reset the mac_header pointer, so that other parts of the stack don't mistakenly access the outer header after the packet has been decapsulated.
This allows to push an Ethernet header to ipip or mplsip packets and redirect them to an Ethernet device:
$ tc filter add dev ipip0 ingress matchall \
action vlan push_eth dst_mac 00:00:5e:00:53:01 \
src_mac 00:00:5e:00:53:00 \
action mirred egress redirect dev eth0Without this patch, push_eth refuses to add an ethernet header because the skb appears to already have a MAC header.
--- net/ipv4/ipip.c | 2 ++ 1 file changed, 2 insertions(+)
net/ipv4/ipip.c +2 -0
@@ -242,6 +242,8 @@ static int ipip_tunnel_rcv(struct sk_buff *skb, u8 ipproto)if (!tun_dst)return 0 ; } +skb_reset_mac_header (skb); +return ip_tunnel_rcv (tunnel, skb, tpi, tun_dst, log_ecn_error); }
Signature · 1 line
2.21.3
PATCH 3/6 sit: allow redirecting ip6ip, ipip and mplsip packets to eth devices
In reply to Guillaume NaultEven though sit transports L3 data (IPv6, IPv4 or MPLS) packets, it needs to reset the mac_header pointer, so that other parts of the stack don't mistakenly access the outer header after the packet has been decapsulated. There are two rx handlers to modify: ipip6_rcv() for the ip6ip mode and sit_tunnel_rcv() which is used to re-implement the ipip and mplsip modes of ipip.ko.
This allows to push an Ethernet header to sit packets and redirect them to an Ethernet device:
$ tc filter add dev sit0 ingress matchall \
action vlan push_eth dst_mac 00:00:5e:00:53:01 \
src_mac 00:00:5e:00:53:00 \
action mirred egress redirect dev eth0Without this patch, push_eth refuses to add an ethernet header because the skb appears to already have a MAC header.
--- net/ipv6/sit.c | 4 ++++ 1 file changed, 4 insertions(+)
net/ipv6/sit.c +4 -0
@@ -710,6 +710,8 @@ static int ipip6_rcv(struct sk_buff *skb)* old iph is no longer valid */ iph = (const struct iphdr *)skb_mac_header (skb); +skb_reset_mac_header (skb); + err =IP_ECN_decapsulate (iph, skb);if (unlikely (err)) {if (log_ecn_error)
@@ -780,6 +782,8 @@ static int sit_tunnel_rcv(struct sk_buff *skb, u8 ipproto) tpi = &ipip_tpi;if (iptunnel_pull_header (skb,0 , tpi->proto, false)) goto drop; +skb_reset_mac_header (skb); +return ip_tunnel_rcv (tunnel, skb, tpi,NULL , log_ecn_error); }
Signature · 1 line
2.21.3
PATCH 4/6 gre: let mac_header point to outer header only when necessary
In reply to Guillaume NaultCommit e271c7b4420d ("gre: do not keep the GRE header around in collect medata mode") did reset the mac_header for the collect_md case. Let's extend this behaviour to classical gre devices as well.
ipgre_header_parse() seems to be the only case that requires mac_header to point to the outer header. We can detect this case accurately by checking ->header_ops. For all other cases, we can reset mac_header.
This allows to push an Ethernet header to ipgre packets and redirect them to an Ethernet device:
$ tc filter add dev gre0 ingress matchall \
action vlan push_eth dst_mac 00:00:5e:00:53:01 \
src_mac 00:00:5e:00:53:00 \
action mirred egress redirect dev eth0Before this patch, this worked only for collect_md gre devices. Now this works for regular gre devices as well. Only the special case of gre devices that use ipgre_header_ops isn't supported.
--- net/ipv4/ip_gre.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
net/ipv4/ip_gre.c +6 -1
@@ -107,6 +107,8 @@ module_param(log_ecn_error, bool, 0644);MODULE_PARM_DESC (log_ecn_error,"Log packets received with corrupted ECN" );static struct rtnl_link_ops ipgre_link_ops__read_mostly ; +static const struct header_ops ipgre_header_ops; +static int ipgre_tunnel_init (struct net_device *dev); static void erspan_build_header(struct sk_buff *skb, u32 id, u32 index,
@@ -364,7 +366,10 @@ static int __ipgre_rcv(struct sk_buff *skb, const struct tnl_ptk_info *tpi, raw_proto, false) < 0) goto drop; -if (tunnel->dev->type !=ARPHRD_NONE ) +/* Special case for ipgre_header_parse(), which expects the +* mac_header to point to the outer IP header. +*/ +if (tunnel->dev->header_ops == &ipgre_header_ops)skb_pop_mac_header (skb);else skb_reset_mac_header (skb);
Signature · 1 line
2.21.3
PATCH 5/6 ip6_tunnel: allow redirecting ip6gre and ipxip6 packets to eth devices
In reply to Guillaume NaultReset the mac_header pointer even when the tunnel transports only L3 data (in the ARPHRD_ETHER case, this is already done by eth_type_trans). This prevents other parts of the stack from mistakenly accessing the outer header after the packet has been decapsulated.
In practice, this allows to push an Ethernet header to ipip6, ip6ip6, mplsip6 or ip6gre packets and redirect them to an Ethernet device:
$ tc filter add dev ip6tnl0 ingress matchall \
action vlan push_eth dst_mac 00:00:5e:00:53:01 \
src_mac 00:00:5e:00:53:00 \
action mirred egress redirect dev eth0Without this patch, push_eth refuses to add an ethernet header because the skb appears to already have a MAC header.
--- net/ipv6/ip6_tunnel.c | 1 + 1 file changed, 1 insertion(+)
net/ipv6/ip6_tunnel.c +1 -0
@@ -837,6 +837,7 @@ static int __ip6_tnl_rcv(struct ip6_tnl *tunnel, struct sk_buff *skb,skb_postpull_rcsum (skb,eth_hdr (skb),ETH_HLEN ); }else { skb->dev = tunnel->dev; +skb_reset_mac_header (skb); }skb_reset_network_header (skb);
Signature · 1 line
2.21.3
PATCH 6/6 gtp: reset mac_header after decap
In reply to Guillaume NaultFor consistency with other L3 tunnel devices, reset the mac_header pointer after decapsulation. This makes the mac_header 0 bytes long, thus making it clear that this skb has no mac_header.
Compile tested only.
--- drivers/net/gtp.c | 1 + 1 file changed, 1 insertion(+)
drivers/net/gtp.c +1 -0
@@ -201,6 +201,7 @@ static int gtp_rx(struct pdp_ctx *pctx, struct sk_buff *skb,* calculate the transport header. */ skb_reset_network_header (skb); +skb_reset_mac_header (skb); skb->dev = pctx->dev;
Signature · 1 line
2.21.3
Quoted 20 lines · Guillaume Nault
Some virtual L3 devices, like vxlan-gpe and gre (in
collect_mdmode), reset the MAC header pointer after they parsed the outer headers. This accurately reflects the fact that the decapsulated packet is pure L3 packet, as that makes the MAC header 0 bytes long (the MAC and network header pointers are equal).However, many L3 devices only adjust the network header after decapsulation and leave the MAC header pointer to its original value. This can confuse other parts of the networking stack, like TC, which then considers the outer headers as one big MAC header.
This patch series makes the following L3 tunnels behave like VXLAN-GPE:
bareudp, ipip, sit, gre, ip6gre, ip6tnl, gtp.The case of gre is a bit special. It already resets the MAC header pointer in
collect_mdmode, so only the classical mode needs to be adjusted. However, gre also has a special case that expects the MAC header pointer to keep pointing to the outer header even after decapsulation. Therefore, patch 4 keeps an exception for this case.
Quoted 5 lines
Ideally, we'd centralise the call to
skb_reset_mac_header()inip_tunnel_rcv(), to avoid manual calls in ipip (patch 2), sit (patch 3) and gre (patch 4). That's unfortunately not feasible currently, because of the gre special case discussed above that precludes us from resetting the MAC header unconditionally.
What about adding a flag to ip_tunnel indicating if it can be done (or should not be done since doing it is the most common)?
Quoted 5 lines
The original motivation is to redirect bareudp packets to Ethernet devices (as described in patch 1). The rest of this series aims at bringing consistency across all L3 devices (apart from gre's special case unfortunately).
Can you add a selftests that covers the use cases you mention in the commit logs?
Quoted 21 lines · David Ahern
Quoted 20 lines · Guillaume Nault
Some virtual L3 devices, like vxlan-gpe and gre (in
collect_mdmode), reset the MAC header pointer after they parsed the outer headers. This accurately reflects the fact that the decapsulated packet is pure L3 packet, as that makes the MAC header 0 bytes long (the MAC and network header pointers are equal).However, many L3 devices only adjust the network header after decapsulation and leave the MAC header pointer to its original value. This can confuse other parts of the networking stack, like TC, which then considers the outer headers as one big MAC header.
This patch series makes the following L3 tunnels behave like VXLAN-GPE:
bareudp, ipip, sit, gre, ip6gre, ip6tnl, gtp.The case of gre is a bit special. It already resets the MAC header pointer in
collect_mdmode, so only the classical mode needs to be adjusted. However, gre also has a special case that expects the MAC header pointer to keep pointing to the outer header even after decapsulation. Therefore, patch 4 keeps an exception for this case.
Quoted 8 lines
Quoted 5 lines
Ideally, we'd centralise the call to
skb_reset_mac_header()inip_tunnel_rcv(), to avoid manual calls in ipip (patch 2), sit (patch 3) and gre (patch 4). That's unfortunately not feasible currently, because of the gre special case discussed above that precludes us from resetting the MAC header unconditionally.What about adding a flag to
ip_tunnelindicating if it can be done (or should not be done since doing it is the most common)?
That's feasible. I didn't do it here because I wanted to keep the patch series focused on L3 tunnels. Modifying ip_tunnel_rcv()'s prototype would also require updating erspan_rcv(), which isn't L3 (erspan carries Ethernet frames). I was feeling such consolidation would be best done in a follow up patch series.
I can repost if you feel strongly about it. Otherwise, I'll follow up with the ip_tunnel_rcv() consolidation in a later patch. Just let me know if you have any preference.
Quoted 7 lines
Quoted 4 lines
The original motivation is to redirect bareudp packets to Ethernet devices (as described in patch 1). The rest of this series aims at bringing consistency across all L3 devices (apart from gre's special case unfortunately).
Can you add a selftests that covers the use cases you mention in the commit logs?
I'm already having a selftests for most of the tunnels (and their different operating modes), gtp being the main exception. But it's not yet ready for upstream, as I'm trying to move the topology in its own .sh file, to keep the main selftests as simple as possible. I'll post it as soon as I get it in good shape.
Thanks for the rewiew.
Quoted 28 lines · Guillaume Nault
Quoted 27 lines · David Ahern
Quoted 25 lines · Guillaume Nault
Some virtual L3 devices, like vxlan-gpe and gre (in
collect_mdmode), reset the MAC header pointer after they parsed the outer headers. This accurately reflects the fact that the decapsulated packet is pure L3 packet, as that makes the MAC header 0 bytes long (the MAC and network header pointers are equal).However, many L3 devices only adjust the network header after decapsulation and leave the MAC header pointer to its original value. This can confuse other parts of the networking stack, like TC, which then considers the outer headers as one big MAC header.
This patch series makes the following L3 tunnels behave like VXLAN-GPE:
bareudp, ipip, sit, gre, ip6gre, ip6tnl, gtp.The case of gre is a bit special. It already resets the MAC header pointer in
collect_mdmode, so only the classical mode needs to be adjusted. However, gre also has a special case that expects the MAC header pointer to keep pointing to the outer header even after decapsulation. Therefore, patch 4 keeps an exception for this case.Ideally, we'd centralise the call to
skb_reset_mac_header()inip_tunnel_rcv(), to avoid manual calls in ipip (patch 2), sit (patch 3) and gre (patch 4). That's unfortunately not feasible currently, because of the gre special case discussed above that precludes us from resetting the MAC header unconditionally.
Quoted 8 lines
Quoted 2 lines
What about adding a flag to
ip_tunnelindicating if it can be done (or should not be done since doing it is the most common)?That's feasible. I didn't do it here because I wanted to keep the patch series focused on L3 tunnels. Modifying ip_tunnel_rcv()'s prototype would also require updating
erspan_rcv(), which isn't L3 (erspan carries Ethernet frames). I was feeling such consolidation would be best done in a follow up patch series.
I was thinking a flag in 'struct ip_tunnel'. It's the private data for those netdevices, so a per-instance setting. I haven't walked through the details to know if it would work.
Quoted 10 lines
I can repost if you feel strongly about it. Otherwise, I'll follow up with the
ip_tunnel_rcv()consolidation in a later patch. Just let me know if you have any preference.Quoted 5 lines
Quoted 4 lines
The original motivation is to redirect bareudp packets to Ethernet devices (as described in patch 1). The rest of this series aims at bringing consistency across all L3 devices (apart from gre's special case unfortunately).
Quoted 9 lines
Quoted 2 lines
Can you add a selftests that covers the use cases you mention in the commit logs?
I'm already having a selftests for most of the tunnels (and their different operating modes), gtp being the main exception. But it's not yet ready for upstream, as I'm trying to move the topology in its own .sh file, to keep the main selftests as simple as possible. I'll post it as soon as I get it in good shape.
That works. Thanks,
Quoted 38 lines · David Ahern
Quoted 28 lines · Guillaume Nault
Quoted 27 lines · David Ahern
Quoted 25 lines · Guillaume Nault
Some virtual L3 devices, like vxlan-gpe and gre (in
collect_mdmode), reset the MAC header pointer after they parsed the outer headers. This accurately reflects the fact that the decapsulated packet is pure L3 packet, as that makes the MAC header 0 bytes long (the MAC and network header pointers are equal).However, many L3 devices only adjust the network header after decapsulation and leave the MAC header pointer to its original value. This can confuse other parts of the networking stack, like TC, which then considers the outer headers as one big MAC header.
This patch series makes the following L3 tunnels behave like VXLAN-GPE:
bareudp, ipip, sit, gre, ip6gre, ip6tnl, gtp.The case of gre is a bit special. It already resets the MAC header pointer in
collect_mdmode, so only the classical mode needs to be adjusted. However, gre also has a special case that expects the MAC header pointer to keep pointing to the outer header even after decapsulation. Therefore, patch 4 keeps an exception for this case.Ideally, we'd centralise the call to
skb_reset_mac_header()inip_tunnel_rcv(), to avoid manual calls in ipip (patch 2), sit (patch 3) and gre (patch 4). That's unfortunately not feasible currently, because of the gre special case discussed above that precludes us from resetting the MAC header unconditionally.Quoted 8 lines
Quoted 2 lines
What about adding a flag to
ip_tunnelindicating if it can be done (or should not be done since doing it is the most common)?That's feasible. I didn't do it here because I wanted to keep the patch series focused on L3 tunnels. Modifying ip_tunnel_rcv()'s prototype would also require updating
erspan_rcv(), which isn't L3 (erspan carries Ethernet frames). I was feeling such consolidation would be best done in a follow up patch series.
Quoted 3 lines
I was thinking a flag in 'struct
ip_tunnel'. It's the private data for those netdevices, so a per-instance setting. I haven't walked through the details to know if it would work.
I didn't think about that. Good idea, that looks perfectly doable. But I'd still prefer to centralise the skb_reset_mac_header() call in a dedicated patch set. I we did it here, we'd have to not reset the mac header by default, to guarantee that unrelated tunnels wouldn't be affected.
However, I think that the default behaviour should be to reset the mac header and that only special cases, like the one in ip_gre, should explicitely turn that off. Therefore, we'd need a follow up patch anyway, to change the way this "reset_mac" flag would be set.
IMHO, the current approach has the advantage of clearly separating the new feature from the refactoring. But if you feel strongly about using a flag in struct ip_tunnel, I can rework this series.
Quoted 53 lines · Guillaume Nault
Quoted 38 lines · David Ahern
Quoted 28 lines · Guillaume Nault
Quoted 27 lines · David Ahern
Quoted 25 lines · Guillaume Nault
Some virtual L3 devices, like vxlan-gpe and gre (in
collect_mdmode), reset the MAC header pointer after they parsed the outer headers. This accurately reflects the fact that the decapsulated packet is pure L3 packet, as that makes the MAC header 0 bytes long (the MAC and network header pointers are equal).However, many L3 devices only adjust the network header after decapsulation and leave the MAC header pointer to its original value. This can confuse other parts of the networking stack, like TC, which then considers the outer headers as one big MAC header.
This patch series makes the following L3 tunnels behave like VXLAN-GPE:
bareudp, ipip, sit, gre, ip6gre, ip6tnl, gtp.The case of gre is a bit special. It already resets the MAC header pointer in
collect_mdmode, so only the classical mode needs to be adjusted. However, gre also has a special case that expects the MAC header pointer to keep pointing to the outer header even after decapsulation. Therefore, patch 4 keeps an exception for this case.Ideally, we'd centralise the call to
skb_reset_mac_header()inip_tunnel_rcv(), to avoid manual calls in ipip (patch 2), sit (patch 3) and gre (patch 4). That's unfortunately not feasible currently, because of the gre special case discussed above that precludes us from resetting the MAC header unconditionally.Quoted 8 lines
Quoted 2 lines
What about adding a flag to
ip_tunnelindicating if it can be done (or should not be done since doing it is the most common)?That's feasible. I didn't do it here because I wanted to keep the patch series focused on L3 tunnels. Modifying ip_tunnel_rcv()'s prototype would also require updating
erspan_rcv(), which isn't L3 (erspan carries Ethernet frames). I was feeling such consolidation would be best done in a follow up patch series.Quoted 3 lines
I was thinking a flag in 'struct
ip_tunnel'. It's the private data for those netdevices, so a per-instance setting. I haven't walked through the details to know if it would work.I didn't think about that. Good idea, that looks perfectly doable. But I'd still prefer to centralise the
skb_reset_mac_header()call in a dedicated patch set. I we did it here, we'd have to not reset the mac header by default, to guarantee that unrelated tunnels wouldn't be affected.
However, I think that the default behaviour should be to reset the mac header and that only special cases, like the one inip_gre, should explicitely turn that off. Therefore, we'd need a follow up patch anyway, to change the way this "reset_mac" flag would be set.
Quoted 4 lines
IMHO, the current approach has the advantage of clearly separating the new feature from the refactoring. But if you feel strongly about using a flag in struct
ip_tunnel, I can rework this series.
I am accustomed to doing refactoring first to add some new feature in the simplest and clearest way.
Quoted 54 lines · David Ahern
Quoted 53 lines · Guillaume Nault
Quoted 38 lines · David Ahern
Quoted 28 lines · Guillaume Nault
Quoted 27 lines · David Ahern
Quoted 25 lines · Guillaume Nault
Some virtual L3 devices, like vxlan-gpe and gre (in
collect_mdmode), reset the MAC header pointer after they parsed the outer headers. This accurately reflects the fact that the decapsulated packet is pure L3 packet, as that makes the MAC header 0 bytes long (the MAC and network header pointers are equal).However, many L3 devices only adjust the network header after decapsulation and leave the MAC header pointer to its original value. This can confuse other parts of the networking stack, like TC, which then considers the outer headers as one big MAC header.
This patch series makes the following L3 tunnels behave like VXLAN-GPE:
bareudp, ipip, sit, gre, ip6gre, ip6tnl, gtp.The case of gre is a bit special. It already resets the MAC header pointer in
collect_mdmode, so only the classical mode needs to be adjusted. However, gre also has a special case that expects the MAC header pointer to keep pointing to the outer header even after decapsulation. Therefore, patch 4 keeps an exception for this case.Ideally, we'd centralise the call to
skb_reset_mac_header()inip_tunnel_rcv(), to avoid manual calls in ipip (patch 2), sit (patch 3) and gre (patch 4). That's unfortunately not feasible currently, because of the gre special case discussed above that precludes us from resetting the MAC header unconditionally.Quoted 8 lines
Quoted 2 lines
What about adding a flag to
ip_tunnelindicating if it can be done (or should not be done since doing it is the most common)?That's feasible. I didn't do it here because I wanted to keep the patch series focused on L3 tunnels. Modifying ip_tunnel_rcv()'s prototype would also require updating
erspan_rcv(), which isn't L3 (erspan carries Ethernet frames). I was feeling such consolidation would be best done in a follow up patch series.Quoted 3 lines
I was thinking a flag in 'struct
ip_tunnel'. It's the private data for those netdevices, so a per-instance setting. I haven't walked through the details to know if it would work.I didn't think about that. Good idea, that looks perfectly doable. But I'd still prefer to centralise the
skb_reset_mac_header()call in a dedicated patch set. I we did it here, we'd have to not reset the mac header by default, to guarantee that unrelated tunnels wouldn't be affected.
However, I think that the default behaviour should be to reset the mac header and that only special cases, like the one inip_gre, should explicitely turn that off. Therefore, we'd need a follow up patch anyway, to change the way this "reset_mac" flag would be set.
Quoted 7 lines
Quoted 4 lines
IMHO, the current approach has the advantage of clearly separating the new feature from the refactoring. But if you feel strongly about using a flag in struct
ip_tunnel, I can rework this series.I am accustomed to doing refactoring first to add some new feature in the simplest and clearest way.
I agree on the general statement. Anyway, I've just received the patchwork-bot message saying the series has been applied. I'll follow up with the struct ip_tunnel flag once net-next reopens (as I guess it's about to close).
This series was applied to netdev/net-next.git (refs/heads/master):
Hello:
This series was applied to netdev/net-next.git (refs/heads/master):
Quoted 6 lines · On Fri, 25 Jun 2021 15:32:59 +0200 you wrote:
Some virtual L3 devices, like vxlan-gpe and gre (in
collect_mdmode), reset the MAC header pointer after they parsed the outer headers. This accurately reflects the fact that the decapsulated packet is pure L3 packet, as that makes the MAC header 0 bytes long (the MAC and network header pointers are equal).
Quoted 6 lines
However, many L3 devices only adjust the network header after decapsulation and leave the MAC header pointer to its original value. This can confuse other parts of the networking stack, like TC, which then considers the outer headers as one big MAC header.
[...]
Here is the summary with links:
- [net-next,1/6] bareudp: allow redirecting bareudp packets to eth devices
https://git.kernel.org/netdev/net-next/c/99c8719b7981 - [net-next,2/6] ipip: allow redirecting ipip and mplsip packets to eth devices https://git.kernel.org/netdev/net-next/c/7ad136fd288c - [net-next,3/6] sit: allow redirecting ip6ip, ipip and mplsip packets to eth devices https://git.kernel.org/netdev/net-next/c/730eed2772e7 - [net-next,4/6] gre: let mac_header point to outer header only when necessary https://git.kernel.org/netdev/net-next/c/aab1e898c26c - [net-next,5/6] ip6_tunnel: allow redirecting ip6gre and ipxip6 packets to eth devices https://git.kernel.org/netdev/net-next/c/da5a2e49f064 - [net-next,6/6] gtp: reset mac_header after decap https://git.kernel.org/netdev/net-next/c/b2d898c8a523
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html