From 246tnt at gmail.com Tue Sep 22 22:16:38 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 23 Sep 2009 00:16:38 +0200 Subject: SMS delivery (Mobile Terminated): First ok, second fails In-Reply-To: <0015174c40b0cbe5df04722ef255@google.com> References: <0015174c40b0cbe5df04722ef255@google.com> Message-ID: <866320f70909221516t7a4a3eeas851a2442cdfa218d@mail.gmail.com> Hi Harald, I don't know if you saw that first email when I posted it (see below for reference), but I still can't decide where to put the trans_free. From the code, it's obvious you thought about it but apparently didn't decide yet since all call to it are commented :) In gsm411_rx_rp_ack(...) there is a comment saying "/* do not free the transaction here, this is done by sending CP-ACK */", however this is no longer true, the method sending the cp_ack is now called _before_ gsm411_rx_rp_ack and so doesn't free up the transaction anymore (the trans_free call in gsm411_tx_cp_ack is commented out). To me gsm411_rx_rp_ack sounds like the right place to do it but if you wrote that comment in the first place I guess you had reason not to do it there. Could you elaborate on that ? Sylvain I've noticed a problem when delivering several SMS to a mobile back-to-back. > The first one is ok, the second one is received by the MS but OpenBSC fails > with "RX RP-ACK but no sms in transaction?!?" when receiving the "RX SMS > RP-ACK (MO)" > (full log below) > > From the symptoms and looking at the code, I would say that the transaction > of the first SMS delivery was not freed, therefore, when we receive the > RP-ACK of the second SMS, we do a trans_find_by_id in gsm0411_rcv_sms, and > we actually find the transaction of the _first_ deliver (which has its .sms > field cleared since it was released already). > > I think you wouldn't notice if you waited between SMS because SMC Timer > TC1* would expire, calling trans_free(). > > The problem is that I don't really know _where_ trans_free should be > called. There are commented out call to it at several places ... > I would think the RP-ACK(MO) reception looks like a good place. But OTOH, > this whole process can queue data, giving away a reference to lchan (without > get) and trans_free does a put on lchan (so I guess that could invalidate > the lchan ref that was queued ? didn't check that in details) > > > Sylvain > > > --- SNIP --- > <0100> gsm_04_11.c:920 send_sms_lchan() > <0002> transaction.c:69 subscr=0x1fe52d0, subscr->net=0x1f8fc30 > <0002> gsm_subscriber_base.c:131 subscr 46332 usage increases usage to: 4 > <0002> gsm_04_11.c:937 lchan (bts=0,trx=0,ts=0,ch=0) increases usage to: 1 > <0100> gsm_04_11.c:972 TX: SMS DELIVER > <0100> gsm_04_11.c:188 TX: CP-DATA trans=4 > <0100> gsm_04_11.c:149 GSM4.11 TX 49 01 1e 01 2a 07 91 44 77 58 10 06 50 00 > 12 00 05 b9 72 65 f7 00 00 90 80 72 12 03 41 00 02 44 3a > <0001> abis_rsl.c:1215 channel=(bts=0,trx=0,ts=0) chan_nr=0x20 sapi=3 DATA > INDICATION > <0100> gsm_04_11.c:817 trans_id=c RX SMS CP-ACK > <0001> abis_rsl.c:1215 channel=(bts=0,trx=0,ts=0) chan_nr=0x20 sapi=3 DATA > INDICATION > <0100> gsm_04_11.c:817 trans_id=c RX SMS CP-DATA > <0100> gsm_04_11.c:191 TX: CP-ACK trans=4 > <0100> gsm_04_11.c:149 GSM4.11 TX 49 04 > <0100> gsm_04_11.c:750 RX SMS RP-ACK (MO) > <0002> gsm_subscriber_base.c:139 subscr 27567 usage decreased usage to: 0 > <0002> gsm_subscriber_base.c:139 subscr 46332 usage decreased usage to: 3 > DB: Found Subscriber: ID 2, IMSI 206205003327508, NAME '', TMSI 1666608304, > EXTEN '27567', LAC 1, AUTH 1 > DBI: -7: The requested variable type does not match what libdbi thinks it > should be > <0002> gsm_subscriber_base.c:131 subscr 46332 usage increases usage to: 4 > <0100> gsm_04_11.c:920 send_sms_lchan() > <0002> transaction.c:69 subscr=0x1fe52d0, subscr->net=0x1f8fc30 > <0002> gsm_subscriber_base.c:131 subscr 46332 usage increases usage to: 5 > <0002> gsm_04_11.c:937 lchan (bts=0,trx=0,ts=0,ch=0) increases usage to: 2 > <0100> gsm_04_11.c:972 TX: SMS DELIVER > <0100> gsm_04_11.c:188 TX: CP-DATA trans=4 > <0100> gsm_04_11.c:149 GSM4.11 TX 49 01 1f 01 2a 07 91 44 77 58 10 06 50 00 > 13 00 05 b9 72 65 f7 00 00 90 80 72 12 03 41 00 03 47 39 19 > <0001> abis_rsl.c:1215 channel=(bts=0,trx=0,ts=0) chan_nr=0x20 sapi=3 DATA > INDICATION > <0100> gsm_04_11.c:817 trans_id=c RX SMS CP-ACK > <0001> abis_rsl.c:1215 channel=(bts=0,trx=0,ts=0) chan_nr=0x20 sapi=3 DATA > INDICATION > <0100> gsm_04_11.c:817 trans_id=c RX SMS CP-DATA > <0100> gsm_04_11.c:191 TX: CP-ACK trans=4 > <0100> gsm_04_11.c:149 GSM4.11 TX 49 04 > <0100> gsm_04_11.c:750 RX SMS RP-ACK (MO) > <0100> gsm_04_11.c:640 RX RP-ACK but no sms in transaction?!? > <0100> gsm_04_11.c:561 TX: SMS RP ERROR, cause 111 (Protocol Error) > <0100> gsm_04_11.c:188 TX: CP-DATA trans=4 > <0100> gsm_04_11.c:149 GSM4.11 TX 49 01 04 05 2a 01 6f > <0001> abis_rsl.c:1215 channel=(bts=0,trx=0,ts=0) chan_nr=0x20 sapi=3 DATA > INDICATION > <0100> gsm_04_11.c:817 trans_id=c RX SMS CP-ACK > <0100> gsm_04_11.c:159 SMC Timer TC1* is expired, calling trans_free() > <0002> transaction.c:101 lchan (bts=0,trx=0,ts=0,ch=0) decreases usage to: > 1 > <0002> gsm_subscriber_base.c:139 subscr 46332 usage decreased usage to: 4 > --- /SNIP --- -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Sat Sep 26 17:08:40 2009 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 26 Sep 2009 19:08:40 +0200 Subject: SMS delivery (Mobile Terminated): First ok, second fails In-Reply-To: <866320f70909221516t7a4a3eeas851a2442cdfa218d@mail.gmail.com> References: <0015174c40b0cbe5df04722ef255@google.com> <866320f70909221516t7a4a3eeas851a2442cdfa218d@mail.gmail.com> Message-ID: <20090926170840.GQ6684@prithivi.gnumonks.org> Hi Sylvain, thanks for looking into this issue. On Wed, Sep 23, 2009 at 12:16:38AM +0200, Sylvain Munaut wrote: > I don't know if you saw that first email when I posted it (see below for > reference), but I still can't decide where to put the trans_free. From the > code, it's obvious you thought about it but apparently didn't decide yet > since all call to it are commented :) Yes, I also was not decided how to solve this problem properly. Most likely I first put it somewhere but then noticed that it doesn't work correctly and then placed a comment. > In gsm411_rx_rp_ack(...) there is a comment saying "/* do not free the > transaction here, this is done by sending CP-ACK */", however this is no > longer true, the method sending the cp_ack is now called _before_ > gsm411_rx_rp_ack and so doesn't free up the transaction anymore (the > trans_free call in gsm411_tx_cp_ack is commented out). > > To me gsm411_rx_rp_ack sounds like the right place to do it but if you wrote > that comment in the first place I guess you had reason not to do it there. > Could you elaborate on that ? I have played with so many different combinations and orders of the various commands/packets that I do not remember what worked how and with which phone. Honestly, I have spent way too much time reading the specifications, and I think they are extremely vague in places and much more difficult than any other part of the GSM specs that I've read. If you have a better understanding of them and can propose a fix, I'm happy to simply test and merge that, rather than again diving into this topic and wasting more than the days I have already put into it :( Regards. -- - 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 Sep 26 18:01:47 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sat, 26 Sep 2009 20:01:47 +0200 Subject: SMS delivery (Mobile Terminated): First ok, second fails In-Reply-To: <20090926170840.GQ6684@prithivi.gnumonks.org> References: <0015174c40b0cbe5df04722ef255@google.com> <866320f70909221516t7a4a3eeas851a2442cdfa218d@mail.gmail.com> <20090926170840.GQ6684@prithivi.gnumonks.org> Message-ID: <866320f70909261101i7eb4d2a0r14a4a4e1c8b1b4ae@mail.gmail.com> Hi Harald, > If you have a better understanding of them and can propose a fix, I'm happy to > simply test and merge that, rather than again diving into this topic and > wasting more than the days I have already put into it :( I don't have a deep understanding of the spec but all the state description and diagram I saw indicated that once you have the RP-ACK, it's over: nothing else to do, so freeing the transaction there makes sense. It's the patch I sent on the list a few days ago, along with the encryption fixes (4 patches submitted for merging in total). And it works with my setup (nanoBTS + tested 3 phones iPhone & cheap nokia & old T610). Sylvain From Andreas.Eversberg at versatel.de Sun Sep 6 15:21:11 2009 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Sun, 6 Sep 2009 17:21:11 +0200 Subject: fragmentation of E1 interfaces Message-ID: hi, to connect multiple BS11 to one single E1 interface via cascade, a special patch was required. now it is part of the mISDN GIT. (socket branch) use these module options: modprobe hfcmulti dmask=0x00000042 bmask=0x0000003c,0x00000780 debug=0x40000 the dmask will give a dchannel mask for the first E1 interface. multiple masks can be given for multiple E1 interfaces. the dmask will have bit set for each dchanne. in the example we have two bits set: slot 1 and slot 6. the bmask will give a bchannel mask for each given dchannel bit: for dchannel on slot 1 we use slot 2,3,4,5 for bchannel for dchannel on slot 6 we use slot 7,8,9,10 for bchannel the debug option displays initialization of E1 card on dmesg. misdn_info: Port 1 'hfc-e1.2-1': TE/NT-mode PRI E1 (for phone lines & E1 devices) 4 B-channels: 2-5 -------- Port 2 'hfc-e1.2-2': TE/NT-mode PRI E1 (for phone lines & E1 devices) 4 B-channels: 7-10 regards, andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andreas.Eversberg at versatel.de Sun Sep 6 15:21:19 2009 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Sun, 6 Sep 2009 17:21:19 +0200 Subject: new release of LCR (linux-call-router) Message-ID: hi, i just uploaded a new version of linux-call-router at www.linux-call-router.de. this version is equal to the current git. it has fixes, one is about conference creation and release. calls can now be forwarded by joining conference during ringing state: "*3#" and you may hang up, the party on hold will get transfered to the ringing phone. the major reason for a release is that OpenBSC main branch can be compiled with LCR, without any patch. hope you enjoy, andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Mon Sep 7 01:39:22 2009 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 7 Sep 2009 10:39:22 +0900 Subject: new release of LCR (linux-call-router) In-Reply-To: References: Message-ID: <20090907013922.GI3962@prithivi.gnumonks.org> Hi Andreas, On Sun, Sep 06, 2009 at 05:21:19PM +0200, Andreas.Eversberg wrote: > the major reason for a release is that OpenBSC main branch can be > compiled with LCR, without any patch. thanks again for your work on this lcr / OpenBSC integration. Even if you don't see much feedback or users here yet (at least Holger, Dieter any myself are currently only workin with OpenBSC standalone as far as I know) it is much appreciated. We're just all working on our own most important TODO items in the codebase... As soon as I'm back to Germany next week, I'll send a formal application for a GSM1800 test license at the 26C3 to the Germany regulatory authority. If we get this license, we're planning to deploy OpenBSC with lcr and interface this with the DECT network of the POC. I have recently obtained two more nanoBTS 1800, so assuming we can get Dieter + Holgers nanoBTS 1800 and a license for it, we should be able to run 5 TRX total capacity. Of course this will mean that we need to develop the RTP-to-MNCC integration, since nanoBTS voice channels arrive on RTP. I am willing to look into this, but I presume you also have a big interest in that (and maybe more time?). Since I now own more nanoBTS, I could send you one for 1-2 months of development of that code. Are you interested in this? Thanks in advance, Regards, -- - 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 Mon Sep 7 12:45:27 2009 From: zecke at selfish.org (Holger Freyther) Date: Mon, 7 Sep 2009 14:45:27 +0200 Subject: new release of LCR (linux-call-router) In-Reply-To: <20090907013922.GI3962@prithivi.gnumonks.org> References: <20090907013922.GI3962@prithivi.gnumonks.org> Message-ID: <200909071445.28187.zecke@selfish.org> On Monday 07 September 2009 03:39:22 Harald Welte wrote: > I have recently obtained two more nanoBTS 1800, so assuming we can get > Dieter + Holgers nanoBTS 1800 and a license for it, we should be able to > run 5 TRX total capacity. hmmm... I think you need to make it four.. I only have a nanoBTS900. > > Of course this will mean that we need to develop the RTP-to-MNCC > integration, since nanoBTS voice channels arrive on RTP. I am willing to > look into this, but I presume you also have a big interest in that (and > maybe more time?). This will most likely cross my path for BSC<->MSC integration as well, I don't when I get to this point though. > > Since I now own more nanoBTS, I could send you one for 1-2 months of > development of that code. Are you interested in this? > > Thanks in advance, > > Regards, From Andreas.Eversberg at versatel.de Mon Sep 7 17:14:21 2009 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Mon, 7 Sep 2009 19:14:21 +0200 Subject: AW: new release of LCR (linux-call-router) Message-ID: hi harald, >Of course this will mean that we need to develop the RTP-to-MNCC integration, since nanoBTS voice channels arrive on RTP. I am willing to look into this, but I presume you also have a big interest in that (and maybe more time?). i am interested having RTP audio available to MNCC interface as well. the audio stream (frames) should be equal for BS11 and nanoBTS, so both streams work for MNCC interface without different handling on the application side. for this i would like to cross-convert the frame coding of BS11 to the actual gsm format inside OpenBSC instead of just forwarding the TRAU frame format. if the TRAU frame is converted inside OpenBSC, calls from BS11 to nanoBTS would also be possible. >Since I now own more nanoBTS, I could send you one for 1-2 months of development of that code. Are you interested in this? yes, i am. this way it is easier to run some tests. regards, andreas From laforge at gnumonks.org Sat Sep 12 09:34:18 2009 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 12 Sep 2009 11:34:18 +0200 Subject: new release of LCR (linux-call-router) In-Reply-To: References: Message-ID: <20090912093418.GY4051@prithivi.gnumonks.org> Hi Andreas, On Mon, Sep 07, 2009 at 07:14:21PM +0200, Andreas.Eversberg wrote: > i am interested having RTP audio available to MNCC interface as well. > the audio stream (frames) should be equal for BS11 and nanoBTS, so both > streams work for MNCC interface without different handling on the > application side. for this i would like to cross-convert the frame > coding of BS11 to the actual gsm format inside OpenBSC instead of just > forwarding the TRAU frame format. I think this makes a lot of sense. In addition to that, when passing the GSM formwat frame up to the application, we should also send some kind of "format identifier" > if the TRAU frame is converted inside OpenBSC, calls from BS11 to nanoBTS > would also be possible. yes, I agree. > > Since I now own more nanoBTS, I could send you one for 1-2 months of > > development of that code. Are you interested in this? > > yes, i am. this way it is easier to run some tests. I am currently once again travelling (after arriving back in Berlin yesterday), and I'll return wednesday next week. I think on Thursday I'll be able to send the nanoBTS to you. If you have any difficulties configuring the nanoBTS or getting it to work with OpenBSC, please simply post to this mailinglist, Dieter, Holger and others have done this before and are able to help just as much as I might be. Thanks in advance, -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From risky at mail.ru Mon Sep 7 16:37:31 2009 From: risky at mail.ru (Sergey V. Efimoff) Date: Mon, 7 Sep 2009 20:37:31 +0400 Subject: DTMF processing errors Message-ID: Hello All, While testing DTMF facilities of OpenBS? I've discovered a couple of bugs. The first bug is generic to GSM TS 04.08, minor and is connected with gsm0408_cc_msg_names variable (gsm_04_08_utils.c). I've found that message names order is wrong: in original source it is enumerated as ... "unknown 0x3b", "STATUS", "unknown 0x3c" "NOTIFY" ... while it should be ... "unknown 0x3b" "unknown 0x3c" "STATUS" "NOTIFY" ... thus faling to identify GSM 04.08 STATUS messages. The second problem is connected with DTMF message sequence. According to the GSM TS 04.08, DTMF message flow is the following: MS -----> START_DTMF MNCC_START_DTMF_IND ----> MNCC MNCC_START_DTMF_RSP <---- MNCC MS <---- START_DTMF_ACK MS ----> STOP_DTMF MNCC_STOP_DTMF_IND ----> MNCC MNCC_STOP_DTMF_RSP <---- MNCC MS <---- STOP_DTMF_ACK This is correct, but some mobile equipment (for example, my iPhone and Nokia 6150) do not reply with STOP_DTMF message; instead of this, they reply with STATUS message (type 0x3D). This type of messages is not processed within OpenBSC. Message is left unhandled in this state and further DTMF transactions become impossible because MNCC does not receive DTMF_STOP. GSM standard says that STATUS message reports about some errors occurred during transaction, but I did not explore the message still, though, I can do that if it is interesting for developers. I have no ideas why some of my mobile phones behave wrong, while others work correctly. I still don't know how to deal with STATUS messages properly, so I've simply added processing entry to the datastatelist[] variable in gsm_04_08.c which describes a call to gsm48_cc_rx_stop_dtmf when received a STATUS message. It is incorrect, I know, but, however, temporary helps to process DTMF messages with MS equipment which have wrong DTMF sequence flow. Now it looks like this: MS -----> START_DTMF MNCC_START_DTMF_IND ----> MNCC MNCC_START_DTMF_RSP <---- MNCC MS <---- START_DTMF_ACK MS ----> STATUS MNCC_STOP_DTMF_IND ----> MNCC MNCC_STOP_DTMF_RSP <---- MNCC MS <---- STOP_DTMF_ACK Sergey. From laforge at gnumonks.org Sat Sep 12 09:31:19 2009 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 12 Sep 2009 11:31:19 +0200 Subject: DTMF processing errors In-Reply-To: References: Message-ID: <20090912093119.GX4051@prithivi.gnumonks.org> On Mon, Sep 07, 2009 at 08:37:31PM +0400, Sergey V. Efimoff wrote: > Hello All, > > While testing DTMF facilities of OpenBS? I've discovered a couple of > bugs. Dear Sergey, thanks for your feedback. Please note though that OpenBSC doesn't really have any DTMF facilities as such, apart from a couple of stubs that were added to later actually add DTMF support. > The first bug is generic to GSM TS 04.08, minor and is connected > with gsm0408_cc_msg_names variable > (gsm_04_08_utils.c). I've found that message names order is wrong: > in original source it is enumerated as > > ... > "unknown 0x3b", > "STATUS", > "unknown 0x3c" > "NOTIFY" > ... > > while it should be > > ... > "unknown 0x3b" > "unknown 0x3c" > "STATUS" > "NOTIFY" > ... > > thus faling to identify GSM 04.08 STATUS messages. thanks. It would be great if you could send us a patch (diff -u), as this is how we typically receive bugfixes or other contributions to our source code. This way only one person has to implement the fix, and we can simply apply the patch to our repository. > The second problem is connected with DTMF message sequence. > According to the GSM TS 04.08, DTMF > message flow is the following: > > MS -----> START_DTMF > MNCC_START_DTMF_IND ----> MNCC > MNCC_START_DTMF_RSP <---- MNCC > MS <---- START_DTMF_ACK > MS ----> STOP_DTMF > MNCC_STOP_DTMF_IND ----> MNCC > MNCC_STOP_DTMF_RSP <---- MNCC > MS <---- STOP_DTMF_ACK > > This is correct, but some mobile equipment (for example, my iPhone > and Nokia 6150) do not reply with > STOP_DTMF message; instead of this, they reply with STATUS message > (type 0x3D). This type of messages is > not processed within OpenBSC. Message is left unhandled in this > state and further DTMF transactions > become impossible because MNCC does not receive DTMF_STOP. This sounds _really_ weird. It might well be that we are sending something wrong to the phone, and the phone thus sends us some generic error (as part of the STATUS) > GSM standard says that STATUS message reports about some errors > occurred during transaction, but I did not explore the message still, though, > I can do that if it is interesting for developers. I have no ideas why > some of my mobile phones behave wrong, while others work correctly. I really think there is something wrong that we are doing in the message syntax or state transitions. Some phones are more tolerant to this than others. It would be interesting to see a protocol trace of such a phone with a "real" network. Of course that is hard to obtain unless you happen to work at an operator or have a demo/testing network with real operator equipment. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From womax at gmx.ch Wed Sep 9 08:44:12 2009 From: womax at gmx.ch (WoMax) Date: Wed, 9 Sep 2009 10:44:12 +0200 Subject: Siemens born nanoBTS Message-ID: I got a few Siemens born nanoBTS, this is OEM from ip.access for project MOGIS. They are new in box. Details on http://umts.zerber.us From cleb at defcon-3.net Mon Sep 14 02:03:53 2009 From: cleb at defcon-3.net (Caleb Pal) Date: Sun, 13 Sep 2009 19:03:53 -0700 Subject: Ericsson RBS 2401 Status Message-ID: <003801ca34df$9d237b20$d76a7160$@net> Hello all, Just thought I would give everyone an update on my progress with the Ericsson RBS. I got a T1 card, a Digium TE122P (http://www.digium.com/en/products/digital/te122.php). This card support E1/T1/J1. The 2401 I have only supports T1, otherwise I would have gotten a HFC based chipset that OpenBSC supports. The TE122P uses the DAHDI drivers, which used to be Zaptel. In reading through the list archives, I found a couple tidbits about Zaptel. The first was back in February from Harald: http://lists.gnumonks.org/pipermail/openbsc/2009-February/000023.html. I didn't see any updates after that. Were there updates made to make the integration with other drivers easier? The next I found was in March from Klaus-Peter Junghann: http://lists.gnumonks.org/pipermail/openbsc/2009-March/000064.html. It looks like he actually got the Zaptel driver to work. I'm not sure how much of Zaptel has changed when the driver set was renamed to DAHDI. I did not see a post from Mr. Junghann with the zaptel input module he spoke of. I'm not sure what the interest level is with getting OpenBSC to integrate with Ericsson RBS's? Like I previously mentioned, I am not much of a coder, so I can't help much in that department. That being said, I am willing to provide remote access to all the resources I have here (Debian Linux 5.0 Server, RBS 2401, Windows LMT). I can also provide access to a spec an (which would be accessed via software on the Windows LMT) if needed down the road. I am going to look into a STA to test on a couple ARFCN's in the GSM1900 band, and I am more than willing to help with handset debugging at that stage. I have quite a few different handsets lying around! Thanks much, Caleb -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Mon Sep 14 04:39:26 2009 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 14 Sep 2009 06:39:26 +0200 Subject: Ericsson RBS 2401 Status In-Reply-To: <003801ca34df$9d237b20$d76a7160$@net> References: <003801ca34df$9d237b20$d76a7160$@net> Message-ID: <20090914043926.GF11036@prithivi.gnumonks.org> Hi Celeb, thanks for your status update. On Sun, Sep 13, 2009 at 07:03:53PM -0700, Caleb Pal wrote: > The first was back in February from Harald: > http://lists.gnumonks.org/pipermail/openbsc/2009-February/000023.html. I > didn't see any updates after that. Were there updates made to make the > integration with other drivers easier? There were no successive updates, but the restructuring of the input layer indicated in that February post should make it already much easier. I have zero idea how the various E1 / T1 related API's look like, but at least from my feeling a number of the E1 common bits have been factored out and the driver should only need to deal with the minimum neccessary device-specific parts. > The next I found was in March from Klaus-Peter Junghann: > http://lists.gnumonks.org/pipermail/openbsc/2009-March/000064.html. It looks > like he actually got the Zaptel driver to work. I'm not sure how much of > Zaptel has changed when the driver set was renamed to DAHDI. I did not see a > post from Mr. Junghann with the zaptel input module he spoke of. Klaus-Peter: Can you please provide your patches? I know they are likely against an old version of OpenBSC and might be more a quick hack than an actual OpenBSC input driver. However, I'd rather see us work from that code than to duplicate your efforts. Thanks. > I'm not sure what the interest level is with getting OpenBSC to integrate > with Ericsson RBS's? Like I previously mentioned, I am not much of a coder, > so I can't help much in that department. That being said, I am willing to > provide remote access to all the resources I have here (Debian Linux 5.0 > Server, RBS 2401, Windows LMT). I can also provide access to a spec an > (which would be accessed via software on the Windows LMT) if needed down the > road. I am going to look into a STA to test on a couple ARFCN's in the > GSM1900 band, and I am more than willing to help with handset debugging at > that stage. I have quite a few different handsets lying around! I think the biggest need is to get protocol traces taken between the RBS and a real-world BSC. Only from those traces we can learn about the vendor-specific Abis extensions. Especialy the OML is typically full of vendor-specific stuff, and we need OML for the early bringup of the BTS. I will try to get some, but I am not sure if I can. In any case, if you have some option to get protocol traces, I am willing to look into adding RBS support. Regards, -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From kpj at junghanns.net Mon Sep 14 07:42:56 2009 From: kpj at junghanns.net (Klaus-Peter Junghanns) Date: Mon, 14 Sep 2009 09:42:56 +0200 Subject: Ericsson RBS 2401 Status In-Reply-To: <20090914043926.GF11036@prithivi.gnumonks.org> References: <003801ca34df$9d237b20$d76a7160$@net> <20090914043926.GF11036@prithivi.gnumonks.org> Message-ID: <4AADF400.2080308@junghanns.net> Harald Welte wrote: > On Sun, Sep 13, 2009 at 07:03:53PM -0700, Caleb Pal wrote: > >> The next I found was in March from Klaus-Peter Junghann: >> http://lists.gnumonks.org/pipermail/openbsc/2009-March/000064.html. It looks >> like he actually got the Zaptel driver to work. I'm not sure how much of >> Zaptel has changed when the driver set was renamed to DAHDI. I did not see a >> post from Mr. Junghann with the zaptel input module he spoke of. > > Klaus-Peter: Can you please provide your patches? I know they are likely > against an old version of OpenBSC and might be more a quick hack than an actual > OpenBSC input driver. However, I'd rather see us work from that code than to > duplicate your efforts. Thanks. > Hi, unfortunately i did not have the time yet to do anything regarding layer 2, that's why there are no patches, yet. The only thing i did was to load the zaptel driver, configure zaptel.conf to provide an internal clock and turn on the BS-11. I could see the BS-11 was sending TEI requests. But zaptel/dahdi is just a layer 1 driver framework, anything above that has to be done by the application (e.g. a new input module for openbsc). Sorry, guys! -- Mit freundlichen Gr??en / best regards Klaus-Peter Junghanns Junghanns.NET Gesellschaft fuer Internet-Services & Software-Development mbH Breite Str. 13a 12167 Berlin Germany Geschaeftsfuehrer : Klaus-Peter Junghanns Eingetragen beim Amtsgericht Charlottenburg, HRB 79169 Finanzamt fuer Koerperschaften III, Steuernummer 29/409/8978 Umsatzsteuernummer : DE 217621658 WEEE-Reg.-Nr. DE 86102730 From oystein at homelien.no Mon Sep 14 10:08:43 2009 From: oystein at homelien.no (Oystein Homelien) Date: Mon, 14 Sep 2009 12:08:43 +0200 (CEST) Subject: Ericsson RBS 2401 Status In-Reply-To: <4AADF400.2080308@junghanns.net> References: <003801ca34df$9d237b20$d76a7160$@net> <20090914043926.GF11036@prithivi.gnumonks.org> <4AADF400.2080308@junghanns.net> Message-ID: On Mon, 14 Sep 2009, Klaus-Peter Junghanns wrote: > I could see the BS-11 was sending TEI requests. But zaptel/dahdi > is just a layer 1 driver framework, anything above that has to > be done by the application (e.g. a new input module for openbsc). The non-up-to-date Sangoma E1 driver for openbsc I recently posted as a patch to this list on request, has a minimal lap-d implementation in the file tei.[ch]. You might want to see if it can be used for the zaptel efforts. yours, oystein From cleb at defcon-3.net Mon Sep 14 02:19:33 2009 From: cleb at defcon-3.net (Caleb Pal) Date: Sun, 13 Sep 2009 19:19:33 -0700 Subject: Motorola V3 Force ARFCN Message-ID: <005701ca34e1$cd675e30$68361a90$@net> Hello, While experimenting with a Motorola V3 GSM branded for AT&T, I enabled the Engineering Menu with a SEEM edit. Not a terribly hard procedure once you know where to look. After performing this hack, I looked in the Engineering Menu, and there is an option to force the ARFCN the phone camps on. I think this would be a useful tool if you want to force a handset to camp on your Base Station. I'm not if it will help with the clock issues, but it might alleviate some frustration. The Original V3's (no 3G) can be found on ebay for a decent price. I'm not sure if any other phones include this functionality (I haven't come across any), so I thought I would share it with you all. If you need help performing the SEEM edit, let me know. Caleb -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailinglists at hellercom.de Mon Sep 14 04:30:38 2009 From: mailinglists at hellercom.de (Bjoern Heller) Date: Mon, 14 Sep 2009 06:30:38 +0200 Subject: Motorola V3 Force ARFCN In-Reply-To: <005701ca34e1$cd675e30$68361a90$@net> References: <005701ca34e1$cd675e30$68361a90$@net> Message-ID: <5A4E59B7-1A13-48C5-ADC2-966F354027B7@hellercom.de> Hello, This option works with most Motorola phones. For example if you have the Razr etc. What you need is only the TripletToolCompilation software and the special USB driver. Tec Am 14.09.2009 um 04:19 schrieb Caleb Pal: > Hello, > > While experimenting with a Motorola V3 GSM branded for AT&T, I > enabled the Engineering Menu with a SEEM edit. Not a terribly hard > procedure once you know where to look. After performing this hack, I > looked in the Engineering Menu, and there is an option to force the > ARFCN the phone camps on. I think this would be a useful tool if you > want to force a handset to camp on your Base Station. I?m not if it > will help with the clock issues, but it might alleviate some > frustration. The Original V3?s (no 3G) can be found on ebay for a > decent price. I?m not sure if any other phones include this > functionality (I haven?t come across any), so I thought I would > share it with you all. If you need help performing the SEEM edit, > let me know. > > Caleb - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Bj?rn Heller Jabber: tec at jabber.hellercom.de -------------- next part -------------- An HTML attachment was scrubbed... URL: From jolly at eversberg.eu Mon Sep 14 11:25:32 2009 From: jolly at eversberg.eu (Andreas Eversberg) Date: Mon, 14 Sep 2009 13:25:32 +0200 Subject: AW: new 1.6 debian packages for lcr and misdnuser In-Reply-To: <20090909085857.GH9518@Redstar.dorchain.net> Message-ID: <200909141125.n8EBPbYH030115@mail.ibsd.net> hi joerg, i am not into debian. can you explain: - what files in your directory http://www.dorchain.net/~joerg/code/debian/ should be added to the git repository? - where should they be located? (inside lcr directory) - what files of original lcr or mISDN git are changed? thanx in advance, andreas From joerg at dorchain.net Mon Sep 14 12:40:12 2009 From: joerg at dorchain.net (Joerg Dorchain) Date: Mon, 14 Sep 2009 14:40:12 +0200 Subject: new 1.6 debian packages for lcr and misdnuser In-Reply-To: <200909141125.n8EBPbYH030115@mail.ibsd.net> References: <20090909085857.GH9518@Redstar.dorchain.net> <200909141125.n8EBPbYH030115@mail.ibsd.net> Message-ID: <20090914124011.GD4209@Redstar.dorchain.net> On Mon, Sep 14, 2009 at 01:25:32PM +0200, Andreas Eversberg wrote: > > i am not into debian. can you explain: no problem. First let me point you to the debian packaging howto: http://www.debian.org/doc/maint-guide/ > - what files in your directory http://www.dorchain.net/~joerg/code/debian/ > should be added to the git repository? At this place you not only find the binary packages, but also the sources. The sources consist of - lcr_1.6~20090906.orig.tar.gz, which is the same as http://www.linux-call-router.de/download/lcr-1.6/lcr_20090906.tar.gz, just with a naming according to debian conventions (don't worry about that. Names are the least problem, just stick with yours.) - lcr_1.6~20090906-1.dsc, which is a short description of the source with several checksums to ensure integrity - lcr_1.6~20090906-1.diff.gz, which contains the changes/additions to your original version. This is the interesting stuff here. For misdn, the analog holds. The diff creates a single directory "debian/" in the root directory of the source. Everything debian specific is contained therein. If you just ignore it all else builds as before. > - where should they be located? (inside lcr directory) As per convention: A single directory debian/ just underneath the main directory. > - what files of original lcr or mISDN git are changed? Directly none. For lcr, there is a subdirectory inside the debian directory debian/patches/, which contains the modifications. it is based on quilt (yes, that is overkill here ;-). Only two patches are currently active (look in the series file inside this directory): replace_local.patch, which changes installation paths to be more debian compliant, and configure_warning, which remove a warning with the current debian build system. For misdn, two patches are active. One that fixes a problem and is probably already in your tree, the other prevents the shared libmisdn.so from being installed, as there are currently some objections here and at the moment the tools in this package are the only one using it. debian/rules is basically a make file with a very strong debian dialect in it. For you, I assume, the patch, configure, and build target are most interesting. FYI, there is also an svn repository for the debian-specify stuff explaining the choosen layout at http://svn.debian.org/wsvn/pkg-voip/README?op=file and http://svn.debian.org/wsvn/pkg-voip/ I would not mind building against the current head of development, but IMHO the distribution would better accept releases. Besides, there need to be support (e.g. in the form of branches) for security fixes in older versions, should the package ever make it into a debian stable release. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 266 bytes Desc: Digital signature URL: From laforge at gnumonks.org Tue Sep 22 15:53:11 2009 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 23 Sep 2009 00:53:11 +0900 Subject: List is quiet... Message-ID: <20090922155311.GD5149@prithivi.gnumonks.org> Hi! I'm surprised that this list is so quiet... no mails for more than a week already. Is anybody still playing with, developing or using OpenBSC? I would really appreciate more community participation, such as * more documentation in the wiki * talk about what you're doing with OpenBSC (esp. the universities!) * discussion / sharing of your experience * bug reports (should probably go in trac) * patches! 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 e.cathelinaud at googlemail.com Tue Sep 22 17:35:36 2009 From: e.cathelinaud at googlemail.com (Eric Cathelinaud) Date: Tue, 22 Sep 2009 19:35:36 +0200 Subject: List is quiet... In-Reply-To: <20090922155311.GD5149@prithivi.gnumonks.org> References: <20090922155311.GD5149@prithivi.gnumonks.org> Message-ID: <383f8f9a0909221035u53f35815n9d42dc8267b941bc@mail.gmail.com> Hi! For now I am no more using it but my university looks interested to do projects with it. I will talk with them about it again tomorrow. Regards Eric 2009/9/22 Harald Welte > Hi! > > I'm surprised that this list is so quiet... no mails for more than a week > already. > > Is anybody still playing with, developing or using OpenBSC? I would really > appreciate more community participation, such as > > * more documentation in the wiki > * talk about what you're doing with OpenBSC (esp. the universities!) > * discussion / sharing of your experience > * bug reports (should probably go in trac) > * patches! > > 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 -------------- An HTML attachment was scrubbed... URL: From s4dd at losers.yore.ma Tue Sep 22 18:22:43 2009 From: s4dd at losers.yore.ma (s4dd at losers.yore.ma) Date: Tue, 22 Sep 2009 19:22:43 +0100 Subject: List is quiet... In-Reply-To: <20090922155311.GD5149@prithivi.gnumonks.org> References: <20090922155311.GD5149@prithivi.gnumonks.org> Message-ID: <4AB915F3.6040501@losers.yore.ma> Harald Welte wrote: > Hi! > > I'm surprised that this list is so quiet... no mails for more than a week > already. -snip- Greetings from a group of Postgrad students in Ireland! Very interested in starting to talk/discuss our experiences with openbsc... This is somewhat hampered our lack of access to any suitable equipment! I've sent in a request for equipment availability to bs11 at domain.tld and await a response. Hopefully we will be joining in on the fun soon enough. Regards, Paul From laforge at gnumonks.org Sat Sep 26 16:49:32 2009 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 26 Sep 2009 18:49:32 +0200 Subject: List is quiet... In-Reply-To: <4AB915F3.6040501@losers.yore.ma> References: <20090922155311.GD5149@prithivi.gnumonks.org> <4AB915F3.6040501@losers.yore.ma> Message-ID: <20090926164932.GM6684@prithivi.gnumonks.org> On Tue, Sep 22, 2009 at 07:22:43PM +0100, s4dd at losers.yore.ma wrote: > Greetings from a group of Postgrad students in Ireland! > > Very interested in starting to talk/discuss our experiences with > openbsc... This is somewhat hampered our lack of access to any > suitable equipment! I've sent in a request for equipment > availability to bs11 at domain.tld and await a response. Unfortunately the BS-11 are almost all gone, and I am still waiting for other people who have previously indicated their interest to actually get back to my recent mail to confirm the purchase. I will let you know if those people who sent their request earlier fail to follow up with an actual purchase (i.e. some BS-11 still being left over) Cheers, -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From s4dd at losers.yore.ma Sat Sep 26 17:37:49 2009 From: s4dd at losers.yore.ma (s4dd at losers.yore.ma) Date: Sat, 26 Sep 2009 18:37:49 +0100 Subject: List is quiet... In-Reply-To: <20090926164932.GM6684@prithivi.gnumonks.org> References: <20090922155311.GD5149@prithivi.gnumonks.org> <4AB915F3.6040501@losers.yore.ma> <20090926164932.GM6684@prithivi.gnumonks.org> Message-ID: <4ABE516D.5010505@losers.yore.ma> Harald Welte wrote: > On Tue, Sep 22, 2009 at 07:22:43PM +0100, s4dd at losers.yore.ma wrote: > > >> Greetings from a group of Postgrad students in Ireland! >> >> Very interested in starting to talk/discuss our experiences with >> openbsc... This is somewhat hampered our lack of access to any >> suitable equipment! I've sent in a request for equipment >> availability to bs11 at domain.tld and await a response. >> > > Unfortunately the BS-11 are almost all gone, and I am still waiting for other > people who have previously indicated their interest to actually get back to > my recent mail to confirm the purchase. > > I will let you know if those people who sent their request earlier fail > to follow up with an actual purchase (i.e. some BS-11 still being left over) > > Cheers, > Thanks for the update Harald, much appreciated. We have money waiting to send if anyone pulls out (or even if they take too long to get back to you!), so do please keep us in mind. Again, many thanks, -Paul From bouchtaoui at gmail.com Tue Sep 22 21:48:48 2009 From: bouchtaoui at gmail.com (Nordin Bouchtaoui) Date: Tue, 22 Sep 2009 23:48:48 +0200 Subject: List is quiet... In-Reply-To: <20090922155311.GD5149@prithivi.gnumonks.org> References: <20090922155311.GD5149@prithivi.gnumonks.org> Message-ID: <8aedb85a0909221448g5d99fe1dl94e5ddcb416d4dc0@mail.gmail.com> Hello Harald, I'm still in the game :p But since the summer holiday is over, I have some other projects to finish with higher priority. Also I'm studying the theoretical background of GSM and your source for better understanding and hopefully be a better help for the OpenBSC project. By the way, did you know in Holland next year from January, some GSM frequencies will be publicly available with NO license required. This means you are allowed to have your own GSM network! Hmmm... 2009/9/22 Harald Welte > Hi! > > I'm surprised that this list is so quiet... no mails for more than a week > already. > > Is anybody still playing with, developing or using OpenBSC? I would really > appreciate more community participation, such as > > * more documentation in the wiki > * talk about what you're doing with OpenBSC (esp. the universities!) > * discussion / sharing of your experience > * bug reports (should probably go in trac) > * patches! > > 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 -------------- An HTML attachment was scrubbed... URL: From mailinglists at hellercom.de Tue Sep 22 21:58:51 2009 From: mailinglists at hellercom.de (Bjoern Heller) Date: Tue, 22 Sep 2009 23:58:51 +0200 Subject: List is quiet... In-Reply-To: <8aedb85a0909221448g5d99fe1dl94e5ddcb416d4dc0@mail.gmail.com> References: <20090922155311.GD5149@prithivi.gnumonks.org> <8aedb85a0909221448g5d99fe1dl94e5ddcb416d4dc0@mail.gmail.com> Message-ID: Hello Harald, I`m still here. Lots of work to do, so not much time for OpenBSC. But still playing around with OpenBSC. Regards Bjoern - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Bj?rn Heller Jabber: tec at jabber.hellercom.de -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Tue Sep 22 22:28:11 2009 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 23 Sep 2009 07:28:11 +0900 Subject: List is quiet... In-Reply-To: <8aedb85a0909221448g5d99fe1dl94e5ddcb416d4dc0@mail.gmail.com> References: <20090922155311.GD5149@prithivi.gnumonks.org> <8aedb85a0909221448g5d99fe1dl94e5ddcb416d4dc0@mail.gmail.com> Message-ID: <20090922222811.GH5149@prithivi.gnumonks.org> On Tue, Sep 22, 2009 at 11:48:48PM +0200, Nordin Bouchtaoui wrote: > By the way, did you know in Holland next year from January, some GSM > frequencies will be publicly available with NO license required. This means > you are allowed to have your own GSM network! Yes, I am aware of the unlicensed availability of the former DECT Guard band (GSM 1800) for low-power GSM applications in .nl I thought that was already the case now, not only from next year on. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From thomas.bhatia at gmail.com Thu Sep 24 09:27:38 2009 From: thomas.bhatia at gmail.com (Tom) Date: Thu, 24 Sep 2009 10:27:38 +0100 Subject: List is quiet... In-Reply-To: <20090922155311.GD5149@prithivi.gnumonks.org> References: <20090922155311.GD5149@prithivi.gnumonks.org> Message-ID: <4ABB3B8A.8020008@gmail.com> Harald Welte wrote: > Hi! > > I'm surprised that this list is so quiet... no mails for more than a week > already. > > Is anybody still playing with, developing or using OpenBSC? I would really > appreciate more community participation, such as > > * more documentation in the wiki > * talk about what you're doing with OpenBSC (esp. the universities!) > * discussion / sharing of your experience > * bug reports (should probably go in trac) > * patches! > > Regards, > Harald > Hello! I have got some nanoBTSs, ip.access BSC and MSC to test/play with OpenBSC. I'm not much of a programmer but an integrator so cannot help with patching. But I can help with everything else. Only thing is unlike the BS11, there's no way of routing calls to asterisk with the nanoBTS, am I correct? I'd really like to see that functionality and if appropriate would like to post a bounty for it. Regards, Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3274 bytes Desc: S/MIME Cryptographic Signature URL: From laforge at gnumonks.org Thu Sep 24 12:16:16 2009 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 24 Sep 2009 21:16:16 +0900 Subject: List is quiet... In-Reply-To: <4ABB3B8A.8020008@gmail.com> References: <20090922155311.GD5149@prithivi.gnumonks.org> <4ABB3B8A.8020008@gmail.com> Message-ID: <20090924121616.GE3930@prithivi.gnumonks.org> Hi Tom, On Thu, Sep 24, 2009 at 10:27:38AM +0100, Tom wrote: > I have got some nanoBTSs, ip.access BSC and MSC to test/play with > OpenBSC. I'm not much of a programmer but an integrator so cannot help > with patching. But I can help with everything else. This is actually very useful to us. Since you have the full setup with BSC and MSC, you could e.g. help us with protocol traces of your ip.access system. You can use wireshark or ethereal to created packet captures (pcaps) while you are performing certain operations. Right now, e.g., people are looking for ways to implement GPRS and EDGE support in the nanoBTS. So maybe you could provide a set of separate A-bis-over-IP traces between BTS and BSC for the following actions: * bootstrapping a nanoBTS in a network that supports GPRS / EDGE * registering one GPRS-capable telephone to the network * establishing the PDP context * actually transferring some IP data over it * deactivation of PDP context * deactivation of the GPRS-capable telephone Furthermore, I think it would be very useful to get packet captures when the nanoBTS uses the multiplexed RTP mode (for NAT traversal), as we could then also work on implementing this protocol in OpenBSC. If you could help with any of that, it would be much appreciated. > Only thing is unlike the BS11, there's no way of routing calls to asterisk > with the nanoBTS, am I correct? I'd really like to see that functionality > and if appropriate would like to post a bounty for it. Andreas Eversberg has indicated that he wants to work on this, I suggest you talk to him if there is anything you can help him with. I would assume that you could easily bribe him with giving him a nanoBTS in return for finishing a OpenBSC <-> LCR integration for the nanoBTS. -- - 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 Tue Sep 22 15:56:28 2009 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 23 Sep 2009 00:56:28 +0900 Subject: OpenBSC related job offer in Dresden / Germany Message-ID: <20090922155628.GE5149@prithivi.gnumonks.org> Hi all! I have recently been informed there is a job opening related to OpenBSC in Dresden / Germany. So if you're interested in working full time on issues such as * integrating OpenBSC into actual applications / products * testing OpenBSC with various handsets in various scenarios * sending bug reports and interacting with actual developers The job is not really about development of the OpenBSC stack itself, but related to system integration. So don't worry if you are neither a full-blown programmer, nor know the GSM protocol specs up to the last bit .. Please drop me a note, in case you're interested. Regards, -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From jens.david at jens-david-consulting.com Tue Sep 22 19:14:08 2009 From: jens.david at jens-david-consulting.com (Jens David) Date: Tue, 22 Sep 2009 21:14:08 +0200 Subject: OpenBSC related job offer in Dresden / Germany In-Reply-To: <20090922155628.GE5149@prithivi.gnumonks.org> References: <20090922155628.GE5149@prithivi.gnumonks.org> Message-ID: <80569762-9A0F-473D-B8D5-658DCE45020E@jens-david-consulting.com> Mhhh, job opening in my hometown? Interesting. Not so many companies there working on related activities. In case it is from (ST-)NXP, BlueWonder, Signalion or other University Mobile Communication ((-pseudo)-spinoff) it would be a good idea to get well informed before signing up I might add from own and ex- colleagues accounts... --j Am 22.09.2009 um 17:56 schrieb Harald Welte: > Hi all! > > I have recently been informed there is a job opening related to > OpenBSC > in Dresden / Germany. So if you're interested in working full time on > issues such as > > * integrating OpenBSC into actual applications / products > * testing OpenBSC with various handsets in various scenarios > * sending bug reports and interacting with actual developers > > The job is not really about development of the OpenBSC stack itself, > but > related to system integration. So don't worry if you are neither a > full-blown > programmer, nor know the GSM protocol specs up to the last bit .. > > Please drop me a note, in case you're interested. > > Regards, > -- > - Harald Welte http://laforge.gnumonks.org/ > = > = > = > = > = > = > ====================================================================== > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 > Ch. A6) > -- Jens David, DG1KJD jens.david at jens-david-consulting.com http://www.jens-david-consulting.com From laforge at gnumonks.org Tue Sep 22 22:22:10 2009 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 23 Sep 2009 07:22:10 +0900 Subject: OpenBSC related job offer in Dresden / Germany In-Reply-To: <80569762-9A0F-473D-B8D5-658DCE45020E@jens-david-consulting.com> References: <20090922155628.GE5149@prithivi.gnumonks.org> <80569762-9A0F-473D-B8D5-658DCE45020E@jens-david-consulting.com> Message-ID: <20090922222210.GF5149@prithivi.gnumonks.org> On Tue, Sep 22, 2009 at 09:14:08PM +0200, Jens David wrote: > Interesting. Not so many companies there working on related activities. you think so, at least ;) > In case it is from (ST-)NXP, BlueWonder, Signalion or other > University Mobile Communication ((-pseudo)-spinoff) it would be a > good idea to get well informed before signing up I might add from > own and ex-colleagues accounts... No, it is none of those companies. As indicated, if you are interested, send private e-mail to me, I'm more than happy to put you in touch with them. Regards, -- - 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 Wed Sep 23 23:58:56 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Thu, 24 Sep 2009 01:58:56 +0200 Subject: [patch 1/4] gsm_04_11: Free transaction on RX_RP_ACK for SMS Message-ID: <866320f70909231658p3b9ec3f1nbc5735276a0b8c77@mail.gmail.com> commit 90e04861aa587d192025dd42aff5501e3742672a Author: Sylvain Munaut Date: Thu Sep 24 01:32:41 2009 +0200 [gsm_04_11] Free transaction on RX_RP_ACK for SMS When only one SMS is sent, the freeing of the lchan will automatically free all transactions on the lchan. However, if there are several SMS sent at once, the call to gsm411_send_sms_lchan will create a new transaction with the same caracteristics as the previous one. If the old one is not free'd, the next call to trans_find_by_id (triggered by the next incoming RP-ACK) will not return the good transaction and things go haywire. Signed-off-by: Sylvain Munaut openbsc/src/gsm_04_11.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-gsm_04_11-Free-transaction-on-RX_RP_ACK-for-SMS.patch Type: application/octet-stream Size: 1331 bytes Desc: not available URL: From laforge at gnumonks.org Sun Sep 27 09:18:42 2009 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 27 Sep 2009 11:18:42 +0200 Subject: Patches from Sylvain In-Reply-To: <866320f70909231658p3b9ec3f1nbc5735276a0b8c77@mail.gmail.com> References: <866320f70909231658p3b9ec3f1nbc5735276a0b8c77@mail.gmail.com> Message-ID: <20090927091842.GE15157@prithivi.gnumonks.org> Thanks, Sylvain, I have merged all of your patches, and I have also decided to merge the encryption branch into the master branch. The encryption function will simply be 'dead code' and not used until it is fully completed... Regards, -- - 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 Sep 28 05:24:41 2009 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 28 Sep 2009 07:24:41 +0200 Subject: Patches from Sylvain In-Reply-To: <866320f70909231658p3b9ec3f1nbc5735276a0b8c77@mail.gmail.com> References: <866320f70909231658p3b9ec3f1nbc5735276a0b8c77@mail.gmail.com> Message-ID: <20090928052441.GF4416@prithivi.gnumonks.org> Thanks, Sylvain, I have merged all of your patches, and I have also decided to merge the encryption branch into the master branch. The encryption function will simply be 'dead code' and not used until it is fully completed... Regards, -- - 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 Thu Sep 24 00:00:22 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Thu, 24 Sep 2009 02:00:22 +0200 Subject: [patch 2/4] gsm_04_08: Fix gsm48_tx_mm_auth_req implementation Message-ID: <866320f70909231700l1f7b307at3536df2b76fce894@mail.gmail.com> commit ed85ac5d09fa892996a06170422430274e050124 Author: Sylvain Munaut Date: Thu Sep 24 01:40:55 2009 +0200 [gsm_04_08] Fix gsm48_tx_mm_auth_req implementation It was mainly missing the key_seq field, causing the command to just be rejected by the ME. Signed-off-by: Sylvain Munaut openbsc/include/openbsc/gsm_04_08.h | 7 +++++++ openbsc/src/gsm_04_08.c | 8 +++++--- 2 files changed, 12 insertions(+), 3 deletions(-) -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-gsm_04_08-Fix-gsm48_tx_mm_auth_req-implementation.patch Type: application/octet-stream Size: 1923 bytes Desc: not available URL: From 246tnt at gmail.com Thu Sep 24 00:01:23 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Thu, 24 Sep 2009 02:01:23 +0200 Subject: [patch 3/4] gsm_04_08: Fix gsm48_send_rr_ciph_mode algorithm ID Message-ID: <866320f70909231701h401da697t66f585a68bcd9cb9@mail.gmail.com> commit 7aa86ed1e8669bcd06970ba23a1ff5abd5da81e6 Author: Sylvain Munaut Date: Thu Sep 24 01:44:24 2009 +0200 [gsm_04_08] Fix gsm48_send_rr_ciph_mode algorithm ID The algorithm ID used in the GSM 04.08 RR message is (x-1) for A5/x. In RSL it's (x+1) for A5/x so there is a difference of 2. Signed-off-by: Sylvain Munaut openbsc/src/gsm_04_08.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-gsm_04_08-Fix-gsm48_send_rr_ciph_mode-algorithm-ID.patch Type: application/octet-stream Size: 997 bytes Desc: not available URL: From 246tnt at gmail.com Thu Sep 24 00:02:12 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Thu, 24 Sep 2009 02:02:12 +0200 Subject: [patch 4/4] abis_rsl: Fix rsl_encryption_cmd L3 length computation Message-ID: <866320f70909231702p4cfe85d4hc4b6f016a7ee9448@mail.gmail.com> commit c582a730570f96ea294d53f5261b6f4df35f256c Author: Sylvain Munaut Date: Thu Sep 24 01:54:40 2009 +0200 [abis_rsl] Fix rsl_encryption_cmd L3 length computation msg->l3h doesn't have any coherent value at that point, can't use that. Signed-off-by: Sylvain Munaut openbsc/src/abis_rsl.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) From 246tnt at gmail.com Thu Sep 24 00:13:45 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Thu, 24 Sep 2009 02:13:45 +0200 Subject: Quick & Dirty test of the ciphering functions Message-ID: <866320f70909231713o3cbe4a59m6b559799f19f4222@mail.gmail.com> Hi everyone, This evening I spent a few hours hacking a small test to activate ciphering and I tought people might be interested with tinkering with it. If you want to try for yourself, start off from the encryption branch of Harald, then apply the 4 patches I just posted to this list then apply the quick hack attached to this message. This patch is not for merge since it's a gross hack just 'to see if it works', and it does ! ( See the log in attachment ) What this patch does is pretty simple: - When there is a location update, it does a AUTHENTICATION REQUEST with a static RAND. - When the AUTHENTICATION RESPONSE is received, it compares the result with the 'known expected' results (see the wiki for AT commands to get SRES and Kc for a given RAND) - When sending a SMS to the MS, it activates the ciphering after receiving the paging response with the 'known precomputed' Kc. If everything goes well, the ME sends back a CIPHER MODE COMPLETE and the rest of the talk is ciphered. The included patch uses A5/2 but can be trivially modified for A5/1. I just wanted to see if the iPhone would accept A5/2 and it doesn't (works with A5/1 tough) ! My old Ericsson T610 takes A5/2 and A5/1. Of course, this is no where near a good implementation but at least it provides proof that the lower level functions works. I'm not sure what's the best solution to get SRES and Kc. Most of the time getting the Ki is not an option, so either we have a fixed RAND, or a bunch RAND and corresponding SRES and Kc ... Or a side channel to run the algo on the phone itself ... Sylvain -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-HACK-TO-TEST-CIPHERED-SMS-DELIVERY-IN-A5-2.patch Type: application/octet-stream Size: 3291 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cipher.log Type: application/octet-stream Size: 7353 bytes Desc: not available URL: From spaar at mirider.augusta.de Thu Sep 24 17:29:27 2009 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Thu, 24 Sep 2009 17:29:27 CEST Subject: Quick & Dirty test of the ciphering functions Message-ID: <4abbac77.mirider@mirider.augusta.de> Hello Sylvain, On Thu, 24 Sep 2009 02:13:45 +0200, "Sylvain Munaut" <246tnt at gmail.com> wrote: > > This evening I spent a few hours hacking a small test to activate > ciphering and I tought people might be interested with tinkering with > it. If you want to try for yourself, start off from the encryption > branch of Harald, then apply the 4 patches I just posted to this list > then apply the quick hack attached to this message. Great that you provide the patches, I did a proof a concept implementation a while ago (http://lists.gnumonks.org/pipermail/openbsc/2009-July/000584.html). However I never found the time to actually complete it, so now I don't have to care any more :-) Best regards, Dieter -- Dieter Spaar, Germany spaar at mirider.augusta.de From laforge at gnumonks.org Sun Sep 27 09:26:15 2009 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 27 Sep 2009 11:26:15 +0200 Subject: Quick & Dirty test of the ciphering functions In-Reply-To: <866320f70909231713o3cbe4a59m6b559799f19f4222@mail.gmail.com> References: <866320f70909231713o3cbe4a59m6b559799f19f4222@mail.gmail.com> Message-ID: <20090927092615.GG15157@prithivi.gnumonks.org> On Thu, Sep 24, 2009 at 02:13:45AM +0200, Sylvain Munaut wrote: > This patch is not for merge since it's a gross hack just 'to see if it > works', and it does ! ( See the log in attachment ) sure, but it's good to know the infrastructure in OpenBSC works... > The included patch uses A5/2 but can be trivially modified for A5/1. I > just wanted to see if the iPhone would accept A5/2 and it doesn't > (works with A5/1 tough) ! My old Ericsson T610 takes A5/2 and A5/1. The iPhone should then also indicate the lack of A5/2 support in the classmark values... > I'm not sure what's the best solution to get SRES and Kc. Most of the time > getting the Ki is not an option, so either we have a fixed RAND, or a bunch > RAND and corresponding SRES and Kc ... Or a side channel to run the algo on > the phone itself ... Well, I presume if you want OpenBSC with encryption support, then you will probably either 1) connect to a real-world MSC (with holgers new MSC/BSC split) and HLR This is the case where you actually want to deploy a network that interoperates with a public network. Don't be surprised, some companies are considering this, and work is being doe in this direction. 2) issue your own SIM cards, where you know the Ki. This is likely the case when you operate a small private network. In this case we would simply store the Ki in our SQL tables. The latter case is what we can test relatively easy by using the '16in1' SIM cards as Dieter has indicated some time ago. I've bought a couple of those, but am too busy right now. Anyone interested to complete our crpyto implementation can also easily get them for very little money. Regards, -- - 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 Sep 28 05:24:47 2009 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 28 Sep 2009 07:24:47 +0200 Subject: Quick & Dirty test of the ciphering functions In-Reply-To: <866320f70909231713o3cbe4a59m6b559799f19f4222@mail.gmail.com> References: <866320f70909231713o3cbe4a59m6b559799f19f4222@mail.gmail.com> Message-ID: <20090928052447.GH4416@prithivi.gnumonks.org> On Thu, Sep 24, 2009 at 02:13:45AM +0200, Sylvain Munaut wrote: > This patch is not for merge since it's a gross hack just 'to see if it > works', and it does ! ( See the log in attachment ) sure, but it's good to know the infrastructure in OpenBSC works... > The included patch uses A5/2 but can be trivially modified for A5/1. I > just wanted to see if the iPhone would accept A5/2 and it doesn't > (works with A5/1 tough) ! My old Ericsson T610 takes A5/2 and A5/1. The iPhone should then also indicate the lack of A5/2 support in the classmark values... > I'm not sure what's the best solution to get SRES and Kc. Most of the time > getting the Ki is not an option, so either we have a fixed RAND, or a bunch > RAND and corresponding SRES and Kc ... Or a side channel to run the algo on > the phone itself ... Well, I presume if you want OpenBSC with encryption support, then you will probably either 1) connect to a real-world MSC (with holgers new MSC/BSC split) and HLR This is the case where you actually want to deploy a network that interoperates with a public network. Don't be surprised, some companies are considering this, and work is being doe in this direction. 2) issue your own SIM cards, where you know the Ki. This is likely the case when you operate a small private network. In this case we would simply store the Ki in our SQL tables. The latter case is what we can test relatively easy by using the '16in1' SIM cards as Dieter has indicated some time ago. I've bought a couple of those, but am too busy right now. Anyone interested to complete our crpyto implementation can also easily get them for very little money. Regards, -- - 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 Thu Sep 24 00:23:45 2009 From: 246tnt at gmail.com (246tnt at gmail.com) Date: Thu, 24 Sep 2009 00:23:45 +0000 Subject: patch serie: download URL Message-ID: <0016e6dab15031c5e8047447d886@google.com> Damn, gmail sucks for posting patches, sorry about that ... Here's an url to download them: http://www.246tnt.com/files/openbsc/20090924/ Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Sun Sep 27 09:19:39 2009 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 27 Sep 2009 11:19:39 +0200 Subject: patch serie: download URL In-Reply-To: <0016e6dab15031c5e8047447d886@google.com> References: <0016e6dab15031c5e8047447d886@google.com> Message-ID: <20090927091939.GF15157@prithivi.gnumonks.org> On Thu, Sep 24, 2009 at 12:23:45AM +0000, 246tnt at gmail.com wrote: > Damn, gmail sucks for posting patches, sorry about that ... I suppose it is worth setting up an SMTP server somewhere that you can use, then do "git format-patch" and "git send-email" -- - 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 Sep 28 05:24:44 2009 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 28 Sep 2009 07:24:44 +0200 Subject: patch serie: download URL In-Reply-To: <0016e6dab15031c5e8047447d886@google.com> References: <0016e6dab15031c5e8047447d886@google.com> Message-ID: <20090928052444.GG4416@prithivi.gnumonks.org> On Thu, Sep 24, 2009 at 12:23:45AM +0000, 246tnt at gmail.com wrote: > Damn, gmail sucks for posting patches, sorry about that ... I suppose it is worth setting up an SMTP server somewhere that you can use, then do "git format-patch" and "git send-email" -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From datacop at wireloss.net Sat Sep 26 00:46:51 2009 From: datacop at wireloss.net (Clemens Hopfer) Date: Sat, 26 Sep 2009 02:46:51 +0200 Subject: junghanns.net singleE1 MiniPCI support Message-ID: <200909260246.51321.datacop@wireloss.net> Hi, has anyone tried running OpenBSC with the junghanns.net singleE1 MiniPCI card? It has got the CologneChip HFC-E1 controller and seems to be supported by mISDN. Target system would be an alix3d3. cu, Clemens From laforge at gnumonks.org Sun Sep 27 08:18:29 2009 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 27 Sep 2009 10:18:29 +0200 Subject: junghanns.net singleE1 MiniPCI support In-Reply-To: <200909260246.51321.datacop@wireloss.net> References: <200909260246.51321.datacop@wireloss.net> Message-ID: <20090927081829.GD15157@prithivi.gnumonks.org> On Sat, Sep 26, 2009 at 02:46:51AM +0200, Clemens Hopfer wrote: > Hi, > > has anyone tried running OpenBSC with the junghanns.net singleE1 MiniPCI card? > > It has got the CologneChip HFC-E1 controller and seems to be supported by > mISDN. Target system would be an alix3d3. I have not tried it, but miniPCI or PCI is just a form factor / mechanical an possibly electrical difference. To the OS / driver it does not make a difference. So I am 99.9% sure it will work. Regards, -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From jens.david at jens-david-consulting.com Mon Sep 28 19:06:59 2009 From: jens.david at jens-david-consulting.com (Jens David) Date: Mon, 28 Sep 2009 21:06:59 +0200 Subject: junghanns.net singleE1 MiniPCI support In-Reply-To: <20090927081829.GD15157@prithivi.gnumonks.org> References: <200909260246.51321.datacop@wireloss.net> <20090927081829.GD15157@prithivi.gnumonks.org> Message-ID: <796BDF92-3481-489F-B8F5-D9F438ECB81D@jens-david-consulting.com> I thought that once, too. Theoretically it is, but in practice you find all sorts of buggy bridges in between system bus and cardbus slot in certain notebook models. Lots of experience and/or long logic analyzer sessions are needed to design a bulletproof programming model, especially when descriptor oriented busmaster-DMA schemes are used. Possibly the CCD guys did not spend so much time because their card is not a consumer product anyway. I would suggest trying a different notebook if everything else fails. --j Am 27.09.2009 um 10:18 schrieb Harald Welte: > On Sat, Sep 26, 2009 at 02:46:51AM +0200, Clemens Hopfer wrote: >> Hi, >> >> has anyone tried running OpenBSC with the junghanns.net singleE1 >> MiniPCI card? >> >> It has got the CologneChip HFC-E1 controller and seems to be >> supported by >> mISDN. Target system would be an alix3d3. > > I have not tried it, but miniPCI or PCI is just a form factor / > mechanical an > possibly electrical difference. To the OS / driver it does not make a > difference. So I am 99.9% sure it will work. > > Regards, > -- > - Harald Welte http://laforge.gnumonks.org/ > = > = > = > = > = > = > ====================================================================== > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 > Ch. A6) > -- Jens David, DG1KJD jens.david at jens-david-consulting.com http://www.jens-david-consulting.com From laforge at gnumonks.org Mon Sep 28 05:24:38 2009 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 28 Sep 2009 07:24:38 +0200 Subject: junghanns.net singleE1 MiniPCI support In-Reply-To: <200909260246.51321.datacop@wireloss.net> References: <200909260246.51321.datacop@wireloss.net> Message-ID: <20090928052438.GE4416@prithivi.gnumonks.org> On Sat, Sep 26, 2009 at 02:46:51AM +0200, Clemens Hopfer wrote: > Hi, > > has anyone tried running OpenBSC with the junghanns.net singleE1 MiniPCI card? > > It has got the CologneChip HFC-E1 controller and seems to be supported by > mISDN. Target system would be an alix3d3. I have not tried it, but miniPCI or PCI is just a form factor / mechanical an possibly electrical difference. To the OS / driver it does not make a difference. So I am 99.9% sure it will work. Regards, -- - 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 Sun Sep 27 17:35:05 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 27 Sep 2009 19:35:05 +0200 Subject: OpenBSC, nanoBTS and Asterisk integration Message-ID: <866320f70909271035l5d32b571j70543f1504fc0cb@mail.gmail.com> Hi, This week end I started coding a channel driver to integrate OpenBSC and Asterisk directly. You can find the code here http://github.com/smunaut/ast_chan_openbsc The current public version is what I coded this Saturday, it doesn't do much, only registers itself as a channel driver and runs the openBSC core within asterisk. It will work only for the ip.access at first (at least) because I'm directly bridging the RTP audio from the nanoBTS to the RTP subsystem of Asterisk. I spent a good part of today hacking together enough code to make a call and it worked, I got bidirectional audio. This latest code is not public yet because it's just a big mess and only take care of setup and not cleanup (so you can do 1 call and then restart :) With this hack, I just wanted to confirm that it could work without too much problem. I will try to clean it up ASAP and publish it so that there is a minimal functionality testable :) OTOH, my time is limited and I split it between OpenBSC, OpenBTS and airprobe so some weeks may be slow. Sylvain From laforge at gnumonks.org Mon Sep 28 05:34:07 2009 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 28 Sep 2009 07:34:07 +0200 Subject: OpenBSC, nanoBTS and Asterisk integration In-Reply-To: <866320f70909271035l5d32b571j70543f1504fc0cb@mail.gmail.com> References: <866320f70909271035l5d32b571j70543f1504fc0cb@mail.gmail.com> Message-ID: <20090928053407.GK4416@prithivi.gnumonks.org> Hi Sylvain, On Sun, Sep 27, 2009 at 07:35:05PM +0200, Sylvain Munaut wrote: > This week end I started coding a channel driver to integrate OpenBSC > and Asterisk directly. > You can find the code here http://github.com/smunaut/ast_chan_openbsc thanks, this is exciting news. Please keep us posted. If yo think it is worth putting this in the OpenBSC git, or at least hosting it on openbsc.gnumonks.org, I'm very open to that. Or are you planning to actually submit this into asterisk mainline, then of course any repo you use now is meant to be only temporary. > This latest code is not public yet because it's just a big mess and > only take care of setup and not cleanup (so you can do 1 call and then > restart :) that's not enough reason to not have it in a separate branch in your git repo, one that you delete as soon as you have merged a cleaned-up version to the master branch :) > OTOH, my time is limited and I split it between OpenBSC, OpenBTS and > airprobe so some weeks may be slow. sure, don't worry. We all know that feeling... -- - 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 Tue Sep 29 08:36:44 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Tue, 29 Sep 2009 10:36:44 +0200 Subject: OpenBSC, nanoBTS and Asterisk integration In-Reply-To: <20090928053407.GK4416@prithivi.gnumonks.org> References: <866320f70909271035l5d32b571j70543f1504fc0cb@mail.gmail.com> <20090928053407.GK4416@prithivi.gnumonks.org> Message-ID: <866320f70909290136w6781f66l8474ef7a142617ff@mail.gmail.com> >> This week end I started coding a channel driver to integrate OpenBSC >> and Asterisk directly. >> You can find the code here http://github.com/smunaut/ast_chan_openbsc > > thanks, this is exciting news. ?Please keep us posted. Ok, I cleaned most of the mess yesterday and updated the tree. The branch 'master' contains eveything that's cleaned up. I also added a 'hack_call' branch that has minimum call control to be able to make mobile-terminated call. Only the 'normal calls' work ( dial -> ring mobile -> answer mobile -> hangup on mobile). Any deviation will most likely result in a crash :) But it's usable and all instructions are in the README for people to test. It's a pity that there are no free EFR/AMR codec implementation, I have to use plain old GSM-FR. > If yo think it is worth putting this in the OpenBSC git, or at least hosting it on > openbsc.gnumonks.org, I'm very open to that. Yes, I've put it on git hub because it was easy to setup and didn't want to bother setting it up on one of my servers. It might be good to host it on openbsc.gnumonks.org to keep everything grouped. I would keep it in a separate git tree tough. > Or are you planning to actually submit this into asterisk mainline, then > of course any repo you use now is meant to be only temporary. Yes, I'll consider submitting it once it and openBSC are stable enough to have 'numbered' releases. OTOH, there might be kindof a mess with licences. IIRC, a few years back it was required to release copyright to digium (so that then can do supported binary distributions with additional features to their clients) and that also imply no link (static or otherwise) to GPL code. So that may take some time :) >> This latest code is not public yet because it's just a big mess and >> only take care of setup and not cleanup (so you can do 1 call and then >> restart :) > > that's not enough reason to not have it in a separate branch in your git > repo, one that you delete as soon as you have merged a cleaned-up version > to the master branch :) The version I had two days ago was a little too hackish, with things like my own IP and RTP port hardcoded at several places and stuff :) Sylvain From laforge at gnumonks.org Tue Sep 29 09:52:20 2009 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 29 Sep 2009 11:52:20 +0200 Subject: OpenBSC, nanoBTS and Asterisk integration In-Reply-To: <866320f70909290136w6781f66l8474ef7a142617ff@mail.gmail.com> References: <866320f70909271035l5d32b571j70543f1504fc0cb@mail.gmail.com> <20090928053407.GK4416@prithivi.gnumonks.org> <866320f70909290136w6781f66l8474ef7a142617ff@mail.gmail.com> Message-ID: <20090929095220.GO6561@prithivi.gnumonks.org> Hi Sylvain, On Tue, Sep 29, 2009 at 10:36:44AM +0200, Sylvain Munaut wrote: > It's a pity that there are no free EFR/AMR codec implementation, I > have to use plain old GSM-FR. what do you mean by 'free' ? patent-free: no, certainly not. but free as in 'souce code available': sure, there are! AMR-NB and AMR-WB: http://www.penguin.cz/~utx/amr I thought I had also found an EFR library some time in the past, though I cannot find it right now. > > If yo think it is worth putting this in the OpenBSC git, or at least > > hosting it on openbsc.gnumonks.org, I'm very open to that. > > Yes, I've put it on git hub because it was easy to setup and didn't want to > bother setting it up on one of my servers. It might be good to host it on > openbsc.gnumonks.org to keep everything grouped. I would keep it in a > separate git tree tough. ok, if you send me your SSH public key, I'll create a repository for you. > > Or are you planning to actually submit this into asterisk mainline, then > > of course any repo you use now is meant to be only temporary. > > Yes, I'll consider submitting it once it and openBSC are stable enough > to have 'numbered' releases. > OTOH, there might be kindof a mess with licences. IIRC, a few years > back it was required to release copyright to digium (so that then can > do supported binary distributions with additional features to their > clients) and that also imply no link (static or otherwise) to GPL > code. Ok, I see. Let's investigate this further down the road. As I indicated before, I really don't like the 'daemon in library' approach that we're using right now, where the entire OpenBSC 'daemon' runs inside a library that is linked to some other executable. I suppose at some point we actually want to offer some kind of IPC based API for external programs, where OpenBSC runs in one process and the other application in another. Once that happens, I might consider licensing the library on the other side of the IPC under a different license. > The version I had two days ago was a little too hackish, with things like > my own IP and RTP port hardcoded at several places and stuff :) don't worry about that too much, can be cleaned up gradually... that's why we call it bsc_hack ;) -- - 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 Tue Sep 29 19:21:41 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Tue, 29 Sep 2009 21:21:41 +0200 Subject: OpenBSC, nanoBTS and Asterisk integration In-Reply-To: <20090929095220.GO6561@prithivi.gnumonks.org> References: <866320f70909271035l5d32b571j70543f1504fc0cb@mail.gmail.com> <20090928053407.GK4416@prithivi.gnumonks.org> <866320f70909290136w6781f66l8474ef7a142617ff@mail.gmail.com> <20090929095220.GO6561@prithivi.gnumonks.org> Message-ID: <866320f70909291221jbf4fde9o7b1bf495490676aa@mail.gmail.com> >> It's a pity that there are no free EFR/AMR codec implementation, I >> have to use plain old GSM-FR. > > what do you mean by 'free' ? ?patent-free: no, certainly not. ?but free as in > 'souce code available': sure, there are! Yes, there is the openmoko & android (using opencore) too. But I meant 'free' as in I can use/distribute it without having to worry :) Here I'm not sure it would be accepted to be merged into asterisk ... > As I indicated > before, I really don't like the 'daemon in library' approach that we're using > right now, where the entire OpenBSC 'daemon' runs inside a library that is > linked to some other executable. > > I suppose at some point we actually want to offer some kind of IPC based API > for external programs, where OpenBSC runs in one process and the other > application in another. ?Once that happens, I might consider licensing the > library on the other side of the IPC under a different license. Yes, having the core running in there is not the most elegant solution :) But since all the interaction is done via the MNCC interface, it's probably very easy to just export that as a socket. Just need to clean up a little the message format (with like type & length field always set properly and such) and then only the mncc.h header would be used by external apps ... Sylvain From laforge at gnumonks.org Wed Sep 30 05:23:39 2009 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 30 Sep 2009 07:23:39 +0200 Subject: OpenBSC, nanoBTS and Asterisk integration In-Reply-To: <866320f70909291221jbf4fde9o7b1bf495490676aa@mail.gmail.com> References: <866320f70909271035l5d32b571j70543f1504fc0cb@mail.gmail.com> <20090928053407.GK4416@prithivi.gnumonks.org> <866320f70909290136w6781f66l8474ef7a142617ff@mail.gmail.com> <20090929095220.GO6561@prithivi.gnumonks.org> <866320f70909291221jbf4fde9o7b1bf495490676aa@mail.gmail.com> Message-ID: <20090930052339.GA3921@prithivi.gnumonks.org> On Tue, Sep 29, 2009 at 09:21:41PM +0200, Sylvain Munaut wrote: > >> It's a pity that there are no free EFR/AMR codec implementation, I > >> have to use plain old GSM-FR. > > > > what do you mean by 'free' ? ?patent-free: no, certainly not. ?but free as in > > 'souce code available': sure, there are! > > But I meant 'free' as in I can use/distribute it without having to worry :) well, if you think that way then you probably should not ever distribute OpenBSC, as it probably implements dozens of things that are covered by GSM related patents. This is why we are working on an experimental implementation for research purpose. As soon as you use that in a commercial context, you will have to ensure that you have licensed the apropriate patents (GSM Essential IP) from Siemens and others. > Yes, having the core running in there is not the most elegant solution :) But > since all the interaction is done via the MNCC interface, it's probably very > easy to just export that as a socket. Just need to clean up a little the > message format (with like type & length field always set properly and such) > and then only the mncc.h header would be used by external apps ... yes, though in this case Andreas Eversberg would have to decide on the licensing of that. Also, MNCC does not cover everything we might want to expose to applications, but it is a start. -- - 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 Wed Sep 30 02:12:36 2009 From: zecke at selfish.org (Holger Freyther) Date: Wed, 30 Sep 2009 04:12:36 +0200 Subject: [RFC] Changes to the lchan and BSC/MSC split Message-ID: <200909300412.37237.zecke@selfish.org> Hey guys, back in January I added ref-counting to the lchan and it has worked to some degree, and we have seen ref-leaks as well (fixed thanks to Andreas). Currently I'm working on integrating OpenBSC into a real MSC at on-waves.com and this has made me read the GSM08.08 specification a bit more. I would like to implement the following. - Remove the refcount from lchan - Replace it with the "transaction" concept. On certain 04.08 messgaes (e.g. paging response, various MM messages) open a transaction from BSC to MSC code. The channel is bound to the transaction. The lchan is getting released when the transaction is finished, in case of the "RSL chan" is going away too early there will be a "clear" signal/method called from the BSC and the MSC side is asked to let it go. The benefit of this: - BSC and MSC are better separated - My MSC code could wrap the transaction into a SCCP connection - Channel leak == transaction_free not getting called. regards holger From 246tnt at gmail.com Wed Sep 30 12:08:16 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 30 Sep 2009 14:08:16 +0200 Subject: [RFC] Changes to the lchan and BSC/MSC split In-Reply-To: <200909300412.37237.zecke@selfish.org> References: <200909300412.37237.zecke@selfish.org> Message-ID: <866320f70909300508u58105360q2e1931331b636d57@mail.gmail.com> Hi, On Wed, Sep 30, 2009 at 4:12 AM, Holger Freyther wrote: > I would like to implement the following. > ? ? ? ?- Remove the refcount from lchan > ? ? ? ?- Replace it with the "transaction" concept. On certain 04.08 messgaes > ? ? ? ? ?(e.g. paging response, various MM messages) open a transaction > ? ? ? ? ?from BSC to MSC code. The channel is bound to the transaction. Are you talking about the transaction in transaction.c ? Because for SMS for examples, we re-use the same lchan for consecutive transactions when delivering multiple SMS back to back and your approach would make that impossible if I understand correctly ? > ? ? ? ? The lchan is getting released when the transaction is finished, in > ? ? ? ? case of the "RSL chan" is going away too early there will be a > ? ? ? ? "clear" signal/method called from the BSC and the MSC side is asked > ? ? ? ? to let it go. From zecke at selfish.org Wed Sep 30 13:24:00 2009 From: zecke at selfish.org (Holger Freyther) Date: Wed, 30 Sep 2009 15:24:00 +0200 Subject: [RFC] Changes to the lchan and BSC/MSC split In-Reply-To: <866320f70909300508u58105360q2e1931331b636d57@mail.gmail.com> References: <200909300412.37237.zecke@selfish.org> <866320f70909300508u58105360q2e1931331b636d57@mail.gmail.com> Message-ID: <200909301524.00883.zecke@selfish.org> On Wednesday 30 September 2009 14:08:16 Sylvain Munaut wrote: > Hi, > > On Wed, Sep 30, 2009 at 4:12 AM, Holger Freyther wrote: > > I would like to implement the following. > > - Remove the refcount from lchan > > - Replace it with the "transaction" concept. On certain 04.08 > > messgaes (e.g. paging response, various MM messages) open a transaction > > from BSC to MSC code. The channel is bound to the transaction. > > Are you talking about the transaction in transaction.c ? Partially yes. I'm talking about GSM08.08 "? 3.2.1.32 COMPLETE LAYER 3 INFORMATION". In which the MSC is getting informed that it is in charge now (only the MSC is closing the SCCP connection...) > > Because for SMS for examples, we re-use the same lchan for consecutive > transactions when delivering multiple SMS back to back and your > approach would make that impossible if I understand correctly ? Well, it is up to the MSC to decide when to close the "transaction"/SCCP connection. So if the MSC policy is to send multiple SMS it will still work. The general change is that the MSC is completely controlling the lchan lifetime. If the radio resource is freed, but the MSC still occupies the channel it will not be reused. holger From laforge at gnumonks.org Wed Sep 30 17:25:13 2009 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 30 Sep 2009 19:25:13 +0200 Subject: [RFC] Changes to the lchan and BSC/MSC split In-Reply-To: <200909300412.37237.zecke@selfish.org> References: <200909300412.37237.zecke@selfish.org> Message-ID: <20090930172513.GD31723@prithivi.gnumonks.org> Hi Zecke, On Wed, Sep 30, 2009 at 04:12:36AM +0200, Holger Freyther wrote: > I would like to implement the following. > - Remove the refcount from lchan > - Replace it with the "transaction" concept. On certain 04.08 messgaes > (e.g. paging response, various MM messages) open a transaction > from BSC to MSC code. The channel is bound to the transaction. yes, this makes a lot of sense, of course. > The lchan is getting released when the transaction is finished, in > case of the "RSL chan" is going away too early there will be a > "clear" signal/method called from the BSC and the MSC side is asked > to let it go. well, what we need to somehow ensure is a situation where multiple transactions are pending / ongoing for one MS, i.e. a call is already established (or in the process of being established), while another call is to be signalled, or while SMS are to be delivered, etc. How would this fit into your new concept? > The benefit of this: > - BSC and MSC are better separated > - My MSC code could wrap the transaction into a SCCP connection > - Channel leak == transaction_free not getting called. There is one additional benefit: faster clearing of channels. Right now, we still keep the lchan open for a very long time even after e.g. location update or MT SMS have completed. In a real network, those timeouts are at least a factor of 10 faster. This also means that we're more susceptible to DoS until we have quicker closing of lchans. Regards, -- - 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 Wed Sep 30 11:23:10 2009 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 30 Sep 2009 13:23:10 +0200 Subject: LAC 0 / paging to all BTS Message-ID: <20090930112310.GC24634@prithivi.gnumonks.org> Hi Zecke, I've been reviewing some of your patches: > commit 45f9b3d3fc47074652be951eb74df2b0be2a230f > Author: Holger Hans Peter Freyther > Date: Fri Aug 21 05:30:19 2009 +0200 > > [paging] Use one of the two reserved LAC to page every BTS > > For the on-waves.com MSC case we want to page every BTS reached > of the network. Our gsm_subscriber entry does not have a LAC > entry set and defaults to zero. Use the reserved 0x0000 to > indicate that we want to use every bts in the network. > > This will influence the paging code to start and stop paging. The problem is that in the current code, we use LAC == 0 to indicate that the subscriber has sent an IMSI DETACH message, i.e. switched his phone off. You are now redefiniing the LAC 0 to something like the opposite case, which I don't particularly like. Is there some alternative solution? Regards, -- - 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 Wed Sep 30 11:37:42 2009 From: zecke at selfish.org (Holger Freyther) Date: Wed, 30 Sep 2009 13:37:42 +0200 Subject: LAC 0 / paging to all BTS In-Reply-To: <20090930112310.GC24634@prithivi.gnumonks.org> References: <20090930112310.GC24634@prithivi.gnumonks.org> Message-ID: <200909301337.42447.zecke@selfish.org> On Wednesday 30 September 2009 13:23:10 Harald Welte wrote: > Hi Zecke, > > I've been reviewing some of your patches: > > commit 45f9b3d3fc47074652be951eb74df2b0be2a230f > > Author: Holger Hans Peter Freyther > > Date: Fri Aug 21 05:30:19 2009 +0200 > > > > [paging] Use one of the two reserved LAC to page every BTS > > > > For the on-waves.com MSC case we want to page every BTS reached > > of the network. Our gsm_subscriber entry does not have a LAC > > entry set and defaults to zero. Use the reserved 0x0000 to > > indicate that we want to use every bts in the network. > > > > This will influence the paging code to start and stop paging. > > The problem is that in the current code, we use LAC == 0 to indicate that > the subscriber has sent an IMSI DETACH message, i.e. switched his phone > off. > > You are now redefiniing the LAC 0 to something like the opposite case, > which I don't particularly like. Is there some alternative solution? I didn't think about the IMSI DETACH case. One easy alternative is to use the other reserved lac value. With the least significant bit set 0 and all others to 1 (so 0xfffe... ETSI always makes me unsure about it). The other option is changing gst_bts_by_lac to specify to not filter by lac but just give the next one. what do you think? z. From laforge at gnumonks.org Wed Sep 30 12:49:21 2009 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 30 Sep 2009 14:49:21 +0200 Subject: LAC 0 / paging to all BTS In-Reply-To: <200909301337.42447.zecke@selfish.org> References: <20090930112310.GC24634@prithivi.gnumonks.org> <200909301337.42447.zecke@selfish.org> Message-ID: <20090930124921.GF27065@prithivi.gnumonks.org> Hi Zecke, On Wed, Sep 30, 2009 at 01:37:42PM +0200, Holger Freyther wrote: > On Wednesday 30 September 2009 13:23:10 Harald Welte wrote: > > > You are now redefiniing the LAC 0 to something like the opposite case, > > which I don't particularly like. Is there some alternative solution? > > I didn't think about the IMSI DETACH case. One easy alternative is to use the > other reserved lac value. With the least significant bit set 0 and all others > to 1 (so 0xfffe... ETSI always makes me unsure about it). I think LAC = 0xfffe seems to be the way to go for paging of all BTS, wile we keep LAC = 0 for the 'user is detached' case. Regards, -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From michael.haben at btinternet.com Wed Sep 30 19:44:16 2009 From: michael.haben at btinternet.com (Mike Haben) Date: Wed, 30 Sep 2009 20:44:16 +0100 Subject: Patch: parsing of Software Activate parameters Message-ID: <4AC3B510.7080300@btinternet.com> Hi all, Patch-file is attached - addresses a FIXME in abis_nm.c, parsing the parameters passed by a Software Activate request. I've tested this on three different IpAccess BTSs (including one which didn't work with the original code), would be good if someone could check it on a BS11. Best regards, Mike H. -------------- next part -------------- A non-text attachment was scrubbed... Name: sw_activate_parse.patch Type: text/x-diff Size: 2079 bytes Desc: not available URL: From 246tnt at gmail.com Wed Sep 30 20:35:04 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 30 Sep 2009 22:35:04 +0200 Subject: [PATCH] input/ipaccess: Fix segv caused by use of uninitialized var Message-ID: <1254342904-15695-1-git-send-email-246tnt@gmail.com> From: Sylvain Munaut This is a regression coming from the recent split of the handle_ts1_read method in two. Signed-off-by: Sylvain Munaut --- openbsc/src/input/ipaccess.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/openbsc/src/input/ipaccess.c b/openbsc/src/input/ipaccess.c index 8a22810..40891ae 100644 --- a/openbsc/src/input/ipaccess.c +++ b/openbsc/src/input/ipaccess.c @@ -319,7 +319,7 @@ static int handle_ts1_read(struct bsc_fd *bfd) return error; } - DEBUGP(DMI, "RX %u: %s\n", ts_nr, hexdump(msgb_l2(msg), ret)); + DEBUGP(DMI, "RX %u: %s\n", ts_nr, hexdump(msgb_l2(msg), msgb_l2len(msg))); hh = (struct ipaccess_head *) msg->data; if (hh->proto == IPAC_PROTO_IPACCESS) { -- 1.6.4