osmo-hnbgw seems to never discard RUA<->SUA mappings
attach a subscriber, and on the hnbgw vty, 'show hnb all'. This will show the hNodeB and two mappings for the subscriber, one for IuCS and one for IuPS.
HNB 192.168.0.15:61809 "firstname.lastname@example.org" MCC 901 MNC 70 LAC 24358 RAC 22 SAC 65535 CID 1048575 HNBAP ID 0 RUA ID 0 IuCS 25->1004 (RUA->SUA) state=1 IuPS 25->1005 (RUA->SUA) state=1
Put the phone in flight mode, the mappings remain. Re-attach the phone, two more mappings show up, and so on.
The mappings remain even after the log shows numerous
osmo-iuh/src/context_map.c:143 Running context mapper garbage collection
Make sure that this gets cleaned up at some point. I would expect at least after a UE Detach, the mappings should go away. I'd expect also right after a conn is closed, so that they are discarded e.g. when a Location Updating is done.
segfault: context_map gc: use llist_for_each_entry_safe()
The context map garbage collector removes entries from the list, hence it must
We haven't hit this before since nothing is yet flagging context maps to be
rua: discard context maps on id-Disconnect
When an id-Disconnect is received, the RUA to SCCP user context becomes unused.
Mark the context map as inactive in that case. It will be cleaned up by the
context map garbage collector.
#3 Updated by neels over 3 years ago
- Status changed from New to In Progress
- % Done changed from 0 to 70
indeed there is a context_map_deactivate() function, which only gets called when the entire hnb context gets torn down.
When to remove context maps? There is a RUA id-Disconnect class of messages, which coincides with an Iu-Release. It makes sense to invalidate a mapping at that point. OsmoHNBGW code already has some state for a mapping by which a discarded mapping remains reserved for two more garbage collector runs, after which it will be discarded.
Found another bug in the garbage collector: must use llist_for_each_entry_*safe* when discarding entries.
#4 Updated by neels over 3 years ago
a quite interesting question is: this context map maps RUA Context-IDs to SUA Context IDs (?) but we're not using SUA anymore. In immediate consequence, it maps RUA Context-IDs to prim->*.conn_id, but I'm having trouble to find any place where this prim conn_id is even used in the current M3UA stack when composing RANAP towards the CN. It seems that there must be some mapping in order for connection-ful messages to receive their responses back to RUA with the correct RUA Context-ID, but I can't find the prim conn_id sent up to RANAP anywhere. Could it be that the entire context_map mechanism in osmo-hnbgw is already superseded by some libosmo-sigtran feature?? Still looking...
#6 Updated by neels over 3 years ago
It is a bit confusing, but I found the locally created context ID in the SCCP Source Local Reference, where it belongs.
The confusing part is: we created e.g. the local reference id 1002 (decimal), and in the wireshark trace, I get 0xea0300. This looks like a completely unrelated ID, until I observe that hex(1002) = 0x03ea. It seems that either the wireshark dissector for SCCP is a bit crude, or that we encode the reference in the "wrong" byte order. As long as the references go back and forth in the same byte order, there isn't really a "wrong" byte order, yet this made it quite challenging to understand what was going on in the network trace.
#7 Updated by laforge over 3 years ago
each SCCP connection is identified (to the SCCP user, such as the hnb-gw) by a connection ID.
Compare the situation with a TCP Socket and think of it something like a socket file descriptor, which has only significance between the "socket provider" (kernel) and the "socket user" (your application program).
The source/destination local references are just present on the wire. Their only requirement is to be unique. There is no defined mapping between the locally-significant connection_id and the protocol-layer source/remote references!