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