Bug #5018
closedneighbor config broken: need separate neighbor section, but 'write file' puts the config back inline
100%
Description
when reading the config OsmoBSC resolves the neighbor relations between cells immediately.
So when writing 'neighbor bts 23', that cell must already exist and be configured.
Same for identifying a neighbor by Cell Global ID / LAC-CI etc:
the config parsing immediately resolves the id, and classifies it as local or remote BTS.
Hence a local neighbor BTS must already be configured beforehand.
A consequence of this is that the config file must first configure all cells,
and in another section below configure only the neighbor relations:
network # first set up all cells bts 0 description my test BTS 0 type sysmobts band GSM-1800 ip.access unit_id 0 0 location_area_code 23 [...] bts 1 description my test BTS 1 type sysmobts band GSM-1800 ip.access unit_id 1 0 location_area_code 42 [...] # neighbor relations bts 0 neighbor bts 1 bts 1 neighbor bts 0
However, the 'write file' feature puts the neighbor relations back inline,
combining the two "config sections" and hence breaks the resulting config.
One solution would be to change 'write file' so that it puts neighbor relations in a separate section.
However, having to put neighbor config separately also potentially confuses users.
So a nicer solution would be to allow putting a neighbor relation in the config before that neighbor is configured.
Updated by neels about 3 years ago
- Status changed from New to In Progress
- % Done changed from 0 to 80
Updated by neels about 3 years ago
- % Done changed from 80 to 90
Updated by neels almost 3 years ago
- Status changed from In Progress to Resolved
- % Done changed from 90 to 100
Patches merged, issue should be fixed now.
Neighbor configuration should be permitted in any order, before or after the neighbor target cells are configured in the config file.
Also, neighbor configuration should be written back to the config file exactly as it was originally configured.
If there are neighbor configuration errors (like non-existing BTS number; non-existing local cell identity etc), osmo-bsc should refuse to start up.
When configuring neighbors on the live VTY console, that error checking does not happen; errors will still be logged as osmo-bsc resolves neighbors and encounters config errors. One possible pitfall: when such an erratic config from live VTY is written to file and osmo-bsc is restarted, the startup will complain about neighbor config errors and osmo-bsc will not start.