Project

General

Profile

Bug #2441

chopped-off pointcodes

Added by dexter almost 2 years ago. Updated over 1 year ago.

Status:
Closed
Priority:
Urgent
Assignee:
Target version:
-
Start date:
08/15/2017
Due date:
% Done:

100%

Spec Reference:

Description

It seems that that the pointcode data is chopped off when receiving unittdata.

When looking at the attached trace.pcapng file, one can see that the RESET
command is correctly transmitted, but the response, the RESET ACK is always
sent to the wrong destination address. (187 instead of 2235). When converting
those to numbers one can see that the addresses seem to be chopped off,
presumably at the 8th bit:

2235 = 100010111011
187  =     10111011

When investigating further it turns out that the pointcode is already chopped
off when the RESET is received:

Tue Aug 15 11:35:20 2017 <000a> a_iface.c:531 N-UNITDATA.ind(00 04 30 04 01 20 )
Tue Aug 15 11:35:20 2017 <000a> a_iface_bssap.c:184 Rx BSC UDT: 00 04 30 04 01 20 
Tue Aug 15 11:35:20 2017 <000a> a_iface_bssap.c:157 Rx BSC UDT BSSMAP RESET
Tue Aug 15 11:35:20 2017 <000a> a_iface_bssap.c:110 Rx RESET from BSC RI=SSN_PC,PC=0.23.3,SSN=unknown 0xfe,GTI=NO_GT, sending RESET ACK
Tue Aug 15 11:35:20 2017 <000a> fsm.c:176 FSM RESET(FSM RESET INST)[0x55555589b7a0]{DISC}: Timeout of T0
Tue Aug 15 11:35:20 2017 <000a> a_reset.c:102 (RI=SSN_PC,PC=0.23.3,SSN=unknown 0xfe,GTI=NO_GT) reset-ack timeout (T0) in state ST_DISC (disconnected), resending...
Tue Aug 15 11:35:20 2017 <000a> a_iface.c:443 Sending RESET to BSC RI=SSN_PC,PC=0.23.3,SSN=unknown 0xfe,GTI=NO_GT

Presumably the upcoming primitive already contains the chopped pointcode.

trace.pcapng trace.pcapng 5.68 KB dexter, 08/15/2017 10:48 AM

History

#1 Updated by laforge over 1 year ago

  • Priority changed from Normal to Urgent

#2 Updated by laforge over 1 year ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 30

it's likely a wrong mask in osmo_sccp_addr_encode(), where we only permit 0x3ff, i.e. 10 bit long point codes. Need to double-chech what's the actual length of point coes permitted in ITU SCCP and fix similar to the diff below:

@@ -237,7 +237,7 @@ int osmo_sccp_addr_encode(struct msgb *msg, const struct osmo_sccp_addr *in)

        if (in->presence & OSMO_SCCP_ADDR_T_PC) {
                sca->point_code_indicator = 1;
-               msgb_put_u16le(msg, in->pc & 0x3ff);
+               msgb_put_u16le(msg, in->pc & 0x3fff);
        }

        if (in->presence & OSMO_SCCP_ADDR_T_SSN) {

#3 Updated by laforge over 1 year ago

#4 Updated by laforge over 1 year ago

  • Status changed from In Progress to Resolved
  • % Done changed from 30 to 100

The fix has been merged.

I've meanwhile implemented some test cases that should help us avoiding any regressions about this in https://gerrit.osmocom.org/#/c/4449/

#5 Updated by laforge over 1 year ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)