Hi Harald,
On Mon, Apr 4, 2016 at 8:10 AM, Harald Welte laforge@gnumonks.org wrote:
Ever since the merge in August 2015, as far as I recall, I never saw a single message from any osmo-bts-trx user whether a) the L1SAP merge back then works for them b) it introduced any regressions
I suspect that there were issues since the beginning of the merge. The issue that I saw with master was reported by Sipos Csaba back in Nov 2015.
http://lists.osmocom.org/pipermail/openbsc/2015-November/000856.html
Unlike Alexander, I was never able to setup a working version with older commits including the one specified in this post.
http://lists.osmocom.org/pipermail/openbsc/2015-September/000398.html
I guess there is something wrong with the OML setup since trx->mo.nm_state is reporting NM_OPSTATE_NULL during the post-RACH channel allocation, but I am not familiar enough with those procedures to debug more.
While some people think I sometimes write good code, I fail to believe that all those intrusive changes didn't break anything for OsmoTRX users. Still, no feedback and no fall-out was reported.
I suspect the case was that very few users, if any, had working setups to break or to report regressions.
Like any larger project, particularly one with different hardware support, we need somebody with essential interest in that hardware to maintain the respective back-end. Think of device driver maintainers in the Linux kernel as an example.
Agreed.
We need a sub-maintainer for osmo-bts-trx, one who
- consistently follows the developments in master and checks for regressiosn
- fixes osmo-bts-trx specific bugs like the fact that GPRS measurment values are not passed to the PCU, breaking rate/link adaption for this platform
- tests interoperability with OsmoTRX and other OpenBTS transceivers out three
- ensures that important osmo-bts-trx related patches/branches end up in master, ensuring that master is what people use. Telling users to use a branch different than master is *wrong* for anything but the most bleeding edge / experiemental code which is to be merged ASAP.
i I can provide a supporting role in the above tasks on behalf of Ettus but we do need a working starting point - that makes number 4 the most critical item. Unfortunately, I am not able to resolve the patch differences (I painfully tried) to make master the main user branch. I agree that directing users to the Fairwaves branch is the wrong approach, but right now it is the only branch for osmo-bts-trx that works.
-TT
Hi Tom,
On Wed, Apr 06, 2016 at 12:01:05AM -0700, Tom Tsou wrote:
I suspect that there were issues since the beginning of the merge. The issue that I saw with master was reported by Sipos Csaba back in Nov 2015.
http://lists.osmocom.org/pipermail/openbsc/2015-November/000856.html
I guess there is something wrong with the OML setup since trx->mo.nm_state is reporting NM_OPSTATE_NULL during the post-RACH channel allocation, but I am not familiar enough with those procedures to debug more.
The lack of proper OML MO state machines on both sides of the A-bis OML link doesn't make it easier either, I know :/
I'm not quite sure how that relates to the bug report above, which indicates a problem in the UDP-based osmo-trx/osmo-bts-trx control interface about setting the BSIC. I would assume that this is the root cause, which only elevates towards e.g. a MO state not changing as it normally should.
I can provide a supporting role in the above tasks on behalf of Ettus
Thanks.
but we do need a working starting point - that makes number 4 the most critical item. Unfortunately, I am not able to resolve the patch differences (I painfully tried) to make master the main user branch. I agree that directing users to the Fairwaves branch is the wrong approach, but right now it is the only branch for osmo-bts-trx that works.
Can you or somebody else interested in getting this resolved provide a full bug report, including * debug log output on OsmoNITB side for for the rsl and nm * debug log output on OsmoBTS side for oml / transceiver interface or anything else related * pcap file of A-bis traffic between OsmoBTS and OsmoNITB, as well as the control commands between osmo-bts-trx and osmo-trx
The above is what to me seems like the "obvious" way to report a bug in order for other developers on this list to try to figure out what is causing the problem. Maybe it's not as obvious to others and we should put together some guidelines in the wiki on this?
In any case, I don't recall seeing a comprehensive report like this on the list yet. If I missed it, my apologies.
Regards, Harald
Dear Harald,
As one of the few users of OsmoBTS/OsmoNITB with an USRP SDR, let me comment on this one.
First, I don't have any commercial interest in this, I am an academic researcher, and as most of us, the only way to be able to create a GSM network and test it is via an SDR.
For this reason I created and maintaining the Wiki article of how to get the full Osmocom stack to work with and Ettus SDR:
http://openbsc.osmocom.org/trac/wiki/Ettus_USRP_B2xx_family
For the first few tries I was only able to get it work with a lot of non-master branches involved.
At this time, almost all non-master branches are now avoided, OsmoBTS is the only one that remains.
I wanted to update this Wiki article and debug the current failures with EDGE introduced on both the PCU/BTS and TRX end, but unfortunately I am now abroad and I don't have access to any USRP devices.
When I'll be back home, I am willing to take a closer look and try findig the issues, but that is 2 months away.
Regards, Csaba
----- Eredeti üzenet ----- Feladó: "Harald Welte" laforge@gnumonks.org Címzett: "Tom Tsou" tom.tsou@ettus.com Másolatot kap: "OpenBSC Mailing List" openbsc@lists.osmocom.org Elküldött üzenetek: Szerda, 2016. Április 6. 9:59:11 Tárgy: Re: Lack of maintenance for osmo-bts-trx
Hi Tom,
On Wed, Apr 06, 2016 at 12:01:05AM -0700, Tom Tsou wrote:
I suspect that there were issues since the beginning of the merge. The issue that I saw with master was reported by Sipos Csaba back in Nov 2015.
http://lists.osmocom.org/pipermail/openbsc/2015-November/000856.html
I guess there is something wrong with the OML setup since trx->mo.nm_state is reporting NM_OPSTATE_NULL during the post-RACH channel allocation, but I am not familiar enough with those procedures to debug more.
The lack of proper OML MO state machines on both sides of the A-bis OML link doesn't make it easier either, I know :/
I'm not quite sure how that relates to the bug report above, which indicates a problem in the UDP-based osmo-trx/osmo-bts-trx control interface about setting the BSIC. I would assume that this is the root cause, which only elevates towards e.g. a MO state not changing as it normally should.
I can provide a supporting role in the above tasks on behalf of Ettus
Thanks.
but we do need a working starting point - that makes number 4 the most critical item. Unfortunately, I am not able to resolve the patch differences (I painfully tried) to make master the main user branch. I agree that directing users to the Fairwaves branch is the wrong approach, but right now it is the only branch for osmo-bts-trx that works.
Can you or somebody else interested in getting this resolved provide a full bug report, including * debug log output on OsmoNITB side for for the rsl and nm * debug log output on OsmoBTS side for oml / transceiver interface or anything else related * pcap file of A-bis traffic between OsmoBTS and OsmoNITB, as well as the control commands between osmo-bts-trx and osmo-trx
The above is what to me seems like the "obvious" way to report a bug in order for other developers on this list to try to figure out what is causing the problem. Maybe it's not as obvious to others and we should put together some guidelines in the wiki on this?
In any case, I don't recall seeing a comprehensive report like this on the list yet. If I missed it, my apologies.
Regards, Harald
On Wed, Apr 6, 2016 at 12:59 AM, Harald Welte laforge@gnumonks.org wrote:
Can you or somebody else interested in getting this resolved provide a full bug report, including
- debug log output on OsmoNITB side for for the rsl and nm
- debug log output on OsmoBTS side for oml / transceiver interface or anything else related
- pcap file of A-bis traffic between OsmoBTS and OsmoNITB, as well as the control commands between osmo-bts-trx and osmo-trx
Yes. I can generate the traces at some point this week.
The above is what to me seems like the "obvious" way to report a bug in order for other developers on this list to try to figure out what is causing the problem. Maybe it's not as obvious to others and we should put together some guidelines in the wiki on this?
I think wiki guidelines on bug reporting would be quite valuable. The range of users for Osmocom and OpenBTS is extremely wide - especially with the latter. For many users and potential users, reporting bugs in the manner suggested above is far from obvious.
-TT
Hi Tom,
On Wed, Apr 06, 2016 at 10:34:45AM -0700, Tom Tsou wrote:
I think wiki guidelines on bug reporting would be quite valuable. The range of users for Osmocom and OpenBTS is extremely wide - especially with the latter. For many users and potential users, reporting bugs in the manner suggested above is far from obvious.
I have started to put together something at http://projects.osmocom.org/projects/cellular-infrastructure/wiki/ReportingB... which should cover the main points. It could be slightly expanded on an example tcpdump statement with default capture filter, but especially in terms of logging configuration it is not possible to give a "one size fits all" recommendation.
What do you think?
The page is not yet linked from other wiki pages, I plan to do that once we make some more progress.
-
Harald Welte -
Sipos Csaba -
Tom Tsou -
Tom Tsou