HI.
A little heads up: uhd version in jenkins building osmo-trx should be
updated to 3.9.0 - this would allow gerrit #1117 to be properly verified
by jenkins.
--
Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
Hi,
I further implemented the base of the virtual layer with the purpose
of replacing the um-air interface with a multicast-socket solution.
This has been started by Harald Welte some time ago in the Osmobts -
laforge/virt-bts branch.
As I was not really confident enough to create an official new branch
before someone had a look on what I did, so I developed in copies of
the osmocom-bb and osmo-bts projects on my github-page
(https://github.com/BastusIII/osmocom-bb-virt/tree/stumpf/virt-um and
https://github.com/BastusIII/osmo-bts-virt/tree/stumpf/virt-bts).
If someone finds to time to have a look into them (structure, path,
implementation) and give me feedback about it, I would be glad :).
Please use the following config files that i have tested:
- https://github.com/BastusIII/osmocom-config-files/blob/master/openbsc-virtu…
- https://github.com/BastusIII/osmocom-config-files/blob/master/osmobts-virtu…
- https://github.com/BastusIII/osmocom-config-files/blob/master/osmocom-bb-mo…
What works:
BTS:
- downlink over gsmtap and a multicast socket
- OML and RSL on abis properly established and seems to work
- virtual-um connection establishment
Osmocom-bb:
- virtual-um -- l23 app connection establishment (bridging osmocon,
no serial link needed)
- BCCH downlink handling and forwarding to l23 app
- handling of some l1ctl requests from l23 (e.g. power management had
to be mocked, so l23 gets a response and is satisfied)
What not:
BTS:
- missing uplink handling
Osmocom-bb
- missing uplink routines (RACH, TCH, dedicated channels)
- handlers for l23 requests only partially implemented (missing TCH, RACH, ...
I a currently a bit overwhelmed by the mass of messages exchanged
between l23-app (used mobile, btw.) and the virtual-um and hanging
because mobile gets a sync timeout.
I am looking forward to hear from you :).
Sebastian Stumpf
Dear all,
as osmo-trx has recently introduced a dependency on a super-recent
version of UHD (as opposed to what regular stable distributions ship),
the nightly debian builds are broken for both Debian 8.0 and Ubuntu
14.04:
https://build.opensuse.org/package/show/network:osmocom:nightly/osmo-trx
I would like to ask the osmo-trx folks to consider
a) adding the uhd version dependencly to the debian rules
b) submitting a suitable uhd package version that can be build in the
osmoco nightly OBS repository
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)
Good Evening,
With the recent commits for the OM2000 protocol, I figured it was time
to dust off the RBS2308 and see what would happen. I am using the latest
version of DAHDI, with a TE122P T1 card. All osmocom software was pulled
yesterday and installed successfully on a machine running Debian Stable.
When OpenBSC starts, all appears normal with regards to bringing the BTS
up until the timeslots for the first TRX are being configured. When the
timeslots are configured, a protocol error is given for each. If I
change trx0/ts0 from the default of CCCH+SDCCH4 to CCCH, that timeslot
is successfully brought up, and the BTS transmits. Other configurations
(TCH/F, TCH/F, PDCH, SDCCH8, TCH/F_TCH/H_PDCH) on timeslots 1-7 give the
same protocol error.
I have attached my openbsc.cfg, the output from the OpenBSC console, a
pcap of the failed startup, and my DAHDI configuration. If they do not
come through the list server, they are also available at:
http://cleb.org/RBS/
Thanks,
Caleb
By random, I looked at an fd leak complained about by coverity in
osmo_stream_srv_fd_cb() and came up with https://gerrit.osmocom.org/1320
Now I wanted to at least run it once to make sure I didn't break anything, but
I'm unsure in figuring out how it is used.
There are two Iu related callers: osmo-iuh's hnbgw.c and libosmo-sccp's sua.c.
And I find libosmo-netif/src/channel/abis/ipa_stream_server.c, called in
libosmo-netif/src/channel.c by osmo_chan_init() and osmo_chan_create(). But it
seems no-one is ever calling these, except for examples in libosmo-netif.
Am I right to conclude that there's some 2G / Abis / ip.access related code in
libosmo-netif but we're not actually using it in openbsc, and that the only
"real" osmo_stream_srv_* callers are 3G/Iu related?
~N
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Harald Welte
pleaes always make sure you send your responses to the mailing list,
never by private mail to individual developer s only
On Mon, Nov 28, 2016 at 07:52:39AM +0800, 韩明君 wrote:
> when i use the newest version of git tag 3G_2016_09 for compile I got lots of
> make error(;′⌒`) so switch to the old version
if you want anyone to help you, you need to include the exact error
messages (copy+paste) in your message to the mailing list.
> Anad another question is where may I found the nightly package,and download the *.deb file
It is really very simple. Go to osmocom.org and search for 'nigthly'.
Then you will find the link to
http://osmocom.org/projects/cellular-infrastructure/wiki/Nightly_Builds
--
- 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)
hello everyone ,first thanks for yours look at this email ...
i work under ubuntu 14.04 and with the doc of http://osmocom.org/projects/openbsc/wiki/Building_OpenBSC
now i only can do make install and success with git version of on-waves/0.3 (openbsc) and success found the executable file
drwxr-xr-x 2 root root 4096 11月 27 15:42 ./
drwxr-xr-x 11 root root 4096 11月 13 21:46 ../
-rwxr-xr-x 1 root root 551571 11月 27 15:42 bs11_config*
-rwxr-xr-x 1 root root 1877782 11月 27 15:42 bsc_hack*
-rwxr-xr-x 1 root root 528464 11月 27 15:42 bsc_mgcp*
-rwxr-xr-x 1 root root 1547559 11月 27 15:42 bsc_msc_ip*
-rwxr-xr-x 1 root root 967960 11月 27 15:42 bsc_nat*
-rwxr-xr-x 1 root root 1359089 11月 27 15:42 ipaccess-config*
-rwxr-xr-x 1 root root 37451 11月 27 15:42 ipaccess-find*
-rwxr-xr-x 1 root root 25066 11月 27 15:42 isdnsync*
but as the README under openbsc this version don't work well with ip based BTS
Hi all,
I'm looking at USSD message generation in openbsc, and would like to move a
bit of msg generation to libosmocore.
However, in libosmocore's gsm0480.c I already find an implementation that seems
to do the same, yet with some differences I'm not sure how to deal with.
The function originally in openbsc:
gsm0480_send_releaseComplete()
On the iu branch, I've moved the msg generation to
gsm0480_gen_releaseComplete()
This should rather go to libosmocore.
There I already find
gsm0480_create_ussd_resp()
The openbsc variants are rather shorter. Is it incomplete/incorrect?? Is the
libosmocore gsm0480_create_ussd_resp() just bloat for this case??
For convenience, let me paste the code:
openbsc's Release Complete, very lean:
struct msgb *gsm0480_gen_releaseComplete(void)
{
struct msgb *msg;
msg = gsm48_msgb_alloc_name("GSM 04.08 USSD REL COMPL");
if (!msg)
return NULL;
gsm0480_l3hdr_push(msg, GSM48_PDISC_NC_SS,
GSM0480_MTYPE_RELEASE_COMPLETE);
return msg;
}
Note that the above does not set a direction flag nor trans_id in the
proto_discr, like libosmocore's gsm0480_create_ussd_resp() does; neither do I
understand the purpose of all the constant "code/id" TLs and wrapping:
struct msgb *gsm0480_create_ussd_resp(uint8_t invoke_id, uint8_t trans_id, const char *text)
{
struct msgb *msg;
uint8_t *ptr8;
int response_len;
msg = msgb_alloc_headroom(1024, 128, "GSM 04.80");
if (!msg)
return NULL;
/* First put the payload text into the message */
ptr8 = msgb_put(msg, 0);
gsm_7bit_encode_n_ussd(ptr8, msgb_tailroom(msg), text, &response_len);
msgb_put(msg, response_len);
/* Then wrap it as an Octet String */
msgb_wrap_with_TL(msg, ASN1_OCTET_STRING_TAG);
/* Pre-pend the DCS octet string */
msgb_push_TLV1(msg, ASN1_OCTET_STRING_TAG, 0x0F);
/* Then wrap these as a Sequence */
msgb_wrap_with_TL(msg, GSM_0480_SEQUENCE_TAG);
/* Pre-pend the operation code */
msgb_push_TLV1(msg, GSM0480_OPERATION_CODE,
GSM0480_OP_CODE_PROCESS_USS_REQ);
/* Wrap the operation code and IA5 string as a sequence */
msgb_wrap_with_TL(msg, GSM_0480_SEQUENCE_TAG);
/* Pre-pend the invoke ID */
msgb_push_TLV1(msg, GSM0480_COMPIDTAG_INVOKE_ID, invoke_id);
/* Wrap this up as a Return Result component */
msgb_wrap_with_TL(msg, GSM0480_CTYPE_RETURN_RESULT);
/* Wrap the component in a Facility message */
msgb_wrap_with_TL(msg, GSM0480_IE_FACILITY);
/* And finally pre-pend the L3 header */
gsm0480_l3hdr_push(msg,
GSM48_PDISC_NC_SS | trans_id
| (1<<7) /* TI direction = 1 */,
GSM0480_MTYPE_RELEASE_COMPLETE);
return msg;
}
Thanks for any insights!
~N
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Harald Welte
On Thu, Nov 24, 2016 at 12:01:08PM -0800, scan-admin(a)coverity.com wrote:
> ________________________________________________________________________________________________________
> *** CID 149097: Null pointer dereferences (FORWARD_NULL)
> /source-Osmocom/openbsc/openbsc/src/gprs/gprs_sndcp_comp.c: 67 in gprs_sndcp_comp_create()
> 61 comp_field->rfc2507_params->nsapi,
> 62 sizeof(comp_entity->nsapi));
> 63 } else if (comp_field->rohc_params) {
> 64 comp_entity->nsapi_len = comp_field->rohc_params->nsapi_len;
> 65 memcpy(comp_entity->nsapi, comp_field->rohc_params->nsapi,
> 66 sizeof(comp_entity->nsapi));
> >>> CID 149097: Null pointer dereferences (FORWARD_NULL)
> >>> Comparing "comp_field->v42bis_params" to null implies that "comp_field->v42bis_params" might be null.
The point of this complaint:
- gprs_sndcp_comp.c:67 implies that v42bis_params might be NULL
- on line 104 we call gprs_sndcp_dcomp_init()
- then this function (gprs_sndcp_dcomp.c near 88) dereferences
comp_field->v42bis_params without checking for NULL (instead relies on
comp_entity->algo == V42BIS)
I think I'd add an OSMO_ASSERT(comp_field->v42bis_params) in
gprs_sndcp_dcomp_init(). pmaier?
~N
Dear Harald,
Just wanted to confirm that a long outstanding crash is now fixed by your patch:
http://cgit.osmocom.org/libosmocore/commit/?id=f92e44c5399d8914aad58bd2c740…
After applying it, the nasty hack I used is not needed anymore, and the BTS-es are coming up just fine, all services are working correctly.
Will update the Nokia Site specific part of the wiki with this new information.
Thanks!
Csaba
Hello,
My name is Zydrunas Tamosevicius. I work for Lime on Myriad-RF and would like to ask to have a new "myriadrf" branch set up and access in osmo-trx git repository. We want to be able to work on adding support for Myriad-RF hardware.
The intention is to have these changes merged into master after we get it working on our branch. Is there any guidelines we have to follow?
Thank you in advance!
--
Best regards,
Zydrunas Tamosevicius
Senior IC Design Engineer (Digital)
Lime Microsystems
z.tamosevicius(a)limemicro.com
All,
Does there exist a document describing to which port the callagent (MSC)
has to connect to, how and where the CIC to RTP IP/port mapping table is
defined etc?
Regards,
Kristian
--
*Kristian Martens*
Software Engineer
Mobile: +49 160 1024262
Office: +49 30 65218529
/
ng4T GmbH
Siemensdamm 50
13629 Berlin
Germany
www.ng4t.com <http://www.ng4t.com>
/
Berlin-Charlottenburg, HRB 123546
Geschäftsführer Dr. Andreas Kallmann
All,
I have seen that it is planned to implement the full AoIP stack for a
standalone OpenBSC. Do have any idea by when this feature could be ready
to use?
Best regards,
Kris
Dear Team,
I am trying to find out KI Value of Anristu MT8820C Test SIm
Card using Pysim Software.
I am using Identiv uTrust 2900 R Smart Card Reader and Identiv
SCR35xx USB Smart Card Reader.
When I put *./pySim-read.py -p 0 *in the terminal it shows the
following error
*.*
Please help me to proceed further.
[image: Inline image 1]
Thanks and Regards....
Rajasekar
Hello All,
We are testing Dynamic TCH allocation. In the latest BSC ( commit version 87ef68eb33d463d8aad1511a272cbdb779f1ba19) it is observed that CS call is not working with TCH/F_PDCH channel configuration. Please note that if PS call is attempted in TCH/F_PDCH channel then it works fine.
When Dynamic TCH tested with the old BSC commit version (7bc6986f6babdaf5f2436dae2f603ae5823aa7b4) then CS call worked fine with TCH/F_PDCH channel.
Please let us know if it is known issue.
Thanks and Regards,
Mrinal
Dear Raul,
In 2012 the Osmocom OpenBSC project started to use your libsmpp34 in
order to add SMPP capabilities to our GSM Netwrok In The Box (NITB).
As there was no source code repository (svn, git. ...) of your library
around at the time, we imported the latest version you had released
(1.10) into a git repository at http://git.osmocom.org/libsmpp34/
Ever since we have been chcecking your sourceforge project occasionally
to see if you had made any further releases, in order to re-synchronize
them. Ther hasn't been any release ever since.
Meanwhile, various (small) improvements have been happening in our git
repository, but those changes are of course not visible to the new user
who is ending up on your sourceforge.net project page.
In order to avoid further confusion to the user, I would like to ask
your input on how we should proceed.
* do you still have plans for this library?
* do you want to run a git repo on sf.net and merge our contributions?
* would you consider designating the git.osmocom.org server as the
official source code repository, maybe even moving other content from
sf.net to https://osmocom.org/projects/libsmpp34
I would appreciate if you could at least put a notice on sf.net
indicating that there is a more actively maintained fork of your library
available at the above URLS.
Let me know if there is something we can do to help, or if you have any
other comments.
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)
So far the state of IuCS aka 3G voice is such that we will not merge the branch
to master unless we have a proper A-interface.
But come to think of it, it would technically be possible to split the code not
by git branches, but rather by the --enable-iu configure switch. In that case
openbsc master would contain all IuCS code, and if compiled with --enable-iu,
compile time switches would disable osmo-nitb, enable osmo-cscn and (currently)
destroy 2G due to lack of an A-interface implementation.
The benefit would be simply to not have a separate branch, making for easier 3G
build instructions and possibly reducing rebase merge conflicts; developers
could adjust the 3G code paths along with their 2G patches.
It's just an idea that came to mind... In the end it's just a kind of "fake"
merge, so not sure whether it's worth the effort.
Any thoughts?
~N
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Harald Welte
Hi all,
for a bit of bikeshed fun on the side, I'd like to ask your opinions on a good
name.
The background: we're in the process of separating libmsc from libbsc. Both use
the structs gsm_network and gsm_subscriber_connection, and both of these
structs contain elements that are used only by libbsc or only by libmsc,
besides the elements that are used by both. So at some point I will "split"
both of these in two, to have a BSC and an MSC version thereof.
How should we name them?
struct gsm_network
(note, if there is a common part, that could still be named 'gsm_network')
--> bsc_network / msc_network
looks familiar but the meaning of the name is lost
--> gsm_bsc / gsm_msc
--> osmo_bsc / osmo_msc
To me these would be the best and the names are still available, but there
are header files named like this and the osmo-bsc binary also has a very
similar name. I think I would go for these anyway.
+1
--> osmo_gsm_bsc / osmo_gsm_msc
As alternative, but the gsm is a bit out of place (particularly in the
light of a UMTS MSC).
struct gsm_subscriber_connection
--> bsc_subscriber_connection / msc_subscriber_connection
but we could use the opportunity to shorten the name
--> bsc_subscr_conn / msc_subscr_conn
I like these best; but add osmo?
+1
--> osmo_bsc_subscr_conn / osmo_msc_subscr_conn
almost the old length.
Happy shedding, "+1" comments and/or opinions welcome
~Neels
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Harald Welte
Dear all,
I have just moved the Osmocom GSUP HLR code from the really unrelated
ancient osmo-auc.git repository into its own osmo-hlr.git repository.
The GSUP HLR is a stand-alone HLR for SIM and USIM based subscribers
which exposes the GSUP protocol towards its users. Currently in
openbsc master, there is OsmoSGSN which supports this protocol.
There is ongoing work to remove the HLR from OsmoNITB and make it access
the GSUP HLR asynchronously. I originally intended to complete this
in summer this year,but was constantly delayed due to various other
tasks :/
Neels is now coming to the rescue and is in charge of moving this ahead
to get it ready to merge.
The osmo-gsup-hlr is still very simplistic. It's a single-threaded
architecture and uses only sqlite3 tables as back-end. It is suitable
for installations of the scale that OsmoNITB was able to handle. It
also lacks various features like fine-grained control of subscribed
services (like supplementary services). The most important goal for
osmo-gsup-hlr is to be a replacement for the HLR code we'r removing from
good old OsmoNITB. It is *not* supposed to be a fully-featured GSM HLR.
One of the advantages of having the GSUP protocol for both CS and PS
side is that there could be other, more scalable/powerful
implementations of the HLR that can just be swapped in.
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)
Hi,
I am using osmo-nitb + osmo-sip-connector and nanoBTS to establish a per to
peer call. I am using:
osmocom-nitb 0.15.1.20161024
osmo-sip-connector 1.20161024
While in call, I hear an annoying background noise while not talking. The
noise disappears when someone speaks.
Any idea what might be causing this and how this can be fixed?
Thanks,
Stefan
Hi All,
We are trying to configure Multi carrier [ 2 or more ARFCN working in
parallel with 1 TRX] with B200 board.
If anyone has done it ,please share working config file and executing
command for BTS and TRX.
Thanks in advance !
--
Thanks & Regards
Dhananjay
Hi,
Is there a function in OpenBSC that can help in estimating the diastase of the connected phone ? For example, something that gives the value of the power received by the phone from the BTS and the power received by the BTS from the phone (during paging or active call).
best regards,
HI.
Pardon the cross-posting, I'm not sure where this question really belongs.
I've been trying to wrap my head around how PDTCH/PACCH/PTCCH activation
works. In osmo-bts-sysmo/oml.c there is pdtch_sapis[] which defines what
got to be activated both in DL and UL directions. Right now it's PDTCH
(UL & DL), PTCCH (DL) and PRACH. Note that PACCH (DL) and PTCCH (UL) are
commented out.
Yet I see code dealing with PACCH in osmo-pcu and corresponding log
messages.
So the question is - how does this works? The PACCH seems to be used so
it's somehow activated but apparently not the same way as PDTCH.
--
Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
Hi.
In sysmobts we use ugly hack to auto-activate BCCH/CCCH on TS0 via
opstart_compl(). How does channel activation looks like for osmo-bts-trx?
On a related note: how do we decide on number of AGCH? In case of
sysmobts it's communicated to L1 in agch.u8NbrOfAgch via lch_par. What
would be equivalent for osmo-bts-trx?
--
Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte