Previous patch introduced bugs in rte_ipv4_fragment_packet functions

dpdk-dev [email protected] 1 participant 1 message Oct 25, 2021

Share & tools

[email protected]

author

2021-10-25 07:44 UTC #0 lore raw

https://bugs.dpdk.org/show_bug.cgi?id=835

            Bug ID: 835
           Summary: Previous patch introduced bugs in
                    rte_ipv4_fragment_packet functions
           Product: DPDK
           Version: unspecified
          Hardware: All
                OS: All
            Status: UNCONFIRMED
          Severity: critical
          Priority: High
         Component: other
          Assignee: [email protected]
          Reporter: [email protected]
                CC: [email protected]

Target Milestone: ---

Overview:
The patch 567473433b7e("ip_frag: fix fragmenting IPv4 fragment") introduces a bug and needs to be rolled back. This is because the patch and variables "flag_offset" conflict with each other.

Quoted 30 lines

lib/ip_frag/rte_ipv4_fragmentation.c +1 -1

index 2e7739d..fead5a9 100644
@@ -75,7 +75,7 @@ static inline void __free_fragments(struct rte_mbuf *mb[],
 uint32_t num)
     uint32_t out_pkt_pos, in_seg_data_pos;
     uint32_t more_in_segs;
     uint16_t fragment_offset, flag_offset, frag_size, header_len;
-    uint16_t frag_bytes_remaining;
+    uint16_t frag_bytes_remaining, not_last_frag;
 
     /*

* Formal parameter checking.

lib/ip_frag/rte_ipv4_fragmentation.c +3 -1

@@ -116,7 +116,9 @@ static inline void __free_fragments(struct rte_mbuf
 *mb[], uint32_t num)
     in_seg = pkt_in;
     in_seg_data_pos = header_len;
     out_pkt_pos = 0;
-    fragment_offset = 0;
+    fragment_offset = (uint16_t)((flag_offset &
+        RTE_IPV4_HDR_OFFSET_MASK) << RTE_IPV4_HDR_FO_SHIFT);
+    not_last_frag = (uint16_t)(flag_offset & IPV4_HDR_MF_MASK);
 
     more_in_segs = 1;

     while (likely(more_in_segs)) {

lib/ip_frag/rte_ipv4_fragmentation.c +0 -0

@@ -186,7 +188,8 @@ static inline void __free_fragments(struct rte_mbuf
 *mb[], uint32_t num)

Quoted 8 lines

lib/ip_frag/rte_ipv4_fragmentation.c +2 -1

             __fill_ipv4hdr_frag(out_hdr, in_hdr, header_len,
                 (uint16_t)out_pkt->pkt_len,
-                flag_offset, fragment_offset, more_in_segs);
+                flag_offset, fragment_offset,
+                not_last_frag || more_in_segs);
 
             fragment_offset = (uint16_t)(fragment_offset +

                 out_pkt->pkt_len - header_len);

"flag_offset" or “fofs” contains all the information about fragment,so this patch is no longer needed.

flag_offset = rte_cpu_to_be_16(in_hdr->fragment_offset);

static inline void __fill_ipv4hdr_frag(struct rte_ipv4_hdr *dst,
const struct rte_ipv4_hdr *src, uint16_t header_len, uint16_t len, uint16_t fofs, uint16_t dofs, uint32_t mf)

{
        rte_memcpy(dst, src, header_len);
        fofs = (uint16_t)(fofs + (dofs >> RTE_IPV4_HDR_FO_SHIFT));
        fofs = (uint16_t)(fofs | mf << RTE_IPV4_HDR_MF_SHIFT);
        dst->fragment_offset = rte_cpu_to_be_16(fofs);
        dst->total_length = rte_cpu_to_be_16(len);
        dst->hdr_checksum = 0;
}

Steps to Reproduce:
1) Use a fragment that is not the last fragment to test rte_ipv4_fragment_packet function:MTU is 68,ip pkt_size is 104(not include ip header len), MF is 1,fragment_offset is 13.
2) Start the test to see the fragmenting results: the values of fragment number and fragment_offset.

Actual Results:
fragment number: 3
fragment_offset: 0x201A 0x2020 0x2026

Expected Results:
fragment number: 3
fragment_offset: 0x200D 0x2013 0x2019

Build Date & Hardware:
Build 2021-10-25 on Linux OS 3.10.0

Signature · 2 lines

You are receiving this mail because:
You are the assignee for the bug.