Your message dated Tue, 03 Sep 2024 03:16:14 +0200 with message-id <ea2c09756c209c3039fd3e1cd1a7951ea28f9b1d.camel@decadent.org.uk> and subject line Re: Bug#1078997: gretap tunnel with checksum enabled: some packets have zero checksum has caused the Debian Bug report #1078997, regarding gretap tunnel with checksum enabled: some packets have zero checksum to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact owner@bugs.debian.org immediately.) -- 1078997: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078997 Debian Bug Tracking System Contact owner@bugs.debian.org with problems
--- Begin Message ---
- To: submit@bugs.debian.org
- Subject: gretap tunnel with checksum enabled: some packets have zero checksum
- From: Роман Мещеряков <romanmescheryakov@yandex.ru>
- Date: Sun, 18 Aug 2024 21:07:10 +0300
- Message-id: <8306001724004430@6yorfbioao7cchjm.vla.yp-c.yandex.net>
Package: iproute2 Version: 6.1.0-3 I have 2 servers named potok1 and potok2. Each of them has many network interfaces: potok1: ip -br a lo UNKNOWN 127.0.0.1/8 ::1/128 ens5f0 UP 172.16.1.1/24 fe80::b696:91ff:fe94:3a74/64 ens5f1 DOWN 172.16.2.1/24 fe80::b696:91ff:fe94:3a75/64 ens5f2 DOWN 172.16.3.1/24 fe80::b696:91ff:fe94:3a76/64 ens5f3 DOWN 172.16.4.1/24 ens3f0 DOWN 172.16.5.1/24 fe80::b696:91ff:fe94:3590/64 ens3f1 DOWN 172.16.6.1/24 fe80::b696:91ff:fe94:3591/64 ens3f2 DOWN 172.16.7.1/24 fe80::b696:91ff:fe94:3592/64 ens3f3 DOWN 172.16.8.1/24 fe80::b696:91ff:fe94:3593/64 enp5s0 UP 10.10.36.62/24 enp6s0 UP 172.16.0.1/24 fe80::6d4:c4ff:fe5b:dfc5/64 potok2: ip -br a lo UNKNOWN 127.0.0.1/8 ::1/128 ens5f0 UP 172.16.1.2/24 fe80::b696:91ff:fe94:36c4/64 ens5f1 DOWN 172.16.2.2/24 fe80::b696:91ff:fe94:36c5/64 ens5f2 DOWN 172.16.3.2/24 fe80::b696:91ff:fe94:36c6/64 ens5f3 DOWN 172.16.4.2/24 ens3f0 DOWN 172.16.5.2/24 fe80::b696:91ff:fe94:361c/64 ens3f1 DOWN 172.16.6.2/24 fe80::b696:91ff:fe94:361d/64 ens3f2 DOWN 172.16.7.2/24 fe80::b696:91ff:fe94:361e/64 ens3f3 DOWN 172.16.8.2/24 fe80::b696:91ff:fe94:361f/64 enp5s0 UP 10.10.36.78/24 fe80::5a05:5f0e:95f2:112d/64 enp6s0 UP 172.16.0.2/24 fe80::6d4:c4ff:fe5b:f093/64 The ens5f0 interfaces of these servers are connected via switch. I configure potok1 using the following commands: sudo ip link add tap12 type gretap csum local 172.16.1.1 remote 172.16.1.2 sudo ip addr add 192.168.0.1/30 dev tap12 sudo ip link set ens5f3 down sudo ip link set tap12 up sudo ip route add 172.16.4.0/24 via 192.168.0.2 sudo ip addr del fe80::64bf:5eff:fe2c:c18e/64 dev tap12 #Don't want IPv6 for tunnel interface I configure potok2 using the following commands: sudo ip link add tap21 type gretap csum local 172.16.1.2 remote 172.16.1.1 sudo ip addr add 192.168.0.2/30 dev tap21 sudo ip link set ens5f3 down sudo ip link set tap21 up sudo ip route add 172.16.4.0/24 via 192.168.0.1 sudo ip addr del fe80::3ca5:93ff:fe79:2602/64 dev tap21 #Don't want IPv6 for tunnel interface Then I ping potok2 from potok1: ping 172.16.4.2 -c 1 I expect that ICMP packets will trip through gretap tunnel there and back and have Checksum Present flag (see RFC 1701 Generic Routing Encapsulation) set. I checked this using tcpdump utility and this is as expected, but I discovered problem with GRE Checksum field. Expected behavior: These tunneled ICMP packets have GRE Checksum field (see RFC 1701) populated with a correct value. Observed behavior: For ICMP echo request packet: as expected. For ICMP echo reply packet: GRE Checksum field is zero! tcpdump utility on potok2 server gave me the following output: sudo tcpdump -e -n -v -xx -i ens5f0 19:08:33.665503 b4:96:91:94:3a:74 > b4:96:91:94:36:c4, ethertype IPv4 (0x0800), length 140: (tos 0x0, ttl 64, id 6361, offset 0, flags [DF], proto GRE (47), length 126) 172.16.1.1 > 172.16.1.2: GREv0, Flags [checksum present], sum 0x940b, off 0x0, proto TEB (0x6558), length 106 66:bf:5e:2c:c1:8e > 3e:a5:93:79:26:02, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 58932, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.0.1 > 172.16.4.2: ICMP echo request, id 58579, seq 1, length 64 0x0000: b496 9194 36c4 b496 9194 3a74 0800 4500 0x0010: 007e 18d9 4000 402f c754 ac10 0101 ac10 0x0020: 0102 8000 6558 940b 0000 3ea5 9379 2602 0x0030: 66bf 5e2c c18e 0800 4500 0054 e634 4000 0x0040: 4001 e3b8 c0a8 0001 ac10 0402 0800 77f8 0x0050: e4d3 0001 01b3 ab66 0000 0000 2546 0a00 0x0060: 0000 0000 1011 1213 1415 1617 1819 1a1b 0x0070: 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 0x0080: 2c2d 2e2f 3031 3233 3435 3637 19:08:33.665530 b4:96:91:94:36:c4 > b4:96:91:94:3a:74, ethertype IPv4 (0x0800), length 140: (tos 0x0, ttl 64, id 24440, offset 0, flags [DF], proto GRE (47), length 126) 172.16.1.2 > 172.16.1.1: GREv0, Flags [checksum present], sum 0x0, off 0x0, proto TEB (0x6558), length 106 3e:a5:93:79:26:02 > 66:bf:5e:2c:c1:8e, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 7185, offset 0, flags [none], proto ICMP (1), length 84) 172.16.4.2 > 192.168.0.1: ICMP echo reply, id 58579, seq 1, length 64 0x0000: b496 9194 3a74 b496 9194 36c4 0800 4500 0x0010: 007e 5f78 4000 402f 80b5 ac10 0102 ac10 0x0020: 0101 8000 6558 0000 0000 66bf 5e2c c18e 0x0030: 3ea5 9379 2602 0800 4500 0054 1c11 0000 0x0040: 4001 eddc ac10 0402 c0a8 0001 0000 7ff8 0x0050: e4d3 0001 01b3 ab66 0000 0000 2546 0a00 0x0060: 0000 0000 1011 1213 1415 1617 1819 1a1b 0x0070: 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 0x0080: 2c2d 2e2f 3031 3233 3435 3637 (See "sum 0x0" for ICMP echo reply packet). To additionally check whether zero checksum is good or not, I decoded bytes output by tcpdump using online Hex Packet Decoder (https://hpd.gasmi.net/) which reported the following: Checksum: 0x0000 incorrect, should be 0x940b Expert Info (Warning/Protocol): Incorrect GRE Checksum [should be 0x940b] Checksum Status: Bad Additional information: -- System Information: Debian Release: 12.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-23-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages iproute2 depends on: ii debconf [debconf-2.0] 1.5.82 ii libbpf1 1:1.1.0-1 ii libbsd0 0.11.7-2 ii libc6 2.36-9+deb12u7 ii libcap2 1:2.66-4 ii libcap2-bin 1:2.66-4 ii libdb5.3 5.3.28+dfsg2-1 ii libelf1 0.188-2.1 ii libmnl0 1.0.4-3 ii libselinux1 3.4-1+b6 ii libtirpc3 1.3.3+ds-1 ii libxtables12 1.8.9-2 Versions of packages iproute2 recommends: pn libatm1 <none> Versions of packages iproute2 suggests: pn iproute2-doc <none> ii python3 3.11.2-1+b1 -- debconf information: iproute2/setcaps: false user@potok2:~$ uname -a Linux potok2 6.1.0-23-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.99-1 (2024-07-15) x86_64 GNU/Linux -- Roman Mescheryakov
--- End Message ---
--- Begin Message ---
- To: 1078997-done@bugs.debian.org
- Subject: Re: Bug#1078997: gretap tunnel with checksum enabled: some packets have zero checksum
- From: Ben Hutchings <ben@decadent.org.uk>
- Date: Tue, 03 Sep 2024 03:16:14 +0200
- Message-id: <ea2c09756c209c3039fd3e1cd1a7951ea28f9b1d.camel@decadent.org.uk>
- In-reply-to: <[🔎] 1317661725268091@gkcrf2nurtnzrdvs.vla.yp-c.yandex.net>
- References: <8306001724004430@6yorfbioao7cchjm.vla.yp-c.yandex.net> <0d95d57bb93c5a6f29cead8e6208244346d2b04e.camel@debian.org> <503631724097818@mail.yandex.ru> <CAMw=ZnQqqJmxSEncJ-y5cZ-w8mZtqjH0-VU8Hj5f9sDgpVxaeQ@mail.gmail.com> <1233881724688710@jizoyk2ozf2hzigw.sas.yp-c.yandex.net> <[🔎] 995119cd0d81738ea6d84be9b8a038505f8f2549.camel@decadent.org.uk> <[🔎] 1317661725268091@gkcrf2nurtnzrdvs.vla.yp-c.yandex.net>
On Mon, 2024-09-02 at 12:08 +0300, Роман Мещеряков wrote: > Here it is: > user@potok2:~$ sudo ethtool -k ens5f0 | grep tx-gre-csum-segmentation > tx-gre-csum-segmentation: on So GRE checksums are being generated on the network device. This is why they do not appear in the packets captured on transmission, only in the packets captured on reception. This is not a bug. Ben. -- Ben Hutchings The two most common things in the universe are hydrogen and stupidity.Attachment: signature.asc
Description: This is a digitally signed message part
--- End Message ---