Hi Peter,
> Ok. Do you have a later message from the following line?
> LOGP(DLLAPD, LOGL_INFO, "I received in state %s\n", lapd_state_names[dl->state]);
Sure, this is how it looks with all relevant debugging enabled:
Fri Aug 2 16:50:13 2013 <0018> lapd_core.c:1465 I received in state LAPD_STATE_MF_EST
Fri Aug 2 16:50:13 2013 <0018> lapd_core.c:1548 incrementing V(R) to 1
Fri Aug 2 16:50:13 2013 <0018> lapd_core.c:222 stop T203
Fri Aug 2 16:50:13 2013 <0018> lapd_core.c:206 start T203
Fri Aug 2 16:50:13 2013 <0018> lapd_core.c:1557 message in single I frame
Fri Aug 2 16:50:13 2013 <001b> e1_input.c:594 RX: 80 80 00 08 81 00 00 01 5f 23 01 01 sapi=62 tei=1
Fri Aug 2 16:50:13 2013 <0005> bts_nokia_site.c:1668 Nokia: Abis received!
Fri Aug 2 16:50:13 2013 <0005> bts_nokia_site.c:1688 ABIS_OM_MDISC_FOM
Fri Aug 2 16:50:13 2013 <0005> bts_nokia_site.c:1515 (0x81) NOKIA_BTS_ACK
Fri Aug 2 16:50:13 2013 <0005> bts_nokia_site.c:1547 ACK = 1
Fri Aug 2 16:50:13 2013 <0005> bts_nokia_site.c:1588 Nokia: STOP OML
& RSL lapd (cause: RESET)
Fri Aug 2 16:50:13 2013 <0018> input/lapd.c:513 LAPD DL-RELEASE request TEI=1 SAPI=62
Fri Aug 2 16:50:13 2013 <0018> lapd_core.c:2183 Message DL-RELEASE-REQUEST received in state LAPD_STATE_MF_EST
Fri Aug 2 16:50:13 2013 <0018> lapd_core.c:2024 perform local release
Fri Aug 2 16:50:13 2013 <0018> lapd_core.c:229 new state LAPD_STATE_MF_EST -> LAPD_STATE_IDLE
Fri Aug 2 16:50:13 2013 <0018> lapd_core.c:222 stop T203
Fri Aug 2 16:50:13 2013 <0018> input/lapd.c:628 LAPD DL-RELEASE confirm TEI=1 SAPI=62
Fri Aug 2 16:50:13 2013 <001b> e1_input.c:585 DL_REL: sapi(62) tei(1)
Fri Aug 2 16:50:13 2013 <001b> bsc_init.c:318 Lost some E1 TEI link: 1 0x887f038
Fri Aug 2 16:50:13 2013 <0018> lapd_core.c:1781 lapd_send_i() called from line 1615
Segmentation fault (core dumped)
bsc_init.c probably complaining because the LAPD connection is closed,
but the OML context does not. Maybe this is the root cause of the
problem: if the OML context not disconnected with the LAPD connection,
it still listens on the OML timeslot and if something got received, it
tries to process it. But still: this is not how it should work. The
OML context is not closed, because we are waiting for the already
resetting BTS, then the OML lapd got restarted again (after the
RESET_TIMER expired). My opinion is that after we closed the lapd
connection, it should not reactivate itself, if data appears on the OML
TS.
BR,
Csaba
Not really, if I have a temporary subscriber coming onto the network, I
would like to be able just to use their IMEI instead of going through the
trouble of getting their IMSI.
T
hats a shame. Reading http://openbsc.osmocom.org/trac/wiki/osmo-nitb
it states;
"
We obtain the IMSI and IMEI of every LOCATION UPDATING REQUEST, and then if
neccessary create a new entry for the equipment as well as the subscribers
in the respective tables.
"
Is there a specific table that all rejected handsets go into or a mixture
of Equipment, EquipmentWatch, Meta and Subcriber?
Many thanks,
Is there a way to add subscribers by just using their IMEI, this is a lot
easier to obtain the the IMSI.
I can see there is and Equipment and EquipmentWatch table in hlr.sqlite in
the Osmo-NITB folder, but there is no Authorised field like in the
Subscribers table.
Many thanks,
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…
the gprs_llc_tx_ui() will call down to BSSGP/NS, which in turn will
call msgb_free() themselves in their error path, so the msgb is
already freed at that time.
As discussed on the mailing list quite some time ago, msgb ownership
policy/rules and implementation need to be more clearly defined, and
this definition adopted in the implementation.
Thanks to Holger for reproducing this.
---
openbsc/src/gprs/gprs_sndcp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/openbsc/src/gprs/gprs_sndcp.c b/openbsc/src/gprs/gprs_sndcp.c
index 853f8db..6564ffb 100644
--- a/openbsc/src/gprs/gprs_sndcp.c
+++ b/openbsc/src/gprs/gprs_sndcp.c
@@ -420,7 +420,8 @@ static int sndcp_send_ud_frag(struct sndcp_frag_state *fs)
rc = gprs_llc_tx_ui(fmsg, lle->sapi, 0, fs->mmcontext);
if (rc < 0) {
/* abort in case of error, do not advance frag_nr / next_byte */
- msgb_free(fmsg);
+ /* do not msgb_free() here, as the lower layer is doing
+ * that if an actual transmission error occurs */
return rc;
}
--
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)
hi Harald,
I'm running OpenBSC in BSC-only mode, where my A-interface gateway
substitutes an MSC (soft switch) to BSC. On the other side, A-interface
gateway has a legacy BSSAP/e1 connectivity.
OpenBSC configuration file is derived from
doc/examples/osmo-bsc/osmo-bsc.cfg
everything is fine with control over sccp/ip, but MGCP gateway port (2427)
is not binded to a public ip.
so, my questions are
- in which way media control is assumed to be performed?
- how this control is reflected in osmo-bsc.cfg
in fact, I'm expecting osmo-BSC to run exactly as the BSC from ip.access,
that establishes SCCP/ip link and accepts MGCP commands from a soft switch
Thank you,
Dmitri
