6 Apr
2016
6 Apr
'16
9:59 a.m.
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
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)