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/osmocom-net-gprs@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgHi Andreas,
On Fri, Jun 28, 2013 at 04:00:56PM +0200, Andreas Eversberg wrote:
> the main problem is that the bssgp/ns instance is created at the time
> the bts (and the pcu) receives informations from bsc. the pcu cannot
> (yet) instantiate at startup time, the required informations for the
> instance are not yet present then. this means that the pcu.cfg cannot
> have any ns/nse vty command. i don't see a good solution right now.
> maybe it is possible to create only the bssgp/ns instance itself,
> without creating, listening, connecting the nsvc.
The existing libgb API should cater for that. You can very well just
call gprs_ns_instantiate() and gprs_ns_vty_init() at PCU startup time,
but call gprs_ns_nsip_listen() and gprs_ns_nsip_connect() at the time
you receive the configuration from the BTS via the PCU_IF_MSG_INFO_IND.
Wouldn't that solve the problem?
The fact that the VTY would parse statically configured 'nse' sections
in the config file should not be a problem, we can simply assume that
the user does not put any such config sections in the config file for
now. If you're worried about saving them via 'write file / copy
running-config startup-config': this is what the gprs_nsvc.persistent
member is for, isn't it? Any non-persistent nsvc's will not be saved
via the VTY code.
Maybe I'm not understanding the problem yet, sorry.
Regards,
Harald
--
- 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)