Re: IPv6 checksum errors with divert
Hi Andrey, hi all, there is at least one further issue with divert (and dummynet) and IPv6: If I put EITHER a divert OR a dummynet pipe/queue into the OUTgoing (layer3) ruleset to the uplink interface, then Youtube is not able to insert their advertisments into playback, and may hang entirly on playback. That seems to not happen due to timing or bandwith issues, but due to the sheer existance of a dummynet (or divert). And if I move the dummynet to the incoming, INTRAnet-facing side of the router, the problem does not appear. So there must still be some other bit in the IPv6 (or in the mbuf?) that gets improperly mangled during divert and also during dummynet. It appears a bit difficult to hunt that one down, due to the sheer amount of traffic involved in YT streaming, and also since I do not know exactly for what to look... Any helpful ideas are welcome. Cheerio, PMc
Re: IPv6 checksum errors with divert
Maybe with a tcpdump or packet capture search for http error codes; https://developer.mozilla.org/en-US/docs/Web/HTTP/Status has a list. 400 errors are what usually lead to errors clients observe while the server is still alive. Brian On 10/30/2021 4:33 PM, Peter wrote: Hi Andrey, hi all, there is at least one further issue with divert (and dummynet) and IPv6: If I put EITHER a divert OR a dummynet pipe/queue into the OUTgoing (layer3) ruleset to the uplink interface, then Youtube is not able to insert their advertisments into playback, and may hang entirly on playback. That seems to not happen due to timing or bandwith issues, but due to the sheer existance of a dummynet (or divert). And if I move the dummynet to the incoming, INTRAnet-facing side of the router, the problem does not appear. So there must still be some other bit in the IPv6 (or in the mbuf?) that gets improperly mangled during divert and also during dummynet. It appears a bit difficult to hunt that one down, due to the sheer amount of traffic involved in YT streaming, and also since I do not know exactly for what to look... Any helpful ideas are welcome. Cheerio, PMc
IPv6 inflight fragmentation
>From what I understood, inflight fragmentation (on an intermediate router) is not practical with IPv6. But it happens: This router has inbound ethernet and outbound PPPoE: vtnet0: flags=8943 metric 0 mtu 1500 tun0: flags=8151 metric 0 mtu 1492 And that's what is transported - Incoming on vtnet0: IP6 2003:e7:1740:a7e0:41d:92ff:fe01:222.20487 > 2a00:1450:4001:67::8.443: Flags [.], seq 0:1428, ack 1, win 1035, options [nop,nop,TS val 2061109754 ecr 739209924], length 1428 IP6 2003:e7:1740:a7e0:41d:92ff:fe01:222.20487 > 2a00:1450:4001:67::8.443: Flags [.], seq 0:1428, ack 1, win 1035, options [nop,nop,TS val 2061113154 ecr 739209924], length 1428 Outgoing on tun0: IP6 2003:e7:1740:a7e0:41d:92ff:fe01:222 > 2a00:1450:4001:67::8: frag (0|1440) 59241 > 443: Flags [.], seq 0:1408, ack 1, win 1035, options [nop,nop,TS val 2312762048 ecr 739149759], length 1408 IP6 2003:e7:1740:a7e0:41d:92ff:fe01:222 > 2a00:1450:4001:67::8: frag (1440|20) IP6 2003:e7:1740:a7e0:41d:92ff:fe01:222 > 2a00:1450:4001:67::8: frag (0|1440) 59243 > 443: Flags [.], seq 1:1409, ack 1, win 1035, options [nop,nop,TS val 3069543472 ecr 739199972], length 1408 IP6 2003:e7:1740:a7e0:41d:92ff:fe01:222 > 2a00:1450:4001:67::8: frag (1440|20) And it doesn't seem like these packets would be answered at all. This happens when there is a dummynet pipe/queue rule (or a divert rule) in the outbound rules to an interface that must reduce the MTU. As soon as we skip over that dummynet (or divert), we get these ICMPv6 messages at the other end, and the fragmentation ceases: 02:59:53.651258 IP6 2003:e7:1740:a7ff::2 > 2003:e7:1740:a7e0:41d:92ff:fe01:222: ICMP6, packet too big, mtu 1492, length 1240 02:59:53.693376 IP6 2003:e7:1740:a7ff::2 > 2003:e7:1740:a7e0:41d:92ff:fe01:222: ICMP6, packet too big, mtu 1492, length 1240 So the problem is with dummynet and divert. Cheerio, PMc
