QUIC protocol causes Fragmentation in Batman

[lemoer]

excerpt on sn07:

root@sn07:~# tcpdump -n -i mesh_fastd ether proto 0x4305 and ether[14] == 0x41 | grep length
05:48:37.300315 88:e6:40:20:70:01 > 88:e6:40:20:40:01, ethertype Unknown (0x4305), length 1408: 
05:48:37.300320 88:e6:40:20:70:01 > 88:e6:40:20:40:01, ethertype Unknown (0x4305), length 62: 
05:48:37.300334 88:e6:40:20:70:01 > 88:e6:40:20:40:01, ethertype Unknown (0x4305), length 1408: 
05:48:37.300336 88:e6:40:20:70:01 > 88:e6:40:20:40:01, ethertype Unknown (0x4305), length 62: 
05:48:37.300346 88:e6:40:20:70:01 > 88:e6:40:20:40:01, ethertype Unknown (0x4305), length 1408: 
05:48:37.300348 88:e6:40:20:70:01 > 88:e6:40:20:40:01, ethertype Unknown (0x4305), length 62: 
05:48:37.300381 88:e6:40:20:70:01 > 88:e6:40:20:40:01, ethertype Unknown (0x4305), length 1408: 
05:48:37.300383 88:e6:40:20:70:01 > 88:e6:40:20:40:01, ethertype Unknown (0x4305), length 62: 
05:48:37.300392 88:e6:40:20:70:01 > 88:e6:40:20:40:01, ethertype Unknown (0x4305), length 1408: 
05:48:37.300396 88:e6:40:20:70:01 > 88:e6:40:20:40:01, ethertype Unknown (0x4305), length 62: 
05:48:37.300406 88:e6:40:20:70:01 > 88:e6:40:20:40:01, ethertype Unknown (0x4305), length 1408: 
05:48:37.300408 88:e6:40:20:70:01 > 88:e6:40:20:40:01, ethertype Unknown (0x4305), length 62: 
05:48:37.300417 88:e6:40:20:70:01 > 88:e6:40:20:40:01, ethertype Unknown (0x4305), length 1408: 
05:48:37.300420 88:e6:40:20:70:01 > 88:e6:40:20:40:01, ethertype Unknown (0x4305), length 62: 
05:48:37.300429 88:e6:40:20:70:01 > 88:e6:40:20:40:01, ethertype Unknown (0x4305), length 1408: 
05:48:37.300431 88:e6:40:20:70:01 > 88:e6:40:20:40:01, ethertype Unknown (0x4305), length 62: 
05:48:37.300439 88:e6:40:20:70:01 > 88:e6:40:20:40:01, ethertype Unknown (0x4305), length 1408: 
05:48:37.300443 88:e6:40:20:70:01 > 88:e6:40:20:40:01, ethertype Unknown (0x4305), length 62: 
05:48:37.303202 88:e6:40:20:70:01 > 88:e6:40:20:40:01, ethertype Unknown (0x4305), length 1408: 
05:48:37.303208 88:e6:40:20:70:01 > 88:e6:40:20:40:01, ethertype Unknown (0x4305), length 62: 
05:48:37.306680 88:e6:40:20:70:01 > 88:e6:40:20:40:01, ethertype Unknown (0x4305), length 1408: 
05:48:37.306684 88:e6:40:20:70:01 > 88:e6:40:20:40:01, ethertype Unknown (0x4305), length 62: 
05:48:37.309060 88:e6:40:20:70:01 > 88:e6:40:20:40:01, ethertype Unknown (0x4305), length 1408: 
05:48:37.309064 88:e6:40:20:70:01 > 88:e6:40:20:40:01, ethertype Unknown (0x4305), length 62: 
05:48:37.312613 88:e6:40:20:70:01 > 88:e6:40:20:40:01, ethertype Unknown (0x4305), length 1408: 
05:48:37.312619 88:e6:40:20:70:01 > 88:e6:40:20:40:01, ethertype Unknown (0x4305), length 62: 
05:48:37.315289 88:e6:40:20:70:01 > 88:e6:40:20:40:01, ethertype Unknown (0x4305), length 1408: 
05:48:37.315294 88:e6:40:20:70:01 > 88:e6:40:20:40:01, ethertype Unknown (0x4305), length 62: 
05:48:37.318503 88:e6:40:20:70:01 > 88:e6:40:20:40:01, ethertype Unknown (0x4305), length 1408: 
05:48:37.318507 88:e6:40:20:70:01 > 88:e6:40:20:40:01, ethertype Unknown (0x4305), length 62: 
05:48:37.320675 88:e6:40:20:70:01 > 88:e6:40:20:40:01, ethertype Unknown (0x4305), length 1408: 
05:48:37.320680 88:e6:40:20:70:01 > 88:e6:40:20:40:01, ethertype Unknown (0x4305), length 62: 
05:48:37.324225 88:e6:40:20:70:01 > 88:e6:40:20:40:01, ethertype Unknown (0x4305), length 1408: 
05:48:37.324230 88:e6:40:20:70:01 > 88:e6:40:20:40:01, ethertype Unknown (0x4305), length 62: 
05:48:37.326614 88:e6:40:20:70:01 > 88:e6:40:20:40:01, ethertype Unknown (0x4305), length 1408: 
05:48:37.326619 88:e6:40:20:70:01 > 88:e6:40:20:40:01, ethertype Unknown (0x4305), length 62: 
05:48:37.329365 88:e6:40:20:70:01 > 88:e6:40:20:40:01, ethertype Unknown (0x4305), length 1408: 

