5 May
2014
5 May
'14
11:13 p.m.
Hi, I am using OsmoSGSN in topology with OpenGGSN and proprietary simulator
of BSS. There was a problem with an implementation of Network service,
cause Network Service implementation in the simulator of BSS is based on
different release of 3GPP standard (3GPP TS 48. 016 v7. 4. 0
(2008-04)/Network service (Release 7))...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:
switch (nsh->pdu_type) {
case NS_PDUT_ALIVE:
+++ LOGP(DNS, LOGL_INFO, "Rx NS ALIVE\n");
+++ /*mark NS-VC as alive*/
+++ (*nsvc)->state = NSE_S_ALIVE;
+++ (*nsvc)->remote_state = NSE_S_ALIVE;
+++ /*initiate TEST procedure: Send ALIVE_ACK and start timer*/
+++ rc = gprs_ns_tx_simple((*nsvc), NS_PDUT_ALIVE_ACK);
+++ nsvc_start_timer((*nsvc), NSVC_TIMER_TNS_TEST);
+++ break;
.
.
.
}
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
regards Michal
17 May
17 May
1:50 p.m.
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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
23 May
23 May
11:44 a.m.
Hi, I am sorry for my previous bad post format. There are the right diff
files.
And the problem was as I said in Imsi attach procedure new TLLI == new
allocated P-tmsi, and there was a problem that the function gprs_tmsi2tlli()
function there was not called and so I had to mask the upper bits in
function where the p-tmsi is allocated, there is also a pcap trace where
you can see it.
thanks, regards
Michal
2014-05-17 13:50 GMT+02:00 Harald Welte <laforge(a)gnumonks.org>rg>:
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(a)gnumonks.org>
http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch.
A6)
1:16 p.m.
On Fri, May 23, 2014 at 11:44:40AM +0200, Michal Grznár wrote:
Hi,
And the problem was as I said in Imsi attach procedure
new TLLI == new
allocated P-tmsi, and there was a problem that the function gprs_tmsi2tlli()
function there was not called and so I had to mask the upper bits in
function where the p-tmsi is allocated, there is also a pcap trace where
you can see it.
Could you please elaborate of what/were (e.g. packet numbers) we
can see "it" and what it should be instead? And please use "git diff"
or preferable "git commit" and git format-patch. The "diff" you
include
is hand-written and sadly not usable because of this.
And as written by Harald before. The place you patch is not correct.
The method you patch should generate a unique P-TMSI. It might should
mask some of the higher bits. But you need to look at the callers of
this function if the tlli is not updated.
e.g. in src/gprs/gprs_gmm.c you will see something like this:
ctx->p_tmsi = sgsn_alloc_ptmsi();
#endif
/* Even if there is no P-TMSI allocated, the MS will switch from
* foreign TLLI to local TLLI */
ctx->tlli_new = gprs_tmsi2tlli(ctx->p_tmsi, TLLI_LOCAL);
/* Inform LLC layer about new TLLI but keep old active */
gprs_llgmm_assign(ctx->llme, ctx->tlli, ctx->tlli_new,
GPRS_ALGO_GEA0, NULL);
So this call to gprs_tmsi2tlli will make sure that 0xc0000000 will
be set. In fact I see two calls to sgsn_alloc_ptmsi and both of them
do the above and assign the new tlli to the context. So please could
you try to explain what you are trying to solve?
holger
28 May
28 May
2:38 p.m.
Hi, it wasn´t handly written diffs but here I send diff made by using git
diff. And the problem you can see in packets with number 27-40 (especially
see in number 30 you see there the old tlli and newly generated P-TMSI in
message attach accept and in number 31 there is new TLLI which is the same
as generated P-TMSI in previous message) and that is the problem I needed
to solve, that the new TLLI was not LOCAL.
regards Michal
2014-05-23 13:16 GMT+02:00 Holger Hans Peter Freyther <holger(a)freyther.de>de>:
On Fri, May 23, 2014 at 11:44:40AM +0200, Michal
Grznár wrote:
Hi,
And the problem was as I said in Imsi attach
procedure new TLLI == new
allocated P-tmsi, and there was a problem that the function
gprs_tmsi2tlli()
function there was not called and so I had to
mask the upper bits in
function where the p-tmsi is allocated, there is also a pcap trace where
you can see it.
Could you please elaborate of what/were (e.g. packet numbers) we
can see "it" and what it should be instead? And please use "git
diff"
or preferable "git commit" and git format-patch. The "diff" you
include
is hand-written and sadly not usable because of this.
And as written by Harald before. The place you patch is not correct.
The method you patch should generate a unique P-TMSI. It might should
mask some of the higher bits. But you need to look at the callers of
this function if the tlli is not updated.
e.g. in src/gprs/gprs_gmm.c you will see something like this:
ctx->p_tmsi = sgsn_alloc_ptmsi();
#endif
/* Even if there is no P-TMSI allocated, the MS will switch from
* foreign TLLI to local TLLI */
ctx->tlli_new = gprs_tmsi2tlli(ctx->p_tmsi, TLLI_LOCAL);
/* Inform LLC layer about new TLLI but keep old active */
gprs_llgmm_assign(ctx->llme, ctx->tlli, ctx->tlli_new,
GPRS_ALGO_GEA0, NULL);
So this call to gprs_tmsi2tlli will make sure that 0xc0000000 will
be set. In fact I see two calls to sgsn_alloc_ptmsi and both of them
do the above and assign the new tlli to the context. So please could
you try to explain what you are trying to solve?
holger
5 Jun
5 Jun
11:52 a.m.
So it is the communication between osmoSGSN and sim-bss (Attach procedure).
The problem comes in attach accept/complete. OsmoSGSN sends message attach
accept with currenr TLLI = 0x78000001 and with new allocated P-TMSI =
0x475b916b. Sim-bss answeres with message attach complete with new tlli
made/generated im osmoSGSN from new P-TMSI...and as I said and as 3GPP
24.008 spec. says new TLLI = new allocated P-TMSI = 0x475b916b. And there
comes the problem that it is not LOCAL TLLI. So the point of the problem is
that new P-TMSI/TLLI is not generated correctly and could be said osmoSGSN
rejects what it generated and that is the problem. If it helps, I connects
osmo-SGSN_vty output.
Regards Michal
2014-05-28 14:38 GMT+02:00 Michal Grznár <mihal.grznar(a)gmail.com>om>:
Hi, it wasn´t handly written diffs but here I send
diff made by using git
diff. And the problem you can see in packets with number 27-40 (especially
see in number 30 you see there the old tlli and newly generated P-TMSI in
message attach accept and in number 31 there is new TLLI which is the same
as generated P-TMSI in previous message) and that is the problem I needed
to solve, that the new TLLI was not LOCAL.
regards Michal
2014-05-23 13:16 GMT+02:00 Holger Hans Peter Freyther <holger(a)freyther.de>
:
On Fri, May 23, 2014 at 11:44:40AM +0200, Michal Grznár wrote:
Hi,
And the problem was as I said in Imsi attach
procedure new TLLI == new
allocated P-tmsi, and there was a problem that the function
gprs_tmsi2tlli()
function there was not called and so I had to
mask the upper bits in
function where the p-tmsi is allocated, there is also a pcap trace where
you can see it.
Could you please elaborate of what/were (e.g. packet numbers) we
can see "it" and what it should be instead? And please use "git
diff"
or preferable "git commit" and git format-patch. The "diff" you
include
is hand-written and sadly not usable because of this.
And as written by Harald before. The place you patch is not correct.
The method you patch should generate a unique P-TMSI. It might should
mask some of the higher bits. But you need to look at the callers of
this function if the tlli is not updated.
e.g. in src/gprs/gprs_gmm.c you will see something like this:
ctx->p_tmsi = sgsn_alloc_ptmsi();
#endif
/* Even if there is no P-TMSI allocated, the MS will switch from
* foreign TLLI to local TLLI */
ctx->tlli_new = gprs_tmsi2tlli(ctx->p_tmsi, TLLI_LOCAL);
/* Inform LLC layer about new TLLI but keep old active */
gprs_llgmm_assign(ctx->llme, ctx->tlli, ctx->tlli_new,
GPRS_ALGO_GEA0, NULL);
So this call to gprs_tmsi2tlli will make sure that 0xc0000000 will
be set. In fact I see two calls to sgsn_alloc_ptmsi and both of them
do the above and assign the new tlli to the context. So please could
you try to explain what you are trying to solve?
holger
5 Aug
5 Aug
3:18 p.m.
On Fri, May 23, 2014 at 11:44:40AM +0200, Michal Grznár wrote:
Hi,
Hi, I am sorry for my previous bad post format. There
are the right diff
files.
And the problem was as I said in Imsi attach procedure new TLLI == new
allocated P-tmsi, and there was a problem that the function gprs_tmsi2tlli()
function there was not called and so I had to mask the upper bits in
function where the p-tmsi is allocated, there is also a pcap trace where
you can see it.
sorry for the late reply. The issue is that your MS does not convert the
P-TMSI to a Local-TLLI. On the other hand Jacob has pointed me to some
documentation of a measurement equipment manufacturer that states that the
local bits/highest two bits of the ptmsi should be set.
> > restart:
> > +++ ptmsi = rand() | 0xc0000000; /*because of GPRS IMSI
we will carry a patch like this.
3559
days inactive
3651
days old
6 comments
3 participants
participants (3)
-
Harald Welte -
Holger Hans Peter Freyther -
Michal Grznár