Hi Klement,
thank you for your response.
ip.reass.is_non_first_fragment is set to 1 also for the first fragment.
(gdb) p ((vnet_buffer_opaque_t *) (b0)->opaque)->ip.reass.is_non_first_fragment
$8 = 1 '\001'
I think the fragment offset is wrongly calculated from the buffer:
(gdb) p ip4_get_fragment_offset (vlib_buffer_get_current (b0))
$9 = 766
(gdb) p ((vnet_buffer_opaque_t *) (b0)->opaque)->ip.save_rewrite_length
$1 = 14 '\016'
At the beginning of the function, the header pointer is set from the buffer
with the rewrite length shifted:
ip4_header_t *ip0 =
(ip4_header_t *) u8_ptr_add (vlib_buffer_get_current (b0),
is_output_feature *
vnet_buffer (b0)->
ip.save_rewrite_length);
(gdb) p fragment_first
$2 = 0
Later, this rewrite length is not considered.
Thanks,
Miklos
________________________________
From: Klement Sekera -X (ksekera - PANTHEON TECH SRO at Cisco)
<ksek...@cisco.com>
Sent: Tuesday, May 26, 2020 11:22 AM
To: Miklós Tirpák <miklos.tir...@emnify.com>
Cc: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] NAT44 does not work with fragmented ICMP packets
CAUTION: This email originated from outside of the organization. Do not click
links or open attachments unless you recognize the sender and know the content
is safe.
Hi Miklos,
thanks for your message. If is_non_first_fragment is set to true then rewrite
will not happen. Can you take a look at what happens in ip4_sv_reass_inline for
the first packet/fragment?
Setting that flag should be pretty fool-proof
498 const u32 fragment_first = ip4_get_fragment_offset_bytes (ip0);
...
549 vnet_buffer (b0)->ip.reass.is_non_first_fragment =
550 ! !fragment_first;
...
619 vnet_buffer (b0)->ip.reass.is_non_first_fragment =
620 ! !ip4_get_fragment_offset (vlib_buffer_get_current
(b0));
Thanks,
Klement
> On 26 May 2020, at 09:25, Miklos Tirpak <miklos.tir...@emnify.com> wrote:
>
> Hi,
>
> we have a scenario where an ICMP packet arrives fragmented over a GTP-U
> tunnel. The outer IP packets are not fragmented, only the inner ones are.
> After GTP-U decapsulation, the packets are routed via an interface where
> NAT44 output-feature is configured.
>
> In the outgoing packets, the source IP is correctly NATed but the ICMP
> identifier (port) is not changed. Hence, the NAT session cannot be found for
> the ICMP reply. This works correctly with smaller packets, the problem is
> only with fragmented ones.
>
> I could reproduce this with both VPP 20.01 and master, and could see that
> ip.reass.is_non_first_fragment is true for every packet. Therefore,
> icmp_in2out() does not update the ICMP header I think.
>
> 712 if (!vnet_buffer (b0)->ip.reass.is_non_first_fragment)
> (gdb) p ((vnet_buffer_opaque_t *) (b0)->opaque)->ip.reass
> $17 = {{{next_index = 1056456440, error_next_index = 0}, {owner_thread_index
> = 270}}, {{{l4_src_port = 16120,
> l4_dst_port = 16120, tcp_ack_number = 0, save_rewrite_length = 14
> '\016', ip_proto = 1 '\001',
> icmp_type_or_tcp_flags = 8 '\b', is_non_first_fragment = 1 '\001',
> tcp_seq_number = 0}, {estimated_mtu = 16120}}}, {
> fragment_first = 16120, fragment_last = 16120, range_first = 0,
> range_last = 0, next_range_bi = 17301774,
> ip6_frag_hdr_offset = 0}}
>
> The node trace seems to be fine:
> ... ip4-lookup -> ip4-rewrite -> ip4-sv-reassembly-output-feature ->
> nat44-in2out-output -> nat44-in2out-output-slowpath
>
> The NAT session is also correct, it includes the new port:
>
> DBGvpp# sh nat44 sessions detail
> NAT44 sessions:
> -------- thread 0 vpp_main: 0 sessions --------
> -------- thread 1 vpp_wk_0: 1 sessions --------
> 100.64.100.1: 1 dynamic translations, 0 static translations
> i2o 100.64.100.1 proto icmp port 63550 fib 1
> o2i 172.16.17.2 proto icmp port 16253 fib 0
> index 0
> last heard 44.16
> total pkts 80, total bytes 63040
> dynamic translation
>
> Do you know if this is a configuration issue or a possible bug? Thank you!
>
> Thanks,
> Miklos
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#16489): https://lists.fd.io/g/vpp-dev/message/16489
Mute This Topic: https://lists.fd.io/mt/74473306/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
