<blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;"><p style="white-space: pre-wrap; word-wrap: break-word;">Patch Set 2:</p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;"><p style="white-space: pre-wrap; word-wrap: break-word;">Patch Set 2:</p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;"><p style="white-space: pre-wrap; word-wrap: break-word;">adding neels here as he might know why osmo-msc behaves strangely.  In either case, I'm happy to merge a work-around here.</p></blockquote><p style="white-space: pre-wrap; word-wrap: break-word;">osmo-msc <-> osmo-hlr speaks GSUP/IPA.<br>osmo-msc initializes this via osmo_gsup_client_create2(), from libosmo-gsup-client installed by osmo-hlr.git.<br>That gsup client code calls ipa_client_conn_create2(), and I see nothing out of the ordinary.<br>Neither osmo-msc nor osmo-hlr source trees contain IPAC_MSGT_ID_RESP or _ACK.</p><p style="white-space: pre-wrap; word-wrap: break-word;">So I assume if osmo-msc speaks weird IPA, then all our programs using ipa_client should behave just as weirdly.</p></blockquote><p style="white-space: pre-wrap; word-wrap: break-word;">The original IPA CCM handshake as we know it from nanoBTS (I just checked my pcap files from a decade ago) goes like this:</p><p style="white-space: pre-wrap; word-wrap: break-word;">BTS -> BSC: TCP connect<br>BTS <- BSC: ID REQ<br>BTS -> BSC: ID ACK<br>BTS -> BSC: ID RESP<br>BSC <- BTS: ID ACK<br>...<br>now we get OML traffic.</p><p style="white-space: pre-wrap; word-wrap: break-word;">I also ahve seen the following</p><p style="white-space: pre-wrap; word-wrap: break-word;">BTS -> BSC: TCP connect<br>BTS -> BSC: ID ACK<br>BTS <- BSC: ID REQ<br>BTS -> BSC: ID RESP<br>BTS <- BSC: ID ACK</p><p style="white-space: pre-wrap; word-wrap: break-word;">which seems to indicate that the BSC was a bit slow in sending the ID REQ, and that the BTS was faster sending that BTS-originated "ACK".</p><p style="white-space: pre-wrap; word-wrap: break-word;">I guess the important part is</p><ul><li>ID_REQ is responded to with ID_RESP</li><li>once the client has received an ID ACK, it proceeds with the higher-level protocol.</li></ul></blockquote><p style="white-space: pre-wrap; word-wrap: break-word;">Ah, interesting. I think I understand what is going on now. It looks like there actually may be some weirdness with the HLR, not the MSC. If below is not intended behavior, I am happy to open up a ticket.</p><p style="white-space: pre-wrap; word-wrap: break-word;">In the osmocom docs for the IPA spec (I think the latest is here? https://ftp.osmocom.org/docs/latest/osmobts-abis.pdf ...if I'm looking at an old version that would explain things too) there is no mention of the bts originated ack in the ccm section (3.3). In my trace of the msc it looks like the ack comes after the response, but that could just be a timing issue.</p><p style="white-space: pre-wrap; word-wrap: break-word;">The existing code in the erlang module sends an ID_REQ from the BTS to the HLR on socket connect, and the HLR never responds, but also seems to not proceed to the higher-level protocol.</p><p style="white-space: pre-wrap; word-wrap: break-word;">HLR -> dia2gsup: ID_REQ<br>dia2gsup -> HLR: ID_REQ (unconditional, see ipa_proto:unblock/1)<br>dia2gsup -> HLR: ID_RESP<br>[no app traffic, no HLR ack]</p><p style="white-space: pre-wrap; word-wrap: break-word;">With this hack, the trace becomes:<br>HLR -> dia2gsup: ID_REQ<br>dia2gsup -> HLR: ID_REQ (unconditional, see ipa_proto:unblock/1)<br>dia2gsup -> HLR: ID_RESP<br>dia2gsup -> HLR: ID_ACK (hacked always after ID_RESP)<br>HLR -> dia2gsup: ID_ACK<br>[App traffic! Joy!]</p><p style="white-space: pre-wrap; word-wrap: break-word;">If I instead have dia2gsup send ID_ACK on startup, and disable the hack, we get stuck in an ack loop:</p><p style="white-space: pre-wrap; word-wrap: break-word;">HLR -> dia2gsup: ID_REQ<br>dia2gsup -> HLR: ID_ACK<br>HLR -> dia2gsup: ID_ACK<br>dia2gsup -> HLR: ID_RESP<br>dia2gsup -> HLR: ID_ACK<br>HLR -> dia2gsup: ID_ACK<br>dia2gsup -> HLR: ID_ACK<br>HLR -> dia2gsup: ID_ACK<br>dia2gsup -> HLR: ID_ACK<br>HLR -> dia2gsup: ID_ACK<br>dia2gsup -> HLR: ID_ACK<br>HLR -> dia2gsup: ID_ACK ...</p><p style="white-space: pre-wrap; word-wrap: break-word;">Finally, if I do half and half... with dia2gsup sending an initial ack, but not responding to acks, I get a successful start</p><p style="white-space: pre-wrap; word-wrap: break-word;">HLR -> dia2gsup: ID_REQ<br>dia2gsup -> HLR: ID_ACK<br>HLR -> dia2gsup: ID_ACK<br>dia2gsup -> HLR: ID_RESP<br>[App traffic! Joy!]</p><p style="white-space: pre-wrap; word-wrap: break-word;">I will update this change to do this last behavior, with configuration to determine if it initiates with an ack and then does not re-ack, or initiates with a request and then does re-ack.</p><p><a href="https://gerrit.osmocom.org/c/erlang/osmo_ss7/+/20019">View Change</a></p><ul style="list-style: none; padding: 0;"></ul><p>To view, visit <a href="https://gerrit.osmocom.org/c/erlang/osmo_ss7/+/20019">change 20019</a>. To unsubscribe, or for help writing mail filters, visit <a href="https://gerrit.osmocom.org/settings">settings</a>.</p><div itemscope itemtype="http://schema.org/EmailMessage"><div itemscope itemprop="action" itemtype="http://schema.org/ViewAction"><link itemprop="url" href="https://gerrit.osmocom.org/c/erlang/osmo_ss7/+/20019"/><meta itemprop="name" content="View Change"/></div></div>

<div style="display:none"> Gerrit-Project: erlang/osmo_ss7 </div>
<div style="display:none"> Gerrit-Branch: master </div>
<div style="display:none"> Gerrit-Change-Id: I6ab3c9efb51e806f582ce8f473a13ee73ca1567e </div>
<div style="display:none"> Gerrit-Change-Number: 20019 </div>
<div style="display:none"> Gerrit-PatchSet: 2 </div>
<div style="display:none"> Gerrit-Owner: matt9j <matt9j@cs.washington.edu> </div>
<div style="display:none"> Gerrit-Reviewer: Jenkins Builder </div>
<div style="display:none"> Gerrit-Reviewer: fixeria <vyanitskiy@sysmocom.de> </div>
<div style="display:none"> Gerrit-Reviewer: laforge <laforge@osmocom.org> </div>
<div style="display:none"> Gerrit-Reviewer: matt9j <matt9j@cs.washington.edu> </div>
<div style="display:none"> Gerrit-Reviewer: neels <nhofmeyr@sysmocom.de> </div>
<div style="display:none"> Gerrit-Comment-Date: Fri, 18 Sep 2020 22:36:15 +0000 </div>
<div style="display:none"> Gerrit-HasComments: No </div>
<div style="display:none"> Gerrit-Has-Labels: No </div>
<div style="display:none"> Gerrit-MessageType: comment </div>