Bug #2441
closedchopped-off pointcodes
100%
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.
Files
Updated by laforge over 6 years 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) {
Updated by laforge over 6 years 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/
