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/.
Neels Hofmeyr nhofmeyr at sysmocom.deOn Wed, Feb 13, 2019 at 02:20:40PM +0100, Harald Welte wrote: > The problem now is: If we "fix" the BTS side to reject the OPSTART without > prior SET RADIO CARRIER ATTRIBUTES, then older OsmoBSC will stop to work with > newer OsmoBTS. If we want newer OsmoBTS to enforce a specific order of messages: Introduce a legacy non-compat config option, sort of like that vi "set nocompatible". In the lack of any config, osmo-bts ignores OPSTARTs that came too early. IIUC a second opstart will follow? As new example config, we ship with an option like "oml strict", which then rejects OPSTARTs that came too early, instead of just ignoring. OTOH, if ignoring too early OPSTARTs works for both old and new osmo-bsc, we might not even need to be strict about it at all? If anyone out there is using osmo-bts with a BSC that only sends an early OPSTART, then this idea of ignorng early OPSTART would break that setup, I guess. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20190215/34d29f18/attachment.bin>