Further clarifications are inline. On 24.05.2017 21:07, emily mcmilin wrote: 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 ... 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. 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 &lt;msuraev(a)sysmocom.de&gt; 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

Hi. On 26.05.2017 19:13, emily mcmilin wrote: 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. 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. -- Max Suraev &lt;msuraev(a)sysmocom.de&gt; 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

Hi Max, Neels, 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 &lt;msuraev(a)sysmocom.de&gt; wrote: 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