Log errors in case the user provides global title indicators or
nature-of-address indicators that exceed the permitted value range
Change-Id: I493b7810bdc58e448f496565ded36f9dce2c1226
In osmo_sccp_addr_encode(), we accidentially truncated all point
codes to 10 bits, where in reality we should have truncated them to
14 bits: One 'f' was missing in the bit-mask.
Closes: OS#2441
Change-Id: Iad67b674b5b5fd41996aa898a131e98900842dd8
SUA uses different semantics (source / destination) address, while SCCP
uses Calling/CalledParty. This leads to some confusion. At least in the
CR/CORE and CREF/COREF case, the CallingParty equals the SRC_ADDR.
Change-Id: I1c641aac7b53c6de7c4e369aaf3004523bd85936
"(cur[1] << 8) & 0x3f" is always 0 regardless of the values of its
operands.
Change-Id: Ie47e632f4bca490baf4282dc5d55ee55ca7f1ae8
Fixes: coverity CID#166932
The SCCP spec clearly defines which optional information element each of
the messages supports. We must make sure to not include any other
options when converting from SUA. SUA has more relaxed rules about
this, and e.g. supports SRC and DEST ADDR in the COAK, while the SCCP CC
only permits a CalledParty, but not CallingParty.
This was found when interoperating against the Ericsson TTCN-3 SCCP
implementation for Eclipse Titan.
Change-Id: I7d9e23dec1d3e786d291abd270a261704593befc
Harald Welte
Neels Hofmeyr