Bug #2384
closed
NSVCI=0 seems to cause problems
Added by laforge over 6 years ago.
Updated over 2 years ago.
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"
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
- 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.
- Related to Bug #2401: OsmoPCU accepts UDP packets from any source added
- Related to Bug #4111: BSSGP SUSPEND ACK with unknown BVCI=0 added
lynxis , daniel is this longer a concern regarding new NS implementation?
- 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.
Also available in: Atom
PDF
