Project

General

Profile

Actions

Bug #4867

open

Cinterion BGS2T failing to attach (no Attach Complete ever sent)

Added by pespin about 1 year ago. Updated about 1 year ago.

Status:
Stalled
Priority:
Normal
Assignee:
Target version:
-
Start date:
11/24/2020
Due date:
% Done:

0%

Spec Reference:

Description

AT+CGDCONT=1,"IP","internet" 
AT+CGATT=1

using osmocom network master with osmo-bts-trx-uhd + osmo-pcu

I see Attach procedure going on until GPRS Attach Accept is sent to the MS, then the MS never answers to it with a GPRS Attach Complete but still keeps interacting with the network ACKing all the DL data block (llc dummy frames) sent by the network, until it eventually tries to begin the whole GPRS Attach procedure again.

I attach a pcap file showing the issue.


Files

Actions #1

Updated by pespin about 1 year ago

Interesting bits:

First attach procedure starts at frame #21
Second attach procedure starts at frame #1135
Second attach procedure starts at frame #2366 (end)

First Attach Accept at frame #144.
The Attach Accept LLC frame #144 is sent on RLCMAC DL block BSN=5 in frame #151.
The BSN=5 is ACKED by the modem in DL ACK/NACK in frame #199.
After that point, the modem never seems to intend to send any uplink data (for instance by requesting a channel in a DL ACK/NACK).

Actions #2

Updated by pespin about 1 year ago

Same issue with a nanoBTS, so it's not a BTS/PCU bug from ours it seems.

Actions #3

Updated by pespin about 1 year ago

I did some verifications regarding the attach procedure:
  • Attach Request doesn't contain "integrity protection support" and hence we don't send back "Ms Network capbility IE" and "Radio Access Capabilitiy IE" in Attach Accept.
  • MS is sending IMSI in Attach Request so we "shall" (correctly) send PTMSI in Attach Response (3GPP TS 24.008 4.7.3.1.3 GPRS attach accepted by the network).
Interesting facts which may be issues:
  • MS in Attach Request sends RAI with LAC 0xfffe (65534) and we answer with RAI containing LAC 0x0005.
  • Could the issue be related to supported ciphering?
Actions #4

Updated by pespin about 1 year ago

I tried attaching with the modem to a commercial network and it attached correctly.

So there seems to be something we are doing wrong in our core network.

Actions #5

Updated by pespin about 1 year ago

Checking same commercial network with a TEMS phone, I see the GPRS attach process being really similar (GPRS only attached), but the commercial network is sending 2 more IEs in the GPRS Attach Accept:
  • P-TMSI Signature
  • Network Feature Support (with LCS-MLOR=0, MBMS=0, IMS VoPS=0, EMB BS=0)
Actions #6

Updated by pespin about 1 year ago

Adding a P-TMSI Signature=0 IE to the Attach Accept doesn't seem to help in fixing the situation. We already have some minimal code in place to send P-TMSI in osmo-sgsn, I simply had to remove the "#if 0" around it.

Actions #7

Updated by pespin about 1 year ago

Removing the P-TMSI IE (and the P-TMSI signature I just introduced) doesn't work either. Same issue.

Actions #8

Updated by pespin about 1 year ago

Layer 3 GPRS ATTACH ACCEPT of commercial network, for later comparison:

080201490412F43008480119F4559A17051805F4D658E323B0

Actions #9

Updated by pespin about 1 year ago

I added the Network Feature Support IE to GPRS Attach Accept and still same issue (https://gerrit.osmocom.org/c/osmo-sgsn/+/21381).

Ciphering seems to be working fine ("Authentication and Ciphering Req" + Resp are looking fine and similar to the commercial network ones), GEAS/0 (no ciphering) is being used.

So all I can think of is we are doing something wrong somewhere at LLC level and the modem is discarding the LLC frame containing the Attach Accept (it is ACKING the rlcmac block containing it just fine though).

Actions #10

Updated by pespin about 1 year ago

I tried changing the initial CS to CS4 instead of 2 to have plently of space to put the messages inside same rlcmac block (avoid fragmentation or simply change size so that boundaries change): still same issue.

TODO:
  • Check llc content of the message itself
  • Try getting rid of dummy blocks in same rlcmac message (see #4849)
  • inject known message from commercial network and see if MS answers with Attach Complete)
Actions #11

Updated by pespin about 1 year ago

I replaced our Attach Accept msg with the successful one from the commercial network (with and without changing RAI) and same issue, no Attach Complete.
So everything points to RLCMAC/LLC now:
  • Check llc content of the message itself
  • Try getting rid of dummy blocks in same rlcmac message (see #4849)
Actions #12

Updated by pespin about 1 year ago

  • Status changed from New to Stalled

After fixing the sending of LLC UI Dummy block in the same rlcmac block (#4849), still the same issue appears (no Attach Complete ever sent).

LLC of the Attach Accept looks good.
I'm starting to run out of ideas.

Actions #13

Updated by laforge about 1 year ago

On Fri, Nov 27, 2020 at 05:15:55PM +0000, pespin [REDMINE] wrote:

I'm starting to run out of ideas.

I guess this is the point where we'd rather look for a different GPRS-only MS
than try to sink tons of time in debugging the specific incompatibility here - as much
as I would love to understand this.

I currently don't recall off-my-head any GPRS-only (non-EGPRS) devices...

Actions #14

Updated by pespin about 1 year ago

Agree, it's going to be more productive for the task at hand to try finding another device.
I intend to give a look soon at which modems are around and try to find some candidate.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)