Project

General

Profile

Actions

Bug #5579

closed

Respect size limit of 130 data bytes in SCCP CR

Added by laforge over 1 year ago. Updated about 1 year ago.

Status:
Resolved
Priority:
Normal
Assignee:
Target version:
-
Start date:
06/16/2022
Due date:
% Done:

100%

Spec Reference:

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

Related to libosmo-sccp + libosmo-sigtran - 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 wireFeedbacklaforge03/28/2019

Actions
Related to OsmoHNBGW - 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-hnbgwResolved02/15/2023

Actions
Actions #2

Updated by laforge over 1 year ago

  • Assignee set to msuraev
Actions #3

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.
§4.3 Connection Confirm (CC):
  • send: ok, sccp_create_cc() do not put any optional data so we're within limit.
§4.4 Connection Refused (CREF):
  • send: ok, sccp_create_refuse() do not put any optional data so we're within limit.
§4.5 Released (RLSD):
  • 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.

Actions #4

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?

Actions #5

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.

Actions #6

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?

Actions #7

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.

Actions #8

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

Actions #9

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.

Actions #10

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
Actions #11

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.

Actions #12

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.

Actions #13

Updated by max over 1 year ago

  • Status changed from In Progress to Resolved
  • % Done changed from 20 to 100
Actions #14

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
Actions #15

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

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)