ReportingBugs » History » Version 5
neels, 04/17/2018 12:04 PM
h1. Reporting Bugs
No software is free of bugs, including Osmocom software. We do appreciate your bug reports, though of course we can make no guarantees that we will be able to fix it. It is a volunteer-driven Free Software project, after all.
In order for us to understand the conditions causing the bug, proper bug reporting is of high importance.
This page intends to provide some input on how to create a bug report that is useful for developers.
Sending incomplete / insufficient bug reports reduces the probability that the developers can fix the bug you experience, so we kindly ask you to work with us by preparing good bug reports. Thanks for your attention.
h2. Important parts of a bug report
The most important parts of a bug report are
# Description of the bug
#* what exactly did you try to do?
#* what was the expected behavior?
#* what was the actual (erroneous) behavior?
#* At which frequency does the bug occur?
#* Have you observed any particular condition/trigger/setup that allows to reproduce the bug?
# Your setup / environment
#* which BTS model/version are you using?
#* which of the many Osmocom programs were running at the time of the bug?
#** which configuration did you use at the time for each Osmocom program? Include all config files
#** which exact version of each Osmocom programs did you use?
#* which other external software or hardware components are interfacing with Osmocom
#* which exact versions of libosmocore, libosmo-abis, libosmo-netif, etc. did you use?
#* if the issue relates to specific phone models, include information about the phone model + firmware/OS version
# Protocol Traces
#* include a pcap file of the relevant communication interfaces, such as
#** Abis/IP between BTS and BSC/NITB (tcp port 3002 + 3003)
#** Gb/IP between PCU and SGSN (udp port 23000 by default)
#** RUA, HNBAP and/or SUA in case of osmo-iuh / 3G
#** The UDP based transceiver interface in case of osmo-trx
# Log file output
#* The log file output ahead of the bug is very important, include the relevant log file snippets
#* If you already suspect/know the bug in a given sub-system, it might make sense to increase the logging verbosity in that sub-system. Please see the respective User Manuals of the Osmocom software you're using.
h2. Actual bug reporting
In case you have a user account with sufficient privileges, you can report the bug directly as a redmine issue on this web-site:
* On osmocom.org, top bar, click "Projects".
* Select, for example, 'OsmoBSC', click on its name.
* On the top right, enter a search term to see whether your issue may already be reported (you may limit the search to Issues). Otherwise:
* Click on "New issue", on the bar that is the "3rd line from the top".
* Pick a meaningful summary line.
* Add a description.
* Add attachments as needed.
* No need to set anything else.
* Click 'Create'.
* If there is no activity on the issue for some time, you may ask on the mailing list.
For the general public, bugs are reported via e-mails to one of our mailing lists. Compose an e-mail with as much of the contents listed above, and send it by e-mail to the applicable mailing list.
Preferably, do not send large attachments via e-mail on a mailing list. If you can, provide a download link instead (or register on osmocom.org and ask for permissions to create issues).
The subject should preferrably start with "BUG:"
The mailing list addresses are as follows:
* @email@example.com@ for bugs clearly related to the GPRS side of things (like OsmoPCU, OsmoSGSN, OsmoGGSN, osmo-gbproxy, ...)
* @firstname.lastname@example.org@ for the circuit switched side (like OsmoBTS, OsmoBSC, OsmoNITB, ...) or library components.
h2. Video Tutorial
At [[osmo-dev-con:OsmoCon2017]], Daniel Willmann gave a presentation on "how to report issues to osmocom":https://media.ccc.de/v/osmocon17-4008-reporting_and_investigating_issues_in_osmocom