Your message dated Tue, 03 Sep 2024 03:16:14 +0200
with message-id <ea2c09756c209c3039fd3e1cd1a7951ea28f9b1d.ca...@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 ow...@bugs.debian.org
immediately.)
--
1078997: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078997
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
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 ---
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.
signature.asc
Description: This is a digitally signed message part
--- End Message ---
