Hi!
With the help of graphviz, I have written a small perl-based tool that
allows you to generate ladder diagrams. It can be found at
git://git.osmocom.org/gen_ladder.git
For your reference, I'm attaching a sample input and output file.
The bent/curved arrows are a result of graphviz trying to indicate
that the message is between e.g. MS and MSC and 'bypasses' BTS and BSC.
I'm still waiting for somebody with more graphviz skills to make this an
option.
Hope this is useful for some of you...
--
- 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!
Collin Mulliner, Tobias Engel and myself have been meeting yesterday to
discuss a generic application interface for OpenBSC.
They are both doing security analysis and want to achieve a clean way
how an external application can get access to a more or less transparent
communication channel to the phone.
The purpose of this is to be able to send intentionally malformed
packets to the mobile phone GSM stack at various different levels within
the stack.
As of now, they have both hacked some custom code into openbsc that gets
them half way where they want to be - but not quite all the way.
The requirements can be summarized as follows:
1) Ability to establish a SDCCH or TCH channel by paging the phone
As of now, the 'silent call' feature from the VTY already does this.
2) Ability to send arbitrary layer3 protocol messages to the phone
Adding this is relatively easy (use rsl_sendmsg on the lchan from the
silent call)
3) Ability to receive responses from the phone, as well as error
conditions such as 'readio link failure'. We don't have a solution
for this yet, and we also have no clean way to identify what might
be a response from the phone to the external app, and what might
be a message from the phone to the normal network code in OpenBSC
4) Ability to selectively disable partial protocol handling in
OpenBSC. Let's say you want to play with the mobile phone call
control implementation. In this case, you want to make sure all CC
related messages go from/to the external program and not from the
regular OpenBSC network code.
So what I've been thinking of as a solution to the problem:
* store a bypass_flags bitmask related to the subscriber structure,
where we indicate values such as BYPASS_RR, BYPASS_MM, BYPASS_CC,
BYPASS_SAPI3.
* if we process an incoming message from the MS in gsm0408_rcvmsg(),
we check if a bypass flag matching the message is found. If yes,
forward the message to the external program
* if we want to send a message from our own protocol stack to the MS,
we check if a bypass flag matching the message is found. If yes,
we drop the message that we were about to send.
* any messages received from the application will be forwarded to the MS
The application interface protocol will likely have a close resemblance
to RSL RLL. We need to exchange the following primitives with the
application, like:
* ESTABLISH REQUEST -- app requests a channel be established to MS (by IMSI)
* ESTABLISH CONFIRM -- network confirms a channel has been established
* ESTABLISH INDICATION -- network tells app connection was made by MS
* [UNIT] DATA REQUEST -- app requests data to be sent to MS
* [UNIT] DATA INDICATION -- network indicates data was received from MS
* ERROR INDICATION -- network tells app something went wrong
* RELEASE REQUEST -- app asks network to release channel
* RELEASE CONFIRM -- net tells app that channel was released (as rqd)
* RELEASE INDICATION -- net tells app that channel was released (by MS)
The channel_number of RSL (indicating on-air timeslot) doesn't make much
sense in this context, of course.
The link_identifier on the other hand is great as it allows the app to
indicate SDCCH/FACCH or SACCH as well as the SAPI.
The actual RSL-like protocol would be encapsulated by UDP and available
on a socket of the MSC.
What do you think?
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)
Hi all!
This subject came to my attention again recently: Why not relicense
OpenBSC under AGPLv3?
Right now we are licensing under GPLv2+ (v2 or any later version). However,
if an operator was to make lots of private modifications and then operate
it on his own network, there would be no distribution and thus no need
for him to release his modified versions of the source code.
This may sound a bit strange to those who have been with the project
since its early days. But we are reaching production quality now, and
we already have the first number of production deployments of the software.
Companies like Netzing and On-waves have been FOSS-friendly and funding
parts of our development effort. They have no issues with the result being
Free Software again. However, there are definitely other companies out
there who are less fond of sharing...
So thus my idea is to put OpenBSC under AGPLv3. This way whoever uses
OpenBSC _in modified form_ to operate a communications network will
have to provide the source code to that modified form on a network
server at no charge.
The only controversial question to me is "your modified version must
prominently offer all users interacting with it remotely through a computer
network (if your version supports such interaction) an opportunity to receive
the Corresponding Source".
1) does a gsm network count as computer network? i'd say yes.
2) is using a gsm network 'interacting with it remotely'? I'd also say yes
3) what does 'prominently offer' mean in the context of GSM? We don't want
the operator to spam their users with advertisement SMS just to know
that they can get the soruce code, after all.
Notwithstanding those open questions, such a network operator would always
have the option of simply sending back his changes for integration in the
official project - and thus he would no longer use a modified version which
then means there is no need for the prominent notice / download at all.
We can make this very clear in the project documentation, putting further
encouragement
The actual relicensing should be less problematic than I thought, since AGPLv3
is compatible with GPLv3.
So I could re-license all parts that I own copyright on (which should be
the majority of the code base anyway) under AGPLv3, while the former GPLv2+
components (like VTY code from zebra, or contributions by other people)
then become GPLv3-or-later.
Of course I would want to encourage all developers/contributors to also
follow the re-licensing. Particularly Holger Freyther, Dieter Spaar, Andreas
Eversberg, Jan Luebbe, Sylvain Munaut, Daniel Willmann, Stefan Schmidt.
So let's start with a poll:
a) Do you think re-licensing to AGPLv3 is a good idea?
b) If you have contributed, would you re-license your code under AGPLv3?
If we have some kind of concesus in the community, I would approach
On-waves whether they would want to do the same for their share of the
copyright. As their "modifications" are all part of OpenBSC git repository,
they would not be subject to any different conditions than before.
Thanks in advance for your feedback,
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)
Hello,
second try to add support to bs11_config for bport0/1 configuration. This
time with enum abis_bs11_line_cfg.
It seems sometimes creating bport1 fails, even LMT shows create obj
greyed out. Don't know why yet.
Regards,
Daniel Willmann
Daniel Willmann (1):
Add {create,delete}-bport1 and bport0-{star,multidrop} to bs11-config
openbsc/include/openbsc/abis_nm.h | 10 +++++++++-
openbsc/src/abis_nm.c | 31 +++++++++++++++++++++++++++++--
openbsc/src/bs11_config.c | 26 ++++++++++++++++++++++++++
3 files changed, 64 insertions(+), 3 deletions(-)
Hi!
It's about time that we find some kind of graphical project logo for the
Osmocom project.
Osmocom is intended as an umbrella project for software like OpenBSC, OsmoSGSN,
OsmocomBB and others.
So it might even be interesting to have some kind of 'family' of logos that
all have the same general theme.... At least the bigger projects like OpenBSC
and OsmocomBB definitely deserve their own incarnation within that family.
If you want to contribute to our project but are not a die-hard C developer,
this is your option to contribute!
The logo must be under a license that permits use+modification for the
Osmocom project itself. Editability for the general public is not important.
With regard to formats, I would prefer something as SVG that we can then
render into pngs of various sizes whenever there is demand for it.
If you have a proposal, simply send it (or a link to a URL) to the
openbsc(a)lists.gnumonks.org mailing list.
Thanks in advance for any submissions!
--
- 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 merged the Channel Release changes that were prototyped/used in the
on-waves/bsc-master branch and basic testing shows that it is working. If you
see weird things happening, please tell me and I try to figure out if it is
due the changes I made or not.
The problem I tried to solve was this:
Assume a phone sends a SMS (allocates SAPI=3) and then we do release the
channel. Now this can happen with a nanoBTS (and I think it is a bug):
BSC BTS/MS
RF Channel Release ->
<- RF Channel Release Ack
<- Release Indication SAPI=0
<- Release Indication SAPI=3
The OpenBSC code used to declare the lchan as available with the RF Channel
Release ACK, we also decided to release the channel with the SAPI release
indication.. So we were sending a RF Channel Release twice... Now with a
loaded cell we could have re-allocated this lchan and then we release
someone's else lchan... I was seeing from RF Failures, to BTS crashes with two
concurrent phones doing call testing..
Our release procedure now works like this:
chan_alloc.c is called to release the lchan.
1.) we remember the release reason and if we should send a SACH deactivate
2.) we declare the channel to be in state release request
3.) we start to release the highest allocated SAPI != 0 (well only three)
4.) from abis_rsl.c we will call to chan_alloc.c in case a SAPI got released
and repeat 3rd).
5.) If only SAPI=0 is left we either release or send a SACH deactivate..
6.) we send a RF Channel Release...
Hi all,
I have just pushed some code to a public repository. It was written to run on
an embedded Linux platform and convert from E1/MTP-Level1 to TCP/IP. Besides
being hacky (I had to do more than initially planned) it provides some code
for MTP-Level3 and handles the link test (SLTM/SLTA).
The code is using a library that has only existed for a couple of days and
need to be ported to libosmocore, the new vty code and such, it will
eventually happen.
regards
holger
i did not write this howto, also i have no access to change it anyway.
> To use in extensions.conf is:
>
> [btsctrl]
> exten => _02X.,1,GotoIf($[${CALLERID(name)} != ""]?4)
> exten => _02X.,2,Set(CALLIDORIG=${CALLERID(num)})
> exten => _02X.,3,Set(CALLERID(num)=02${CALLIDORIG})
> exten => _02X.,4,Dial(LCR/GSM/${EXTEN:2},120)
>
> So can I define a prefix (02) for mobiles and forward the calls to
LCR.
>
> Maybe help someone other having my problem.
> I suggest Andreas Everberg to update his HowTo...
hi,
what howto do you mean? can you give me the link to it?
regards,
andreas
> To use in extensions.conf is:
>
> [btsctrl]
> exten => _02X.,1,GotoIf($[${CALLERID(name)} != ""]?4)
> exten => _02X.,2,Set(CALLIDORIG=${CALLERID(num)})
> exten => _02X.,3,Set(CALLERID(num)=02${CALLIDORIG})
> exten => _02X.,4,Dial(LCR/GSM/${EXTEN:2},120)
>
> So can I define a prefix (02) for mobiles and forward the calls to
LCR.
>
> Maybe help someone other having my problem.
> I suggest Andreas Everberg to update his HowTo...
Hi, again!
So, as I said in my last E-Mail, I got a new BTS (DSC1800).
Now I have to configure it, so I started ipaccess-find to get his IP
and then ipaccess-config to configure it.
I get this error:
lucabert@Luca:/tmp$ ipaccess-config -u 151/0/0 -o 192.168.1.18
192.168.1.108 ipaccess-config (C) 2009-2010 by Harald Welte and others
This is FREE SOFTWARE with ABSOLUTELY NO WARRANTY
Trying to connect to ip.access BTS ...
Lost some E1 TEI link
Lost some E1 TEI link
Segmentation fault
Can someone say me what is the problem?
Thanks!
--
_______________________________________________________________________
Luca Bertoncello
Entwicklung Mail: bertoncello(a)netzing.de
NETZING Solutions AG Tel.: 0351/41381 - 23
Fröbelstr. 57, 01159 Dresden Fax: 0351/41381 - 12
HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag(a)netzing.de
_______________________________________________________________________
Hi, list!
Of course OpenBSC knows which phone-calls there are right now.
I'd like to get this list. How can I do this?
Thanks a lot!
--
_______________________________________________________________________
Luca Bertoncello
Entwicklung Mail: bertoncello(a)netzing.de
NETZING Solutions AG Tel.: 0351/41381 - 23
Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12
HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag(a)netzing.de
_______________________________________________________________________
Hello Holger,
On Fri, 23 Jul 2010 21:38:36 +0800, "Holger Hans Peter Freyther" <holger(a)freyther.de> wrote:
>
> PS: How big is your diff to make it compile on Windows?
I have not ported the TUN calls yet. My last try for OpenBSC plus
GPRS was in a Linux VM, however I had problems there with the TUN
interface. I could see outgoing packets with proper NAT translation
(the DNS queries from the phone) and I could also see the DNS replies
"outside" the VM but they never got through to the TUN interface.
Maybe its a problem related to the VM, but after this experience I
decided to wait playing with the TUN interface on Cygwin because
it probably makes sense to have a running reference system first.
BTW, anyone having OpenBSC plus GPRS running on MacOS X ? Thats the
closest to Unix I have here besides a VM.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
I find the measurement report of OpenBSC very difficult to read,
because it is not possible to distinguish the various phones.
Of course, it is possible to filter the log (logging filter imsi ...),
but sometimes, as in my case, it is necessary to get the measurement
reports of many phones at the same time.
In this case, it is not possible to know which phone generate which
report.
I create a patch to solve this problem. With this patch, the
measurement reports contain the lchan in which the call (or SMS) runs
(just as information), the IMSI and the extension of the phone.
If you are interested, here is it!
Greetings
--
_______________________________________________________________________
Luca Bertoncello
Entwicklung Mail: bertoncello(a)netzing.de
NETZING Solutions AG Tel.: 0351/41381 - 23
Fröbelstr. 57, 01159 Dresden Fax: 0351/41381 - 12
HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag(a)netzing.de
_______________________________________________________________________
Hello Holger,
On Fri, 23 Jul 2010 19:07:55 +0800, "Holger Hans Peter Freyther" <holger(a)freyther.de> wrote:
>
> Dieter do you know if cygwin will silently ignore the MSG_TRUNC
> flag or if you will have a problem on Window?
Thanks for asking.
According to what I found so far, Cygwin should support MSG_TRUNC.
However considering the fact that there is much more to do to
get OpenBSC and GPRS running under Cygwin (porting the calls to
access the TUN interface in OpenGGSN), one more obstacle should
not really care ;-) (I guess I am the only one who uses OpenBSC
on Cygwin).
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hi Harald, Dieter,
what do you think of using MSG_TRUNC and checking if we have
truncated our packets in a recv call?
Dieter do you know if cygwin will silently ignore the MSG_TRUNC
flag or if you will have a problem on Window?
diff --git a/openbsc/src/gprs/gprs_ns.c b/openbsc/src/gprs/gprs_ns.c
index 3db1d67..ab2d937 100644
--- a/openbsc/src/gprs/gprs_ns.c
+++ b/openbsc/src/gprs/gprs_ns.c
@@ -867,7 +867,7 @@ static struct msgb *read_nsip_msg(struct bsc_fd *bfd, int *error,
return NULL;
}
- ret = recvfrom(bfd->fd, msg->data, NS_ALLOC_SIZE - NS_ALLOC_HEADROOM, 0,
+ ret = recvfrom(bfd->fd, msg->data, NS_ALLOC_SIZE - NS_ALLOC_HEADROOM, MSG_TRUNC,
(struct sockaddr *)saddr, &saddr_len);
if (ret < 0) {
LOGP(DNS, LOGL_ERROR, "recv error %s during NSIP recv\n",
@@ -879,6 +879,11 @@ static struct msgb *read_nsip_msg(struct bsc_fd *bfd, int *error,
msgb_free(msg);
*error = ret;
return NULL;
+ } else if (ret > NS_ALLOC_SIZE - NS_ALLOC_HEADROOM) {
+ LOGP(DNS, LOGL_ERROR, "truncated msg. real size is: %d\n", ret);
+ msgb_free(msg);
+ *error = -ENOSPC;
+ return NULL;
}
msg->l2h = msg->data;
Hi, list!
A very strange problem...
Today I got a new BTS (DSC1800) and I tried to configure it.
Unfortunately it does not respond correctly (I'll send a separate
E-Mail about this problem), so I decided to try with the last version
of OpenBSC (maybe a bug in ipaccess-config?).
Unfortunately I can't compile it. I get these errors:
gcc -Wall -I/usr/local/include/ -I/usr/local/include/ -g -O2 -L/usr/local/lib -losmocore -o bsc_hack bsc_hack.o bsc_init.o bsc_vty.o vty_interface_layer3.o libmsc.a libbsc.a libvty.a libmsc.a -ldl -ldbi -L/usr/local/lib -losmovty -lcrypt
bsc_init.o:(.data+0x0): multiple definition of `gsm_7bit_alphabet'
bsc_hack.o:(.data+0x0): first defined here
bsc_vty.o:(.data+0x0): multiple definition of `gsm_7bit_alphabet'
bsc_hack.o:(.data+0x0): first defined here
vty_interface_layer3.o:(.data+0x0): multiple definition of `gsm_7bit_alphabet'
bsc_hack.o:(.data+0x0): first defined here
libmsc.a(gsm_subscriber.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet'
bsc_hack.o:(.data+0x0): first defined here
libmsc.a(db.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet'
bsc_hack.o:(.data+0x0): first defined here
libmsc.a(mncc.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet'
bsc_hack.o:(.data+0x0): first defined here
libmsc.a(gsm_04_08.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet'
bsc_hack.o:(.data+0x0): first defined here
libmsc.a(gsm_04_11.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet'
bsc_hack.o:(.data+0x0): first defined here
libmsc.a(transaction.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet'
bsc_hack.o:(.data+0x0): first defined here
libmsc.a(token_auth.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet'
bsc_hack.o:(.data+0x0): first defined here
libmsc.a(rrlp.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet'
bsc_hack.o:(.data+0x0): first defined here
libmsc.a(ussd.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet'
bsc_hack.o:(.data+0x0): first defined here
libmsc.a(silent_call.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet'
bsc_hack.o:(.data+0x0): first defined here
libmsc.a(handover_decision.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet'
bsc_hack.o:(.data+0x0): first defined here
libmsc.a(auth.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet'
bsc_hack.o:(.data+0x0): first defined here
libmsc.a(osmo_msc.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet'
bsc_hack.o:(.data+0x0): first defined here
libmsc.a(gsm_04_80.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet'
bsc_hack.o:(.data+0x0): first defined here
libbsc.a(abis_rsl.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet'
bsc_hack.o:(.data+0x0): first defined here
libbsc.a(abis_nm.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet'
bsc_hack.o:(.data+0x0): first defined here
libbsc.a(gsm_data.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet'
bsc_hack.o:(.data+0x0): first defined here
libbsc.a(gsm_04_08_utils.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet'
bsc_hack.o:(.data+0x0): first defined here
libbsc.a(chan_alloc.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet'
bsc_hack.o:(.data+0x0): first defined here
libbsc.a(debug.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet'
bsc_hack.o:(.data+0x0): first defined here
libbsc.a(abis_nm_vty.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet'
bsc_hack.o:(.data+0x0): first defined here
libbsc.a(gsm_subscriber_base.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet'
bsc_hack.o:(.data+0x0): first defined here
libbsc.a(bsc_rll.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet'
bsc_hack.o:(.data+0x0): first defined here
libbsc.a(trau_mux.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet'
bsc_hack.o:(.data+0x0): first defined here
libbsc.a(paging.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet'
bsc_hack.o:(.data+0x0): first defined here
libbsc.a(e1_config.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet'
bsc_hack.o:(.data+0x0): first defined here
libbsc.a(e1_input.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet'
bsc_hack.o:(.data+0x0): first defined here
libbsc.a(misdn.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet'
bsc_hack.o:(.data+0x0): first defined here
libbsc.a(ipaccess.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet'
bsc_hack.o:(.data+0x0): first defined here
libbsc.a(handover_logic.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet'
bsc_hack.o:(.data+0x0): first defined here
libbsc.a(talloc_ctx.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet'
bsc_hack.o:(.data+0x0): first defined here
libbsc.a(system_information.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet'
bsc_hack.o:(.data+0x0): first defined here
libbsc.a(rest_octets.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet'
bsc_hack.o:(.data+0x0): first defined here
libbsc.a(rtp_proxy.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet'
bsc_hack.o:(.data+0x0): first defined here
libbsc.a(bts_siemens_bs11.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet'
bsc_hack.o:(.data+0x0): first defined here
libbsc.a(bts_ipaccess_nanobts.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet'
bsc_hack.o:(.data+0x0): first defined here
libbsc.a(bts_unknown.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet'
bsc_hack.o:(.data+0x0): first defined here
libbsc.a(bsc_api.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet'
bsc_hack.o:(.data+0x0): first defined here
libbsc.a(meas_rep.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet'
bsc_hack.o:(.data+0x0): first defined here
libbsc.a(socket.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet'
bsc_hack.o:(.data+0x0): first defined here
libbsc.a(subchan_demux.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet'
bsc_hack.o:(.data+0x0): first defined here
libvty.a(common_vty.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet'
bsc_hack.o:(.data+0x0): first defined here
collect2: ld gab 1 als Ende-Status zurück
make[3]: *** [bsc_hack] Fehler 1
make[3]: Verlasse Verzeichnis '/home/lucabert/BSC/openbsc/openbsc/src'
make[2]: *** [all-recursive] Fehler 1
make[2]: Verlasse Verzeichnis '/home/lucabert/BSC/openbsc/openbsc/src'
make[1]: *** [all-recursive] Fehler 1
make[1]: Verlasse Verzeichnis '/home/lucabert/BSC/openbsc/openbsc'
make: *** [all] Fehler 2
Can someone confirm me, that the problem is in this version and not in my PC?
Thanks
--
_______________________________________________________________________
Luca Bertoncello
Entwicklung Mail: bertoncello(a)netzing.de
NETZING Solutions AG Tel.: 0351/41381 - 23
Fröbelstr. 57, 01159 Dresden Fax: 0351/41381 - 12
HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag(a)netzing.de
_______________________________________________________________________
Hi!
I've just committed a patch that will cause libosmocore to abort in case
we try to msgb_put() beyond the end fo the buffer or msgb_push() ahead
of the start.
I hope we can uncover any hidden buffer under/overflows this way, if they
exist.
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)
Hi, list!
We have actually 4 BaseStation (but in the future we will buy at least
other 2).
Now want my Boss to buy a PoE-Switch at which we connect all
BaseStation.
This Switch has to supply power, too.
Now, I'm not sure (I don't know PoE in detail) if I can use every
PoE-Switch.
I searched in Internet and I found a Netgear FS108P. It's cheap and it
will be enough for us. Can I use it with our BaseStation or have I to
use the power supplier of the BaseStations, too?
Thanks a lot for your answers!
--
_______________________________________________________________________
Luca Bertoncello
Entwicklung Mail: bertoncello(a)netzing.de
NETZING Solutions AG Tel.: 0351/41381 - 0
Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12
HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag(a)netzing.de
_______________________________________________________________________
Hi!
As some of you will have noticed, I've been working hard on a TCAP
implementation. As this is now getting into pretty good shape, I'm
looking at implementing MAP.
Right now I'm trying to come up with a good design to implement both
MAP client (let's say a SGSN or MSC that issues a Location Updating Request)
and server applications (think of HLR receiving + processing the Loc Upd Req).
The full flow of primitives can be seen in the attached diagram (which
by the way was designed unsing the new gen_ladder tool from
git://git.osmocom.org/gen_ladder.git).
In TCAP, it is relatively hard to grasp that every message consists of a
dialogue part and an (optional) collection of component parts. The dialogue
and component state machines are separate but interact. Since a lot of
functionality is possibly contained in one PDU, this ladder diagram does not
really care about actual messages/packets, but about the sequencing of
primitives.
First, terminology:
client: A "request-side" client like a SGSN or MSC wanting to do loc upd
libmap-cl: The libosmo-map instance at the client
libtcap-cl: The libosmo-tcap instance at the client
[between the two libtcap instances we have the signalling link]
libtcap-srv: The libosmo-tcap instance at the server
libmap-srv: The libosmo-map instance at the server
server: The "responder-side" server like a HLR that receives loc upd
1) MAP-OPEN primitive is sent sent from client to libosmo-map. Note
that no actual packets are exchanged on the signalling linke yet!
2) two MAP-INVOKE component requests are sent to libosmo-map. They contain
the actual location updating requests (two of them for two different MS)
3) MAP-DELIMITER.req primitive is issued by client to libosmo-map. At this
point, a TCAP TC-BEGIN.req primitive is issued to libosmo-tcap.
libosmo-tcap assembles a TCAP message consisting of a TC-BEGIN dialogue
portion (including loc upd req application context) containing two
TC-INVOKE components. This message is sent over the signalling link.
4) The server libosmo-tcap receives the TC-BEGIN message with two TC-INVOKE
components. It issues a TC-BEGIN.indication to libosmo-map, which in
turn generates a MAP-OPEN.indicatin for the server application
5) The server application checks if it supports the application context and
then confirms the MAP-OPEN by a MAP-OPEN.response primitive. This
primitive is "cached" at libosmo-map at that time.
6) the server libosmo-tcap sends the first TC-INVOKE.indication to
libosmo-map which forwards it to the server application. the application
respondes with a 'result-last' primitive that is passed up to libosmo-tcap
7) the server libosmo-tcap sends the second TC-INVOKE.indication to
libosmo-map which forwards it to the server application. the application
respondes with a 'result-last' primitive that is passed up to libosmo-tcap
Since this TC-INVOKE.ind is flagged as 'last', libosmo-map will issue
a MAP-DELIMITER.indication to the server program.
8) The server application responds with MAP-DELIMITER.request, which triggers
libosmo-map to issue a TC-CONTINUE.request, which in turn triggers
generating the TCAP TC-CONTINUE message containing the two TC-RESULT-Last
components
[...]
This primitive sequencing is mandated by the combination of the ITU-T Q.77x
specifications and the GSM TS 09.02 / 29.002. Now the task at hand is to
decide on the software architecture and which parts have to be handled
synchronously or not.
It was my idea to pass everything by-value at the libosmo-tcap/libosmo-map
interface. While they both keep state information, I do not want to pass
any information by reference at thee inter-layer boundaries. This might cause
headaches in memory management (reference counting, etc.)
Another aspect is that the actual execution of the function (e.g. location
updating operation) might not be finished synchronously. If the server
process implements a HLR, the HLR might be implemented as on-disk storage
(e.g. SQL). In that case, the MAP-INVOKE.ind containing the location update
will trigger some disk access. Only once that disk access has finished, the
corresponding MAP-RESULT-L.req can be generated.
The rough idea would be to have a queue of those tcap<->map primitives.
This way, we could have single-threaed or (with proper locking) a thread pool
approach, where each thread then dequeues one primitive, processes it,
and sends a response primitive once it is finished.
Any feedback/comments to this proposed architecture are most welcome.
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)
hi luca,
it seems that there is a change in the API. therefore i prepared a
"snapshot" at www.linux-call-router.de to be downloaded. this version of
openbsc and lcr is older, but works together. as soon as the current
openbsc has been tested more (channel ressource handling has changed for
example), i will make it work again.
regards,
andreas
> #0 0x0805b009 in gsm0408_rcvmsg (msg=0x864ffb8, link_id=0 '\0') at
openbsc/src/bsc_api.c:111
> 111 rc = api->compl_l3(lchan->conn, msg,
0);
>
> The problem seems to be the variable api, which is NULL.
>
> (gdb) print api
> $1 = (struct bsc_api *) 0x0
Hi, List!
I got it! Now can I call mobile phones with Asterisk.
If someone is interested, the problem was in the Asterisk-configuration
(from HowTo).
To use in extensions.conf is:
[btsctrl]
exten => _02X.,1,GotoIf($[${CALLERID(name)} != ""]?4)
exten => _02X.,2,Set(CALLIDORIG=${CALLERID(num)})
exten => _02X.,3,Set(CALLERID(num)=02${CALLIDORIG})
exten => _02X.,4,Dial(LCR/GSM/${EXTEN:2},120)
So can I define a prefix (02) for mobiles and forward the calls to LCR.
Maybe help someone other having my problem.
I suggest Andreas Everberg to update his HowTo...
And now the next problem: calling a VoIP-phone from mobile phone... :)
I'll get it, too!
Bye
--
_______________________________________________________________________
Luca Bertoncello
Entwicklung Mail: bertoncello(a)netzing.de
NETZING Solutions AG Tel.: 0351/41381 - 0
Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12
HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag(a)netzing.de
_______________________________________________________________________
Hello Luca,
On Wed, 14 Jul 2010 11:22:05 +0200, "Luca Bertoncello" <bertoncello(a)netzing.de> wrote:
>
> I can confirm, that "neci 1" solve my problem!
> I can call and send SMS without any problem, from the NE110, too!
Great to hear that. I am not sure how well OpenBSC is tested with
NECI set to "1" but I guess it should not cause too many problems,
its only the channel allocator which behaves differently.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello Holger,
On Wed, 14 Jul 2010 17:52:51 +0800, "Holger Hans Peter Freyther" <holger(a)freyther.de> wrote:
>
> maybe I was too blind and didn't see it in GSM 04.08, but setting NECI=1
> will not allow us to assign a TCH/F for MO Call.
What about this:
0100xxxx
Originating speech call from dual-rate mobile station when TCH/H
is sufficient and supported by the MS for speech calls and the
network sets NECI bit to 1
At least this is what the Nokia 3310 uses for a voice call. OpenBSC
should than allocate a TCH for it.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello Harald,
On Tue, 13 Jul 2010 16:06:55 +0200, "Harald Welte" <laforge(a)gnumonks.org> wrote:
>
> The Netzing NE110 (as well as other MTK phones) seem to have a bug in
> their MO-SMS code. Dieter has told me he is looking at a workaround to this
> (by sending dummy authentication request/response), and he will e-mail this
> list once he has some results.
This was a tough one. I tried Authentication and Ciphering commands in
various combinations without any success. Finally I changed the allocated
channel to SDCCH instead of TCH. And voila, it worked, even without
Authentication and/or Ciphering.
So it seems that there is a problem with MTK phones (and maybe others)
and MO-SMS on a TCH channel. I am not sure yet if there is a workaround
to solve this and still use the TCH.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello Holger,
On Wed, 14 Jul 2010 14:56:27 +0800, "Holger Hans Peter Freyther" <holger(a)freyther.de> wrote:
>
> do you remember which kind of channel the phone is requesting? is it
> really asking for a channel for calls?
Yes, the phone always sets the mask according to this (from the spec):
111xxxxx
Originating call and TCH/F is needed, or originating call
and the network does not set NECI bit to 1, or
procedures that can be completed with a SDCCH and the
network does not set NECI bit to 1
This was the same for other phones, not just MTK based phones. NECI was
set to 0, however I think that setting NECI to 1 might be the solution
for the problem, without the need to change the Very Early Assignment
procedure. I have not yet tested this in detail, so I might miss
something.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello Luca,
On Wed, 14 Jul 2010 10:04:05 +0200, "Luca Bertoncello" <bertoncello(a)netzing.de> wrote:
>
> Wow! It works! And I can send SMS with the NE110 phones too!
> Maybe could it be a solution to set lctype to GSM_LCHAN_SDCCH if the
> phone tried to send an SMS?
Harald probably knows the details better, but the basic problem is
that the phone does not tell you exactly what channels it needs
when it sends the Channel Request, at least if NECI is set to 0
(new establishment causes are not supported). So the channel
allocator allocates a TCH channel, to be able to handle everything
(SMS and Voice).
One solution for this is to switch from Very Early Assignment to
other assignment procedures. I think Holger and Harald have plans
to support this.
However there also seems to be a different solution: You can set
NECI to 1, this way the phone can tell you in more detail what
it wants. I have not done extensive tests, but it seems that
this could solve the problem without the need to change the
code. You just have to set "neci 1" in the OpenBSC configuration
file.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello Luca,
On Wed, 14 Jul 2010 08:45:49 +0200, "Luca Bertoncello" <bertoncello(a)netzing.de> wrote:
>
> Of course! I tested OpenBSC with GSM1800, too. And, unfortunately, it
> does not work... Attached the pcap-file and the config of OpenBSC.
> Here some information from ipaccess-find:
If you want to find out if the SMS sending problem is related to
what I posted yesterday, you can try the following:
In "/src/abis_rsl.c", function "rsl_rx_chan_rqd()" replace the line
lctype = get_ctype_by_chreq(bts, rqd_ref->ra, bts->network->neci);
with
lctype = GSM_LCHAN_SDCCH;
This will always allocate an SDCCH and you can check if SMS sending
now works. However this is only for testing, voice calls will no
longer work with this change.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Am Wed, 23 Jun 2010 20:18:56 +0800
schrieb Holger Freyther <zecke(a)selfish.org>:
> the first pointer is to the sha1/commit id[1]. So every commit has an
> id, it happens to be the sha1 hash over some parts of the content. Now
> git log will show all these as "commit". Now the openbsc version is
> generated by the little "./git-version-gen" utility. In fact the
> utility is calling "git describe" (man git-describe).
>
> E.g. it looks like this:
> 0.9.0-891-gaf7edd9
>
> 0.9.0 is the last tag we had..
> 891 is the number of commits since that tag
> gaf7edd9 is the commit/sha1. This is what you want.
>
> I hope this helps
Unfortunately not...
I tried to give git-describe in the tree of the "sms-sending"-BSC
(0.9.0-531-gb938d6b) and in the tree of the last version
(0.9.0-890-g2788b96), then I tried to use git bisect:
lucabert@Luca:/tmp/bsc/openbsc$ git bisect good gb938d6b
Bad rev input: gb938d6b
lucabert@Luca:/tmp/bsc/openbsc$ git bisect bad g2788b96
fatal: Needed a single revision
Bad rev input: g2788b96
It seems not to work... Maybe I need vacancy? I can't understand what
you suppose I can do...
Thanks for your suggestion!
--
_______________________________________________________________________
Luca Bertoncello
Entwicklung Mail: bertoncello(a)netzing.de
NETZING Solutions AG Tel.: 0351/41381 - 0
Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12
HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag(a)netzing.de
_______________________________________________________________________
Hi,
I've rewritten the GSM 7 bit default encoding as the current
implementation results in wrong encoding for certain
characters, e.g. '@'. The septet packing lacked the lookup
and this only worked for characters that had a 1-1 mapping
between their ascii value and the default alphabet table. I
introduced a lookup table and now do the character
translation before packing the data. Patch is attached.
I guess the decoding needs to be rewritten as well and I may
provide a patch for that in the future as well. For now the
encoding produced enough headaches for me :)
I adjusted the copyright stanza in these files but I'm not
completely sure if this is appropriate or not, so feel free
to remove, I won't be offended :)
Cheers
Nico
Hi,
Is there a version of Scapy with the GSM protocol layers that I can use with
the ipaccess-proxy, as discussed in Harold Welte's presentation?
Many thanks,
Steve
Hi guys,
Today I git-cloned the latest version opnbsc/libosmocore and built it
successfully.
But when running the nanoBTS900, no BCCH is sent, just the carrier signal.
I can confirm this, because I've two nanoBTSs, one 900 and the other
1800, the 1800 version works well.
With a special gsm module (Telit), I can perform a scan for the
available BCCHs in the environment.
Anyone recognize this?
Hi, List!
I'm trying to get OpenBSC working with Asterisk.
I have a working configuration of Asterisk, and a working configuration
of OpenBSC.
I use a nanoBTS DSC1800.
The O.S. is Debian lenny and I have a Cologne Chip Designs GmbH ISDN
network Controller [HFC-E1] ISDN card.
In my interface.conf I just have:
[GSM]
gsm-bs
nt
layer1hold no
layer2hold no
tones yes
earlyb no
channel-in free
channel-out any
nodtmf
My gsm.conf:
interface-bsc mISDN_l1loop.1
interface-lcr mISDN_l1loop.2
debug DRLL:DCC:DMM:DRR:DRSL:DNM:DSMS:DMNCC:DMNSMS:DPAG:DMUX:DMEAS
config /home/lucabert/bscAsterisk/lucabertBSC.cfg
hlr /home/lucabert/bscAsterisk/hlr.sqlite3
In my options.conf I have a line:
gsm
and in my routing.conf I have this line by [main]:
interface=GSM : remote application=asterisk context=btsctrl
Now I start LCR (as root):
/usr/local/sbin/lcr start
It starts and wait until the nanoBTS log in.
Then, when I try to use the net with my mobile, LCR crashes.
I generated a core file. With gdb I see:
Program terminated with signal 11, Segmentation fault.
[New process 4026]
[New process 4029]
#0 0x0805b009 in gsm0408_rcvmsg (msg=0x864ffb8, link_id=0 '\0') at openbsc/src/bsc_api.c:111
111 rc = api->compl_l3(lchan->conn, msg, 0);
The problem seems to be the variable api, which is NULL.
(gdb) print api
$1 = (struct bsc_api *) 0x0
Can someone help me? I use OpenBSC 0.9.0.967-02d3 and LCR 1.7
(both downloaded yesterday with git clone).
Thanks a lot for your help
--
_______________________________________________________________________
Luca Bertoncello
Entwicklung Mail: bertoncello(a)netzing.de
NETZING Solutions AG Tel.: 0351/41381 - 0
Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12
HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag(a)netzing.de
_______________________________________________________________________
> As I don't have access to a nanoBTS I never tried it, but you could take a
> look at Sylvain's chan_openbsc for Asterisk
> (http://github.com/smunaut/ast_chan_openbsc).
Yeah, that probably doesn't work anymore.
Yet another thing I must finish. But that's pretty low on my list ...
Sylvain
Hello guys,
I want to change a nanoBTS's id, so I can control two BTSs each as a
seperate BTS (not as a seperate TRX).
But this is what I get:
$ ./ipaccess-config -u 1801/1/0 10.100.2.27
ipaccess-config (C) 2009-2010 by Harald Welte and others
This is FREE SOFTWARE with ABSOLUTELY NO WARRANTY
Trying to connect to ip.access BTS ...
<0005> abis_nm.c:518 OC=SITE-MANAGER(00) INST=(ff,ff,ff) STATE CHG:
OP_STATE=Disabled AVAIL=Not installed(07)
<0005> abis_nm.c:518 OC=BTS(01) INST=(00,ff,ff) STATE CHG:
OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked
<0005> abis_nm.c:518 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) STATE
CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked
OML link established using TRX 0
setting Unit ID to '1801/1/0'
<0005> abis_nm.c:518 OC=CHANNEL(03) INST=(00,00,00) STATE CHG:
OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked
<0005> abis_nm.c:518 OC=CHANNEL(03) INST=(00,00,01) STATE CHG:
OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked
<0005> abis_nm.c:518 OC=CHANNEL(03) INST=(00,00,02) STATE CHG:
OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked
<0005> abis_nm.c:518 OC=CHANNEL(03) INST=(00,00,03) STATE CHG:
OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked
<0005> abis_nm.c:518 OC=CHANNEL(03) INST=(00,00,04) STATE CHG:
OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked
<0005> abis_nm.c:518 OC=CHANNEL(03) INST=(00,00,05) STATE CHG:
OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked
<0005> abis_nm.c:518 OC=CHANNEL(03) INST=(00,00,06) STATE CHG:
OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked
<0005> abis_nm.c:518 OC=CHANNEL(03) INST=(00,00,07) STATE CHG:
OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked
<0005> abis_nm.c:518 OC=RADIO-CARRIER(02) INST=(00,00,ff) STATE CHG:
OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked
<0005> abis_nm.c:518 OC=GPRS-NSE(f0) INST=(00,ff,ff) STATE CHG:
OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked
<0005> abis_nm.c:518 OC=GPRS-CELL(f1) INST=(00,00,ff) STATE CHG:
OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked
<0005> abis_nm.c:518 OC=GPRS-NSVC(f2) INST=(00,00,ff) STATE CHG:
OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked
<0005> abis_nm.c:518 OC=GPRS-NSVC(f2) INST=(00,01,ff) STATE CHG:
OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked
<0005> abis_nm.c:518 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff)
IPACCESS(0xf1): <0005> abis_nm.c:2757 SET NVATTR NACK CAUSE=Parameter
value outside permitted range
Failure to set attribute. This seems fatal
Is this familiar to you?
Thank you.
Hi, List!
I have now to connect OpenBSC with Asterisk, in order to use a
VoIP-phone to call mobiles (and viceversa).
I found this HowTo: http://openbsc.osmocom.org/trac/wiki/OpenBSC_LCR
Since I don't know Asterisk I'm not sure if it is what I really need...
In the HowTo 2 ISDN-Cards are used. Need I really these? I'm using a
nanoBTS (accessed over Ethernet), so I think I don't need the Cologne
Chips E1 PCI card. Is it right?
Then, at least as first step, I don't want to connect my Asterisk with
the rest of the world.
I really want to create my own test-network with a VoiIP-phone and a
couple of mobiles.
Do I really need a ISDN-card?
And last, but not least, (as I said, I don't know Asterisk!!), how can
I decide, that a number I choose from mobile or VoiIP-phone is a mobile
or a VoiIP-phone?
Maybe there is a running configuration of Asterisk I can use as example?
Thanks a lot for your help!
--
_______________________________________________________________________
Luca Bertoncello
Entwicklung Mail: bertoncello(a)netzing.de
NETZING Solutions AG Tel.: 0351/41381 - 0
Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12
HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag(a)netzing.de
_______________________________________________________________________
As horiz0n on IRC points out:
00:16 <horiz0n> hehe, calling the c123 from my 9500 communicator crashes openbsc
00:17 <horiz0n> here is the log http://notepad.cc/share/LQ3awCtXz9
00:21 <horiz0n> and here the debug log http://notepad.cc/share/tPJYXo3SJG
<0000> abis_rsl.c:1388 (bts=0,trx=0,ts=1,ss=0) SAPI=0 DATA INDICATION
<0003> gsm_04_08.c:1109 CIPHERING MODE COMPLETE
<0003> gsm_04_08_utils.c:197 Sending Channel Release: Chan: Number: 0 Type: 2
<0004> abis_rsl.c:586 (bts=0,trx=0,ts=1,ss=0) DEACTivate SACCH CMD
<0000> chan_alloc.c:363 (bts=0,trx=0,ts=1,ss=0) Recycling Channel
<0000> abis_rsl.c:1388 (bts=0,trx=0,ts=1,ss=0) SAPI=0 DATA INDICATION
./runbsc.sh: line 6: 1179 Segmentation fault sudo ./bsc_hack -e 1 -d DINP:DNM:DRSL:DRR:DMM:DCC:DRLL:DMNCC:DSMS:DPAG,0:0:0
So what happens: We get a CM Service request, then go through authentication
and ciphering. At that point, the network decides to release the channel
and the channel is not completely closed yet (only SACCH deactivated) when
we get an incoming SETUP message.
This message is treated as a new message (msc_compl_l3, but it has no
conn->subscr and the code segfaults in trans_find_by_id(subscr=NULL, ...)
So I think there are actually multiple bugs.
1) the channel should not be released at that time
2) we have some kind of a race condition at channel release, where incoming
messages should either be discarded _or_ should still be processed with
all the data structures intact.
Cheers,
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 news, everyone [tm]
GPRS is by now in a fairly useful state. I've spent the better part of the
last 3 days to fix all the remaining known bugs. It is working fine from
a variety of phones including a G1 (MSM7200) , K800i (unkown baseband), TYTN2
(also Qualcomm MSM but with windows mobile), E680 (Neptune LTE), ...
The following parts are still missing:
* Integration with the HLR, so every phone is accepted on GPRS
* IP Header compression (ROHC)
* Data compression (v.42bis)
* Authentication (depends on HLR integration)
* GEA3 Encryption (though most of the infrastructure is there)
* Ability to route APNs to different GGSNs
So everyone who has access to a nanoBTS: Try it now. The build/config
instructions haven't changed from what I described last time when I wrote
a GPRS status update to this list.
Happy hacking,
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)
-------- Original-Nachricht --------
> Datum: Wed, 30 Jun 2010 12:10:20 +0800
> Von: Holger Hans Peter Freyther <holger(a)freyther.de>
> An: openbsc(a)lists.gnumonks.org
> Betreff: Re: Segmentation fault while sending sms via bsc_hack_VTY
> >
> > thanks a lot for starting to debug this. Could you help me a bit with
> > your test setup? Which type of BTS do you use? Could you get us a pcap
> > file for the Channel Activate NACK?
Attached I have a pcap file from bsc_hack. It logged until the segmentation fault happened. Additionally, I have captured the bsc_hack output and valgrind output in the other file. There you also find the openbsc config file. Only bsc_hack was started, without lcr or openggsn for this testing.
We use two nanoBTS - ipaccess-find prints out:
MAC Address='00:02:95:00:2f:b7' IP Address='10.1.1.10' Unit ID='1802/0/0' Location 1='' Location 2='BTS_NBT131G' Equipment Version='165a029_48' Software Version='168c002_v100b16d0' Unit Name='nbts-00-02-95-00-2F-B7' Serial Number='00071355'
MAC Address='00:02:95:00:57:3e' IP Address='10.1.1.11' Unit ID='1800/0/0' Location 1='' Location 2='BTS_NBT131G' Equipment Version='165a029_55' Software Version='168a302_v142b13d0' Unit Name='nbts-00-02-95-00-57-3E' Serial Number='00107709'
Each BTS has its own part in the openbsc.cfg
>
> please confirm that both the SMS crash and the NACKs are resolved.
I loaded and built the current version from OpenBSC (Jun., 30. ~ 3:00 p.m.). SMS still crashes when sending from vty console.
As far as I can tell, the NACKs are resolved.
>
> thanks
thank you too!
Hi folks.
I am currently playing with the crypto features of openBSC. When i want
to enter the key for a specific subscriber in the VTY console openBSC
crashes.
When i create the entry manually with sqlite3 and try again the entry in
the database will be overwritten and it seems to work.
The string i entered in VTY was:
subscriber imsi 001010000000000 a3a8 comp128v1
DEADBEEF0C0FFEE0F00D013370D00F23
The gdb backtrace is:
openbsc@openBSC:~/openbsc/openbsc/src$ gdb -- pid 1612
GNU gdb (GDB) 7.1-ubuntu
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
pid: No such file or directory.
Attaching to process 1612
Reading symbols from /home/openbsc/openbsc/openbsc/src/bsc_hack...done.
Reading symbols from /usr/local/lib/libosmocore.so.0...done.
Loaded symbols for /usr/local/lib/libosmocore.so.0
Reading symbols from /lib/tls/i686/cmov/libdl.so.2...(no debugging
symbols found)...done.
Loaded symbols for /lib/tls/i686/cmov/libdl.so.2
Reading symbols from /usr/lib/libdbi.so.0...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/libdbi.so.0
Reading symbols from /usr/local/lib/libosmovty.so.0...done.
Loaded symbols for /usr/local/lib/libosmovty.so.0
Reading symbols from /lib/tls/i686/cmov/libcrypt.so.1...(no debugging
symbols found)...done.
Loaded symbols for /lib/tls/i686/cmov/libcrypt.so.1
Reading symbols from /lib/tls/i686/cmov/libc.so.6...(no debugging
symbols found)...done.
Loaded symbols for /lib/tls/i686/cmov/libc.so.6
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/tls/i686/cmov/libm.so.6...(no debugging
symbols found)...done.
Loaded symbols for /lib/tls/i686/cmov/libm.so.6
Reading symbols from /usr/lib/dbd/libdbdsqlite3.so...(no debugging
symbols found)...done.
Loaded symbols for /usr/lib/dbd/libdbdsqlite3.so
Reading symbols from /usr/lib/libsqlite3.so.0...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/libsqlite3.so.0
Reading symbols from /lib/tls/i686/cmov/libpthread.so.0...(no debugging
symbols found)...done.
[Thread debugging using libthread_db enabled]
Loaded symbols for /lib/tls/i686/cmov/libpthread.so.0
0x00c9d422 in __kernel_vsyscall ()
(gdb) continue
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0x0046450b in vfprintf () from /lib/tls/i686/cmov/libc.so.6
(gdb) bt
#0 0x0046450b in vfprintf () from /lib/tls/i686/cmov/libc.so.6
#1 0x00484147 in vasprintf () from /lib/tls/i686/cmov/libc.so.6
#2 0x006b042f in dbi_conn_queryf () from /usr/lib/libdbi.so.0
#3 0x08054c05 in db_sync_authinfo_for_subscr (ainfo=0x579ff4,
subscr=0x994ec18) at db.c:413
#4 0x0805408e in ena_subscr_a3a8 (self=0x8089ee0, vty=0x99501f8,
argc=4, argv=0xbfc33f6c) at vty_interface_layer3.c:502
#5 0x00a74cfb in cmd_execute_command_real (vline=<value optimized out>,
vty=<value optimized out>, cmd=0x0)
at command.c:1874
#6 0x00a74e27 in cmd_execute_command (vline=0x994a5c0, vty=0x99501f8,
cmd=0x0, vtysh=0) at command.c:1909
#7 0x00a7766f in vty_command (vty=0x99501f8) at vty.c:321
#8 vty_execute (vty=0x99501f8) at vty.c:585
#9 vty_read (vty=0x99501f8) at vty.c:1319
#10 0x00a793aa in client_data (fd=0x99504d4, what=1) at
telnet_interface.c:128
#11 0x003b7925 in bsc_select_main (polling=0) at select.c:119
#12 0x0804bc66 in main (argc=3, argv=0xbfc34604) at bsc_hack.c:271
(gdb)
Maybe this helps to find the bug.
regards.
Philipp
--
______________________________________
Philipp Fabian Benedikt Maier
philipp.maier(a)runningserver.com
Funk: DO5DXT
http://www.runningserver.comhttp://www.diskettenschlitz.de
______________________________________