Hi,
The final destination address for the packet is
505:505:505:505:505:505:505:505. Why would you think it is not?
When the kernel is routing the packet (at 4ea1:2222:2222::11) it does
not look at the UDP checksum to accept/reject it.
Regards,
João
On 7/8/21 7:56 PM, Hupfer, Michael via Wireshark-dev wrote:
Please see packet 4 of the atached capture
In my opinion checksum 0xc343 is actually correct, since it is
calculated using the final destination address 4ea1:2222:2222::11, but
wireshark reports 0x2e12 as correct, which is the result of the
checksum calculation if the address from the extension header
505:505:505:505:505:505:505:505 is used.
Please refer to RFC 2460:
If the IPv6 packet contains a Routing header, the Destination
Address used in the pseudo-header is that of the *final*
*destination*. At the originating node, that address will be in
the last element of the Routing header; at the recipient(s),
that address will be in the Destination Address field of the
IPv6 header.
In addition, the Linux kernel accepts the UDP packet.
3.4.6 (v3.4.6-0-g6357ac1405b8)
Compiled (64-bit) with Qt 5.15.2, with libpcap, with GLib 2.52.3, with
zlib
1.2.11, with SMI 0.4.8, with c-ares 1.15.0, with Lua 5.2.4, with
GnuTLS 3.6.3
and PKCS #11 support, with Gcrypt 1.8.3, with MIT Kerberos, with
MaxMind DB
resolver, with nghttp2 1.39.2, with brotli, with LZ4, with Zstandard, with
Snappy, with libxml2 2.9.9, with QtMultimedia, with automatic updates
using
WinSparkle 0.5.7, with AirPcap, with SpeexDSP (using bundled
resampler), with
Minizip.
Running on 64-bit Windows 10 (2009), build 19043, with Intel(R) Core(TM)
i7-8665U CPU @ 1.90GHz (with SSE4.2), with 32483 MB of physical
memory, with
locale German_Germany.utf8, with light display mode, without HiDPI,
with Npcap
version 1.31, based on libpcap version 1.10.1-PRE-GIT, with GnuTLS
3.6.3, with
Gcrypt 1.8.3, with brotli 1.0.2, without AirPcap, binary plugins
supported (21
loaded).
Built using Microsoft Visual Studio 2019 (VC++ 14.28, build 29910).
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
