Bug #2401
closedOsmoPCU accepts UDP packets from any source
100%
Description
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
Updated by laforge almost 7 years ago
- Related to Bug #2384: NSVCI=0 seems to cause problems added
Updated by dexter over 6 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.
Updated by laforge over 6 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.
Updated by dexter over 6 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:
https://gerrit.osmocom.org/4317
https://gerrit.osmocom.org/4319
Updated by laforge about 5 years ago
- Related to Feature #3372: Support for SNS auto-configuration (SIZE / SNS-CONFIG procedure) added
Updated by laforge about 5 years 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.
