Project

General

Profile

Bug #3499

pcu is logging "Allocating DL TBF: MS_CLASS=0/0" ; TLV parsing code commented?

Added by keith over 1 year ago. Updated about 10 hours ago.

Status:
New
Priority:
Normal
Assignee:
Target version:
-
Start date:
08/24/2018
Due date:
% Done:

0%

Spec Reference:

Description

This also relates to this error seen with EGPRS capable phone:
"Not accepting non-EGPRS phone in EGPRS-only mode"

However, in GPRS mode, this does not appear to make any immediately obvious difference to functionality, but all the same, MS_CLASS=0/0 is obviously wrong.

This is because the code to parse the MS RA Cap is commented, with a note:

"Do not rely on this IE."

As far as I can tell from analysis of NS trace, the BSSGP contains correct Radio Access Capability IE, that is to say, It is corresponding with what the MS sent in the Attach Request.

So why "do not rely?" Why is the code commented? Perhaps in 2016, this information from the BSSGP was not reliable?

See http://git.osmocom.org/osmo-pcu/commit/?id=741d25cb6f8c0c1522cf6d1be2fea49356ecd4bd
and the two previous commits.


Related issues

Related to OsmoPCU - Feature #1525: Use the Radio Access Capabilites that are being transferred via BSSGP (downlink)New02/22/2016

History

#1 Updated by laforge over 1 year ago

#2 Updated by msuraev about 1 year ago

  • Related to Feature #1525: Use the Radio Access Capabilites that are being transferred via BSSGP (downlink) added

#3 Updated by laforge 9 months ago

  • Assignee set to lynxis

#4 Updated by laforge 15 days ago

  • Assignee deleted (lynxis)

#5 Updated by pespin 1 day ago

This ticket is a duplicate (talking about same issue) of #1525

We need to add some TTCN3 test to check emulation-SGSN sending this data to PCU and make sure it's taken into account.

Related code: gprs_bssgp_pcu_rx_dl_ud() (src/gprs_bssgp_pcu.cpp).

Related commits (from older to newer, they are together in history):
0df80be95e3604656ff36024f793ef3c36455051
4a07a3be11e7366b557bab795aa23b42725ec23e
f4bb42459ca4f3e18f9ee3d3a27389b85c7692e8
741d25cb6f8c0c1522cf6d1be2fea49356ecd4bd

#6 Updated by pespin 1 day ago

  • Assignee set to pespin

#7 Updated by keith about 17 hours ago

pespin wrote:

This ticket is a duplicate (talking about same issue) of #1525

Yes, I did not see #1525 when I made this. Feel free to close this one. (maybe move the description to a comment in the other ticket if you feel it's helpful in any way)

#8 Updated by pespin about 10 hours ago

According to some TTCN3 tests I'm doing, decode_gsm_ra_cap() is broken an returns an error, that's probably why it was commented out (probably they thought messages sent by SGSN were wrong, but actually decoding in PCU seems broken.).
I'm working on fixing it now.

#9 Updated by pespin about 10 hours ago

I just saw that csn1.cpp/csn1.hpp files are actually coming initially from wireshark. In current master, they are named:
epan/dissectors/packet-csn1.c
epan/dissectors/packet-csn1.h

I think it may make sense to try updating our code to match the one in wireshark instead of fixing this exact issue, because wireshark is decoding it fine.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)