According to 3GPP TS 44.004, section 7.4a, two alternative RACH block
formats are specified: 8 bit (1 octet) and 11 bit. This change adds
CSN.1 definitions for 11 bit EGPRS Packet Channel Request as per
3GPP TS 44.060, table 11.2.5a.2.
Change-Id: I96df3352856933c9140177b2801a2c71f4134183
Related: OS#1548
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
Port from wireshark.git 428ee66ae1c524b49f9043729b1f1e9b4f52f409, from
Pascal Quantin.
The original commit is also changing the RRC_Container field to
M_CALLBACK, but we leave them as M_VAR_ARRAY since the callback is
basically used to add more dissection information in wireshark.
Change-Id: I0f374e78300efddff00c4df26a401adcdee18a12
Original file from wireshark.git (packet-gsm_csn1.c) is being built and
maintained as a C file. There's no real need for us to maintain it as a
C++, and doing so will make both files derive over time (as already
happened). Let's keep it as a C compiler (which btw seems to be more
strict) to make it easier to port patches back and forth wireshark.git.
Take the chance to move some declarations we added to csn1.h to be able
to build it out of wireshark. Let's keep those in a separate header file
to ease looking for differences.
Change-Id: I818a8ae947f002d35142f9f5473454cfd80e1830
There's two variants for the Ms Radio Access Capabilities.
* The usual encoding with spare bits (usually to fill up to octet boundary)
as defined in TS 24.008 Table 10.5.146
And there's too:
* MS Radio Access Capabilities 2 IE from TS44.060 section 12.30, which is
the same but removing all spare bits, and which is used in messages like
Packet Resource Request and Additional MS RAC messages.
The later is used basically for messages having extra IEs after the MS
Radio Access capabilities IE, since they are encoded immediatelly
afterwards.
So this patch does:
* Adds the expected spare bits (M_PADDING) to MS_Radio_Access_capability_t
* Creates a new MS_Radio_Access_capability2_t without padding
* Updates code to use the new "2" version where needed.
Note RLCMACTest long de/encoding line logs change only because the name
of the struct changes (the "2" is added).
Change-Id: Ibd756f80a03452a651e2771dbc628d701e55ac4b
It seems the assumptions regarding maximum number of RA capabilitites
in one message were wrong. Doing some rough calculations, each RA
capabilitiy value (without extensions) can take around 20ish bits, which
means for a message containing up to 52 bytes that quite a lot of
different values could be theoretically fed in. Let's be safe and
increase the array size to be able to handle all different access
technologies listed in See TS 24.008 table 10.5.146 following
restrictions:
* "The MS Radio Access capability is a type 4 information element, with a maximum length of 52 octets."
* "Among the three Access Type Technologies GSM 900-P, GSM 900-E and GSM 900-R only one shall be present."
* "the mobile station should provide the relevant radio access
capability for either GSM 1800 band OR GSM 1900 band, not both".
Wireshark requires similar fix (it's not important though because it
currently uses another ad-hoc decoder for RAcap).
Related: OS#4463
Change-Id: I5334eaacfbc238fae8bea50c9e9667c2117f81ff
Port from wireshark.git de028e81c53f9c45ccc5adb3bffd2f16ae2017bf
This commit breaks transcoding of the test vectors containing
the MS RA Capability IE due to the reasons explained in [1].
The more fields we add, the longer gets the output of the CSN.1
encoder. This is not critical, since we never need to encode
messages containing the MS RA Capability IE on practice.
[1] Ibb4cbd3f5865415fd547e95fc24ff31df1aed4c0
Ported-by: Pau Espin Pedrol <pespin@sysmocom.de>
Change-Id: Ibb4cbd3f5865415fd547e95fc24ff31df1aed4c0
The implementation of CSN.1 codec was taken from Wireshark, where
it's implemented in pure C. For some reason it was mixed with C++
specific features, mostly using references in parameter
declaration. Not sure what are the benefits.
Change-Id: I56d8b7fbd2f9f4e0bdd6b09d0366fe7eb7aa327a
(as they are part of the RlcMacUplink_t structure that is also used to call csnStreamDissector function).
Port from wireshark.git commit 9f8b638cfa8a660fb64c54dcadb83e6747db0a15.
Ported-by: Pau Espin Pedrol <pespin@sysmocom.de>
Change-Id: If46f8cc3f21f527f911dcac6ff1b78f182104a00
Currently code using that function in osmo-pcu is disabled, allegadly
because SGSN was sending incorrect values, but it looks more like a CSN1
issue.
Related: OS#1525, OS#3499
Change-Id: I92c86397f988afaa791871d823a45fa85054f3bb
Having explicit include above the douible-include guard defines is
potential source for hard to track bugs. Let's move it inside the guard
statement.
Change-Id: I5114a63ce00b03c8eed23565d52969250bd505cc
Related: OS#1539
The presence of the LENGTH field adds an additional offset which
breaks the related M_SERIALIZE in gsm_rlcmac.cpp. In that case,
the Desc in EGPRS_AckNack_t is being cast to EGPRS_AckNack_w_len_t
and then ((EGPRS_AckNack_w_len_t *)Desc)->Desc is filled with the
parsed data, which is a platform dependant number of bytes apart the
real Desc struct.
Remove LENGTH field from EGPRS_AckNack_w_len_t so that the Desc field
is the first field.
Note that this is not a real fix. The rlcmac wireshark dissector
still has the same declaration but doesn't seem to suffer from this
problem.
Sponsored-by: On-Waves ehf
Generic improvements to the csn.1 dissector include:
• Added a flag to the type descriptor structure so that any type can (potentially) flagged as xxx_OR_NULL. This was specifically needed for UINT_OR_NULL for the ms capabilities struct.
• Changed the CSN_SERIALIZE so that the length of the length field can be specified.
• For CSN_NEXT_EXIST removed the requirement that the next type be CSN_END, to allow truncation of multiple IEs.
• For CSN_LEFT_ALIGNED_VAR_BITMAP corrected the handling of bit_offset.
• Added a new type CSN_PADDING_BITS to make inspection of padding bits more convenient.
• Improved the CSN_RECURSIVE_TARRAY_1 to show the array index.
Improvements to the gsm_rlcmac dissector include:
• Rework the definition of EGPRS Ack/Nack Description so that the length IE (and absence thereof) is handled correctly.
• Added Padding Bits definitions to all PDUs
• Change the Multislot_capability_t and Content_t definitions to allow truncation at any IE
Vadim Yanitskiy
Pau Espin
Vincent Helfre
Harald Welte