tcap routing doesn't work the way the test thinks. E.g. a Begin can't be routed to a special destination because it does't contain a dtid which is needed to route to the correct ASP.
STP_Tests_TCAP: Test routing of fragments in TC_tcap_loadshare_ipa_tcap_range_success_pc
A TCAP Begin will cause the stp to create a cache entry and route according to that. Send only a TCAP Continue so we check the tcap range routing logic.
Verdict: fail reason: Odd TDMA frame number := 935
There's no requirement that periodic interference reports must land on a TDMA frame number satisfying 'fn mod 104 == 0' - only that they keep arriving every configured averaging period. Instead, verify that the interval between consecutive reports equals 104 TDMA frames (1 SACCH period), using the new f_gsm_fn_sub() helper.
Revert "bts: limit stderr logging to ERROR to avoid long write() to ext4 fs"
This reverts commit 3c798765f04dd7428c76e3c5cbf3f2ee27a0af4d.
Reducing logging verbosity did not help: we're still seeing the clock skew errors and restarts. This makes debugging harder, and is not relevant anymore because we've switched to tmpfs [1].
Revert "bts: limit stderr logging to NOTICE to avoid long write() to ext4 fs"
This reverts commit c3ab9ec33f37c6837fb8bcb0fa0bbd2e98781fb7.
Reducing logging verbosity did not help: we're still seeing the clock skew errors and restarts. This makes debugging harder, and is not relevant anymore because we've switched to tmpfs [1].
If a TCAP message arrives which is: * not a TCAP Begin or Abort (e.g. a TCAP Continue) * not in the TCAP session cache/tracking * not have a dTID for a registered TCAP Add Range
The tcap load-share will reject this message with a UDTS
CCID: Check if reader handles special P3 value 0x00 correctly
If data is requested from SIM with P3 set 0x00, it means that 256 bytes are requested. The reader will receive a procedure byte, which must cause it to receive all 256 data bytes + two status words.
CCID: Check if reader restarts WWT upon NULL procedure byte
The reader will receive a NULL procedure byte every 0.2 for a long time. The reader may only respond with a status that time extension was requested. At the end the SIM proceeds with a valid response. This response must be returned by the reader.
CCID: Check if reader sends request TPDU with maximum size
The maximum size of a request TPDU can have 5 bytes header and 255 bytes data. It is expected that the reader transmits all bytes to SIM without failure.
CCID: Check response of reader with empty SIM carrier
The reader has a SIM carrier inserted, but there is no response from the SIM while expecting the ATR. The reader will get a timeout and is expected to respond with a suitable error code.
The test uses the slot with the SIMtrace inserted. The SIMtrace will not respond with an ATR. This way there is no (extra) empty slot required for this test.
CCID: Check if reader times out while expecting status words
A case 1 APDU is sent toward the reader. The reader expects two status words. If none of these are sent by the SIM the reader must timeout and send an error message back to the host.
BSSAP(_LE)/RANAP: Proper counting of RESET retries
N retries means N+1 attempts.
Since M3UA_Emulation (in deps/, not in library) doesn't support pushing DUNA/DAVA as primitive up the stack, we cannot implement the related SCCP primitives which should end up sending in turn other primitives to our BSSAP(_LE)/RANAP emulations. This means we currently have no way to figure out the status of the underlying SCCP/MTP link, and our only way is implement a poor man's solution: retransmit RESET until we get an answer.
Since before bssap_reset_retries was set to 1 everywhere and we were only attempting once, it could happen that the other end (the IUT) was not yet connected to the STP when we send the RESET, and hence it is discarded the STP. In that scenario, we'd time out and fail the test. Instead, now that we do N+1 attempts, we retry after 5 seconds, which should be enough time for the peer to reconnect to the STP.
