[ovs-discuss] How to submit a bug report
Llorente Santos Jesus
jesus.llorente.santos at aalto.fi
Mon Sep 11 21:27:46 UTC 2017
Hi Ben, thank you for getting back to me on this.
I noticed that my previous email with the steps to reproduce was sent to ovs-dev mailing list. It somewhat felt like the appropriate place to send such detailed issue.
In any case, I have added those same steps to the open issue in the ovs-issues repo. I hope that simplifies the follow up!
I spent quite bit of time looking at the code but I couldn't really see anything odd. Comparing 2.5.3 with 2.7.0, showed a vast number of commits. I deepened into the tunnelling code for GRE, VXLAN and Geneve but couldn't stop the difference. It's quite odd, in my experience, marking packets does not invalidate in any case receiving them into the socket.
The issue here is that 2.5.3 is the current LTS version, which in late June received a new update. The release note says "Bug fixes", so maybe there is still something we can fix there...
From: Ben Pfaff [mailto:blp at ovn.org]
Sent: 12 September 2017 00:03
To: Llorente Santos Jesus <jesus.llorente.santos at aalto.fi>
Cc: ovs-discuss at openvswitch.org
Subject: Re: [ovs-discuss] How to submit a bug report
On Mon, Sep 11, 2017 at 07:27:56PM +0000, Llorente Santos Jesus wrote:
> I have been seeing buggy behaviour with the tunnelling ports of OvS. I
> would like to ask some help in how to properly submit a bug report I created an issue in the git "ovs-issues" (https://github.com/openvswitch/ovs-issues/issues/134) about 2 weeks ago, but it seems no one is monitoring that.
> I sent an email to bugs at openvswitch.org following these instructions
> I have also sent an email to this mailing list, but no one has responded my message.
> Can anyone help me? I would really like to get this annoying bug fixed!
Your report has definitely been recorded. I can think of a few reasons why no one has acted on it, besides simply being busy. One is that it does not give readers a good way to reproduce the problem, even though it talks about a very particular scenario. Developers are more likely to try to reproduce and fix a bug when it doesn't require a lot of forethought on how to get started. Another is that it sounds like the problem has been fixed in a later version. It's not too rewarding to fix bugs that are already fixed.
Given that it's been fixed, you could use "git bisect" to try to find out what commit fixed it. If you reported that, it could allow a developer to understand and fix the problem without much additional work.
More information about the discuss