Portal:DeveloperDocs/Bug reporting

These are our guidelines about bug reporting. Our software packages are widely used, in several different scenarios, and are developed by humans. That means that eventually there would be issues and bugs arising. Proper and actionable bug reports are key to trigger movements from developers in order to address and fix such issues and bugs.

Also, duplicated and/or bogus bug reports slow down the development process and requires valuable time resources from developers.

Submitting a bug report

Please follow these steps when reporting an issue/bug:

1. Try to identify that this is actually a bug and not a misuse in your side.
2. If using a package from a downstream distribution, try contacting first the distro maintainer. The bug could be in the packaging itself.
3. Check if the bug has been fixed already. You would need to look at sites like https://git.netfilter.org and https://git.kernel.org/pub/scm/linux/kernel/git/pablo
4. In case is not fixed, visit our current bug tracker: http://bugzilla.netfilter.org/
5. Check if the bug has been reported already. If the bug has been reported and you would like to give additional information, please go ahead.
6. In order to do a proper bug report, collect all this information:
   • library versions, for example libnftnl, libmnl, libnetfilter-conntrack, etc.
   • utility versions, for example nft, conntrack-tools, ulogd2, iptables, ipset, etc
   • linux kernel version, for example `uname -a`
   • linux kernel config, for example `cat /boot/config-$(uname -r) | egrep _NFT\|NF_TABLES\|NETFILTER\|_NF_`
   • the ruleset or config you are using. Delete personal or sensible data if required
   • debug output if applicable, for example `nft --debug=all yourcommand`
   • any relevant `dmesg` output
   • any relevant `sysctl` configuration
   • steps to reproduce the issue, if possible
   • any other specific or local configuration you may be using related to Netfilter software
7. Once all the information above is collected, file a bug report in our bug tracker
8. If the issue is really serious, urgent, causing security issues or the like, feel free to contact netfilter-devel@vger.kernel.org
9. Ideally, if you are a software developer, try submitting a prospective patch.

Additional info in case of bugs

There are some external tools that could give additional details about what is going on with a bug:

• valgrind: this utility collects data about memory usage and reports memory leaks and memory-related crashes
• gdb: this utility can print the stack trace of functions inside programs. You would need debugging symbols to know function names
• strace: this tool reports the syscalls that any program does
• tcpdump: this can help in determining what's happening with network packets/flows in the kernel

More info in the development environment page.

See also

Valuable additional information:

• Patch submission guidelines
• Development environment
• Contributing
• Mailing lists