Bug #4867
openCinterion BGS2T failing to attach (no Attach Complete ever sent)
0%
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
Updated by pespin over 3 years 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).
Updated by pespin over 3 years ago
- File attach_complete_never_sent_nanobts.pcapng.gz attach_complete_never_sent_nanobts.pcapng.gz added
Same issue with a nanoBTS, so it's not a BTS/PCU bug from ours it seems.
Updated by pespin over 3 years ago
- 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).
- 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?
Updated by pespin over 3 years 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.
Updated by pespin over 3 years ago
- P-TMSI Signature
- Network Feature Support (with LCS-MLOR=0, MBMS=0, IMS VoPS=0, EMB BS=0)
Updated by pespin over 3 years 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.
Updated by pespin over 3 years ago
Removing the P-TMSI IE (and the P-TMSI signature I just introduced) doesn't work either. Same issue.
Updated by pespin over 3 years ago
Layer 3 GPRS ATTACH ACCEPT of commercial network, for later comparison:
080201490412F43008480119F4559A17051805F4D658E323B0
Updated by pespin over 3 years 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).
Updated by pespin over 3 years 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)
Updated by pespin over 3 years ago
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)
Updated by pespin over 3 years 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.
Updated by laforge over 3 years 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...
Updated by pespin over 3 years 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.