Change in ...osmo_ss7[master]: ipa_proto: Allow configuring ack initiation behavior

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/gerrit-log@lists.osmocom.org/.

laforge gerrit-no-reply at lists.osmocom.org
Sun Sep 20 09:34:24 UTC 2020


laforge has posted comments on this change. ( https://gerrit.osmocom.org/c/erlang/osmo_ss7/+/20019 )

Change subject: ipa_proto: Allow configuring ack initiation behavior
......................................................................


Patch Set 3:

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.

> > The original IPA CCM handshake as we know it from nanoBTS (I just checked my pcap files from a decade ago) goes like this:
> > 
> > BTS -> BSC: TCP connect
> > BTS <- BSC: ID REQ
> > BTS -> BSC: ID ACK
> > BTS -> BSC: ID RESP
> > BSC <- BTS: ID ACK
> > ...
> > now we get OML traffic.
> > 
> > I also ahve seen the following
> > 
> > BTS -> BSC: TCP connect
> > BTS -> BSC: ID ACK
> > BTS <- BSC: ID REQ
> > BTS -> BSC: ID RESP
> > BTS <- BSC: ID ACK
> > 
> > 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".
> > 
> > I guess the important part is
> > * ID_REQ is responded to with ID_RESP
> > * once the client has received an ID ACK, it proceeds with the higher-level protocol.
> 

> 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). 

feel free to submit a related update

> In my trace of the msc it looks like the ack comes after the response, but that could just be a timing issue.

We don't really know what is the correct way :/
 
> 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.

You mean it send an ID_RQ from the MSC/MME/dia2gsup to the HLR?  This is certainly wrong.

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.

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.
 
> HLR -> dia2gsup: ID_REQ

correct

> dia2gsup -> HLR: ID_REQ (unconditional, see ipa_proto:unblock/1)

incorrect

> dia2gsup -> HLR: ID_RESP

correct

> [no app traffic, no HLR ack]

no ACK in either way

> With this hack, the trace becomes:
> HLR -> dia2gsup: ID_REQ

correct

> dia2gsup -> HLR: ID_REQ (unconditional, see ipa_proto:unblock/1)

still incorrect

> dia2gsup -> HLR: ID_RESP

correct

> dia2gsup -> HLR: ID_ACK (hacked always after ID_RESP)
> HLR -> dia2gsup: ID_ACK

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.

> If I instead have dia2gsup send ID_ACK on startup, and disable the hack, we get stuck in an ack loop:

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.
> Finally, if I do half and half... with dia2gsup sending an initial ack, but not responding to acks, I get a successful start
> 
> HLR -> dia2gsup: ID_REQ
> dia2gsup -> HLR: ID_ACK
> HLR -> dia2gsup: ID_ACK
> dia2gsup -> HLR: ID_RESP
> [App traffic! Joy!]

this also looks valid to me, in-line with the pcap's I mentioned earlier


-- 
To view, visit https://gerrit.osmocom.org/c/erlang/osmo_ss7/+/20019
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings

Gerrit-Project: erlang/osmo_ss7
Gerrit-Branch: master
Gerrit-Change-Id: I6ab3c9efb51e806f582ce8f473a13ee73ca1567e
Gerrit-Change-Number: 20019
Gerrit-PatchSet: 3
Gerrit-Owner: matt9j <matt9j at cs.washington.edu>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: fixeria <vyanitskiy at sysmocom.de>
Gerrit-Reviewer: laforge <laforge at osmocom.org>
Gerrit-Reviewer: matt9j <matt9j at cs.washington.edu>
Gerrit-Reviewer: neels <nhofmeyr at sysmocom.de>
Gerrit-Comment-Date: Sun, 20 Sep 2020 09:34:24 +0000
Gerrit-HasComments: No
Gerrit-Has-Labels: No
Gerrit-MessageType: comment
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20200920/dfd0e153/attachment.htm>


More information about the gerrit-log mailing list