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/.
matt9j gerrit-no-reply at lists.osmocom.orgmatt9j 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 2: > Patch Set 2: > > > Patch Set 2: > > > > > adding neels here as he might know why osmo-msc behaves strangely. In either case, I'm happy to merge a work-around here. > > > > osmo-msc <-> osmo-hlr speaks GSUP/IPA. > > osmo-msc initializes this via osmo_gsup_client_create2(), from libosmo-gsup-client installed by osmo-hlr.git. > > That gsup client code calls ipa_client_conn_create2(), and I see nothing out of the ordinary. > > Neither osmo-msc nor osmo-hlr source trees contain IPAC_MSGT_ID_RESP or _ACK. > > > > So I assume if osmo-msc speaks weird IPA, then all our programs using ipa_client should behave just as weirdly. > > 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. 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. 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. 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. HLR -> dia2gsup: ID_REQ dia2gsup -> HLR: ID_REQ (unconditional, see ipa_proto:unblock/1) dia2gsup -> HLR: ID_RESP [no app traffic, no HLR ack] With this hack, the trace becomes: HLR -> dia2gsup: ID_REQ dia2gsup -> HLR: ID_REQ (unconditional, see ipa_proto:unblock/1) dia2gsup -> HLR: ID_RESP dia2gsup -> HLR: ID_ACK (hacked always after ID_RESP) HLR -> dia2gsup: ID_ACK [App traffic! Joy!] If I instead have dia2gsup send ID_ACK on startup, and disable the hack, we get stuck in an ack loop: HLR -> dia2gsup: ID_REQ dia2gsup -> HLR: ID_ACK HLR -> dia2gsup: ID_ACK dia2gsup -> HLR: ID_RESP dia2gsup -> HLR: ID_ACK HLR -> dia2gsup: ID_ACK dia2gsup -> HLR: ID_ACK HLR -> dia2gsup: ID_ACK dia2gsup -> HLR: ID_ACK HLR -> dia2gsup: ID_ACK dia2gsup -> HLR: ID_ACK HLR -> dia2gsup: ID_ACK ... 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!] 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. -- 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: 2 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: Fri, 18 Sep 2020 22:36:15 +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/20200918/d5b10d82/attachment.htm>