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/.
Pau Espin Pedrol pespin at sysmocom.deOn 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. -- - Pau Espin Pedrol <pespin at sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte