On Wed, Nov 4, 2020 at 7:53 PM lina.wang <lina.w...@mediatek.com> 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: > > 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: > > > On Tue, Sep 15, 2020 at 08:17:40PM +0800, lina.wang wrote: > > > > 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. > > > > > > > On Tue, 2020-09-15 at 11:32 +0200, Steffen Klassert wrote: > > > > > On Tue, Sep 15, 2020 at 05:05:22PM +0800, lina.wang wrote: > > > > > > > > > > > > Yes, DF bit is not set. > > > > > > > > > > ... > > > > > > > > > > > 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...