| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
It seems that for some reason the asn2wrs.py code generator cannot deal
with ASN.1 choices being defined with their numeric values defined in
non-ascending order. Other ASN.1 code genreation tools work perfectly
fine under such conditions.
The decode error happens in the COL_INFO: The numeric value of the
choice is mapped to a wrong entry in the string table, resulting in
the wrong message type being shown in the INFO column.
We apply this patch to the ASN.1 source of the RSPRO protocol definition
to fix the decode.
|
|
The Osmocom RSPRO protocol is a protocol for remote SIM card access,
i.e. extending the SIM card interface between phone/mdoem (UE) and
a remote SIM card reader. The primary user of this protocol is
osmo-remsim software suite, which can be found at
https://osmocom.org/projects/osmo-remsim/wiki
RSPRO is specified in ASN.1 using BER and runs on top of the IPA
multiplex (protocol-gsm_ipa.c).
Change-Id: Ibcdb2c92281d05c36e3973de4d7ec4aa0cd9b207
|
|
This is mean to use the value to select the correct field length.
Fix Coverity CID 1517107, 1517124, 1517136, 1517164, 1517184, 1517195.
|
|
Some of the item length changes in !9655 needed to be done with
the ASN.1 templates so that they don't get lost on ASN.1 regeneration.
Fixup ed8ee831fda2df69657af95dc34a3ea6b3ef4c88
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
A few HS-DSCH conversations are created when calling add_hsdsch_bind,
such as when a RadioLinkReconfigurationPrepare procedure has
a id-HSDSCH-MACdFlows-to-Add element. This method should add
the CommunicationContextID to the conversation just like the
other ways of creating the conversation. This provides a UEID
for a unique key for RLC reassembly.
|
|
Clear the object_identifier_id global at the beginning of
each QCStatement, in case the statementId BER has errors and
does not put a value in the ptr. (call_ber_oid_callback correctly
handles being passed a NULL.)
Fix #18552.
|
|
|
|
This parameter was introduced as a safeguard for bugs
that generate an unbounded string but its utility for
that purpose is doubtful and the way it is being used
creates problems with invalid truncation of UTF-8
strings.
Rename wmem_strbuf_sized_new() with a better name.
|
|
To debug with line directive build with -DENABLE_DEBUG_A2W=ON flag
|
|
It was reverted by mistake in g47a1b0f9
|
|
|
|
Instead of using tvb_get_bits and proto_tree_add_uint,
use a bitmask in the field info and proto_tree_add_item.
This means that when epan/print.c writes PDML or JSON,
the value written is the correctly masked value (PDML also
includes the unmasked value.)
When proto_tree_add_uint is used, the value written to
PDML and JSON is the original value from the packet buffer,
not properly shifted.
|
|
Using a bitmask in the field definition allows us to use
proto_tree_add_item, which means that when print.c writes
PDML and JSON, the value written is the correctly masked
value (PDML also includes the unmasked value.)
When functions like proto_tree_add_uint are used instead,
the value written to PDML and JSON is the original value
from the packet buffer, not properly shifted.
|
|
Instead of using tvb_get_bits32 and proto_tree_add_uint,
use a bitmask in the field info and proto_tree_add_item.
This means that when epan/print.c writes PDML or JSON,
the value written is the correctly masked value (PDML also
includes the unmasked value.)
When proto_tree_add_uint is used, the value written to
PDML and JSON is the original value from the packet buffer,
not properly shifted.
|
|
Fixes #18652.
|
|
|
|
Use a wmem_strbuf_t to avoid a truncation in the middle of a
multibyte character with a fixed length buffer.
Fixes #18543.
|
|
In their infinite wisdom, 3GPP succeeded to make non backward compatible
ASN.1 description
Closes #18646
|
|
|
|
|
|
Let's add it as a hidden filter for IEEE 754 single precision floating point
Closes #18491
|
|
|
|
|
|
|
|
The minimum and maximum length arguments to
dissect_per_constrained_set_of() are currently both ints.
According to O-RAN.WG3.E2AP-v02.03, section 9.3.7 "Constant
definitions", maxofRICrequestID is 1024, not 2^32-1; however, we were
specifying it as 2^32-1 (4294967295).
2^32-1 won't fit into an int, and Apple clang version 14.0.0
(clang-1400.0.29.102) warns about that:
./asn1/e2ap/e2ap.cnf:647:54: error: implicit conversion from 'long' to 'int' changes value from 4294967295 to -1 [-Werror,-Wconstant-conversion]
1, maxofRICrequestID, FALSE);
^~~~~~~~~~~~~~~~~
./asn1/e2ap/packet-e2ap-val.h:7:40: note: expanded from macro 'maxofRICrequestID'
#define maxofRICrequestID 4294967295
^~~~~~~~~~
The handling of MIN and MAX should be done with separate "minimum is
MIN" and "maximum is MAX" flags, and we might want either to have
asn2wrs.py reject attempts to have constraints with integer minimum and
maximum values outside the range [-2^31, 2^31-1], make the types for
sizes unsigned, or allow 64-bit constraints (and still limit the
constraint values, so we don't have to dive down a bignum rathole).
But, for now, we just change maxofRICrequestID to match what the 2022-10
version of the spec, 2.03, appears to say.
(I can't find the 2.01 version online, so I don't know whether it was
1024 in 2.01, or if it was changed in 2.02 or 2.03.)
|
|
|
|
|
|
Closes #18485
|
|
Add the missing dot in H.248 protocol name and dissector table.
Closes #18513
|
|
|
