BR in docker reporting bad UDP checksum from router Link Request

[jkcko]

I am running the docker openthread/otbr image (latest as of 20 Feb 2024) openthread/otbr@sha256:613ff44ea7ff030c24d1e4c0d8565d2880d35d5f89d4d9cd1ce839a3cd110cdd
and trying to get a CLI-FTD device to join it. I've configured the dataset on the joiner from the dataset active -x dump from the OTBR and configured wireshark with the network decryption key.

The OTBR reports "Bad UDP checksum" (0x5cf) for the Link Request from the FTD.

Feb 24 00:45:02 83551ab5ad71 otbr-agent[195]: 00:01:52.366 [I] MeshForwarder-: Received IPv6 UDP msg, len:80, chksum:05cf, ecn:no, from:96af302843d35a33, sec:no, prio:net, rss:-40.0
Feb 24 00:45:02 83551ab5ad71 otbr-agent[195]: 00:01:52.366 [I] MeshForwarder-: src:[fe80:0:0:0:94af:3028:43d3:5a33]:19788
Feb 24 00:45:02 83551ab5ad71 otbr-agent[195]: 00:01:52.366 [I] MeshForwarder-: dst:[ff02:0:0:0:0:0:0:2]:19788
Feb 24 00:45:02 83551ab5ad71 otbr-agent[195]: 00:01:52.366 [N] Ip6-----------: Bad UDP checksum
Feb 24 00:45:02 83551ab5ad71 otbr-agent[195]: 00:01:52.366 [N] Ip6-----------: Failed to handle payload: Drop

The same frame in captured to Wireshark shows the UDP checksum is correct however. What could be the reasons the Ip6 module on the otbr-agent is unable to validate the checksum?

IEEE 802.15.4 Data, Dst: Broadcast, Src: 96:af:30:28:43:d3:5a:33
    Frame Control Field: 0xd841, Frame Type: Data, PAN ID Compression, Destination Addressing Mode: Short/16-bit, Frame Version: IEEE Std 802.15.4-2006, Source Addressing Mode: Long/64-bit
        .... .... .... .001 = Frame Type: Data (0x1)
        .... .... .... 0... = Security Enabled: False
        .... .... ...0 .... = Frame Pending: False
        .... .... ..0. .... = Acknowledge Request: False
        .... .... .1.. .... = PAN ID Compression: True
        .... .... 0... .... = Reserved: False
        .... ...0 .... .... = Sequence Number Suppression: False
        .... ..0. .... .... = Information Elements Present: False
        .... 10.. .... .... = Destination Addressing Mode: Short/16-bit (0x2)
        ..01 .... .... .... = Frame Version: IEEE Std 802.15.4-2006 (1)
        11.. .... .... .... = Source Addressing Mode: Long/64-bit (0x3)
    Sequence Number: 159
    Destination PAN: 0x1234
    Destination: 0xffff
    Extended Source: 96:af:30:28:43:d3:5a:33 (96:af:30:28:43:d3:5a:33)
    FCS: 0x8288 (Correct)
6LoWPAN, Src: fe80::94af:3028:43d3:5a33, Dest: ff02::2
    IPHC Header
        011. .... = Pattern: IP header compression (0x03)
        ...1 1... .... .... = Traffic class and flow label: Version, traffic class, and flow label compressed (0x3)
        .... .1.. .... .... = Next header: Compressed
        .... ..11 .... .... = Hop limit: 255 (0x3)
        .... .... 0... .... = Context identifier extension: False
        .... .... .0.. .... = Source address compression: Stateless
        .... .... ..11 .... = Source address mode: Compressed (0x0003)
        .... .... .... 1... = Multicast address compression: True
        .... .... .... .0.. = Destination address compression: Stateless
        .... .... .... ..11 = Destination address mode: 8-bits inline (0x0003)
        [Source context: fe80::]
        [Destination context: fe80::]
    [Source: fe80::94af:3028:43d3:5a33]
    Destination: ff02::2
    UDP header compression
        1111 0... = Pattern: UDP compression header (0x1e)
        .... .0.. = Checksum: Inline
        .... ..00 = Ports: Inline (0)
    Source port: 19788
    Destination port: 19788
    UDP checksum: 0x05cf
Internet Protocol Version 6, Src: fe80::94af:3028:43d3:5a33, Dst: ff02::2
    0110 .... = Version: 6
    .... 0000 0000 .... .... .... .... .... = Traffic Class: 0x00 (DSCP: CS0, ECN: Not-ECT)
        .... 0000 00.. .... .... .... .... .... = Differentiated Services Codepoint: Default (0)
        .... .... ..00 .... .... .... .... .... = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    .... 0000 0000 0000 0000 0000 = Flow Label: 0x00000
    Payload Length: 42
    Next Header: UDP (17)
    Hop Limit: 255
    Source Address: fe80::94af:3028:43d3:5a33
    Destination Address: ff02::2
User Datagram Protocol, Src Port: 19788, Dst Port: 19788
    Source Port: 19788
    Destination Port: 19788
    Length: 42
    Checksum: 0x05cf [correct]
        [Calculated Checksum: 0x05cf]
    [Checksum Status: Good]
    [Stream index: 15]
    [Timestamps]
        [Time since first frame: 15014.669837000 seconds]
        [Time since previous frame: 5.241010000 seconds]
    UDP payload (34 bytes)
Mesh Link Establishment
    Security Suite: 802.15.4 Security (0x00)
    Auxiliary Security Header
        Security Control Field: 0x15, Security Level: Encryption with 32-bit Message Integrity Code, Key Identifier Mode: Explicit Key with 4-octet Key Source
            .... .101 = Security Level: Encryption with 32-bit Message Integrity Code (0x5)
            ...1 0... = Key Identifier Mode: Explicit Key with 4-octet Key Source (0x2)
            ..0. .... = Frame Counter Suppression: False
            .0.. .... = ASN in Nonce: False
            0... .... = Reserved: 0x0
        Frame Counter: 2821
        Key Identifier Field
            Key Source: 0x0000000000000000
            Key Index: 0x01
    Command: Link Request (0)
    TLV (Version = 4)
        Type: Version (18)
        Length: 2
        Version: 4
    TLV (TLV Request)
        Type: TLV Request (13)
        Length: 2
        Type: Address16 (10)
        Type: Route64 (9)
    TLV (Challenge = 79d1e543c8e83903)
        Type: Challenge (3)
        Length: 8
        Challenge: 79d1e543c8e83903

[jkcko]

Finally resolved it. The PHY was returning the length of the received packet not including the 2-byte FCS which was automatically validated in hardware.