Actions
Bug #2718
closedipaccess_bts_handle_ccm() gets ID_REQ/ID_RESP/ID_ACK wrong
Start date:
12/06/2017
Due date:
% Done:
100%
Spec Reference:
Description
We've never had any documentation for the IPA CCM sub-protocol, but logic dictates [tm] that the sequence is as follows:
- BTS<-BSC IPA_IDENTITY_REQ (requesting unit-id etc.)
- BTS->BSC IPA_IDENTITY_RESP (responding with unit-id etc.)
- BTS<-BSC IPA_IDENTITY_ACK (acknowledging that the identity is known/welcome)
- BTS->BSC IPA_IDENTITY_ACK (another ack to ack the ack?)
- wait for any IPA_IDENTITY_REQ
- respond with IPA_IDENTITY_RESP
- immediately send an IPA_IDENTITY_ACK, no matter if the BSC/server sends an ACK first
And this code is used in our OsmoBTS code base :/
Related issues
Updated by laforge over 6 years ago
- Related to Bug #2719: OsmoBSC doesn't send BCCH filling after RSL connection unless BTS sends unsolicited message added
Updated by laforge about 6 years ago
actually, looking at my very firsrt pcap files between nanoBTS and BSC from 2010, it looks more like:
- BTS -> BSC TCP connection from BTS -> BSC
- BTS -> BSC: IPA_IDENTITY_ACK
- BTS <- BSC: IPA_IDENTITY_REQ
- BTS -> BSC: IPA_IDENTITY_RESP
- BTS <- BSC: IPA_IDENTITY_ACK
So the first ack from client (BTS) to server (BSC) is basically something like "I don't care about your identity, we are good to go, I as the client accept any identity you may have".
In the opposite direction, the BSC then asks for the BTS identity, to which the BTS responds, and only after that, the BSC indicates ACK to the BTS (and hence the BTS may proceed).
Updated by laforge about 6 years ago
So actually libosmo-abis is right and the TTCN IPA_Emulation code was wrong. Fixed in https://gerrit.osmocom.org/7861
Updated by laforge about 6 years ago
- Status changed from In Progress to Resolved
- % Done changed from 0 to 100
patch merged.
Actions