The SCCP CR payload length limit is now implemented in libosmo-sigtran
v1.7.0. The limit no longer needs to be enforced in osmo-hnbgw.
This reverts commit 2c91bd66a1,
except for keeping the cfg option, marked deprecated, and not doing
anything.
Fixes: OS#5906
Related: SYS#5968
Related: OS#5579
Depends: I174b2ce06a31daa5a129c8a39099fe8962092df8 (osmo-ttcn3-hacks)
Change-Id: I18dece84b33bbefce8617fbb0b2d79a7e5adb263
'map' is already guaranteed to be not NULL for that message type by the
preceding switch().
Related: CID#307434
Change-Id: Id30f459616391187aa2f8ad400c316e2144154c6
Clean up SCCP connections when a HNB disconnects.
When a HNB disconnects, we clean up all RUA <-> SCCP connection state
for that HNB. In that cleanup, discarding the SCCP connection is so far
missing.
Add a flag indicating true between SCCP CC and DISCONNECT. Hence we can
tell during context_map_deactivate() whether the cleanup is graceful
(DISCONNECT already sent) or non-graceful (need to DISCONNECT).
Change-Id: Icc2db9f6c0b2d0a814ff1110ffbe5e8f7f629222
Tested in ttcn3, by test cases not ready for submission (would require
enabling/disabling PFCP while osmo-hnbgw is running).
ttcn3 tests in I511e758807e0512c18f3f9e0a8c4699b9a3f5992
Related: SYS#6093
Change-Id: I39b9632f8524a9f3455c1a2d7611bfe8ba07c2fd
For the benefit of skipping decoding of all PS RANAP and RUA messages,
introduce code dup: decode CS and PS separately.
Related: SYS#5895
Change-Id: Ifb57bad6a0d5ff263e4c6c3facc51620e110e7d2
It is reported that a third-party SGSN is rejecting SCCP CR when the
SCCP message part exceeds a certain length. The solution is to first
send an SCCP CR without payload, and send the payload in a DT later.
Add config option
hnbgw
sccp cr max-payload-len <0-999999>
If the RANAP payload surpasses the given length, osmo-hnbgw will first
send an SCCP CR without payload, cache the RANAP payload, and put that
in an SCCP DT once the SCCP CC is received.
The original idea was to limit the size of the entire SCCP part of the
message, but I'm currently not sure how to determine that without
copying much of the osmo_sccp code. I figured using a limit on the RANAP
payload is sufficient. To avoid the error with above third-party SGSN,
the easy solution is to set max-payload-len to 0, so that we always get
a separate SCCP CR without payload.
Related: SYS#5968
Related: I827e081eaacfb8e76684ed1560603e6c8f896c38 (osmo-ttcn3-hacks)
Change-Id: If0c5c0a76e5230bf22871f527dcb2dbdf34d7328
There can be SCCP primitives without payload data, e.g. an "empty" SCCP
Connection Request.
Patch 'mgw_fsm: add MGW support to osmo-hnbgw' added RANAP message
decoding that lacks a guard against NULL data. Fix that: do not try to
decode NULL data.
Related: SYS#5968
Change-Id: Id755e769e82ace7203460ea1b3c847c2c90d41bf
osmo-hnbgw lacks support for an co-located media gateway. This makes it
virtually impossible to isolate the HNB from the core network properly.
Lets add MGCP support to osmo-hnbgw so that it can control a co-located
media gateway to relay the RTP streams between HNB and core network.
Change-Id: Ib9b62e0145184b91c56ce5d8870760bfa49cc5a4
Related: OS#5152
Neels Hofmeyr
Neels Hofmeyr
Philipp Maier
Pau Espin