Project

General

Profile

Actions

Bug #2718

closed

ipaccess_bts_handle_ccm() gets ID_REQ/ID_RESP/ID_ACK wrong

Added by laforge over 6 years ago. Updated almost 6 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Target version:
-
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:
  1. BTS<-BSC IPA_IDENTITY_REQ (requesting unit-id etc.)
  2. BTS->BSC IPA_IDENTITY_RESP (responding with unit-id etc.)
  3. BTS<-BSC IPA_IDENTITY_ACK (acknowledging that the identity is known/welcome)
  4. BTS->BSC IPA_IDENTITY_ACK (another ack to ack the ack?)
Now the code in libosmo-abis/src/input/ipaccess.c, specifically in ipaccess_bts_handle_ccm() does the following:
  1. wait for any IPA_IDENTITY_REQ
  2. respond with IPA_IDENTITY_RESP
  3. 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

Related to OsmoBSC - Bug #2719: OsmoBSC doesn't send BCCH filling after RSL connection unless BTS sends unsolicited messageResolvedstsp12/06/2017

Actions
Actions #1

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
Actions #2

Updated by msuraev about 6 years ago

Could it be due to some quirk with nanoBTS?

Actions #3

Updated by laforge almost 6 years ago

actually, looking at my very firsrt pcap files between nanoBTS and BSC from 2010, it looks more like:

  1. BTS -> BSC TCP connection from BTS -> BSC
  2. BTS -> BSC: IPA_IDENTITY_ACK
  3. BTS <- BSC: IPA_IDENTITY_REQ
  4. BTS -> BSC: IPA_IDENTITY_RESP
  5. 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).

Actions #4

Updated by laforge almost 6 years ago

  • Status changed from New to In Progress
Actions #5

Updated by laforge almost 6 years ago

So actually libosmo-abis is right and the TTCN IPA_Emulation code was wrong. Fixed in https://gerrit.osmocom.org/7861

Actions #6

Updated by laforge almost 6 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 0 to 100

patch merged.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)