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