The 'gprs_llc' is defined as a pure C structure with C++ specific
extensions (methods), so it's rather a class. Accessing its field
'frame' statically causes Clang to throw a compilation error:
gprs_bssgp_pcu.cpp:111:29: error: invalid use of non-static data member 'frame'
if (len > sizeof(gprs_llc::frame))
Let's avoid this and use LLC_MAX_LEN as the size limitation.
God knows what to expect from such a mix of C++ and C...
Change-Id: I7f84bd776cc780a45880f136107f6e0bc56241d1
This is rather a cosmetic change aimed to make ASAN / Coverity happy.
In general, we never pass any input from an untrusted source.
Change-Id: I26d654da4c3bf5fd86a298c3027fd9820c932308
It does not make sense since INT_MAX is always less than LONG_MAX.
Found by Clang [-Wtautological-constant-out-of-range-compare].
Change-Id: I9934e05aa050bf93b3c795376f5dca3a848a7e11
(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
Port of wireshark.git 8626bb4cbb4d9926f7b56663585d9ef66252f93f.
We don't really need the other fields added there, let's keep only the
value out of the union.
Change-Id: Ia8889252ee7518a919a15d749815c2803b4b23cd
Port of wireshark.git commit 6aca10831f86c562970b13efa811f46e25ee3091.
From Mike Morrin:
Fix pedantic compiler warnings in csn.1 dissectors.
There is some tricky casting going on in csn.1 structures. To eliminate all
the warnings, the function pointers needed to be moved out of the object
pointer unions. Fortunately macros (mostly) hide these changes from the
protocol dissector tables.
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7686
svn path=/trunk/; revision=44899
Change-Id: Ia1a8c50c4b024ca6df4e3fbbf891cd33591ccc9b
This is a port of wireshark.git commit
2f024256bf337400ef3a82fa75e6d48d5707e059.
From 78516187d821b8d19d16987b1d6bc855ee7cbe10 Mon Sep 17 00:00:00 2001
From: Sylvain Munaut <tnt@246tNt.com>
Date: Sat, 4 Feb 2012 10:00:22 +0100
Subject: [PATCH 4/6] packet-csn1: Allow CHOICE elements to re-process the bits used for the choice
We may want to display more detail, or the sub-element should be
displayed with its headers or whatever ...
Change-Id: I3a5a95d5f918b8f17a2400a6d0c4d855ecacea7e
Port of wireshark.git 2f024256bf337400ef3a82fa75e6d48d5707e059.
From c6ee558d3bb00bfd25cca7c534448bf60df3c7cf Mon Sep 17 00:00:00 2001
From: Sylvain Munaut <tnt@246tNt.com>
Date: Sat, 4 Feb 2012 10:24:01 +0100
Subject: [PATCH 6/6] packet-csn: Extend CSN_SERIALIZE to allow 0 bit of length
In some coding there is no 'length' field at the top of a serialized
block, or it's more complex than a single field, in which case we
have to rely on the serialize decoder to consume the correct number
of bits.
We extend the CSN_SERIALIZE processing so that if a '0 bit' length
field is specified, then the length is not displayed and the
consumed bits by the serialize function is taken as the length
at posteriori.
The processing keeps the same behavior for any length > 0.
Change-Id: I9fadc99218594447001f7bb9943f4514b9877799
So that they always occur next to an increment of bit_offset.
Port from wireshark.git 1c81971d4292438ffdf83e9f9b9ab96c133c785b.
Ported-by: Pau Espin Pedrol <pespin@sysmocom.de>
Change-Id: I7474e9d632e068d6e33b0a502b81d4fff1f48802
Port from iwireshark.git commit cc6d4341e65ef2e8d8488fe0ac0f236ece0dd844.
It looks like it makes no difference to us now, but other EGPRS messages
may use it in the future.
Ported-by: Pau Espin Pedrol <pespin@sysmocom.de>
Change-Id: I34039370c292e62790a38abb59f55c69fffa88e8
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
P-TMSI is optional IE, but IE is mandatory and hence always available.
Since the encoding is actually a Mobile Identity, the IMSI is used in
case P-TMSI is not available.
Change-Id: I4dbf8db04e81f98352a42ce34a5d91326be9bfd1
It's not really needed to have those together in some function calls,
and makes it more difficult to follow the code. Furthermore, new callers
not having content already aligned (len+value) will be using these
functions in forthcoming commits.
Change-Id: Ifb9d3997bfb74b35366c3d1bc51ce458f19abf16
Others projects don't contain a dash in there, and it seems to cause
problems with TTCN3 VTY expectations.
Change-Id: I3430abb5fc622dec293457466e760de95fa3a05c
Some are used to control (M)CS values for downlink while some do it for
uplink. Let's make clear which one is used for what. Take the chance to
document the fields a bit better than they were.
Some more information about the origin of cs_downgrade_threshold can be
found in the commit introducing it: 70b96aa232.
Related: OS#4286
Change-Id: I4e890e924b094a1937fbd3794de96704cf0421a8
So far there was a memory leak, because free()ing 'the_pcu.bctx'
would cause ASAN to complain. And that's reasonable, because it
needs to be freed properly. Moreover, 'the_pcu.bctx' may simply
be uninitialized in some cases, e.g. when OsmoPCU is terminated
before connecting to the SGSN.
Let's use the new bssgp_bvc_ctx_free() from libosmogb.
Change-Id: I274e79e1746c7678b81720ec11e8a564befe38ba
Depends: Ia78979379dbdccd6e4628c16f00d0c06d9212172
Both BSSGP SUSPEND ACK and NACK messages use BVCI=0 (signaling),
which always exists. Claiming that BVCI=0 is unknown is wrong.
Instead of adding both BSSGP_PDUT_SUSPEND_{ACK,NACK} to the 'if'
statement, let's rather avoid rejection for all BVCI=0 messages,
as there may be other unlisted message types.
Change-Id: I780657c1e8f67e0bef0e92a31db7ba61b57d7ec4
Related: OS#4111
Recent commit added an assertion to check for buffer boundaries and it
actually gets hit.
One of the 2 code paths calling pcu_l1if_tx_pch() was passing a buffer
of 23 bytes while one of maximum 22 is expected (because plen is not set
in the buffer but set inside pcu_l1if_tx_pch()).
So it seems before the assert, that code path was actually writing 1
byte outside the boundaries of data buffer, since bitvec_pack() uses
data_len field of bitvec.
Related: OS#4228
Fixes: 8dc09e73d0
Change-Id: I84c5dfd4d5580e9d4c00ed21887cb51bd9abbd2e