enbility / ship-go / 35354868886

93%

Build Type

push

github

Committed by web-flow

Commit Message

fix(ship): increase the Wait-For-Ready-Timer on a prolongation request (TC_SHIP_HELLO_002) (#122)

Fixes #121.

## The problem

SHIP 13.4.4.1.3 has an accepted prolongation request **increase** the
Wait-For-Ready-Timer
by T_hello_inc, which is the same value as T_hello_init, and every SME
"hello" update
announce the timer's current value:

> If an SME User accepts the prolongation request: It SHALL increase its
> Wait-For-Ready-Timer by T_hello_inc.
>
> Sub-element "waiting" set to the current value of Wait-For-Ready-Timer
if
> Wait-For-Ready-Timer is active.

In state READY, `handshakeHello_ReadyListen` restarted the timer at
T_hello_init instead,
which loses the time that was left, and always announced
`waiting=60000`. `tHelloInc` was
defined but never used.

TC_SHIP_HELLO_002 sends the first prolongation request after 45 seconds
and then waits
60 seconds per round. A DUT that increases its 60-second timer has 15 s
left
(T_hello_prolong_waiting_gap) at the end of every round. ship-go had
none left: it
restarted its timer just before sending the reply, while the test tool
starts its wait
only after receiving that reply, so the abort landed at the very end of
step 3.2. An
independent tester reported the test case failing:

```
  0.000s  <--  {"connectionHello":{"phase":"ready","waiting":60000}}
 45.020s  -->  {"connectionHello":{"phase":"pending","prolongationRequest":true}}
 45.021s  <--  {"connectionHello":{"phase":"ready","waiting":60000}}
105.022s  <--  {"connectionHello":{"phase":"aborted"}}
```

## What changed

**The handshake timer knows when it expires.** `setHandshakeTimer`
records the deadline,
and `handshakeTimerRemaining` reports the time left on a running timer
of a given type.

**An accepted request increases the timer.** `extendHandshakeTimer` adds
to the running
timer by stopping and rescheduling it under `handshakeTimerMux`.
Incoming messages and a
timer expiry can both run `handleState` at the same time, so the timer
must not be abl... (continued)

Coverage Stats

38 of 42 new or added lines in 3 files covered. (90.48%)

2 existing lines in 1 file now uncovered.

6066 of 6517 relevant lines covered (93.08%)

11845.99 hits per line