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)