[Edited Message Follows]

Hi everyone,

I have an use-case where I need to fragment an encapsulated IPv6 packet. I'm 
doing it using the ip6_frag_do_fragment() routine, like so:
encap_size = sizeof(some_encap_tunnel_t);
ip6_frag_do_fragment(vm, pi0, vnet_buffer(p0)->ip_frag.mtu - encap_size, 
encap_size, &frags);

Looking at the implementation of ip6_frag_do_fragment() I notice that 
l2unfragmentablesize bytes, which here is encap_size , are getting overwritten 
after they were first copied into the newly allocated fragment, which makes no 
sense imho because what's the whole point of l2unfragmentablesize then? Let me 
elaborate.
This correctly copies the tunnel headers stack from the original packet into 
the fragment:
clib_memcpy_fast(to_b->data, org_from_packet, l2unfragmentablesize + 
sizeof(ip6_header_t));

But right after:
to_ip6 = vlib_buffer_get_current(to_b);  // (potentially offending line) this 
points into the just copied tunnel headers stack,
to_frag_hdr = (ip6_frag_hdr_t*)(to_ip6 + 1); // also this,
to_data = (void*)(to_frag_hdr + 1);  // and this one too..
...
// not good, this overwrites the tunnel headers stack that were previously 
copied
// from_data correctly points to the encapsulated IPv6 payload (from the 
original to be fragmented packet)
clib_memcpy_fast(to_data + to_ptr=0, from_data + ptr=0, bytes_to_copy);
|
v
+---------------------+------+-----+
| some_encap_tunnel_t | ipv6 | ... |
+---------------------+------+-----+

Whereas ip4_frag_do_fragment() , with the same use-case (i.e. encapsulated ipv4 
packet fragmentation), works just fine as it copies and keeps untouched the 
l2unfragmentablesize bytes from the original to be fragmented packet on every 
produced fragment.

Hope this makes sense.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#17146): https://lists.fd.io/g/vpp-dev/message/17146
Mute This Topic: https://lists.fd.io/mt/76011077/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to