OsmoSGSN [PATCH], Network Service

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/.

Harald Welte laforge at gnumonks.org
Sat May 17 11:50:33 UTC 2014


Hi Michal,

thanks a lot for reporting back on your experience.

Hoewever, it is customary to post changes as unified diff ('diff -u'
format here on this list for review.  I have a hard time understanding
the format that you posted.  Can you pleaes re-post your changes?
Either with diff -u created manually, or with 'git diff' or similar.

On Mon, May 05, 2014 at 11:13:37PM +0200, Michal Grznár wrote:
> Hi, I am using OsmoSGSN in topology with OpenGGSN and proprietary simulator
> and the problem is that in IP-subnetwork, which I am using there is no
> use for RESET or UNBLOCK procedure, so I had to do a PATCH in
> gprs_ns.c, which was needed to complete succesful connection between
> sim-bss and OsmoSGSN:

If you would like to see such code merged, please extend osmo-sgsn so
that the type of BSS can be configured via vty,  and make the code
conditional.  At that point you could simply have a different config
file for your sim-bss than we have.

> another PATCH I needed to do was to change a little bit procedure for
> allocation of P-TMSI in procedure uint32_t sgsn_alloc_ptmsi(void) in
> gprs_sgsn.c
> 
> uint32_t sgsn_alloc_ptmsi(void)
> {
>       struct sgsn_mm_ctx *mm;
>       uint32_t ptmsi;
> 
> restart:
> +++    ptmsi = rand() | 0xc0000000;              /*because of GPRS IMSI
> ATTACH*/
>           llist_for_each_entry(mm, &sgsn_mm_ctxts, list) {
>                  if (mm->p_tmsi == ptmsi)
>                           goto restart;
>           }
>           return ptmsi;
> }
> 
> because in GPRS IMSI ATTACH in message ATTACH COMPLETE (3GPP 24.008,
> 23.003, 48.018) there is new TLLI==new allocated P-TMSI and I need local
> TLLI, so I had to do it this way

This is most certainly not the right way to fix the problem.  The TLLI
is generated at a different layer than the P-TMSI.  The P-TMSI should be
completely random, and the TLLI derived from that should mask the upper
bits, using the gprs_tmsi2tlli() function.

Can you please explain more what the actual problem was and how it
manifested iself?  If possible, include pcap traces for further
illustration.

Thanks,
	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)




More information about the OpenBSC mailing list