commit | 93ad3fd9b9aed26a609551c06a80db0e276eb4f1 | [log] [tgz] |
---|---|---|
author | Vadim Yanitskiy <vyanitskiy@sysmocom.de> | Sat May 23 18:17:19 2020 +0700 |
committer | Vadim Yanitskiy <vyanitskiy@sysmocom.de> | Sat May 23 19:26:58 2020 +0700 |
tree | 10e66f12cd5093a32bc407d6be510b08f8af8b0a | |
parent | 0614e9333fb5072640ba9939a28ffc1588cfe5bd [diff] |
csn1: fix: never use enumerated types in codec structures I faced a problem while working on EGPRS Packet Channel Request coding support: the unit test I wrote for it was passing when compiled with AddressSanitizer, but failing when compiled without it o_O. Somehow this was observed only with GCC 10. Here is a part the standard output diff for that unit test: *** testEGPRSPktChReq *** decode_egprs_pkt_ch_req(0x2b5) returns 0 - ==> One Phase Access + ==> unknown 0xdd5f4e00 decode_egprs_pkt_ch_req(0x14a) returns 0 - ==> One Phase Access + ==> unknown 0xdd5f4e00 decode_egprs_pkt_ch_req(0x428) returns 0 - ==> Short Access + ==> unknown 0xdd5f4e01 At the same time, debug output of the CSN.1 decoder looked fine. So WYSINWYG (What You See Is *NOT* What You Get)! As it turned out, this was happening because I used an enumerated type to represent the sub-type of EGPRS Packet Channel Request. typedef struct { EGPRS_PacketChannelRequestType_t Type; // <-- enum EGPRS_PacketChannelRequestContent_t Content; } EGPRS_PacketChannelRequest_t; The problem is that length of an enumerated field, more precisely the amount of bytes it takes in the memory, is compiler/machine dependent. While the CSN.1 decoder assumes that the field holding sequential number of the chosen element is one octet long, so its address is getting casted to (guint8 *) and the value is written to the first MSB. // csnStreamDecoder(), case CSN_CHOICE: pui8 = pui8DATA(data, pDescr->offset); *pui8 = i; // [ --> xx .. .. .. ] Let's make sure that none of the existing RLC/MAC definitions is using enumerated types, and add a warning comment to CSN_CHOICE. Affected CSN.1 definitions (unit test output adjusted): - Additional_access_technologies_struct_t, - Channel_Request_Description_t. Change-Id: I917a40647480c6f6f3b0e68674ce9894379a9e7f
This repository contains a C/C++-language implementation of a GPRS Packet Control Unit, as specified by ETSI/3GPP. It is part of the Osmocom Open Source Mobile Communications project.
The Packet Control Unit is terminating the Layer 2 (RLC/MAC) of the GPRS radio interface and adapting it to the Gb Interface (BSSGP+NS Protocol) towards the SGSN.
The PCU interfaces with the physical layer of the radio interface. OsmoPCU is typically used co-located with the BTS, specifically OsmoBTS. For legacy BTSs that run proprietary sotware without an interface to OsmoPCU, you may also co-locate it with the BSC, specifically OsmoBSC
The official homepage of the project is https://osmocom.org/projects/osmopcu/wiki/OsmoPCU
You can clone from the official osmo-pcu.git repository using
git clone git://git.osmocom.org/osmo-pcu.git
There is a cgit interface at http://git.osmocom.org/osmo-pcu/
We provide a user manual as well as a vty reference manual
Please note that a lot of the PCU configuration actually happens inside the BSC, which passes this configuration via A-bis OML to the BTS, which then in turn passes it via the PCU socket into OsmoPCU.
Discussions related to osmo-pcu are happening on the osmocom-net-gprs@lists.osmocom.org mailing list, please see https://lists.osmocom.org/mailman/listinfo/osmocom-net-gprs for subscription options and the list archive.
Please observe the Osmocom Mailing List Rules when posting.
Our coding standards are described at https://osmocom.org/projects/cellular-infrastructure/wiki/Coding_standards
We us a gerrit based patch submission/review process for managing contributions. Please see https://osmocom.org/projects/cellular-infrastructure/wiki/Gerrit for more details
The current patch queue for osmo-pcu can be seen at https://gerrit.osmocom.org/#/q/project:osmo-pcu+status:open