commit b4999b60d48bcbb5aa575973d068e07ab672e095 Author: Philipp Maier pmaier@sysmocom.de Date: Wed Oct 26 15:19:41 2016 +0200
pcu_sock: add basic pcu interface support Adds a basic version of a pcu socket interface, similar to the one that can be found in osmo-bts. Change-Id: Ib13cb4099d12fa71e9e0b8727e19ab29e11909b2
This commit adds PCU sockets to OsmoNITB, but these are not configurable, which is a problem for the osmo-gsm-tester. We cannot have separate OsmoNITB processes all write to /tmp/pcu_bts, their paths needs to be configurable.
Also they seem to not be cleaned up when the process exits. I now see failures of OsmoNITB starting because the /tmp/pcu_bts is still present. This appears when a different user attempts to start an OsmoNITB, i.e. I had a successful run with the 'jenkins' user and am then trying as 'neels'. I guess the PCU socket file should be cleaned up on exit??
The third point is that I don't understand why the OsmoNITB or the OsmoBSC need PCU sockets. The commit log does not explain that unfortunately.
I would like this commit to be reverted until the location is configurable, so that the osmo-gsm-tester can continue to run across several users. (and several NITBs at once, which we're not using yet, but in principle could want to.)
I have a ticket for this in the OsmoGSMTester project, we may need to move it to a different parent project or create a new ticket: https://osmocom.org/issues/2293
~N
Hi Neels,
On Mon, May 29, 2017 at 01:12:29AM +0200, Neels Hofmeyr wrote:
commit b4999b60d48bcbb5aa575973d068e07ab672e095 Change-Id: Ib13cb4099d12fa71e9e0b8727e19ab29e11909b2
This commit adds PCU sockets to OsmoNITB, but these are not configurable, which is a problem for the osmo-gsm-tester. We cannot have separate OsmoNITB processes all write to /tmp/pcu_bts, their paths needs to be configurable.
This is a pity, sorry about missing that. I think the BSC-side PCU socket has started at a time where even the OsmoBTS PCU socket was not configurable yet. But the history of course doesn't help here.
It's sad that we only see this now - for a patch that has been in gerrit for review since March :/
Also they seem to not be cleaned up when the process exits. I now see failures of OsmoNITB starting because the /tmp/pcu_bts is still present. This appears when a different user attempts to start an OsmoNITB, i.e. I had a successful run with the 'jenkins' user and am then trying as 'neels'. I guess the PCU socket file should be cleaned up on exit??
not sure if we do that for mncc and the other sockets. I would try to follow what's done there. In a crash you cannot reliably clean them up anyway, so in general one must live with that.
The third point is that I don't understand why the OsmoNITB or the OsmoBSC need PCU sockets. The commit log does not explain that unfortunately.
In classic GSM networks the PCU was always co-located with the BSC. It's only nanoBTS and OsmoBTS that put the PCU with the BTS (which was more or less required or strongly implied by the fact there's no TDM but an IP link on Abis).
So if we want to support GPRS/EGPRS for classic BTSs with proprietary BTSs-side code, we ned to have support for co-locating OsmoPCU with OsmoBSC (or NITB, but that will die soon anyway). To the PCU this is fully transparent, i.e. the PCU should not care whether it attaches to the pcu_sock of a BTS (in the OsmoBTS case) or to that of a BSC. The protocol is the same.
I would like this commit to be reverted until the location is configurable, so that the osmo-gsm-tester can continue to run across several users. (and several NITBs at once, which we're not using yet, but in principle could want to.)
There are a long series of follow-up commits merged which would all need to be reverted (otherwise there are clashes and fall-out). So I think the more realistic approach is to simply make the socket path configurable, possibly even share some of the setup/cleanup code with mncc_sock? I have plenty of other Osmocom TODOs on my list for this Sunday, but will try to look at it tonight. Cannot make promises, though.
I have a ticket for this in the OsmoGSMTester project, we may need to move it to a different parent project or create a new ticket: https://osmocom.org/issues/2293
I think it's an issue with libbsc, so it should go to the OpenBSC project in the libbsc category?
Regards, Harald
Hi Neels,
See https://gerrit.osmocom.org/#/c/2777/ which is merged now.
@Phillip + Lynxis: Please note this will affect your configurations with RBS2000. you'll have to explicitly add the related config file line when you update beyond that patch!
On Mon, May 29, 2017 at 02:00:56PM +0200, Harald Welte wrote:
Hi Neels,
See https://gerrit.osmocom.org/#/c/2777/ which is merged now.
Excellent!
~N
On Mon, May 29, 2017 at 10:24:13AM +0200, Harald Welte wrote:
It's sad that we only see this now - for a patch that has been in gerrit for review since March :/
Well yea, also kind of normal to miss some things every now and then. On the up-side, the osmo-gsm-tester is starting to give us useful feedback ;)
socket file should be cleaned up on exit??
not sure if we do that for mncc and the other sockets. I would try to follow what's done there. In a crash you cannot reliably clean them up anyway, so in general one must live with that.
ok. As soon as the path for the sockets is configurable, the osmo-gsm-tester will be fine.
In classic GSM networks the PCU was always co-located with the BSC.
[...]
Ah ok, I understand now. All I know is Osmocom, so the classic way is new to me :)
I would like this commit to be reverted until the location is configurable, so
There are a long series of follow-up commits merged which would all need
[...]
It's ok, I can also write up a patch; though I'm not sure what you mean with sharing code with mncc_sock yet. I could try to figure that out, unless you're faster than me anyway.
It's not super high prio, because so far the tester is running only one {BSC, NITB} at a time, and as long as we clean up after manual runs with a different user things should continue to work for the time being.
I have a ticket for this in the OsmoGSMTester project, we may need to move it to a different parent project or create a new ticket: https://osmocom.org/issues/2293
I think it's an issue with libbsc, so it should go to the OpenBSC project in the libbsc category?
Agreed.
~N
-
Harald Welte -
Neels Hofmeyr