in order to work around a bug in asn1c. When we keep the original
TBCD-STRING, the APER-encoded PLMNidentity always has an extra leading
length byte that the decoder doesn't expect.
We now have the RUA and SUA parts interconnected by the
context ID mapper, and should be able to pass messages back and forward
between both sides.
Unfortunately this touches a bit of everything, but the structures are
all still very much in flux. Hopefully they will start to stabilize at
some point soon...
This socket doesn't do much yet except to connect to localhost:14001
The host/port needs to be made configurable, and the RUA<->SUA
interfacing needs to be implemented.
Also, we'll need two SUA sockets, one for MSC and one for SGSN.
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.