maybe mss fix is not working correctly or we should announce mtu via dhcp.

[lemoer]

By using

timeout -s SIGHUP 10 tcpdump -n -i mesh_fastd ether proto 0x4305 and ether[14] == 0x41 -w /dev/null | grep length

you can capure exactly 10 seconds.

script:

#!/bin/sh

sn="sn01 sn04 sn06 sn07 sn08 sn09 sn10"

for s in $sn; do
	echo -n ${s} unicast\ 
       ssh ${s} timeout -s SIGHUP 10 tcpdump -n -i mesh_fastd ether proto 0x4305 and ether[14] == 0x40 -w /dev/null 2>&1 | grep "packets captured"
	echo -n ${s} fragment \ 
       ssh ${s} timeout -s SIGHUP 10 tcpdump -n -i mesh_fastd ether proto 0x4305 and ether[14] == 0x01 -w /dev/null  2>&1 | grep "packets captured"
done

[lemoer]

Messungen:

sn01 unicast 20625 packets captured
sn01 fragment  41403 packets captured
sn04 unicast 13529 packets captured
sn04 fragment  28247 packets captured
sn06 unicast
sn06 fragment
sn07 unicast 26222 packets captured
sn07 fragment  33097 packets captured
sn08 unicast 53993 packets captured
sn08 fragment  12164 packets captured
sn09 unicast 13374 packets captured
sn09 fragment  8083 packets captured
sn10 unicast
sn10 fragment                     

[lemoer]

A protocol named "QUIC" udp/443, which google uses in google chrome seems to cause a lot of the traffic.

[1977er]

Is this still a thing? Do we ignore it?

[lemoer]

I guess, it is still a thing in general... It was never really answered what to do with this.

[lemoer]

Fragmenting this much traffic can't be efficient, can it?

[CodeFetch]

lemoer suggested to filter the port completely. I'm against filtering the port completely (against our philosophy). I think we should behave according to the standard and only drop packets which are too big and reply with an ICMP "too big" packet as implemented in PR #107. This allows correctly configured servers (seemingly everything but Google) to use QUIC.

[1977er]

Filtering what? 443/udp? I don't like to burn a whole port just because some applications using it behave strange.

[1977er]

Do we (continue to) ignore it?

[lemoer]

Quic has become official http/3 standard.