Actions
Bug #2441
closedchopped-off pointcodes
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.
Files
Actions