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)
Hi all,
I have received the following invitation from the FrOSCon team.
Please let me know if anyone is already intending to attend the
conference, or would be interested in getting together thre in a
devroom.
I'm personally not so sure since we already had the OsmoDevCon earlier
this year... but then, late August is almost half a year later ;)
------------
Hello OpenBSC Team,
we would like to invite you to take part in the seventh Free and Open
Source Software Conference (FrOSCon 2012).
FrOSCon is a two-day conference on Free Software and Open Source,
which takes place on August 25th/26th, 2012 at the University of
Applied Sciences Bonn-Rhein-Sieg, in St. Augustin near Bonn, Germany.
Main part of the conference is a comprehensive range of talks and
workshops. Furthermore, there is a large exhibition area, where
projects have the opportunity to present themselves and get in touch
with users and other developers. Moreover, we offer a few rooms for
Free Software projects to organize developer meetings or to present
their own program.
We would be pleased if your project would like to contribute to this
year's FrOSCon and thus support the communication and exchange within
the Open Source and Free Software community. Depending on the kind of
your participation, there is different information available to you.
To sign up for a booth, please visit
https://callforexhibitors.froscon.org and register your project.
Please feel free to contact us for any questions at
exhibitors(a)froscon.org <mailto:exhibitors@froscon.org>. The
registration for booths will be open until May 23rd.
If your project wants to sign up for a developer room, please write a
proposal to projects(a)froscon.org <mailto:projects@froscon.org>. The
proposal should contain a short summary (1-2 paragraphs) of what you
plan to do and which special requirements you have. Since the demand
for developer rooms usually exceeds the number of rooms we can offer,
we will choose the projects which look the most promising to us based
on the submitted proposals. If you have questions concerning the
developer rooms, feel free to contact projects(a)froscon.org
<mailto:projects@froscon.org>. The deadline for the submission of
developer room proposals is April 30th.
Additionally our Call for Papers already started, we are looking
forward to your submissions of talks and workshops. You can register
via http://cfp.froscon.org/. For further information concerning the
Call for Papers take a look at
http://www.froscon.de/en/program/call-for-papers/. The Call for Papers
will end on May 23rd, too.
We hope to meet you at FrOSCon in St. Augustin.
Kind regards,
The FrOSCon Team
-----------
--
- 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 dear osmocom folks,
I have been doing some bitrate throughput tests from different MS (i.e. phones
models) connected to a working osmo-nitb/sgsn/ggsn configuration (with a nanoBTS
DCS1800) and i get 15kbits/s maximum (tcp/udp transfer) with the gprs subnet nat-ed to a 100baseT
lan connected to a 2Mbits/s dsl line
The channel configuration is as follow in the osmo-nitb configuration file :
<file /etc/osmocom/bsc.conf>
(...)
nominal power 23
max_power_red 0
rsl e1 tei 0
timeslot 0
phys_chan_config CCCH+SDCCH4
! hopping enabled 0
timeslot 1
phys_chan_config TCH/F
! hopping enabled 0
timeslot 2
phys_chan_config TCH/F
! hopping enabled 0
timeslot 3
phys_chan_config TCH/F
! hopping enabled 0
timeslot 4
phys_chan_config TCH/F
! hopping enabled 0
timeslot 5
phys_chan_config TCH/F
! hopping enabled 0
timeslot 6
phys_chan_config TCH/F
! hopping enabled 0
timeslot 7
phys_chan_config PDCH
</file>
Should i change the channel configuration to get more bitrate ?
Should add more cells (bts?) to add more channels ?
my best, cheers.
Xavier.
Peter Suge wrote:
>Please send the pcap file as requested. It includes significant
>detail which is not shown in console messages. You can use tcpdump
>to create the file from the command line, or even wireshark.
Here is the pcap:
https://docs.google.com/open?id=0B1aXbMU98OahcWp3cVRRWEJBeHc
The phone cannot communicate any GPRS data after the message in packet
480 (sent upon power up), which is also when the console shows a
message like this below (not actual message from attached pcap):
<0012> gprs_bssgp.c:347 BSSGPTLLI=0x7d3b6971 Rx UPLINK-UNITDATA
<0013> gprs_llc.c:478 LLC SAPI=1C FCS=0x35b15fCMD=UI DATA
<0013> gprs_llc.c:742 LLC RX:unknown TLLI 0x7d3b6971, creating LLME on the fly
Others on this mailing list asked for the config files. Here is the
nanobts config, which follows the example on the instructions in the
wiki for GPRS, with the main differences being allowing all devices to
attach and I set the IP addresses. Also, I put the PDCH in the last
two timeslots.
https://docs.google.com/file/d/0B1aXbMU98OahcGFFWkRIcE54NDQ
Here is the SGSN config:
https://docs.google.com/open?id=0B1aXbMU98OaheVFqdUhYZWkwQzg
There are some strange things in the BCCH configuration in packet #240
of the pcap that don't match configuration files. For example, I have
set cell reselection hysteresis as shown in the openbsc.cfg to 4, but
the BCCH configuration packet #240 has the value of 2.
Let me know if you see anything, and I appreciate your feedback.
John
Hi,
I have an ipaccess nanobts model 165AU. I have followed the instructions
for GPRS on the OpenBSC with a fresh install of Ubuntu 11.10:
http://openbsc.osmocom.org/trac/wiki/OpenBSC_GPRS
By adding the IMSIs for two GPRS capable handsets to the database and
assigning extensions, the phones will attach and I can make calls between
the handsets.
However, there seems to be no functionality related to GPRS. A couple of
of different iPhones in GPRS field test mode won't pick up GPRS-related
parameters in "filed test mode", such as they won't see different values I
try for T3192 timer or DRC Timer Max. Note that I see changes I try for
these parameters (T3192 and DRC Timer Max) sent to the nanobts from the
wireshark packet captures. These same iPhones can make phone calls through
the nanoBTS/OpenBSC.
Probably, the most significant underlying issue is that I don't see the
SGSN IP address ever sent to the nanoBTS anywhere in the Wireshark packet
capture. It's clearly set in my configuration line "gprs nsvc 0 remote ip
192.168.XXX.YYY", and again I'm using an exact copy of the instructions
linked above. So, GPRS clearly won't work without the nanoBTS "knowing"
the SGSN. I do see the link between SGSN and GGSN, and the SGSN/GGSN
both "up", but no traffic of course between the nanoBTS and SGSN.
Note that I also did some searching and I saw one posting where the
configuration line "gprs mode gprs" should be "gprs mode egprs", but that
didn't make any difference. Does anyone have suggestions of what might be
wrong or what I should look at?
Thanks, John
Hi all!
This is the announcement for the 2nd incarnation of our bi-weekly
Osmocom Berlin meeting.
April 25, 7pm @ CCC Berlin, Marienstr. 11, 10113 Berlin
The schedule is as follows:
19:00 Introduction into the TETRA base station located @ CCCB
For quite some time, there is a full TETRA base station located
in the Berlin CCC, consisting of two base radios (BR), a site
controller (TSC), an auto-tuning cavity combiner and other
equipment. The talk will introduce the architecture of the
system and the current status of getting it running.
20:00 Presenting the CC32RS512 / towards an Osmocom Card OS
The CC32RS512 is a flash-based smart card controller to which
the documentation is available without NDA. This means that we
finally are able to implement a Smart Card OS (COS) as free
software.
20:30 Informal discussions
If you are interested to show up, feel free to do so. There is no
registration required. If the initial part is not interesting to you,
feel free to join us later at 20:30. The meeting is free as in "free
beer", despite no actual free beer being around ;)
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)
Dear group members,
(I would like to apologize if you got this message for the second
time, but last time I sent it to the wrong mail address and I am not
sure if the gnumonks mailing list is synchronized with this one,
osmocom, I am sorry if you get this mail for the second time!)
I would like to ask you a question regarding the timeouts and
initiating/allocating an SDCCH channel for a subscriber inside of the
GSM network. I am trying to modify some parts of OpenBSC
(/openbsc/src/libmsc/rrlp.c) and to implement the MS-based RRLP in
OpenBSC (to send assistance data in form of almanac, ephemeris, BTS
geolocation data and GPS reference time to the MS).
At the moment I use the silent sms to start an RRLP request (send RRLP
request + assistance data and then send the silent sms). But if it
takes too long to send the assistance data OpenBSC starts from the
beginning (send rrlp request + assistance data + sms again). I think
this is because OpenBSC waits for an ack from the MS for the silent
sms (which has not been sent) and therefore it's a timeout issue. As a
quick hack I have modified parts of the code and got the RRLP to work
(sent successfully these data and I got a position from the MS).
Just for the curious one, I commented out three lines just before the
return, in /openbsc/src/libmsc/gsm_04_11.c in the function,
gsm411_rx_rp_ack, the following lines:
//else
//gsm411_release_conn(trans->conn);
/* free the transaction here */
//trans_free(trans);
and I changed one timer value from 10 to 100, in
/openbsc/src/libbsc/bsc_rll.c in the function, rll_establish to:
osmo_timer_schedule(&rllr->timer, 100, 0);.
As I know what I did was wrong (since changing the timers and not
releasing the channel properly influences the whole system) but I just
did it for the purpose of testing and to see do I send correct data
and does the RRLP work at all.
I hope you can give me some hints and guides how to allocate a channel
for around 130 seconds and to send the RRLP assistance data within
that channel without doing the above tricks. Once everything works
properly I will provide the RRLP code.
Best regards,
Refik Hadzialic
Hi Patrick,
They come up on eBay now and again. You might want to keep an eye on there.
I paid around £150. I'm not sure if that's good or bad...
Best Regards,
Alex
On 04/04/2012 10:22, Patrick Klapper wrote:
> Hello,
>
> I am interested in buying a nanoBTS.
> The sales department of ip.access told me, that they only sell their products to mobile operators.
>
> Where can I buy an ip.access nanoBTS (GSM1800) and what's its price?
>
> Regards
>
> Patrick
To quote myself...
On Fri, Mar 30, 2012 at 12:00:42PM +0200, Harald Welte wrote:
> > I would probably be in favor of Wednesday
>
> Great, then we have already three people in favor of Wednesday (which
> would also work out fine for me).
I've now inquired with CCC Berlin, people there seem to be fine with a
bi-weekly meeting on wednesday. I told them that one CCCB member would
be present at every meeting. This would likely be me (unless I'm
travelling) so we have to see that somebody else (dexter, prom, roh,
zecke, ...) can fulfill that role during other meetings.
The first meeting thus will be next wednesday, April 11. I suggest we
meet at 7pm. A more official announcement will follow.
--
- 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)
