Project

General

Profile

Actions

Bug #5579

closed

Respect size limit of 130 data bytes in SCCP CR

Added by laforge 6 months ago. Updated 3 months 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 wireStalledosmith03/28/2019

Actions
Actions #2

Updated by laforge 5 months ago

  • Assignee set to msuraev
Actions #3

Updated by msuraev 4 months 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 4 months 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 4 months 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 4 months 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 4 months 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 4 months 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 4 months 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 4 months 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 4 months 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 4 months 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 3 months ago

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

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)