Thanks! I’ll push a patch. Regards, Klement
> On 26 May 2020, at 12:33, Miklos Tirpak <miklos.tir...@emnify.com> wrote: > > Yes, it works with ip0: > > vnet_buffer (b0)->ip.reass.is_non_first_fragment = > ! !ip4_get_fragment_offset (ip0); > > Thanks, > Miklos > From: Klement Sekera -X (ksekera - PANTHEON TECH SRO at Cisco) > <ksek...@cisco.com> > Sent: Tuesday, May 26, 2020 12:14 PM > 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. > > > I think it’s enough if instead of vlib_buffer_get_current(b0) we just use ip0 > (that already takes save_rewrite_length into consideration). Can you please > test with this modification? > > Thanks, > Klement > > > On 26 May 2020, at 11:51, Miklos Tirpak <miklos.tir...@emnify.com> wrote: > > > > Hi, > > > > I think there is a problem in ip4_sv_reass_inline(), it does not consider > > ip.save_rewrite_length when it calculates is_non_first_fragment at line 619 > > (master): > > vnet_buffer (b0)->ip.reass.is_non_first_fragment = > > ! !ip4_get_fragment_offset (vlib_buffer_get_current (b0)); > > > > Let me open a pull request to fix this. > > > > Thanks, > > Miklos > > From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> on behalf of Miklos Tirpak > > via lists.fd.io <miklos.tirpak=emnify....@lists.fd.io> > > Sent: Tuesday, May 26, 2020 9:25 AM > > To: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> > > Subject: [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, > > > > 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 (#16492): https://lists.fd.io/g/vpp-dev/message/16492 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] -=-=-=-=-=-=-=-=-=-=-=-