Bug #2401

OsmoPCU accepts UDP packets from any source

Added by laforge about 2 years ago. Updated 8 months ago.

Target version:
Start date:
Due date:
% Done:


Spec Reference:


It doesn't matter to which IP/PORT the NSVC of the PCU have been configured: It seems we only bind to the respective local port without doing a connect() of the socket to the given destination IP. Outbound packets are sent via sendto(). Incoming packets are read using recvfrom() and gprs_ns_rcvmsg() seems to dynamically allocate a NSVC if we don't know any NSVC for that source address.

The above behavior makes a lot of sense for the SGSN, but it isn't the right thing to do on the PCU side. We should either connect() the socket to the known address/port of the SGSN, or we should drop packets in gprs_ns_rcvmsg() if we don't have a configured NSVC for that source ip/port

Related issues

Related to OsmoPCU - Bug #2384: NSVCI=0 seems to cause problemsNew07/20/2017

Related to OsmoPCU - Feature #3372: Support for SNS auto-configuration (SIZE / SNS-CONFIG procedure)Resolved07/01/2018


#1 Updated by laforge about 2 years ago

  • Related to Bug #2384: NSVCI=0 seems to cause problems added

#2 Updated by laforge about 2 years ago

  • Priority changed from Normal to High

#3 Updated by laforge about 2 years ago

  • Assignee set to dexter

#4 Updated by dexter almost 2 years ago

  • Status changed from New to In Progress

I had a look at it:

Its probably the simplest to fix this by adding remote_ip and remote port
member to gprs_ns_inst. And then check in gprs_ns_rcvmsg(). If
remote_ip/remote_port is set to 0, all packets are accepted.

/*! An instance of the NS protocol stack */
struct gprs_ns_inst {

/*! NS-over-IP specific bits */
struct {
struct osmo_fd fd;
uint32_t local_ip;
uint16_t local_port;
uint32_t remote_ip;
uint16_t remote_port;
int dscp;
} nsip;


In gprs_bssgp_pcu.cpp:gprs_bssgp_create_and_connect() where we also instantiate
bssgp_nsi we could populate remote_ip/remote_port.

#5 Updated by laforge almost 2 years ago

Please double-check that any related proposal would work for all
users of the gprs_ns code, i.e. SGSN, PCU and gb_proxy.

I'm not implying that your proposal would not work. I'm just mentioning
that we have to make sure it works in all related use cases.

I guess it could be implemented in a way that if remote_ip/remote_port
are zero, then no connect() is made on the socket, and the current
behavior is preserved.

#6 Updated by dexter almost 2 years ago

  • % Done changed from 0 to 100

I have now implemented it using connect(). If the struct members remote_ip, and remote_port are set then connect() is used, otherwise everything works like it always did. I also added some log and verified that the SGSN accepts from packets from anyone and the BTS only from its assigned SGSN.

Patches are in Gerrit:

#7 Updated by dexter almost 2 years ago

  • Status changed from In Progress to Resolved

#8 Updated by laforge over 1 year ago

  • Status changed from Resolved to Closed

#9 Updated by laforge 8 months ago

  • Related to Feature #3372: Support for SNS auto-configuration (SIZE / SNS-CONFIG procedure) added

#10 Updated by laforge 8 months ago

FYI: With the changes required for OS#3372, this "connect()" behavior had to be made conditional to using the classic Gb/NS flavor. As soon as the IP-SNS with dynamic configuration is used, we have to communicate with multiple NS endpoints on the SGSN side.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)