[PATCH] Add support of virtual networks for sending network name to ms depending on imsi

Harald Welte laforge at gnumonks.org
Mon Apr 18 09:38:04 UTC 2016

Hi Ivan,

I would prefer if we could use long-name and short-name instead of 'long
name' and 'short name' in the VTY syntax.

The VTY commands with spaces in them are a sign of my lack of
understanding of the VTY system at that time.  Multiple words should
only be used if there actually is a 'fork' in the tree, i.e. if several
commands are possible.

So two commands 'name short' and 'name long' would make sense, as they
are about name, and there are two options, one for short, and one for
long name.  Basically the same as 'name (short|long)'

But 'short name' and 'long name' will install command nodes for 'short'
and long', which doesn't make sense.  We keep the old syntax for
compatibility on the 'network' node, but for new code added, we should
try to avoid this.

So let's either use 'name (short|long)' (maybe the best solutioin) or
'short-name' and 'long-name'.

> +#define IMSI_PREFIX_LENGTH 16

we should probably not pull the magic number 16 out of our sleeve here,
but try to use an existing #define for the length of an IMSI.  I'm quite
sure we have one somewhere in libosmocore or the openbsc code base.

> +struct gsm_virt_network *gsm_virt_net_alloc_register(struct gsm_network *net)
> +{
> +	struct gsm_virt_network *virt_net;
> +
> +	virt_net = gsm_virt_net_alloc(net);
> +	if (!virt_net)
> +		return NULL;
> +
> +	virt_net->nr = net->num_virt_net++;
> +	virt_net->network = net;
> +	strcpy(virt_net->imsi_prefix, "00101");
> +	virt_net->name_short = talloc_strdup(net, "OpenBSC");
> +	virt_net->name_long = talloc_strdup(net, "OpenBSC");

why do we have hard-coded defaults for a prefix 00101 inside the code?
I think we should advoid such automatism, as creating a new virtual
network will then instantaneously match 00101 prefixed IMSIs without the
user ever specifying this. Or am I misunderstanding this?


- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

More information about the OpenBSC mailing list