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