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
Current stderr output is empty anyway, and not checking it allows
enavling different log levels to easily debug issues.
Change-Id: I5b12e919e08a6eeaad31a459e5a15fdee4d76a61
Old method takes lots of lines of codes and prints inn unconfortable way
because left-trailing zeros are dropped, making it difficult to split in
bytes.
Change-Id: I56c24f934824e4e52a91a7273aec384b2e15aa67
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
Since there can be multiple PDCH channels configured on different
timeslots, different TRXes, and BTSes, the PTCCH/U handling code
in OsmoPCU needs to know the exact origin of a given RACH.ind.
Otherwise, it is not known which subscriber originated a given
PTCCH/U indication, and hence it is impossible to send PTCCH/D
Timing Advance notification properly.
Fortunately, we can extend the RACH.ind message without even
bumping the protocol version, because every single PDU has a
fixed size defined by the largest message - INFO.ind. In case
if the actual message payload is smaller, the rest is filled
with a constant padding byte (0x00).
Older versions of OsmoPCU will consider the new fields as padding,
while the messages from older OsmoBTS versions will always have
both fields set to 0x00. Since C0/TS0 cannot be configured to
PDCH, this can be easily detected on the other end.
Change-Id: If209001885ffb14b64a8e808df3700d85a4b2ef9
Related: OS#1545
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
Share a single instance of 'pcu_l1_meas' between all unit tests,
set initial measurement values in main(). This way we can get
rid of the following warnings:
Unable to update UL (M)CS CS-X because we don't have link quality measurements.
Change-Id: I1c82076df6cd0833d243e1e6afb140bae3bd2ec9
Fixes: OS#3828
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
For a long time the VTY command to show all active TBFs was broken.
The TBF filtering (by allocation origin) logic allows one to show
TBFs allocated on CCCH, PACCH, or on both of them. In the latter
case we have been checking whether a TBF was allocated on both
logical channels at the same time.
Let's fix this by passing a flag-mask instead of boolean arguments.
To be able to use GPRS_RLCMAC_FLAG_* definitions from "tbf.h", let's
exclude them from "#ifdef __cplusplus ... #endif" block.
Change-Id: I1c9f401368af880a97d32905c4cce0da481ffc21
Anders Broman
Pau Espin
Harald Welte