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)
