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. You#ve got to use either OsmoBSC or OpenGGSN ( see also https://projects.osmocom.org/issues/2235 ) for tests related to control interface.
As for adding test a way to produce such a trap for testing (via vty command for example) - sure, why not, should be relatively easy. Please make a ticket in https://projects.osmocom.org/ to make sure that it can be properly prioritized and won't be buried in ML archives.
On 01.06.2017 23:32, emily mcmilin wrote:
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
- 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`
- 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
- 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