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/.
Holger Freyther holger at freyther.de> On 9. Nov 2017, at 12:40, Neels Hofmeyr <nhofmeyr at sysmocom.de> wrote: > > My questions are: > > - Is it implemented this way for performance considerations? The performance consideration doesn't have anything to do with the order of matches. Not to use longest matching rule might be considered a performance consideration (both at runtime and implementation). Because there is no longest match a rule set (think of it in terms of first and then second rule) can not work. imsi-deny "all" imsi-allow "neels" In hindsight what would have been better is to define a policy "deny/allow" per access-list and then people can build opt-in or opt-out (allow every one but neels): access-list foo default allow access-list foo imsi-deny "neels" (deny everone one but neels): access-list foo default deny access-list foo imsi-allow "neels" Usecases where something like this. In this group only XYZ country IMSIs are allowed. But if you operate this as a testcell allow your own IMSI as well. Or for test cells.. No local IMSIs but allow my local IMSI. > - Are we not going to change this, even assuming that we regard changes being > useful, because we don't want to break with previous configs? I think any existing user of osmo-bsc already will already have difficulties to upgrade, changing the access lists might not make a big difference? > - When looking in auth_imsi(), the access list names are: > auth_imsi() name | comments | osmo-bsc passes > bsc_lst "local" vty 'msc' level access rules > nat_lst "global" vty 'bsc' level access rules > Needless to say that "local", "global", "nat", "bsc" and "msc" are quite > hard to follow. Sorry about that. I haven't looked at the code but it started in the NAT and then was generalized to be used in the BSC as well. > From the osmo-bsc filter code's perspective, there may be multiple MSCs > configured, and per-msc config could be seen as more specific ("local") than > bsc level, which applies to all MSCs ("global")... Was that the intention or > is the local/global actually swapped by accident? > (I notice that this feature seems to be intended for osmo-bsc-nat, and > there's also a concept of a super-global blacklist that is always NULL in > osmo-bsc.) super-global? Hehe. In terms of terminology and system. Upstream for the BSC is a MSC (or bsc-nat that emulates the A-link of a MSC) and the upstream for the bsc-nat is a real MSC (or another nat). Local depends where you are so just saying "BSC" might not be that clear either? holger