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.