Hi Holger,
I was able to narrow it down, and it seems this is the patch that
causing the problem:
http://cgit.osmocom.org/libosmocore/commit/?id=f5a079f739c57d8be7c59149fd45…
Up to that patch it works (more or less), but after I applied it, I
got this seg faults.
I don't know how to do back traces but I try to get some info about
this topic and will send the results.
Csaba
Hello,
I am wonder how to add support for other Transceivers, in particular the
BladeRF ( http://nuand.com/ ). If anyone has a start point for me to learn
how to do this, it would be fantastic!
Many thanks
On Tue, Jul 02, 2013 at 11:51:49PM -0700, Caleb Pal wrote:
> Holger,
Hi,
I have a reliable re-producer of the issue. It happens when the PCU is
dead and we still receive segmented data from the GGSN. The re-producer
is inside a branch of mine of the OsmoPCU code[1]. The commit message
has some information about how to re-produce (what is missing is the
ACL config of the SGSN to allow this test).
Maybe you want to try to fix the issue based on this setup?
kind regards
holger
[1] http://git.osmocom.org/osmo-pcu/commit/?h=zecke/features/emulator&id=a727a2…
If we don't do this, we will generate a bogus warning in
gprs_sgsn:sgsn_pdp_ctx_free() when we release a pctx which still has the
lib pointer set to non-NULL.
At the same point, we introduce an OSMO_ASSERT() to verify that the
pctx->lib really equals the pdp context which libgtp reported to us.
---
openbsc/src/gprs/sgsn_libgtp.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/openbsc/src/gprs/sgsn_libgtp.c b/openbsc/src/gprs/sgsn_libgtp.c
index f2eb35d..c244e2c 100644
--- a/openbsc/src/gprs/sgsn_libgtp.c
+++ b/openbsc/src/gprs/sgsn_libgtp.c
@@ -264,6 +264,10 @@ static int create_pdp_conf(struct pdp_t *pdp, void *cbp, int cause)
DEBUGP(DGPRS, "Received CREATE PDP CTX CONF, cause=%d(%s)\n",
cause, get_value_string(gtp_cause_strs, cause));
+ /* make sure that libgtp doesn't call us with inconsistent
+ * pointers */
+ OSMO_ASSERT(pctx->lib == pdp);
+
/* Check for cause value if it was really successful */
if (cause < 0) {
LOGP(DGPRS, LOGL_NOTICE, "Create PDP ctx req timed out\n");
@@ -292,8 +296,13 @@ static int create_pdp_conf(struct pdp_t *pdp, void *cbp, int cause)
reject:
pctx->state = PDP_STATE_NONE;
- if (pdp)
+ if (pdp) {
pdp_freepdp(pdp);
+ /* unlink the now non-existing library handle from the
+ * pdp context */
+ pctx->lib = NULL;
+ }
+
/* Send PDP CTX ACT REJ to MS */
rc = gsm48_tx_gsm_act_pdp_rej(pctx->mm, pctx->ti, reject_cause,
0, NULL);
--
1.8.3.2
--
- 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)
Dear LaF0rge,
I pushed "zecke/features/emulator" to the osmo-pcu repository. All it
does is to send a static GPRS Attach for a foreign TLLI. Looking at the
communication with Wireshark one will see:
Identity Requests messages.. always with N(U) = 0
and in the SGSN log one can see:
<0012> gprs_llc.c:773 LLC RX: unknown TLLI 0xadf11820, creating LLME on the fly
...
<0012> gprs_llc.c:357 LLC TX: unknown TLLI 0xedf11820, creating LLME on the fly
What happens is the following:
When receiving the GPRS Attach we create a LLME for the 'foreign' TLLI,
but the look-up will never compare tlli/old_tlli with the foreign one. It
will always be localized.
The smallest change is this one:
diff --git a/openbsc/src/gprs/gprs_llc.c b/openbsc/src/gprs/gprs_llc.c
index 8af5367..52727ce 100644
--- a/openbsc/src/gprs/gprs_llc.c
+++ b/openbsc/src/gprs/gprs_llc.c
@@ -777,9 +777,10 @@ int gprs_llc_rcvmsg(struct msgb *msg, struct tlv_parsed *tv)
(llhp.cmd == GPRS_LLC_XID || llhp.cmd == GPRS_LLC_UI)) {
struct gprs_llc_llme *llme;
/* FIXME: don't use the TLLI but the 0xFFFF unassigned? */
- llme = llme_alloc(msgb_tlli(msg));
+ llme = llme_alloc(tlli_foreign2local(msgb_tlli(msg)));
LOGP(DLLC, LOGL_DEBUG, "LLC RX: unknown TLLI 0x%08x, "
- "creating LLME on the fly\n", msgb_tlli(msg));
+ "creating LLME on the fly\n",
+ tlli_foreign2local(msgb_tlli(msg)));
lle = &llme->lle[llhp.sapi];
} else {
LOGP(DLLC, LOGL_NOTICE,
(but one could move that into llme_alloc and then it works for RX/TX). After
this patch the Identity Request requests will have an increasting N(U) and the
tlli in the message will be 0xadf11820. The SGSN will still print:
<0012> gprs_llc.c:142 TLLI 0xadf11820 is foreign, converting to local TLLI 0xedf11820
So this means that for the entire GPRS attach procedure we will use the
initial foreign TLLI.... so somehow... the code in the MM handling...
/* 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 tlli_new does not appear to be used at all and I don't see how/where
we would use/create the OLD_TLLI IE? Is it implemented?
holger
In case we have access to the context verify that the selected
msgb_tlli is either the old_tlli or the tlli. It is wrong to use
any other TLLI.
---
openbsc/src/gprs/gprs_llc.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/openbsc/src/gprs/gprs_llc.c b/openbsc/src/gprs/gprs_llc.c
index 57e557a..c3bd9d2 100644
--- a/openbsc/src/gprs/gprs_llc.c
+++ b/openbsc/src/gprs/gprs_llc.c
@@ -52,6 +52,10 @@ static int _bssgp_tx_dl_ud(struct msgb *msg, struct sgsn_mm_ctx *mmctx)
dup.drx_parms = mmctx->drx_parms;
dup.ms_ra_cap.len = mmctx->ms_radio_access_capa.len;
dup.ms_ra_cap.v = mmctx->ms_radio_access_capa.buf;
+
+ /* make sure we only send it to the right llme */
+ OSMO_ASSERT(msgb_tlli(msg) == mmctx->llme->tlli
+ || msgb_tlli(msg) == mmctx->llme->old_tlli);
}
memcpy(&dup.qos_profile, qos_profile_default,
sizeof(qos_profile_default));
--
1.8.3.2
--UugvWAfsgieZRqgk--
hi,
these 7 patches have been tested with sysmobts and osmo-bts (trx
interface). it works with calls and gprs. before applying any of these
patches, i suggest to double check it with a different test setup.
regards,
andreas
During the GPRS Attach procedure we might have a foreign tlli and
in the RX create a LLME on the fly for this tlli. The GMM GPRS
Attach handling code will then assign a new TLLI and keep the
foreign tlli as the llme->old_tlli.
When the GMM is sending the identity request the msgb_tlli will
point to the foreign tlli. The GPRS LLC code will then try to find
that foreign tlli but due the conversion this will not be found.
Instead a new ad-hoc LLE/LLME will be created on the fly for
each message (this means there are duplicate LLE/LLMEs in the
list).
Make the code more strict and remove the tlli_foreign2local change
from the look-up routine. This will make the GPRS LLC code find
the right LLE/LLME and the N(U) will be handled correctly.
Addresses:
<0012> gprs_llc.c:773 LLC RX: unknown TLLI 0xadf11820, creating LLME on the fly
...
<0012> gprs_llc.c:357 LLC TX: unknown TLLI 0xedf11820, creating LLME on the fly
Reproducable:
Use pcu_emu (gprs attach) and observe with wireshark.
---
openbsc/src/gprs/gprs_llc.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/openbsc/src/gprs/gprs_llc.c b/openbsc/src/gprs/gprs_llc.c
index 8af5367..57e557a 100644
--- a/openbsc/src/gprs/gprs_llc.c
+++ b/openbsc/src/gprs/gprs_llc.c
@@ -147,12 +147,10 @@ static inline uint32_t tlli_foreign2local(uint32_t tlli)
}
/* lookup LLC Entity based on DLCI (TLLI+SAPI tuple) */
-static struct gprs_llc_lle *lle_by_tlli_sapi(uint32_t tlli, uint8_t sapi)
+static struct gprs_llc_lle *lle_by_tlli_sapi(const uint32_t tlli, uint8_t sapi)
{
struct gprs_llc_llme *llme;
- tlli = tlli_foreign2local(tlli);
-
llist_for_each_entry(llme, &gprs_llc_llmes, list) {
if (llme->tlli == tlli || llme->old_tlli == tlli)
return &llme->lle[sapi];
--
1.8.3.2
--UugvWAfsgieZRqgk
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment; filename="0002-gprs_llc-Assert-that-we-send-frames-with-either-tlli.patch"
Hi all,
Attached patch adds vty command for setting Access control classes (GSM
02.11 Section 4 Access control) in RACH Control Parameters (GSM 04.08
Section 10.5.2.29
RACH Control Parameters).
--
Regards,
Ivan Kluchnikov.
http://fairwaves.ru
Today, after I successfully started two InSite BTS units on the same E1
line, I tried to test the OpenBSC handover function.
I got a strange error message, that I have to enable RTP Proxy
mode with "-P" in osmo-nitb. Because these units are running from E1,
I just simply ask: do we have handover support for E1 based BTSs? Cell
reselection and inter BTS voice calls, SMSs are working just fine.
BR,
Csaba
hi harald,
i know that you talked about before so maybe you can give me a hint. i
like to make osmo-sgsn allow roaming (different PLMN of the phone than
the one in the RAI of the BTS).
regards,
andreas
Good Morning Harald,
do you mind if we drop support for the HSL BTS? The support is
spewing out compile warnings, now turns up in coverity reports
as well and we don't even know if it is working with the latest
version of the software running on these BTS.
holger
Hi,
Coverity pointed out a missing break. I have added it now but the
fix might break BS11 code that relied on this broken functionality.
Could anyone with a BS11 please test this? I will integrate the
change in a week.
holger
Hi Thomas,
I've made some progress in making osmo-trx able to power off/on
without restart. At this moment it's almost there - the only big
remaining issue I see is some bug with UHD device start/stop. It seems
we do not re-initialize it properly and assert (num_rd == OUTCHUNK)
fails. I hope you could fix that.
I completely re-wrote Thread class to make starting/stopping threads a
synchronous reliable operation. I also introduced shutdown() function
to FIFOServiceLoopThread, ControlServiceLoopThread and
TransmitPriorityQueueServiceLoopThread. This method takes care of
un-blocking a thread from a blocking read from a queue or a socket.
Few bugs in the other code is fixed as well. Details are below, please
review the patches.
Patch set is checked into https://github.com/fairwaves/osmo-trx under
achemeris/stable_threads and achemeris/poweroff_hack branches.
> commit c5da6607b4d17706380de72e0814e28f03624c51
> Author: Alexander Chemeris <Alexander.Chemeris(a)gmail.com>
> Date: Sun Jul 14 14:57:14 2013 +0400
>
> Transceiver52M: Fix crash in uhd_device destructor due to deleting statically allocated memory.
This is a genuine bug, should be fixed upstream.
> commit dbd27a60b6ed99fd6fd2339ffafccc0d759fa2fc
> Author: Alexander Chemeris <Alexander.Chemeris(a)gmail.com>
> Date: Sat Jul 13 21:26:39 2013 +0400
>
> CommonLibs: Fix compile time warnings.
Fixes annoying warning.
> commit 8eaa40dd6c2a783306d809aec98c2937e15068f3
> Author: Alexander Chemeris <Alexander.Chemeris(a)gmail.com>
> Date: Sun Jul 14 16:23:32 2013 +0400
>
> Transceiver52M: Remove unused thread mAlignRadioServiceLoopThread;
This actually leads to crash when Thread class is abstract.
> commit b8646946526903d2bbfa657690936b9bcba80ca5
> Author: Alexander Chemeris <Alexander.Chemeris(a)gmail.com>
> Date: Sat Jul 13 22:29:12 2013 +0400
>
> CommonLibs: DEBUG: Mark interthread classes which are not used in OsmoTRX.
I've added this comments just to simplify debugging. I.e. I don't want
to debug interthread primitives which we do not use.
> commit 69b6a6dfcd882df180e9d5e9856225f4b1d2eeed
> Author: Alexander Chemeris <Alexander.Chemeris(a)gmail.com>
> Date: Sun Jul 14 01:43:04 2013 +0400
>
> CommonLibs: Allow NULLs to be retrieved from InterthreadQueue.
>
> We need a way to stop InterthreadQueue blocking read to be able to shutdown
> a thread. The easiest way to do that is to push NULL to the queue, but the
> original implementation will just ignore that and continue blocking. After
> the change the blocking read() will exit with NULL result which is perfectly
> fine with us.
>
> Ideally we should change all methods of InterthreadQueue to return a status
> value to indicate normal exits, timeouts, etc. Right now the only way to
> indicate an error is returning NULL, which could be a valid operation.
>
> commit d4a8c1360e5d54188b648766dde199fa37f2ed27
> Author: Alexander Chemeris <Alexander.Chemeris(a)gmail.com>
> Date: Sun Jul 14 02:00:00 2013 +0400
>
> CommonLibs: Add shutdown() method to the DatagramSocket class.
>
> This method is useful to abort a blocking operations on a socket during shutdown.
>
> commit 302a9198df85e4f771368f24d8445dec7c8b2203
> Author: Alexander Chemeris <Alexander.Chemeris(a)gmail.com>
> Date: Sun Jul 14 12:04:44 2013 +0400
>
> CommonLibs: Signal::wait() should return the value which pthread_cond_timedwait() returns.
>
> commit e279124660a2add686e6c9266d18a9bb0cf43258
> Author: Alexander Chemeris <Alexander.Chemeris(a)gmail.com>
> Date: Sun Jul 14 12:38:25 2013 +0400
>
> CommonLibs: Rewrite Threads class to be predictable during start/stop.
>
> Current implementation strictly synchronize thread startup and shutdown
> to make sure a thread is actually started on startThread() exit and
> that it's stopped on stopThread() exit (or an error is returned).
>
> I also changed the Thread class to be used as a parent class for
> an actual thread. This way we could provide much better logical
> separation between variables used by different threads. Which will
> (hopefully) reduce number of issues with inter-thread communications.
>
> commit de202e343564913e0591de10850e617d7de55b6b
> Author: Alexander Chemeris <Alexander.Chemeris(a)gmail.com>
> Date: Sun Jul 14 12:42:52 2013 +0400
>
> Transceiver52M: Port all threads to the new Thread interface.
>
> Also note that we introduced shutdown() method for Transceiver threads which
> implement proper shutdown of threads when they are in blocking read state.
> This involves using shutdown() on sockets and pushing NULL to queues.
>
> With this change we should be able to start/stop transceiver channels at
> arbitrary moments.
>
> commit 129ad76b15f1fdf0588d5a24fe2d0f7ef3df274e
> Author: Alexander Chemeris <Alexander.Chemeris(a)gmail.com>
> Date: Sun Jul 14 12:48:37 2013 +0400
>
> Transceiver52M: Delay is no longer needed at the transceiver exit, threads should shut down cleanly.
>
> commit 604f65e69f2317dd5dc1aeb8faf3c107cd8a2231
> Author: Alexander Chemeris <Alexander.Chemeris(a)gmail.com>
> Date: Sun Jul 14 13:22:31 2013 +0400
>
> CommonLibs: Port InterthreadTest and SocketsTest to the new Thread API.
>
> commit c4038ef54c806c8c00f7fa28bc2b8b200bc3356f
> Author: Alexander Chemeris <Alexander.Chemeris(a)gmail.com>
> Date: Sun Jul 14 13:24:16 2013 +0400
>
> CommonLibs: Adding a new ThreadsTest testsuite.
>
> It's very basic at this moment. We should add a stress-test for thread
> start/stop at least.
This is the meat of the branch.
At this stage everything works fine, threads are shutdown properly,
but power off command still doesn't power off the transceiver.
> commit c0f0da4ec8e0068a562f427a89a899bf190bc74a
> Author: Alexander Chemeris <Alexander.Chemeris(a)gmail.com>
> Date: Sun Jul 14 23:07:31 2013 +0400
>
> Transceiver52M: HACK: Exit transceiver on POWEROFF command.
>
> This hack allows OsmoBTS to correctly restart itself with different parameters.
> We assume that transceiver is run as a service and will be restarted on exit.
>
> commit 806a64b1df40871543e9ae34386463d08a564147
> Author: Alexander Chemeris <Alexander.Chemeris(a)gmail.com>
> Date: Sun Jul 14 22:58:55 2013 +0400
>
> Transceiver52M: Start and stop all threads on POWERON/POWEROFF.
>
> This change reveals some issue with the UHD start/stop code. Specifically,
> we get a failed assert in RadioInterface::pullBuffer() (num_rd == OUTCHUNK
> with num_rd=0) with the POWERON/POWEROFF/POWERON sequence.
These patches implements actual power off command. They are split into
a separate branch, because they lead to assert failure I mentioned
above. In my setup it's 100% reproducible. I hope you could fix that.
> commit 4c39dd4b492b439742911aa70623d41ad634d7f4
> Author: Alexander Chemeris <Alexander.Chemeris(a)gmail.com>
> Date: Sun Jul 14 22:45:40 2013 +0400
>
> Transceiver52M: Introduce usage counting for DriveLoop and RadioInterface.
>
> The reason is to allow them to be started from any TRX. I.e. they are started
> when the first TRX starts and stopped when the last TRX stops.
This hack is a workaround for the assert failure above - it shuts down
the complete transceiver in a hope that it will be restarted by
external means. Meant as to be used in production while we don't have
the assert failure fixed.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ООО УмРадио
http://fairwaves.ru
It appears to me that for NM_OC_BS11 mo was either NULL or the
one mo value from NM_OC_BS11_RACK. The break inside the nested
switch case didn't break from the outer one.
Fixes Coverity: CID 1040728
---
openbsc/src/libcommon/gsm_data_shared.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/openbsc/src/libcommon/gsm_data_shared.c b/openbsc/src/libcommon/gsm_data_shared.c
index 9a50f6b..1b0814c 100644
--- a/openbsc/src/libcommon/gsm_data_shared.c
+++ b/openbsc/src/libcommon/gsm_data_shared.c
@@ -390,6 +390,7 @@ gsm_objclass2mo(struct gsm_bts *bts, uint8_t obj_class,
default:
return NULL;
}
+ break;
case NM_OC_BS11_RACK:
mo = &bts->bs11.rack.mo;
break;
--
1.8.3.2
Hi all,
I'm moving this conversation from private to public. I think Sylvain
and Andreas might be interested in participating.
---------- Forwarded message ----------
From: Thomas Tsou <tom(a)tsou.cc>
Date: Tue, Jul 9, 2013 at 2:51 AM
Subject: Re: DSP optimization
To: Alexander Chemeris <alexander.chemeris(a)gmail.com>
On Mon, Jul 8, 2013 at 6:52 AM, Alexander Chemeris
<alexander.chemeris(a)gmail.com> wrote:
> Wow, optimization of 5-16x for Viterbi is huge indeed. I wonder what
> would be results for our Atoms.
Without SSE, just C only butterfly, the improvement is around 4x. SSE
3 (Atom) forces a small change on the normalization (not separated out
yet), but the results weren't very far off from SSE 4.1 when I tested
on Core 2 Duo.
I might try to manipulate the interface to read in the state tables
instead of the generator polynomials. That would really help with
testing and integration, but I'm not sure yet. There are many ways to
go here.
> What is problematic with the runtime detection? CPU autodetection on
> Linux should be as easy as reading /proc/cpuinfo. But I see an issue
> is with correctly setting up build system to generate all version on
> the same run. I think we could leave CPU autodetection for the
> "everything else" milestone, using compile time selection for now.
I think compile time detection is more appropriate. For GSM / LTE
we're almost always dealing with fixed sized vectors and not odd
calculations (e.g. 1023 size FFT), so it's unlikely that the results
will change on repeated runs.
/proc/cpuinfo parsing scripts I've seen have been prone to breakage.
If you have a really good one, let me know. I usually prefer to run
configure checks against the actual instruction, but that can get
messy with a lot of checks. Anyhow, I'm not worrying about this now.
> What repository will you push at? We need to have at least master
> branch and dual-channel branch working with the optimizations. And I
> believe everyone would be happy to see optimizations in the
> libosmocore for the benefit of other projects as well. I don't foresee
> any issues with a slight change in the API of libosmocore if it is
> justified - just send an RFC/patch to the OpenBSC mailing list and it
> will be reviewed.
Non-Viterbi changes are sigProc.cpp changes only, so they are not
branch-specific - they will probably merge into the oldest available
OpenBTS releases. The Viterbi changes merge into Andreas's branch,
which is a very large change. For now, somebody needs to write it,
which is why I'm considering making the interfaces match.
Attached are the standalone unit test cases for SSE 4.2. As previously
mentioned, Atom needs SSE3 only. I'll add the ifdefs for those
shortly. I don't know if there's an appropriate repository for these
right now - linking libosmocore from the transceiver for comparison
purposes only seems silly. I just generated a temporary tarball for
the time being.
Thomas
--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ООО УмРадио
http://fairwaves.ru
Hi Thomas,
What is the reason you disabled setting power attenuation an receive
gain for the second trx? Since both channels in UmTRX are independent,
it should be possible to control tx power and rx gain independently.
In the "SETPOWER" command handler:
if (mPrimary)
mRadioInterface->setPowerAttenuation(dbPwr);
In the "SETRXGAIN" it's even stranger, as it's set twice in case of primary trx:
newGain = mRadioInterface->setRxGain(newGain);
mEnergyThreshold = INIT_ENERGY_THRSHD;
if (mPrimary)
newGain = mRadioInterface->setRxGain(newGain);
--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ООО УмРадио
http://fairwaves.ru
Dear LaF0rge, Andreas,
I am really disappointed about the used process for this change. As
an absolute minimum run "make check" after bigger changes. The run
takes about 20 seconds (and that is probably 15s in the timer test),
I have to spend way more time fixing the fall-out from that and it
creates the impression that you do not value my time!
I think Andreas should have posted this kind of change to the mailing
list and ask for review. The way it was done is really unacceptable
and the build is still broken. And to make it worse I think the change
is wrong in several ways:
1.) The issue of the last '7bit' being 'empty' only applies to USSD/CB:
"If the total number of characters to be sent equals (8n-1) where
n=1,2,3 etc. then there are 7 spare bits at the end of the message.
To avoid the situation where the receiving entity confuses 7 binary
zero pad bits as the @ character, the carriage return or <CR> character
(defined in subclause 7.1.1) shall be used for padding in this situation,
just as for Cell Broadcast."
In SMS one has both the octet length and the character length inside
the messages. In USSD this information is not present.
2.) The semantic of the change is bad.
+ octet_len = response_len*7/8;
+ if (response_len*7%8 != 0)
+ octet_len++;
+ /* Warning, response_len indicates the amount of septets
+ * (characters), we need amount of octets occupied */
Every caller of gsm_7bit_encode now needs to consider adding this change,
it is better to move this into gsm_utils.c. E.g. take a look at my branch
called zecke/features/alpha-numeric for a gsm_7bit_encode_oct. Which
comes with a testcase... and moves this responsibility into libosmocore
and is based on the real octets written (instead of trying to figure it
our afterwards).
We all make money by working on Osmocom sub-projects and I really can't
stand such amateurish work. Can we force reset master to before the merge
and try again?
cheers
holger
Hi
in order to decode Cipher Mode Command from Alcatel S-12, please accept a
patch to gsm0808.c
Without it OpenBSC rejects ciphering, and procedures are broken from MSC
side
@@ -305,6 +305,7 @@
[GSM0808_IE_CELL_IDENTIFIER] = { TLV_TYPE_TLV },
[GSM0808_IE_CHOSEN_CHANNEL] = { TLV_TYPE_TV },
[GSM0808_IE_LAYER_3_INFORMATION] = { TLV_TYPE_TLV },
+ [GSM0808_IE_LAYER_3_HEADER_INFORMATION] = { TLV_TYPE_TLV
},
[GSM0808_IE_SPEECH_VERSION] = { TLV_TYPE_TV },
[GSM0808_IE_CHOSEN_ENCR_ALG] = { TLV_TYPE_TV },
},
Right now there is a pilot with MNO, and Telscale SS7 Card runs code for
A-interface gateway,
converting BSSAP/SS7 to SCCPoverIP + rtp.
It seems that such a gateway also has to adapt OpenBSC to each particular
MSC.
As an example, DTAP portion of Cipher Mode Complete must be removed for
proper operation with S12.
Code will published as soon as pilot succeeds.
Best Regards,
Dmitri
hi,
while trying to do a second call (hold the first, dial another number),
i found out that there is no acknowledge for a CM service request, when
encyption is enabled. the attached patch will fix it.
regards,
andreas
Hi everyone,
I have to setup a complete call with voice support and also a complete working GPRS network with just simulation and no physical base station, is it achievable?
It would be great if someone could enlighten me on this.
Thanks and regards,
Priyanka
I have FINALLY gotten to play with my sysmoBTS acquired many months ago,
and updated to the latest packages using okpg, and am running a NITB.
GSM850 test setup in open mode A5/0, and I can SMS and call between devices.
However, there is no audio, and BTS console logs reports many repeats of
the following during an established call.
<0006> tch.c:601 (bts=0,trx=0,ts=7,ss=0) Rx Payload Type EFR is unsupported
<0006> tch.c:601 (bts=0,trx=0,ts=7,ss=0) Rx Payload Type EFR is unsupported
<0006> tch.c:601 (bts=0,trx=0,ts=7,ss=0) Rx Payload Type EFR is unsupported
A CM service request must be acknowledged also, when encryption is already
enabled.
Without encryption enabled, the security status is GSM_SECURITY_NOTAVAIL,
which causes a CM service acknowledge. On initial CM service request, the
security status is GSM_SECURITY_SUCCEED, if encryption is enabled. This
will not lead to an acknowledge, because the cyphering command implies an
acknowlege. An additional CM service request requires an acknowledge, so
I added a new security status: GSM_SECURITY_ALREADY
---
openbsc/include/openbsc/gsm_data.h | 1 +
openbsc/src/libmsc/gsm_04_08.c | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/openbsc/include/openbsc/gsm_data.h b/openbsc/include/openbsc/gsm_data.h
index d7db887..05e0490 100644
--- a/openbsc/include/openbsc/gsm_data.h
+++ b/openbsc/include/openbsc/gsm_data.h
@@ -21,6 +21,7 @@ enum gsm_security_event {
GSM_SECURITY_NOAVAIL,
GSM_SECURITY_AUTH_FAILED,
GSM_SECURITY_SUCCEEDED,
+ GSM_SECURITY_ALREADY,
};
struct msgb;
diff --git a/openbsc/src/libmsc/gsm_04_08.c b/openbsc/src/libmsc/gsm_04_08.c
index 58107e3..2ce0e8c 100644
--- a/openbsc/src/libmsc/gsm_04_08.c
+++ b/openbsc/src/libmsc/gsm_04_08.c
@@ -194,7 +194,7 @@ int gsm48_secure_channel(struct gsm_subscriber_connection *conn, int key_seq,
status = GSM_SECURITY_NOAVAIL;
} else if (conn->lchan->encr.alg_id > RSL_ENC_ALG_A5(0)) {
DEBUGP(DMM, "Requesting to secure an already secure channel");
- status = GSM_SECURITY_SUCCEEDED;
+ status = GSM_SECURITY_ALREADY;
} else if (!ms_cm2_a5n_support(subscr->equipment.classmark2,
net->a5_encryption)) {
DEBUGP(DMM, "Subscriber equipment doesn't support requested encryption");
@@ -856,6 +856,7 @@ static int _gsm48_rx_mm_serv_req_sec_cb(
break;
case GSM_SECURITY_NOAVAIL:
+ case GSM_SECURITY_ALREADY:
rc = gsm48_tx_mm_serv_ack(conn);
break;
--
1.8.1.5
--------------030304030609050702010202--
A CM service request must be acknowledged also, when encryption is already
enabled.
Without encryption enabled, the security status is GSM_SECURITY_NOTAVAIL,
which causes a CM service acknowledge. On initial CM service request, the
security status is GSM_SECURITY_SUCCEED, if encryption is enabled. This
will not lead to an acknowledge, because the cyphering command implies an
acknowlege. An additional CM service request requires an acknowledge, so
I added a new security status: GSM_SECURITY_ALREADY
---
openbsc/include/openbsc/gsm_data.h | 1 +
openbsc/src/libmsc/gsm_04_08.c | 8 +++++++-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/openbsc/include/openbsc/gsm_data.h b/openbsc/include/openbsc/gsm_data.h
index d7db887..05e0490 100644
--- a/openbsc/include/openbsc/gsm_data.h
+++ b/openbsc/include/openbsc/gsm_data.h
@@ -21,6 +21,7 @@ enum gsm_security_event {
GSM_SECURITY_NOAVAIL,
GSM_SECURITY_AUTH_FAILED,
GSM_SECURITY_SUCCEEDED,
+ GSM_SECURITY_ALREADY,
};
struct msgb;
diff --git a/openbsc/src/libmsc/gsm_04_08.c b/openbsc/src/libmsc/gsm_04_08.c
index 58107e3..3725eb9 100644
--- a/openbsc/src/libmsc/gsm_04_08.c
+++ b/openbsc/src/libmsc/gsm_04_08.c
@@ -194,7 +194,7 @@ int gsm48_secure_channel(struct gsm_subscriber_connection *conn, int key_seq,
status = GSM_SECURITY_NOAVAIL;
} else if (conn->lchan->encr.alg_id > RSL_ENC_ALG_A5(0)) {
DEBUGP(DMM, "Requesting to secure an already secure channel");
- status = GSM_SECURITY_SUCCEEDED;
+ status = GSM_SECURITY_ALREADY;
} else if (!ms_cm2_a5n_support(subscr->equipment.classmark2,
net->a5_encryption)) {
DEBUGP(DMM, "Subscriber equipment doesn't support requested encryption");
@@ -302,6 +302,11 @@ static int _gsm0408_authorize_sec_cb(unsigned int hooknum, unsigned int event,
release_loc_updating_req(conn);
break;
+ case GSM_SECURITY_ALREADY:
+ LOGP(DMM, LOGL_ERROR, "We don't expect LOCATION "
+ "UPDATING after CM SERVICE REQUEST\n");
+ /* fall through */
+
case GSM_SECURITY_NOAVAIL:
case GSM_SECURITY_SUCCEEDED:
/* We're all good */
@@ -856,6 +861,7 @@ static int _gsm48_rx_mm_serv_req_sec_cb(
break;
case GSM_SECURITY_NOAVAIL:
+ case GSM_SECURITY_ALREADY:
rc = gsm48_tx_mm_serv_ack(conn);
break;
--
1.8.1.5
--------------040306030909000104060200--
lapdm.c takes the re-establishment message and forwards it to lapd_core.c,
so we can assume that msgb is set at primitive. In case there is data in
the re-establishment msg, it is moved into send_buffer. In case of no
data (0 length), it must be freed.
---
src/gsm/lapd_core.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/gsm/lapd_core.c b/src/gsm/lapd_core.c
index 68b5e78..08143ed 100644
--- a/src/gsm/lapd_core.c
+++ b/src/gsm/lapd_core.c
@@ -1962,11 +1962,13 @@ static int lapd_res_req(struct osmo_dlsap_prim *dp, struct lapd_msg_ctx *lctx)
if (dl->send_buffer)
msgb_free(dl->send_buffer);
dl->send_out = 0;
- if (msg && msg->len)
+ if (msg->len) {
/* Write data into the send buffer, to be sent first */
dl->send_buffer = msg;
- else
+ } else {
+ msgb_free(msg);
dl->send_buffer = NULL;
+ }
/* Discard partly received L3 message */
if (dl->rcv_buffer) {
--
1.7.3.4
--------------030109030604040502010001--
Hi Peter,
> It means that some real programming is needed. It's not a small
> change. It might work as-is with one phone camping to only one of the
> two BTSes at a time, but you will likely have corruptions if you have
> a bunch of phones on both BTSes at once.
I was able to start two InSite units at the same time, probably
because these units has only one TRX per BTS. I was even able to
establish an inter-BTS voice call. Cell reselection and SMS was
working fine also.
But when I tried to enable handover, I got this strange message that I
have to enable RTP proxy. If I do so, my voice calls are failing
completely (not a surprise, these units are connecting through E1). I
could really use a straight answer from any developer, that OpenBSC has
handover support for non-IP (E1 based) units or not, because I am not
trying to get this done if it is completely missing.
> When using nitb with a multi-TRX MetroSite there is a similar pattern
> to what you describe - after the BTS is reset using the Nokia BTS
> Manager, nitb only ever manages to correctly initialize the first
> TRX. An error occurs and nitb exits. Restarting nitb sometimes allows
> it to initialize the second TRX, sometimes no. My guess is that
> failure or success depends on what phones are sending to the BTS
> meanwhile, but it could also be only a matter of timing.
Today I was able to setup our MetroSite (2 GSM1800 TRXs) unit and encountered the very
same problem: only the first TRX was initialized, though both TRXs are
set up in the openbsc config file. For the start and stop process you
absolutely right. Out of ten tries, usually 2-3 are successful if I
try to start both InSite units, but the chances are better if I
previously start openbsc with a single BTS config file, then hit
Ctrl+C and start the mutli BTS config file. It is also interesting,
that both TRXSIG lapd connections are ON according to the BTS manager
with MetroSite, but the second TRX is just not working.
> The nokia_site code can definitily be improved when it comes to
> startup/shutdown, but I don't know how well known the Nokia OML is.
> It would also be nice to listen to the BTS Manager serial port
> communication. If I understand correctly, many (all?) things that
> BTS Manager can do over serial are also possible over E1.
I can do these traces if you let me know what commands are you
interested in. For example I can tell you for sure, that the site
reset request command sent by OpenBSC (bts_nokia_site.c to be
specific) is doing exactly the same, when I hit "Enable Abis" in Nokia
BTS Manager.
BTW do you have Nokia units too?
I am still open to give access to our MetroSite (or
the InSite) units if a developer is interested in it.
I also have a fine selection of Nokia BTS managers that includes
almost all Nokia BTS types (InSite, MetroSite, UltraSite, Flexi HUB,
MetroHUB, Flexi EDGE, Metro Hopper etc.) I am happy to share this with any developer,
just PM me with an FTP server account and remember: the whole package
is 2.2GB.
Br,
Csaba
Dear Members,
As I previously mentioned, I have two Nokia InSite BTS units that I
want to set up for my university. One GSM900 and one GSM1800 unit, and
I want to share some findings that can be useful for other users too.
First, the informations about the DAHDI configuration at the end of
the building page:
http://openbsc.osmocom.org/trac/wiki/Building_OpenBSC
It sais the following for system.conf:
dchan=1
bchan=2-30
I wanted to point out that it is not necessary to define a dchan,
because with BTSes this is not a traditional E1 line configuration
where you share timeslots and you have to signal it
via the traditional E1 signaling channel (dchan), because for every
BTS there are dedicated timeslots for OMUSIG, TRXSIG and TCHs etc,
that cannot be used by anybody else. And
because we are not using that dchan, it is a waste of capacity to
allocate it. My DAHDI system.conf looks like this:
span=1,0,0,ccs,hdb3,crc4
bchan=1-31
and it works perfectly without a configured dchan (well its far from
perfect but at least the problem is not with the E1 configuration).
Because every BTS works like this, it would be wise the update that
information. For T1 lines and other framing configurations (cas, ami
etc.) it is the same.
The second thing is that Nokia InSite units (probably others too) can
be daisy chained. It is possible to share the first BTS units E1
connection for the daisy chained units with the integrated HDSL
cross-connection interface. With this technique it is possible to
share one E1 connection between 5 BTSes.
But there is a slight problem. I figured out if the BTS is not
connecting to the E1 directly, but via this HDSL interface, it needs
more time before it can be configured via OML,RSL. So in
bts_nokia_site.c the #DEFINE RESET_INTERVAL have to be raise from the
current 15 seconds to at least 25 seconds, otherwise the unit is not
going to came up. With this modification I was able to use the unity
via this HDSL cross-connection interface.
The third thing is multiple BTS operation. As I mentioned I want to
use two InSite units with OpenBSC. But at the beginning of
bts_nokie_site.c there is a big warning: I most certainly going to
have problems with multi BTS operation. Despite the warning I tried with two units, and
found an interesting thing: if I try to start the two units, only one
of the two units are going to came up. But if I start
the daisy chained unit first, then stop openbsc and immediately start
openbsc again but now with the two unit config file, both BTSes are
came up just fine, the phones can camp on both units. I don't know the
real reason behind this behavior, but I have log and PCAP traces
about the working and non-working scenarios. If someone interested in
it I can share the results. Although a possible reason is that in
bts_nokia_insite.c the shutdown routine is completely missing. It is
not a good solution, but at least we should reset the BTS(es) and
all the signalling channels in the shutdown state (like with BS11),
until we figure out some proper way of shutting Nokia BTSes down.
BR,
Csaba
Dear Osmocom community,
I'm currently looking for one or multiple volunteers who are willing to
tend to the mailman 'moderator queue' of the various osmocom mailing
lists (baseband-devel, openbsc, simtrace, tetra, osmocom-pcu, ...)
Our lists are 'member posting only' to protect them from spam. This
means that spammers will be caught in the list moderation queue together
with the occasional legitimate message from a non-subscriber.
You need to manually look over that queue in the mailman web interface,
select those legitimate posts as 'approve' and 'defer' all others.
The task requires very few minutes, but it requires them every day or
second day. It is a perfect opportunity how non-developers can
contribute to the project :)
Please let me know if anyone is willing to take care of this. Thanks!
Regards,
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)
To the MetroSIte topic:
I think we have a MetroSite unit with PSU, E1 card, TRE and 2 TRX.
Nobody tried it out because we dont have a BSC, but I will try to hook
it up to the E1 card and see if it works, I hope I can find a -48V DC
supply :-) If it works I will happily set up access for developers if
someone interested in it.
In the mean time, I will going to do some multi unit tests with the
two insite units and figure it out why sometimes both units came up,
and the other time why only the first unit came up only. I think it is
important to find why is this happening, because InSIte and MetroSite
units can both be daisy chained, and due to the extensive network
upgrades (in Europe) a lot of these units will be available on the
markets (Vodafone and Telenor already dropped these units after the
RAN upgrades in Hungary).
But it is also true, that maybe a good development direction would be
to support femto cells, that are easily and cheaply accessible to
anyone, uses IP technology and In general it is easy to work with.
BR,
Csaba
Dear Mailinglist
I am having a spot of bother with setting up asterisk with openbsc. I have gone with a basic setup from scratch LCR/ASTERISK/SIP minus mISDN as I dont require it and it would not compile it to my current kernel version in ubuntu 12.04 without downgrading it.
Anyway my problem is that I don't know how to prevent OpenBSC from using its own HLR and instead forward all phones that want to register to my nanoBTS to do so via Asterisk.
This is causing me grief because asterisk is its verbose logs is providing me this error when I try to make a call:
> -- Executing [8690 <at> phones:1] Dial("SIP/IMSI466974600011287-00000000",
> "SIP/IMSI466974104638690") in new stack
> [Dec 18 16:00:49] WARNING[2934]: app_dial.c:2218 dial_exec_full:
> Unable to create channel of type 'SIP' (cause 20 - Unknown)
> == Everyone is busy/congested at this time (1:0/0/1)
> -- Auto fallthrough, channel 'SIP/IMSI466974600011287-00000000'
> status is 'CHANUNAVAIL'
when I do show sip peers they are all offline because OpenBSC is registering my handsets and not passing on registration to Asterisk. I believe once OpenBSC is passing on registration all will be healthy with asterisk.
I don't have my configurations with me at the moment snipit above is from a google search, hopefully some helpful soul will know my blunders without my configs
Thank you all .
Regards
Adam
Dear Andreas,
the coverity prevent utility has found three inconsistencies in the
lapd_core.c and the gsm_04_08.c and I think you are suited the best
to comment on how to resolve them.
src/gsm/lapd_core.c
static int lapd_res_req(struct osmo_dlsap_prim *dp, struct lapd_msg_ctx *lctx)
...
1943 LOGP(DLLAPD, LOGL_INFO, "perform re-establishment (SABM) length=%d\n",
1944 msg->len);
...
CID 1040665 (#1 of 1): Dereference before null check (REVERSE_INULL)
check_after_deref: Null-checking "msg" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
1956 if (msg && msg->len)
so we already dereferenced msg to print the length. So at this point,
is it legetimate to a have NULL msgb or shall the null check be removed?
src/libmsc/gsm_04_08.c
static int gsm48_cc_rx_connect(struct gsm_trans *trans, struct msgb *msg)
...
2090 if (trans->subscr) {
2091 connect.fields |= MNCC_F_CONNECTED;
2092 strncpy(connect.connected.number, trans->subscr->extension,
2093 sizeof(connect.connected.number)-1);
2094 strncpy(connect.imsi, trans->subscr->imsi,
2095 sizeof(connect.imsi)-1);
2096 }
...
CID 1040740 (#1 of 1): Dereference after null check (FORWARD_NULL)
6. var_deref_op: Dereferencing null pointer "trans->subscr".
2117 osmo_counter_inc(trans->subscr->net->stats.call.mt_connect);
2118
2119 return mncc_recvmsg(trans->subscr->net, trans, MNCC_SETUP_CNF, &connect);
trans->subscr is conditionally dereferenced and then unconditionally,
what is correct?
static int gsm48_cc_rx_setup(struct gsm_trans *trans, struct msgb *msg)
...
1761 if (trans->subscr) {
1762 setup.fields |= MNCC_F_CALLING;
1763 strncpy(setup.calling.number, trans->subscr->extension,
1764 sizeof(setup.calling.number)-1);
1765 strncpy(setup.imsi, trans->subscr->imsi,
1766 sizeof(setup.imsi)-1);
1767 }
...
CID 1040739 (#1 of 1): Dereference after null check (FORWARD_NULL)
14. var_deref_model: Passing null pointer "trans->subscr" to function "subscr_name(struct gsm_subscriber *)", which dereferences it. [show details]
1813 LOGP(DCC, LOGL_INFO, "Subscriber %s (%s) sends SETUP to %s\n",
1814 subscr_name(trans->subscr), trans->subscr->extension,
1815 setup.called.number);
1816
1817 osmo_counter_inc(trans->subscr->net->stats.call.mo_setup);
Same thing as above. Can the null check be removed? Would you have the
time to do that?
Hi all,
Attached patch fixes lengths of MS Network Capability and MS Radio
Access Capability elements.
Original code was inconsistent about lengths and could lead to out of
bounds write. Lengths were also inconsistent with the TS 24.008.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ООО УмРадио
http://fairwaves.ru