<p style="white-space: pre-wrap; word-wrap: break-word;">Please note we never saw any real specification for the IPA CCM protocol. We just implemented it based on what we understood by looking at protocol traces.</p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;"><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;"><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><li></li></ul></blockquote></blockquote><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;"><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). </p></blockquote><p style="white-space: pre-wrap; word-wrap: break-word;">feel free to submit a related update</p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;"><p style="white-space: pre-wrap; word-wrap: break-word;">In my trace of the msc it looks like the ack comes after the response, but that could just be a timing issue.</p></blockquote><pre style="font-family: monospace,monospace; white-space: pre-wrap;">We don't really know what is the correct way :/<br> <br>> 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.</pre><p style="white-space: pre-wrap; word-wrap: break-word;">You mean it send an ID_RQ from the MSC/MME/dia2gsup to the HLR?  This is certainly wrong.</p><p style="white-space: pre-wrap; word-wrap: break-word;">The ID_REQ is sent from the (TCP) server to the (TCP) client, as the server needs to identify who the client is.  In GSUP, the HLR is the server and everything else is a client.</p><pre style="font-family: monospace,monospace; white-space: pre-wrap;">It may very well be the case that the Erlang IPA implementation was first written for a server use case and I later used it without checking for the client side in GSUP.<br> <br>> HLR -> dia2gsup: ID_REQ</pre><p style="white-space: pre-wrap; word-wrap: break-word;">correct</p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;"><p style="white-space: pre-wrap; word-wrap: break-word;">dia2gsup -> HLR: ID_REQ (unconditional, see ipa_proto:unblock/1)</p></blockquote><p style="white-space: pre-wrap; word-wrap: break-word;">incorrect</p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;"><p style="white-space: pre-wrap; word-wrap: break-word;">dia2gsup -> HLR: ID_RESP</p></blockquote><p style="white-space: pre-wrap; word-wrap: break-word;">correct</p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;"><p style="white-space: pre-wrap; word-wrap: break-word;">[no app traffic, no HLR ack]</p></blockquote><p style="white-space: pre-wrap; word-wrap: break-word;">no ACK in either way</p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;"><p style="white-space: pre-wrap; word-wrap: break-word;">With this hack, the trace becomes:<br>HLR -> dia2gsup: ID_REQ</p></blockquote><p style="white-space: pre-wrap; word-wrap: break-word;">correct</p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;"><p style="white-space: pre-wrap; word-wrap: break-word;">dia2gsup -> HLR: ID_REQ (unconditional, see ipa_proto:unblock/1)</p></blockquote><p style="white-space: pre-wrap; word-wrap: break-word;">still incorrect</p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;"><p style="white-space: pre-wrap; word-wrap: break-word;">dia2gsup -> HLR: ID_RESP</p></blockquote><p style="white-space: pre-wrap; word-wrap: break-word;">correct</p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;"><p style="white-space: pre-wrap; word-wrap: break-word;">dia2gsup -> HLR: ID_ACK (hacked always after ID_RESP)<br>HLR -> dia2gsup: ID_ACK</p></blockquote><p style="white-space: pre-wrap; word-wrap: break-word;">those two lok good to me.  I don' think it matters much when they happen, but it always seemed logical to me to have the ACK phase after the REQ/RESP phase.</p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;"><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></blockquote><p style="white-space: pre-wrap; word-wrap: break-word;">I think this is again a result of the fact that the erlang IPA implementation wants to be the server, but actually is used as a client here.  I don't recall the code, but if this distinction is not there, please feel free to add some kind of flag that tells it whcih role it is to assume.<br>> Finally, if I do half and half... with dia2gsup sending an initial ack, but not responding to acks, I get a successful start<br>> <br>> 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;">this also looks valid to me, in-line with the pcap's I mentioned earlier</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: 3 </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: Sun, 20 Sep 2020 09:34:24 +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>