26 May
2017
26 May
'17
6:36 p.m.
Further clarifications are inline.
On 24.05.2017 21:07, emily mcmilin wrote:
(Note that in this case I am using the SysmoBTS HW, hence osmo-bts-trx
is not running, and my version of bsc_control.py insists on
host/port.)
Not a problem at all - the TRAP message is generated when BTS (any) connects to or
disconnects from BSC. The particular BTS type should not matter.
The ports could be looked up in libosmocore's include/osmocom/ctrl/ports.h in
addition to corresponding user manuals.
In case of OsmoBSC the ctrl port is 4249 (same as NITB) see Table 7 in Appendix A of
OsmoBSC user manual. That's also the port used by bsc_control.py by default. Also the
port is reported upon startup:
...
20170526183514003 DLCTRL <0025> control_if.c:787 CTRL at 127.0.0.1 4249
...
I am able to use GET vars as expected, for example:
`$ python ~/openbsc/openbsc/contrib/bsc_control.py -g
bts.0.oml-connection-state -d localhost -p 4249
Got message: GET_REPLY 9194480470313757573
bts.0.oml-connection-state connected`
However, I am not able to issue the specific GET for
"bts_connection_status" that you used in your example:
`$ python ~/openbsc/openbsc/contrib/bsc_control.py -g
bts_connection_status -d localhost -p 4249
Got message: ERROR 6533531211354498498 Command not found`
That's very odd - I'm unable to reproduce this:
./bsc_control.py -g bts_connection_status -d localhost
Got message: GET_REPLY 7587255856797935347 bts_connection_status disconnected
Could it be the case that you're running NITB instead of OsmoBSC? Please provide all
the commands you're using to start everything (not only python scripts). Also, please
make sure that no osmo* is started automatically by .service or .sh scripts.
Are these two .*connection.* commands synonymous in
function, or am I
missing something?
(Note there are other examples of seeming mismatch between the command
in the manual and the command that I can run, ie:
'net.btsN.trxM.arfcn' in Table 2 referenced before vs
'bts.0.trx.0.arfcn' in my use case -- note the difference in . pattern
-- which I assume to be a non-issue, but would love further clarity
on.)
However, speaking to TRAP calls specifically, in both cases, I get a
non-response from CLI (initially meeting my expectations, but it
remains non-responsive despite issuing the GET .*connection.* commands
noted above in another terminal, thus my confusion):
`$ python ~/openbsc/openbsc/contrib/bsc_control.py -m
bts_connection_status -d localhost -p 4249
^C
<snip>
$ python ~/openbsc/openbsc/contrib/bsc_control.py -m
bts.0.oml-connection-state -d localhost -p 4249
^C
<snip>`
The trigger for TRAP is not GET request - those are orthogonal. The event which
causes the TRAP to be generated is the (dis)connection of BTS from/to BSC. So the
test sequence would look as follows:
1. Start OsmoBSC - `$ ./src/osmo-bsc/osmo-bsc -c ~/.config/osmocom/osmo-bsc.cfg`
2. Start bsc_control.py in monitor mode - `$ ./bsc_control.py -d localhost -m`
3. Start OsmoBTS `$ systemctl start sysmobts`
4. Stop OsmoBTS `$ ^c`
The last 2 actions should generated TRAPs.
Note that:
* the config files for BSC and BTS should match (same unit-id etc)
* the connection between BTS and BSC have to succeed (see the stderr/logs and
wireshark traces for OML [tcp port 3002 or tcp port 3003])
--
Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte