jool: nat64 incorrect/bad checksum for tcp4 and udp4 Packets on mpc85xx/p1010
Nobody has claimed this yet.
- Dominant language
- Makefile
- Stars
- 4.6k
- Forks
- 4k
- Avg merge
- 3d 12h
- Merged PRs (30d)
- 134
Description
Maintainer:
Environment: mpc85xx/p1010 tplink_tl-wdr4900-v1 openwrt-23.05 and master
Description: In NAT64 mode the outgoing TCP4 and UDP4 Packets have incorrect checksum.
ICMP4 Packets have a correct checksum. It is reproducible with NAT64 for a IPv6-only network (Jool)
--WAN Port
# tcpdump -vv -n -i wan port 443
tcpdump: listening on wan, link-type EN10MB (Ethernet), snapshot length 262144 bytes
18:55:05.781478 IP (tos 0x0, ttl 63, id 38729, offset 0, flags [none], proto TCP (6), length 52) 10.230.6.111.65039 > 10.230.6.97.443: Flags [S], cksum 0x4a3a (incorrect -> 0x6cd6), seq 683981143, win 64998, options [mss 1413,nop,wscale 8,nop,nop,sackOK], length 0
# tcpdump -vv -n -i wan port 53
tcpdump: listening on wan, link-type EN10MB (Ethernet), snapshot length 262144 bytes
18:58:56.558108 IP (tos 0x0, ttl 63, id 56188, offset 0, flags [none], proto UDP (17), length 65) 10.230.6.111.61227 > 10.230.6.97.53: [bad udp cksum 0xd34c -> 0xf5e8!] 33906+ A? openwrt.localdomain. (37)
# tcpdump -vv -n -i wan icmp and host 10.230.6.97
tcpdump: listening on wan, link-type EN10MB (Ethernet), snapshot length 262144 bytes
19:01:13.227767 IP (tos 0x0, ttl 63, id 1800, offset 0, flags [none], proto ICMP (1), length 84) 10.230.6.111 > 10.230.6.97: ICMP echo request, id 1378, seq 1, length 64
--LAN Port
# tcpdump -vv -n -i br-lan port 443
tcpdump: listening on br-lan, link-type EN10MB (Ethernet), snapshot length 262144 bytes
18:55:05.781334 IP6 (flowlabel 0x04c88, hlim 64, next-header TCP (6) payload length: 32) fd43:992c:dac1:0:ac01:6e7a:8273:c4ee.20423 > 64:ff9b::ae6:661.443: Flags [S], cksum 0x5963 (correct), seq 683981143, win 64998, options [mss 1413,nop,wscale 8,nop,nop,sackOK], length 0
# tcpdump -vv -n -i br-lan port 53 and host 64:ff9b::ae6:661
tcpdump: listening on br-lan, link-type EN10MB (Ethernet), snapshot length 262144 bytes
18:58:56.557985 IP6 (flowlabel 0xf90a4, hlim 64, next-header UDP (17) payload length: 45) fd43:992c:dac1:0:ac01:6e7a:8273:c4ee.58641 > 64:ff9b::ae6:661.53: [udp sum ok] 33906+ A? openwrt.localdomain. (37)
# tcpdump -vv -n -i br-lan icmp6 and host 64:ff9b::ae6:661
tcpdump: listening on br-lan, link-type EN10MB (Ethernet), snapshot length 262144 bytes
19:01:13.227645 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 64) fd43:992c:dac1:0:ac01:6e7a:8273:c4ee > 64:ff9b::ae6:661: [icmp6 sum ok] ICMP6, echo request, id 141, seq 1
X86_64 and mvebu/cortexa9 is working fine.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Reproduce the NAT64/Jool setup on mpc85xx/p1010 using the WAN and LAN tcpdump captures in this report; compare the TCP4 and UDP4 checksums with the IPv6 packets and the working ICMP4 case. Done means outgoing translated TCP4 and UDP4 packets have valid checksums on openwrt-23.05 and master, matching the reported behavior on working platforms.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- linux
- Domain
- networking
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100