Let's do what's done for u8, which looks far more sane.
Fixes following gcc 11.2.0 warning:
"""
epan/dissectors/packet-csn1.c:913:17: warning: ‘ui16’ may be used uninitialized in this function [-Wmaybe-uninitialized]
913 | memcpy(pui16, &ui16, 2);
| ^~~~~~~~~~~~~~~~~~~~~~~
"""
All additional release fields in RadioAccesCapabilities are considered
optional, and the CSN_DESCR for Content_t already marks almost all as such,
except DownlinkDualCarrierCapability_r7.
It has been found that some MS transmits a MS RA Capability with a Length=61 bits
where the last bit in the buffer is setting the Exist bit for
DownlinkDualCarrierCapability_r7 as 1. Hence, the CSN1 decoder failed to
decode the whole message because it expected to keep reading there
despite there's no more bytes to read.
While this is could actually be considered an MS bug, let's relax our
expectancies and simply consider the case { 1 <end> } as it was { 0 },
and mark skip decoding DownlinkDualCarrierCapability_r7. That what
wireshark (packet-gsm_a_gsm.c) or pycrate do for instance.
This patch itself doesn't fix the problem where actually the Exist bit
is stored as 1 in the output decoded structure, but simply allows keep
ongoing with decoding until the end. This issue will be fixed in a
follow-up patch.
This patch is a port from patch fixing same issue in the osmo-pcu.git copy of
csn1 decoder:
https://git.osmocom.org/osmo-pcu/commit/?id=ebdc0d8c170ee2dbf23b19056d6c2d0ef316b3c2
Implement little endian support for tvb_get_bits family of functions.
The big/little endian refers to bit numbering within an octet. In big
endian, the most significant bit is considered bit 0, while in little
endian the least significant bit is considered bit 0.
Add encoding parameters to proto tree bits format family functions.
Specify ENC_BIG_ENDIAN in all dissectors using these functions except in
USB HID that requires ENC_LITTLE_ENDIAN to work correctly.
When formatting bits values, always display most significant bit on the
leftmost position regardless of the encoding. This results in no gaps
between octets and makes the displayed value comprehensible.
Close#4478Fix#17014
Some integer fields in CSN.1 structures can be encoded with an offset.
A good example is GPRS Mobile Allocation IE defined in 3GPP TS 44.060,
section 12.10a, table 12.10a.1:
< GPRS Mobile Allocation IE > ::=
< HSN : bit (6) >
{ 0 | 1 < RFL number list : < RFL number list struct > > }
{ 0 < MA_LENGTH : bit (6) >
< MA_BITMAP : bit (val(MA_LENGTH) + 1) >
| 1 { 0 | 1 < ARFCN index list : < ARFCN index list struct > > }
} ;
so in this case the variable-length MA_BITMAP is defined as follows:
< MA_BITMAP : bit (val(MA_LENGTH) + 1) >
what basically means that its bit length shall be encoded with
a negative offset 1, therefore the following statements apply:
MA_LENGTH=0 defines MA_BITMAP of bit length 1
MA_LENGTH=1 defines MA_BITMAP of bit length 2
...
MA_LENGTH=63 defines MA_BITMAP of bit length 64
== What's wrong? ==
For some reason, Wireshark shows the raw values without applying
the offset. Here is an example of GPRS Mobile Allocation IE:
GPRS_Mobile_Allocation
.... .101 010. .... = HSN: 42
...0 .... = RFL_NUMBER Exist: 0
.... 0... = Mobile Allocation: (Union)
u.MA
.... .001 111. .... = Bit length: 15
...0 .... = Bitmap: 0 // 1st
.... 1... = Bitmap: 1
.... .0.. = Bitmap: 0
.... ..1. = Bitmap: 1
.... ...0 = Bitmap: 0
1... .... = Bitmap: 1
.0.. .... = Bitmap: 0
..1. .... = Bitmap: 1 // 8th
...0 .... = Bitmap: 0
.... 1... = Bitmap: 1
.... .0.. = Bitmap: 0
.... ..1. = Bitmap: 1
.... ...0 = Bitmap: 0
1... .... = Bitmap: 1
.0.. .... = Bitmap: 0
..1. .... = Bitmap: 1 // 16th
== Solution ==
Let's use proto_tree_add_uint_bits_format_value(), so we can print
the final value with the offset applied, as well as the original
one and the offset itself:
GPRS_Mobile_Allocation
.... .101 010. .... = HSN: 42
...0 .... = RFL_NUMBER Exist: 0
.... 0... = Mobile Allocation: (Union)
u.MA
.... .001 111. .... = Bit length: 16 (Raw 15 + Offset 1)
Change-Id: Ic4eaf2d8a3c2fedca855726e4175ddf47d16c5af
Reviewed-on: https://code.wireshark.org/review/37931
Petri-Dish: Anders Broman <a.broman58@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
No need to decrement it every loop. Furthermore, when more types are
supported, same line can be reused.
Change-Id: Ic61c2e839d8dcb0e035172d706978a18b16520df
Reviewed-on: https://code.wireshark.org/review/36592
Reviewed-by: Pascal Quantin <pascal@wireshark.org>
The csnStreamDissector() shall not return 0 prematurely if no more
bits left in the input buffer. Otherwise some malformed packets
may not be displayed by Wireshark as such, confusing the user(s).
There are two possible cases:
a) The number of remaining bits is negative - this is an error
in any case. Return CSN_ERROR_NEED_MORE_BITS_TO_UNPACK.
b) The number of remaining bits is zero - this might be an error
or not depending on particular CSN.1 definition. We don't
know in advance without entering the parsing loop.
In case a) everything is simple, while in case b) we should not
make precipitate decicions. Some CSN.1 definitions have names
like 'M_*_OR_NULL', what basically means that they're optional
and can be ignored or omitted.
Most of the case statements do check whether the number of remaining
bits is enough to unpack a value, so let's leave the final decicion
up to the current handler (pointed by pDescr) if no more bits left.
This is a port of the original patch [1] for OsmoPCU [2].
[1] https://gerrit.osmocom.org/c/osmo-pcu/+/17394
[2] https://osmocom.org/projects/osmopcu/
Change-Id: If35d62b1cb81e8b2909401684c3b801cb79f1294
Reviewed-on: https://code.wireshark.org/review/36588
Reviewed-by: Pau Espin Pedrol <pespin@sysmocom.de>
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Gerald Combs <gerald@wireshark.org>
This way if CSN1 encoded bitstream contains more elements than what the
defintion expects it will fail instead of overflowing the decoded
buffer.
Example: RA Capabilities struct (recursive array) sent by a real android phone
when attaching to the network. Then SGSN sends it back and osmo-pcu would crash
similar to this:
*** stack smashing detected ***: terminated
Process terminating with default action of signal 6 (SIGABRT): dumping core
at 0x4C62CE5: raise (in /usr/lib/libc-2.31.so)
by 0x4C4C856: abort (in /usr/lib/libc-2.31.so)
by 0x4CA62AF: __libc_message (in /usr/lib/libc-2.31.so)
by 0x4D36069: __fortify_fail (in /usr/lib/libc-2.31.so)
by 0x4D36033: __stack_chk_fail (in /usr/lib/libc-2.31.so)
by 0x124706: testRAcap2(void*) (RLCMACTest.cpp:468)
Port from osmo-pcu.git efad80bfbffb2a35d2516e56dc40979f19c6c370
Related: https://osmocom.org/issues/4463
Change-Id: I6bdd6960141829491aebbfdaab548c41d4a3bc9f
Reviewed-on: https://code.wireshark.org/review/36572
Reviewed-by: Harald Welte <laforge@gnumonks.org>
Petri-Dish: Pascal Quantin <pascal@wireshark.org>
Tested-by: Petri Dish Buildbot
Reviewed-by: Pascal Quantin <pascal@wireshark.org>
Some CSN.1 definitions may contain so-called unions that usually
combine two or more choices. The exact element to be chosen is
determined by the value encoded in one or more bits preceeding
it. Here is an example of an identity union:
{ 0 < Global TFI : < Global TFI IE > >
| 10 < TLLI / G-RNTI : bit (32) >
| 110 < TQI : bit (16) > }
So if a given bitstream starts with '0'B, the Global TFI IE follows.
Otherwise either TLLI / G-RNTI or TQI is to be chosen. But what if
neither of the choice items matches? For example, what if a given
bitstream starts with '111'B?
Most likely we should treat the bitstream as malformed, stop further
decoding and report an error. And that's how Pycrate's [1] CSN.1
decoder [2] behaves. Hovewer, as it turns out, Wireshark would
simply skip the whole choice element and start decoding the next
one from the same bit position.
Here is an example of a malformed packet:
GSM RLC/MAC: PACKET_POLLING_REQUEST (4) (Downlink)
01.. .... = Payload Type (DL): RLC/MAC block contains an RLC/MAC control block
that does not include the optional octets of
the RLC/MAC control header (1)
..00 .... = RRBP: Reserved Block: (N+13) mod 2715648 (0)
.... 1... = S/P: RRBP field is valid
.... .001 = USF: 1
PACKET_POLLING_REQUEST (4) (downlink)
0001 00.. = MESSAGE_TYPE (DL): PACKET_POLLING_REQUEST (4)
.... ..11 = PAGE_MODE: Same as before (3)
---! ID <--- This is wrong! '111'B is unknown
1... .... = CONTROL_ACK_TYPE: PACKET CONTROL ACKNOWLEDGEMENT
message format shall be an RLC/MAC control block
Padding Bits
.110 0000 0000 1000 0101 0000 1000 1000 = Padding: 1611157640
0100 0000 0001 0011 1010 1000 0000 0100 = Padding: 1075030020
1000 1011 0010 1011 0010 1011 0010 1011 = Padding: 2334862123
0010 1011 0010 1011 0010 1011 0010 1011 = Padding: 724249387
0010 1011 0010 1011 0010 1011 0010 1011 = Padding: 724249387
0010 1011 = Padding: 43
Let's fix this, so after this patch we get:
GSM RLC/MAC: PACKET_POLLING_REQUEST (4) (Downlink)
01.. .... = Payload Type (DL): RLC/MAC block contains an RLC/MAC control block
that does not include the optional octets of
the RLC/MAC control header (1)
..00 .... = RRBP: Reserved Block: (N+13) mod 2715648 (0)
.... 1... = S/P: RRBP field is valid
.... .001 = USF: 1
PACKET_POLLING_REQUEST (4) (downlink)
0001 00.. = MESSAGE_TYPE (DL): PACKET_POLLING_REQUEST (4)
.... ..11 = PAGE_MODE: Same as before (3)
ID
STREAM NOT SUPPORTED (PacketPollingID)
[Expert Info (Warning/Protocol): STREAM NOT SUPPORTED (PacketPollingID)]
[STREAM NOT SUPPORTED (PacketPollingID)]
[Severity level: Warning]
[Group: Protocol]
[1] https://github.com/P1sec/pycrate
[2] https://github.com/P1sec/pycrate/wiki/Using-the-pycrate-csn1-translator-and-runtime
Change-Id: I7096c294e0d04d6afb3414874d3404cbb637fdae
Reviewed-on: https://code.wireshark.org/review/36077
Reviewed-by: Pau Espin Pedrol <pespin@sysmocom.de>
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Change all wireshark.org URLs to use https.
Fix some broken links while we're at it.
Change-Id: I161bf8eeca43b8027605acea666032da86f5ea1c
Reviewed-on: https://code.wireshark.org/review/34089
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Change-Id: I3dbb2a4f8f7ea125e4f96e302ea33ff03706eb1b
Reviewed-on: https://code.wireshark.org/review/15674
Reviewed-by: Michael Mann <mmann78@netscape.net>
Petri-Dish: Michael Mann <mmann78@netscape.net>
Reviewed-by: Pascal Quantin <pascal.quantin@gmail.com>
The intent here is to remove proto_tree_add_text from packet-csn1.c, but the macros setup means A LOT more hf fields needs to be created.
Many of those new hf fields were created with a perl script
Bug: 11504
Change-Id: If12c7677185f18a7f684fd3746397be92b56b36d
Reviewed-on: https://code.wireshark.org/review/10391
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
Specifically:
- Set packet.h to be the first wireshark #include after
config.h and "system" #includes.
packet.h added as an #include in some cases when missing.
- Remove some #includes included (directly/indirectly) in
packet.h. E.g., glib.h.
(Done only for those files including packet.h).
- As needed, move "system" #includes to be after config.h and
before wireshark #includes.
- Rework various #include file specifications for consistency.
- Misc.
Change-Id: Ifaa1a14b50b69fbad38ea4838a49dfe595c54c95
Reviewed-on: https://code.wireshark.org/review/5923
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Reviewed-by: Bill Meier <wmeier@newsguy.com>
Change-Id: I5f573dffabb8685a8e5a334ff2bfb24d9838daa6
Reviewed-on: https://code.wireshark.org/review/2601
Tested-by: Michael Mann <mmann78@netscape.net>
Reviewed-by: Michael Mann <mmann78@netscape.net>
(Using sed : sed -i '/^ \* \$Id\$/,+1 d')
Fix manually some typo (in export_object_dicom.c and crc16-plain.c)
Change-Id: I4c1ae68d1c4afeace8cb195b53c715cf9e1227a8
Reviewed-on: https://code.wireshark.org/review/497
Reviewed-by: Anders Broman <a.broman58@gmail.com>
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
Interface based on header type rather than MCS.
passes in the header type for EGPRS packets.
This makes sense because in a real protocol stack, the header type is encoded
in the burst stealing bits, allowing the header can be decoded, giving the CPS
IE, which then allows the data blocks to be decoded, so wireshark now follows
the same practice.
I found that there was a (previously overlooked) alignment error in decoding
the last octet of some headers due to the last "octet" having less than 8 bits,
and both the protocol stacks I have here assume that the left-hand bits are
missing (as per the figures in 44.060). I corrected this by making a small
extension to the NULL encoding in packet-csn.[ch] to allow a NULL field to
consume more than 0 bits.
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7615
svn path=/trunk/; revision=44805
Due to the variable remaining_bits_len getting out of sync with bit_offset (in
one case due to a mistake in the patch for bug 6375, and in another case
pre-existing).
I have shuffled the decrements of remaining_bits_len so that they always occur
next to an increment of bit_offset, so that this type of problem is easier to
spot.
From me: convert tabs to spaces to match the rest of the file.
svn path=/trunk/; revision=40662
Pau Espin
Gerald Combs
Vadim Yanitskiy