Bug #3427
closedipa: DTAP received on RSL is not sent through to IPA MSC
0%
Description
At first, during N-CONNECT, the RSL request is going through to BSSMAP/IPA fine:
20180727183939313 DCHAN DEBUG abis_rsl.c:1612 lchan(0-0-0-CCCH_SDCCH4-0)[0x6120000021a0]{WAIT_RLL_RTP_ESTABLISH}: (type=SDCCH) SAPI=0 ESTABLISH INDICATION
20180727183939313 DCHAN DEBUG abis_rsl.c:1645 lchan(0-0-0-CCCH_SDCCH4-0)[0x6120000021a0]{WAIT_RLL_RTP_ESTABLISH}: Received Event LCHAN_EV_RLL_ESTABLISH_IND
20180727183939313 DCHAN DEBUG lchan_fsm.c:710 lchan(0-0-0-CCCH_SDCCH4-0)[0x6120000021a0]{WAIT_RLL_RTP_ESTABLISH}: state_chg to ESTABLISHED
20180727183939313 DMSC NOTICE fsm.c:299 SUBSCR_CONN[0x612000003220]{INIT}: Allocated
20180727183939313 DLCLS NOTICE fsm.c:299 LCLS[0x6120000033a0]{NO_LCLS}: Allocated
20180727183939313 DLCLS NOTICE fsm.c:329 LCLS[0x6120000033a0]{NO_LCLS}: is child of SUBSCR_CONN[0x612000003220]
20180727183939313 DMSC INFO gsm_08_08.c:373 Tx MSC COMPL L3
20180727183939314 DMSC NOTICE osmo_bsc_sigtran.c:285 Initializing resources for new SIGTRAN connection to MSC: RI=SSN_PC,PC=100,SSN=BSSAP...
20180727183939314 DMSC NOTICE gsm_08_08.c:500 SUBSCR_CONN[0x612000003220]{INIT}: Received Event MO-CONNECT.req
20180727183939314 DMSC DEBUG osmo_bsc_sigtran.c:327 Allocated new connection id: 1
20180727183939314 DMSC NOTICE osmo_bsc_sigtran.c:331 Opening new SIGTRAN connection (id=1) to MSC: RI=SSN_PC,PC=100,SSN=BSSAP
20180727183939314 DLSCCP DEBUG sccp_scoc.c:1615 Received SCCP User Primitive N-CONNECT.request)
20180727183939314 DLSCCP DEBUG fsm.c:299 SCCP-SCOC(1)[0x612000003520]{IDLE}: Allocated
20180727183939314 DLSCCP DEBUG sccp_scoc.c:1657 SCCP-SCOC(1)[0x612000003520]{IDLE}: Received Event N-CONNECT.req
20180727183939314 DLSS7 DEBUG sccp_scrc.c:398 sccp_scrc_rx_scoc_conn_msg: HDR=(CO:CORE,V=0,LEN=0),
PART(T=Routing Context,L=4,D=00000000),
PART(T=Protocol Class,L=4,D=00000002),
PART(T=Source Reference,L=4,D=00000001),
PART(T=Destination Address,L=20,D=00020003800200080000006480030008000000fe),
PART(T=Sequence Control,L=4,D=00000000),
PART(T=Source Address,L=20,D=0002000380020008000004ac80030008000000fe),
PART(T=Data,L=30,D=001c5705080032f44000c851e0170f05080232f44000c85005f45b45589f)
20180727183939314 DLSUA DEBUG sua.c:385 sua_addr_parse_part(IEI=0x0103) (20) 00 02 00 03 80 02 00 08 00 00 00 64 80 03 00 08 00 00 00 fe
20180727183939314 DLSUA DEBUG sua.c:439 SUA IEI 0x0103 pos 4/20: subpart tag 0x8002, len 8
20180727183939314 DLSUA DEBUG sua.c:439 SUA IEI 0x0103 pos 12/20: subpart tag 0x8003, len 8
20180727183939314 DLSUA DEBUG sua.c:385 sua_addr_parse_part(IEI=0x0103) (20) 00 02 00 03 80 02 00 08 00 00 00 64 80 03 00 08 00 00 00 fe
20180727183939315 DLSUA DEBUG sua.c:439 SUA IEI 0x0103 pos 4/20: subpart tag 0x8002, len 8
20180727183939315 DLSUA DEBUG sua.c:439 SUA IEI 0x0103 pos 12/20: subpart tag 0x8003, len 8
20180727183939315 DLSUA DEBUG sua.c:385 sua_addr_parse_part(IEI=0x0102) (20) 00 02 00 03 80 02 00 08 00 00 04 ac 80 03 00 08 00 00 00 fe
20180727183939315 DLSUA DEBUG sua.c:439 SUA IEI 0x0102 pos 4/20: subpart tag 0x8002, len 8
20180727183939315 DLSUA DEBUG sua.c:439 SUA IEI 0x0102 pos 12/20: subpart tag 0x8003, len 8
20180727183939315 DLSS7 DEBUG osmo_ss7_hmrt.c:278 m3ua_hmdc_rx_from_l2(): dpc=100=100 not local, message is for routing
20180727183939315 DLSS7 DEBUG osmo_ss7_hmrt.c:227 Found route for dpc=100=100: pc=0=0 mask=0x0=0 via AS as-clnt-msc-0 proto=ipa
20180727183939315 DLSCCP DEBUG sccp_scoc.c:732 SCCP-SCOC(1)[0x612000003520]{IDLE}: state_chg to CONN_PEND_OUT
20180727183939315 DMSC NOTICE bsc_subscr_conn_fsm.c:253 SUBSCR_CONN[0x612000003220]{INIT}: state_chg to WAIT_CC
20180727183939315 DLINP DEBUG stream.c:279 connected write
20180727183939315 DLINP DEBUG stream.c:204 sending data
20180727183939315 DLINP DEBUG stream.c:279 connected write
20180727183939315 DLINP DEBUG stream.c:204 sending data
But right after than, e.g on an MM Identity Response, the message is not routed to the MSC:
20180727183939782 DCHAN DEBUG abis_rsl.c:1603 lchan(0-0-0-CCCH_SDCCH4-0)[0x6120000021a0]{ESTABLISHED}: (type=SDCCH) SAPI=0 DATA INDICATION
20180727183939783 DMSC INFO gsm_08_08.c:601 Tx MSC DTAP LINK_ID=0x00
20180727183939783 DMSC NOTICE gsm_08_08.c:623 SUBSCR_CONN(conn1)[0x612000003220]{ACTIVE}: Received Event MO_DTAP
20180727183939783 DMSC INFO osmo_bsc_sigtran.c:363 Tx MSC DTAP
20180727183939783 DMSC DEBUG osmo_bsc_sigtran.c:381 Sending connection (id=1) oriented data to MSC: RI=SSN_PC,PC=100,SSN=BSSAP (01 00 0b 05 59 08 3a 65 24 05 35 31 76 08 )
20180727183939783 DLSCCP DEBUG sccp_scoc.c:1615 Received SCCP User Primitive N-DATA.request)
20180727183939783 DLSCCP DEBUG sccp_scoc.c:1657 SCCP-SCOC(1)[0x612000003520]{ACTIVE}: Received Event N-DATA.req
20180727183939783 DLSS7 DEBUG sccp_scrc.c:398 sccp_scrc_rx_scoc_conn_msg: HDR=(CO:CODT,V=0,LEN=0),
PART(T=Routing Context,L=4,D=00000000),
PART(T=Destination Reference,L=4,D=001f0000),
PART(T=Data,L=14,D=01000b0559083a65240535317608)
20180727183939783 DLSCCP ERROR sccp_scrc.c:138 MTP-TRANSFER.req from SCCP without DPC?!? called=RI=0
The log clearly shows DPC=100, yet sccp_scrc.c:138 complains about a missing DPC.
Updated by neels over 5 years ago
actually, osmo-bsc logs the msc->a.msc_addr, but calls osmo_sccp_tx_data_msg(msc->a.sccp_user,...), so it logs something else than it is in fact doing.
When logging the SCCP user instead, I get:
20180727190803569 DMSC DEBUG osmo_bsc_sigtran.c:381 Sending connection (id=1) oriented data to MSC: msc-0:RI=SSN_PC,PC=(no PC),SSN=BSSAP (01 00 0b 05 59 08 29 43 35 00 10 01 00 52 )
so it's probably an osmo-bsc issue, not a libosmo-sigtran one.
Updated by neels over 5 years ago
- Status changed from In Progress to Rejected
It all comes down to cs7 / as / point-code override dpc needing to point to the MSC's point-code.
I can't say I understand why this is so, but the sccp conn constantly takes on the remote PC (conn->remote_pc) from incoming messages, and also overwrites the outgoing messages with that conn->remote_pc. It seems odd to me that it isn't sufficient to configure a remote PC to connect to, set that once, and keep it that way.
Now, over IPA, some messages seem to come in without SCCP addresses at all. I see that only the first connection establishment contains SCCP addresses with point-codes, and after that the SCCP part simply contains a destination local reference. Since there are no point-codes in the messages, it seems to me odd to want to remember that message's point-code.
Since conn->remote_pc is always set to whatever PC was seen coming in, we require to override the incoming PC to a value. Instead of figuring that out from the MSC's SCCP address, we seem to explicitly require the 'point-code override dpc 1234' setting to do so.
Maybe I'm ignorant and naive, but browsing the code and trying to understand what was going on had me really confused and not understanding why the PC handling can't be simpler than that.
I don't understand why we have an SCCP address book and set the MSC's SCCP address in 'msc' / 'msc-addr <addr-book-name>' when we override the PC in the AS already.
Bottom line is: IPA absolutely requires the 'point-code overide dpc' set to the MSC's remote PC, and it had better match the one we're normally getting on incoming messages.
Updated by laforge over 5 years ago
On Fri, Jul 27, 2018 at 06:49:00PM +0000, neels [REDMINE] wrote:
I can't say I understand why this is so, but the sccp conn constantly takes on the remote PC
(conn->remote_pc) from incoming messages, and also overwrites the outgoing messages with that
conn->remote_pc. It seems odd to me that it isn't sufficient to configure a remote PC to connect to, set
that once, and keep it that way.
I'm not quite following you here, sorry.
Now, over IPA, some messages seem to come in without SCCP addresses at all. I see that only the first connection establishment contains SCCP addresses with point-codes, and after that the SCCP part simply contains a destination local reference.
This is true for any connection-oriented SCCP, whether over IPA or not.
Since there are no point-codes in the messages, it seems to me odd to want to remember that message's
point-code.
There are Point Codes at the SCCP level (which only exist in the first
connection establishment), and there are point codes at the SS7/MTP
level. SCCP routing is what determines the MTP-level point codes based
on SCCP addresses and/or other policy.
I don't understand why we have an SCCP address book and set the MSC's SCCP address in 'msc' / 'msc-addr <addr-book-name>' when we override the PC in the AS already.
Because the Point code at SCCP level is not the point code at "MTP" level (which can be real MTP, M3UA or IPA).
After the SCCP code has encoded the SCCP message from a parsed structure
into a binary, it sends it to the MTP/SS7 code and routes it to a point
code that was derived based on SCCP routing. In real MTP or M3UA, the
point code (DPC) is actually part of a message and hence later on,
inside the M3UA code, we know to which point code to send it.
In IPA, there is no MTP/M3UA header and no way where at "below SCCP
level" one could store a point code. We only have a binary/encoded SCCP
message, and no routing label (DPC) that we can parse. How should we
perform a routing decision here? Re-parse the SCCP message in a layer
that isn't supposed to know anything about SCCP in the first place? And
even in that case, as you have noticed, most connection-oriented SCCP
messages don't contain a point-code.
So you would have to have some kind of persistent state about
connections/flows, in a protocol layer that has no notion of it,
basically doing "SCCP connection tracking" inside the IPA layer?
Also, what if the SCCP layer is in some use case (beyond A interface)
using SCCP addresses that don't even contain point codes?
I'm always open to improve the codebase, but when implementing it I
couldn't really find any easier / more straight-forward approach.
Also, keep in mind that IPA/SCCPlite is legacy-only, used by only very
few users/deployments, and it's easy to have one additional config line
in those cases.
Regards,
Harald
