The idea of this code is to
* provide a SCCP User SAP as boundary between the User of SCCP
or SCCP-like transport like SUA
* implement the minimum subset of SUA to transport RANAP messages
betweene HNB-GW and MSC/SGSN
At this point
* we don't yet implement the proper state machines and timer
* we don't imp[lement the SCCP RESET procedure
* we don't implement AS/ASP management
The code is full of FIXMEs whihc hopefully will get fixed gradually.
After some cleanup + verification, it should move to a library, possibly
either replacing/renaming libomo-sccp, or adding it to libosmo-netif?
When IMSI is a TBCD-STRING type, and TBCD-STRING is defined as OCTET
STRING, we end up encoding the IMSI the wrong way. I don't knwo why
that is, but changing it fixed the problem, as described below:
before this commit:
00 17 PeranentNAS-UE-ID
40 criticality ignore
0a (length)
00 presence = IMSI
08 BUG: why the additional length field?
46 23 91 34 70 77 80 f3 IMSI (643219430777083)
after this commit:
00 17 PeranentNAS-UE-ID
40 criticality ignore
09 (length)
50 presence = IMSI
46 23 91 34 70 77 80 f3 IMSI (643219430777083)
asn1tostruct.py generates three files. Try to teach the makefile that
all three of them depend on the .asn source file to ensure they're
re-built whenever the .asn source file changes.
encoding correctness still needs to be verified at this point. At least
they generate some binary output without failing somewhere earlier in
the encoding process - and they don't leave any leaked memory behind,
see talloc_report() at the end of test-ranap.c:main().
The definition of the above data types as per 3GPP specs results in a
SEQUENCE_OF() an anonymous structure, which is slightly inconvenient to
use. So let's split the SEQUENCE OF part and the actual definition of
the item in separate types.
There used to be a lot of code duplication between the code to generate
initiating, successfulOutcome and unsuccessfulOutcome messages. Try to
reduce that by callign a generic function.
So far, we copy-pasted/cherry-picked individual encoder/decoder
functions as the overall ranap_{encode,decode} didn't compile yet.
As the latter is now finally compiling, we can remove those copies and
link in ranap_{encode,decode}.o
This is not development, it is random trial and error hacking. I really
hate the fact that we have no useful asn.1 code generator and need to
work with hacks like asn1tostruct.py and asn1c without information
object classes :/
This commit is a one-day-long iteration of trial+error, manually editing
and adding the .asn source of RANAP until we get something that in the
end at least compiles and links. Do I trust the resulting code? No.
But we have no alternative :(
We shouldn't generate names like
RANAP_RAB_SetupList_EnhancedRelocCompleteReq__t when creating the
_encode() and _decode() functiosn, as the '-IEs' at the end must be
stripped before converting all '-' to '_'.
As asn1c cannot understand information object classes, we cannot compile
RANAP-PDU-Contents.asn but instead need to manually add the respective
infrmation elements to RANAP-PDU.asn.
This might need a lot of cleanup for out-of-source-tree builds and the
like, but let's not spend time on this now. The old Makefile also
didn't support that. But loosing the ability to regenerate the C source
is not an option either.
Harald Welte
Daniel Willmann