From laforge at gnumonks.org Fri Jul 2 15:42:01 2010 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 2 Jul 2010 17:42:01 +0200 Subject: RFC: Relicensing OpenBSC under AGPLv3 In-Reply-To: <20100519192810.GE14287@prithivi.gnumonks.org> References: <20100519192810.GE14287@prithivi.gnumonks.org> Message-ID: <20100702154201.GA7039@prithivi.gnumonks.org> Hi All! As I have only received positive feedback from all developers and copyright holders so far (including On-Waves), I think we will go ahead with the AGPLv3 re-licensing. If your name appears in the git commitlog of OsmocomBB or libosmocore, you will soon receive a separate e-mail from me, confirming you agree with the AGPLv3 re-licensing. If you do not agree, it is no problem. Then that respective code will remain under GPLv3, as e.g. the vty-code that we've imported from zebra/quagga. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From bertoncello at netzing.de Thu Jul 1 06:26:38 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Thu, 1 Jul 2010 08:26:38 +0200 Subject: [BUG REPORT]: Unable to send SMS In-Reply-To: <20100630160010.GR4876@prithivi.gnumonks.org> References: <4C2207B9.9030300@freyther.de> <20100623151604.009bc143@Luca> <4C220E2F.2070008@freyther.de> <20100628101558.63137742@Luca> <20100628145256.799f9d2e@Luca> <20100629155531.GA17995@prithivi.gnumonks.org> <20100630083001.18b01a57@Luca> <4C2AF060.1090602@freyther.de> <20100630092528.1cb58e3d@Luca> <20100630160010.GR4876@prithivi.gnumonks.org> Message-ID: <20100701082638.79cb3e4f@Luca> Am Wed, 30 Jun 2010 18:00:10 +0200 schrieb Harald Welte : > > The problem is always the same, I described in my E-Mails. > > I tried to install the last version of OpenBSC (git clone ...), > > because Harald said, he applied a patch. > > Neither Holger nor I can reproduce your problem, so we are a bit > stuck here. Hi, Harald! I tried your patch 93d50e69d37b3e3bd5cd41967705b8645cfefdec. Unfortunately I can't test, if it works with SMS, since I can NOT log in to the network. As Attachment the pcap-file with my try. I get always this error: <0004> abis_rsl.c:831 (bts=0,trx=0,ts=0,ss=0) CHANNEL ACTIVATE NACKCAUSE=0x6f(Protocol error, unspecified) <0011> handover_logic.c:197 unable to find HO record Thanks -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at 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 at netzing.de _______________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bertoncello at netzing.de Thu Jul 1 06:30:09 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Thu, 1 Jul 2010 08:30:09 +0200 Subject: [BUG REPORT]: Unable to send SMS In-Reply-To: <20100701082638.79cb3e4f@Luca> References: <4C2207B9.9030300@freyther.de> <20100623151604.009bc143@Luca> <4C220E2F.2070008@freyther.de> <20100628101558.63137742@Luca> <20100628145256.799f9d2e@Luca> <20100629155531.GA17995@prithivi.gnumonks.org> <20100630083001.18b01a57@Luca> <4C2AF060.1090602@freyther.de> <20100630092528.1cb58e3d@Luca> <20100630160010.GR4876@prithivi.gnumonks.org> <20100701082638.79cb3e4f@Luca> Message-ID: <20100701083009.590708c2@Luca> I'm sorry... Hier the pcap-file... Regards -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at 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 at netzing.de _______________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: after93d50e69d37b3e3bd5cd41967705b8645cfefdec Type: application/octet-stream Size: 98304 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From holger at freyther.de Fri Jul 9 09:45:17 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Fri, 09 Jul 2010 17:45:17 +0800 Subject: [BUG REPORT]: Unable to send SMS In-Reply-To: <20100701083009.590708c2@Luca> References: <4C2207B9.9030300@freyther.de> <20100623151604.009bc143@Luca> <4C220E2F.2070008@freyther.de> <20100628101558.63137742@Luca> <20100628145256.799f9d2e@Luca> <20100629155531.GA17995@prithivi.gnumonks.org> <20100630083001.18b01a57@Luca> <4C2AF060.1090602@freyther.de> <20100630092528.1cb58e3d@Luca> <20100630160010.GR4876@prithivi.gnumonks.org> <20100701082638.79cb3e4f@Luca> <20100701083009.590708c2@Luca> Message-ID: <4C36EFAD.7080603@freyther.de> On 07/01/2010 02:30 PM, Luca Bertoncello wrote: > I'm sorry... Hier the pcap-file... Hi Luca, I just had some time to look at the pcap but I am a bit confused. You seem to have multiple bsc_hack starts within the PCAP file? I have seen at least one NACK message, but not at the end of things. Maybe you want to start a new toplevel thread with your problems. Do you still see the Channel Activate NACK messages? Do you still see the SMS Problem? Which phones have you tested this with? From bertoncello at netzing.de Fri Jul 9 11:22:50 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Fri, 9 Jul 2010 13:22:50 +0200 Subject: [BUG REPORT]: Unable to send SMS In-Reply-To: <4C36EFAD.7080603@freyther.de> References: <4C2207B9.9030300@freyther.de> <20100623151604.009bc143@Luca> <4C220E2F.2070008@freyther.de> <20100628101558.63137742@Luca> <20100628145256.799f9d2e@Luca> <20100629155531.GA17995@prithivi.gnumonks.org> <20100630083001.18b01a57@Luca> <4C2AF060.1090602@freyther.de> <20100630092528.1cb58e3d@Luca> <20100630160010.GR4876@prithivi.gnumonks.org> <20100701082638.79cb3e4f@Luca> <20100701083009.590708c2@Luca> <4C36EFAD.7080603@freyther.de> Message-ID: <20100709132250.4b2a8382@Luca> Am Fri, 09 Jul 2010 17:45:17 +0800 schrieb Holger Hans Peter Freyther : > I just had some time to look at the pcap but I am a bit confused. You > seem to have multiple bsc_hack starts within the PCAP file? I have > seen at least one NACK message, but not at the end of things. > > Maybe you want to start a new toplevel thread with your problems. Do > you still see the Channel Activate NACK messages? Do you still see > the SMS Problem? Which phones have you tested this with? Hi, Holger! I just tried with the last version of OpenBSC. Unfortunately it still does not work... :( I uploaded the pcap-file on my server. In this session I just started OpenBSC, logged in with my mobile (Siemens S65v) and tried to send the SMS. And then closed OpenBSC. You can download the pcap-file from http://www.lucabert.de/~lucabert/bscCantSMS.pcap.bz2 I hope, you can understand the problem now... -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at 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 at netzing.de _______________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From holger at freyther.de Sat Jul 10 11:09:18 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sat, 10 Jul 2010 19:09:18 +0800 Subject: [BUG REPORT]: Unable to send SMS In-Reply-To: <20100709132250.4b2a8382@Luca> References: <4C2207B9.9030300@freyther.de> <20100623151604.009bc143@Luca> <4C220E2F.2070008@freyther.de> <20100628101558.63137742@Luca> <20100628145256.799f9d2e@Luca> <20100629155531.GA17995@prithivi.gnumonks.org> <20100630083001.18b01a57@Luca> <4C2AF060.1090602@freyther.de> <20100630092528.1cb58e3d@Luca> <20100630160010.GR4876@prithivi.gnumonks.org> <20100701082638.79cb3e4f@Luca> <20100701083009.590708c2@Luca> <4C36EFAD.7080603@freyther.de> <20100709132250.4b2a8382@Luca> Message-ID: <4C3854DE.9060409@freyther.de> On 07/09/2010 07:22 PM, Luca Bertoncello wrote: > You can download the pcap-file from > http://www.lucabert.de/~lucabert/bscCantSMS.pcap.bz2 > > I hope, you can understand the problem now... Hi Luca, from a quick look you seem to be passed the Chan Act NACK issues, you try a MT SMS? and the phone does not 'send' it? is that right? What one can see in the trace is that the MS tries to send it again, again, and releases the SAPIs. Which phone is that? does it work with any other phone? From bertoncello at netzing.de Sun Jul 11 06:28:49 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Sun, 11 Jul 2010 08:28:49 +0200 Subject: [BUG REPORT]: Unable to send SMS In-Reply-To: <4C3854DE.9060409@freyther.de> References: <4C2207B9.9030300@freyther.de> <20100623151604.009bc143@Luca> <4C220E2F.2070008@freyther.de> <20100628101558.63137742@Luca> <20100628145256.799f9d2e@Luca> <20100629155531.GA17995@prithivi.gnumonks.org> <20100630083001.18b01a57@Luca> <4C2AF060.1090602@freyther.de> <20100630092528.1cb58e3d@Luca> <20100630160010.GR4876@prithivi.gnumonks.org> <20100701082638.79cb3e4f@Luca> <20100701083009.590708c2@Luca> <4C36EFAD.7080603@freyther.de> <20100709132250.4b2a8382@Luca> <4C3854DE.9060409@freyther.de> Message-ID: <20100711082849.64c1d8a6@frodo.lucabert.intra> Am Sat, 10 Jul 2010 19:09:18 +0800 schrieb Holger Hans Peter Freyther : Hi, Holger! > from a quick look you seem to be passed the Chan Act NACK issues, you > try a MT SMS? and the phone does not 'send' it? is that right? What > one can see in the trace is that the MS tries to send it again, > again, and releases the SAPIs. Yes! So it is! I think, I said that... > Which phone is that? does it work with any other phone? My phone is a Siemens S65v. I tried with other phones, too (Nokia, unknown model). Same problem... :( Thanks -- _________________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at 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 at netzing.de __________________________________________________________________________ From laforge at gnumonks.org Mon Jul 12 14:48:12 2010 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 12 Jul 2010 16:48:12 +0200 Subject: [BUG REPORT]: Unable to send SMS In-Reply-To: <20100711082849.64c1d8a6@frodo.lucabert.intra> References: <20100630083001.18b01a57@Luca> <4C2AF060.1090602@freyther.de> <20100630092528.1cb58e3d@Luca> <20100630160010.GR4876@prithivi.gnumonks.org> <20100701082638.79cb3e4f@Luca> <20100701083009.590708c2@Luca> <4C36EFAD.7080603@freyther.de> <20100709132250.4b2a8382@Luca> <4C3854DE.9060409@freyther.de> <20100711082849.64c1d8a6@frodo.lucabert.intra> Message-ID: <20100712144812.GJ28077@prithivi.gnumonks.org> Hi Luca, On Sun, Jul 11, 2010 at 08:28:49AM +0200, Luca Bertoncello wrote: > > Which phone is that? does it work with any other phone? > > My phone is a Siemens S65v. I tried with other phones, too (Nokia, > unknown model). Same problem... :( I have now tried the current version of libosmocore + openbsc and tested SMS with the following phones: * Nokia 3310 * HTC TyTN II * Google/Android G1 * Sony-Ericsson K800i * Motorola C123 It was working from all of them without any problem. I really cannot reproduce the problem you are experiencing at all. Can you please 1) make sure you do a full rebuild (make distclean; ./configure; make; make install) of both libosmocore and openbsc 2) send your openbsc.cfg that was used -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Mon Jul 12 15:07:23 2010 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 12 Jul 2010 17:07:23 +0200 Subject: [BUG REPORT]: Unable to send SMS In-Reply-To: <20100712144812.GJ28077@prithivi.gnumonks.org> References: <4C2AF060.1090602@freyther.de> <20100630092528.1cb58e3d@Luca> <20100630160010.GR4876@prithivi.gnumonks.org> <20100701082638.79cb3e4f@Luca> <20100701083009.590708c2@Luca> <4C36EFAD.7080603@freyther.de> <20100709132250.4b2a8382@Luca> <4C3854DE.9060409@freyther.de> <20100711082849.64c1d8a6@frodo.lucabert.intra> <20100712144812.GJ28077@prithivi.gnumonks.org> Message-ID: <20100712150722.GK28077@prithivi.gnumonks.org> On Mon, Jul 12, 2010 at 04:48:12PM +0200, Harald Welte wrote: > Hi Luca, > > On Sun, Jul 11, 2010 at 08:28:49AM +0200, Luca Bertoncello wrote: > > > Which phone is that? does it work with any other phone? > > > > My phone is a Siemens S65v. I tried with other phones, too (Nokia, > > unknown model). Same problem... :( > > I have now tried the current version of libosmocore + openbsc and tested > SMS with the following phones: > > * Nokia 3310 > * HTC TyTN II > * Google/Android G1 > * Sony-Ericsson K800i > * Motorola C123 I've also tested it with a Netzing NE110, and it is not able to send outgoing SMS messages. As discussed earlier, this phone really seems like it has a protocol bug. It sends a CM SERVICE REQUEST, we answer by CM SERVICE ACCEPT, and the phone never sends any follo-up message (such as establishing the SAPI3 connection or actually sending the SMS). I suppose nobody has tested this phone (or the underlying stack) with a GSM network that doesn't do authentication and/or encryption. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From bertoncello at netzing.de Tue Jul 13 07:12:03 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Tue, 13 Jul 2010 09:12:03 +0200 Subject: [BUG REPORT]: Unable to send SMS In-Reply-To: <20100712144812.GJ28077@prithivi.gnumonks.org> References: <20100630083001.18b01a57@Luca> <4C2AF060.1090602@freyther.de> <20100630092528.1cb58e3d@Luca> <20100630160010.GR4876@prithivi.gnumonks.org> <20100701082638.79cb3e4f@Luca> <20100701083009.590708c2@Luca> <4C36EFAD.7080603@freyther.de> <20100709132250.4b2a8382@Luca> <4C3854DE.9060409@freyther.de> <20100711082849.64c1d8a6@frodo.lucabert.intra> <20100712144812.GJ28077@prithivi.gnumonks.org> Message-ID: <20100713091203.58d83a8b@Luca> Am Mon, 12 Jul 2010 16:48:12 +0200 schrieb Harald Welte : > I have now tried the current version of libosmocore + openbsc and > tested SMS with the following phones: > > * Nokia 3310 > * HTC TyTN II > * Google/Android G1 > * Sony-Ericsson K800i > * Motorola C123 > > It was working from all of them without any problem. I really cannot > reproduce the problem you are experiencing at all. Can you please > > 1) make sure you do a full rebuild (make distclean; ./configure; > make; make install) of both libosmocore and openbsc > 2) send your openbsc.cfg that was used Hi, Harald! Thanks for your E-Mail. I just tried the last version from git of libosmocore and OpenBSC. I did a full rebuild in a new directory (no previous version). I tried to send an SMS with my Siemens S65v (today I have just that or NE110. No other phones...). Again not possible. Attached the pcap-file of the try and my config-file. I'm not sure what this "<0011> handover_logic.c:163 unable to find HO record" means (see below): lucabert at Luca:~/workspace/bscmanage/Debug$ /usr/local/sbin/bsc_hack -c lucabertBSC.cfg DB: Database initialized. DB: Database prepared. <000d> input/ipaccess.c:632 accept()ed new OML link from 192.168.1.107 <0005> bsc_init.c:737 bootstrapping OML for BTS 0 <000d> input/ipaccess.c:694 accept()ed new RSL link from 192.168.1.107 <0004> bsc_init.c:1010 bootstrapping RSL for BTS/TRX (0/0) on ARFCN 123 using MCC=1 MNC=1 LAC=1 CID=0 BSIC=63 TSC=7 <0011> handover_logic.c:163 unable to find HO record <0004> abis_rsl.c:942 (bts=0,trx=0,ts=0,ss=0): MEAS RES for inactive channel <0004> abis_rsl.c:1363 RF release on (bts=0,trx=0,ts=2,ss=0) but state ACTIVE <0004> abis_rsl.c:1051 (bts=0,trx=0,ts=2,ss=0) CHAN REL ACK but state ACTIVE <0004> abis_rsl.c:1363 RF release on (bts=0,trx=0,ts=2,ss=0) but state NONE <0004> abis_rsl.c:1051 (bts=0,trx=0,ts=2,ss=0) CHAN REL ACK but state NONE signal 2 received <0005> bsc_init.c:753 shutting down OML for BTS 0 If I see in the DB after trying to send the SMS I found: sqlite> select * from sms; id|created|sent|sender_id|receiver_id|deliver_attempts|valid_until|reply_path_req|status_rep_req|protocol_id|data_coding_scheme|ud_hdr_ind|dest_addr|user_data|header|text 53|2010-07-01 14:31:42||15|1|0|134727356|0|32|0|0|0|1000|?4||Ok 66|2010-07-02 06:56:16|2010-07-02 07:47:26|11|14|0|134721918|0|0|34|0|0|12345|@?||Abb 67|2010-07-02 06:56:35|2010-07-02 12:56:33|11|1|0|134721918|0|0|34|0|0|1000|@?||Abb ?||Test-07-13 06:43:02||11|1|0|134727872|0|0|34|0|0|1000|? ?||Test-07-13 06:43:14||11|1|0|134727872|0|0|34|0|0|1000|? ?||Test-07-13 06:43:28||11|1|0|134727872|0|0|34|0|0|1000|? (the first 3 SMS comes from a previous version of OpenBSC, that works). I use a nanoBTS900 and on my PC runs a KUbuntu Hardy (8.04). I tried the same on a Debian lenny (last version of libosmocore and OpenBSC, same configuration). Unfortunately, same result. Attached the pcap-file generated on the lenny-PC. Here what I see in the console of lenny: lucabert at debian503:/tmp$ /usr/local/sbin/bsc_hack -c /tmp/lucabertBSC.cfg DB: Database initialized. DB: Database prepared. <000d> input/ipaccess.c:632 accept()ed new OML link from 192.168.1.107 <0005> bsc_init.c:737 bootstrapping OML for BTS 0 <000d> input/ipaccess.c:694 accept()ed new RSL link from 192.168.1.107 <0004> bsc_init.c:1010 bootstrapping RSL for BTS/TRX (0/0) on ARFCN 123 using MCC=1 MNC=1 LAC=1 CID=0 BSIC=63 TSC=7 <0011> handover_logic.c:163 unable to find HO record <0004> abis_rsl.c:942 (bts=0,trx=0,ts=0,ss=0): MEAS RES for inactive channel <0004> bsc_api.c:99 Got data in non active state. discarding. <0004> abis_rsl.c:942 (bts=0,trx=0,ts=0,ss=0): MEAS RES for inactive channel <0004> abis_rsl.c:1363 RF release on (bts=0,trx=0,ts=2,ss=0) but state ACTIVE <0004> abis_rsl.c:1051 (bts=0,trx=0,ts=2,ss=0) CHAN REL ACK but state ACTIVE <0004> abis_rsl.c:1363 RF release on (bts=0,trx=0,ts=2,ss=0) but state NONE <0004> abis_rsl.c:1051 (bts=0,trx=0,ts=2,ss=0) CHAN REL ACK but state NONE ^Csignal 2 received <0005> bsc_init.c:753 shutting down OML for BTS 0 Thanks a lot for your answer Luca -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at 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 at netzing.de _______________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: lucabertBSC.cfg Type: application/octet-stream Size: 1673 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: hardy.pcap.bz2 Type: application/x-bzip Size: 50279 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: lenny.pcap.bz2 Type: application/x-bzip Size: 34795 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From laforge at gnumonks.org Tue Jul 13 14:06:55 2010 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 13 Jul 2010 16:06:55 +0200 Subject: [BUG REPORT]: Unable to send SMS In-Reply-To: <20100713091203.58d83a8b@Luca> References: <20100630092528.1cb58e3d@Luca> <20100630160010.GR4876@prithivi.gnumonks.org> <20100701082638.79cb3e4f@Luca> <20100701083009.590708c2@Luca> <4C36EFAD.7080603@freyther.de> <20100709132250.4b2a8382@Luca> <4C3854DE.9060409@freyther.de> <20100711082849.64c1d8a6@frodo.lucabert.intra> <20100712144812.GJ28077@prithivi.gnumonks.org> <20100713091203.58d83a8b@Luca> Message-ID: <20100713140655.GY28077@prithivi.gnumonks.org> Hi Luca, On Tue, Jul 13, 2010 at 09:12:03AM +0200, Luca Bertoncello wrote: > > I have now tried the current version of libosmocore + openbsc and > > tested SMS with the following phones: > > > > * Nokia 3310 > > * HTC TyTN II > > * Google/Android G1 > > * Sony-Ericsson K800i > > * Motorola C123 > > > > It was working from all of them without any problem. I really cannot > > reproduce the problem you are experiencing at all. Can you please > > > > 1) make sure you do a full rebuild (make distclean; ./configure; > > make; make install) of both libosmocore and openbsc > > 2) send your openbsc.cfg that was used > > Hi, Harald! > > Thanks for your E-Mail. > I just tried the last version from git of libosmocore and OpenBSC. > I did a full rebuild in a new directory (no previous version). > > I tried to send an SMS with my Siemens S65v (today I have just that or > NE110. No other phones...). Again not possible. I think one of the things you could ask from Netzing is to provide some more different phones to you for testing purpose. It's a small expense but should help us to identify if it is something related to your setup (i.e. your OpenBSC installation behaves different than ours), or it is related to the phones. I suggest you ask Mr. Schneider for an OK to buy some old Nokia 3310 off eBay, and possibly a SonyEricsson K800i. This is what I mostly use for testing. At least on GPRS, the K800i was particularly "picky" i.e. it would always refuse to work if OpenBSC/OsmoSGSN did anything wrong - which made it a good device for testing. 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. > I'm not sure what this "<0011> handover_logic.c:163 unable to find HO > record" means (see below): this is just a status message of the handover code that discovers this newly- established channel is not part of a handover procedure, but a channel for regular channel establishment. > I use a nanoBTS900 and on my PC runs a KUbuntu Hardy (8.04). Can you try the GSM1800 nanoBTS, and tell me the software/firmware version (as reported by ipaccess-config)? Holger, Dieter and myself all don't understand the problems you are experiencing, and it might be something that is different in your setup than ours (and we use GSM1800 nanoBTS). Sorry for taking so much time to resolve this, but it really is a big mystery. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From bertoncello at netzing.de Wed Jul 14 06:45:49 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Wed, 14 Jul 2010 08:45:49 +0200 Subject: [BUG REPORT]: Unable to send SMS In-Reply-To: <20100713140655.GY28077@prithivi.gnumonks.org> References: <20100630092528.1cb58e3d@Luca> <20100630160010.GR4876@prithivi.gnumonks.org> <20100701082638.79cb3e4f@Luca> <20100701083009.590708c2@Luca> <4C36EFAD.7080603@freyther.de> <20100709132250.4b2a8382@Luca> <4C3854DE.9060409@freyther.de> <20100711082849.64c1d8a6@frodo.lucabert.intra> <20100712144812.GJ28077@prithivi.gnumonks.org> <20100713091203.58d83a8b@Luca> <20100713140655.GY28077@prithivi.gnumonks.org> Message-ID: <20100714084549.3cc162d9@Luca> Am Tue, 13 Jul 2010 16:06:55 +0200 schrieb Harald Welte : Hi, Harald! > I suggest you ask Mr. Schneider for an OK to buy some old Nokia 3310 > off eBay, and possibly a SonyEricsson K800i. This is what I mostly > use for testing. At least on GPRS, the K800i was particularly > "picky" i.e. it would always refuse to work if OpenBSC/OsmoSGSN did > anything wrong - which made it a good device for testing. I just forwarded your E-Mail to Mr. Schneider. Thanks for the suggestion! > Can you try the GSM1800 nanoBTS, and tell me the software/firmware > version (as reported by ipaccess-config)? Holger, Dieter and myself > all don't understand the problems you are experiencing, and it might > be something that is different in your setup than ours (and we use > GSM1800 nanoBTS). 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: MAC Address='00:02:95:00:34:f8' IP Address='192.168.1.172' Unit ID='150/0/0' Location 1='NSAG Entw 1' Location 2='BTS_NBT131G' Equipment Version='165a029_48' Software Version='168a002_v141d0' Unit Name='BTS_140' Serial Number='00072269' > Sorry for taking so much time to resolve this, but it really is a big > mystery. Thank you for your help! Sometimes can bugs be very difficult to find... :D Bye -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at 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 at netzing.de _______________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: dsc1800.pcap.bz2 Type: application/x-bzip Size: 40329 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: lucabertBSC-2BS.cfg Type: application/octet-stream Size: 2368 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From spaar at mirider.augusta.de Tue Jul 13 23:09:18 2010 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Tue, 13 Jul 2010 23:09:18 CEST Subject: [BUG REPORT]: Unable to send SMS Message-ID: <4c3cf21e.mirider@mirider.augusta.de> Hello Harald, On Tue, 13 Jul 2010 16:06:55 +0200, "Harald Welte" 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 at mirider.augusta.de From bertoncello at netzing.de Wed Jul 14 06:55:36 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Wed, 14 Jul 2010 08:55:36 +0200 Subject: [BUG REPORT]: Unable to send SMS In-Reply-To: <4c3cf21e.mirider@mirider.augusta.de> References: <4c3cf21e.mirider@mirider.augusta.de> Message-ID: <20100714085536.7e1ab379@Luca> Am Tue, 13 Jul 2010 23:09:18 CEST schrieb "Dieter Spaar" : > 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. Hi, Dieter! Could you send me your configuration? I'd like to try it with my phone... Thanks a lot! Luca -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at 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 at netzing.de _______________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From laforge at gnumonks.org Wed Jul 14 10:01:35 2010 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 14 Jul 2010 12:01:35 +0200 Subject: [BUG REPORT]: Unable to send SMS In-Reply-To: <4c3cf21e.mirider@mirider.augusta.de> References: <4c3cf21e.mirider@mirider.augusta.de> Message-ID: <20100714100135.GJ16536@prithivi.gnumonks.org> Hi Dieter, On Tue, Jul 13, 2010 at 11:09:18PM +0200, Dieter Spaar wrote: > Hello Harald, > > On Tue, 13 Jul 2010 16:06:55 +0200, "Harald Welte" 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. Ah, ok. This of course is an interesting issue. > 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. The problem is that I could not see a very well-defined / unified behavior among all the various phoen models on what kind of "establishment cause" they send during the RACH request. So instead of assignign an SDCCH and later having to re-assing to a TCH after learning the phone wants to make a voice call, we always assing a TCH to the phone on any RACH request. Technically, according to the specification, a phone has no right to make any assumptions on the type of channel it will be assigned. So it is clearly a bug in the MTK GSM stack. However, the only real solution to this problem probably is to implement "late assignment" of the TCH, i.e. first send the IMM ASS to a SDCCH, and then do an additional ASSIGNMENT CMD to a TCH once we know the phone wants to make a call (and not send SMS). Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From spaar at mirider.augusta.de Wed Jul 14 09:00:28 2010 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Wed, 14 Jul 2010 09:00:28 CEST Subject: [BUG REPORT]: Unable to send SMS Message-ID: <4c3d7cac.mirider@mirider.augusta.de> Hello Luca, On Wed, 14 Jul 2010 08:45:49 +0200, "Luca Bertoncello" 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 at mirider.augusta.de From bertoncello at netzing.de Wed Jul 14 08:04:05 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Wed, 14 Jul 2010 10:04:05 +0200 Subject: [BUG REPORT]: Unable to send SMS In-Reply-To: <4c3d7cac.mirider@mirider.augusta.de> References: <4c3d7cac.mirider@mirider.augusta.de> Message-ID: <20100714100405.5dec3dde@Luca> Am Wed, 14 Jul 2010 09:00:28 CEST schrieb "Dieter Spaar" : > 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. Hi, Dieter! 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? I'll try some experiments later... Bye -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at 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 at netzing.de _______________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From spaar at mirider.augusta.de Wed Jul 14 11:04:01 2010 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Wed, 14 Jul 2010 11:04:01 CEST Subject: [BUG REPORT]: Unable to send SMS Message-ID: <4c3d99a1.mirider@mirider.augusta.de> Hello Luca, On Wed, 14 Jul 2010 10:04:05 +0200, "Luca Bertoncello" 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 at mirider.augusta.de From bertoncello at netzing.de Wed Jul 14 09:14:21 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Wed, 14 Jul 2010 11:14:21 +0200 Subject: [BUG REPORT]: Unable to send SMS In-Reply-To: <4c3d99a1.mirider@mirider.augusta.de> References: <4c3d99a1.mirider@mirider.augusta.de> Message-ID: <20100714111421.66e092be@Luca> Am Wed, 14 Jul 2010 11:04:01 CEST schrieb "Dieter Spaar" : Hi, Dieter! > 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). So the theory. Unfortunately (as always!) the practice is other... :D > 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. Aha! I did some tests, to know which Channel Requests are sent in the specific context, and I see that OpenBSC (with neci == 0!!) get 0xE5 or 0xE6 by calling and 0xE1 by SMS sending. Unfortunately, the mask is the same, and the function get_ctype_by_chreq can't decide what the phone says... Maybe an "if(ra == 0XE1)" will help to correct the problem, but it is a VERY BAD solution... > 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. I try with neci 1 in my config! Thanks a lot for the suggestion! -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at 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 at netzing.de _______________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bertoncello at netzing.de Wed Jul 14 09:22:05 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Wed, 14 Jul 2010 11:22:05 +0200 Subject: [BUG REPORT]: Unable to send SMS In-Reply-To: <20100714111421.66e092be@Luca> References: <4c3d99a1.mirider@mirider.augusta.de> <20100714111421.66e092be@Luca> Message-ID: <20100714112205.42dff24a@Luca> Am Wed, 14 Jul 2010 11:14:21 +0200 schrieb Luca Bertoncello : > > 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. > > I try with neci 1 in my config! Hi, all! I can confirm, that "neci 1" solve my problem! I can call and send SMS without any problem, from the NE110, too! Thanks Dieter! Your suggestion was VERY good! -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at 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 at netzing.de _______________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From spaar at mirider.augusta.de Wed Jul 14 11:08:57 2010 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Wed, 14 Jul 2010 11:08:57 CEST Subject: [BUG REPORT]: Unable to send SMS Message-ID: <4c3d9ac9.mirider@mirider.augusta.de> Hello Holger, On Wed, 14 Jul 2010 14:56:27 +0800, "Holger Hans Peter Freyther" 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 at mirider.augusta.de From holger at freyther.de Wed Jul 14 09:52:51 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Wed, 14 Jul 2010 17:52:51 +0800 Subject: [BUG REPORT]: Unable to send SMS In-Reply-To: <4c3d9ac9.mirider@mirider.augusta.de> References: <4c3d9ac9.mirider@mirider.augusta.de> Message-ID: <4C3D88F3.60504@freyther.de> On 07/14/2010 11:08 AM, Dieter Spaar wrote: > 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. Hi, 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. From spaar at mirider.augusta.de Wed Jul 14 11:56:54 2010 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Wed, 14 Jul 2010 11:56:54 CEST Subject: [BUG REPORT]: Unable to send SMS Message-ID: <4c3da606.mirider@mirider.augusta.de> Hello Luca, On Wed, 14 Jul 2010 11:22:05 +0200, "Luca Bertoncello" 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 at mirider.augusta.de From spaar at mirider.augusta.de Wed Jul 14 12:03:52 2010 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Wed, 14 Jul 2010 12:03:52 CEST Subject: [BUG REPORT]: Unable to send SMS Message-ID: <4c3da7a8.mirider@mirider.augusta.de> Hello Holger, On Wed, 14 Jul 2010 17:52:51 +0800, "Holger Hans Peter Freyther" 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 at mirider.augusta.de From holger at freyther.de Wed Jul 14 10:10:31 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Wed, 14 Jul 2010 18:10:31 +0800 Subject: [BUG REPORT]: Unable to send SMS In-Reply-To: <4c3da7a8.mirider@mirider.augusta.de> References: <4c3da7a8.mirider@mirider.augusta.de> Message-ID: <4C3D8D17.7030500@freyther.de> On 07/14/2010 12:03 PM, Dieter Spaar wrote: > 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 True, and our channel allocator will allocate a TCH/F if we have no (free) TCH/H available. Yeah, setting NECI=1 sounds like a possible workaround. I wonder if NECI=1 is set on real networks as well. :) From mortzy at gmail.com Wed Jul 7 12:16:37 2010 From: mortzy at gmail.com (Stephen Mortimer) Date: Wed, 7 Jul 2010 13:16:37 +0100 Subject: Working GSM1800 config for latest OpenBSC In-Reply-To: References: <4C2557CE.9050501@freyther.de> Message-ID: Thanks Sylvian, Removing the E1 config lines did the trick. Regards, Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.zahoransky at gmx.de Fri Jul 2 17:23:44 2010 From: r.zahoransky at gmx.de (Richard M. Zahoransky) Date: Fri, 02 Jul 2010 19:23:44 +0200 Subject: Segmentation fault while sending sms via bsc_hack_VTY In-Reply-To: <20100630160238.GS4876@prithivi.gnumonks.org> References: <20100630145554.32420@gmx.net> <20100630160238.GS4876@prithivi.gnumonks.org> Message-ID: <4C2E20A0.1050707@gmx.de> Harald Welte schrieb: > Hi Richard, > > your backtrace seems to indicate that you do not have an extension assigned > to the subscriber with ID 1. Sending SMS from VTY will be performed as if > it was sent from that 'magic' subscriber. > > Thank you all very much! it worked after I have created a subscriber with ID 1. Greetings, Richard From bogus@does.not.exist.com Thu Jul 1 22:02:36 2010 From: bogus@does.not.exist.com () Date: Fri, 02 Jul 2010 00:02:36 +0200 Subject: Cryptography VTY Bugreport References: <4C2A7B49.7010206@runningserver.com> Message-ID: Hi, On Wed, 30 Jun 2010 01:01:29 +0200, Philipp Fabian Benedikt Maier wrote: > 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. > As we have found out at #openbsc, this issue is related to x86 and x86_64 differences. Please find a patch attached which fixes the format string for subscriber_id in a couple of places in db.c. From cscan at gmx.net Thu Jul 1 22:48:03 2010 From: cscan at gmx.net (cscan at gmx.net) Date: Fri, 02 Jul 2010 00:48:03 +0200 Subject: Cryptography VTY Bugreport (patch inside) In-Reply-To: <20100701223008.3303gmx1@mx094.gmx.net> References: <4C2A7B49.7010206@runningserver.com> <20100701223008.3303gmx1@mx094.gmx.net> Message-ID: Sorry. Now with the patch file included. -------------- next part -------------- A non-text attachment was scrubbed... Name: db.c-subscriber_id.patch Type: application/octet-stream Size: 2643 bytes Desc: not available URL: From laforge at gnumonks.org Fri Jul 2 21:16:15 2010 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 2 Jul 2010 23:16:15 +0200 Subject: GPRS / OsmoSGSN status update Message-ID: <20100702211615.GC7039@prithivi.gnumonks.org> 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 http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From 246tnt at gmail.com Sat Jul 3 18:52:21 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sat, 3 Jul 2010 20:52:21 +0200 Subject: GPRS / OsmoSGSN status update In-Reply-To: <20100702211615.GC7039@prithivi.gnumonks.org> References: <20100702211615.GC7039@prithivi.gnumonks.org> Message-ID: Hi, > So everyone who has access to a nanoBTS: Try it now. I just tried it again, updating all the components. And unfortunately it seems it doesn't work for me anymore. osmo-sgsn says : <0016> gprs_bssgp.c:343 BSSGP TLLI=0xe7e2fc84 UPLINK-UNITDATA <0017> gprs_llc.c:410 LLC SAPI=1 C FCS=0xea1c55(WRONG) CMD=UI DATA several time when a phones tries to connect. I never used to have FCS errors before. VTY shows there is a mm-context but no pdp-context. Also several LLC entities. Not quite sure what's going on yet ... (my gprs knowledge is quite limited ATM) > The build/config > instructions haven't changed from what I described last time when I wrote > a GPRS status update to this list. There is also a howto here: http://openbsc.osmocom.org/trac/wiki/OpenBSC_GPRS Cheers, Sylvain From laforge at gnumonks.org Sat Jul 3 19:28:26 2010 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 3 Jul 2010 21:28:26 +0200 Subject: GPRS / OsmoSGSN status update In-Reply-To: References: <20100702211615.GC7039@prithivi.gnumonks.org> Message-ID: <20100703192826.GD19264@prithivi.gnumonks.org> Hi Sylvain, On Sat, Jul 03, 2010 at 08:52:21PM +0200, Sylvain Munaut wrote: > > So everyone who has access to a nanoBTS: Try it now. > > I just tried it again, updating all the components. > > And unfortunately it seems it doesn't work for me anymore. Just an update for the list: it has been fixed. I was using some length values for certain IEs to do input validation... and those length values came from 04.08 where 24.008 already has much longer lengths for those IEs. It's fixed now in master. > osmo-sgsn says : > > <0016> gprs_bssgp.c:343 BSSGP TLLI=0xe7e2fc84 UPLINK-UNITDATA > <0017> gprs_llc.c:410 LLC SAPI=1 C FCS=0xea1c55(WRONG) CMD=UI DATA this is a problem with the debug statement not with the actual code. will fix it soon. > VTY shows there is a mm-context but no pdp-context. Also several LLC entities. > > Not quite sure what's going on yet ... (my gprs knowledge is quite limited ATM) > > > > > The build/config > > instructions haven't changed from what I described last time when I wrote > > a GPRS status update to this list. > > There is also a howto here: http://openbsc.osmocom.org/trac/wiki/OpenBSC_GPRS good. Now we only need a actual wiki page for OsmoSGSN and its VTY commands. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Sun Jul 4 06:25:23 2010 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 4 Jul 2010 08:25:23 +0200 Subject: Segfault from Race condition when closing channel? Message-ID: <20100704062523.GF19264@prithivi.gnumonks.org> As horiz0n on IRC points out: 00:16 hehe, calling the c123 from my 9500 communicator crashes openbsc 00:17 here is the log http://notepad.cc/share/LQ3awCtXz9 00:21 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 http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From holger at freyther.de Sun Jul 4 07:23:45 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sun, 04 Jul 2010 15:23:45 +0800 Subject: Segfault from Race condition when closing channel? In-Reply-To: <20100704062523.GF19264@prithivi.gnumonks.org> References: <20100704062523.GF19264@prithivi.gnumonks.org> Message-ID: <4C303701.9060905@freyther.de> On 07/04/2010 02:25 PM, Harald Welte wrote: > So I think there are actually multiple bugs. > 1) the channel should not be released at that time Yeah, the MSC code should look at the request type of the CM Service Request and create a transaction (e.g. for SMS, CC) and start a timeout to terminate the transaction when nothing has happened. > 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. Well, it is a bug on a higher level. The MSC code decides to release the lchan because there is no transaction and operation left to execute, it calls the gsm0808_clear method which will free the subscriber_connection_data and will call lchan_release on all open lchan's. Now if more data is coming, the bsc_api code sees there is no connection inside the lchan and will create one and call the complete layer3 callback... and somehow the MSC code assumes that there is a subscriber set inside the subscriber_connection_data, which is not the case. Long story short, abis_rsl.c should probably not forward data when being in state REL_REQUEST and we should create a transaction for CC/SMS/USSD. From holger at freyther.de Mon Jul 5 07:45:51 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 05 Jul 2010 15:45:51 +0800 Subject: Segfault from Race condition when closing channel? In-Reply-To: <4C303701.9060905@freyther.de> References: <20100704062523.GF19264@prithivi.gnumonks.org> <4C303701.9060905@freyther.de> Message-ID: <4C318DAF.4080602@freyther.de> On 07/04/2010 03:23 PM, Holger Hans Peter Freyther wrote: > Long story short, abis_rsl.c should probably not forward data when being > in state REL_REQUEST and we should create a transaction for CC/SMS/USSD. Hi, I have done the following: 1.) In bsc_api.c only forward when the lchan->state is ACTIVE 2.) Create a dummy operation to keep the channel active in the beginning so we have five seconds for a transaction to handle it, I am releasing the "anchor" on the first CC/USSD/SMS/LU to free the channel fast. What should be done: We should create a transaction instead but I am not sure if we can derive the transaction id from the CM Service Request. Can we? From bertoncello at netzing.de Mon Jul 5 07:08:07 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Mon, 5 Jul 2010 09:08:07 +0200 Subject: Help by connecting OpenBSC with Asterisk Message-ID: <20100705090807.7c67c138@Luca> 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 at 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 at netzing.de _______________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From codec at muc.ccc.de Mon Jul 5 14:12:36 2010 From: codec at muc.ccc.de (codec) Date: Mon, 05 Jul 2010 16:12:36 +0200 Subject: Help by connecting OpenBSC with Asterisk In-Reply-To: <20100705090807.7c67c138@Luca> References: <20100705090807.7c67c138@Luca> Message-ID: <4C31E854.8080806@muc.ccc.de> Hi Luca, On 7/5/10 9:08 AM, Luca Bertoncello wrote: > 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? I use a E1 card because we run on a BS-11 microBTS where the E1 link provides general uplink and the ABIS protocol. You should be fine without it. > Maybe there is a running configuration of Asterisk I can use as example? 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). cheers, codec From 246tnt at gmail.com Mon Jul 5 16:44:20 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Mon, 5 Jul 2010 18:44:20 +0200 Subject: Help by connecting OpenBSC with Asterisk In-Reply-To: References: <20100705090807.7c67c138@Luca> <4C31E854.8080806@muc.ccc.de> Message-ID: > 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 From bouchtaoui at gmail.com Mon Jul 5 13:25:44 2010 From: bouchtaoui at gmail.com (Nordin) Date: Mon, 05 Jul 2010 15:25:44 +0200 Subject: Can't change nanoBTS id. Message-ID: <4C31DD58.3010902@gmail.com> 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. From holger at freyther.de Mon Jul 5 13:47:27 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 05 Jul 2010 21:47:27 +0800 Subject: Can't change nanoBTS id. In-Reply-To: <4C31DD58.3010902@gmail.com> References: <4C31DD58.3010902@gmail.com> Message-ID: <4C31E26F.9010800@freyther.de> On 07/05/2010 09:25 PM, Nordin wrote: > 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 > > <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 Hi Nordin, having a pcap file would be nice, what happens if you try 1802/0/0 as a unit id? does this work? From bouchtaoui at gmail.com Mon Jul 5 15:27:57 2010 From: bouchtaoui at gmail.com (Nordin) Date: Mon, 05 Jul 2010 17:27:57 +0200 Subject: Can't change nanoBTS id. In-Reply-To: <4C31E26F.9010800@freyther.de> References: <4C31DD58.3010902@gmail.com> <4C31E26F.9010800@freyther.de> Message-ID: <4C31F9FD.6080307@gmail.com> On 5-7-2010 15:47, Holger Hans Peter Freyther wrote: > > Hi Nordin, > > having a pcap file would be nice, what happens if you try 1802/0/0 as a > unit id? does this work? > > Hi Holger, Yes the 1800 part and the TRX part can be modified without any error, just the BTS part is a problem. But the strange thing is, it is working again after I rebuilt with debugging symbols. So I'll try to reproduce the problem... From bouchtaoui at gmail.com Mon Jul 5 15:40:32 2010 From: bouchtaoui at gmail.com (Nordin Bouchtaoui) Date: Mon, 5 Jul 2010 17:40:32 +0200 Subject: Can't change nanoBTS id. In-Reply-To: <4C31E26F.9010800@freyther.de> References: <4C31DD58.3010902@gmail.com> <4C31E26F.9010800@freyther.de> Message-ID: Hello Holger, Sorry I was mistaken, the problem still exist. I added a pcap file for wireshark, I hope you'll find usefull things in it. But have you tried it yourself, with the same result? regards, Nordin. 2010/7/5 Holger Hans Peter Freyther > On 07/05/2010 09:25 PM, Nordin wrote: > > 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 > > > > > <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 > > Hi Nordin, > > having a pcap file would be nice, what happens if you try 1802/0/0 as a > unit id? does this work? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bertoncello at netzing.de Wed Jul 7 08:24:33 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Wed, 7 Jul 2010 10:24:33 +0200 Subject: LCR crashes. Please help me! Message-ID: <20100707102433.3bb36baf@Luca> 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 at 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 at netzing.de _______________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Andreas.Eversberg at versatel.de Wed Jul 7 13:53:27 2010 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Wed, 7 Jul 2010 15:53:27 +0200 Subject: AW: LCR crashes. Please help me! Message-ID: 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 From bertoncello at netzing.de Mon Jul 12 14:28:19 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Mon, 12 Jul 2010 16:28:19 +0200 Subject: LCR crashes. Please help me! In-Reply-To: References: Message-ID: <20100712162819.4297bfc8@Luca> Am Wed, 7 Jul 2010 15:53:27 +0200 schrieb "Andreas.Eversberg" : > 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. Hi, I tried this version unfortunately unsuccessfully... When I try to call a mobile (from Twinkle or other VoIP-phone) I get this error: == Using SIP RTP CoS mark 5 -- Executing [12345 at btsctrl:1] Dial("SIP/debian503-00000006", "SIP/12345 at btsctrl,120") in new stack == Using SIP RTP CoS mark 5 [Jul 7 16:06:24] WARNING[24859]: chan_sip.c:5340 create_addr: No such host: btsctrl [Jul 7 16:06:24] WARNING[24859]: app_dial.c:1747 dial_exec_full: Unable to create channel of type 'SIP' (cause 20 - Unknown) == Everyone is busy/congested at this time (1:0/0/1) -- Auto fallthrough, channel 'SIP/debian503-00000006' status is 'CHANUNAVAIL' == Using SIP RTP CoS mark 5 In my sip.conf I have this: [debian503] type=friend username=debian503 md5secret=02e540ea7754341606ad6cf1b3c9e618 host=static context=btsctrl dtmfmode=inband and in extensions.conf this: [btsctrl] ;;exten => _X.,1,Set,CALLERID(num)=5552342 exten => _X.,1,dial(SIP/${EXTEN}@btsctrl,120) Can someone help me? Thanks a lot! -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at 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 at netzing.de _______________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From laforge at gnumonks.org Tue Jul 13 14:11:01 2010 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 13 Jul 2010 16:11:01 +0200 Subject: LCR crashes. Please help me! In-Reply-To: <20100712162819.4297bfc8@Luca> References: <20100712162819.4297bfc8@Luca> Message-ID: <20100713141101.GZ28077@prithivi.gnumonks.org> Dear Luca, On Mon, Jul 12, 2010 at 04:28:19PM +0200, Luca Bertoncello wrote: > When I try to call a mobile (from Twinkle or other VoIP-phone) I get > this error: > > == Using SIP RTP CoS mark 5 > -- Executing [12345 at btsctrl:1] Dial("SIP/debian503-00000006", "SIP/12345 at btsctrl,120") in new stack > == Using SIP RTP CoS mark 5 > [Jul 7 16:06:24] WARNING[24859]: chan_sip.c:5340 create_addr: No such host: btsctrl > [Jul 7 16:06:24] WARNING[24859]: app_dial.c:1747 dial_exec_full: Unable to create channel of type 'SIP' (cause 20 - Unknown) > == Everyone is busy/congested at this time (1:0/0/1) > -- Auto fallthrough, channel 'SIP/debian503-00000006' status is 'CHANUNAVAIL' > == Using SIP RTP CoS mark 5 1) Those error messages do not seem to relate to OpenBSC at all 2) Please look at them carefully Dial("SIP/debian503-00000006", "SIP/12345 at btsctrl,120" No such host: btsctrl Your program seems to want to establish a connection to the host "btsctrl" but that host does not seem to have a DNS or other name resolving entry, it thus fails to obtain an IP address and does not connect to wherever you want to connect to. Please keep this list on-topic, i.e. OpenBSC related, including OpenBSC + lcr. But people here have little interest in discussing Asterisk configuration. Thanks, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From bertoncello at netzing.de Wed Jul 14 07:52:13 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Wed, 14 Jul 2010 09:52:13 +0200 Subject: LCR crashes. Please help me! In-Reply-To: <20100713141101.GZ28077@prithivi.gnumonks.org> References: <20100712162819.4297bfc8@Luca> <20100713141101.GZ28077@prithivi.gnumonks.org> Message-ID: <20100714095213.05557cbe@Luca> Am Tue, 13 Jul 2010 16:11:01 +0200 schrieb Harald Welte : > 1) Those error messages do not seem to relate to OpenBSC at all > 2) Please look at them carefully > Dial("SIP/debian503-00000006", "SIP/12345 at btsctrl,120" > No such host: btsctrl > > Your program seems to want to establish a connection to the host > "btsctrl" but that host does not seem to have a DNS or other name > resolving entry, it thus fails to obtain an IP address and does not > connect to wherever you want to connect to. After the HowTo from http://openbsc.osmocom.org/trac/wiki/OpenBSC_LCR it should be the Asterisk-context. But I tried to add btsctrl in my /etc/hosts (with the IP of my PC), too. It makes a loop, and it does not work again. > Please keep this list on-topic, i.e. OpenBSC related, including > OpenBSC + lcr. But people here have little interest in discussing > Asterisk configuration. Thanks, I know, and I'm very sorry to annoying you with this question, but my Asterisk works (I can call VoIP-phones). It seems to be a problem of the integration between OpenBSC and LCR, or a problem of LCR. Has someone a running integration OpenBSC/Asterisk and can send to the configuration? Thanks -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at 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 at netzing.de _______________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bertoncello at netzing.de Fri Jul 16 07:42:09 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Fri, 16 Jul 2010 09:42:09 +0200 Subject: LCR crashes. Please help me! In-Reply-To: References: Message-ID: <20100716094209.27d86de5@Luca> Am Wed, 7 Jul 2010 15:53:27 +0200 schrieb "Andreas.Eversberg" : > 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 and Andreas! Today I debugged your program and I found the problem. OpenBSC, in his main(), initializes the struct bsc_api, but LCR does NOT make it! I wrote a patch. Here is it! Now it is possible to compile the last version of OpenBSC and LCR (from git) and to get them together working. Besides, the HowTo at http://openbsc.osmocom.org/trac/wiki/OpenBSC_LCR is for a OLD version of Asterisk and LCR/OpenBSC. 1) It is not necessary to change Makefile.am and gsm_audio.c 2) The option for configure is no more --with-gsm but --with-gsm-bs 3) In extensions.conf the right syntax is: [btsctrl] exten => _X.,1,Set,CALLERID(num)=5552342 exten => _X.,n,Dial(LCR/GSM/${EXTEN},120) I hope, this will help someone other trying to get OpenBSC and Asterisk working together! Regards -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at 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 at netzing.de _______________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: lcrOpenBSC.patch Type: text/x-patch Size: 590 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From holger at freyther.de Fri Jul 16 08:21:15 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Fri, 16 Jul 2010 16:21:15 +0800 Subject: LCR crashes. Please help me! In-Reply-To: <20100716094209.27d86de5@Luca> References: <20100716094209.27d86de5@Luca> Message-ID: <4C40167B.4000403@freyther.de> On 07/16/2010 03:42 PM, Luca Bertoncello wrote: > I hope, this will help someone other trying to get OpenBSC and Asterisk > working together! Hi, you could ask Harald to get a login to the trac and then you could change the page. :) From bouchtaoui at gmail.com Wed Jul 7 10:52:11 2010 From: bouchtaoui at gmail.com (Nordin) Date: Wed, 07 Jul 2010 12:52:11 +0200 Subject: nanobts sends no BCCH Message-ID: <4C345C5B.1030000@gmail.com> 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? From mortzy at gmail.com Wed Jul 7 12:11:25 2010 From: mortzy at gmail.com (Stephen Mortimer) Date: Wed, 7 Jul 2010 13:11:25 +0100 Subject: Fuzzing your GSM phone with OpenBSC and Scapy Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From openbsc at ngolde.de Thu Jul 8 15:56:18 2010 From: openbsc at ngolde.de (Nico Golde) Date: Thu, 8 Jul 2010 17:56:18 +0200 Subject: [PATCH] rewritten gsm 7 bit encoding Message-ID: <20100708155618.GA26411@pool.math.tu-berlin.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 From nico at ngolde.de Thu Jul 8 15:45:33 2010 From: nico at ngolde.de (Nico Golde) Date: Thu, 8 Jul 2010 17:45:33 +0200 Subject: [PATCH] * rewrite gsm_7bit_encode() based on a lookup table as the previous code produced wrong encodings for certain characters. Message-ID: --- include/osmocore/gsm_utils.h | 28 ++++++++++++++++++ src/gsm_utils.c | 64 ++++++++++++++++++++++++++++++++---------- 2 files changed, 77 insertions(+), 15 deletions(-) diff --git a/include/osmocore/gsm_utils.h b/include/osmocore/gsm_utils.h index 7dc2388..661846a 100644 --- a/include/osmocore/gsm_utils.h +++ b/include/osmocore/gsm_utils.h @@ -3,6 +3,7 @@ * (C) 2008 by Daniel Willmann * (C) 2009 by Holger Hans Peter Freyther * (C) 2009-2010 by Harald Welte + * (C) 2010 by Nico Golde * * All Rights Reserved * @@ -53,6 +54,33 @@ enum gsm_band { GSM_BAND_810 = 0x80, }; +/* ETSI GSM 03.38 6.2.1 and 6.2.1.1 default alphabet + * Greek symbols at hex positions 0x10 and 0x12-0x1a + * left out as they can't be handled with a char and + * since most phones don't display or write these + * characters this would only needlessly make the code + * more complex +*/ +unsigned char gsm_7bit_alphabet[] = { + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x0a, 0xff, 0x0a, 0x0d, 0xff, + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, + 0xff, 0xff, 0x20, 0x21, 0x22, 0x23, 0x02, 0x25, 0x26, 0x27, 0x28, 0x29, 0x2a, 0x2b, 0x2c, + 0x2d, 0x2e, 0x2f, 0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x38, 0x39, 0x3a, 0x3b, + 0x3c, 0x3d, 0x3e, 0x3f, 0x00, 0x41, 0x42, 0x43, 0x44, 0x45, 0x46, 0x47, 0x48, 0x49, 0x4a, + 0x4b, 0x4c, 0x4d, 0x4e, 0x4f, 0x50, 0x51, 0x52, 0x53, 0x54, 0x55, 0x56, 0x57, 0x58, 0x59, + 0x5a, 0x3c, 0x2f, 0x3e, 0x14, 0x11, 0xff, 0x61, 0x62, 0x63, 0x64, 0x65, 0x66, 0x67, 0x68, + 0x69, 0x6a, 0x6b, 0x6c, 0x6d, 0x6e, 0x6f, 0x70, 0x71, 0x72, 0x73, 0x74, 0x75, 0x76, 0x77, + 0x78, 0x79, 0x7a, 0x28, 0x40, 0x29, 0x3d, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x01, 0x24, + 0x03, 0xff, 0x5f, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x60, 0xff, 0xff, 0xff, + 0xff, 0x5b, 0x0e, 0x1c, 0x09, 0xff, 0x1f, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x5d, + 0xff, 0xff, 0xff, 0xff, 0x5c, 0xff, 0x0b, 0xff, 0xff, 0xff, 0x5e, 0xff, 0xff, 0x1e, 0x7f, + 0xff, 0xff, 0xff, 0x7b, 0x0f, 0x1d, 0xff, 0x04, 0x05, 0xff, 0xff, 0x07, 0xff, 0xff, 0xff, + 0xff, 0x7d, 0x08, 0xff, 0xff, 0xff, 0x7c, 0xff, 0x0c, 0x06, 0xff, 0xff, 0x7e, 0xff, 0xff +}; + const char *gsm_band_name(enum gsm_band band); enum gsm_band gsm_band_parse(const char *mhz); diff --git a/src/gsm_utils.c b/src/gsm_utils.c index dc97cef..f0b031d 100644 --- a/src/gsm_utils.c +++ b/src/gsm_utils.c @@ -2,6 +2,7 @@ * (C) 2008 by Daniel Willmann * (C) 2009 by Holger Hans Peter Freyther * (C) 2009-2010 by Harald Welte + * (C) 2010 by Nico Golde * * All Rights Reserved * @@ -53,33 +54,66 @@ int gsm_7bit_decode(char *text, const uint8_t *user_data, uint8_t length) return i - l; } +/* GSM 03.38 6.2.1 Prepare character packing */ +static int gsm_septet_encode(uint8_t *result, const char *data) +{ + int i, y = 0; + uint8_t ch; + for(i = 0; i < strlen(data); i++){ + ch = data[i]; + switch(ch){ + case 0x0c: + case 0x5e: + case 0x7b: + case 0x7d: + case 0x5c: + case 0x5b: + case 0x7e: + case 0x5d: + case 0x7c: + result[y] = 0x1b; + result[y + 1] = gsm_7bit_alphabet[ch]; + y++; + break; + default: + result[y] = gsm_7bit_alphabet[ch]; + break; + } + y++; + } -/* GSM 03.38 6.2.1 Charachter packing */ + return y; +} + +/* GSM 03.38 6.2.1 Character packing */ int gsm_7bit_encode(uint8_t *result, const char *data) { - int i,j = 0; - unsigned char ch1, ch2; + int i,y,z = 0; + /* prepare for the worst case, every character expanding to two bytes */ + uint8_t *rdata = calloc(strlen(data) * 2, sizeof(uint8_t)); + uint8_t cb, nb; int shift = 0; - for ( i=0; i> shift; - ch2 = data[(i+1)] & 0x7F; - ch2 = ch2 << (7-shift); + for(i = 0; i < y; i++) { + if(shift == 7 && i + 1 < y){ + shift = 0; + continue; + } - ch1 = ch1 | ch2; + cb = (rdata[i] & 0x7f) >> shift; + if(i + 1 < y){ + nb = (rdata[i + 1] & 0x7f) << (7 - shift); + cb = cb | nb; + } - result[j++] = ch1; + result[z++] = cb; shift++; - - if ((shift == 7) && (i+1 References: <20100708155618.GA26411@pool.math.tu-berlin.de> Message-ID: <4C35FC09.2090404@selfish.org> On 07/08/2010 11:56 PM, Nico Golde wrote: > > 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 :) The rule of thumb I heard is that anything above four lines of code is copyrightable, so your addition is totally fine! I do have two nitpicks though. We do not indent the case labels inside a switch statement and the other is more important to me, and might ask you to write a decoder, could you please update the encoding/decoding and add the string that could not be decoded by the current code? thanks From openbsc at lists.gnumonks.org Thu Jul 8 18:45:46 2010 From: openbsc at lists.gnumonks.org (Nico Golde) Date: Thu, 8 Jul 2010 20:45:46 +0200 Subject: [PATCH] rewritten gsm 7 bit encoding In-Reply-To: <4C35FC09.2090404@selfish.org> References: <20100708155618.GA26411@pool.math.tu-berlin.de> <4C35FC09.2090404@selfish.org> Message-ID: <20100708184546.GA28369@pool.math.tu-berlin.de> Hi, * Holger Freyther [2010-07-08 20:04]: > On 07/08/2010 11:56 PM, Nico Golde wrote: > > 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 :) > > The rule of thumb I heard is that anything above four lines > of code is copyrightable, so your addition is totally fine! Ok. > I do have two nitpicks though. We do not indent the case labels > inside a switch statement Fixed, attached. > and the other is more important to me, > and might ask you to write a decoder, could you please update > the encoding/decoding and add the string that could not be > decoded by the current code? I felt this was coming :) I didn't write the decoder yet as it was quite time consuming already to go through the encoding process and I personally didn't need the decoding yet. But I agree, of course a decoder that fits the encoder is necessary (even though what could be properly decoded before also can be properly decoded now, no change for this). And I'm also willing to write it as soon as I have more time. As a string my example was '@' which should be encoded as 00 (1 byte hex) but is encoded as 40 instead by the current code. Cheers Nico From nico at ngolde.de Thu Jul 8 18:14:17 2010 From: nico at ngolde.de (Nico Golde) Date: Thu, 8 Jul 2010 20:14:17 +0200 Subject: [PATCH] * rewrite gsm_7bit_encode() based on a lookup table as the previous code produced wrong encodings for certain characters. Message-ID: --- include/osmocore/gsm_utils.h | 28 ++++++++++++++++++ src/gsm_utils.c | 64 ++++++++++++++++++++++++++++++++---------- 2 files changed, 77 insertions(+), 15 deletions(-) diff --git a/include/osmocore/gsm_utils.h b/include/osmocore/gsm_utils.h index 7dc2388..661846a 100644 --- a/include/osmocore/gsm_utils.h +++ b/include/osmocore/gsm_utils.h @@ -3,6 +3,7 @@ * (C) 2008 by Daniel Willmann * (C) 2009 by Holger Hans Peter Freyther * (C) 2009-2010 by Harald Welte + * (C) 2010 by Nico Golde * * All Rights Reserved * @@ -53,6 +54,33 @@ enum gsm_band { GSM_BAND_810 = 0x80, }; +/* ETSI GSM 03.38 6.2.1 and 6.2.1.1 default alphabet + * Greek symbols at hex positions 0x10 and 0x12-0x1a + * left out as they can't be handled with a char and + * since most phones don't display or write these + * characters this would only needlessly make the code + * more complex +*/ +unsigned char gsm_7bit_alphabet[] = { + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x0a, 0xff, 0x0a, 0x0d, 0xff, + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, + 0xff, 0xff, 0x20, 0x21, 0x22, 0x23, 0x02, 0x25, 0x26, 0x27, 0x28, 0x29, 0x2a, 0x2b, 0x2c, + 0x2d, 0x2e, 0x2f, 0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x38, 0x39, 0x3a, 0x3b, + 0x3c, 0x3d, 0x3e, 0x3f, 0x00, 0x41, 0x42, 0x43, 0x44, 0x45, 0x46, 0x47, 0x48, 0x49, 0x4a, + 0x4b, 0x4c, 0x4d, 0x4e, 0x4f, 0x50, 0x51, 0x52, 0x53, 0x54, 0x55, 0x56, 0x57, 0x58, 0x59, + 0x5a, 0x3c, 0x2f, 0x3e, 0x14, 0x11, 0xff, 0x61, 0x62, 0x63, 0x64, 0x65, 0x66, 0x67, 0x68, + 0x69, 0x6a, 0x6b, 0x6c, 0x6d, 0x6e, 0x6f, 0x70, 0x71, 0x72, 0x73, 0x74, 0x75, 0x76, 0x77, + 0x78, 0x79, 0x7a, 0x28, 0x40, 0x29, 0x3d, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x01, 0x24, + 0x03, 0xff, 0x5f, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x60, 0xff, 0xff, 0xff, + 0xff, 0x5b, 0x0e, 0x1c, 0x09, 0xff, 0x1f, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x5d, + 0xff, 0xff, 0xff, 0xff, 0x5c, 0xff, 0x0b, 0xff, 0xff, 0xff, 0x5e, 0xff, 0xff, 0x1e, 0x7f, + 0xff, 0xff, 0xff, 0x7b, 0x0f, 0x1d, 0xff, 0x04, 0x05, 0xff, 0xff, 0x07, 0xff, 0xff, 0xff, + 0xff, 0x7d, 0x08, 0xff, 0xff, 0xff, 0x7c, 0xff, 0x0c, 0x06, 0xff, 0xff, 0x7e, 0xff, 0xff +}; + const char *gsm_band_name(enum gsm_band band); enum gsm_band gsm_band_parse(const char *mhz); diff --git a/src/gsm_utils.c b/src/gsm_utils.c index dc97cef..ce5cefd 100644 --- a/src/gsm_utils.c +++ b/src/gsm_utils.c @@ -2,6 +2,7 @@ * (C) 2008 by Daniel Willmann * (C) 2009 by Holger Hans Peter Freyther * (C) 2009-2010 by Harald Welte + * (C) 2010 by Nico Golde * * All Rights Reserved * @@ -53,33 +54,66 @@ int gsm_7bit_decode(char *text, const uint8_t *user_data, uint8_t length) return i - l; } +/* GSM 03.38 6.2.1 Prepare character packing */ +static int gsm_septet_encode(uint8_t *result, const char *data) +{ + int i, y = 0; + uint8_t ch; + for(i = 0; i < strlen(data); i++){ + ch = data[i]; + switch(ch){ + case 0x0c: + case 0x5e: + case 0x7b: + case 0x7d: + case 0x5c: + case 0x5b: + case 0x7e: + case 0x5d: + case 0x7c: + result[y] = 0x1b; + result[y + 1] = gsm_7bit_alphabet[ch]; + y++; + break; + default: + result[y] = gsm_7bit_alphabet[ch]; + break; + } + y++; + } -/* GSM 03.38 6.2.1 Charachter packing */ + return y; +} + +/* GSM 03.38 6.2.1 Character packing */ int gsm_7bit_encode(uint8_t *result, const char *data) { - int i,j = 0; - unsigned char ch1, ch2; + int i,y,z = 0; + /* prepare for the worst case, every character expanding to two bytes */ + uint8_t *rdata = calloc(strlen(data) * 2, sizeof(uint8_t)); + uint8_t cb, nb; int shift = 0; - for ( i=0; i> shift; - ch2 = data[(i+1)] & 0x7F; - ch2 = ch2 << (7-shift); + for(i = 0; i < y; i++) { + if(shift == 7 && i + 1 < y){ + shift = 0; + continue; + } - ch1 = ch1 | ch2; + cb = (rdata[i] & 0x7f) >> shift; + if(i + 1 < y){ + nb = (rdata[i + 1] & 0x7f) << (7 - shift); + cb = cb | nb; + } - result[j++] = ch1; + result[z++] = cb; shift++; - - if ((shift == 7) && (i+1 References: <20100708155618.GA26411@pool.math.tu-berlin.de> <4C35FC09.2090404@selfish.org> <20100708184546.GA28369@pool.math.tu-berlin.de> Message-ID: > (even though what could be properly decoded before > also can be properly decoded now, no change for this). Well, I think that before encode(decode(x)) == x because the 'errors' matched in encode and decode. Therefore message sent from GSM to GSM actually worked fine and only if you involved the VTY interface then it failed. But if they don't match anymore, then VTY -> GSM will work but GSM -> GSM will be broken. Sylvain From holger at freyther.de Fri Jul 9 09:19:41 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Fri, 09 Jul 2010 17:19:41 +0800 Subject: [PATCH] rewritten gsm 7 bit encoding In-Reply-To: References: <20100708155618.GA26411@pool.math.tu-berlin.de> <4C35FC09.2090404@selfish.org> <20100708184546.GA28369@pool.math.tu-berlin.de> Message-ID: <4C36E9AD.7020504@freyther.de> On 07/09/2010 04:58 AM, Sylvain Munaut wrote: >> (even though what could be properly decoded before >> also can be properly decoded now, no change for this). > > Well, I think that before > > encode(decode(x)) == x Hi all, if the decoder is too much work right now, you can change the test to only test encoding. So make it encode(x) == expected_result and add one test case for the string that was failing, convert the old decoding to decode(x) == expected_result as well. and you might feel like adding an expected failure (because the code is missing). The benefit of changing the test is that you can more easily convince me that the new code can do everything the old promised and is fixing something that didn't work with the old one. From openbsc at ngolde.de Fri Jul 9 16:56:30 2010 From: openbsc at ngolde.de (Nico Golde) Date: Fri, 9 Jul 2010 18:56:30 +0200 Subject: [PATCH] rewritten gsm 7 bit encoding In-Reply-To: <4C36E9AD.7020504@freyther.de> References: <20100708155618.GA26411@pool.math.tu-berlin.de> <4C35FC09.2090404@selfish.org> <20100708184546.GA28369@pool.math.tu-berlin.de> <4C36E9AD.7020504@freyther.de> Message-ID: <20100709165630.GA14587@pool.math.tu-berlin.de> Hi, * Holger Hans Peter Freyther [2010-07-09 13:00]: > On 07/09/2010 04:58 AM, Sylvain Munaut wrote: > >> (even though what could be properly decoded before > >> also can be properly decoded now, no change for this). > > > > Well, I think that before > > > > encode(decode(x)) == x > > if the decoder is too much work right now, you can change the test to > only test encoding. So make it encode(x) == expected_result and add one > test case for the string that was failing, convert the old decoding to > decode(x) == expected_result as well. and you might feel like adding an > expected failure (because the code is missing). > > The benefit of changing the test is that you can more easily convince me > that the new code can do everything the old promised and is fixing > something that didn't work with the old one. Alright, cleaned up the previous code a bit, implemented the decoder and added a test case which the previous code encoded incorrect. Please note that just using the new test case string in the old code will also pass the test even though the encoding is wrong. You need to compare the encoded values to e.g. output of pduspy[0]. Patch attached. Cheers Nico [0] http://www.nobbi.com/download/pduspy.zip From nico at ngolde.de Fri Jul 9 15:19:12 2010 From: nico at ngolde.de (Nico Golde) Date: Fri, 9 Jul 2010 17:19:12 +0200 Subject: [PATCH] * rewrite GSM 7bit default encoding/decoding based on a lookup table as the previous code produced wrong encodings for certain characters. Message-ID: --- include/osmocore/gsm_utils.h | 28 ++++++++++++ src/gsm_utils.c | 99 +++++++++++++++++++++++++++++++++-------- tests/sms/sms_test.c | 17 +++++++- 3 files changed, 123 insertions(+), 21 deletions(-) diff --git a/include/osmocore/gsm_utils.h b/include/osmocore/gsm_utils.h index 7dc2388..64f9edc 100644 --- a/include/osmocore/gsm_utils.h +++ b/include/osmocore/gsm_utils.h @@ -3,6 +3,7 @@ * (C) 2008 by Daniel Willmann * (C) 2009 by Holger Hans Peter Freyther * (C) 2009-2010 by Harald Welte + * (C) 2010 by Nico Golde * * All Rights Reserved * @@ -53,6 +54,33 @@ enum gsm_band { GSM_BAND_810 = 0x80, }; +/* ETSI GSM 03.38 6.2.1 and 6.2.1.1 default alphabet + * Greek symbols at hex positions 0x10 and 0x12-0x1a + * left out as they can't be handled with a char and + * since most phones don't display or write these + * characters this would only needlessly make the code + * more complex +*/ +unsigned char gsm_7bit_alphabet[] = { + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x0a, 0xff, 0xff, 0x0d, 0xff, + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, + 0xff, 0xff, 0x20, 0x21, 0x22, 0x23, 0x02, 0x25, 0x26, 0x27, 0x28, 0x29, 0x2a, 0x2b, 0x2c, + 0x2d, 0x2e, 0x2f, 0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x38, 0x39, 0x3a, 0x3b, + 0x3c, 0x3d, 0x3e, 0x3f, 0x00, 0x41, 0x42, 0x43, 0x44, 0x45, 0x46, 0x47, 0x48, 0x49, 0x4a, + 0x4b, 0x4c, 0x4d, 0x4e, 0x4f, 0x50, 0x51, 0x52, 0x53, 0x54, 0x55, 0x56, 0x57, 0x58, 0x59, + 0x5a, 0x3c, 0x2f, 0x3e, 0x14, 0x11, 0xff, 0x61, 0x62, 0x63, 0x64, 0x65, 0x66, 0x67, 0x68, + 0x69, 0x6a, 0x6b, 0x6c, 0x6d, 0x6e, 0x6f, 0x70, 0x71, 0x72, 0x73, 0x74, 0x75, 0x76, 0x77, + 0x78, 0x79, 0x7a, 0x28, 0x40, 0x29, 0x3d, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, + 0xff, 0xff, 0x0c, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x5e, 0xff, 0xff, + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x40, 0xff, 0x01, 0xff, + 0x03, 0xff, 0x7b, 0x7d, 0xff, 0xff, 0xff, 0xff, 0xff, 0x5c, 0xff, 0xff, 0xff, 0xff, 0xff, + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x5b, 0x7e, 0x5d, 0xff, 0x7c, 0xff, 0xff, 0xff, + 0xff, 0x5b, 0x0e, 0x1c, 0x09, 0xff, 0x1f, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x5d, + 0xff, 0xff, 0xff, 0xff, 0x5c, 0xff, 0x0b, 0xff, 0xff, 0xff, 0x5e, 0xff, 0xff, 0x1e, 0x7f, + 0xff, 0xff, 0xff, 0x7b, 0x0f, 0x1d, 0xff, 0x04, 0x05, 0xff, 0xff, 0x07, 0xff, 0xff, 0xff, + 0xff, 0x7d, 0x08, 0xff, 0xff, 0xff, 0x7c, 0xff, 0x0c, 0x06, 0xff, 0xff, 0x7e, 0xff, 0xff +}; + const char *gsm_band_name(enum gsm_band band); enum gsm_band gsm_band_parse(const char *mhz); diff --git a/src/gsm_utils.c b/src/gsm_utils.c index dc97cef..fb69377 100644 --- a/src/gsm_utils.c +++ b/src/gsm_utils.c @@ -2,6 +2,7 @@ * (C) 2008 by Daniel Willmann * (C) 2009 by Holger Hans Peter Freyther * (C) 2009-2010 by Harald Welte + * (C) 2010 by Nico Golde * * All Rights Reserved * @@ -34,52 +35,110 @@ #include "../config.h" -/* GSM 03.38 6.2.1 Charachter packing */ +/* GSM 03.38 6.2.1 Character lookup for decoding */ +static int gsm_septet_lookup(uint8_t ch) +{ + int i = 0; + for(; i < sizeof(gsm_7bit_alphabet); i++){ + if(gsm_7bit_alphabet[i] == ch) + return i; + } + return -1; +} + +/* GSM 03.38 6.2.1 Character unpacking */ int gsm_7bit_decode(char *text, const uint8_t *user_data, uint8_t length) { int i = 0; int l = 0; + uint8_t *rtext = calloc(length, sizeof(uint8_t)); + uint8_t tmp; - /* FIXME: We need to account for user data headers here */ + /* FIXME: We need to account for user data headers here */ i += l; - for (; i < length; i ++) - *(text ++) = + for (; i < length; i ++){ + rtext[i] = ((user_data[(i * 7 + 7) >> 3] << (7 - ((i * 7 + 7) & 7))) | (user_data[(i * 7) >> 3] >> ((i * 7) & 7))) & 0x7f; + } + for(i = 0; i < length; i++){ + /* this is an extension character */ + if(rtext[i] == 0x1b){ + tmp = rtext[i+1]; + *(text++) = gsm_7bit_alphabet[0x7f + tmp]; + i++; + continue; + } + + *(text++) = gsm_septet_lookup(rtext[i]); + } + *text = '\0'; + free(rtext); - return i - l; + return i; } +/* GSM 03.38 6.2.1 Prepare character packing */ +static int gsm_septet_encode(uint8_t *result, const char *data) +{ + int i, y = 0; + uint8_t ch; + for(i = 0; i < strlen(data); i++){ + ch = data[i]; + switch(ch){ + /* fall-through for extension characters */ + case 0x0c: + case 0x5e: + case 0x7b: + case 0x7d: + case 0x5c: + case 0x5b: + case 0x7e: + case 0x5d: + case 0x7c: + result[y++] = 0x1b; + default: + result[y] = gsm_7bit_alphabet[ch]; + break; + } + y++; + } -/* GSM 03.38 6.2.1 Charachter packing */ + return y; +} + +/* GSM 03.38 6.2.1 Character packing */ int gsm_7bit_encode(uint8_t *result, const char *data) { - int i,j = 0; - unsigned char ch1, ch2; + int i,y,z = 0; + /* prepare for the worst case, every character expanding to two bytes */ + uint8_t *rdata = calloc(strlen(data) * 2, sizeof(uint8_t)); + uint8_t cb, nb; int shift = 0; - for ( i=0; i> shift; - ch2 = data[(i+1)] & 0x7F; - ch2 = ch2 << (7-shift); + for(i = 0; i < y; i++) { + if(shift == 7 && i + 1 < y){ + shift = 0; + continue; + } - ch1 = ch1 | ch2; + cb = (rdata[i] & 0x7f) >> shift; + if(i + 1 < y){ + nb = (rdata[i + 1] & 0x7f) << (7 - shift); + cb = cb | nb; + } - result[j++] = ch1; + result[z++] = cb; shift++; - - if ((shift == 7) && (i+1 + * (C) 2010 by Nico Golde * All Rights Reserved * * This program is free software; you can redistribute it and/or modify @@ -32,7 +33,7 @@ int main(int argc, char** argv) uint8_t *sms; uint8_t i; - /* test 7-bit coding/decoding */ + /* test 7-bit coding/decoding */ const char *input = "test text"; uint8_t length; uint8_t coded[256]; @@ -43,5 +44,19 @@ int main(int argc, char** argv) if (strcmp(result, input) != 0) { printf("7 Bit coding failed... life sucks\n"); printf("Wanted: '%s' got '%s'\n", input, result); + return -1; } + + memset(coded, 0, sizeof(coded)); + memset(result, 0, sizeof(coded)); + input = strdup("!$ a more#^- complicated test@@?_\%! case"); + length = gsm_7bit_encode(coded, input); + gsm_7bit_decode(result, coded, length); + if (strcmp(result, input) != 0) { + printf("7 Bit coding failed... life sucks\n"); + printf("Wanted: '%s' got '%s'\n", input, result); + return -2; + } + + return 0; } -- 1.7.1 --ibTvN161/egqYuK8-- From holger at freyther.de Mon Jul 19 19:06:18 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Tue, 20 Jul 2010 03:06:18 +0800 Subject: [PATCH] rewritten gsm 7 bit encoding In-Reply-To: <20100709165630.GA14587@pool.math.tu-berlin.de> References: <20100708155618.GA26411@pool.math.tu-berlin.de> <4C35FC09.2090404@selfish.org> <20100708184546.GA28369@pool.math.tu-berlin.de> <4C36E9AD.7020504@freyther.de> <20100709165630.GA14587@pool.math.tu-berlin.de> Message-ID: <4C44A22A.5060205@freyther.de> On 07/10/2010 12:56 AM, Nico Golde wrote: > Alright, cleaned up the previous code a bit, implemented the > decoder and added a test case which the previous code > encoded incorrect. Please note that just using the new test > case string in the old code will also pass the test even > though the encoding is wrong. You need to compare the > encoded values to e.g. output of pduspy[0]. Patch attached. Hi Nico, I have finally applied your patch, thanks for poking me. I have also made two modifications. The first is to separate testing of encoding/decoding and comparing it to a byte array/string, the second is to fix a possible off by one. I used the current result of the encoding and there seems to be at least one more bug with our encoding routines. We append zero byte(s) at the end that are not touched by the encoding routine but covered by the length. A nice way to test this is to change the memset(something, 0 to memset(something, 23 and see how it is going to change. Would you be interested in changing that? From openbsc at ngolde.de Mon Jul 19 21:05:44 2010 From: openbsc at ngolde.de (Nico Golde) Date: Mon, 19 Jul 2010 23:05:44 +0200 Subject: [PATCH] rewritten gsm 7 bit encoding In-Reply-To: <4C44A22A.5060205@freyther.de> References: <20100708155618.GA26411@pool.math.tu-berlin.de> <4C35FC09.2090404@selfish.org> <20100708184546.GA28369@pool.math.tu-berlin.de> <4C36E9AD.7020504@freyther.de> <20100709165630.GA14587@pool.math.tu-berlin.de> <4C44A22A.5060205@freyther.de> Message-ID: <20100719210544.GA13264@pool.math.tu-berlin.de> Hi, * Holger Hans Peter Freyther [2010-07-19 22:13]: > On 07/10/2010 12:56 AM, Nico Golde wrote: > > Alright, cleaned up the previous code a bit, implemented the > > decoder and added a test case which the previous code > > encoded incorrect. Please note that just using the new test > > case string in the old code will also pass the test even > > though the encoding is wrong. You need to compare the > > encoded values to e.g. output of pduspy[0]. Patch attached. > > I have finally applied your patch, thanks for poking me. I have > also made two modifications. The first is to separate testing of > encoding/decoding and comparing it to a byte array/string, the > second is to fix a possible off by one. Good catch, I already had this fixed locally but was waiting with another patch until you have looked at this one. Will repost an update in case something like this occurs again to prevent this doubled work. > I used the current result of the encoding and there seems to > be at least one more bug with our encoding routines. We append > zero byte(s) at the end that are not touched by the encoding > routine but covered by the length. > > A nice way to test this is to change the memset(something, 0 to > memset(something, 23 and see how it is going to change. > > Would you be interested in changing that? I just looked into this and if I'm not mistaken this is no bug in the encoding but just a bug when comparing the encoded result. The current code memcmp's n bytes where n is the result of gsm_7bit_encode() with the input string bytewise. The problem with this is that the function returns the number of septets not octets. Attached is a patch for the test code that should fix this. Cheers Nico From nico at ngolde.de Mon Jul 19 21:01:50 2010 From: nico at ngolde.de (Nico Golde) Date: Mon, 19 Jul 2010 23:01:50 +0200 Subject: [PATCH] * when comparing the coded result with the expected coded values, do not compare n bytes where n is the result of gsm_7bit_encode() but the actual length of the input string as gsm_7bit_encode() returns the number of septets not octets Message-ID: --- tests/sms/sms_test.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/tests/sms/sms_test.c b/tests/sms/sms_test.c index 3742dd8..cab91ab 100644 --- a/tests/sms/sms_test.c +++ b/tests/sms/sms_test.c @@ -99,7 +99,7 @@ int main(int argc, char** argv) return -1; } - if (memcmp(coded, test_encode[i].expected, length) != 0) { + if (memcmp(coded, test_encode[i].expected, strlen(test_encode[i].expected)) != 0) { fprintf(stderr, "Encoded content does not match for %d\n", i); return -1; -- 1.7.1 --Kj7319i9nmIyA2yE-- From openbsc at ngolde.de Mon Jul 19 22:32:13 2010 From: openbsc at ngolde.de (Nico Golde) Date: Tue, 20 Jul 2010 00:32:13 +0200 Subject: [PATCH] rewritten gsm 7 bit encoding In-Reply-To: <20100719210544.GA13264@pool.math.tu-berlin.de> References: <20100708155618.GA26411@pool.math.tu-berlin.de> <4C35FC09.2090404@selfish.org> <20100708184546.GA28369@pool.math.tu-berlin.de> <4C36E9AD.7020504@freyther.de> <20100709165630.GA14587@pool.math.tu-berlin.de> <4C44A22A.5060205@freyther.de> <20100719210544.GA13264@pool.math.tu-berlin.de> Message-ID: <20100719223213.GE20955@ngolde.de> Hi, * Nico Golde [2010-07-20 00:29]: > * Holger Hans Peter Freyther [2010-07-19 22:13]: > > On 07/10/2010 12:56 AM, Nico Golde wrote: [...] > > I used the current result of the encoding and there seems to > > be at least one more bug with our encoding routines. We append > > zero byte(s) at the end that are not touched by the encoding > > routine but covered by the length. > > > > A nice way to test this is to change the memset(something, 0 to > > memset(something, 23 and see how it is going to change. > > > > Would you be interested in changing that? > > I just looked into this and if I'm not mistaken this is no > bug in the encoding but just a bug when comparing the > encoded result. The current code memcmp's n bytes where n is > the result of gsm_7bit_encode() with the input string > bytewise. The problem with this is that the function returns > the number of septets not octets. Attached is a patch for > the test code that should fix this. Sorry, forget what I wrote here, it's just wrong :) Cheers Nico From holger at freyther.de Tue Jul 20 08:02:07 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Tue, 20 Jul 2010 16:02:07 +0800 Subject: [PATCH] rewritten gsm 7 bit encoding In-Reply-To: <20100719210544.GA13264@pool.math.tu-berlin.de> References: <20100708155618.GA26411@pool.math.tu-berlin.de> <4C35FC09.2090404@selfish.org> <20100708184546.GA28369@pool.math.tu-berlin.de> <4C36E9AD.7020504@freyther.de> <20100709165630.GA14587@pool.math.tu-berlin.de> <4C44A22A.5060205@freyther.de> <20100719210544.GA13264@pool.math.tu-berlin.de> Message-ID: <4C4557FF.8030701@freyther.de> On 07/20/2010 05:05 AM, Nico Golde wrote: > I just looked into this and if I'm not mistaken this is no > bug in the encoding but just a bug when comparing the > encoded result. The current code memcmp's n bytes where n is > the result of gsm_7bit_encode() with the input string > bytewise. The problem with this is that the function returns > the number of septets not octets. Attached is a patch for > the test code that should fix this. Hi Nico, I don't think using strlen is correct. The gsm_7bit_encode method makes no promise that the result will have a null byte at the end, in fact nothing in this method will add a null byte, and the null byte in the output is only present because of memset in the calling method. I think gsm_7bit_encode should return the length of bytes it has written to, not more. :) PS: The gsm_7bit_encode usage in gsm_04_08.c is wrong. :) From openbsc at ngolde.de Tue Jul 20 11:04:52 2010 From: openbsc at ngolde.de (Nico Golde) Date: Tue, 20 Jul 2010 13:04:52 +0200 Subject: [PATCH] rewritten gsm 7 bit encoding In-Reply-To: <4C4557FF.8030701@freyther.de> References: <20100708155618.GA26411@pool.math.tu-berlin.de> <4C35FC09.2090404@selfish.org> <20100708184546.GA28369@pool.math.tu-berlin.de> <4C36E9AD.7020504@freyther.de> <20100709165630.GA14587@pool.math.tu-berlin.de> <4C44A22A.5060205@freyther.de> <20100719210544.GA13264@pool.math.tu-berlin.de> <4C4557FF.8030701@freyther.de> Message-ID: <20100720110452.GA2172@pool.math.tu-berlin.de> Hi, * Holger Hans Peter Freyther [2010-07-20 13:03]: > On 07/20/2010 05:05 AM, Nico Golde wrote: > > I just looked into this and if I'm not mistaken this is no > > bug in the encoding but just a bug when comparing the > > encoded result. The current code memcmp's n bytes where n is > > the result of gsm_7bit_encode() with the input string > > bytewise. The problem with this is that the function returns > > the number of septets not octets. Attached is a patch for > > the test code that should fix this. > > I don't think using strlen is correct. The gsm_7bit_encode > method makes no promise that the result will have a null > byte at the end, in fact nothing in this method will add a > null byte, and the null byte in the output is only present > because of memset in the calling method. Yeah, realized this after writing, hence the second reply. > I think gsm_7bit_encode should return the length of bytes > it has written to, not more. :) Yes and I think this is part of the problem. Currently the function returns i instead of z while z is the counter for the bytes actually written and i the number of encoded septets. I will probably look into this at the weekend. Cheers Nico From openbsc at ngolde.de Tue Jul 20 13:49:32 2010 From: openbsc at ngolde.de (Nico Golde) Date: Tue, 20 Jul 2010 15:49:32 +0200 Subject: [PATCH] rewritten gsm 7 bit encoding In-Reply-To: <20100720110452.GA2172@pool.math.tu-berlin.de> References: <20100708155618.GA26411@pool.math.tu-berlin.de> <4C35FC09.2090404@selfish.org> <20100708184546.GA28369@pool.math.tu-berlin.de> <4C36E9AD.7020504@freyther.de> <20100709165630.GA14587@pool.math.tu-berlin.de> <4C44A22A.5060205@freyther.de> <20100719210544.GA13264@pool.math.tu-berlin.de> <4C4557FF.8030701@freyther.de> <20100720110452.GA2172@pool.math.tu-berlin.de> Message-ID: <20100720134932.GA18756@pool.math.tu-berlin.de> Hi, * Nico Golde [2010-07-20 14:10]: > * Holger Hans Peter Freyther [2010-07-20 13:03]: [...] > > On 07/20/2010 05:05 AM, Nico Golde wrote: > > I think gsm_7bit_encode should return the length of bytes > > it has written to, not more. :) > > Yes and I think this is part of the problem. Currently the > function returns i instead of z while z is the counter for > the bytes actually written and i the number of encoded > septets. I will probably look into this at the weekend. Ok had some time now. Please check the attached patch. Cheers Nico From nico at ngolde.de Tue Jul 20 13:43:58 2010 From: nico at ngolde.de (Nico Golde) Date: Tue, 20 Jul 2010 15:43:58 +0200 Subject: [PATCH] tests: don't hardcode length values of expected encoding gsm_7bit_encode: make sure to return the number of actually written bytes gsm_7bit_decode: calculate length of resulting septets from input length before decoding Message-ID: The input length to gsm_7bit_decode reflects the number of encoded bytes to be decoded. As the decoding is done on the input in septetes we need to take this into account and recalculate the length. --- src/gsm_utils.c | 10 ++++++---- tests/sms/sms_test.c | 21 ++++++++++----------- 2 files changed, 16 insertions(+), 15 deletions(-) diff --git a/src/gsm_utils.c b/src/gsm_utils.c index 3a378ac..818655e 100644 --- a/src/gsm_utils.c +++ b/src/gsm_utils.c @@ -49,21 +49,23 @@ static int gsm_septet_lookup(uint8_t ch) /* GSM 03.38 6.2.1 Character unpacking */ int gsm_7bit_decode(char *text, const uint8_t *user_data, uint8_t length) { - int i = 0; + int i = 0,y; int l = 0; + int septet_l = (length * 8) / 7; uint8_t *rtext = calloc(length, sizeof(uint8_t)); uint8_t tmp; /* FIXME: We need to account for user data headers here */ i += l; - for (; i < length; i ++){ + for (; i < septet_l; i++){ rtext[i] = ((user_data[(i * 7 + 7) >> 3] << (7 - ((i * 7 + 7) & 7))) | (user_data[(i * 7) >> 3] >> ((i * 7) & 7))) & 0x7f; } - for(i = 0; i < length; i++){ + + for(i = 0; i < septet_l; i++){ /* this is an extension character */ if(rtext[i] == 0x1b && i + 1 < length){ tmp = rtext[i+1]; @@ -139,7 +141,7 @@ int gsm_7bit_encode(uint8_t *result, const char *data) } free(rdata); - return i; + return z; } /* determine power control level for given dBm value, as indicated diff --git a/tests/sms/sms_test.c b/tests/sms/sms_test.c index 3742dd8..9d87b5b 100644 --- a/tests/sms/sms_test.c +++ b/tests/sms/sms_test.c @@ -37,7 +37,7 @@ struct test_case { static const char simple_text[] = "test text"; static const uint8_t simple_enc[] = { - 0xf4, 0xf2, 0x9c, 0x0e, 0xa2, 0x97, 0xf1, 0x74, 0x00, + 0xf4, 0xf2, 0x9c, 0x0e, 0xa2, 0x97, 0xf1, 0x74 }; static const char escape_text[] = "!$ a more#^- complicated test@@?_\%! case"; @@ -46,7 +46,6 @@ static const uint8_t escape_enc[] = { 0x86, 0xd2, 0x02, 0x8d, 0xdf, 0x6d, 0x38, 0x3b, 0x3d, 0x0e, 0xd3, 0xcb, 0x64, 0x10, 0xbd, 0x3c, 0xa7, 0x03, 0x00, 0xbf, 0x48, 0x29, 0x04, 0x1a, 0x87, 0xe7, 0x65, - 0x00, 0x00, 0x00, 0x00, 0x00 }; static const struct test_case test_encode[] = @@ -54,12 +53,12 @@ static const struct test_case test_encode[] = { .input = simple_text, .expected = simple_enc, - .expected_length = 9, + .expected_length = sizeof(simple_enc), }, { .input = escape_text, .expected = escape_enc, - .expected_length = 41, + .expected_length = sizeof(escape_enc), }, }; @@ -67,12 +66,12 @@ static const struct test_case test_decode[] = { { .input = simple_enc, - .input_length = 9, + .input_length = sizeof(simple_enc), .expected = simple_text, }, { .input = escape_enc, - .input_length = 41, + .input_length = sizeof(escape_enc), .expected = escape_text, }, }; @@ -89,13 +88,13 @@ int main(int argc, char** argv) char result[256]; /* test 7-bit encoding */ - for (i = 0; i < ARRAY_SIZE(test_encode); ++i) { - memset(coded, 0, sizeof(coded)); + for (i = 0; i < ARRAY_SIZE(test_encode); ++i) { + memset(coded, 0x42, sizeof(coded)); length = gsm_7bit_encode(coded, test_encode[i].input); if (length != test_encode[i].expected_length) { - fprintf(stderr, "Failed to encode case %d. Got %d\n", - i, length); + fprintf(stderr, "Failed to encode case %d. Got %d, expected %d\n", + i, length, test_encode[i].expected_length); return -1; } @@ -108,7 +107,7 @@ int main(int argc, char** argv) /* test 7-bit decoding */ for (i = 0; i < ARRAY_SIZE(test_decode); ++i) { - memset(result, 0, sizeof(coded)); + memset(result, 0x42, sizeof(coded)); gsm_7bit_decode(result, test_decode[i].input, test_decode[i].input_length); -- 1.7.1 --7JfCtLOvnd9MIVvH-- From holger at freyther.de Tue Jul 20 13:53:28 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Tue, 20 Jul 2010 21:53:28 +0800 Subject: [PATCH] rewritten gsm 7 bit encoding In-Reply-To: <20100720134932.GA18756@pool.math.tu-berlin.de> References: <20100708155618.GA26411@pool.math.tu-berlin.de> <4C35FC09.2090404@selfish.org> <20100708184546.GA28369@pool.math.tu-berlin.de> <4C36E9AD.7020504@freyther.de> <20100709165630.GA14587@pool.math.tu-berlin.de> <4C44A22A.5060205@freyther.de> <20100719210544.GA13264@pool.math.tu-berlin.de> <4C4557FF.8030701@freyther.de> <20100720110452.GA2172@pool.math.tu-berlin.de> <20100720134932.GA18756@pool.math.tu-berlin.de> Message-ID: <4C45AA58.6040303@freyther.de> On 07/20/2010 09:49 PM, Nico Golde wrote: > Ok had some time now. Please check the attached patch. looks fine, I will apply it by tonight. From holger at freyther.de Tue Jul 20 19:15:47 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Wed, 21 Jul 2010 03:15:47 +0800 Subject: [PATCH] rewritten gsm 7 bit encoding In-Reply-To: <4C45AA58.6040303@freyther.de> References: <20100708155618.GA26411@pool.math.tu-berlin.de> <4C35FC09.2090404@selfish.org> <20100708184546.GA28369@pool.math.tu-berlin.de> <4C36E9AD.7020504@freyther.de> <20100709165630.GA14587@pool.math.tu-berlin.de> <4C44A22A.5060205@freyther.de> <20100719210544.GA13264@pool.math.tu-berlin.de> <4C4557FF.8030701@freyther.de> <20100720110452.GA2172@pool.math.tu-berlin.de> <20100720134932.GA18756@pool.math.tu-berlin.de> <4C45AA58.6040303@freyther.de> Message-ID: <4C45F5E3.4050105@freyther.de> On 07/20/2010 09:53 PM, Holger Hans Peter Freyther wrote: > On 07/20/2010 09:49 PM, Nico Golde wrote: > >> Ok had some time now. Please check the attached patch. > > looks fine, I will apply it by tonight. > I have pushed the patch, two small issues were left, please verify that I have done this correctly: 1.) y was unused in decode, I removed it 2.) rtext should be as big as septext_l (i made it one bigger for a null byte but that is not needed). z. From openbsc at ngolde.de Tue Jul 20 20:32:26 2010 From: openbsc at ngolde.de (Nico Golde) Date: Tue, 20 Jul 2010 22:32:26 +0200 Subject: [PATCH] rewritten gsm 7 bit encoding In-Reply-To: <4C45F5E3.4050105@freyther.de> References: <4C36E9AD.7020504@freyther.de> <20100709165630.GA14587@pool.math.tu-berlin.de> <4C44A22A.5060205@freyther.de> <20100719210544.GA13264@pool.math.tu-berlin.de> <4C4557FF.8030701@freyther.de> <20100720110452.GA2172@pool.math.tu-berlin.de> <20100720134932.GA18756@pool.math.tu-berlin.de> <4C45AA58.6040303@freyther.de> <4C45F5E3.4050105@freyther.de> Message-ID: <20100720203226.GA826@pool.math.tu-berlin.de> Hi, * Holger Hans Peter Freyther [2010-07-20 22:08]: > On 07/20/2010 09:53 PM, Holger Hans Peter Freyther wrote: > > On 07/20/2010 09:49 PM, Nico Golde wrote: > > > >> Ok had some time now. Please check the attached patch. > > > > looks fine, I will apply it by tonight. > > I have pushed the patch, two small issues were left, please > verify that I have done this correctly: > > 1.) y was unused in decode, I removed it Meh I thought I already removed this :) > 2.) rtext should be as big as septext_l (i made it > one bigger for a null byte but that is not needed). Correct. Cheers Nico From laforge at gnumonks.org Fri Jul 9 11:20:26 2010 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 9 Jul 2010 13:20:26 +0200 Subject: [PATCH] rewritten gsm 7 bit encoding In-Reply-To: References: <20100708155618.GA26411@pool.math.tu-berlin.de> <4C35FC09.2090404@selfish.org> <20100708184546.GA28369@pool.math.tu-berlin.de> Message-ID: <20100709112026.GV22836@prithivi.gnumonks.org> On Thu, Jul 08, 2010 at 10:58:42PM +0200, Sylvain Munaut wrote: > > (even though what could be properly decoded before > > also can be properly decoded now, no change for this). > > Well, I think that before > > encode(decode(x)) == x > > because the 'errors' matched in encode and decode. Therefore message > sent from GSM to GSM actually worked fine and only if you involved the > VTY interface then it failed. ACK. > But if they don't match anymore, then VTY -> GSM will work but GSM -> > GSM will be broken. The idea of storing a plaintext version and the binary-encoded TPDU inside the SQL database was exactly to solve this. the plaintext/UTF8 version is intended for human readers, but if we have the BLOB from a MO SMS (or an external application writing to the database), then that very same unmodified BLOB should be sent to the other MS as part of the MT SMS. So whatever modifications we make, we should keep in mind that the transparent MO-SMS to MT-SMS path remains unharmed. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Fri Jul 9 07:55:43 2010 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 9 Jul 2010 09:55:43 +0200 Subject: New utility for drawing protocol ladder diagrams Message-ID: <20100709075543.GM22836@prithivi.gnumonks.org> 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 http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) -------------- next part -------------- [entities] # define the entities in the system (in order) ms bts bsc # msc means MSC + VLR msc hlr [messages] # define the protocol messages in-order ms bts "L1 RACH burst" bts bsc "RSL CHAN RQD" bsc bts "RSL CHAN ACT REQ" bts bsc "RSL CHAN ACT ACK" bsc bts "RSL IMM ASS CMD" bts ms "IMMEDIATE ASSIGN" ms bsc "MM LOC UPD REQ" bsc msc "COMPL L3 INFO (LOC UPD REQ)" msc ms "MM IDENTITY REQUEST" ms msc "MM IDENTITY RESPONSE" msc hlr "MAP SEND AUTH INFO req" hlr msc "MAP SEND AUTH INFO resp" msc ms "MM AUTH REQ" ms msc "MM AUTH RESP" msc hlr "MAP UPD LOC AREA req" hlr msc "MAP INSERT SUBSCR DATA req" msc hlr "MAP INSERT SUBSCR DATA resp" hlr msc "MAP UPD LOC AREA resp" ms msc "Dedicated Channel" both dashed -------------- next part -------------- A non-text attachment was scrubbed... Name: location_update.ps Type: application/postscript Size: 40697 bytes Desc: not available URL: From bertoncello at netzing.de Wed Jul 14 13:55:15 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Wed, 14 Jul 2010 15:55:15 +0200 Subject: OpenBSC+LCR+Asterisk: I got it! Message-ID: <20100714155515.31827c02@Luca> 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 at 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 at netzing.de _______________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Andreas.Eversberg at versatel.de Mon Jul 26 08:26:14 2010 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Mon, 26 Jul 2010 10:26:14 +0200 Subject: AW: OpenBSC+LCR+Asterisk: I got it! Message-ID: 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... From Andreas.Eversberg at versatel.de Mon Jul 26 08:33:45 2010 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Mon, 26 Jul 2010 10:33:45 +0200 Subject: AW: OpenBSC+LCR+Asterisk: I got it! Message-ID: 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... From laforge at gnumonks.org Sun Jul 18 20:09:38 2010 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 18 Jul 2010 22:09:38 +0200 Subject: RFC about Osmcoom TCAP / MAP implementation Message-ID: <20100718200938.GH14598@prithivi.gnumonks.org> 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 http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) -------------- next part -------------- A non-text attachment was scrubbed... Name: map_client_server.ps.gz Type: application/octet-stream Size: 9542 bytes Desc: not available URL: From laforge at gnumonks.org Sun Jul 18 20:36:15 2010 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 18 Jul 2010 22:36:15 +0200 Subject: RFC about Osmcoom TCAP / MAP implementation In-Reply-To: <20100718200938.GH14598@prithivi.gnumonks.org> References: <20100718200938.GH14598@prithivi.gnumonks.org> Message-ID: <20100718203615.GI14598@prithivi.gnumonks.org> Hi again, Attached to this mail you can find a more practical example of what I believe is the correct flow of primitives in a real-world location updating procedure between a SGSN (or MSC) and the HLR. As you can see, there are two linked invocations/transactions: 1) the actual location updating request (SGSN/MSC -> HLR) 2) the 'insert subscriber data' transaction that is triggered (HLR -> SGSN) 3) the complation of the location updating request after the insert subscriber data has been completed. It's actually quite "impressive" to see how much needs to happen for such a relatively simple task. The MAP-DELIMITER.ind is generated locally by the MAP-provider to the map user to indicate that it has finished sending all primitives for one incoming TCAP message/packet/pdu. It is used as a means of synchronization, to which the MAP-User then typically responds with a MAP-DELIMITER.req which in turn triggers the transmission of all queued primitives in a response message. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) -------------- next part -------------- A non-text attachment was scrubbed... Name: map_loc_upd.ps.gz Type: application/octet-stream Size: 11793 bytes Desc: not available URL: From mosbah.abdelkader at gmail.com Sun Jul 18 21:45:48 2010 From: mosbah.abdelkader at gmail.com (mosbah abdelkader) Date: Sun, 18 Jul 2010 22:45:48 +0100 Subject: RFC about Osmcoom TCAP / MAP implementation Message-ID: Hello, Is the source code made public. -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Mon Jul 19 11:25:33 2010 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 19 Jul 2010 13:25:33 +0200 Subject: RFC about Osmcoom TCAP / MAP implementation In-Reply-To: References: Message-ID: <20100719112533.GL14598@prithivi.gnumonks.org> On Sun, Jul 18, 2010 at 10:45:48PM +0100, mosbah abdelkader wrote: > Is the source code made public. Are you joking? this is an open source project! libasn1c, libomso-asn1-tcap and libosmo-tcap from http://git.osmocom.org/gitweb/ Please note: This is very EARLY DEVELOPMENT code. It is not useful for anyone to play withit, unless you want to help the development effort. I will not answer any questions on how to use it, how to compile it or how to do anything else with it until I consider it reasonably well finished. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From mosbah.abdelkader at gmail.com Mon Jul 19 11:32:08 2010 From: mosbah.abdelkader at gmail.com (mosbah abdelkader) Date: Mon, 19 Jul 2010 13:32:08 +0200 Subject: RFC about Osmcoom TCAP / MAP implementation In-Reply-To: <20100719112533.GL14598@prithivi.gnumonks.org> References: <20100719112533.GL14598@prithivi.gnumonks.org> Message-ID: No, I am not joking. I only havn't discovered the url of the code. Now it is Ok. I am a telecommunications engineer and I will be very happy to contribute in such a project. Is that possible. Best regards. On Mon, Jul 19, 2010 at 1:25 PM, Harald Welte wrote: > On Sun, Jul 18, 2010 at 10:45:48PM +0100, mosbah abdelkader wrote: > > > Is the source code made public. > > Are you joking? this is an open source project! > > libasn1c, libomso-asn1-tcap and libosmo-tcap from > http://git.osmocom.org/gitweb/ > > Please note: This is very EARLY DEVELOPMENT code. It is not useful for > anyone to play withit, unless you want to help the development effort. > > I will not answer any questions on how to use it, how to compile it or how > to do anything else with it until I consider it reasonably well finished. > > -- > - Harald Welte > http://laforge.gnumonks.org/ > > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bertoncello at netzing.de Wed Jul 21 12:37:29 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Wed, 21 Jul 2010 14:37:29 +0200 Subject: Switch with PowerOverEthernet for a BaseStation Message-ID: <20100721143729.64a510fc@Luca> 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 at 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 at netzing.de _______________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From 246tnt at gmail.com Wed Jul 21 13:16:54 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 21 Jul 2010 15:16:54 +0200 Subject: Switch with PowerOverEthernet for a BaseStation In-Reply-To: <20100721143729.64a510fc@Luca> References: <20100721143729.64a510fc@Luca> Message-ID: > Now, I'm not sure (I don't know PoE in detail) if I can use every > PoE-Switch. No you can't. The nanoBTS are not fully PoE compliant. For example they didn't work with my Netgear GS724TP or GS748TP. > 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? The netgear FS108P is a switch that's known to work with them. I use it myself. Sylvain From laforge at gnumonks.org Wed Jul 21 22:14:37 2010 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 22 Jul 2010 00:14:37 +0200 Subject: Switch with PowerOverEthernet for a BaseStation In-Reply-To: References: <20100721143729.64a510fc@Luca> Message-ID: <20100721221437.GZ19410@prithivi.gnumonks.org> On Wed, Jul 21, 2010 at 03:16:54PM +0200, Sylvain Munaut wrote: > > Now, I'm not sure (I don't know PoE in detail) if I can use every > > PoE-Switch. > > No you can't. > The nanoBTS are not fully PoE compliant. For example they didn't work > with my Netgear GS724TP or GS748TP. I believe the nanoBTS 1) draw more power than the standard permits 2) don't do the proper handshaking but simply draw power without negotiating it > > 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? > > The netgear FS108P is a switch that's known to work with them. I use it myself. it works for me, too. but only for two nanoBTS, as soon as I connect the third, the overpower LED of the switch lights up. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From bertoncello at netzing.de Thu Jul 22 07:16:19 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Thu, 22 Jul 2010 09:16:19 +0200 Subject: Switch with PowerOverEthernet for a BaseStation In-Reply-To: <20100721221437.GZ19410@prithivi.gnumonks.org> References: <20100721143729.64a510fc@Luca> <20100721221437.GZ19410@prithivi.gnumonks.org> Message-ID: <20100722091619.35f0ca62@Luca> Am Thu, 22 Jul 2010 00:14:37 +0200 schrieb Harald Welte : > I believe the nanoBTS > 1) draw more power than the standard permits > 2) don't do the proper handshaking but simply draw power without > negotiating it > > > > 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? > > > > The netgear FS108P is a switch that's known to work with them. I > > use it myself. > > it works for me, too. but only for two nanoBTS, as soon as I connect > the third, the overpower LED of the switch lights up. Aha, thanks for your answer. Do someone knows other PoE-Switches that can be used with 3 or 4 nanoBTS? I will need at least to connect 3 nanoBTS... Thanks a lot! Luca -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at 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 at netzing.de _______________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bertoncello at netzing.de Thu Jul 22 07:29:47 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Thu, 22 Jul 2010 09:29:47 +0200 Subject: Switch with PowerOverEthernet for a BaseStation In-Reply-To: <20100722091619.35f0ca62@Luca> References: <20100721143729.64a510fc@Luca> <20100721221437.GZ19410@prithivi.gnumonks.org> <20100722091619.35f0ca62@Luca> Message-ID: <20100722092947.4ffaa4d0@Luca> Am Thu, 22 Jul 2010 09:16:19 +0200 schrieb Luca Bertoncello : > Do someone knows other PoE-Switches that can be used with 3 or 4 > nanoBTS? > I will need at least to connect 3 nanoBTS... I just found these switches: - DES-1008PA 8-Port 10/100 Desktop Switch with 4 PoE Ports - LANCOM ES-1108P The first has a power supply of 48V DC/1.45A, then I **THINK**, I should connect up to 4 nanoBTS (power consumption of a nanoBTS: 0.3A). The second give for every PoE-ports 15,4 W, with 48V supply it is ~0.320A. Do you think I can use one of these Switches to connect 3 or 4 nanoBTS? Thanks a lot! -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at 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 at netzing.de _______________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From laforge at gnumonks.org Thu Jul 22 15:09:44 2010 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 22 Jul 2010 17:09:44 +0200 Subject: Switch with PowerOverEthernet for a BaseStation In-Reply-To: <20100722091619.35f0ca62@Luca> References: <20100721143729.64a510fc@Luca> <20100721221437.GZ19410@prithivi.gnumonks.org> <20100722091619.35f0ca62@Luca> Message-ID: <20100722150944.GS19410@prithivi.gnumonks.org> Hi Luca, On Thu, Jul 22, 2010 at 09:16:19AM +0200, Luca Bertoncello wrote: > > > The netgear FS108P is a switch that's known to work with them. I > > > use it myself. > > > > it works for me, too. but only for two nanoBTS, as soon as I connect > > the third, the overpower LED of the switch lights up. > > Aha, thanks for your answer. > > Do someone knows other PoE-Switches that can be used with 3 or 4 > nanoBTS? > I will need at least to connect 3 nanoBTS... As NETZING are an official ip.access Customer, you should have access to the data sheet that specifies the maximum power consumption of each BTS unit. Based on this you can then search for available switches that provide at least this amount of power on each port. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From holger at freyther.de Wed Jul 21 13:46:16 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Wed, 21 Jul 2010 21:46:16 +0800 Subject: Switch with PowerOverEthernet for a BaseStation In-Reply-To: <20100721143729.64a510fc@Luca> References: <20100721143729.64a510fc@Luca> Message-ID: <4C46FA28.8090300@freyther.de> On 07/21/2010 08:37 PM, Luca Bertoncello wrote: > 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? Maybe you should ask ipaccess? From bertoncello at netzing.de Thu Jul 22 13:29:23 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Thu, 22 Jul 2010 15:29:23 +0200 Subject: Detect phone calls Message-ID: <20100722152923.571cf79f@Luca> 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 at 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 at netzing.de _______________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From holger at freyther.de Thu Jul 22 13:55:00 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Thu, 22 Jul 2010 21:55:00 +0800 Subject: Detect phone calls In-Reply-To: <20100722152923.571cf79f@Luca> References: <20100722152923.571cf79f@Luca> Message-ID: <4C484DB4.3060303@freyther.de> On 07/22/2010 09:29 PM, Luca Bertoncello wrote: > 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? You can iterate over the transaction list. The list anchor is inside the gsm_network structure, each transaction has a subsystem attached, e.g. for Call Control you can use cc part of the union to get to the call. From bertoncello at netzing.de Thu Jul 22 14:01:01 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Thu, 22 Jul 2010 16:01:01 +0200 Subject: Detect phone calls In-Reply-To: <4C484DB4.3060303@freyther.de> References: <20100722152923.571cf79f@Luca> <4C484DB4.3060303@freyther.de> Message-ID: <20100722160101.41042309@Luca> Am Thu, 22 Jul 2010 21:55:00 +0800 schrieb Holger Hans Peter Freyther : > You can iterate over the transaction list. The list anchor is > inside the gsm_network structure, each transaction has a subsystem > attached, e.g. for Call Control you can use cc part of the union > to get to the call. OK, I need to write a function in OpenBSC, isn't it? Is it not possible to get it from DB or Logs? Just to know... And then: how can I get the IMSI/TMSI/IMEI/ID of a phone in the Log of MEAS? Is it possible to do this with an option (that I did not found yet), or have I to change the code of OpenBSC? Thanks -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at 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 at netzing.de _______________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From holger at freyther.de Thu Jul 22 14:52:10 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Thu, 22 Jul 2010 22:52:10 +0800 Subject: Detect phone calls In-Reply-To: <20100722160101.41042309@Luca> References: <20100722152923.571cf79f@Luca> <4C484DB4.3060303@freyther.de> <20100722160101.41042309@Luca> Message-ID: <4C485B1A.9060001@freyther.de> On 07/22/2010 10:01 PM, Luca Bertoncello wrote: > Am Thu, 22 Jul 2010 21:55:00 +0800 > And then: how can I get the IMSI/TMSI/IMEI/ID of a phone in the Log of > MEAS? > > Is it possible to do this with an option (that I did not found yet), or > have I to change the code of OpenBSC? It depends on your requirement (measurement is a new one). If you just want to have measurement reports there are various "show lchan-*" commands, if you need to have the Call Information, you need to add a new command. From laforge at gnumonks.org Sun Jul 25 17:55:46 2010 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 25 Jul 2010 19:55:46 +0200 Subject: Detect phone calls In-Reply-To: <20100722152923.571cf79f@Luca> References: <20100722152923.571cf79f@Luca> Message-ID: <20100725175546.GL8192@prithivi.gnumonks.org> On Thu, Jul 22, 2010 at 03:29:23PM +0200, Luca Bertoncello wrote: > 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? 'show lchan' is not sufficient? It shows you which channels are currently active for which subscriber. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From jmercury313 at gmail.com Thu Jul 22 15:11:16 2010 From: jmercury313 at gmail.com (jason mercury) Date: Thu, 22 Jul 2010 18:11:16 +0300 Subject: installing openbsc on opensuse Message-ID: Hi to all, I want to use openbsc on opensuse linux. What procedure shoul i follow? Thanks. Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at freyther.de Thu Jul 22 17:57:14 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Fri, 23 Jul 2010 01:57:14 +0800 Subject: installing openbsc on opensuse In-Reply-To: References: Message-ID: <4C48867A.4050801@freyther.de> On 07/22/2010 11:11 PM, jason mercury wrote: > Hi to all, > > I want to use openbsc on opensuse linux. What procedure shoul i follow? http://openbsc.osmocom.org/trac/wiki/Building_OpenBSC, just the package names might end with -devel instead of -dev... From laforge at gnumonks.org Thu Jul 22 20:18:34 2010 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 22 Jul 2010 22:18:34 +0200 Subject: libosmocore now abort()s on msgb overflow/underflow Message-ID: <20100722201834.GZ19410@prithivi.gnumonks.org> 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 http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From bertoncello at netzing.de Fri Jul 23 06:47:23 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Fri, 23 Jul 2010 08:47:23 +0200 Subject: Problem to compile the last version of OpenBSC Message-ID: <20100723084723.38dedf80@Luca> 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 at 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 at netzing.de _______________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From holger at freyther.de Fri Jul 23 08:37:53 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Fri, 23 Jul 2010 16:37:53 +0800 Subject: Problem to compile the last version of OpenBSC In-Reply-To: <20100723084723.38dedf80@Luca> References: <20100723084723.38dedf80@Luca> Message-ID: <4C4954E1.3080206@freyther.de> On 07/23/2010 02:47 PM, Luca Bertoncello wrote: > Unfortunately I can't compile it. I get these errors: Please update the libosmocore. From bertoncello at netzing.de Fri Jul 23 08:42:32 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Fri, 23 Jul 2010 10:42:32 +0200 Subject: Problem to compile the last version of OpenBSC In-Reply-To: <4C4954E1.3080206@freyther.de> References: <20100723084723.38dedf80@Luca> <4C4954E1.3080206@freyther.de> Message-ID: <20100723104232.41139eac@Luca> Am Fri, 23 Jul 2010 16:37:53 +0800 schrieb Holger Hans Peter Freyther : > On 07/23/2010 02:47 PM, Luca Bertoncello wrote: > > > Unfortunately I can't compile it. I get these errors: > > Please update the libosmocore. OK, I updated the libosmocore and now can I compile! Thanks a lot! -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at 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 at netzing.de _______________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bertoncello at netzing.de Fri Jul 23 06:52:51 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Fri, 23 Jul 2010 08:52:51 +0200 Subject: Unable to configure a BTS Message-ID: <20100723085251.33b19c55@Luca> 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 at 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 at 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 at netzing.de _______________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From holger at freyther.de Fri Jul 23 07:25:32 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Fri, 23 Jul 2010 15:25:32 +0800 Subject: Unable to configure a BTS In-Reply-To: <20100723085251.33b19c55@Luca> References: <20100723085251.33b19c55@Luca> Message-ID: <4C4943EC.20406@freyther.de> On 07/23/2010 02:52 PM, Luca Bertoncello wrote: > Segmentation fault I can not comment on the other bits (besides Nordin having had issues as well), the segfault is an issue I introduced. In the coredump uploaded to the On Waves servers it is crashing in my drop OML when RSL failed code and I plan to fix that once I have my private stuff settled. From bertoncello at netzing.de Fri Jul 23 07:31:23 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Fri, 23 Jul 2010 09:31:23 +0200 Subject: Unable to configure a BTS In-Reply-To: <4C4943EC.20406@freyther.de> References: <20100723085251.33b19c55@Luca> <4C4943EC.20406@freyther.de> Message-ID: <20100723093123.2c2a13a1@Luca> Am Fri, 23 Jul 2010 15:25:32 +0800 schrieb Holger Hans Peter Freyther : > I can not comment on the other bits (besides Nordin having had > issues as well), the segfault is an issue I introduced. In the > coredump uploaded to the On Waves servers it is crashing in my > drop OML when RSL failed code and I plan to fix that once I have > my private stuff settled. Aha, this is for me a very huge problem, because I have a demonstration next Monday and I have just today to test all... Could you say me, when you introduce this problem, so that I can use a previous version to configure my BTS? Thanks a lot! -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at 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 at netzing.de _______________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bertoncello at netzing.de Fri Jul 23 07:47:40 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Fri, 23 Jul 2010 09:47:40 +0200 Subject: Unable to configure a BTS In-Reply-To: <4C4943EC.20406@freyther.de> References: <20100723085251.33b19c55@Luca> <4C4943EC.20406@freyther.de> Message-ID: <20100723094740.3ef30f59@Luca> Am Fri, 23 Jul 2010 15:25:32 +0800 schrieb Holger Hans Peter Freyther : > On 07/23/2010 02:52 PM, Luca Bertoncello wrote: > > > Segmentation fault > > I can not comment on the other bits (besides Nordin having had > issues as well), the segfault is an issue I introduced. In the > coredump uploaded to the On Waves servers it is crashing in my > drop OML when RSL failed code and I plan to fix that once I have > my private stuff settled. I tried a very old version I have in a old PC (compiled on 16/10/2009). Now there is no segmentation fault, but it does not work... I get: netzing at debian503:~/openbsc/openbsc/src$ ./ipaccess-config -u 151/0/0 -o 192.168.1.18 -r 192.168.1.108 ipaccess-config (C) 2009 by Harald Welte This is FREE SOFTWARE with ABSOLUTELY NO WARRANTY Trying to connect to ip.access BTS ... BTS disappeared, dead socket Lost some E1 TEI link and it waits until the end of the eternity (I suppose). Is it possible, that the problem is on the BTS? How can I be sure? Thanks a lot! -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at 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 at netzing.de _______________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bouchtaoui at gmail.com Fri Jul 23 08:02:57 2010 From: bouchtaoui at gmail.com (Nordin) Date: Fri, 23 Jul 2010 10:02:57 +0200 Subject: Unable to configure a BTS In-Reply-To: <20100723094740.3ef30f59@Luca> References: <20100723085251.33b19c55@Luca> <4C4943EC.20406@freyther.de> <20100723094740.3ef30f59@Luca> Message-ID: <4C494CB1.6050400@gmail.com> First of all, how did you configure? You wrote: lucabert at 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 I think it's best to split it in two steps: ./ipaccess-config -u 151/0/0 bts-ip ./ipaccess-config -o bsc-ip bts-ip You need also to power off than power on and than try it again. My BTS kind of got lock as TRX (as a slave of master BTS) and can't send BCCH anymore. This problem occured since I tried to modify the bts-id, that's the middle number of the id. I recommend you not to do the same, otherwise your bts won't work properly. On 23-7-2010 9:47, Luca Bertoncello wrote: > Am Fri, 23 Jul 2010 15:25:32 +0800 > schrieb Holger Hans Peter Freyther: > > >> On 07/23/2010 02:52 PM, Luca Bertoncello wrote: >> >> >>> Segmentation fault >>> >> I can not comment on the other bits (besides Nordin having had >> issues as well), the segfault is an issue I introduced. In the >> coredump uploaded to the On Waves servers it is crashing in my >> drop OML when RSL failed code and I plan to fix that once I have >> my private stuff settled. >> > I tried a very old version I have in a old PC (compiled on 16/10/2009). > Now there is no segmentation fault, but it does not work... > > I get: > > netzing at debian503:~/openbsc/openbsc/src$ ./ipaccess-config -u 151/0/0 > -o 192.168.1.18 -r 192.168.1.108 > ipaccess-config (C) 2009 by Harald Welte This is FREE SOFTWARE with > ABSOLUTELY NO WARRANTY > > Trying to connect to ip.access BTS ... > BTS disappeared, dead socket > Lost some E1 TEI link > > and it waits until the end of the eternity (I suppose). > Is it possible, that the problem is on the BTS? How can I be sure? > > Thanks a lot! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bertoncello at netzing.de Fri Jul 23 08:35:54 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Fri, 23 Jul 2010 10:35:54 +0200 Subject: Unable to configure a BTS In-Reply-To: <4C494CB1.6050400@gmail.com> References: <20100723085251.33b19c55@Luca> <4C4943EC.20406@freyther.de> <20100723094740.3ef30f59@Luca> <4C494CB1.6050400@gmail.com> Message-ID: <20100723103554.5a95ad6a@Luca> Am Fri, 23 Jul 2010 10:02:57 +0200 schrieb Nordin : > First of all, how did you configure? > You wrote: > > lucabert at 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 > > I think it's best to split it in two steps: > ./ipaccess-config -u 151/0/0 bts-ip > ./ipaccess-config -o bsc-ip bts-ip I tried it, too! Same error... :( > You need also to power off than power on and than try it again. And I tried this, too. Unfortunately no better results... > My BTS kind of got lock as TRX (as a slave of master BTS) and can't > send BCCH anymore. This problem occured since I tried to modify the > bts-id, that's the middle number of the id. > > I recommend you not to do the same, otherwise your bts won't work > properly. OK, thanks for the advice, but I first need to configure the BTS to speech with my PC and my OpenBSC... Thanks -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at 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 at netzing.de _______________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From holger at freyther.de Fri Jul 23 08:40:24 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Fri, 23 Jul 2010 16:40:24 +0800 Subject: Unable to configure a BTS In-Reply-To: <20100723094740.3ef30f59@Luca> References: <20100723085251.33b19c55@Luca> <4C4943EC.20406@freyther.de> <20100723094740.3ef30f59@Luca> Message-ID: <4C495578.1040002@freyther.de> On 07/23/2010 03:47 PM, Luca Bertoncello wrote: > I get: > > netzing at debian503:~/openbsc/openbsc/src$ ./ipaccess-config -u 151/0/0 > -o 192.168.1.18 -r 192.168.1.108 > ipaccess-config (C) 2009 by Harald Welte This is FREE SOFTWARE with > ABSOLUTELY NO WARRANTY > > and it waits until the end of the eternity (I suppose). > Is it possible, that the problem is on the BTS? How can I be sure? As usual for being able to debug problems: Segmentation Fault -> Attach a Backtrace Some Protocol Error -> Attach a Packetdump. I don't have access to GSM1800 BTS so I will not be able to test a similar setup. From bertoncello at netzing.de Fri Jul 23 08:47:15 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Fri, 23 Jul 2010 10:47:15 +0200 Subject: Unable to configure a BTS In-Reply-To: <4C495578.1040002@freyther.de> References: <20100723085251.33b19c55@Luca> <4C4943EC.20406@freyther.de> <20100723094740.3ef30f59@Luca> <4C495578.1040002@freyther.de> Message-ID: <20100723104715.5b9a87e4@Luca> Am Fri, 23 Jul 2010 16:40:24 +0800 schrieb Holger Hans Peter Freyther : > As usual for being able to debug problems: > > Segmentation Fault -> Attach a Backtrace > Some Protocol Error -> Attach a Packetdump. You're right! Please excuse me... Attached the PCAP file and follow the backtrace: lucabert at Luca:~/BSC/openbsc/openbsc/src/ipaccess$ gdb ./ipaccess-config /tmp/core GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later 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"... warning: Can't read pathname for load map: Input/output error. 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...done. Loaded symbols for /lib/tls/i686/cmov/libdl.so.2 Reading symbols from /usr/lib/libdbi.so.0...done. Loaded symbols for /usr/lib/libdbi.so.0 Reading symbols from /lib/tls/i686/cmov/libcrypt.so.1...done. Loaded symbols for /lib/tls/i686/cmov/libcrypt.so.1 Reading symbols from /lib/tls/i686/cmov/libc.so.6...done. Loaded symbols for /lib/tls/i686/cmov/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /lib/tls/i686/cmov/libm.so.6...done. Loaded symbols for /lib/tls/i686/cmov/libm.so.6 Core was generated by `ipaccess-config -u 151/0/0 -o 192.168.1.18 192.168.1.108'. Program terminated with signal 11, Segmentation fault. [New process 27115] #0 bsc_unregister_fd (fd=0x80c59f4) at ../include/osmocore/linuxlist.h:107 107 next->prev = prev; (gdb) Thanks -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at 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 at netzing.de _______________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: ipaccess-config.pcap Type: application/octet-stream Size: 49664 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From 246tnt at gmail.com Fri Jul 23 08:58:05 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 23 Jul 2010 10:58:05 +0200 Subject: Unable to configure a BTS In-Reply-To: <20100723104715.5b9a87e4@Luca> References: <20100723085251.33b19c55@Luca> <4C4943EC.20406@freyther.de> <20100723094740.3ef30f59@Luca> <4C495578.1040002@freyther.de> <20100723104715.5b9a87e4@Luca> Message-ID: > Core was generated by `ipaccess-config -u 151/0/0 -o 192.168.1.18 192.168.1.108'. > Program terminated with signal 11, Segmentation fault. > [New process 27115] > #0 ?bsc_unregister_fd (fd=0x80c59f4) at ../include/osmocore/linuxlist.h:107 > 107 ? ? ? ? ? ? next->prev = prev; > (gdb) That's not much of a backtrace Please, use the 'bt' command to get the full backtrace. Using the 'bt full' command if even better. And to further improve things you could also make sure the libosmocore and openbsc were compiled with full debugging symbol by including -ggdb if the CFLAGS/LDFLAGS Sylvain From bertoncello at netzing.de Fri Jul 23 09:22:19 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Fri, 23 Jul 2010 11:22:19 +0200 Subject: Unable to configure a BTS In-Reply-To: References: <20100723085251.33b19c55@Luca> <4C4943EC.20406@freyther.de> <20100723094740.3ef30f59@Luca> <4C495578.1040002@freyther.de> <20100723104715.5b9a87e4@Luca> Message-ID: <20100723112219.27197436@Luca> Am Fri, 23 Jul 2010 10:58:05 +0200 schrieb Sylvain Munaut <246tnt at gmail.com>: > That's not much of a backtrace > > Please, use the 'bt' command to get the full backtrace. > Using the 'bt full' command if even better. And to further improve > things you could also make sure the libosmocore and openbsc were > compiled with full debugging symbol by including -ggdb if the > CFLAGS/LDFLAGS OK, here more information: (gdb) bt full #0 bsc_unregister_fd (fd=0x80c59f4) at ../include/osmocore/linuxlist.h:107 No locals. #1 0x08055c67 in ipaccess_drop_rsl (trx=0x806d880) at input/ipaccess.c:427 ts = (struct e1inp_ts *) 0x80c548c #2 0x08055d3f in ipaccess_drop_oml (bts=0x806cc38) at input/ipaccess.c:368 trx = (struct gsm_bts_trx *) 0x806d880 ts = line = (struct e1inp_line *) 0x80c4ef8 #3 0x08055d97 in ipaccess_drop (ts=0x0, bfd=) at input/ipaccess.c:400 link = (struct e1inp_sign_link *) 0x0 bts_nr = 0 #4 0x080563ca in ipaccess_fd_cb (bfd=0x80c5470, what=) at input/ipaccess.c:451 line = ts_nr = 1 rc = #5 0xb76e8073 in bsc_select_main (polling=0) at select.c:119 flags = 1 ufd = (struct bsc_fd *) 0x80c5470 tmp = (struct bsc_fd *) 0xb76f93a0 readset = {__fds_bits = {0 }} writeset = {__fds_bits = {0 }} exceptset = {__fds_bits = {0 }} work = 0 rc = no_time = {tv_sec = 0, tv_usec = 0} #6 0x0804af42 in main (argc=6, argv=0xbffbde84) at ipaccess-config.c:861 bts = (struct gsm_bts *) 0x806cc38 sin = {sin_family = 2, sin_port = 48651, sin_addr = {s_addr = 1812048064}, sin_zero = "\000\000\000\000\000\000\000"} rc = 135027188 option_index = 0 stream_id = stderr_target = long_options = {{name = 0x8061169 "unit-id", has_arg = 1, flag = 0x0, val = 117}, {name = 0x8061171 "oml-ip", has_arg = 1, flag = 0x0, val = 111}, { name = 0x8061178 "ip-address", has_arg = 1, flag = 0x0, val = 105}, {name = 0x8061183 "ip-gateway", has_arg = 1, flag = 0x0, val = 103}, {name = 0x806118e "restart", has_arg = 0, flag = 0x0, val = 114}, {name = 0x8061196 "nvram-flags", has_arg = 1, flag = 0x0, val = 110}, {name = 0x80611a2 "nvattr-set", has_arg = 1, flag = 0x0, val = 83}, {name = 0x80611ad "nvattr-unset", has_arg = 1, flag = 0x0, val = 85}, {name = 0x80611ba "help", has_arg = 0, flag = 0x0, val = 104}, {name = 0x80611bf "listen", has_arg = 1, flag = 0x0, val = 108}, {name = 0x80611c6 "stream-id", has_arg = 1, flag = 0x0, val = 115}, {name = 0x80611d0 "software", has_arg = 1, flag = 0x0, val = 100}, { name = 0x806106d "firmware", has_arg = 1, flag = 0x0, val = 102}, {name = 0x80611d9 "write-firmware", has_arg = 0, flag = 0x0, val = 119}, {name = 0x0, has_arg = 0, flag = 0x0, val = 0}} Thanks -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at 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 at netzing.de _______________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From holger at freyther.de Fri Jul 23 09:17:59 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Fri, 23 Jul 2010 17:17:59 +0800 Subject: Unable to configure a BTS In-Reply-To: <20100723104715.5b9a87e4@Luca> References: <20100723085251.33b19c55@Luca> <4C4943EC.20406@freyther.de> <20100723094740.3ef30f59@Luca> <4C495578.1040002@freyther.de> <20100723104715.5b9a87e4@Luca> Message-ID: <4C495E47.10904@freyther.de> On 07/23/2010 04:47 PM, Luca Bertoncello wrote: > #0 bsc_unregister_fd (fd=0x80c59f4) at ../include/osmocore/linuxlist.h:107 > 107 next->prev = prev; > (gdb) please type bt (or longer backtrace). :) From holger at freyther.de Fri Jul 23 09:23:40 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Fri, 23 Jul 2010 17:23:40 +0800 Subject: Unable to configure a BTS In-Reply-To: <20100723104715.5b9a87e4@Luca> References: <20100723085251.33b19c55@Luca> <4C4943EC.20406@freyther.de> <20100723094740.3ef30f59@Luca> <4C495578.1040002@freyther.de> <20100723104715.5b9a87e4@Luca> Message-ID: <4C495F9C.8010207@freyther.de> On 07/23/2010 04:47 PM, Luca Bertoncello wrote: > Attached the PCAP file and follow the backtrace: ip.src == 192.168.1.108 || ip.dst == 192.168.1.108 doesn't really show much information... Your PC opens the connection, it is acked The BTS sends sends a IPA Identity ACK, we send one. The BTS closes the connections. Now the question is why, and I don't know. :) From bertoncello at netzing.de Fri Jul 23 09:27:21 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Fri, 23 Jul 2010 11:27:21 +0200 Subject: Unable to configure a BTS In-Reply-To: <4C495F9C.8010207@freyther.de> References: <20100723085251.33b19c55@Luca> <4C4943EC.20406@freyther.de> <20100723094740.3ef30f59@Luca> <4C495578.1040002@freyther.de> <20100723104715.5b9a87e4@Luca> <4C495F9C.8010207@freyther.de> Message-ID: <20100723112721.11329420@Luca> Am Fri, 23 Jul 2010 17:23:40 +0800 schrieb Holger Hans Peter Freyther : > > Attached the PCAP file and follow the backtrace: > > ip.src == 192.168.1.108 || ip.dst == 192.168.1.108 > > doesn't really show much information... > > Your PC opens the connection, it is acked > The BTS sends sends a IPA Identity ACK, we send one. > The BTS closes the connections. > > Now the question is why, and I don't know. :) Could is the DSC1800 KO? The device is NOT new, but it comes after more experiments from a university... Is there a possibility to check, if the DSC1800 has a problem? Thanks -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at 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 at netzing.de _______________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From 246tnt at gmail.com Fri Jul 23 09:33:22 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 23 Jul 2010 11:33:22 +0200 Subject: Unable to configure a BTS In-Reply-To: <20100723112721.11329420@Luca> References: <20100723085251.33b19c55@Luca> <4C4943EC.20406@freyther.de> <20100723094740.3ef30f59@Luca> <4C495578.1040002@freyther.de> <20100723104715.5b9a87e4@Luca> <4C495F9C.8010207@freyther.de> <20100723112721.11329420@Luca> Message-ID: > Could is the DSC1800 KO? > The device is NOT new, but it comes after more experiments from a > university... > > Is there a possibility to check, if the DSC1800 has a problem? Did you do a full factory reset with a reset dongle ? You can try the ipaccess-telnet utility (search the ml or the wiki for details) and see what the console says (if anything). Sylvain From bertoncello at netzing.de Fri Jul 23 09:42:02 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Fri, 23 Jul 2010 11:42:02 +0200 Subject: Unable to configure a BTS In-Reply-To: References: <20100723085251.33b19c55@Luca> <4C4943EC.20406@freyther.de> <20100723094740.3ef30f59@Luca> <4C495578.1040002@freyther.de> <20100723104715.5b9a87e4@Luca> <4C495F9C.8010207@freyther.de> <20100723112721.11329420@Luca> Message-ID: <20100723114202.142c720b@Luca> Am Fri, 23 Jul 2010 11:33:22 +0200 schrieb Sylvain Munaut <246tnt at gmail.com>: > > Is there a possibility to check, if the DSC1800 has a problem? > > Did you do a full factory reset with a reset dongle ? No, I didn't... What is this "reset dongle"? > You can try the ipaccess-telnet utility (search the ml or the wiki for > details) and see what the console says (if anything). Unfortunately I can telnet, because I can't send the NVRAM flag 0x400... :( Any other suggestion? Thanks -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at 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 at netzing.de _______________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From 246tnt at gmail.com Fri Jul 23 09:49:23 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 23 Jul 2010 11:49:23 +0200 Subject: Unable to configure a BTS In-Reply-To: <20100723114202.142c720b@Luca> References: <20100723085251.33b19c55@Luca> <4C4943EC.20406@freyther.de> <20100723094740.3ef30f59@Luca> <4C495578.1040002@freyther.de> <20100723104715.5b9a87e4@Luca> <4C495F9C.8010207@freyther.de> <20100723112721.11329420@Luca> <20100723114202.142c720b@Luca> Message-ID: >> > Is there a possibility to check, if the DSC1800 has a problem? >> >> Did you do a full factory reset with a reset dongle ? > > No, I didn't... What is this "reset dongle"? See http://lists.gnumonks.org/pipermail/openbsc/2009-August/000804.html The dongle can be emulated with a carefully placed conductive pin (screwdriver, needed, probe, whatever you have laying around :) Sylvain From bertoncello at netzing.de Fri Jul 23 09:53:52 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Fri, 23 Jul 2010 11:53:52 +0200 Subject: Unable to configure a BTS In-Reply-To: References: <20100723085251.33b19c55@Luca> <4C4943EC.20406@freyther.de> <20100723094740.3ef30f59@Luca> <4C495578.1040002@freyther.de> <20100723104715.5b9a87e4@Luca> <4C495F9C.8010207@freyther.de> <20100723112721.11329420@Luca> <20100723114202.142c720b@Luca> Message-ID: <20100723115352.67bca4e0@Luca> Am Fri, 23 Jul 2010 11:49:23 +0200 schrieb Sylvain Munaut <246tnt at gmail.com>: > See > http://lists.gnumonks.org/pipermail/openbsc/2009-August/000804.html > > The dongle can be emulated with a carefully placed conductive pin > (screwdriver, needed, probe, whatever you have laying around :) Unfortunately I don't have a dongle and I don't have the possibility to make one... Other suggestion? Thanks -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at 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 at netzing.de _______________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From 246tnt at gmail.com Fri Jul 23 09:57:48 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 23 Jul 2010 11:57:48 +0200 Subject: Unable to configure a BTS In-Reply-To: <20100723115352.67bca4e0@Luca> References: <20100723085251.33b19c55@Luca> <4C4943EC.20406@freyther.de> <20100723094740.3ef30f59@Luca> <4C495578.1040002@freyther.de> <20100723104715.5b9a87e4@Luca> <4C495F9C.8010207@freyther.de> <20100723112721.11329420@Luca> <20100723114202.142c720b@Luca> <20100723115352.67bca4e0@Luca> Message-ID: >> http://lists.gnumonks.org/pipermail/openbsc/2009-August/000804.html >> >> The dongle can be emulated with a carefully placed conductive pin >> (screwdriver, needed, probe, whatever you have laying around :) > > Unfortunately I don't have a dongle and I don't have the possibility to > make one... That's what I noted above, you don't _need_ a dongle ... you just need to follow the procedure and instead of the dongle, just short the pin 9 & 10 of TIB-IN with anything metallic/conductive. Sylvain From bertoncello at netzing.de Fri Jul 23 10:30:07 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Fri, 23 Jul 2010 12:30:07 +0200 Subject: Unable to configure a BTS In-Reply-To: References: <20100723085251.33b19c55@Luca> <4C4943EC.20406@freyther.de> <20100723094740.3ef30f59@Luca> <4C495578.1040002@freyther.de> <20100723104715.5b9a87e4@Luca> <4C495F9C.8010207@freyther.de> <20100723112721.11329420@Luca> <20100723114202.142c720b@Luca> <20100723115352.67bca4e0@Luca> Message-ID: <20100723123007.4b3e1ee4@Luca> Am Fri, 23 Jul 2010 11:57:48 +0200 schrieb Sylvain Munaut <246tnt at gmail.com>: > That's what I noted above, you don't _need_ a dongle ... you just need > to follow the procedure and instead of the dongle, just short the pin > 9 & 10 of TIB-IN with anything metallic/conductive. OK, I understand, but without a USB-connector it is very hard to do without damages... I don't want to try. The BTS has to give back to the university in the next days... Anyway thanks! -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at 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 at netzing.de _______________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From 246tnt at gmail.com Fri Jul 23 10:41:28 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 23 Jul 2010 12:41:28 +0200 Subject: Unable to configure a BTS In-Reply-To: <20100723123007.4b3e1ee4@Luca> References: <20100723085251.33b19c55@Luca> <4C4943EC.20406@freyther.de> <20100723094740.3ef30f59@Luca> <4C495578.1040002@freyther.de> <20100723104715.5b9a87e4@Luca> <4C495F9C.8010207@freyther.de> <20100723112721.11329420@Luca> <20100723114202.142c720b@Luca> <20100723115352.67bca4e0@Luca> <20100723123007.4b3e1ee4@Luca> Message-ID: >> That's what I noted above, you don't _need_ a dongle ... you just need >> to follow the procedure and instead of the dongle, just short the pin >> 9 & 10 of TIB-IN with anything metallic/conductive. > > OK, I understand, but without a USB-connector it is very hard to do > without damages... ??? Have you _looked_ at the connector. It has nothing to do with USB and 9/10 are the twi pins on the exterior ... can't miss them (unless you're half-blind or have any other condition obviously ...) > I don't want to try. The BTS has to give back to the university in the > next days... well, there is always the 'It was like that when I got it' excuse :) From bertoncello at netzing.de Fri Jul 23 10:48:39 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Fri, 23 Jul 2010 12:48:39 +0200 Subject: Unable to configure a BTS In-Reply-To: References: <20100723085251.33b19c55@Luca> <4C4943EC.20406@freyther.de> <20100723094740.3ef30f59@Luca> <4C495578.1040002@freyther.de> <20100723104715.5b9a87e4@Luca> <4C495F9C.8010207@freyther.de> <20100723112721.11329420@Luca> <20100723114202.142c720b@Luca> <20100723115352.67bca4e0@Luca> <20100723123007.4b3e1ee4@Luca> Message-ID: <20100723124839.1b1a7b1f@Luca> Am Fri, 23 Jul 2010 12:41:28 +0200 schrieb Sylvain Munaut <246tnt at gmail.com>: > > OK, I understand, but without a USB-connector it is very hard to do > > without damages... > > ??? > > Have you _looked_ at the connector. It has nothing to do with USB and > 9/10 are the twi pins on the exterior ... can't miss them (unless > you're half-blind or have any other condition obviously ...) Then I didn't understood which port do you mean... Now I found the connector you mean. It's like a RJ45, but with 10 pins. Isn't it? Now which are the PINs 9 and 10? The last two LEFT or the last two RIGHT? Thanks! -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at 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 at netzing.de _______________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bouchtaoui at gmail.com Fri Jul 23 11:03:53 2010 From: bouchtaoui at gmail.com (Nordin) Date: Fri, 23 Jul 2010 13:03:53 +0200 Subject: Unable to configure a BTS In-Reply-To: <20100723124839.1b1a7b1f@Luca> References: <20100723085251.33b19c55@Luca> <4C4943EC.20406@freyther.de> <20100723094740.3ef30f59@Luca> <4C495578.1040002@freyther.de> <20100723104715.5b9a87e4@Luca> <4C495F9C.8010207@freyther.de> <20100723112721.11329420@Luca> <20100723114202.142c720b@Luca> <20100723115352.67bca4e0@Luca> <20100723123007.4b3e1ee4@Luca> <20100723124839.1b1a7b1f@Luca> Message-ID: <4C497719.7000305@gmail.com> On 23-7-2010 12:48, Luca Bertoncello wrote: > Am Fri, 23 Jul 2010 12:41:28 +0200 > schrieb Sylvain Munaut<246tnt at gmail.com>: > > >>> OK, I understand, but without a USB-connector it is very hard to do >>> without damages... >>> >> ??? >> >> Have you _looked_ at the connector. It has nothing to do with USB and >> 9/10 are the twi pins on the exterior ... can't miss them (unless >> you're half-blind or have any other condition obviously ...) >> > Then I didn't understood which port do you mean... > > Now I found the connector you mean. It's like a RJ45, but with 10 pins. > Isn't it? > > Now which are the PINs 9 and 10? The last two LEFT or the last two > RIGHT? > > Thanks! > ----------------------------- | U U U U U U U U U U | | | | | | 0 .. 9 10 | | | | | |___________ ___________| |_____| I hope this helps :) From bertoncello at netzing.de Fri Jul 23 11:09:22 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Fri, 23 Jul 2010 13:09:22 +0200 Subject: Unable to configure a BTS In-Reply-To: <4C497719.7000305@gmail.com> References: <20100723085251.33b19c55@Luca> <4C4943EC.20406@freyther.de> <20100723094740.3ef30f59@Luca> <4C495578.1040002@freyther.de> <20100723104715.5b9a87e4@Luca> <4C495F9C.8010207@freyther.de> <20100723112721.11329420@Luca> <20100723114202.142c720b@Luca> <20100723115352.67bca4e0@Luca> <20100723123007.4b3e1ee4@Luca> <20100723124839.1b1a7b1f@Luca> <4C497719.7000305@gmail.com> Message-ID: <20100723130922.7b320be7@Luca> Am Fri, 23 Jul 2010 13:03:53 +0200 schrieb Nordin : > > Now I found the connector you mean. It's like a RJ45, but with 10 > > pins. Isn't it? > > > > Now which are the PINs 9 and 10? The last two LEFT or the last two > > RIGHT? > > > > Thanks! > > > ----------------------------- > | U U U U U U U U U U | > | | | | > | 0 .. 9 10 | > | | > | | > |___________ ___________| > |_____| > > I hope this helps :) Unfortunately not... I tried to short PIN9+10, and wait until the LED flashes (more than 2 mins), then I powered off and on the BTS. It does not seems it was resetted... Other suggestions? -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at 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 at netzing.de _______________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bouchtaoui at gmail.com Fri Jul 23 11:15:32 2010 From: bouchtaoui at gmail.com (Nordin) Date: Fri, 23 Jul 2010 13:15:32 +0200 Subject: Unable to configure a BTS In-Reply-To: <20100723130922.7b320be7@Luca> References: <20100723085251.33b19c55@Luca> <4C4943EC.20406@freyther.de> <20100723094740.3ef30f59@Luca> <4C495578.1040002@freyther.de> <20100723104715.5b9a87e4@Luca> <4C495F9C.8010207@freyther.de> <20100723112721.11329420@Luca> <20100723114202.142c720b@Luca> <20100723115352.67bca4e0@Luca> <20100723123007.4b3e1ee4@Luca> <20100723124839.1b1a7b1f@Luca> <4C497719.7000305@gmail.com> <20100723130922.7b320be7@Luca> Message-ID: <4C4979D4.4040601@gmail.com> Than you haven't shortcutted the two pins well, cause if you did, after 30 seconds it flashes red light. I had that in the first time too, until I found a way to shortcut it well. I used a screwdriver, just try it again, it should work. Don't worry, it won't damage a lot :p On 23-7-2010 13:09, Luca Bertoncello wrote: > Am Fri, 23 Jul 2010 13:03:53 +0200 > schrieb Nordin: > > >>> Now I found the connector you mean. It's like a RJ45, but with 10 >>> pins. Isn't it? >>> >>> Now which are the PINs 9 and 10? The last two LEFT or the last two >>> RIGHT? >>> >>> Thanks! >>> >>> >> ----------------------------- >> | U U U U U U U U U U | >> | | | | >> | 0 .. 9 10 | >> | | >> | | >> |___________ ___________| >> |_____| >> >> I hope this helps :) >> > Unfortunately not... > > I tried to short PIN9+10, and wait until the LED flashes (more than 2 > mins), then I powered off and on the BTS. > > It does not seems it was resetted... > > Other suggestions? > From bertoncello at netzing.de Fri Jul 23 11:26:04 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Fri, 23 Jul 2010 13:26:04 +0200 Subject: Unable to configure a BTS In-Reply-To: <4C4979D4.4040601@gmail.com> References: <20100723085251.33b19c55@Luca> <4C4943EC.20406@freyther.de> <20100723094740.3ef30f59@Luca> <4C495578.1040002@freyther.de> <20100723104715.5b9a87e4@Luca> <4C495F9C.8010207@freyther.de> <20100723112721.11329420@Luca> <20100723114202.142c720b@Luca> <20100723115352.67bca4e0@Luca> <20100723123007.4b3e1ee4@Luca> <20100723124839.1b1a7b1f@Luca> <4C497719.7000305@gmail.com> <20100723130922.7b320be7@Luca> <4C4979D4.4040601@gmail.com> Message-ID: <20100723132604.102946fb@Luca> Am Fri, 23 Jul 2010 13:15:32 +0200 schrieb Nordin : > Than you haven't shortcutted the two pins well, cause if you did, > after 30 seconds it flashes red light. > I had that in the first time too, until I found a way to shortcut it > well. I used a screwdriver, just try it again, it should work. Don't > worry, it won't damage a lot :p Unfortunately not... I just tried again. After ~30 seconds the LED flashes, but as I powered on it has the same configured data and I can't configure it... Now I have this idea: I supply the power using PoE. Maybe have I to supply the power not with PoE? Thanks -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at 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 at netzing.de _______________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bouchtaoui at gmail.com Fri Jul 23 12:00:49 2010 From: bouchtaoui at gmail.com (Nordin) Date: Fri, 23 Jul 2010 14:00:49 +0200 Subject: Unable to configure a BTS In-Reply-To: <20100723132604.102946fb@Luca> References: <20100723085251.33b19c55@Luca> <4C4943EC.20406@freyther.de> <20100723094740.3ef30f59@Luca> <4C495578.1040002@freyther.de> <20100723104715.5b9a87e4@Luca> <4C495F9C.8010207@freyther.de> <20100723112721.11329420@Luca> <20100723114202.142c720b@Luca> <20100723115352.67bca4e0@Luca> <20100723123007.4b3e1ee4@Luca> <20100723124839.1b1a7b1f@Luca> <4C497719.7000305@gmail.com> <20100723130922.7b320be7@Luca> <4C4979D4.4040601@gmail.com> <20100723132604.102946fb@Luca> Message-ID: <4C498471.70506@gmail.com> On 23-7-2010 13:26, Luca Bertoncello wrote: > Am Fri, 23 Jul 2010 13:15:32 +0200 > schrieb Nordin: > > >> Than you haven't shortcutted the two pins well, cause if you did, >> after 30 seconds it flashes red light. >> I had that in the first time too, until I found a way to shortcut it >> well. I used a screwdriver, just try it again, it should work. Don't >> worry, it won't damage a lot :p >> > Unfortunately not... > I just tried again. After ~30 seconds the LED flashes, but as I powered > on it has the same configured data and I can't configure it... > Are you sure? You can use ipaccess-find to see if the id is modified. If I remember it will be something like 65xxx/0/0 > Now I have this idea: I supply the power using PoE. Maybe have I to > supply the power not with PoE? > I don't see any difference, If you see the BTS's LED flashes, it's working. But maybe you should use the normal power supplier that comes with the BTS. It's possible the PoE you use is not strong enough. > Thanks > From bertoncello at netzing.de Fri Jul 23 12:05:07 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Fri, 23 Jul 2010 14:05:07 +0200 Subject: Unable to configure a BTS In-Reply-To: <4C498471.70506@gmail.com> References: <20100723085251.33b19c55@Luca> <4C4943EC.20406@freyther.de> <20100723094740.3ef30f59@Luca> <4C495578.1040002@freyther.de> <20100723104715.5b9a87e4@Luca> <4C495F9C.8010207@freyther.de> <20100723112721.11329420@Luca> <20100723114202.142c720b@Luca> <20100723115352.67bca4e0@Luca> <20100723123007.4b3e1ee4@Luca> <20100723124839.1b1a7b1f@Luca> <4C497719.7000305@gmail.com> <20100723130922.7b320be7@Luca> <4C4979D4.4040601@gmail.com> <20100723132604.102946fb@Luca> <4C498471.70506@gmail.com> Message-ID: <20100723140507.4c407a18@Luca> Am Fri, 23 Jul 2010 14:00:49 +0200 schrieb Nordin : > Are you sure? You can use ipaccess-find to see if the id is modified. > If I remember it will be something like 65xxx/0/0 Yes! The first line of ipaccess-find has 65535/X/X (I don't have it now, and I don't remember the value of X). But starting from the second it is as before... > I don't see any difference, If you see the BTS's LED flashes, it's > working. But maybe you should use the normal power supplier that > comes with the BTS. > It's possible the PoE you use is not strong enough. Unfortunately I don't have other power supply... :( Thanks -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at 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 at netzing.de _______________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From laforge at gnumonks.org Sun Jul 25 18:02:09 2010 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 25 Jul 2010 20:02:09 +0200 Subject: Unable to configure a BTS In-Reply-To: <20100723115352.67bca4e0@Luca> References: <4C4943EC.20406@freyther.de> <20100723094740.3ef30f59@Luca> <4C495578.1040002@freyther.de> <20100723104715.5b9a87e4@Luca> <4C495F9C.8010207@freyther.de> <20100723112721.11329420@Luca> <20100723114202.142c720b@Luca> <20100723115352.67bca4e0@Luca> Message-ID: <20100725180209.GM8192@prithivi.gnumonks.org> On Fri, Jul 23, 2010 at 11:53:52AM +0200, Luca Bertoncello wrote: > Am Fri, 23 Jul 2010 11:49:23 +0200 > schrieb Sylvain Munaut <246tnt at gmail.com>: > > > See > > http://lists.gnumonks.org/pipermail/openbsc/2009-August/000804.html > > > > The dongle can be emulated with a carefully placed conductive pin > > (screwdriver, needed, probe, whatever you have laying around :) > > Unfortunately I don't have a dongle and I don't have the possibility to > make one... Luca, it is not the responsibility of this community mailing list to fix your problems at work. If NETZING has not bought a reset dongle and has no ability to manufacture one (which I seriously doubt, I have seen the NETZING electronics lab before) - then you will simply have to tell NETZING that this device will have to be bought or manufactured. If you are on a short deadline than I am sorry to hear this, but you will have to solve the problem somehow, and it is not the responsibility of the people on this list to do so. Also, please spend more time analyzing problems and investigating possible resolutions. Your follow-up mails regarding a USB connector are showing that you have neither studied the ip.access documentation (that NETZING has), nor our wiki in detail before contacting the list. Please use this list after you have exhausted all other resources. Regards, Harald. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From holger at freyther.de Fri Jul 23 11:07:55 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Fri, 23 Jul 2010 19:07:55 +0800 Subject: PATCH/RFC use recvfrom with MSG_TRUNC as flag Message-ID: <4C49780B.1080902@freyther.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; From spaar at mirider.augusta.de Fri Jul 23 15:27:19 2010 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Fri, 23 Jul 2010 15:27:19 CEST Subject: PATCH/RFC use recvfrom with MSG_TRUNC as flag Message-ID: <4c49b4d7.mirider@mirider.augusta.de> Hello Holger, On Fri, 23 Jul 2010 19:07:55 +0800, "Holger Hans Peter Freyther" 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 at mirider.augusta.de From holger at freyther.de Fri Jul 23 13:38:36 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Fri, 23 Jul 2010 21:38:36 +0800 Subject: PATCH/RFC use recvfrom with MSG_TRUNC as flag In-Reply-To: <4c49b4d7.mirider@mirider.augusta.de> References: <4c49b4d7.mirider@mirider.augusta.de> Message-ID: <4C499B5C.4070500@freyther.de> On 07/23/2010 03:27 PM, Dieter Spaar wrote: > > Thanks for asking. No problem, your contributions are always very welcome! > > 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). Well, I plan to use it in every recvfrom call in OpenBSC, not only GPRS, but if it is working on cygwin there might be no other obstacle in using it. PS: How big is your diff to make it compile on Windows? From spaar at mirider.augusta.de Fri Jul 23 15:58:26 2010 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Fri, 23 Jul 2010 15:58:26 CEST Subject: PATCH/RFC use recvfrom with MSG_TRUNC as flag Message-ID: <4c49bc22.mirider@mirider.augusta.de> Hello Holger, On Fri, 23 Jul 2010 21:38:36 +0800, "Holger Hans Peter Freyther" 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 at mirider.augusta.de From bertoncello at netzing.de Fri Jul 23 14:32:38 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Fri, 23 Jul 2010 16:32:38 +0200 Subject: [PATCH] Subscriber data in measurement report Message-ID: <20100723163238.29df2913@Luca> 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 at 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 at netzing.de _______________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: measurementWithSubscriber.patch Type: text/x-patch Size: 540 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From holger at freyther.de Tue Jul 27 20:03:13 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Wed, 28 Jul 2010 04:03:13 +0800 Subject: New cellmgr-ng git repository filled with content Message-ID: <4C4F3B81.70201@freyther.de> 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 From laforge at gnumonks.org Fri Jul 30 16:58:51 2010 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 30 Jul 2010 18:58:51 +0200 Subject: Wanted: Osmocom logo Message-ID: <20100730165851.GW13645@prithivi.gnumonks.org> 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 at lists.gnumonks.org mailing list. Thanks in advance for any submissions! -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From osmocom at lakedaemon.net Fri Jul 30 17:15:51 2010 From: osmocom at lakedaemon.net (Jason) Date: Fri, 30 Jul 2010 13:15:51 -0400 Subject: Wanted: Osmocom logo In-Reply-To: <20100730165851.GW13645@prithivi.gnumonks.org> References: <20100730165851.GW13645@prithivi.gnumonks.org> Message-ID: <4C5308C7.6070602@lakedaemon.net> Harald Welte wrote: > 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. > The first thing that jumped to mind was Tux with the GSM signal strength bars on his belly. :-) Then I remembered that while Linux is used in the development process, it doesn't run on the intended hardware... oops. Has Tux transcended Linux? Can he symbolize any open source effort? thx, Jason. From laforge at gnumonks.org Fri Jul 30 18:49:28 2010 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 30 Jul 2010 20:49:28 +0200 Subject: Wanted: Osmocom logo In-Reply-To: <4C5308C7.6070602@lakedaemon.net> References: <20100730165851.GW13645@prithivi.gnumonks.org> <4C5308C7.6070602@lakedaemon.net> Message-ID: <20100730184928.GZ13645@prithivi.gnumonks.org> Hi Jason, On Fri, Jul 30, 2010 at 01:15:51PM -0400, Jason wrote: > >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. > > > > The first thing that jumped to mind was Tux with the GSM signal strength bars > on his belly. :-) Then I remembered that while Linux is used in the > development process, it doesn't run on the intended hardware... oops. Has > Tux transcended Linux? Can he symbolize any open source effort? well, OpenBSC, OsmoSGSN, OpenGGSN and even layer23, osmcom, osmoload, etc. all run on the host PC, preferrably running Linux. So besides the firmware part, everything else actually has somewhat of a connection to Linux - though not really. Dieter runs everything but OsmoSGSN on Windows, and it should be pretty portable on any POSIX OS. So yes, I agree, referring to tux is probably not the best idea in our logo. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From zecke at selfish.org Fri Jul 30 20:20:50 2010 From: zecke at selfish.org (Holger Freyther) Date: Sat, 31 Jul 2010 04:20:50 +0800 Subject: Channel Release Changes to Master Message-ID: <4C533422.3060004@selfish.org> 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...