Bug #5579
closedRespect size limit of 130 data bytes in SCCP CR
100%
Description
ITU-T Q.713 states the DATA section of CR (and subsequent CREF or CC responses) is 130 bytes. This is different from the general 256 byte limit of DT1 or other messages. The same 130 byte limit applies to RLSD/RLC.
We should handle this in a generic way inside libosmo-sigtran so that applications trying to send > 130 byte payload in N-CONNECT.req will simply result in an empty CR followed by a delayed DT1 being sent. This way the applications don't have to care.
Related issues
Updated by msuraev over 1 year ago
- Status changed from New to In Progress
Relevant specs:
https://www.rfc-editor.org/rfc/rfc3868
https://www.itu.int/rec/T-REC-Q.713-200103-I/en
Low-level SCCP routines:
§4.2 Connection Request (CR):- send: ok, sccp_create_cr() enforces 130 bytes limit on data.
- send: ok, sccp_create_cc() do not put any optional data so we're within limit.
- send: ok, sccp_create_refuse() do not put any optional data so we're within limit.
- send: ok, sccp_create_rlsd() do not put any optional data so we're within limit.
Note: the limit does not applies to §4.6 Release complete (RLC) message since it has no optional data.
osmo_sccp_tx_conn_req(_msg)() are functions which supply optional data to lower levels, which can be triggered with 'connect-req' vty command in examples/ client in sccp-user mode.
Updated by msuraev over 1 year ago
- % Done changed from 0 to 10
I presume this should be done only for libosmo-sigtran. Or should I change old libosmo-sccp as well?
Updated by laforge over 1 year ago
Libosmo-sccp is not really used anywhere anymore, except some header files. So yes this is about libosmo-sigtran.
Updated by msuraev over 1 year ago
What do we do with other (CC/CREF/RLSD) messages? Also follow-up with DT1 like CR or just drop with error message?
Updated by laforge over 1 year ago
For CC yes, separate DT1.
For CREF and RLSD you cannot send any more DT1, as the state of the connection doesn't permit a DT1 later. For CREF we have to drop it. I guess for RLSD, the DT1 needs to be sent before the RLSD? Please checkthe state machines in the specs what is permitted.
Updated by neels over 1 year ago
Looking forward to seeing this implemented. So far I see patches that reject messages surpassing the limit, a patch that sends a separate DT1 isn't on gerrit yet, right?
Once this is done, we should be able to revert my patch to osmo-hnbgw, sending the separate DT1: https://gerrit.osmocom.org/c/osmo-hnbgw/+/28230
Updated by msuraev over 1 year ago
patch that sends a separate DT1 isn't on gerrit yet
Nope, I'm working on it. I've sent simple patches ahead to get the feedback earlier and avoid huge interdependent patch bombs.
patch to osmo-hnbgw, sending the separate DT1
That's a nice test-case, thanks for heads-up.
Updated by msuraev over 1 year ago
- Related to Bug #3871: osmo_scu_prim conn_id should be scoped per-user and direction, and should not correlate with the local-reference spoken on the SCCP wire added
Updated by msuraev over 1 year ago
- % Done changed from 10 to 20
The data limit for DT1/DT2 is 256 bytes but looking throughout SCCP/SCOC code (osmo_sccp_tx_data() and alike) I can't find where it's being enforced. Is there some segmentation/queue mechanism which guarantees that we'll never have malformed DTn?
My concern is how to properly handle CR/CC/RLSD with more than 256 bytes of optional data.
Updated by laforge over 1 year ago
On Sun, Aug 21, 2022 at 08:01:28AM +0000, msuraev wrote:
The data limit for DT1/DT2 is 256 bytes but looking throughout SCCP/SCOC code (osmo_sccp_tx_data() and alike) I can't find where it's being enforced. Is there some segmentation/queue mechanism which guarantees that we'll never have malformed DTn?
there is no segmentation/reassembly mechanism AFAIR
My concern is how to properly handle CR/CC/RLSD with more than 256 bytes of optional data.
I don't think it's even technically possible in the SCCP protocol due to the length fields being contrained to one byte.
Updated by max over 1 year ago
- Status changed from In Progress to Resolved
- % Done changed from 20 to 100
Applied in changeset libosmo-sccp|e5d615efdcffa9b248c555d1db5ce596649ef28d.
Updated by neels about 1 year ago
- Related to Feature #5906: SCCP CR has a 130 byte limit on data payload, now enforced in libosmo-sigtran. Remove 'sccp cr max-payload-len' cfg option from osmo-hnbgw added
Updated by neels about 1 year ago
This patch is released in libosmo-sigtran v1.7.0.
We still have essentially the same thing implemented in osmo-hnbgw, which was in fact the trigger for implementing this in libosmo-sigtran itself. I am now removing the osmo-hnbgw implementation of the SCCP CR data limit.
This is tracked in #5906
