Range of "ipa unit-id" site_id vty config

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Harald Welte laforge at gnumonks.org
Tue Nov 7 21:16:24 UTC 2017


On Tue, Nov 07, 2017 at 12:36:03PM +0100, Pau Espin Pedrol wrote:
> Hi,
> 
> I see the range for ipa unit-d site_id range of values is 0-65534 as
> configured in the VTY:
>
> osmo-bts/src/common/vty.c
> 397:      "ipa unit-id <0-65534> <0-255>",
>
> osmo-bsc/src/libbsc/bsc_vty.c
> 1850:      "ip.access unit_id <0-65534> <0-255>",
>
> openbsc/openbsc/src/libbsc/bsc_vty.c
> 1803:      "ip.access unit_id <0-65534> <0-255>",
>
> osmo-bts/src/common/vty.c
> 397:      "ipa unit-id <0-65534> <0-255>",
>
> However, being it a uint16_t having 2^16=65536 values, I would expect the
> range to be 0-65535 (finished in 5, not 4). The only reason I can think of
> is that the last address is somehow reserved and must not be used. Does
> somebody know if that's the case? I couldn't find any documentation and as
> far as I can tell our code doesn't seem to handle the site_id=65535 case
> specially. If it is not reserved, then I can send a patch to change the
> range to be 0-65535.

I don't actually know, as we don't know what ip.access' thoughts were when
designing this. There mihgt be something we forgot.  I'd vote to keep as-is
as it doesn't hurt to have one less unit id vs. the risk to break some setup.

> $ ag "0-65534"
> libosmocore/src/gb/gprs_ns_vty.c
> 269:    "nse <0-65535> nsvci <0-65534>",
> osmo-sgsn/src/gprs/gb_proxy_vty.c
> 149:      "sgsn nsei <0-65534>",
> 364:      "secondary-sgsn nsei <0-65534>",
> 532:    "delete-gbproxy-peer <0-65534> bvci <2-65534>",
> 553:    "delete-gbproxy-peer <0-65534> (only-bvc|only-nsvc|all) [dry-run]",
> 626:    "delete-gbproxy-link <0-65534> (tlli|imsi|sgsn-nsei) IDENT",
> 698:    "delete-gbproxy-link <0-65534> (stale|de-registered)",

I cannot find any reference in 08.14 or 01.16 to why NSVCI 0xffff is reserved,
so it could be changed

> libosmo-sccp/src/osmo_ss7_vty.c
> 420:    "listen " XUA_VAR_STR " <0-65534>",
> 442:    "no listen " XUA_VAR_STR " <0-65534>",
>
> openbsc/openbsc/src/libmgcp/mgcp_vty.c
> 294:      "bind port <0-65534>",
> 337:      "rtp bts-base <0-65534>",
> 350:      "rtp bts-range <0-65534> <0-65534>",
> 360:      "rtp net-range <0-65534> <0-65534>",
> 370:      "rtp net-base <0-65534>",
> 378:      "rtp base <0-65534>",
> 383:      "rtp transcoder-range <0-65534> <0-65534>",
> 393:      "rtp transcoder-base <0-65534>",
> 755:      "transcoder-remote-base <0-65534>",
> 1119:      "tap-call <0-64> ENDPOINT (bts-in|bts-out|net-in|net-out) A.B.C.D <0-65534>",
>
> osmo-mgw/src/libosmo-mgcp-client/mgcp_client_vty.c
> 130:      "mgw bts-base <0-65534>",
> 140:      "mgcpgw bts-base <0-65534>",
>
> osmo-mgw/src/libosmo-legacy-mgcp/mgcp_vty.c
> 294:      "bind port <0-65534>",
> 337:      "rtp bts-base <0-65534>",
> 350:      "rtp bts-range <0-65534> <0-65534>",
> 360:      "rtp net-range <0-65534> <0-65534>",
> 370:      "rtp net-base <0-65534>",
> 378:      "rtp base <0-65534>",
> 383:      "rtp transcoder-range <0-65534> <0-65534>",
> 393:      "rtp transcoder-base <0-65534>",
> 765:      "transcoder-remote-base <0-65534>",
> 1130:      "tap-call <0-64> ENDPOINT (bts-in|bts-out|net-in|net-out) A.B.C.D <0-65534>",
>
> osmo-mgw/src/libosmo-mgcp/mgcp_vty.c
> 264:      "bind port <0-65534>",
> 297:      "rtp net-range <0-65534> <0-65534>",
> 947:      "tap-rtp <0-64> ENDPOINT CONN (in|out) A.B.C.D <0-65534>",

port numbers go to 65535, so all the above can be changed.

> openbsc/openbsc/src/libmgcp/mgcp_vty.c
> 596:      "number endpoints <0-65534>",
>
> osmo-mgw/src/libosmo-legacy-mgcp/mgcp_vty.c
> 606:      "number endpoints <0-65534>",
>
> osmo-mgw/src/libosmo-mgcp/mgcp_vty.c
> 509:      "number endpoints <0-65534>",

not sure. dexter as done lots of work on the code, he should be able to comment

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



More information about the OpenBSC mailing list