Hi list,
I just thought I had fixed gsm_7bit_decode_n(), since its API doc says
* \param length The length of the input sequence (in octets).
int gsm_7bit_decode_n([...], uint8_t length);
but the implementation is
int gsm_7bit_decode_n([...], uint8_t septet_l)
and indeed the length parameter is handled as septet length. So, logically, I
came up with this patch:
diff --git a/src/gsm/gsm_utils.c b/src/gsm/gsm_utils.c
index e8e452f..a9afc1a 100644
--- a/src/gsm/gsm_utils.c
+++ b/src/gsm/gsm_utils.c
@@ -184,8 +184,9 @@
return text - text_buf_begin;
}
-int gsm_7bit_decode_n(char *text, size_t n, const uint8_t *user_data, uint8_t septet_l)
+int gsm_7bit_decode_n(char *text, size_t n, const uint8_t *user_data, uint8_t octet_l)
{
+ uint8_t septet_l = ((uint16_t)octet_l * 8) / 7;
return gsm_7bit_decode_n_hdr(text, n, user_data, septet_l, 0);
}
(the cast to uint16_t makes 100% sure the calculation isn't truncated to
uint8_t after the *8 multiplication -- I picked this up while hacking on 8bit
microcontrollers. That truncation doesn't really happen on our 32bit/64bit
machines, but if it did, the length would effectively be limited to 255/8 == 31
characters.)
Then I noticed that callers actually do *8/7 before calling the function:
parse_process_uss_req():
num_chars = (uss_req_data[6] * 8) / 7;
/* Prevent a mobile-originated buffer-overrun! */
if (num_chars > MAX_LEN_USSD_STRING)
num_chars = MAX_LEN_USSD_STRING;
gsm_7bit_decode_n_ussd((char *)req->ussd_text,
sizeof(req->ussd_text),
&(uss_req_data[7]), num_chars);
(This is gsm_7bit_decode_n_ussd(), its API doc says "see gsm_7bit_decode_n()")
So we have the API talking about length "in octets" while the implementation
clearly employs septet length.
Fixing the implementation to match the API doc would break binary
compatibility. I should probably fix the API doc to match that weird
implementation, but it nags and hurts a little.
Any opinions?
~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: Holger Freyther, Harald Welte
Hi,
I am looking into building a very simple MNCC to SIP bridge to be used with the NITB (and later the CSCN). This will be based on what was learned from adding the RTP bridge which means the audio will not flow through the bridge (eventually later there will be a UDP proxy for NAT traversal)
The primary design points are:
* Being able to select TCH/F or TCH/H
* Decide on the codec very late
* Support for AMR parameters through MNCC
I just look at MO and MT Call establishment from a high-level point of view:
MO-Call:
* NITB will send the SETUP indication
* MNCC GW will do screening and decide if to proceed
* MNCC GW will make TCH/F or TCH/H decision and ask for a source IP, source port
* Based on bearer caps (to be handled by MNCC GW?) and TCH/F, TCH/H MNCC GW can offer a SDP file with multiple codecs to the PBX.
...
* PBX will decide on a codec (ringing or 200 connect)
* MNCC GW will ask NITB to reconfigure and audio will flow
* (TODO: check ringtone, check default, check codec change)
MT-Call:
* MNCC GW will be presented with a list of codecs already
* Depending on that TCH/F or TCH/H can/must be chosen (e.g. for AMR even the codec rate can be in the SDP file that decides which TCH/F or TCH/H to use)
* Can decide bearer caps once paging has succeeded and call is progressing
* Sets audio codec and waits for call to connect
Handover support:
* IP/port (and then SSRC and timestamp in RTP) will change
* MNCC GW could try SIP re-invite with changed parameters
* MMCC GW could hope PBX implements RTP annex and re-learns the connection
Do you have comments or remarks? The above will lead to a version update, probably a dedicated assignment command in MNCC, and separating socket creation and codec change. Anyone wants to have a go at that?
have a nice weekend
holger
Dear all,
IN-Berlin has confirmed the dates in April where we could book the
venue.
Can those eligible + interested in attending please quickly indicate
their preference at http://doodle.com/poll/if263cpxieavsqiq ?
Thanks!
Disclaimer: OsmoDevCon is an invitation-only event for developers with
proven history of contributing to any of the Osmocom projects. The fact
that there is a public poll about the scheduling of the event and/or
your participation in that poll does not mean a particular applicant is
invited.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
Dear all,
I've gone through the high-level list of change areas / projects from
Rel-4 through Rel-14 and collected a list of those parts that seemed
like they could be interesting from an Osmocom point of view.
In case you're curious and enjoy reading 3GPP docs as much as I do,
feel free to check out
http://projects.osmocom.org/projects/cellular-infrastructure/wiki/Interesti…
Some parts were just recently mentioned, like Extended Uplink TBF,
Network Assisted Cell Change, MNCC-SIP interface, Local Call Local
Switch. We also already knew about the "Real" A-over-IP specification
(different from the SCCPlite A interface that OsmoBSC implements), and
A5/4.
There's quite some other interesting bits and pieces, such as for
example the feasibility study on GSM/EDGE BTS power saving, where they
propose (it's not accepted yet) to reduce the transmit power on the
BCCH-carrying TRX at certain points in the time multiplex.
Enjoy,
Harald
--
- Harald Welte <hwelte(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 Directors: Holger Freyther, Harald Welte
Hi,
I'm having a trouble when using pySIM to change the authentication
algorithm in a USIM-SJS1 card. Basically I want disable the 3G authentication
on the card, and only use 2G authentication regardless of the network type.
Anyway, here's my procedure.
In the beginning, I didn't realize there's a zecke/tmp2 branch. So i
modified the the cards.py by myself. I added
data, sw = self._scc.update_binary('6F00', '03')
in the this line
http://cgit.osmocom.org/pysim/tree/pySim/cards.py?h=master#n461
I learned the values '6F00' and '03' from this osmocom webpage
<https://openbsc.osmocom.org/trac/wiki/sysmoUSIM-SJS1>.
One thing to mention that is I also commented out the self._scc.verify_chv()
and update KI/IMSI statements in above. Because it always fails in the
self._scc.verify_chv() step (apdu response 69xx), though I provided the
adm-1 key in the CLI.
After it's done, unfortunately I found that when use ./pySim-read.py to
read SIM again, it fails with apdu response 6b00. Also, the attempt to
updating authentication algorithm didn't work when test in the phone.
Did I already mess up this SIM card at this point?
Then, I found there's a zecke/tmp2 branch. Tried it. Still not working
either in reading (apdu response 6b00); or writing (still ails
in self._scc.verify_chv() with apdu response 6983)
Please give suggestion on what I should do.
Thank you.
Hi all,
several years ago at an OsmoDevCon, we decided to rename the PCU
mailinglist into osmocom-net-grps to expand it to cover all parts of the
GPRS/packet-switched systm, and then continue to discuss
circuit-switched stuff in openbsc.
Over the years it seems the list was more and more forgotten, and all
patches were posted here. I would like to propose to move all GPRS / PS
related discussion to the osmo-net-gprs mailing list again.
Now you can argue that osmo-sgsn, osmo-gbproxy and gtphub are all built
inside the openbsc repository. The presence of osmo-sgsn, osmo-gbproxy
etc. inside one single OpenBSC git reposiory is a historic legacy, and
one that I'm not very proud of. Rather than having more of that
overlap/confusion we should probably aim for less and more separation.
However, let's wait for the Iu-CS / Iu-PS integration and osmo-cscn
(nitb without integrated bsc) first, and then look at how to lay out the
source code repositories.
Meanwhile, let's please aim at discussing GPRS related topics + patches
(particularly PCU bits) on the osmocom-net-gprs list. Thanks for your
attention!
I think there are a lot of people on the openbsc lists who are primarily
interested in OsmoNITB and who are not neccessarily interested in the
low-level-bits of the GPRS/EGPRS RLC/MAC layers ....
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)
This is just to say that all my currently waiting patch sets have been
merged to the respective master branches, after due nitpicking by Holger
in person (thanks!) with various style/simplicity modifications applied.
(The one still open is the int/void* thing, not intended as a patch anyway but
more as a question.)
So the road is clear now for configuring osmo-nitb with its entire set of
own IP addresses, and as a side effect various other osmo-programs also
have configurable telnet-VTY, Ctrl-interface and Abis addresses now.
To summarize the final result:
(1) Abis/IP
e1_input
ipa bind 10.9.8.7
(2) telnet VTY
line vty
bind 10.9.8.7
(3) ctrl interface
ctrl
bind 10.9.8.7
(4) MNCC unix domain socket
-M /path/to/socket/file
(5) SMPP SMSC
smpp
local-tcp-ip 10.9.8.7 2775
Is this worth a Wiki entry?
~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: Holger Freyther, Harald Welte
Hi all,
new year, new approaches. In December I was tasked to think about a
real SMSC with SMPP input and SS7 output (or SMPP in the future) and
I wrote down my ideas[1] about data storage, approach, how to achieve
scaling. What is missing fail-over but there are some ideas for this
as well.
The implementation will be done using Pharo and at least the first
data storage will use mongodb >= 3.2. In the past my Pharo work has not
been hosted in git but for this project it will change and maybe it
creates some more visibility, historically documentation and debian
packages were not too visible but that will be different this time
as well.
If you are interested in specification, Smalltalk, testing, load testing,
SS7 or such please join me in the development.
happy hacking
holger
[1] https://github.com/zecke/osmo-smsc/blob/master/README.asciidoc it
will move to git.osmocom.org but I just wanted to have online asciidoc
rendering.
