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])

Hi.

On 26.05.2017 19:13, emily mcmilin wrote:

I am running osmo-nitb, and it my preference to continue to do so. Will that be a problem?

Not really, but in this case you'll have to use ctrl variables from corresponding user manual. In case of osmo-nitb there's no bts_connection_status. You can use, for example, net.0.bsc.N.notification-rejection-v1 to get TRAP message when phone is rejected. Simply try to connect to your network using sim card which is not allowed and you should receive TRAP with that sim IMSI.

I have confidence that there is proper communication between my BTS and BSC, because when I SET arfcn (as in the example below) and then powerup/down my SysmoBTS, the arfcn does properly update (as verified on a sig analyzer).

$ python ~/openbsc/openbsc/contrib/bsc_control.py -s bts.0.trx.0.arfcn 148 -d localhost -p 4249

However, issuing the command to TRAP oml connection state (example below), traps no message when I powerup/down the SysmoBTS:

$ python ~/openbsc/openbsc/contrib/bsc_control.py -m bts.0.oml-connection-state -d localhost -p 4249

Would you expect a TRAP command to captured in the immediately above example?

No, that won't work because there's simply no trap in osmo-nitb which is generated for BTS (dis)connection. Also, there's no need to specify which variable you're expecting as a TRAP - this'll be ignored and you'll get the TRAP for all variables anyway.

You've got to check "Control interface" chapter of user manual for whatever program you're using. I've used OsmoBSC just as a quickstart example, if you're using anything else, than you've got to check for variable names in the manual with "Trap=Yes" (if any) and use them. The variables are program-specific: those which are available in osmo-bsc might be absent in osmo-nitb and vice versa. In case of NITB I suggest to use net.0.bsc.N.notification-rejection-v1 where N is the number you've used in your NITB config for bts entry (use 0 if unsure).

Also, let me stress again orthogonality of SET/GET operation to TRAP messages. If there's variable which could GET it doesn't mean there's corresponding TRAP. It works other way around too - if theres a TRAP with given name it does not mean that there's variable with the same name which you could GET. It might be, it might be not - that's why we've got to consult the manual which have separate columns for Access (RW means Read/Write - both SET and GET are possible, RO means ReadOnly - only GET is possible, etc) and Trap.

Of course we can add TRAP filtering to bsc_control.py as well as bts_connection_status to osmo-nitb if necessary but I think it's a subject of a separate discussion.

Hi Max, Neels,

In case of NITB I suggest to use net.0.bsc.N.notification-rejection-v1 where N is the number you've used in your NITB config for bts entry (use 0 if unsure).

Is it possible include a programmatic way to test TRAP functionality for osmo-nitb? As I am not clear on what triggers a "notification-rejection-v1", I am unable to verify the TRAP functionality, however I have tried to following:

while 1) running bsc_control.py with TRAP option in terminal 1: `vagrant@endaga-client-osmocom:~$ python ~/openbsc/openbsc/contrib/bsc_control.py -m -d localhost -p 4249`

2) blocking a physical phone that was previously connected: a) attaching a phone with the auth policy set as: `auth policy accept-all` b) changing the auth policy to `auth policy closed` and instigating failed attempts to attach the same phone

and

3) modifying and then deleting an arbitrary subscriber, which did not appear to be a meaningful test of the issuance of a "notification-rejection-v1" TRAP message, given failure setup noted below: ``` vagrant@endaga-client-osmocom:~$ python ~/openbsc/openbsc/contrib/bsc_control.py -s subscriber-modify-v1 2620345,445566 -d localhost -p 4249 Got message: SET_REPLY 2448569608243303391 subscriber-modify-v1 OK vagrant@endaga-client-osmocom:~$ python ~/openbsc/openbsc/contrib/bsc_control.py -s subscriber-delete-v1 2620345,445566 -d localhost -p 4249 Got message: ERROR 719581889546954682 Failed to find subscriber vagrant@endaga-client-osmocom:~$ ```

Nonetheless, neither produced any TRAP message in terminal 1.

Please let me know your thoughts on a including a programmatic way to test TRAP functionality for osmo-nitb.

Thanks, Emily

Hi Max,

Thanks for your update and sorry for my delayed response.

On Thu, Jun 8, 2017 at 1:35 AM, Max msuraev@sysmocom.de wrote:

Ah, sorry, my bad - I've mixed up osmo-bsc_nat with osmo-nitb. I'm afraid at the moment there's no way to produce TRAP from OsmoNITB.

I have created an issue requesting the addition of a TRAP implementation TO the CTRL interface in OsmoNITB:

https://projects.osmocom.org/issues/2331

Thanks, Emily