This commit used a send template (ts) to match a received BSSGP PDU which
doesn't work due to some differences in the length field.
Use tr_BSSGP_IMSI again and change the template restrictions so it
compiles.
Fixes: 6ee0126971
Change-Id: I85676e96f8d32a9d2c7deadc1d66707b6b8697d0
Fixes warning:
Osmocom_Gb_Types.ttcn:1377.13-32: warning: Inadequate restriction on the
referenced function `f_oct_or_wc(bmax, 2)', this may cause a dynamic test
case error at runtime
Change-Id: Icb8698c7f2ca697a3638d5a4e4e38f20e14fd34c
The TC_rim tests do not use the RIM templates from Osmocom_Gb_Types as
intended.
Change-Id: Ie484f288aa0515ef4df4a3cf7f8a347a3f3cf587
Related: SYS#5103
When testing the serving BSS part of the RIM application in osmo-pcu, we
will need receiving templates that allow us to verify the response (RAN
INFORMATION) rim container.
Change-Id: I964d7504f3c4aeaa4ce537316b3140e8b893003d
Related: SYS#5103
* allow configuration of signalling + data weight for each NS-VC
* advertise per-NSVC signalling/data weight in SNS-CONFIG
* keep track of unblocked NS-VCS separately for data / signalling
* transmit BVCI=0 traffic only over signalling NS-VC
* transmit BVCI>0 traffic only over data NS-VC
* accept incoming BVCI=0 traffic only if signalling_weight > 0
* accept incoming BVCI>0 traffic only if data_weight > 0
Related: OS#4953
Change-Id: I9798e639b4bc8658482945970775b012b5840779
We need to move the IP-SNS handling up one layer, as only the NS-VCG
knows all the other NS-VCs, and after the SNS-CONFIG-ACK, we must
mark all of our NS-VCs as alive and start the alive procedure.
Related: OS#4953
Change-Id: Ie0f4342a0346952d7c50ac36900148e311d4c782
We expect the uplink BSSGP status to be routed based in the
inner/contained downlink PDU - and vice-versa.
Change-Id: If2ddd158346a3da340f1c673354196f3872c4f67
Related: OS#4951
RADIO-STATUS can occur with TLLI, but also with P-TMSI or IMSI.
Update our templates accordingly while keeping backwards compatibility.
Related: OS#4951
Change-Id: I1119e50e457b02d52e7c2c26a8b8039bf2118296
We used to generate a random TLLI for each ConnHldr. Instead, use a
deterministic function to generate the P-TMSI (just like we do for the
IMSI) and derive a local TLLI from that P-TMSI.
Related: OS#4472, SYS#5002
Change-Id: Ic1eaa1d298fe998ca97432769953bfc5a5333ae4
The template set we use for testing the GB (BSSGB) interface on
osmo-sgsn and osmo-pcu lacks templates to generate RIM (ran information
management) messages. The records and unions are already specified in
BSSGP_Types.ttcn, we just need to form templates in order to be able to
use them.
Change-Id: Ic495e0bb6ceb2b65cbc7c3da7ee519a013aede55
Related: SYS#5103
When the SGSN is sending an OVERLOAD message, we expect that to
propagate down to every BSS on the other side.
Change-Id: Ic61fabd9c633bcb3f256fe7aa5834e66cc66a4fb
This tests the LLC-DISCARDED message, which relates to a BVCI but
is itself sent on BVCI=0. We expect it transparently passes from BSS
to SGSN.
Change-Id: I98d02d6fa68bddf15b732d06dab00e91e72995d1
Those functions don't depend on any L3 specific data structurs, and
it is not a good idea to burden every user with having to impot all
of a 2G/3G Layer3 just to generate some hexstring identifiers.
Change-Id: I6fc41ed94e97e0ec44dc4ea56d110bdd9ac77a72
With PCUIF 10 the remote can be IPv4 or IPv6.
Add all missing parts including SNS IPv6 elements,
the support to omit IPv4 elements and a PCU_Tests_SNSv6.cfg
configuration to run all tests with IPv6
Change-Id: I43d64caca600fff78f3fbbb3e8179f447f235d46
Those can help to match if messages meet certain constraints stipulated
in the BSSGP specification.
Change-Id: I05c768f5a9e4f0b5c1375c2603135a349c38e849
The existing BSSGP_Emulation is built around the assumption that every
instance of BSSGP_Emulation only servers one signaling-BVC and one
PTP-BVC. While this is true for osmo-pcu at this point (BTS-colocated
PCU), other BSS/PCU implementations differ.
In general, there can always be any number of PTP BVC (one per cell)
next to the signaling BVC (one per BSS). Let's represent this in
BSSGP_Emulation so we can create more comprehensive tests.
Change-Id: I7e30b4c4e188518a574e082962fba457b3a97ce3
This in turn means Osmocom_Gb_Types doesn't need to depend on
GSM_RR_Types anymore, which is particularly ugly as the latter
now depends on RLCMAC_*, creating a long chain of dependencies.
Change-Id: I8c8da7709695ff0023f71b3999291e2515b22e46
osmo-pcu.git 0052051c07af63da98137c9f8e3b3119642eb587 introduced a bug
(fixed in 1d68cdff928f32941aff36c70e4543203c283d15) where no MS could
GMM attach to the network, but no test showed the issue.
This couple test verifies both correct behavior and also ensures wrong
IMSI is detected and reported.
Related: OS#4729
Change-Id: I5072d80b7ed9945a6083cdf3254efb8b8f119c54
This additional couple of test cases reveals several bugs:
1) the IUT encodes a erroneous RR Paging Request message
containing P-TMSI, so TITAN fails to decode it;
2) the IUT prints an invalid P-TMSI in its log output
due to load of misaligned address (found by UBSan).
[1] I97fd5ffc15a4a58112d7c37c69b7ac42b0741a0e
[2] Icf8836f216793e342b239c8e6645aac1e82bf324
Change-Id: I7fbec5b2c5c3943a7413417b623f55c135c152d7
PCU is using BcdMccMnc as it's encoded as 24.008.
But SGSN code is using it as it would be byte by byte
sorted.
Fixes: OS#3878
Change-Id: Ie8f67f16f18e4c5090bc5a4c46a866a7e7e00206
Alexander Couzens
Daniel Willmann
Philipp Maier
Harald Welte
Pau Espin