convert literal APN name to protocol encoded version before use

The definition of the APN field format in GTPv1 is hidden in a chain
of documents.

3GPP TS 29.060 (the GTPv1-C specification) Section 7.7.30:

> The Access Point Name contains a logical name (see 3GPP TS 23.060 [4]).
> It is coded as in the value part defined in 3GPP TS 24.008

3GPP TS 24.008 Section 10.5.6.1:

> The value part is defined in 3GPP TS 23.003.

3GPP TS 23.003 Section 9.1:

> The APN consists of one or more labels. Each label is coded as a one
> octet length field followed by that number of octets coded as 8 bit
> ASCII characters

This converts a literal APN (e.g. Label1.Label2.Label3) to a structured
field (e.g. \006Label1\006Label2\006Label3)

Signed-off-by: Andreas Schultz <aschultz@tpip.net>
---
 sgsnemu/sgsnemu.c | 18 ++++++++++++++----
 1 file changed, 14 insertions(+), 4 deletions(-)

On Fri, Nov 13, 2015 at 03:57:37PM +0100, Andreas Schultz wrote:
> This converts a literal APN (e.g. Label1.Label2.Label3) to a structured
> field (e.g. \006Label1\006Label2\006Label3)

thanks, applied to my local tree, will push soon.

Hi,

On 13.11.2015 15:57, Andreas Schultz wrote:
> 
>> The APN consists of one or more labels. Each label is coded as a one
>> octet length field followed by that number of octets coded as 8 bit
>> ASCII characters
> 
> This converts a literal APN (e.g. Label1.Label2.Label3) to a structured
> field (e.g. \006Label1\006Label2\006Label3)

We already have gprs_apn_to_str and gprs_str_to_apn in
openbsc/src/gprs/gprs_utils.c (along with test cases)  which are
probably good candidates (among other functions in that file) to be
moved to libosmocore, which sgsnemu is using already.

Nevertheless most of the basic GPRS stuff (e.g. gsm_04_08_gprs.c which
is on a similar level) is still in openbsc, so I would like to have more
of a concept (gsm, gb, or a new gprs lib? Name prefix?) before starting
refactoring.

Jacob

Hi Jacob,

On Mon, Nov 16, 2015 at 09:46:58AM +0100, Jacob Erlbeck wrote:

> Nevertheless most of the basic GPRS stuff (e.g. gsm_04_08_gprs.c which
> is on a similar level) is still in openbsc, so I would like to have more
> of a concept (gsm, gb, or a new gprs lib? Name prefix?) before starting
> refactoring.

I would argue to put more things into libosmogsm.  We already have
plenty of libraries and I think there's not much point to have even more
fragmentation.  I mean, we're not talking about hundreds of megabyte of
boost-enabled C++ code, but some amount of helper functions here.

libosmogb should stay related specific to the Gb (NS/BSSGP) interface, I
think that's a pretty clean/clear split.

In terms of prefixing: libosmogsm uses gsm* where * is for the reduced
spec number, and some gprs_* symbols.  I think it's hard to come up with
a detailed rule, but I'd say as long as it fits within that scheme it is
fine.

Starting now to prefix eveything with osmo_ seems a bit ridiculous, with
all the existing other-prefixed symbols. but let's kepe the nubmer of
prefixes limited ;)

Hi Harald,

On 16.11.2015 09:59, Harald Welte wrote:
> I would argue to put more things into libosmogsm.  We already have
> plenty of libraries and I think there's not much point to have even more
> fragmentation.  I mean, we're not talking about hundreds of megabyte of
> boost-enabled C++ code, but some amount of helper functions here.
> 
> libosmogb should stay related specific to the Gb (NS/BSSGP) interface, I
> think that's a pretty clean/clear split.

Agreed.

> In terms of prefixing: libosmogsm uses gsm* where * is for the reduced
> spec number, and some gprs_* symbols.  I think it's hard to come up with
> a detailed rule, but I'd say as long as it fits within that scheme it is
> fine.
> 
> Starting now to prefix eveything with osmo_ seems a bit ridiculous, with
> all the existing other-prefixed symbols. but let's kepe the nubmer of
> prefixes limited ;)

I just came across gsm/apn.c (which seems to be a sensible place to put
the conversion functions) where are currently definitions of
osmo_apn_qualify and osmo_apn_qualify_from_imsi. So for the sake of
consistency I can move the function there as osmo_apn_from_str/to_str.

Jacob