> I don't understand. This callback will be called with data you need to
write
> to the network. In case of MTP Level3 you will need to wrap that around
the
> msgb you got.
I means: is the interaction with mtp3 layer implemented (is sending sccp
data by mtp3 implemented by the library?)?
Also, what about the reception of data from mtp3 layer. is that implemented
in the sccp lib.
I am asking these questions because I see the code of mtp3 in the lib but no
significant call is present in the sccp part of the lib.
Thank you for your help.
Hello everyone,
I've just finnished writing together a small web interface for the OpenBSC
HLR. It allows you to modify various parameters in the database and also
provides a set of functions to modify the HLR or sending SMSes in your own
scripts.
The project is still very alpha but it seems to work reasonably good. Feel
free to give any feedback!
Screenshots and source code is available on my website:
https://stormhub.org/simplehlr/
--
*Best regards,
Peter Caprioli*
I have some questions:
1) When I start bsc_hack bsc_init.c first establishes OML link and
initializes the bts then it establishes RSL link and bts starts
broadcasting. However, it takes so much time to start the bts. Instead of
this I want to do the following: it establishes OML link at the beginning
and only once, then when i want to start broadcasting it establishes just
the RSL link and bts will start faster since i don't have to wait for OML
link. What should be done for this?
2) If i send one or two word messages from telnet interface it is okay. But
if i send a longer message the phone could't receive the end of the message
correctly(last words may be incomplete). Did any one encounter with this
problem? What is wrong with me?
3) Could I send SMS in which extension of the sender is text not integer.
For example, i want to send an information SMS that this is a test network.
For this purpose i want to send an SMS from 'OpenBSC'. I set the extension
of the first subscriber in database as text and tried to send the SMS but
SMS wasn't delivered. What should i do?
4) Can i add SMS externally to SMS table of database?
Thanks.
Jason
As reported in ticket #55 SGSN can crash due to double free-ing. You
can replace 'can' by 'will' in that last phrase. I had a sift through
the code and tried to solve this by removing the free in gprs_ns.c.
Whenever the calling function created the msgb-struct, I have made the
function free it after its use. If the function got the msgb from a
calling function, there will not be a free (hoping that will be done
on the higher level).
HTH/F
Hi all!
Thanks to a generous donor, we have received a couple of OT-290 trace
phones. These are commercial products intended for taking L2/L3 air
interface traces. If you've read any of the fabulous GSM papers by
Prof. Dr.-Ing. Joachim Goeller: The OT-phones is what he used to
generate all his traces.
The majority of what those phones can do is now also possible with
OsmocomBB.
However, OT-290 support GPRS tracing/testing - for CS-1 throguh CS-4.
I would be willing to give away one of the two remaining OT-290 (for
free) to anyone who would in return commit to developing a GSMTAP
interface for it.
The message format on the serial UART between phone and PC is documented
(PDF documentation by Sagem included with the phones). So based on this
documentation and an OT-290 phone, it should be possible to write a
small command-line program that receives the GSM/GPRS messages from the
OT-290 and sends them via GSMTAP into wireshark.
The result would then be similar to what
http://cgit.osmocom.org/cgit/dct3-gsmtap/ is for DCT-3 phones.
If you're interested, please respond to this message. Please don't
apply for the phone if you are not able to find the required time and
interest for actually doing the GSMTAP integration.
Thanks!
--
- 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)
Holger wrote:
> wanted to avoid this issue is that whoever transmits needs to select the
> llme/lle. I think my code set old_tlli to the foreign or such but I dropped it
> (and can't remember why it wasn't needed anymore).
Been there, tried that. It wasn't so much that is wasn't needed, but elsewhere
in the code old_tlli (and especially the fact if it is 0xffffffff or
not) is used to (re)set
some stuff.
> This will not be the last issue you will experience with GPRS. Both the
> nanoBTSs implementation and our SGSN are not very stable.
Well... only 7 hours of Qday to go ;-)
> Some of the known GPRS issues include:
>
> - http://openbsc.osmocom.org/trac/ticket/55 (crash)
I solved that one
> - http://openbsc.osmocom.org/trac/ticket/44 (correctness)
> - http://openbsc.osmocom.org/trac/ticket/43 (leak)
Will check these.
> There is also the 'santos' branch of someone that forked our code and has
> done a bit of bugfixing.
Ah ok. I'll look into that. Might be of use during the last couple of hours
HTH/F
I might be horribly wrong, but there is something I did not grasp in
gprs_llc.c. So I altered it, but since I am not sure I share it here...
Function 'gprs_llc_tx_ui' uses function 'lle_by_tlli_sapi' to retrieve an
lle based on a tlli/sapi combination. To do the lookup, the supplied tlli
is 'localized' (tlli_foreign2local). If this does not result in a succesful
find, function 'llme_alloc' is used to "create an LLME on the fly". However
'llme_alloc' does not localize the tlli. So every next search for the lle
fails.
For this I created this patch:
--- openbsc/openbsc/src/gprs/gprs_llc.c 2012-04-30 15:42:58.958823325 +0200
+++ ../openbsc/openbsc/openbsc/src/gprs/gprs_llc.c 2012-04-30
10:54:11.291836887 +0200
@@ -157,7 +160,8 @@
if (!llme)
return NULL;
- llme->tlli = tlli;
+ llme->tlli = tlli_foreign2local(tlli);
llme->old_tlli = 0xffffffff;
llme->state = GPRS_LLMS_UNASSIGNED;
This seems to have solved the problem (unable to get an IP link
operational), but I am not sure if this was the correct way to handle this,
so please feel free to comment.
HTH/F
Goodafternoon,
This is just a quick email to let you know that we are currently (as in:
today) using OpenBSC to offer a GPRS service to some equipment during
Queensday. For those of you that do not know this: Queensday is a Dutch
festivity where the birthday of the Queen is celebrated. It attracts a mass
of people and under that condition no (normal) mobile network will stay
operational. Since we have some equipment running, we decided to try out
creating our own mobile network. For this we installed several ip.access
nanoBTSes and use OpenBSC as central software.
Unfortunately this is not a complete success. Although we tested it and
those tests gave us confidence, we now experience a lot of connection
losses. Several nanoBTS'es bootstrap quite regularly, and almost all
connected devices are unreachable after several minutes (some later than
others). Only restarting OmniBSC quite often seems to bring back some life.
Up until now I have been unable to find out why things are wrong.
While preparing for this use of OpenBSC I came accross some things that
might be worthwhile to share with you. I'll do that in separate messages,
so contents does not get clobbered. Please allow me to thank you all for
the great work you have done in this set of software. I hope some of my
experiences will help you pushing this forward.
Kind regards,
Frank
Please be aware of a problem in ESXi in which the checksum of UDP packets
is wrongly calculated. This will cause the UDP traffic from the SGSN to the
BTS'es (vice versa) to fail. It can take quite a while to figure this out
(well... to be honest all it takes is a good look at the extended tcpdump
output, but hey).
If you experience problems setting up GPRS (symptom: NSVC remains ALIVE
BLOCKED), try this command:
ethtool --offload eth0 rx off tx off gso off
(with eth0 the correct interface, or better: for all interfaces).
This works under CentOS (tested) and Debian/Ubuntu (read about it).
HTH/F
Hi jolly,
I'm seeing some strange behavior on the BTS side LAPDm code:
When we get a SABM on SAPI=3 from the phone, this gets translated into
an RSL_RLL_EST_IND. However, as there commonly is no l3 payload in a
SAPI=3 SABM, the L3_INFO IE should not be present in that message.
Instead of a RLL_EST_IND without L3_INFO IE, we get a L3_INFO IE that
consists only of 1 byte tag and 2 byte length, but not payload. The
Length value seems non-deterministic, i.e. like uninitialized memory.
I've tried to resolve this, and I suspect it is somehow related to the
DUMMY msgb that the lapd code allocates (why is it doing that?) in
send_dl_simple().
The code path should be:
lapd_rx_u()
if (length == 0) send_dl_simple()
send_rslms_dlsap()
here we check for (!dp->oph.msg), but since there is a dummy msgb,
we probably run into the send_rslms_rll_l3() case instead of
send_rll_simple().
What do you think is the best way to resolve this?
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)
