Cellular Network Infrastructure » Radio Access Network » OsmoBSC

fixeria wrote in #note-1:

Ideally, yes, we should not permit local/remote port number 0. Currently an NSVC is considered not configured (by the VTY logic) if osmo_sockaddr_str_from_sockaddr() fails to convert the remote addr/port. The OML logic defines its own has_valid_nsvc(), which checks a) if local port if not 0 and b) if !osmo_sockaddr_is_any(). We cannot just change the value range to <1-65535> because then osmo-bsc would fail to parse config files it previously generated...

I investigated this a bit further and found out that local udp port 0 is a perfectly valid (special) value, which has been supported until the following patch was merged:

commit 315af2f9ea1e8b9bf6e58caebd9dd7829edecfed
Author: Alexander Couzens <lynxis@fe80.eu>
Date:   Mon Dec 19 21:21:32 2022 +0100

    bts: ipa/osmo-bts/sysmobts: MO: add support for the second NSVC

This commit added has_valid_nsvc() returning false if the local bind port is 0, so after this commit would simply ignore NSVCs with local udp port 0 and leave the respective MOs unconfigured in the BTS, even if a valid pair of remote address/port is set.

I abandoned my previously submitted patch:

https://gerrit.osmocom.org/c/osmo-bsc/+/32170 gprs: use sane default local UDP ports for NSVSs

and submitted another new one fixing has_valid_nsvc():

https://gerrit.osmocom.org/c/osmo-bsc/+/32169 gprs: fix has_valid_nsvc(): permit local udp port 0

I also confirmed in the leaked ip.access A-bis document that 0 is a permitted local port value for nanoBTS.