Bug #4958: NSVC still makred as ALIVE even minutes after peer is gone - osmo-gbproxy - Open Source Mobile Communications

Actions

Copy link

Bug #4958

closed

NSVC still makred as ALIVE even minutes after peer is gone

Added by laforge about 3 years ago. Updated about 3 years ago.

Status:

Resolved

Priority:

High

Assignee:

lynxis

Target version:

Start date:

01/19/2021

Due date:

% Done:

100%

Spec Reference:

Description

I start any TTCN3 testcase (like TC_BVC_bringup) and that test terminates.

Some minutes later I checkt the VTY output:

OsmoGbProxy> show ns nsei 101
NSEI 00101: UDP, DEAD
FSM Instance Name: 'GPRS-NS2-SNS-BSS(NSE00101-SNS)[0x6120000015a0]', ID: 'NSE00101-SNS'
 Log-Level: 'DEBUG', State: 'CONFIGURED'
Maximum number of remote  NS-VCs: 8, IPv4 Endpoints: 4, IPv6 Endpoints: 0
Local IPv4 Endpoints:
 127.0.0.1:23000, Signalling Weight: 2, Data Weight: 1
Remote IPv4 Endpoints:
 127.0.0.10:7777, Signalling Weight: 1, Data Weight: 0
 127.0.0.10:7770, Signalling Weight: 0, Data Weight: 1
 NSVCI none: ALIVE DYNAMIC data_weight=1 sig_weight=0 udp)[127.0.0.1]:23000<>[127.0.0.10]:7770
 NSVCI none: ALIVE DYNAMIC data_weight=0 sig_weight=1 udp)[127.0.0.1]:23000<>[127.0.0.10]:7777

As we can see, the NSE has gone to "DEAD", but magically its two NSVCs are still marked ALIVE at the bottom. This is fals. There's nothing that response to NS-ALIVE messages for several minutes already.

Actions

Copy link

Updated by laforge about 3 years ago

so the problem seems to be that we print the FSM state name, while "ALIVE" suggests to the user that this relates to the NSVC being ALIVE, i.e. able to carry traffic.

Do we change the FSM state name to "OPERATIONAL" or something else that doesn't already have a meaning?

Do we keep the name ALIVE but transition into a different state when we see Tnsalive/Tnstest timeouts?

Do we not print the FSM state anymore, but something else?

Actions

Copy link

Updated by lynxis about 3 years ago

Status changed from New to In Progress

Actions

Copy link

Updated by lynxis about 3 years ago

For block/reset we have the following state transitions:

Unconfigured -> Reset -> Blocked -> Unblocked.
The test procedure is started in the Blocked state.

For UDP

Unconfigured -> Alive -> Unblocked.
The test procedure is started in Unblocked state. Because Alive is doing the test procedure to know if the link is really alive.

I could rename the Alive into Test. We should add another flag to `show ns` which show the dead or alive state of the NSVC.

Actions

Copy link

Updated by laforge about 3 years ago

Related we are constantely getting ERROR messages as we attempt ALIVE->ALIVE state transitions in the NS-VC FSM:

Tue Jan 19 18:05:57 2021 DLNS fsm.c:322 GPRS-NS2-VC(UDP-NSE00101-remote-127_0_0_10:7777)[0x6120000036a0]{ALIVE}: Timeout of T0
Tue Jan 19 18:05:57 2021 DLNS gprs_ns2_vc_fsm.c:460 GPRS-NS2-VC(UDP-NSE00101-remote-127_0_0_10:7777)[0x6120000036a0]{ALIVE}: transition to state ALIVE not permitted!

Actions

Copy link

Updated by laforge about 3 years ago

lynxis wrote:

I could rename the Alive into Test. We should add another flag to `show ns` which show the dead or alive state of the NSVC.

I think "RECOVERY" or "RECOVERING" might be the most easy understandable word for this situation. "ALIVE" can mean the link is alive, but it also relates to Tns-alive, the alive procedure, ... and Test likewise may be confusing.

Actions

Copy link