Re: [PATCH] xfrm:fragmented ipv4 tunnel packets in inner interface

On Wed, Nov 4, 2020 at 7:53 PM lina.wang [off-list ref] wrote:

Besides several operators donot fragment packets even DF bit is not set,
and instead just drop packets which they think big, maybe they have a
consideration--- fragmentation is expensive for both the router that
fragments and for the host that reassembles.

BTW, ipv6 has the different behaviour when it meets such scenary, which
is what we expected,ipv4 should follow the same thing. otherwise,
packets are drop, it is a serious thing, and there is no hints. What we
do is just fragmenting smaller packets, or is it possible to give us
some flag or a sysctl to allow us to change the behaviour?

On Thu, 2020-09-17 at 19:19 +0800, lina.wang wrote:

quoted

But it is not just one operator's broken router or misconfigured
router.In the whole network, it is common to meet that router will drop
bigger packet silently.I think we should make code more compatible.and
the scenary is wifi calling, which mostly used udp,you know, udp
wouldnot retransmit.It is serious when packet is dropped

On Thu, 2020-09-17 at 09:46 +0200, Steffen Klassert wrote:

quoted

On Tue, Sep 15, 2020 at 08:17:40PM +0800, lina.wang wrote:

quoted

We didnot get the router's log, which is some operator's.Actually, after
we patched, there is no such issue. Sometimes,router will return
packet-too-big, most of times nothing returned,dropped silently

This looks like a broken router, we can't fix that in the code.

quoted

On Tue, 2020-09-15 at 11:32 +0200, Steffen Klassert wrote:

quoted

On Tue, Sep 15, 2020 at 05:05:22PM +0800, lina.wang wrote:

quoted

Yes, DF bit is not set.

...

quoted

Those two packets are fragmented to one big udp packet, which payload is 1516B.
After getting rid of tunnel header, it is also a udp packet, which payload is
1466 bytes.It didnot get any response for this packet.We guess it is dropped
by router. Because if we reduced the length, it got response.

If the DF bit is not set, the router should fragment the packet. If it
does not do so, it is misconfigured. Do you have access to that router?

I'm afraid I don't really understand the exact scenario from the
description of the patch.

However... a few questions come to mind.
(a) why not set the DF flag, does the protocol require > mtu udp frames
(b) what is the mtu of the inner tunnel device, and what is the mtu on
the route through the device?
- shouldn't we be udp fragmenting to the route/device mtu?
maybe stuff is simply misconfigured...