On 27 Sep 2016, at 05:47, Bruce Smith brucemate@mail.com wrote:
Greetings,
Dear Bruce,
I have never used osmo-trx/uhd or related with OpenBSC but in terms of figuring out what is broken let's have a look at the different components.
There's a delay of ~10s at the line marked **** where the BTS seems to wait for a location update request from the MS; which never gets received, hence the BTS times out and releases the channel. Using a phone in diagnostic mode, this message appears to be sent correctly, however the BTS never receives/processes it.
So OpenBSC/osmo-nitb seems to work correctly. It doesn't "ignore" a message and it is just missing. My hypothesizes that you might have time to explore:
a.) osmo-trx not being able to decode the message? b.) The osmo-bts-trx is not "receiving" data from osmo-trx? c.) osmo-bts-trx not getting the LAPDm framing right?
I've tried using older configuration files (which have worked with older builds), as well as the sample configuration files contained with each of the master branches, but to no differing effect.
Given the MS can see and attempt to connect to the BTS, I'm assuming the transceiver chain is working correctly... my thoughts are that perhaps I've got some simple configuration set incorrectly somewhere along the way.
libosmocore (master) - 2016-08-30 libosmo-abis (master) - 2016-09-05 libosmo-netif (master) - 2016-07-07 openggsn (master) - 2016-06-05 libosmo-sccp (master) - 2016-07-07 openbsc (master) - 2016-09-05 osmo-bts (master) - 2016-09-06 osmo-pcu (master) - 2016-09-06 osmo-trx (master) - 2016-08-11 uhd_003.009.002-0
Could you downgrade your osmo-trx and osmo-bts to the 12+ months old version? The rest should work just fine and doesn't seem to have the issue. So my bet is either osmo-bts (a year ago you must have used a branch, now the refactored master branch is used) or osmo-trx?
holger
Hi
That's the same that is happening with me since about two weeks, and I was unable to solve it. They told me it might be uhd problem, but I installed different uhds with the same issue.
osmo-bitb shows the same error like this: <0000> chan_alloc.c:342 (bts=0,trx=0,ts=7,pchan=TCH/F) Allocating lchan=0 as TCH_F <0004> abis_rsl.c:1727 (bts=0,trx=0,ts=7,ss=0) Activating ARFCN(60) SS(0) lctype TCH_F r=EMERGENCY ra=0xab ta=3 <0004> abis_rsl.c:536 (bts=0,trx=0,ts=7,pchan=TCH/F) Tx RSL Channel Activate with act_type=INITIAL <0004> abis_rsl.c:1127 (bts=0,trx=0,ts=7,ss=0) state NONE -> ACTIVATION REQUESTED <0004> abis_rsl.c:1456 (bts=0,trx=0,ts=7,ss=0) CHANNEL ACTIVATE ACK <0004> abis_rsl.c:1127 (bts=0,trx=0,ts=7,ss=0) state ACTIVATION REQUESTED -> ACTIVE <0004> abis_rsl.c:806 (bts=0,trx=0,ts=7,ss=0) RF Channel Release CMD due error 1 <0004> abis_rsl.c:718 (bts=0,trx=0,ts=7,ss=0) DEACTivate SACCH CMD <0004> abis_rsl.c:1127 (bts=0,trx=0,ts=7,ss=0) state ACTIVE -> RELEASE DUE ERROR <0004> abis_rsl.c:863 (bts=0,trx=0,ts=7,ss=0) RF CHANNEL RELEASE ACK <0004> abis_rsl.c:767 (bts=0,trx=0,ts=7,ss=0) is back in operation.
it once showed this error: <0022> control_if.c:286 Failed to parse ip access message: -5 <0000> chan_alloc.c:355 Failed to allocate SDCCH channel <0004> abis_rsl.c:1678 BTS 0 CHAN RQD: no resources for SDCCH 0x10
osmo-pcu is not working fine with me, can this help to solve the problem?, this is the output for using it with and without sudo. pi@raspberrypi:~ $ osmo-pcu -r 1 No config file: 'osmo-pcu.cfg' Using default config. <0001> osmobts_sock.cpp:227 Opening OsmoPCU L1 interface to OsmoBTS <0001> osmobts_sock.cpp:264 Failed to connect to the osmo-bts PCU socket, delaying... '/tmp/pcu_bts' <0001> osmobts_sock.cpp:227 Opening OsmoPCU L1 interface to OsmoBTS <0001> osmobts_sock.cpp:264 Failed to connect to the osmo-bts PCU socket, delaying... '/tmp/pcu_bts' ^CSignal 2 received. full talloc report on 'Osmo-PCU context' (total 1 bytes in 1 blocks) pi@raspberrypi:~ $ sudo osmo-pcu -r 1 No config file: 'osmo-pcu.cfg' Using default config. <0001> osmobts_sock.cpp:227 Opening OsmoPCU L1 interface to OsmoBTS <0001> osmobts_sock.cpp:285 osmo-bts PCU socket has been connected <0001> pcu_l1_if.cpp:357 BTS not available pi@raspberrypi:~ $
I use USRP2 , I used recently a reference clock of 10 MHz but didn't solve the issue, but it is good to know that N210 is with the same error.
Another thing that my network rarely shows on the MS, but the osmo-nitb still shows the output every minute or more or when I do a mobile network search.
Thanks Abdulghafar
On Tue, Sep 27, 2016 at 6:50 PM, Holger Freyther holger@freyther.de wrote:
On 27 Sep 2016, at 05:47, Bruce Smith brucemate@mail.com wrote:
Greetings,
Dear Bruce,
I have never used osmo-trx/uhd or related with OpenBSC but in terms of figuring out what is broken let's have a look at the different components.
There's a delay of ~10s at the line marked **** where the BTS seems to
wait for a location update request from the MS; which never gets received, hence the BTS times out and releases the channel. Using a phone in diagnostic mode, this message appears to be sent correctly, however the BTS never receives/processes it.
So OpenBSC/osmo-nitb seems to work correctly. It doesn't "ignore" a message and it is just missing. My hypothesizes that you might have time to explore:
a.) osmo-trx not being able to decode the message? b.) The osmo-bts-trx is not "receiving" data from osmo-trx? c.) osmo-bts-trx not getting the LAPDm framing right?
I've tried using older configuration files (which have worked with older
builds), as well as the sample configuration files contained with each of the master branches, but to no differing effect.
Given the MS can see and attempt to connect to the BTS, I'm assuming the
transceiver chain is working correctly... my thoughts are that perhaps I've got some simple configuration set incorrectly somewhere along the way.
libosmocore (master) - 2016-08-30 libosmo-abis (master) - 2016-09-05 libosmo-netif (master) - 2016-07-07 openggsn (master) - 2016-06-05 libosmo-sccp (master) - 2016-07-07 openbsc (master) - 2016-09-05 osmo-bts (master) - 2016-09-06 osmo-pcu (master) - 2016-09-06 osmo-trx (master) - 2016-08-11 uhd_003.009.002-0
Could you downgrade your osmo-trx and osmo-bts to the 12+ months old version? The rest should work just fine and doesn't seem to have the issue. So my bet is either osmo-bts (a year ago you must have used a branch, now the refactored master branch is used) or osmo-trx?
holger
On 27 Sep 2016, at 23:51, Abdulghafar Shabaneh abdulghafar1412@gmail.com wrote:
Hi
Hi!
That's the same that is happening with me since about two weeks, and I was unable to solve it. They told me it might be uhd problem, but I installed different uhds with the same issue.
same disclaimer that I have only worked with the BS11, nanoBTS and the last years with the sysmoBTS.
osmo-bitb shows the same error like this: <0000> chan_alloc.c:342 (bts=0,trx=0,ts=7,pchan=TCH/F) Allocating lchan=0 as TCH_F <0004> abis_rsl.c:1727 (bts=0,trx=0,ts=7,ss=0) Activating ARFCN(60) SS(0) lctype TCH_F r=EMERGENCY ra=0xab ta=3 <0004> abis_rsl.c:536 (bts=0,trx=0,ts=7,pchan=TCH/F) Tx RSL Channel Activate with act_type=INITIAL <0004> abis_rsl.c:1127 (bts=0,trx=0,ts=7,ss=0) state NONE -> ACTIVATION REQUESTED <0004> abis_rsl.c:1456 (bts=0,trx=0,ts=7,ss=0) CHANNEL ACTIVATE ACK <0004> abis_rsl.c:1127 (bts=0,trx=0,ts=7,ss=0) state ACTIVATION REQUESTED -> ACTIVE <0004> abis_rsl.c:806 (bts=0,trx=0,ts=7,ss=0) RF Channel Release CMD due error 1 <0004> abis_rsl.c:718 (bts=0,trx=0,ts=7,ss=0) DEACTivate SACCH CMD <0004> abis_rsl.c:1127 (bts=0,trx=0,ts=7,ss=0) state ACTIVE -> RELEASE DUE ERROR <0004> abis_rsl.c:863 (bts=0,trx=0,ts=7,ss=0) RF CHANNEL RELEASE ACK <0004> abis_rsl.c:767 (bts=0,trx=0,ts=7,ss=0) is back in operation.
it once showed this error: <0022> control_if.c:286 Failed to parse ip access message: -5 <0000> chan_alloc.c:355 Failed to allocate SDCCH channel <0004> abis_rsl.c:1678 BTS 0 CHAN RQD: no resources for SDCCH 0x10
I think this is not the first issue but a consequence of many channels ending up in error.
I use USRP2 , I used recently a reference clock of 10 MHz but didn't solve the issue, but it is good to know that N210 is with the same error.
Another thing that my network rarely shows on the MS, but the osmo-nitb still shows the output every minute or more or when I do a mobile network search.
Same hint as to the original poster. Try an older version of osmo-bts and tell us preferable the SHA1 of it. Then we will ask you to git bisect between working and non-working version.
holger
Hi
I have tried to downgrade to a lot of branches of the osmo-bts, but unfortunately was unable to catch a good one!, most of them don't build and install correctly with errors in make or ./configure commands.
osmo-trx seems to be working fine with the 3.008.004 UHD, it was showing that Transceiver successfully tuned the down link and up-link frequencies.
I decided to quit with this USRP unless you have a help of which osmo-bts can be compatible and working with current osmo-nitb for USRPs. Can you suggest any help?
Thanks Abdulghafar
On Tue, Sep 27, 2016 at 10:51 PM, Abdulghafar Shabaneh < abdulghafar1412@gmail.com> wrote:
Hi
That's the same that is happening with me since about two weeks, and I was unable to solve it. They told me it might be uhd problem, but I installed different uhds with the same issue.
osmo-bitb shows the same error like this: <0000> chan_alloc.c:342 (bts=0,trx=0,ts=7,pchan=TCH/F) Allocating lchan=0 as TCH_F <0004> abis_rsl.c:1727 (bts=0,trx=0,ts=7,ss=0) Activating ARFCN(60) SS(0) lctype TCH_F r=EMERGENCY ra=0xab ta=3 <0004> abis_rsl.c:536 (bts=0,trx=0,ts=7,pchan=TCH/F) Tx RSL Channel Activate with act_type=INITIAL <0004> abis_rsl.c:1127 (bts=0,trx=0,ts=7,ss=0) state NONE -> ACTIVATION REQUESTED <0004> abis_rsl.c:1456 (bts=0,trx=0,ts=7,ss=0) CHANNEL ACTIVATE ACK <0004> abis_rsl.c:1127 (bts=0,trx=0,ts=7,ss=0) state ACTIVATION REQUESTED -> ACTIVE <0004> abis_rsl.c:806 (bts=0,trx=0,ts=7,ss=0) RF Channel Release CMD due error 1 <0004> abis_rsl.c:718 (bts=0,trx=0,ts=7,ss=0) DEACTivate SACCH CMD <0004> abis_rsl.c:1127 (bts=0,trx=0,ts=7,ss=0) state ACTIVE -> RELEASE DUE ERROR <0004> abis_rsl.c:863 (bts=0,trx=0,ts=7,ss=0) RF CHANNEL RELEASE ACK <0004> abis_rsl.c:767 (bts=0,trx=0,ts=7,ss=0) is back in operation.
it once showed this error: <0022> control_if.c:286 Failed to parse ip access message: -5 <0000> chan_alloc.c:355 Failed to allocate SDCCH channel <0004> abis_rsl.c:1678 BTS 0 CHAN RQD: no resources for SDCCH 0x10
osmo-pcu is not working fine with me, can this help to solve the problem?, this is the output for using it with and without sudo. pi@raspberrypi:~ $ osmo-pcu -r 1 No config file: 'osmo-pcu.cfg' Using default config. <0001> osmobts_sock.cpp:227 Opening OsmoPCU L1 interface to OsmoBTS <0001> osmobts_sock.cpp:264 Failed to connect to the osmo-bts PCU socket, delaying... '/tmp/pcu_bts' <0001> osmobts_sock.cpp:227 Opening OsmoPCU L1 interface to OsmoBTS <0001> osmobts_sock.cpp:264 Failed to connect to the osmo-bts PCU socket, delaying... '/tmp/pcu_bts' ^CSignal 2 received. full talloc report on 'Osmo-PCU context' (total 1 bytes in 1 blocks) pi@raspberrypi:~ $ sudo osmo-pcu -r 1 No config file: 'osmo-pcu.cfg' Using default config. <0001> osmobts_sock.cpp:227 Opening OsmoPCU L1 interface to OsmoBTS <0001> osmobts_sock.cpp:285 osmo-bts PCU socket has been connected <0001> pcu_l1_if.cpp:357 BTS not available pi@raspberrypi:~ $
I use USRP2 , I used recently a reference clock of 10 MHz but didn't solve the issue, but it is good to know that N210 is with the same error.
Another thing that my network rarely shows on the MS, but the osmo-nitb still shows the output every minute or more or when I do a mobile network search.
Thanks Abdulghafar
On Tue, Sep 27, 2016 at 6:50 PM, Holger Freyther holger@freyther.de wrote:
On 27 Sep 2016, at 05:47, Bruce Smith brucemate@mail.com wrote:
Greetings,
Dear Bruce,
I have never used osmo-trx/uhd or related with OpenBSC but in terms of figuring out what is broken let's have a look at the different components.
There's a delay of ~10s at the line marked **** where the BTS seems to
wait for a location update request from the MS; which never gets received, hence the BTS times out and releases the channel. Using a phone in diagnostic mode, this message appears to be sent correctly, however the BTS never receives/processes it.
So OpenBSC/osmo-nitb seems to work correctly. It doesn't "ignore" a message and it is just missing. My hypothesizes that you might have time to explore:
a.) osmo-trx not being able to decode the message? b.) The osmo-bts-trx is not "receiving" data from osmo-trx? c.) osmo-bts-trx not getting the LAPDm framing right?
I've tried using older configuration files (which have worked with
older builds), as well as the sample configuration files contained with each of the master branches, but to no differing effect.
Given the MS can see and attempt to connect to the BTS, I'm assuming
the transceiver chain is working correctly... my thoughts are that perhaps I've got some simple configuration set incorrectly somewhere along the way.
libosmocore (master) - 2016-08-30 libosmo-abis (master) - 2016-09-05 libosmo-netif (master) - 2016-07-07 openggsn (master) - 2016-06-05 libosmo-sccp (master) - 2016-07-07 openbsc (master) - 2016-09-05 osmo-bts (master) - 2016-09-06 osmo-pcu (master) - 2016-09-06 osmo-trx (master) - 2016-08-11 uhd_003.009.002-0
Could you downgrade your osmo-trx and osmo-bts to the 12+ months old version? The rest should work just fine and doesn't seem to have the issue. So my bet is either osmo-bts (a year ago you must have used a branch, now the refactored master branch is used) or osmo-trx?
holger
I'm sorry about your lack of positive experience. One problem is that osmo-bts-trx is basically unmaintained for at least 1.5 years as all the original authors and the commercial users seem to have lost interest in supporting it. I find this incredibly sad, but who should do this kind of work and continuous testing/integration, if not the commercial suppliers or users of said SDR hardware?
I'm beginning to think we should remove the code from the master repository until somebody steps up to take care of ongoing maintenance :((
On 09/11/2016 17:08, Abdulghafar Shabaneh wrote:
Hi
I decided to quit with this USRP unless you have a help of which osmo-bts can be compatible and working with current osmo-nitb for USRPs. Can you suggest any help?
Hi! This doesn't fix what Harald mentions, and I don't know if it may be of some help, I hope so, so I will describe my setup.
I am keeping my NITB work separated the osmo-trx/bts box, even though it really makes no difference as I am using static-builds of osmobts-trx and osmo-trx, that I built with this: git://git.osmocom.org/osmo-bts.git So, they are the versions that the submodules in that repo point to there currently.
That, I believe, is for osmo-bts, this release: fairwaves/0.3.0-fw-4 http://git.osmocom.org/osmo-bts/tag/?h=fairwaves/0.3.0-fw-4 http://git.osmocom.org/osmo-bts/commit/?h=fairwaves/master&id=b78554342c...
and for osmo-trx it's at this commit http://git.osmocom.org/osmo-trx/commit/?id=c312905f43bb120450c33d9a80bc35771...
Not sure what dependencies you actually have there in the rest of the osmo stack to build those two (bts/trx), but I can tell you that I have built that tree and it works fine for the purposes of working and testing the NITB.
Should you want to work on osmo-bts, you might have an issue. There are a lot of branches there, I certainly have no idea what's going on.
I am using an N210, and IIRC, I had grave problems with the UHD from the ettus ubuntu repo, so I cloned from githib and compiled master at the time. my UHD is reporting UHD_003.010.git-156-g2d68f228 so it was this commit: https://github.com/EttusResearch/uhd/commit/2d68f228
In case (I really don't think so) it has some impact, all this happens to be on a stock Ubuntu 12.04.5 LTS, 3.13.0-85-generic #129~precise1-Ubuntu SMP Fri Mar 18 17:38:08 UTC 2016 x86_64
Everything is working "perfectly" ;-)
k.
On 10/11/2016 17:52, Keith wrote:
I am keeping my NITB work separated the osmo-trx/bts box, even though it really makes no difference as I am using static-builds of osmobts-trx and osmo-trx, that I built with this: git://git.osmocom.org/osmo-bts.git
Sorry, that should read: https://github.com/fairwaves/osmo-combo
So, they are the versions that the submodules in that repo point to there currently.
-
Abdulghafar Shabaneh -
Bruce Smith -
Harald Welte -
Holger Freyther -
Keith