Well is there any possible way to retrieve the correct payload without the 
previous one? Hard coding it to only get the payload until it reaches “\n” is 
the best solution I could come up with, but obviously this presents a mistake 
since it will cut packets that have a newline string in them. To continue 
developing my buffering action I need the full correct packet, do you see any 
other solution?


From: Ben Pfaff<mailto:b...@ovn.org>
Sent: Thursday, May 21, 2020 21:14
To: Luca Mancini<mailto:luca.manc...@outlook.com>
Cc: ovs-discuss@openvswitch.org<mailto:ovs-discuss@openvswitch.org>
Subject: Re: [ovs-discuss] OVERLAPPING DP_PACKETS ctx->xin->payload

On Thu, May 21, 2020 at 01:28:37PM +0000, Luca Mancini wrote:
> Hi,
> I found out while debugging my new action that ovs overlaps incoming packet 
> payloads and I haven’t found a fix for this. I can’t tell if it’s an OVS bug 
> or if I’m doing something wrong.
> Basically once do_xlate_actions is called and my action is “hit” I attempt to 
> print the packet to gdb using this command:
> Ofproto/ofproto-dpif-xlate.c:
> Compose_foo(ctx):
>                         VLOG_ERR(  "%s",   (char *) 
> dp_packet_get_udp_payload(ctx->xin->packet)    );
> While debugging I saw the function  dp_packet_get_udp_payload(*b) often being 
> called on a previous already used dp_packet pointer (*b), which by debugging 
> even further, I notice it sometimes still contains the previous udp payload 
> received previously, so the call overlaps the 2 payloads. Is this normal 
> behavior? More precise info on how it overlaps can be seen here:
> https://mail.openvswitch.org/pipermail/ovs-discuss/2020-May/050090.html
> This is my very trivial setup
>   *   I’m using netcat to send udp payloads between the 2 hosts in the 
> topology h1----s1---h2
>   *   Only flows that contain udp packets go through my foo_Action : “sh 
> ovs-ofctl add-flow s1 in_port=1,dl_type=2048,nw_proto=17,action=foo”
> My end goal is to save these incoming packets in a buffer and if the payloads 
> are wrong then there’s really no point.
> I’m guessing I need a way to free the contents of the pointer 
> ctx->xin->payload, but I haven’t found anything useful in the code, also 
> since ctx->xin->packet is a const I can’t modify it.
> Sorry if this is kind of a repost from my previous query but I’ve tried 
> everything, so any help will be highly appreciated!

Nothing you've presented so far gives me confidence that there's any bug
at all.  The libc memory allocator reuses memory when it's freed, and
doesn't clear it when it's reused.  If the previous packet is longer
than the current one, then some of its bytes are likely to still be
there in memory.

discuss mailing list

Reply via email to