Bug #2384
closedNSVCI=0 seems to cause problems
100%
Description
If I configure NSVCI=0 in omso-bsc.cfg for a given BTS, OsmoPCU will behave eratically in terms of the NS protocol layer towards the SGSN.
Basically, OsmoPCU will at some point decide the NS-VC is no longer alive and refuse NS_ALIVE messages from the SGSN with "NS_STATUS, Cause: PDU not compatible with protocol state"
Related issues
Updated by laforge over 6 years ago
the problem is not 100% reproducible. In som cases, OsmoPCU will send FLOW-CONTROL PDUs every second, in which time the NS-VC stays alive. Only if there are no NS-PDUs exchanged for 60 seconds, OsmoPCU will start rejecting the NS_ALIVE PDU.
So something must be inhibiting the generation of NS_ALIVE in PCU-SGSN direction, as well as inhibiting the FLOW-CONTROL.
Interestingly, "show ns" on the PCU will show
Osmo-PCU# show ns Encapsulation NS-UDP-IP Local IP: 0.0.0.0, UDP Port: 21000 Encapsulation NS-FR-GRE-IP Local IP: 0.0.0.0 NSEI 96, NS-VC 0, Remote: SGSN, ALIVE UNBLOCKED, UDP 172.31.0.1:23000
Updated by laforge over 6 years ago
- Priority changed from Normal to Low
this might have been a "false flag" as two SGSNs were sending UDP packets to the PCU simultaneously. This in turn makes me wonder why we would accept UDP packts from a source address that doesn't equal the IP/port specified in the NSVC configuration.
Updated by laforge over 6 years ago
- Related to Bug #2401: OsmoPCU accepts UDP packets from any source added
Updated by fixeria over 4 years ago
- Related to Bug #4111: BSSGP SUSPEND ACK with unknown BVCI=0 added
Updated by lynxis over 2 years ago
- Status changed from New to Closed
- Assignee changed from laforge to lynxis
- % Done changed from 0 to 100
I would guess it's not anymore a problem. The new implementation checks the UDP source of the packets and NSVCI.
The new code doesn't care if nsvci == 0 or > 0.
I'm closing this for now since it's quite old and needs to be checked again.
