Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.kernel > #83525 > unrolled thread
| Started by | Роман Мещеряков <romanmescheryakov@yandex.ru> |
|---|---|
| First post | 2024-08-18 20:10 +0200 |
| Last post | 2024-09-03 03:30 +0200 |
| Articles | 8 — 4 participants |
Back to article view | Back to linux.debian.kernel
Bug#1078997: gretap tunnel with checksum enabled: some packets have zero checksum Роман Мещеряков <romanmescheryakov@yandex.ru> - 2024-08-18 20:10 +0200
Bug#1078997: gretap tunnel with checksum enabled: some packets have zero checksum Luca Boccassi <bluca@debian.org> - 2024-08-19 17:00 +0200
Processed: Re: gretap tunnel with checksum enabled: some packets have zero checksum "Debian Bug Tracking System" <owner@bugs.debian.org> - 2024-08-19 17:00 +0200
Bug#1078997: gretap tunnel with checksum enabled: some packets have zero checksum Luca Boccassi <bluca@debian.org> - 2024-08-19 22:30 +0200
Bug#1078997: gretap tunnel with checksum enabled: some packets have zero checksum Роман Мещеряков <romanmescheryakov@yandex.ru> - 2024-08-26 19:00 +0200
Bug#1078997: gretap tunnel with checksum enabled: some packets have zero checksum Ben Hutchings <ben@decadent.org.uk> - 2024-09-01 20:00 +0200
Bug#1078997: gretap tunnel with checksum enabled: some packets have zero checksum Роман Мещеряков <romanmescheryakov@yandex.ru> - 2024-09-02 11:30 +0200
Bug#1078997: marked as done (gretap tunnel with checksum enabled: some packets have zero checksum) "Debian Bug Tracking System" <owner@bugs.debian.org> - 2024-09-03 03:30 +0200
| From | Роман Мещеряков <romanmescheryakov@yandex.ru> |
|---|---|
| Date | 2024-08-18 20:10 +0200 |
| Subject | Bug#1078997: gretap tunnel with checksum enabled: some packets have zero checksum |
| Message-ID | <JcSvL-5Vst-1@gated-at.bofh.it> |
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
[toc] | [next] | [standalone]
| From | Luca Boccassi <bluca@debian.org> |
|---|---|
| Date | 2024-08-19 17:00 +0200 |
| Message-ID | <Jdc1r-67Gj-19@gated-at.bofh.it> |
| In reply to | #83525 |
[Multipart message — attachments visible in raw view] — view raw
Control: tags -1 moreinfo On Sun, 18 Aug 2024 21:07:10 +0300 =?utf- 8?B?0KDQvtC80LDQvSDQnNC10YnQtdGA0Y/QutC+0LI=?= <romanmescheryakov@yandex.ru> wrote: > Package: iproute2 > Version: 6.1.0-3 Hi, Can you reproduce the same issue on testing or unstable? -- Kind regards, Luca Boccassi
[toc] | [prev] | [next] | [standalone]
| From | "Debian Bug Tracking System" <owner@bugs.debian.org> |
|---|---|
| Date | 2024-08-19 17:00 +0200 |
| Subject | Processed: Re: gretap tunnel with checksum enabled: some packets have zero checksum |
| Message-ID | <Jdc1s-67Gj-25@gated-at.bofh.it> |
| In reply to | #83525 |
Processing control commands: > tags -1 moreinfo Bug #1078997 [iproute2] gretap tunnel with checksum enabled: some packets have zero checksum Added tag(s) moreinfo. -- 1078997: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078997 Debian Bug Tracking System Contact owner@bugs.debian.org with problems
[toc] | [prev] | [next] | [standalone]
| From | Luca Boccassi <bluca@debian.org> |
|---|---|
| Date | 2024-08-19 22:30 +0200 |
| Message-ID | <JdhaN-6aVv-1@gated-at.bofh.it> |
| In reply to | #83525 |
Both kernel and iproute2, backports is fine too On Mon, 19 Aug 2024 at 21:15, Роман Мещеряков <romanmescheryakov@yandex.ru> wrote: > > Luca, sorry if my question is silly. Do you mean "testing or unstable" iproute2 package, Debian kernel or complete fresh Debian installation? > -- > Kind regards, Roman Mescheryakov > > > 19.08.2024, 17:48, "Luca Boccassi" <bluca@debian.org>: > > Control: tags -1 moreinfo > > On Sun, 18 Aug 2024 21:07:10 +0300 =?utf- > 8?B?0KDQvtC80LDQvSDQnNC10YnQtdGA0Y/QutC+0LI=?= > <romanmescheryakov@yandex.ru> wrote: > > Package: iproute2 > Version: 6.1.0-3 > > > Hi, > > Can you reproduce the same issue on testing or unstable? > > > -- > Kind regards, > Luca Boccassi
[toc] | [prev] | [next] | [standalone]
| From | Роман Мещеряков <romanmescheryakov@yandex.ru> |
|---|---|
| Date | 2024-08-26 19:00 +0200 |
| Message-ID | <JfLep-7O4B-5@gated-at.bofh.it> |
| In reply to | #83532 |
Updated kernel to version 6.9.7+bpo and iproute2 package to version 6.9.0-1~bpo12+1 on both servers, the bug is still reproduced:
user@potok2:~$ sudo tcpdump -e -n -v -xx -i ens5f0
tcpdump: listening on ens5f0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
<RSTP packet removed>
18:59:58.207520 b4:96:91:94:3a:74 > b4:96:91:94:36:1c, ethertype IPv4 (0x0800), length 140: (tos 0x0, ttl 64, id 50867, 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 53099, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.0.1 > 172.16.4.2: ICMP echo request, id 61963, seq 1, length 64
0x0000: b496 9194 361c b496 9194 3a74 0800 4500
0x0010: 007e c6b3 4000 402f 197a ac10 0101 ac10
0x0020: 0102 8000 6558 940b 0000 3ea5 9379 2602
0x0030: 66bf 5e2c c18e 0800 4500 0054 cf6b 4000
0x0040: 4001 fa81 c0a8 0001 ac10 0402 0800 dcde
0x0050: f20b 0001 7ea6 cc66 0000 0000 1c34 0300
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
18:59:58.207552 b4:96:91:94:36:1c > b4:96:91:94:3a:74, ethertype IPv4 (0x0800), length 140: (tos 0x0, ttl 64, id 5001, 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 24156, offset 0, flags [none], proto ICMP (1), length 84)
172.16.4.2 > 192.168.0.1: ICMP echo reply, id 61963, seq 1, length 64
0x0000: b496 9194 3a74 b496 9194 361c 0800 4500
0x0010: 007e 1389 4000 402f cca4 ac10 0102 ac10
0x0020: 0101 8000 6558 0000 0000 66bf 5e2c c18e
0x0030: 3ea5 9379 2602 0800 4500 0054 5e5c 0000
0x0040: 4001 ab91 ac10 0402 c0a8 0001 0000 e4de
0x0050: f20b 0001 7ea6 cc66 0000 0000 1c34 0300
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
<RSTP packet removed>
^C
4 packets captured
4 packets received by filter
0 packets dropped by kernel
user@potok2:~$ uname -r
6.9.7+bpo-amd64
user@potok2:~$ sudo apt show iproute2
Package: iproute2
Version: 6.9.0-1~bpo12+1
> Both kernel and iproute2, backports is fine too
>
> On Mon, 19 Aug 2024 at 21:15, Роман Мещеряков
> <romanmescheryakov@yandex.ru> wrote:
>
>> Luca, sorry if my question is silly. Do you mean "testing or unstable" iproute2 package, Debian kernel or complete fresh Debian installation?
>> --
>> Kind regards, Roman Mescheryakov
>>
>> 19.08.2024, 17:48, "Luca Boccassi" <bluca@debian.org>:
>>
>> Control: tags -1 moreinfo
>>
>> On Sun, 18 Aug 2024 21:07:10 +0300 =?utf-
>> 8?B?0KDQvtC80LDQvSDQnNC10YnQtdGA0Y/QutC+0LI=?=
>> <romanmescheryakov@yandex.ru> wrote:
>>
>> Package: iproute2
>> Version: 6.1.0-3
>>
>> Hi,
>>
>> Can you reproduce the same issue on testing or unstable?
>>
>> --
>> Kind regards,
>> Luca Boccassi
[toc] | [prev] | [next] | [standalone]
| From | Ben Hutchings <ben@decadent.org.uk> |
|---|---|
| Date | 2024-09-01 20:00 +0200 |
| Message-ID | <JhX1L-9gbp-1@gated-at.bofh.it> |
| In reply to | #83702 |
[Multipart message — attachments visible in raw view] — view raw
On Mon, 26 Aug 2024 19:11:50 +0300 =?utf-
8?B?0KDQvtC80LDQvSDQnNC10YnQtdGA0Y/QutC+0LI=?=
<romanmescheryakov@yandex.ru> wrote:
> Updated kernel to version 6.9.7+bpo and iproute2 package to version
6.9.0-1~bpo12+1 on both servers, the bug is still reproduced:
>
> user@potok2:~$ sudo tcpdump -e -n -v -xx -i ens5f0
[...]
Please send the output of:
ethtool -k ens5f0 | grep tx-gre-csum-segmentation
Ben.
--
Ben Hutchings
Q. Which is the greater problem in the world today,
ignorance or apathy?
A. I don't know and I couldn't care less.
[toc] | [prev] | [next] | [standalone]
| From | Роман Мещеряков <romanmescheryakov@yandex.ru> |
|---|---|
| Date | 2024-09-02 11:30 +0200 |
| Message-ID | <JibxL-9pWu-1@gated-at.bofh.it> |
| In reply to | #83798 |
Here it is: user@potok2:~$ sudo ethtool -k ens5f0 | grep tx-gre-csum-segmentation tx-gre-csum-segmentation: on > On Mon, 26 Aug 2024 19:11:50 +0300 =?utf- > 8?B?0KDQvtC80LDQvSDQnNC10YnQtdGA0Y/QutC+0LI=?= > <romanmescheryakov@yandex.ru> wrote: > >> Updated kernel to version 6.9.7+bpo and iproute2 package to version > > 6.9.0-1~bpo12+1 on both servers, the bug is still reproduced: > >> user@potok2:~$ sudo tcpdump -e -n -v -xx -i ens5f0 > > [...] > > Please send the output of: > > ethtool -k ens5f0 | grep tx-gre-csum-segmentation > > Ben. > > -- > Ben Hutchings > Q. Which is the greater problem in the world today, > ignorance or apathy? > A. I don't know and I couldn't care less.
[toc] | [prev] | [next] | [standalone]
| From | "Debian Bug Tracking System" <owner@bugs.debian.org> |
|---|---|
| Date | 2024-09-03 03:30 +0200 |
| Subject | Bug#1078997: marked as done (gretap tunnel with checksum enabled: some packets have zero checksum) |
| Message-ID | <JiqwN-9zOB-1@gated-at.bofh.it> |
| In reply to | #83525 |
[Multipart message — attachments visible in raw view] — view raw
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
[toc] | [prev] | [standalone]
Back to top | Article view | linux.debian.kernel
csiph-web