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
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
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@gnumonks.org:
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@gnumonks.org
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
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
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@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
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@gmail.com:
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@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
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.
-
Harald Welte -
Holger Hans Peter Freyther -
Michal Grznár