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>",
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 actually see the same range pattern in lots of places around osmocom vty parameters, which makes me think somebody may have initially introduced the wrong number and then people have been copy-pasting the same number over and over again when adding new parameters:
$ ag "0-65534" libosmocore/src/gb/gprs_ns_vty.c 269: "nse <0-65535> nsvci <0-65534>",
libosmo-sccp/src/osmo_ss7_vty.c 420: "listen " XUA_VAR_STR " <0-65534>", 442: "no listen " XUA_VAR_STR " <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)",
osmo-bsc/src/libbsc/bsc_vty.c 1850: "ip.access unit_id <0-65534> <0-255>",
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>", 596: "number endpoints <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>",
openbsc/openbsc/src/libbsc/bsc_vty.c 1803: "ip.access unit_id <0-65534> <0-255>",
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>", 606: "number endpoints <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>", 509: "number endpoints <0-65534>", 947: "tap-rtp <0-64> ENDPOINT CONN (in|out) A.B.C.D <0-65534>",
osmo-bts/src/common/vty.c 397: "ipa unit-id <0-65534> <0-255>",
Regards,
Hmm, looks like a general policy to keep the 0xffff available as special value in case we ever need it, rather than a correctness requirement. I think though it's not worth the trouble changing all of those, because it entails checking each and every one to be absolutely sure.
About the recent gsm-tester patches: I'd rather have a is_int(min, max) function in osmo-gsm-tester and leave the values as-is. For that validator you can return a lambda like
def int_validator(min=0, max=65535): return lambda x: x >= min and x <= max
~N
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
On Wed, Nov 08, 2017 at 06:16:24AM +0900, Harald Welte wrote:
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
heh, noticing now, if each endpoint has four or more RTP/C ports, while we have in total 65535 ports available, the number of endpoints will hardly ever be able to surpass 16384.
~N
On 07/11/17 22:16, Harald Welte wrote:
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
After having a quick deeper look, I saw the following written in libosmocore/src/gb/gprs_ns.c:53
* This implementation has the following limitations: * - Only one NS-VC for each NSE: No load-sharing function * - NSVCI 65535 and 65534 are reserved for internal use
And I see several checks against 0xff and 0xfe in the code playing with dummy ids. I guess it's worth looking at it, because we should then either remove use of 65534 or try to fix the implementation and provide the 2 ports missing. But I agree it's probably not a high priority.
-
Harald Welte -
Neels Hofmeyr -
Pau Espin Pedrol