From zecke at selfish.org Mon Nov 9 03:20:09 2009 From: zecke at selfish.org (Holger Freyther) Date: Mon, 9 Nov 2009 04:20:09 +0100 Subject: RFC: Establishing logging standards In-Reply-To: <20091007145647.GO25086@prithivi.gnumonks.org> References: <200910071038.05122.zecke@selfish.org> <20091007145647.GO25086@prithivi.gnumonks.org> Message-ID: <200911090420.10095.zecke@selfish.org> Hey LaForge, in one way this is a continuation of the thread but there is no real need to quote anything. I went to ulogd and had a look (and copied the levels), I looked at what we have and what would be neat and came up with a small interface right now[1]... The first thing is the introduction to have a log level. This will allow to set a global log level or one by subsystem... The next thing is the concept of a target. We can add multiple targets (stdout, syslog, file, telnet) and have them be active at the same time (think of a loop inside the debugp statement). We can have a log level per target... The next thing is a "context". On the receive message path we start with the phsyical connection to the BTS, then with MM or RSL, going to GSM04.08, and then more protocols. On this path we can add a "context". E.g. we received this message for this bts, it was this lchan, it was this subscriber... (and the same for the sending path) Having the context will allow to have filters. E.g. only show me RSL messages sent for the LCHAN assigned to SUBSCRIBER with the IMSI:XYZ. I foresee this useful when trying to debug things with the telnet interface in a real network. At this point I would appreciate API feedback to see if it is useful to continue this way or if another solution is better. regards z [1] In the holger/new-debug-arch branch From laforge at gnumonks.org Tue Nov 10 07:17:05 2009 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 10 Nov 2009 16:17:05 +0900 Subject: RFC: Establishing logging standards In-Reply-To: <200911090420.10095.zecke@selfish.org> References: <200910071038.05122.zecke@selfish.org> <20091007145647.GO25086@prithivi.gnumonks.org> <200911090420.10095.zecke@selfish.org> Message-ID: <20091110071705.GH4048@prithivi.gnumonks.org> Hi zecke, On Mon, Nov 09, 2009 at 04:20:09AM +0100, Holger Freyther wrote: > in one way this is a continuation of the thread but there is no real need to > quote anything. I went to ulogd and had a look (and copied the levels), I > looked at what we have and what would be neat and came up with a small > interface right now[1]... ok, I will look at it asap. > The first thing is the introduction to have a log level. This will > allow to set a global log level or one by subsystem... yes, that makes sense. > The next thing is the concept of a target. We can add multiple targets > (stdout, syslog, file, telnet) and have them be active at the same time (think > of a loop inside the debugp statement). We can have a log level per > target... also makes sense, of course. > The next thing is a "context". On the receive message path we start with > the phsyical connection to the BTS, then with MM or RSL, going to GSM04.08, > and then more protocols. On this path we can add a "context". E.g. we > received this message for this bts, it was this lchan, it was this > subscriber... (and the same for the sending path) agree here, too. > Having the context will allow to have filters. E.g. only show me RSL messages > sent for the LCHAN assigned to SUBSCRIBER with the IMSI:XYZ. I foresee this > useful when trying to debug things with the telnet interface in a real > network. yes, that makes even more sense. not sure to what level of complexity we need to go. It's probably sufficient if we can already set the context+loglevel, and then indicate a subscriber/imsi as filter. If anybody wants something more sophisticated, like all messages on one specific lchan/trx/bts/..., it's probably sufficient to simply ask him to write the filter function in c code and somehow easily hook that into the logging. I mean, in any case we always have wireshark, too. But what wireshark doesn't have at the moment is the context to trace all actions of one subscriber, e.g. So we should not try to over-engineer for every possible use case -- - 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 Nov 11 13:57:25 2009 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 11 Nov 2009 22:57:25 +0900 Subject: RFC: Establishing logging standards In-Reply-To: <20091110071705.GH4048@prithivi.gnumonks.org> References: <200910071038.05122.zecke@selfish.org> <20091007145647.GO25086@prithivi.gnumonks.org> <200911090420.10095.zecke@selfish.org> <20091110071705.GH4048@prithivi.gnumonks.org> Message-ID: <20091111135725.GB20087@prithivi.gnumonks.org> On Tue, Nov 10, 2009 at 04:17:05PM +0900, Harald Welte wrote: > > > in one way this is a continuation of the thread but there is no real need to > > quote anything. I went to ulogd and had a look (and copied the levels), I > > looked at what we have and what would be neat and came up with a small > > interface right now[1]... > > ok, I will look at it asap. I've now looked at it. I am not sure if we really need our own filter language, whoch would just add a lot of ugly string parsing/handling code and overall complexity. I mean, if you want to write that, do it :) But I think there are other more important things to take care of... Another topic is: How do you want to handle the log targets? I mean, there's only one logfile or one syslog target, sure. But what about the VTY's? We can have a number of VTY connections, and it may very well make sense to use one non-debug VTY for issuing commands (without scrolling debug messages) and a different VTY where you are mainly interested in seeing [scrolling] debug log. So every VTY would register its own debug target after the telnet connection is established? Otherwise everything looks fine to me. -- - 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 Nov 11 14:05:06 2009 From: zecke at selfish.org (Holger Freyther) Date: Wed, 11 Nov 2009 15:05:06 +0100 Subject: RFC: Establishing logging standards In-Reply-To: <20091111135725.GB20087@prithivi.gnumonks.org> References: <200910071038.05122.zecke@selfish.org> <20091110071705.GH4048@prithivi.gnumonks.org> <20091111135725.GB20087@prithivi.gnumonks.org> Message-ID: <200911111505.07378.zecke@selfish.org> On Wednesday 11 November 2009 14:57:25 Harald Welte wrote: > On Tue, Nov 10, 2009 at 04:17:05PM +0900, Harald Welte wrote: > > > in one way this is a continuation of the thread but there is no real > > > need to quote anything. I went to ulogd and had a look (and copied the > > > levels), I looked at what we have and what would be neat and came up > > > with a small interface right now[1]... > > > > ok, I will look at it asap. > > I've now looked at it. I am not sure if we really need our own filter > language, whoch would just add a lot of ugly string parsing/handling code > and overall complexity. I mean, if you want to write that, do it :) But > I think there are other more important things to take care of... I agree. I was thinking about the VTY case and we need to have a way to go from string to code (enabling/configuring the filter) and I didn't want to add a lot of VTY commands. Let me think about something easy here.. > > Another topic is: How do you want to handle the log targets? I mean, > there's only one logfile or one syslog target, sure. But what about the > VTY's? We can have a number of VTY connections, and it may very well make > sense to use one non-debug VTY for issuing commands (without scrolling > debug messages) and a different VTY where you are mainly interested in > seeing [scrolling] debug log. My idea was to add a "target" when the telnet connection is opened and remove it when it is closed and by default not output anything. > > So every VTY would register its own debug target after the telnet > connection is established? Yeah. > > Otherwise everything looks fine to me. I hope to have a first implementation to toy with soon. regards holger From roch at on-waves.com Wed Nov 11 14:10:54 2009 From: roch at on-waves.com (Roch) Date: Wed, 11 Nov 2009 14:10:54 +0000 Subject: RFC: Establishing logging standards In-Reply-To: <200911111505.07378.zecke@selfish.org> References: <200910071038.05122.zecke@selfish.org> <20091110071705.GH4048@prithivi.gnumonks.org> <20091111135725.GB20087@prithivi.gnumonks.org> <200911111505.07378.zecke@selfish.org> Message-ID: <4AFAC5EE.3060102@on-waves.com> Hi, I think it would be nice to have Cisco-like approach with term mon/term no mon commands in order to enable debug on one vty. Regards Roch. Holger Freyther wrote: > On Wednesday 11 November 2009 14:57:25 Harald Welte wrote: > >> On Tue, Nov 10, 2009 at 04:17:05PM +0900, Harald Welte wrote: >> >>>> in one way this is a continuation of the thread but there is no real >>>> need to quote anything. I went to ulogd and had a look (and copied the >>>> levels), I looked at what we have and what would be neat and came up >>>> with a small interface right now[1]... >>>> >>> ok, I will look at it asap. >>> >> I've now looked at it. I am not sure if we really need our own filter >> language, whoch would just add a lot of ugly string parsing/handling code >> and overall complexity. I mean, if you want to write that, do it :) But >> I think there are other more important things to take care of... >> > > I agree. I was thinking about the VTY case and we need to have a way to go > from string to code (enabling/configuring the filter) and I didn't want to add a > lot of VTY commands. Let me think about something easy here.. > > > > >> Another topic is: How do you want to handle the log targets? I mean, >> there's only one logfile or one syslog target, sure. But what about the >> VTY's? We can have a number of VTY connections, and it may very well make >> sense to use one non-debug VTY for issuing commands (without scrolling >> debug messages) and a different VTY where you are mainly interested in >> seeing [scrolling] debug log. >> > > My idea was to add a "target" when the telnet connection is opened and remove > it when it is closed and by default not output anything. > > > >> So every VTY would register its own debug target after the telnet >> connection is established? >> > > > Yeah. > > >> Otherwise everything looks fine to me. >> > > > I hope to have a first implementation to toy with soon. > > regards > holger > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From s4dd at losers.yore.ma Wed Nov 25 23:18:21 2009 From: s4dd at losers.yore.ma (s4dd at losers.yore.ma) Date: Wed, 25 Nov 2009 23:18:21 +0000 Subject: BS11 does not work, but everything looks normal. In-Reply-To: <4ACE0430.5070002@tent.at> References: <4ACCDC48.20505@gmx.de> <20091008080407.GI25086@prithivi.gnumonks.org> <19110841ed56fb28d6836911e86be9b8.squirrel@mailadmin.nerdsurf.de> <2B0E6B35-65E1-454D-9584-9C58285346B4@mail.ru> <4ACE0430.5070002@tent.at> Message-ID: <4B0DBB3D.1090004@losers.yore.ma> Gents, I too could do with a hint as to where I could locate the appropriate bs-11 firmware files. Any and all help appreciated. -Paul Kai M?nz wrote: > Actually I'm missing the firmware files. Could anyone give me a hint > where I can find them? > > Regards, > Kai > > Sergey V. Efimoff wrote: >> See http://openbsc.gnumonks.org/trac/wiki/bs11_config >> >> Though have not seen any audio problems on BS-11. >> >> On Oct 8, 2009, at 4:05 PM, Kai M?nz wrote: >> >>> How can i reflash the firmware of the BS-11? Mine sometimes "scrambles" >>> the audio signal which seems to be a software bug in my BS-11? >>> >>>> Hmm, in my case the solution consisted of 3 steps: >>>> >>>> 1. Full BS-11 firmware re-flash. >>>> 2. Accurate calibration of internal oscillator. >>>> 3. Update of mISDN stack to the latest version. > > From laforge at gnumonks.org Sun Nov 8 05:39:02 2009 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 8 Nov 2009 14:39:02 +0900 Subject: [PATCH] implemented GSM340_TP_VPF_ABSOLUTE In-Reply-To: <20091028160259.77c7e4b5@stefreak.de> References: <20091028160259.77c7e4b5@stefreak.de> Message-ID: <20091108053902.GY5881@prithivi.gnumonks.org> Dear Steffen, thanks for your patch, it is most welcome. Sorry for not providing feedback earlier. Please see my comments below: > - case GSM340_TP_VPF_ABSOLUTE: > + case GSM340_TP_VPF_ABSOLUTE: ; > /* Chapter 9.2.3.12.2 */ > - /* FIXME: like service center time stamp */ > - DEBUGP(DSMS, "VPI absolute not implemented yet\n"); > + time_t expires = gsm340_scts(sms_vp); > + time_t now = mktime(gmtime(NULL)); > + if (expires <= now) > + minutes = 0; > + else > + minutes = (expires-now)/60; please declare the variables (expires/now) at the beginning of the section, e.g. the case statement or even the top of the function. > +/* Turn semi-octet representation into int: 0x89 => 98 */ > +static u_int8_t unbcdify(u_int8_t value) > +{ > + u_int8_t ret; > + > + ret = (value&0x0F)*10; > + ret += value>>4; > + > + return ret; > +} we might want to have some kind of treatment (or at least an error message) if the input BCD nibbles exceed the 0...9 range. > static void gsm340_gen_scts(u_int8_t *scts, time_t time) > { > - struct tm *tm = localtime(&time); > + struct tm *tm = gmtime(&time); > > *scts++ = bcdify(tm->tm_year % 100); > *scts++ = bcdify(tm->tm_mon + 1); > @@ -338,7 +356,30 @@ static void gsm340_gen_scts(u_int8_t *scts, time_t time) > *scts++ = bcdify(tm->tm_hour); > *scts++ = bcdify(tm->tm_min); > *scts++ = bcdify(tm->tm_sec); > - *scts++ = 0; /* FIXME: timezone */ > + *scts++ = 0; /* FIXME: local timezone */ > +} mh. We are no wending GMT but no timezone information, which I'm not quite sure if it is better than we did before. A proper solution would be to use the signed value of tm->tm_gmtoff/(60*15); > +/* Decode 03.40 TP-SCTS (into utc/gmt timestamp) */ > +static time_t gsm340_scts(u_int8_t *scts) > +{ > + struct tm tm; > + > + u_int8_t yr = unbcdify(*scts++); > + printf("%i",yr); > + if (yr <= 60) > + tm.tm_year = 100 + yr; > + else > + tm.tm_year = yr; is this year '60' specified anywhere in the GSM spec, or did you just introduce it yourself? In the latter case, I would rather use something like 80, since GSM was not specified before the eighties. Thanks again, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From stefreak at stefreak.de Sun Nov 8 13:08:56 2009 From: stefreak at stefreak.de (Steffen 'stefreak' Neubauer) Date: Sun, 8 Nov 2009 14:08:56 +0100 Subject: [PATCH] implemented GSM340_TP_VPF_ABSOLUTE In-Reply-To: <20091108053902.GY5881@prithivi.gnumonks.org> References: <20091028160259.77c7e4b5@stefreak.de> <20091108053902.GY5881@prithivi.gnumonks.org> Message-ID: <20091108140856.30ea75b3@stefreak.de> Hello Harald, On Sun, 8 Nov 2009 14:39:02 +0900 Harald Welte wrote: > thanks for your patch, it is most welcome. Sorry for not providing > feedback earlier. Please see my comments below: no problem, thank you for your comment! :) > please declare the variables (expires/now) at the beginning of the > section, e.g. the case statement or even the top of the function. They were declared at the beginning of the case statement, aren't they? But now they are declared on top of the function. > we might want to have some kind of treatment (or at least an error > message) if the input BCD nibbles exceed the 0...9 range. Okay, now it sends a debug message. > mh. We are no wending GMT but no timezone information, which I'm not > quite sure if it is better than we did before. A proper solution > would be to use the signed value of tm->tm_gmtoff/(60*15); Before it sent the local time but with the timezone information "GMT/UTC" (offset=0). But now it sends the local timezone and the local timezone information. > is this year '60' specified anywhere in the GSM spec, or did you just > introduce it yourself? In the latter case, I would rather use > something like 80, since GSM was not specified before the eighties. No, the spec didn't specify this anywhere, even not in the newest version of the document. You're right, 80 is a better value. Fixed it ;) > Thanks again, > Harald I have to thank you! The new patch is attached :) Greetings, Steffen -------------- next part -------------- A non-text attachment was scrubbed... Name: patch.diff Type: text/x-patch Size: 2644 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From stefreak at stefreak.de Sun Nov 8 13:14:16 2009 From: stefreak at stefreak.de (Steffen 'stefreak' Neubauer) Date: Sun, 8 Nov 2009 14:14:16 +0100 Subject: [PATCH] implemented GSM340_TP_VPF_ABSOLUTE In-Reply-To: <20091108140856.30ea75b3@stefreak.de> References: <20091028160259.77c7e4b5@stefreak.de> <20091108053902.GY5881@prithivi.gnumonks.org> <20091108140856.30ea75b3@stefreak.de> Message-ID: <20091108141416.0a15451a@stefreak.de> On Sun, 8 Nov 2009 14:08:56 +0100 Steffen 'stefreak' Neubauer wrote: > The new patch is attached :) Oh i have to say that i have not really tested it - but it compiles fine :) I'm sorry; testing is not easy without a BTS :) I hope that's ok! Greetings, Steffen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From laforge at gnumonks.org Wed Nov 11 14:04:58 2009 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 11 Nov 2009 23:04:58 +0900 Subject: [PATCH] implemented GSM340_TP_VPF_ABSOLUTE In-Reply-To: <20091028160259.77c7e4b5@stefreak.de> References: <20091028160259.77c7e4b5@stefreak.de> Message-ID: <20091111140458.GC20087@prithivi.gnumonks.org> Thanks, I've now merged it, despite it is untested. I don't think it can seriously break any existing functionality... and if we add some code for a feature that was missing before, having a (possibly) still buggy implementation doesn't hurt either. It would be great if somebody could test the correct timezone setting and the VPF functionality in general. One way to test this (and continue to test it in the future) is to write a test that uses hard-coded TPDU's or CP-DATA blocks (preferrably captured from real-world SMS) and feeds them through our code and checks if the result is as expected. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Sun Nov 1 00:27:53 2009 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 1 Nov 2009 01:27:53 +0100 Subject: GPRS branch status updates In-Reply-To: <866320f70910311648w1586398bi1ec33cc6186ebea4@mail.gmail.com> References: <20091031180549.GB16562@prithivi.gnumonks.org> <866320f70910311638q2b2f2604o520ac15d920ca9e2@mail.gmail.com> <866320f70910311648w1586398bi1ec33cc6186ebea4@mail.gmail.com> Message-ID: <20091101002753.GG16562@prithivi.gnumonks.org> On Sun, Nov 01, 2009 at 12:48:43AM +0100, Sylvain Munaut wrote: > Ah, there is another hardcoded ip in nanobts_attr_nsvc0 in bsc_init.c > You need to put the OpenBSC ip in there. yes, you're right. I completely forgot about that. Patches for making those things non-hardcoded are greatly appreciated. The NSVC0 attribute address should be replaced by the getsockname() of the UDP socket. The IP address that's hardcoded for sending the UDP packets should be the address from which we are receiving the UDP packets. For now, there's only one. In the future, we will likely have multiple BTS, all sending UDP packets to port 23000 - in this case, we somehow need to keep track of those source IP addresses and generate a per-source-IP data structure. The best option probably is to keep the IP address somewhere stored in the struct gsm_bts and then match the BTS based on the source IP address for incoming packets, as well as determine the destination IP address when sending packets based on msg->trx->bts. 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 246tnt at gmail.com Sun Nov 1 10:05:31 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 1 Nov 2009 11:05:31 +0100 Subject: GPRS branch status updates In-Reply-To: <20091101002753.GG16562@prithivi.gnumonks.org> References: <20091031180549.GB16562@prithivi.gnumonks.org> <866320f70910311638q2b2f2604o520ac15d920ca9e2@mail.gmail.com> <866320f70910311648w1586398bi1ec33cc6186ebea4@mail.gmail.com> <20091101002753.GG16562@prithivi.gnumonks.org> Message-ID: <866320f70911010205w79918fa4v7885cd9a9bc83d51@mail.gmail.com> Fixing the IP helped but I don't think it's working yet because the last line in the log is : <0020> abis_nm.c:594 OC=GPRS CELL(f1) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03) And a little earlier there is : <0020> abis_nm.c:594 OC=GPRS CELL(f1) INST=(00,00,ff) IPACCESS(0xf7): SET ATTR NACK CAUSE=Message cannot be performed <0020> abis_nm.c:594 OC=GPRS CELL(f1) INST=(00,00,ff) Failure Event Report Type=communication failure Severity=major failure The full log is there. http://pastebin.com/m785cf86b I searched for what could be wrong but I didn't see anything obvious. Could you provide a trace of a working startup so I can compare ? Sylvain From spaar at mirider.augusta.de Sun Nov 1 14:34:28 2009 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Sun, 01 Nov 2009 14:34:28 Subject: GPRS branch status updates Message-ID: <4aed9c74.mirider@mirider.augusta.de> Hello Sylvain, On Sun, 1 Nov 2009 11:05:31 +0100, "Sylvain Munaut" <246tnt at gmail.com> wrote: > > I searched for what could be wrong but I didn't see anything obvious. > Could you provide a trace of a working startup so I can compare ? Maybe my trace is usefull too, I modified the two IP addresses and set "timeslot 7" to "phys_chan_config TCH/F_PDCH". I only noticed that it did not work immediately after the nanoBTS has been powered on, I had to start bsc_hack a second time (not sure if this can be reproduced). The trace is in the attached ZIP file, its from a Cygwin system. Best regards, Dieter Dieter Spaar, Germany spaar at mirider.augusta.de -------------- next part -------------- A non-text attachment was scrubbed... Name: log1.zip Type: application/x-zip-compressed Size: 1504 bytes Desc: not available URL: From 246tnt at gmail.com Sun Nov 1 20:17:26 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 1 Nov 2009 21:17:26 +0100 Subject: GPRS branch status updates In-Reply-To: <4aed9c74.mirider@mirider.augusta.de> References: <4aed9c74.mirider@mirider.augusta.de> Message-ID: <866320f70911011217k3fbfe6b3u185b930db24c7e7a@mail.gmail.com> Hi Dieter, Thanks for the trace, I'll have a look now. In the mean time I made some progress: - I have to remove the NM_ATT_IPACC_RLC_CFG_3 tag and config from nanobts_attr_cell. If I don't the GPRS CELL NACKs the attributes and never activate. The message sent back by the bts is "new value for attribute RLC Configuration 3 not supported" - In gprs_bssgp.c the function bssgp_rx_ul_ud calls : bts = gsm48_bts_by_ra_id( TLVP_VAL(&tp, BSSGP_IE_CELL_ID), TLVP_LEN(&tp, BSSGP_IE_CELL_ID)); But gsm48_bts_by_ra_id defined in gsm_04_08_gprs.c takes 3 arguments the gsm_network as first one then the buffer and lenght. Since the function was implicitely defined in gprs_bssgp.c, it compiled but of course segfaulted as soon as it got there ... I don't even understand how it worked for you. - Now, I get this : <0004> gsm_04_08_gprs.c:434 GMM RA UPDATE REQUEST type="RA updating" REJECT <0004> gsm_04_08_gprs.c:408 <- ROUTING AREA UPDATE REJECT But as soon as the REJECT is sent to the BTS, it reboots ... no error no message nothing ... Sylvain From spaar at mirider.augusta.de Sun Nov 1 21:29:42 2009 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Sun, 01 Nov 2009 21:29:42 Subject: GPRS branch status updates Message-ID: <4aedfdc6.mirider@mirider.augusta.de> Hello Sylvain, On Sun, 1 Nov 2009 21:17:26 +0100, "Sylvain Munaut" <246tnt at gmail.com> wrote: > > - In gprs_bssgp.c the function bssgp_rx_ul_ud calls : > > bts = gsm48_bts_by_ra_id( > TLVP_VAL(&tp, BSSGP_IE_CELL_ID), > TLVP_LEN(&tp, BSSGP_IE_CELL_ID)); > > But gsm48_bts_by_ra_id defined in gsm_04_08_gprs.c takes 3 arguments > the gsm_network as first one then the buffer and lenght. Since the > function was implicitely defined in gprs_bssgp.c, it compiled but of > course segfaulted as soon as it got there ... I don't even understand > how it worked for you. At the time I made the trace, I did not yet have connected with a GPRS phone. In the meantime I made a temporary workaround by referencing the global "bsc_gsmnet" and using it for the first parameter. > <0004> gsm_04_08_gprs.c:434 GMM RA UPDATE REQUEST type="RA updating" REJECT > <0004> gsm_04_08_gprs.c:408 <- ROUTING AREA UPDATE REJECT > > But as soon as the REJECT is sent to the BTS, it reboots ... no error > no message nothing ... I get a "GMM Attach Request" with my phone and the same behaviour afterwards, the nanoBTS reboots. Best regards, Dieter -- Dieter Spaar, Germany spaar at mirider.augusta.de From 246tnt at gmail.com Mon Nov 2 00:05:20 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Mon, 2 Nov 2009 01:05:20 +0100 Subject: GPRS branch status updates In-Reply-To: <4aedfdc6.mirider@mirider.augusta.de> References: <4aedfdc6.mirider@mirider.augusta.de> Message-ID: <866320f70911011605p326f2e50t2d8670eb8354be3b@mail.gmail.com> Hi Dieter, >> ?- In gprs_bssgp.c ?the function bssgp_rx_ul_ud calls : >> >> ? ? ? ? bts = gsm48_bts_by_ra_id( >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?TLVP_VAL(&tp, BSSGP_IE_CELL_ID), >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?TLVP_LEN(&tp, BSSGP_IE_CELL_ID)); >> >> ?But gsm48_bts_by_ra_id defined in gsm_04_08_gprs.c takes 3 arguments >> the gsm_network as first one then the buffer and lenght. Since the >> function was implicitely defined in gprs_bssgp.c, it compiled but of >> course segfaulted as soon as it got there ... I don't even understand >> how it worked for you. > > At the time I made the trace, I did not yet have connected with a GPRS > phone. In the meantime I made a temporary workaround by referencing > the global "bsc_gsmnet" and using it for the first parameter. Yes, I did the same because I couldn't find any way to get a proper gsm_network at that point in the code ... >> <0004> gsm_04_08_gprs.c:434 GMM RA UPDATE REQUEST type="RA updating" ?REJECT >> <0004> gsm_04_08_gprs.c:408 <- ROUTING AREA UPDATE REJECT >> >> But as soon as the REJECT is sent to the BTS, it reboots ... no error >> no message nothing ... > > I get a "GMM Attach Request" with my phone and the same behaviour > afterwards, the nanoBTS reboots. I found out the problem. In gprs_bssgp_tx_dl_ud, then length encoded in the PDU TLV is incorect. It uses msg->len but at that point it already did a msgb_push to add space for the header so msg->len is already too big. You need to save the size of msg->len before the msgb_push and then use that when encoding the PDU TLV length. Now, the MS tries to do : <0004> gsm_04_08_gprs.c:434 GMM RA UPDATE REQUEST type="RA updating" REJECT <0004> gsm_04_08_gprs.c:408 <- ROUTING AREA UPDATE REJECT repeatedly ... (3 or 4 times before giving up) BTW, do you sometimes hangout in #openbsc ? Sylvain From laforge at gnumonks.org Mon Nov 2 13:47:18 2009 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 2 Nov 2009 22:47:18 +0900 Subject: GPRS branch status updates In-Reply-To: <866320f70911011605p326f2e50t2d8670eb8354be3b@mail.gmail.com> References: <4aedfdc6.mirider@mirider.augusta.de> <866320f70911011605p326f2e50t2d8670eb8354be3b@mail.gmail.com> Message-ID: <20091102134718.GB6000@prithivi.gnumonks.org> On Mon, Nov 02, 2009 at 01:05:20AM +0100, Sylvain Munaut wrote: > >> <0004> gsm_04_08_gprs.c:434 GMM RA UPDATE REQUEST type="RA updating" ?REJECT > >> <0004> gsm_04_08_gprs.c:408 <- ROUTING AREA UPDATE REJECT This is actually very funny. According to the protocol, a RA update should only be performed if the MS was/is already GPRS ATTACHED to this network before. It clearly wasn't in this case, as the OpenBSC network never offered GPRS support. Still, it tries it. That's why we're rejecting it. > >> But as soon as the REJECT is sent to the BTS, it reboots ... no error > >> no message nothing ... > > > > I get a "GMM Attach Request" with my phone and the same behaviour > > afterwards, the nanoBTS reboots. The ATTACH REQUEST is what the phone should be doing from the very beginning. The RA update ounds like yet another bug in some GPRS protocol stack[s]... > I found out the problem. > > In gprs_bssgp_tx_dl_ud, then length encoded in the PDU TLV is > incorect. It uses msg->len but at that point it already did a > msgb_push to add space for the header so msg->len is already too big. > You need to save the size of msg->len before the msgb_push and then > use that when encoding the PDU TLV length. Thanks, nice spot. I think I've made that mistake before, as it sounds so familiar. I've fixed it now in the gprs brnch. Cheers, -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From spaar at mirider.augusta.de Mon Nov 2 11:35:00 2009 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Mon, 02 Nov 2009 11:35:00 Subject: GPRS branch status updates Message-ID: <4aeec3e4.mirider@mirider.augusta.de> Hello Sylvain, On Mon, 2 Nov 2009 01:05:20 +0100, "Sylvain Munaut" <246tnt at gmail.com> wrote: > > I found out the problem. > > In gprs_bssgp_tx_dl_ud, then length encoded in the PDU TLV is > incorect. It uses msg->len but at that point it already did a > msgb_push to add space for the header so msg->len is already too big. > You need to save the size of msg->len before the msgb_push and then > use that when encoding the PDU TLV length. Thanks for the info, I tried it here but it did not help for the "GMM ATTACH REQUEST", the nanoBTS still reboots when it receives the data of the "GPRS IDENTITY REQUEST" which is sent afterwards. I finally found the reason for this behaviour (at least I hope it is the reason), I had to specify the correct BVCI parameter for the call to gprs_ns_sendmsg() in gprs_bssgp_tx_dl_ud(). If I use "925" instead of "0" it works. The phone sends an "GMM IDENITY RESPONSE" and continues to send "GMM ATTACH REQUEST" because it does not yet receive an accept. > BTW, do you sometimes hangout in #openbsc ? No, usually not (its a bit difficult for me to do my work and look at what is happing on IRC). Best regards, Dieter -- Dieter Spaar, Germany spaar at mirider.augusta.de From 246tnt at gmail.com Tue Nov 3 07:03:15 2009 From: 246tnt at gmail.com (246tnt at gmail.com) Date: Tue, 03 Nov 2009 07:03:15 +0000 Subject: GPRS branch status updates In-Reply-To: <4aeec3e4.mirider@mirider.augusta.de> Message-ID: <0016e6d99cc198fcc304777216fc@google.com> > I finally found the reason for this behaviour (at least I hope > it is the reason), I had to specify the correct BVCI parameter > for the call to gprs_ns_sendmsg() in gprs_bssgp_tx_dl_ud(). If > I use "925" instead of "0" it works. Ah yes, I had to do that too. I fixed that first and forgot about it because it didn't fix the reboot but apparently both fix are needed for things to work. > The phone sends an "GMM > IDENITY RESPONSE" and continues to send "GMM ATTACH REQUEST" > because it does not yet receive an accept. After rebooting the phone fully I was able to convince it it wasn't attached (both my iPhone and my android had the same behavior of thinking they were still attached after switching from their 'home' network EDGE to OpenBSC GPRS, even with different mnc/mcc ... And they didn't seem to care about the RA REJECT with "implicit detach" cause) Initially I had a segfault when receiving a GMM ATTACH. The MCC/MNC in the CELL ID transmitted in the GMM ATTACH REQUEST are not the one I set in openbsc.cfg, they seem hardcoded to 001/01 but I haven't found from where yet. So currently you need to set 1/1 in your openbsc.cfg as well. Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Tue Nov 3 07:55:27 2009 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 3 Nov 2009 16:55:27 +0900 Subject: GPRS branch status updates In-Reply-To: <0016e6d99cc198fcc304777216fc@google.com> References: <4aeec3e4.mirider@mirider.augusta.de> <0016e6d99cc198fcc304777216fc@google.com> Message-ID: <20091103075527.GS3781@prithivi.gnumonks.org> On Tue, Nov 03, 2009 at 07:03:15AM +0000, 246tnt at gmail.com wrote: > Initially I had a segfault when receiving a GMM ATTACH. The MCC/MNC in > the CELL ID transmitted in the GMM ATTACH REQUEST are not the one I set > in openbsc.cfg, they seem hardcoded to 001/01 but I haven't found from > where yet. it's the NM_ATT_IPACC_CGI in nanobts_attr_bts[]: three bytes bcd-encoded mcc/mnc, two bytes lac and two bytes cell id. two-byte values as u_int16_t in network byte order. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From spaar at mirider.augusta.de Tue Nov 3 08:36:15 2009 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Tue, 03 Nov 2009 08:36:15 Subject: GPRS branch status updates Message-ID: <4aefeb7f.mirider@mirider.augusta.de> Hello Sylvain, On Tue, 03 Nov 2009 07:03:15 +0000, 246tnt at gmail.com wrote: > > Initially I had a segfault when receiving a GMM ATTACH. The MCC/MNC in the > CELL ID transmitted in the GMM ATTACH REQUEST are not the one I set in > openbsc.cfg, they seem hardcoded to 001/01 but I haven't found from where > yet. So currently you need to set 1/1 in your openbsc.cfg as well. Its in bsc_init.c, the variable "nanobts_attr_bts": NM_ATT_IPACC_CGI, 0, 7, 0x00, 0xf1, 0x10, 0x00, 0x01, 0x00, 0x00, I did modify patch_nm_tables() and added: // this overwrites nanobts_attr_bts[54], but we set it later anyway gsm48_ra_id_by_bts(&nanobts_attr_bts[49], bts); nanobts_attr_bts[54] = htons(bts->cell_identity) & 0xFF; nanobts_attr_bts[55] = (htons(bts->cell_identity) >> 8) & 0xFF; Additionally I fixed setting the BSIC: nanobts_attr_bts[45] = bts->bsic; I have not yet provided a patch because its not fully tested, however Harald is informed. Best regards, Dieter -- Dieter Spaar, Germany spaar at mirider.augusta.de From laforge at gnumonks.org Tue Nov 3 07:10:58 2009 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 3 Nov 2009 16:10:58 +0900 Subject: GPRS branch status updates In-Reply-To: <4aeec3e4.mirider@mirider.augusta.de> References: <4aeec3e4.mirider@mirider.augusta.de> Message-ID: <20091103071058.GP3781@prithivi.gnumonks.org> Hi Dieter and Sylvain, On Mon, Nov 02, 2009 at 11:35:00AM +0000, Dieter Spaar wrote: > Thanks for the info, I tried it here but it did not help for the > "GMM ATTACH REQUEST", the nanoBTS still reboots when it receives > the data of the "GPRS IDENTITY REQUEST" which is sent afterwards. > I finally found the reason for this behaviour (at least I hope > it is the reason), I had to specify the correct BVCI parameter > for the call to gprs_ns_sendmsg() in gprs_bssgp_tx_dl_ud(). If > I use "925" instead of "0" it works. The phone sends an "GMM > IDENITY RESPONSE" and continues to send "GMM ATTACH REQUEST" > because it does not yet receive an accept. I'll soon add the nsvci and bvci values to the config file. Those values are then used by both the OML attributes and the BSSGP/NS protocol code, which should address this problem 'the right way'. > > BTW, do you sometimes hangout in #openbsc ? > > No, usually not (its a bit difficult for me to do my work and > look at what is happing on IRC). yes, getting Dieter at least on an instant messenger (not even talking about IRC) is really hard ;) -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From spaar at mirider.augusta.de Mon Nov 2 23:03:42 2009 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Mon, 02 Nov 2009 23:03:42 Subject: GPRS branch status updates Message-ID: <4aef654e.mirider@mirider.augusta.de> Hello Harald, On Mon, 2 Nov 2009 22:47:18 +0900, "Harald Welte" wrote: > > This is actually very funny. According to the protocol, a RA update should > only be performed if the MS was/is already GPRS ATTACHED to this network > before. It clearly wasn't in this case, as the OpenBSC network never > offered GPRS support. Still, it tries it. That's why we're rejecting it. Not sure if I understand it in detail, from my understanding an RA Update is performed when the Routing Area has changed (or the periodic RA update timer has expired). So if the phone is already attached to a network, shouldn't we receive the RA update if it selects our new RA ? Best regards, Dieter -- Dieter Spaar, Germany spaar at mirider.augusta.de From laforge at gnumonks.org Tue Nov 3 00:25:14 2009 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 3 Nov 2009 09:25:14 +0900 Subject: GPRS branch status updates In-Reply-To: <4aef654e.mirider@mirider.augusta.de> References: <4aef654e.mirider@mirider.augusta.de> Message-ID: <20091103002513.GA3847@prithivi.gnumonks.org> On Mon, Nov 02, 2009 at 11:03:42PM +0000, Dieter Spaar wrote: > Hello Harald, > > On Mon, 2 Nov 2009 22:47:18 +0900, "Harald Welte" wrote: > > > > This is actually very funny. According to the protocol, a RA update should > > only be performed if the MS was/is already GPRS ATTACHED to this network > > before. It clearly wasn't in this case, as the OpenBSC network never > > offered GPRS support. Still, it tries it. That's why we're rejecting it. > > Not sure if I understand it in detail, from my understanding an RA Update > is performed when the Routing Area has changed (or the periodic RA update > timer has expired). So if the phone is already attached to a network, > shouldn't we receive the RA update if it selects our new RA ? a routing area change is a routing area change within one network. if it enters a new network (different MCC/MNC), it needs to gprs attach to this network first. -- - 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 Nov 9 07:33:09 2009 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 9 Nov 2009 16:33:09 +0900 Subject: GPRS branch status updates In-Reply-To: <4aef654e.mirider@mirider.augusta.de> References: <4aef654e.mirider@mirider.augusta.de> Message-ID: <20091109073309.GQ4027@prithivi.gnumonks.org> On Mon, Nov 02, 2009 at 11:03:42PM +0000, Dieter Spaar wrote: > Hello Harald, > > On Mon, 2 Nov 2009 22:47:18 +0900, "Harald Welte" wrote: > > > > This is actually very funny. According to the protocol, a RA update should > > only be performed if the MS was/is already GPRS ATTACHED to this network > > before. It clearly wasn't in this case, as the OpenBSC network never > > offered GPRS support. Still, it tries it. That's why we're rejecting it. > > Not sure if I understand it in detail, from my understanding an RA Update > is performed when the Routing Area has changed (or the periodic RA update > timer has expired). So if the phone is already attached to a network, > shouldn't we receive the RA update if it selects our new RA ? As it turns out, this really seems to be the case. So even while switching from one mobile network (MNC/MCC) to another, the MS can apparently just perform a RA update and does not have to do a GPRS attach. This explains the beahvior. It's still quite weird to me, but well, at least we know the phones in question are behaving like they should. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From mailinglists at hellercom.de Mon Nov 2 05:38:15 2009 From: mailinglists at hellercom.de (Bjoern Heller) Date: Mon, 2 Nov 2009 06:38:15 +0100 Subject: lots of new BS11 internals pictures Message-ID: <265B94EC-A6B4-4C2E-A7A2-42C9DC220016@hellercom.de> Hi, we made lots of pictures of the bs11 pcbs. Maybe they will help you during disassembly or are interesting in an technical aspect. http://www.flickr.com/photos/hellercom/sets/72157619296925571/ regards Bjoern - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Bj?rn Heller Jabber: tec at jabber.hellercom.de -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Mon Nov 2 21:39:36 2009 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 3 Nov 2009 06:39:36 +0900 Subject: question about cell broadcast estimate In-Reply-To: References: Message-ID: <20091102213936.GD6000@prithivi.gnumonks.org> Dear Tim! I hope you don't mind I'm Cc'ing the mailing list. This means that other people can get involved in the discussion - and also means that I only have to write my summary about what needs to be done once, even if you for some reason are unable to complete the actual implementation :) On Mon, Nov 02, 2009 at 01:25:13PM -0500, Newman, Timothy wrote: > I'm working at Virginia Tech and it looks like we are going to start playing > with the cell broadcast gsm stuff. I'd like to just go ahead and add it into > openbsc. This is great news, thanks. Which BTS type are you using with OpenBSC? > Other than the brief read through of some of the 3GPP documents related to > cell broadcast, I'm not too familiar with the interworkings of it. It's not really difficult. What needs to be done 1) enable a channel configuration that adds a CBCH to one of the SDCCH/4 in a combined CCCH, or one of the SDCCH/8. I'd prefer the SDCCH/4, since that is supported by both BS-11 and nanoBTS. However, feel free to implement both options 2) encode the CBCH message (very similar to SMS encoding) TS 03.38 / 03.41 3) have a function to send the CBCH to the BTS over RSL (TS 08.58) 4) later: Implement the Scheduling (Chapter 2.1 of TS 04.12) for DRX There's two options for cell broadcast: 1) you can set a default cell broadcast message once by the BSC. The BTS then transmit that CB in every idle fame of the CBCH (TS 08.58 SMS BROADCAST CMD) 2) you want to sent multiple different CB messages, then the BSC needs to do the scheduling and send them to the BTS's (TS 08.58 SMS BROADCAST REQ) > I'm a little unclear how long this may take to add this functionality into > openbsc. If you had to estimate how long it would take (e.g. 1, 2, 6, 12 > months), what would you say? Just give me your estimate and I'll multiply > this by 4 because it will be students working on the project and they need a > little (a lot) of ramp of time for this also. If I or any other of the OpenBSC developers was doing it, I would say this is a matter of days, one week max for all of the options described above. However, you need to consider that your studends also have to read up the 3GPP specs, are unfamiliar with the terminlology, don't know the OpenBSC codebase, probably have not that much experience with "plain C" programming in an select-loop single threaded design, ... so a factor of four might not be sufficient. Regards, Harald p.s.: I would be interested in learning what you're using OpenBSC for at Virginia Tech. If you have a minute to elaborate on that, I'm very curious. Other people on the mailing list might share that interest, especially those users from academic institutions. If you prefer to respond privately, that would also be OK with me. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From trnewman at vt.edu Mon Nov 2 22:17:10 2009 From: trnewman at vt.edu (Newman, Timothy) Date: Mon, 2 Nov 2009 17:17:10 -0500 Subject: question about cell broadcast estimate In-Reply-To: <20091102213936.GD6000@prithivi.gnumonks.org> References: <20091102213936.GD6000@prithivi.gnumonks.org> Message-ID: > > p.s.: I would be interested in learning what you're using OpenBSC for at > Virginia Tech. If you have a minute to elaborate on that, I'm very curious. > Other people on the mailing list might share that interest, especially those > users from academic institutions. If you prefer to respond privately, that > would also be OK with me. > Well it's primarily something of interest to the emergency services people around here. It's much more efficient to use the cell broadcast functions that the hardcoded "send us your cell phone #" emergency notification system they currently have. So in the end, it's to improve communications for emergency services, plus I'd like to simply get some students in this part of the spec and have a group that's familiar with OpenBSC. We offer a cellular class and want to integrate openbsc and openbts labs into them. Tim ------------------------------------------- Timothy R. Newman, Ph.D. Wireless @ Virginia Tech 447 Durham Hall Blacksburg, VA 24061 Phone: 540-231-2041 From womax at gmx.ch Mon Nov 2 22:06:18 2009 From: womax at gmx.ch (WoMax) Date: Mon, 2 Nov 2009 23:06:18 +0100 Subject: special offer - nanoBTS Message-ID: <8A8F55B3A30F442B9A286DCCAD520D0E@HAL2008> Special offer for the last nanoBTS type 139, Siemens (MOGIS) branded, new in box, but without POE-Adapter! Only one available, only 1900 Euro plus shipment. Contact me at womax(at)gmx(dot)ch From mailinglists at hellercom.de Thu Nov 5 07:44:06 2009 From: mailinglists at hellercom.de (Bjoern Heller) Date: Thu, 5 Nov 2009 08:44:06 +0100 Subject: NanoBTS Message-ID: <068B4935-2AB1-473A-87E6-B7FB80680A98@hellercom.de> Hello everybody! Got my ip.access today by mail! *happy. Is there any configuration tool for it? Or how do I configure it to listen on an specific IP? Best Regards Bj?rn Heller From zecke at selfish.org Thu Nov 5 07:51:53 2009 From: zecke at selfish.org (Holger Freyther) Date: Thu, 5 Nov 2009 08:51:53 +0100 Subject: NanoBTS In-Reply-To: <068B4935-2AB1-473A-87E6-B7FB80680A98@hellercom.de> References: <068B4935-2AB1-473A-87E6-B7FB80680A98@hellercom.de> Message-ID: <200911050851.53763.zecke@selfish.org> On Thursday 05 November 2009 08:44:06 Bjoern Heller wrote: > Hello everybody! > > Got my ip.access today by mail! *happy. > > Is there any configuration tool for it? > Or how do I configure it to listen on an specific IP? Please see http://openbsc.gnumonks.org/trac/wiki/ipaccess-config there is also ipaccess-find to find a nanoBTS in your net.. z. From womax at gmx.ch Thu Nov 5 08:14:52 2009 From: womax at gmx.ch (WoMax) Date: Thu, 5 Nov 2009 09:14:52 +0100 Subject: NanoBTS In-Reply-To: <200911050851.53763.zecke@selfish.org> References: <068B4935-2AB1-473A-87E6-B7FB80680A98@hellercom.de> <200911050851.53763.zecke@selfish.org> Message-ID: <985843214A0D4C6891BC13878D230C9C@HAL2008> If your nanoBTS is preprogramed with a static IP you don't know, or you want to start with a virgin one, use the trick with the reset-dongle I described earlier in the list. From mailinglists at hellercom.de Thu Nov 5 08:47:18 2009 From: mailinglists at hellercom.de (Bjoern Heller) Date: Thu, 5 Nov 2009 09:47:18 +0100 Subject: NanoBTS In-Reply-To: <985843214A0D4C6891BC13878D230C9C@HAL2008> References: <068B4935-2AB1-473A-87E6-B7FB80680A98@hellercom.de> <200911050851.53763.zecke@selfish.org> <985843214A0D4C6891BC13878D230C9C@HAL2008> Message-ID: <6561A0FB-2B3F-4AD2-82EC-85FCBF7EA079@hellercom.de> Ah, cant find it in my inbox. could you cc the mail for me? Thanks ;) Best Regards Bj?rn Heller Am 05.11.2009 um 09:14 schrieb "WoMax" : > If your nanoBTS is preprogramed with a static IP you don't know, or > you want > to start with a virgin one, use the trick with the reset-dongle I > described > earlier in the list. > > From 246tnt at gmail.com Thu Nov 5 08:53:10 2009 From: 246tnt at gmail.com (246tnt at gmail.com) Date: Thu, 05 Nov 2009 08:53:10 +0000 Subject: NanoBTS In-Reply-To: <6561A0FB-2B3F-4AD2-82EC-85FCBF7EA079@hellercom.de> Message-ID: <0014853120d5549e1704779bdb7c@google.com> http://lists.gnumonks.org/pipermail/openbsc/2009-August/000804.html On Nov 5, 2009 9:47am, Bjoern Heller wrote: > Ah, > cant find it in my inbox. > could you cc the mail for me? > Thanks ;) > Best Regards > Bj?rn Heller > Am 05.11.2009 um 09:14 schrieb "WoMax" womax at gmx.ch>: > If your nanoBTS is preprogramed with a static IP you don't know, or you > want > to start with a virgin one, use the trick with the reset-dongle I > described > earlier in the list. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailinglists at hellercom.de Thu Nov 5 09:24:18 2009 From: mailinglists at hellercom.de (Bjoern Heller) Date: Thu, 5 Nov 2009 10:24:18 +0100 Subject: NanoBTS In-Reply-To: <0014853120d5549e1704779bdb7c@google.com> References: <0014853120d5549e1704779bdb7c@google.com> Message-ID: <4FB03710-8DE4-4A8D-B620-D27EA041758A@hellercom.de> Hello, the led flashed red, but after restart it went back to yellow as before. Best Regards Bj?rn Heller Am 05.11.2009 um 09:53 schrieb 246tnt at gmail.com: > http://lists.gnumonks.org/pipermail/openbsc/2009-August/000804.html > > > On Nov 5, 2009 9:47am, Bjoern Heller > wrote: > > Ah, > > > > > > > > cant find it in my inbox. > > > > could you cc the mail for me? > > > > Thanks ;) > > > > > > > > Best Regards > > > > Bj?rn Heller > > > > > > > > Am 05.11.2009 um 09:14 schrieb "WoMax" womax at gmx.ch>: > > > > > > > > > > If your nanoBTS is preprogramed with a static IP you don't know, > or you want > > > > to start with a virgin one, use the trick with the reset-dongle I > described > > > > earlier in the list. > > > > > > > > > > > > > > > > From mailinglists at hellercom.de Thu Nov 5 11:50:32 2009 From: mailinglists at hellercom.de (Bjoern Heller) Date: Thu, 5 Nov 2009 12:50:32 +0100 Subject: NanoBTS In-Reply-To: <4FB03710-8DE4-4A8D-B620-D27EA041758A@hellercom.de> References: <0014853120d5549e1704779bdb7c@google.com> <4FB03710-8DE4-4A8D-B620-D27EA041758A@hellercom.de> Message-ID: <8E351935-5A5E-4874-BC07-73B967016583@hellercom.de> Ok, found the BTS, but in ipaccess config I get a "no matching signalling link for hh- >proto=0xff" back. I used the command from the wiki... Best Regards Bj?rn Heller Am 05.11.2009 um 10:24 schrieb Bjoern Heller : > Hello, > > the led flashed red, but after restart it went back to yellow as > before. > > Best Regards > Bj?rn Heller > > Am 05.11.2009 um 09:53 schrieb 246tnt at gmail.com: > >> http://lists.gnumonks.org/pipermail/openbsc/2009-August/000804.html >> >> >> On Nov 5, 2009 9:47am, Bjoern Heller >> wrote: >> > Ah, >> > >> > >> > >> > cant find it in my inbox. >> > >> > could you cc the mail for me? >> > >> > Thanks ;) >> > >> > >> > >> > Best Regards >> > >> > Bj?rn Heller >> > >> > >> > >> > Am 05.11.2009 um 09:14 schrieb "WoMax" womax at gmx.ch>: >> > >> > >> > >> > >> > If your nanoBTS is preprogramed with a static IP you don't know, >> or you want >> > >> > to start with a virgin one, use the trick with the reset-dongle I >> described >> > >> > earlier in the list. >> > >> > >> > >> > >> > >> > >> > >> > > From zecke at selfish.org Thu Nov 5 12:02:27 2009 From: zecke at selfish.org (Holger Freyther) Date: Thu, 5 Nov 2009 13:02:27 +0100 Subject: NanoBTS In-Reply-To: <8E351935-5A5E-4874-BC07-73B967016583@hellercom.de> References: <0014853120d5549e1704779bdb7c@google.com> <4FB03710-8DE4-4A8D-B620-D27EA041758A@hellercom.de> <8E351935-5A5E-4874-BC07-73B967016583@hellercom.de> Message-ID: <200911051302.27571.zecke@selfish.org> On Thursday 05 November 2009 12:50:32 Bjoern Heller wrote: > Ok, found the BTS, but > in ipaccess config I get a "no matching signalling link for hh- > > >proto=0xff" back. I used the command from the wiki... update the source? I fixed that last week. z. From mailinglists at hellercom.de Thu Nov 5 14:36:13 2009 From: mailinglists at hellercom.de (Bjoern Heller) Date: Thu, 5 Nov 2009 15:36:13 +0100 Subject: NanoBTS Message-ID: <47A2C2E9-B3F6-4BAB-8FE5-446F014CBC19@hellercom.de> Got it ;) Voice-calls working. Thanks everyone!!! Best Regards Bj?rn Heller Am 05.11.2009 um 13:02 schrieb Holger Freyther : > On Thursday 05 November 2009 12:50:32 Bjoern Heller wrote: >> Ok, found the BTS, but >> in ipaccess config I get a "no matching signalling link for hh- >> >>> proto=0xff" back. I used the command from the wiki... > > > update the source? I fixed that last week. > > z. > > From laforge at gnumonks.org Sat Nov 7 12:02:36 2009 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 7 Nov 2009 21:02:36 +0900 Subject: Testers wanted: Ensuring BS-11 is always working Message-ID: <20091107120236.GM5881@prithivi.gnumonks.org> Hi! Since the current two main developers of OpenBSC (Holger and myself) are travelling almost all the time and not in the vicinity of a BS-11, I fear that we sometimes might introduce code that is incompatible with the BS-11 or introduces regressions on it. Threfore, I would like to see if there are any volunteers here who are willing to regularly check out the latest code and test it if it still works on their BS-11. Anyone? Thanks in advance, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From mailinglists at hellercom.de Sun Nov 8 00:47:44 2009 From: mailinglists at hellercom.de (Bjoern Heller) Date: Sun, 8 Nov 2009 01:47:44 +0100 Subject: SMS delivery Message-ID: <39A78D51-A220-4BB8-8426-C788F88E8D4E@hellercom.de> Hello, I never used it much, but when I try to send an SMS from a MS to another one it is not delivered to the second MS. OpenBSC displays that the SMS was received. If I do a Location Update on the second Phone the SMS gets delivered. Also if I enter the command "sms send pending". How can I setup automatic delivery? Am I right, that OpenBSC first looks, if the second subscriber is connected to the network and then delivers the message? regards Bjoern - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Bj?rn Heller Jabber: tec at jabber.hellercom.de -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Sun Nov 8 05:30:33 2009 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 8 Nov 2009 14:30:33 +0900 Subject: SMS delivery In-Reply-To: <39A78D51-A220-4BB8-8426-C788F88E8D4E@hellercom.de> References: <39A78D51-A220-4BB8-8426-C788F88E8D4E@hellercom.de> Message-ID: <20091108053033.GX5881@prithivi.gnumonks.org> Hi Bjoern, On Sun, Nov 08, 2009 at 01:47:44AM +0100, Bjoern Heller wrote: > I never used it much, but when I try to send an SMS > from a MS to another one it is not delivered to the second MS. > OpenBSC displays that the SMS was received. > If I do a Location Update on the second Phone the SMS gets delivered. > Also if I enter the command "sms send pending". yes, this is correct. > How can I setup automatic delivery? this has not yet been implemented. I did not want to implement that before introducing some kind of SMS protocol and splitting the SMSC functionality into a separate process. But you are of course free to try to implement it. Attempting one delivery immediately after we receive the SMS is probably a very good idea. But whether or not to regularly run timers to retry failed deliveries, I am not sure. With a long queue of pending messages like we had on HAR, the load iterating over that table can be very high, and it definitely will cause delays(latency) in processing of speech frames or even signalling. > Am I right, that OpenBSC first looks, if the second subscriber is connected > to the network and then delivers the message? yes. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From dburgess at jcis.net Sun Nov 8 19:17:11 2009 From: dburgess at jcis.net (David A. Burgess) Date: Sun, 8 Nov 2009 11:17:11 -0800 Subject: SMS delivery In-Reply-To: <20091108053033.GX5881@prithivi.gnumonks.org> References: <39A78D51-A220-4BB8-8426-C788F88E8D4E@hellercom.de> <20091108053033.GX5881@prithivi.gnumonks.org> Message-ID: <4FDE2860-BF26-4153-8D0F-A93BCD80CBEE@jcis.net> Harald - We have an SMS store and forward server for OpenBTS if you are interested. It performs automatic redelivery attempts and "bounces" undeliverable messages, but the interface is RFC-3428 and it is not yet aware of TPDU types. (Bonus: It was written by John Gilmore.) Some commercial SMSCs do support RFC-3428, though, so maybe this can be made to fit into your model. -- David On Nov 7, 2009, at 9:30 PM, Harald Welte wrote: > Hi Bjoern, > > On Sun, Nov 08, 2009 at 01:47:44AM +0100, Bjoern Heller wrote: > >> I never used it much, but when I try to send an SMS >> from a MS to another one it is not delivered to the second MS. >> OpenBSC displays that the SMS was received. >> If I do a Location Update on the second Phone the SMS gets delivered. >> Also if I enter the command "sms send pending". > > yes, this is correct. > >> How can I setup automatic delivery? > > this has not yet been implemented. I did not want to implement > that before > introducing some kind of SMS protocol and splitting the SMSC > functionality into > a separate process. But you are of course free to try to > implement it. > Attempting one delivery immediately after we receive the SMS is > probably a very > good idea. > > But whether or not to regularly run timers to retry failed > deliveries, I am not > sure. With a long queue of pending messages like we had on HAR, > the load > iterating over that table can be very high, and it definitely will > cause > delays(latency) in processing of speech frames or even signalling. > >> Am I right, that OpenBSC first looks, if the second subscriber is >> connected >> to the network and then delivers the message? > > yes. > > -- > - Harald Welte http:// > laforge.gnumonks.org/ > ====================================================================== > ====== > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 > 175-7 Ch. A6) David A. Burgess Kestrel Signal Processing, Inc. From bouchtaoui at gmail.com Mon Nov 9 10:50:41 2009 From: bouchtaoui at gmail.com (Nordin) Date: Mon, 09 Nov 2009 11:50:41 +0100 Subject: No access message. Message-ID: <4AF7F401.8070002@gmail.com> Hello guys, If I run the latest version of openbsc and tried to register with my MS (Nokia 6310) to it, my phone finally says No Access. I see sending Channel Release several time in the debugging output. I also see increase/decrease usage several time. It has been a while not looking at the meaning of debug messages. I just use the standard config file for nanobts and changed a few parameters like unit_id, band, mcc and mnc, that's all. I noticed that I can't add an accept parameter, like before. Also in the config file I can't find anything like that, am I missing something? kind regards, nordin. From 246tnt at gmail.com Mon Nov 9 11:19:30 2009 From: 246tnt at gmail.com (246tnt at gmail.com) Date: Mon, 09 Nov 2009 11:19:30 +0000 Subject: No access message. In-Reply-To: <4AF7F401.8070002@gmail.com> Message-ID: <0016e6d7e35205a5b60477ee5e46@google.com> Hi, > If I run the latest version of openbsc and tried to register with my MS > (Nokia 6310) to it, my phone finally says No Access. Because the IMSI is probably not an authorized one. > I see sending Channel Release several time in the debugging output. I > also see increase/decrease usage several time. It has been a while not > looking at the meaning of debug messages. Yes, I've seen multiple RF release too. I think there is a bug somewhere but didn't search yet. > I just use the standard config file for nanobts and changed a few > parameters like unit_id, band, mcc and mnc, that's all. I noticed that I > can't add an accept parameter, like before. Also in the config file I > can't find anything like that, am I missing something? The equivalent config parameter is "auth policy". The defaut nano bts config file uses "auth policy closed" so all unauthorized phones will be rejected. You need t use "auth policy accept-all" if you want to authorized everyone without any check. Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From bouchtaoui at gmail.com Mon Nov 9 11:40:29 2009 From: bouchtaoui at gmail.com (Nordin) Date: Mon, 09 Nov 2009 12:40:29 +0100 Subject: No access message. In-Reply-To: <0016e6d7e35205a5b60477ee5e46@google.com> References: <0016e6d7e35205a5b60477ee5e46@google.com> Message-ID: <4AF7FFAD.4040702@gmail.com> Thank you for your response, 246tnt at gmail.com schreef: > Hi, > >> If I run the latest version of openbsc and tried to register with my >> MS (Nokia 6310) to it, my phone finally says No Access. > > Because the IMSI is probably not an authorized one. Uhhh, where can I authorize it? >> I just use the standard config file for nanobts and changed a few >> parameters like unit_id, band, mcc and mnc, that's all. I noticed >> that I can't add an accept parameter, like before. Also in the config >> file I can't find anything like that, am I missing something? > > The equivalent config parameter is "auth policy". The defaut nano bts > config file uses "auth policy closed" so all unauthorized phones will > be rejected. You need t use "auth policy accept-all" if you want to > authorized everyone without any check. > I don't want to bother you with silly questions, but I just can't find something about policy in the config-file examples, see link. http://repo.or.cz/w/openbsc.git/blob_plain/HEAD:/openbsc/src/openbsc.cfg.nanobts From mailinglists at hellercom.de Mon Nov 9 11:45:14 2009 From: mailinglists at hellercom.de (Bjoern Heller) Date: Mon, 9 Nov 2009 12:45:14 +0100 Subject: No access message. In-Reply-To: <4AF7FFAD.4040702@gmail.com> References: <0016e6d7e35205a5b60477ee5e46@google.com> <4AF7FFAD.4040702@gmail.com> Message-ID: <9BA6E16E-F49C-4A96-B123-E39E5708CB95@hellercom.de> Try to telnet to localhost 4242 then enable configure terminal network auth policy accept-all Best Regards Bj?rn Heller Am 09.11.2009 um 12:40 schrieb Nordin : > Thank you for your response, > > 246tnt at gmail.com schreef: >> Hi, >> >>> If I run the latest version of openbsc and tried to register with >>> my MS (Nokia 6310) to it, my phone finally says No Access. >> >> Because the IMSI is probably not an authorized one. > > Uhhh, where can I authorize it? > >>> I just use the standard config file for nanobts and changed a few >>> parameters like unit_id, band, mcc and mnc, that's all. I noticed >>> that I can't add an accept parameter, like before. Also in the >>> config file I can't find anything like that, am I missing something? >> >> The equivalent config parameter is "auth policy". The defaut nano >> bts config file uses "auth policy closed" so all unauthorized >> phones will be rejected. You need t use "auth policy accept-all" if >> you want to authorized everyone without any check. >> > > I don't want to bother you with silly questions, but I just can't > find something about policy in the config-file examples, see link. > http://repo.or.cz/w/openbsc.git/blob_plain/HEAD:/openbsc/src/openbsc.cfg.nanobts > > > From bouchtaoui at gmail.com Mon Nov 9 12:50:59 2009 From: bouchtaoui at gmail.com (Nordin) Date: Mon, 09 Nov 2009 13:50:59 +0100 Subject: No access message. In-Reply-To: <9BA6E16E-F49C-4A96-B123-E39E5708CB95@hellercom.de> References: <0016e6d7e35205a5b60477ee5e46@google.com> <4AF7FFAD.4040702@gmail.com> <9BA6E16E-F49C-4A96-B123-E39E5708CB95@hellercom.de> Message-ID: <4AF81033.8000607@gmail.com> Thanks for your responses guys, It was my mistake I wrote "auth_policy" instead of "auth policy" Bjoern Heller schreef: > Try to telnet to localhost 4242 > > then > > enable > configure terminal > network > auth policy accept-all > > > Best Regards > Bj??rn Heller > > Am 09.11.2009 um 12:40 schrieb Nordin : > >> Thank you for your response, >> >> 246tnt at gmail.com schreef: >>> Hi, >>> >>>> If I run the latest version of openbsc and tried to register with >>>> my MS (Nokia 6310) to it, my phone finally says No Access. >>> >>> Because the IMSI is probably not an authorized one. >> >> Uhhh, where can I authorize it? >> >>>> I just use the standard config file for nanobts and changed a few >>>> parameters like unit_id, band, mcc and mnc, that's all. I noticed >>>> that I can't add an accept parameter, like before. Also in the >>>> config file I can't find anything like that, am I missing something? >>> >>> The equivalent config parameter is "auth policy". The defaut nano >>> bts config file uses "auth policy closed" so all unauthorized phones >>> will be rejected. You need t use "auth policy accept-all" if you >>> want to authorized everyone without any check. >>> >> >> I don't want to bother you with silly questions, but I just can't >> find something about policy in the config-file examples, see link. >> http://repo.or.cz/w/openbsc.git/blob_plain/HEAD:/openbsc/src/openbsc.cfg.nanobts >> >> >> >> > From mailinglists at hellercom.de Mon Nov 9 11:43:31 2009 From: mailinglists at hellercom.de (Bjoern Heller) Date: Mon, 9 Nov 2009 12:43:31 +0100 Subject: No access message. In-Reply-To: <4AF7F401.8070002@gmail.com> References: <4AF7F401.8070002@gmail.com> Message-ID: Hi, maybe your SIM is rejecting the loc update (my old D2 cards do). Best Regards Bj?rn Heller Am 09.11.2009 um 11:50 schrieb Nordin : > Hello guys, > > If I run the latest version of openbsc and tried to register with my > MS (Nokia 6310) to it, my phone finally says No Access. > I see sending Channel Release several time in the debugging output. > I also see increase/decrease usage several time. It has been a while > not looking at the meaning of debug messages. I just use the > standard config file for nanobts and changed a few parameters like > unit_id, band, mcc and mnc, that's all. I noticed that I can't add > an accept parameter, like before. Also in the config file I can't > find anything like that, am I missing something? > > > kind regards, > > nordin. > > From openbscuser at gmail.com Thu Nov 12 17:54:22 2009 From: openbscuser at gmail.com (=?UTF-8?Q?=E0=B2=A8=E0=B2=BE=E0=B2=97=E0=B3=87=E0=B2=B6=E0=B3=8D?=) Date: Thu, 12 Nov 2009 23:24:22 +0530 Subject: Testing an OpenBSC installation. Message-ID: <1258048462.10194.3.camel@nsubrahm> Hi, Your tutorial on getting started with Debian system is good. Once the installation is over, what tests would you suggest to know the system is ok ? Similarly, how would one ensure that the machine running OpenBSC is talking nice with the BTS ? N From mailinglists at hellercom.de Thu Nov 12 18:34:23 2009 From: mailinglists at hellercom.de (Bjoern Heller) Date: Thu, 12 Nov 2009 19:34:23 +0100 Subject: Testing an OpenBSC installation. In-Reply-To: <1258048462.10194.3.camel@nsubrahm> References: <1258048462.10194.3.camel@nsubrahm> Message-ID: Hello, thank you ;) Test if misdn is loaded, and then run ./bsc_hack -a But your BS11 must be configured before with bs11_config if not already done. regards Bjoern Am 12.11.2009 um 18:54 schrieb ??????: > Hi, > Your tutorial on getting started with Debian system is good. Once > the installation is over, what tests would you suggest to know the > system is ok ? Similarly, how would one ensure that the machine running > OpenBSC is talking nice with the BTS ? > > N > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Bj?rn Heller Jabber: tec at jabber.hellercom.de -------------- next part -------------- An HTML attachment was scrubbed... URL: From openbscuser at gmail.com Thu Nov 12 17:58:14 2009 From: openbscuser at gmail.com (=?UTF-8?Q?=E0=B2=A8=E0=B2=BE=E0=B2=97=E0=B3=87=E0=B2=B6=E0=B3=8D?=) Date: Thu, 12 Nov 2009 23:28:14 +0530 Subject: [Fwd: Testing an OpenBSC installation.] Message-ID: <1258048694.10194.4.camel@nsubrahm> Never mind, I think, I found it. http://bs11-abis.gnumonks.org/trac/wiki/BS11_Getting_Started Thanks ! -------- Forwarded Message -------- From: ?????? Reply-to: openbscuser at gmail.com To: openbsc Subject: Testing an OpenBSC installation. Date: Thu, 12 Nov 2009 23:24:32 +0530 Hi, Your tutorial on getting started with Debian system is good. Once the installation is over, what tests would you suggest to know the system is ok ? Similarly, how would one ensure that the machine running OpenBSC is talking nice with the BTS ? N From openbscuser at gmail.com Fri Nov 13 18:50:30 2009 From: openbscuser at gmail.com (=?UTF-8?Q?=E0=B2=A8=E0=B2=BE=E0=B2=97=E0=B3=87=E0=B2=B6=E0=B3=8D?=) Date: Sat, 14 Nov 2009 00:20:30 +0530 Subject: Unable to do menuconfig. Message-ID: <1258138230.10090.4.camel@nsubrahm> Hi, I am following instruction from this page : http://openbsc.gnumonks.org/trac/wiki/Debian_Getting_Started When I do make menuconfig I get to the point until I have to select the mISDN modules. Firstly, I had to download the 2.6.31.6 kernel which is different as described in the page above. And, secondly, when I do select (based on the best 'guess'), there is no change at all ! I am forced to select 'Exit' - it does not proceed further. Is there anything you would like to suggest ? I am running minimal Ubuntu Linux (https://help.ubuntu.com/community/Installation/MinimalCD) as a guest OS using VirtualBox hosted on Ubuntu 9.10. N. From mailinglists at hellercom.de Sat Nov 14 16:21:09 2009 From: mailinglists at hellercom.de (Bjoern Heller) Date: Sat, 14 Nov 2009 17:21:09 +0100 Subject: nanoBTS transmit power Message-ID: <91F01427-C346-4072-88C4-FB37525600E0@hellercom.de> Hi, how do I configure the nanoBTS transmit power? regards Bj?rn - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Bj?rn Heller Jabber: tec at jabber.hellercom.de -------------- next part -------------- An HTML attachment was scrubbed... URL: From zecke at selfish.org Sat Nov 14 18:45:43 2009 From: zecke at selfish.org (Holger Freyther) Date: Sat, 14 Nov 2009 19:45:43 +0100 Subject: nanoBTS transmit power In-Reply-To: <91F01427-C346-4072-88C4-FB37525600E0@hellercom.de> References: <91F01427-C346-4072-88C4-FB37525600E0@hellercom.de> Message-ID: <200911141945.43688.zecke@selfish.org> On Saturday 14 November 2009 17:21:09 Bjoern Heller wrote: > Hi, > > how do I configure the nanoBTS transmit power? Good question. I think Dieter knows this best. We have two options that influence the transmit power. One is the power a mobile station should use to communicate with us ("ms max power") and then something I don't know ("max_power_red") but we do have links to the spec in the vty_interface.c z. From spaar at mirider.augusta.de Sat Nov 14 20:42:44 2009 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Sat, 14 Nov 2009 20:42:44 Subject: nanoBTS transmit power Message-ID: <4aff1644.mirider@mirider.augusta.de> Hello Holger, On Sat, 14 Nov 2009 19:45:43 +0100, "Holger Freyther" wrote: > > Good question. I think Dieter knows this best. We have two options that > influence the transmit power. One is the power a mobile station should use to > communicate with us ("ms max power") and then something I don't know > ("max_power_red") but we do have links to the spec in the vty_interface.c "max_power_red" is the power used by the BTS, it reduces the maximum power by a certain amount. Those are the results from a measurement I already posted a while ago to the list: nanoBTS 1800, ARCN 840, no voice/data traffic: NM_ATT_RF_MAXPOWR_R RF output 0 20 dBm 1 18 dBm 2 16 dBm 4 12 dBm 8 4.4 dBm 9 2.0 dBm 10 0.4 dBm 11 -1.6 dBm 12 -3.6 dBm Please be aware that the value "max_power_red" from the config file is divided by two to get NM_ATT_RF_MAXPOWR_R ("max_power_red" is the actual reduction in dB). Best regards, Dieter -- Dieter Spaar, Germany spaar at mirider.augusta.de From laforge at gnumonks.org Wed Nov 18 08:07:20 2009 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 18 Nov 2009 09:07:20 +0100 Subject: nanoBTS transmit power In-Reply-To: <4aff1644.mirider@mirider.augusta.de> References: <4aff1644.mirider@mirider.augusta.de> Message-ID: <20091118080719.GI3520@prithivi.gnumonks.org> Dear all, On Sat, Nov 14, 2009 at 08:42:44PM +0000, Dieter Spaar wrote: > Please be aware that the value "max_power_red" from the config file > is divided by two to get NM_ATT_RF_MAXPOWR_R ("max_power_red" is the > actual reduction in dB). correct. This is also documented in the wiki at http://openbsc.gnumonks.org/trac/wiki/bsc_hack_VTY -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From openbscuser at gmail.com Sat Nov 14 18:06:42 2009 From: openbscuser at gmail.com (=?UTF-8?Q?=E0=B2=A8=E0=B2=BE=E0=B2=97=E0=B3=87=E0=B2=B6=E0=B3=8D?=) Date: Sat, 14 Nov 2009 23:36:42 +0530 Subject: Unable to compile because of missing dbi/dbi.h Message-ID: <1258222002.24380.1.camel@nsubrahm> Hi, I am trying to compile the source code but, I am stuck with the dbi.h header file. Where can I get this include file so that I can successfully compile ? N. From zecke at selfish.org Sat Nov 14 18:42:44 2009 From: zecke at selfish.org (Holger Freyther) Date: Sat, 14 Nov 2009 19:42:44 +0100 Subject: Unable to compile because of missing dbi/dbi.h In-Reply-To: <1258222002.24380.1.camel@nsubrahm> References: <1258222002.24380.1.camel@nsubrahm> Message-ID: <200911141942.44636.zecke@selfish.org> On Saturday 14 November 2009 19:06:42 ?????? wrote: > Hi, > I am trying to compile the source code but, I am stuck with the dbi.h > header file. Where can I get this include file so that I can > successfully compile ? We are using libdbi. On Debian/Ubuntu the package is called libddbi0-dev. At runtime you will also need the dbi sqlite3 backend, again on Debian this is called libdbd-sqlite3... z. From vogelchr at vogel.cx Sat Nov 14 18:47:36 2009 From: vogelchr at vogel.cx (Christian Vogel) Date: Sat, 14 Nov 2009 19:47:36 +0100 Subject: Unable to compile because of missing dbi/dbi.h In-Reply-To: <1258222002.24380.1.camel@nsubrahm> References: <1258222002.24380.1.camel@nsubrahm> Message-ID: Hi. On Sat, 14 Nov 2009 19:06:42 +0100, ?????? wrote: > I am trying to compile the source code but, I am stuck with the dbi.h > header file. Where can I get this include file so that I can > successfully compile ? Have a look at http://bs11-abis.gnumonks.org/trac/wiki/Debian_Getting_Started You are missing the development headers for the dbi library (libdbi0-dev). If you are working with a different distribution, please search their package repositories for something similar. Chris From laforge at gnumonks.org Sun Nov 15 13:46:24 2009 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 15 Nov 2009 14:46:24 +0100 Subject: GPRS branch status update Message-ID: <20091115134624.GG23248@prithivi.gnumonks.org> Hi! I've applied a series of fixes and extensions to the GPRS branch, and would like to invited interested nanoBTS users to give it another try. Right now, I am getting fully through GPRS routing area update and attach request, i.e. the phones can fully register to the GPRS network. Minimal PDP context activation and deactivation has been implemented, i.e. the phone will send a ACTIVATE PDP CONTEXT REQUEST, and the network will simply ACK it. However, since the network does not add any IPCP options, the phone will typically DEACTIVATE the context immediately after that. Have fun, -- - 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 Mon Nov 16 09:16:53 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Mon, 16 Nov 2009 10:16:53 +0100 Subject: GPRS branch status update In-Reply-To: <20091115134624.GG23248@prithivi.gnumonks.org> References: <20091115134624.GG23248@prithivi.gnumonks.org> Message-ID: <866320f70911160116m27da860aga4af787ec16d9a37@mail.gmail.com> Hi, > I've applied a series of fixes and extensions to the GPRS branch, and > would like to invited interested nanoBTS users to give it another try. I gave it a go and got to the ACTIVATE PDP CONTEXT with few hacks : - Changed gsm48_gmm_authorize to make identity requests if it doesn't have everything it needs, and call it from gsm48_rx_gmm_att_req instead of making identity requests directly. - Remove the NM_ATT_IPACC_RLC_CFG_3 attr since my nanoBTS doesn't have EDGE - (and of course, set correct IPs in nanobts_attr_nsvc0 & ipac_gprs_send) The main problem I have currently is that both phones I use (android magic & iPhone 1G), seem to ignore most of the packets that are sent back. So for example, after a GMM ATTACH REQUEST a IDENTITY REQUEST is sent back, and for the first one, the phone answers, then a second IDENTITY REQUEST is sent (need both IMSI & IMEI and the phone did the initial attach request by TMSI ...) and there it's just ignored, no answer. The phone will just retry the ATTACH REQUEST . Same thing with RA LOCATION UPDATE, if I send REJECT with cause=implicit detach, it just retries the RA UPDATE instead of going to ATTACH REQUEST. And the list goes on, the ACTIVATE PDP CONTEXT ACCEPT has to be sent 4-5 times before the phone accept it. Does anyone have a clue what could cause that behavior ? Sylvain From laforge at gnumonks.org Mon Nov 16 16:21:18 2009 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 16 Nov 2009 17:21:18 +0100 Subject: GPRS branch status update In-Reply-To: <866320f70911160116m27da860aga4af787ec16d9a37@mail.gmail.com> References: <20091115134624.GG23248@prithivi.gnumonks.org> <866320f70911160116m27da860aga4af787ec16d9a37@mail.gmail.com> Message-ID: <20091116162118.GB21953@prithivi.gnumonks.org> Hi Sylvain, On Mon, Nov 16, 2009 at 10:16:53AM +0100, Sylvain Munaut wrote: > > I've applied a series of fixes and extensions to the GPRS branch, and > > would like to invited interested nanoBTS users to give it another try. > > I gave it a go and got to the ACTIVATE PDP CONTEXT with few hacks : > > - Changed gsm48_gmm_authorize to make identity requests if it doesn't > have everything it needs, and call > it from gsm48_rx_gmm_att_req instead of making identity requests directly. ok, that makes sense, and I believe this is the same as what we're doing in the non-GPRS mobility management case (location update procedure). Feel free to send a patch. > - Remove the NM_ATT_IPACC_RLC_CFG_3 attr since my nanoBTS doesn't have EDGE There is some way how to inquire the capabilities of the nanoBTS through ip.access specific 12.21 extensions. I must have seen it in their wireshark dissector but don't remember the details. As I'm not using EDGE at the moment anyway (we're not indicating it in the SI either), I think it is safe to simply remove RLC_CFG_3 completely for the time being. I am currently travelling and don't have the latest git version, so if you don't mind simply send a patch - this way I cannot easily forget about it. > - (and of course, set correct IPs in nanobts_attr_nsvc0 & ipac_gprs_send) yes, if you or anyone wants to remove those hardcoded parts and rather replace it with the BSC's IP address (e.g. getsockname on the OML connection), that would be great. > The main problem I have currently is that both phones I use (android > magic & iPhone 1G), seem to ignore most of the packets that are sent > back. that's strange. I suppose that means that those packets are somehow broken and ignored by either the BTS or the MS. Have you checked in wireshark how it looks like? If you decode UDP port 23000 packets as NSIP protocol, you will get a full decode of ns, bssgp llc and 04.08 Things to check is if the NSVCI/BVCI/TLLI of the response we send matches the TLLI of the request. Also interesting to see if the dissector detects some broken messages or if the data we send generally makes sense or not. > So for example, after a GMM ATTACH REQUEST a IDENTITY REQUEST is sent > back, and for the first one, the phone answers, then a second IDENTITY > REQUEST is sent (need both IMSI & IMEI and the phone did the initial > attach request by TMSI ...) and there it's just ignored, no answer. that's strange. I have so far tested wit Motorola EZX phones such as the A780, and that has worked. I didn't have time to test with any other phone and thus flavor of GPRS stack. > Same thing with RA LOCATION UPDATE, if I send REJECT with > cause=implicit detach, it just retries the RA UPDATE instead of going > to ATTACH REQUEST. And the list goes on, the ACTIVATE PDP CONTEXT > ACCEPT has to be sent 4-5 times before the phone accept it. ok, we're doing this wrong anyway. My assumption that we need to reject a RA update until we have seen an ATTACH request apparently was wrong. I still think it's illogical, but it seems we have to accept a RA UPDATE even if the phone is not ATTACHed and mark it implicitly as ATTACHed at that point. So feel free to play with the code and tell me what works for you[r phone] -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From mailinglists at hellercom.de Mon Nov 16 09:16:57 2009 From: mailinglists at hellercom.de (Bjoern Heller) Date: Mon, 16 Nov 2009 10:16:57 +0100 Subject: GPRS branch status update In-Reply-To: <20091115134624.GG23248@prithivi.gnumonks.org> References: <20091115134624.GG23248@prithivi.gnumonks.org> Message-ID: <8454B8AF-E86E-4B71-8C66-A3436AFEBC6A@hellercom.de> Will try it later today! Best Regards Bj?rn Heller Am 15.11.2009 um 14:46 schrieb Harald Welte : > Hi! > > I've applied a series of fixes and extensions to the GPRS branch, and > would like to invited interested nanoBTS users to give it another try. > > Right now, I am getting fully through GPRS routing area update and > attach > request, i.e. the phones can fully register to the GPRS network. > > Minimal PDP context activation and deactivation has been > implemented, i.e. > the phone will send a ACTIVATE PDP CONTEXT REQUEST, and the network > will > simply ACK it. However, since the network does not add any IPCP > options, > the phone will typically DEACTIVATE the context immediately after > that. > > Have fun, > > -- > - Harald Welte http://laforge.gnumonks.org/ > === > === > ====================================================================== > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 > Ch. A6) > From Andreas.Eversberg at versatel.de Mon Nov 16 17:52:29 2009 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Mon, 16 Nov 2009 18:52:29 +0100 Subject: patch: callref bugfix Message-ID: this patch will correct some callref behavior. if a message with an unknown callref is received, a release is sent to the other layer. if a release with an unknown callref is received, it is ignored. no message is sent, if the callref is already gone. diff --git a/openbsc/src/gsm_04_08.c b/openbsc/src/gsm_04_08.c index d6e161a..3f12546 100644 --- a/openbsc/src/gsm_04_08.c +++ b/openbsc/src/gsm_04_08.c @@ -1705,6 +1705,10 @@ static int mncc_recvmsg(struct gsm_network *net, struct gsm_trans *trans, { struct msgb *msg; + /* don't send message, if call is not associated anymore */ + if (!mncc->callref) + return 0; + if (trans) if (trans->lchan) DEBUGP(DCC, "(bts %d trx %d ts %d ti %x sub %s) " @@ -3242,10 +3246,12 @@ int mncc_send(struct gsm_network *net, int msg_type, void *arg) if (!trans) { struct gsm_subscriber *subscr; + if (msg_type == MNCC_REL_REQ) + return 0; /* drop */ if (msg_type != MNCC_SETUP_REQ) { DEBUGP(DCC, "(bts - trx - ts - ti -- sub %s) " "Received '%s' from MNCC with " - "unknown callref %d\n", data->called.number, + "unknown callref %x\n", data->called.number, get_mncc_name(msg_type), data->callref); /* Invalid call reference */ return mncc_release_ind(net, NULL, data->callref, diff --git a/openbsc/src/mncc.c b/openbsc/src/mncc.c index f62541c..1874750 100644 --- a/openbsc/src/mncc.c +++ b/openbsc/src/mncc.c @@ -301,8 +301,20 @@ int mncc_recv(struct gsm_network *net, int msg_type, void *arg) /* create callref, if setup is received */ if (!call) { - if (msg_type != MNCC_SETUP_IND) + if (msg_type == MNCC_REL_IND) return 0; /* drop */ + if (msg_type != MNCC_SETUP_IND) { + struct gsm_mncc rel; + + DEBUGP(DMNCC, "(call %x) Rejecting message %s with unknown ref.\n", + callref, get_mncc_name(msg_type)); + memset(&rel, 0, sizeof(struct gsm_mncc)); + rel.callref = callref; + mncc_set_cause(&rel, GSM48_CAUSE_LOC_PRN_S_LU, + GSM48_CC_CAUSE_INVAL_TRANS_ID); + mncc_send(net, MNCC_REL_REQ, &rel); + return 0; + } /* create call */ if (!(call = talloc_zero(tall_call_ctx, struct gsm_call))) { struct gsm_mncc rel; From zecke at selfish.org Wed Nov 18 19:53:10 2009 From: zecke at selfish.org (Holger Freyther) Date: Wed, 18 Nov 2009 20:53:10 +0100 Subject: patch: callref bugfix In-Reply-To: References: Message-ID: <200911182053.10840.zecke@selfish.org> On Monday 16 November 2009 18:52:29 Andreas.Eversberg wrote: > this patch will correct some callref behavior. > > if a message with an unknown callref is received, a release is sent to > the other layer. > if a release with an unknown callref is received, it is ignored. > no message is sent, if the callref is already gone. Great patch, the problem is that your mailer has line wrapped the patch and now I'm not able to apply it. Do you think you could either just send the patch as attachment, send it not line wrapped or maybe even give that git commit and git format-patch a try? regards holger From Andreas.Eversberg at versatel.de Mon Nov 16 17:52:31 2009 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Mon, 16 Nov 2009 18:52:31 +0100 Subject: patch: fix of paging result issue Message-ID: hi, one of my nokia phones 6310i: V 04.20 04-03-02 NPE-4 (c) NPM. when the subscriber is paged, the phone will answer with "CHREQ_T_PAG_R_ANY" value (ra=0x83). because the phone does not tell use what it wants, i must assume that there may be a need for a traffic channel. without this patch, the call will be made with wrong channel type: <0200> paging.c:113 Going to send paging commands: imsi: '262XXXXXXXXXXX' tmsi: '0x3044ea7a' <0010> abis_rsl.c:1179 Activating ARFCN(121) TS(0) SS(0) lctype SDCCH chan_nr=0x20 r=PAGING ra=0x83 can we figure out which subscriber did the channel request? if so, we can check what channel type is required. (we can look through the transactions and select the required channel type. if a transaction with higher rate is paging, we can assign this channel type.) any ideas? regards, andreas diff --git a/openbsc/src/gsm_04_08_utils.c b/openbsc/src/gsm_04_08_utils.c index 6ffb109..2c30d13 100644 --- a/openbsc/src/gsm_04_08_utils.c +++ b/openbsc/src/gsm_04_08_utils.c @@ -283,7 +283,7 @@ static const enum gsm_chan_t ctype_by_chreq[] = { [CHREQ_T_VOICE_CALL_TCH_H] = GSM_LCHAN_TCH_H, [CHREQ_T_DATA_CALL_TCH_H] = GSM_LCHAN_TCH_H, [CHREQ_T_LOCATION_UPD] = GSM_LCHAN_SDCCH, - [CHREQ_T_PAG_R_ANY] = GSM_LCHAN_SDCCH, + [CHREQ_T_PAG_R_ANY] = GSM_LCHAN_TCH_F, [CHREQ_T_PAG_R_TCH_F] = GSM_LCHAN_TCH_F, [CHREQ_T_PAG_R_TCH_FH] = GSM_LCHAN_TCH_F, }; From zecke at selfish.org Tue Nov 17 09:27:58 2009 From: zecke at selfish.org (Holger Freyther) Date: Tue, 17 Nov 2009 10:27:58 +0100 Subject: patch: fix of paging result issue In-Reply-To: References: Message-ID: <200911171027.58617.zecke@selfish.org> On Monday 16 November 2009 18:52:31 Andreas.Eversberg wrote: > <0200> paging.c:113 Going to send paging commands: imsi: > '262XXXXXXXXXXX' tmsi: '0x3044ea7a' > <0010> abis_rsl.c:1179 Activating ARFCN(121) TS(0) SS(0) lctype SDCCH > chan_nr=0x20 r=PAGING ra=0x83 > > can we figure out which subscriber did the channel request? We can not on this level. This a tricky question. So the MS is asking for any channel and we were conservative and gave it a SDCCH and then the chan modify for the voice call will fail. The options I'm seeing for this are: - Assign the SDCCH and don't do very early assignment... E.g. change the mncc code to do the assignment command for a tch... - Assign the TCH even if we don't need that much bandwidth... I'm not sure if we want to support both very early and early assignment in the code base or not... I'm just leaving this to harald to make the call. z. From Andreas.Eversberg at versatel.de Mon Nov 16 17:52:31 2009 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Mon, 16 Nov 2009 18:52:31 +0100 Subject: patch: paging timer configuration Message-ID: this patch will add paging timer configuration to network. diff --git a/openbsc/include/openbsc/gsm_data.h b/openbsc/include/openbsc/gsm_data.h index 3040525..954fd60 100644 --- a/openbsc/include/openbsc/gsm_data.h +++ b/openbsc/include/openbsc/gsm_data.h @@ -283,7 +283,7 @@ struct gsm_paging_request { gsm_cbfn *cbfn; void *cbfn_param; }; -#define T3113_VALUE 60, 0 +#define T3113_VALUE 60 /* * This keeps track of the paging status of one BTS. It @@ -410,6 +410,7 @@ struct gsm_network { char *name_short; enum gsm_auth_policy auth_policy; int a5_encryption; + int tout_3113; /* layer 4 */ int (*mncc_recv) (struct gsm_network *net, int msg_type, void *arg); diff --git a/openbsc/src/paging.c b/openbsc/src/paging.c index 184ea0f..b542273 100644 --- a/openbsc/src/paging.c +++ b/openbsc/src/paging.c @@ -235,7 +235,7 @@ static int _paging_request(struct gsm_bts *bts, struct gsm_subscriber *subscr, req->cbfn_param = data; req->T3113.cb = paging_T3113_expired; req->T3113.data = req; - bsc_schedule_timer(&req->T3113, T3113_VALUE); + bsc_schedule_timer(&req->T3113, bts->network->tout_3113 ? : T3113_VALUE, 0); llist_add_tail(&req->entry, &bts_entry->pending_requests); if (!bsc_timer_pending(&bts_entry->work_timer)) diff --git a/openbsc/src/vty_interface.c b/openbsc/src/vty_interface.c index 8dec579..95767bc 100644 --- a/openbsc/src/vty_interface.c +++ b/openbsc/src/vty_interface.c @@ -274,6 +274,10 @@ static int config_write_net(struct vty *vty) vty_out(vty, " long name %s%s", gsmnet->name_long, VTY_NEWLINE); vty_out(vty, " auth policy %s%s", gsm_auth_policy_name(gsmnet->auth_policy), VTY_NEWLINE); vty_out(vty, " encryption a5 %u%s", gsmnet->a5_encryption, VTY_NEWLINE); + if (gsmnet->tout_3113) + vty_out(vty, " paging timeout %u%s", gsmnet->tout_3113, VTY_NEWLINE); + else + vty_out(vty, " paging timeout default%s", VTY_NEWLINE); return CMD_SUCCESS; } @@ -793,6 +797,24 @@ DEFUN(cfg_net_encryption, return CMD_SUCCESS; } +DEFUN(cfg_net_paging_timeout, + cfg_net_paging_timeout_cmd, + "paging timeout (<1-65535>|default)", + "Set the paging timeout value (T3113) for this network\n") +{ + int tout = atoi(argv[0]); + + if (tout < 0 || tout > 0xffff) { + vty_out(vty, "%% Value %d is not in the valid range (1-65535 or 'default')%s", + tout, VTY_NEWLINE); + return CMD_WARNING; + } + + gsmnet->tout_3113 = tout; + + return CMD_SUCCESS; +} + /* per-BTS configuration */ DEFUN(cfg_bts, cfg_bts_cmd, @@ -1232,6 +1254,7 @@ int bsc_vty_init(struct gsm_network *net) install_element(GSMNET_NODE, &cfg_net_name_long_cmd); install_element(GSMNET_NODE, &cfg_net_auth_policy_cmd); install_element(GSMNET_NODE, &cfg_net_encryption_cmd); + install_element(GSMNET_NODE, &cfg_net_paging_timeout_cmd); install_element(GSMNET_NODE, &cfg_bts_cmd); install_node(&bts_node, config_write_bts); From laforge at gnumonks.org Fri Nov 20 09:25:27 2009 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 20 Nov 2009 10:25:27 +0100 Subject: patch: paging timer configuration In-Reply-To: References: Message-ID: <20091120092527.GL13105@prithivi.gnumonks.org> On Mon, Nov 16, 2009 at 06:52:31PM +0100, Andreas.Eversberg wrote: > this patch will add paging timer configuration to network. sorry, the patch will not apply, it seems like your mail program has introduced extra linefeeds and/or whitespace changes :( I'm not as picky as some kernel folks, I don't mind if you send patches as attachments if that's easier for you. Can you please re-send the patches without the linefeed/whitepsace issues? -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From zecke at selfish.org Fri Nov 20 18:55:35 2009 From: zecke at selfish.org (Holger Freyther) Date: Fri, 20 Nov 2009 19:55:35 +0100 Subject: patch: paging timer configuration In-Reply-To: <20091120092527.GL13105@prithivi.gnumonks.org> References: <20091120092527.GL13105@prithivi.gnumonks.org> Message-ID: <200911201955.36057.zecke@selfish.org> On Friday 20 November 2009 10:25:27 Harald Welte wrote: > On Mon, Nov 16, 2009 at 06:52:31PM +0100, Andreas.Eversberg wrote: > > this patch will add paging timer configuration to network. > > sorry, the patch will not apply, it seems like your mail program > has introduced extra linefeeds and/or whitespace changes :( > > I'm not as picky as some kernel folks, I don't mind if you send patches as > attachments if that's easier for you. > > Can you please re-send the patches without the linefeed/whitepsace issues? I will redo the patch and also add some more timers to the config. I will also not add a default (but patch the *.cfg files). regards holger From zecke at selfish.org Mon Nov 23 10:41:48 2009 From: zecke at selfish.org (Holger Freyther) Date: Mon, 23 Nov 2009 11:41:48 +0100 Subject: patch: paging timer configuration In-Reply-To: <200911201955.36057.zecke@selfish.org> References: <20091120092527.GL13105@prithivi.gnumonks.org> <200911201955.36057.zecke@selfish.org> Message-ID: <200911231141.48910.zecke@selfish.org> On Friday 20 November 2009 19:55:35 Holger Freyther wrote: > I will redo the patch and also add some more timers to the config. I will > also not add a default (but patch the *.cfg files). I have added this timer, the 3101 timer and a bunch of timers that we are not using yet (but that I will have to use) as well. I have also updated existing config files, you will need to add: network timer tXXXX value in your network section, copy the values from the four cfg files we have in the repository. z. From Andreas.Eversberg at versatel.de Mon Nov 16 17:52:31 2009 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Mon, 16 Nov 2009 18:52:31 +0100 Subject: patch: fix of double free bug Message-ID: this patch fixes double free of paging request. the function paging_T3113_expired() must call paging_remove_request() first. then the cbfn may be called. the cbfn function cannot eventually remove the paging request again, because it is not in the list anymore. the result of paging timeout was a crash. diff --git a/openbsc/src/paging.c b/openbsc/src/paging.c index 5a9643c..164a08b 100644 --- a/openbsc/src/paging.c +++ b/openbsc/src/paging.c @@ -224,11 +243,13 @@ static void paging_T3113_expired(void *data) sig_data.bts = req->bts; sig_data.lchan = NULL; + /* must be destroyed before calling cbfn, to prevent double free */ + paging_remove_request(&req->bts->paging, req); + dispatch_signal(SS_PAGING, S_PAGING_COMPLETED, &sig_data); if (req->cbfn) req->cbfn(GSM_HOOK_RR_PAGING, GSM_PAGING_EXPIRED, NULL, NULL, req->cbfn_param); - paging_remove_request(&req->bts->paging, req); } static int _paging_request(struct gsm_bts *bts, struct gsm_subscriber *subscr, From zecke at selfish.org Tue Nov 17 08:58:45 2009 From: zecke at selfish.org (Holger Freyther) Date: Tue, 17 Nov 2009 09:58:45 +0100 Subject: patch: fix of double free bug In-Reply-To: References: Message-ID: <200911170958.45583.zecke@selfish.org> On Monday 16 November 2009 18:52:31 Andreas.Eversberg wrote: > this patch fixes double free of paging request. > > the function paging_T3113_expired() must call paging_remove_request() > first. then the cbfn may be called. the cbfn function cannot eventually > remove the paging request again, because it is not in the list anymore. > > the result of paging timeout was a crash. > > diff --git a/openbsc/src/paging.c b/openbsc/src/paging.c > index 5a9643c..164a08b 100644 > --- a/openbsc/src/paging.c > +++ b/openbsc/src/paging.c > @@ -224,11 +243,13 @@ static void paging_T3113_expired(void *data) > sig_data.bts = req->bts; > sig_data.lchan = NULL; > > + /* must be destroyed before calling cbfn, to prevent double free > */ > + paging_remove_request(&req->bts->paging, req); > + > dispatch_signal(SS_PAGING, S_PAGING_COMPLETED, &sig_data); > if (req->cbfn) > req->cbfn(GSM_HOOK_RR_PAGING, GSM_PAGING_EXPIRED, NULL, > NULL, > req->cbfn_param); Ack, this has one issue though... "req" now points to freed memory. We will need to put a copy of the callback and the data somewhere before calling the callback. I'm doing this right now. z. From laforge at gnumonks.org Fri Nov 20 10:22:00 2009 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 20 Nov 2009 11:22:00 +0100 Subject: patch: fix of double free bug In-Reply-To: References: Message-ID: <20091120102200.GM13105@prithivi.gnumonks.org> On Mon, Nov 16, 2009 at 06:52:31PM +0100, Andreas.Eversberg wrote: > this patch fixes double free of paging request. thanks for your patch, seems like it was already applied... -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From Andreas.Eversberg at versatel.de Mon Nov 16 17:52:31 2009 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Mon, 16 Nov 2009 18:52:31 +0100 Subject: patch: subscriber usage debug Message-ID: this patch will give more detailed debug information about subscriber usage. when subcriber structure is allocated, it will be shown on debug output. subscr_get() and subscr_put() debug will also show the calling function for better understanding. diff --git a/openbsc/include/openbsc/gsm_subscriber.h b/openbsc/include/openbsc/gsm_subscriber.h index d612ed5..02e193a 100644 --- a/openbsc/include/openbsc/gsm_subscriber.h +++ b/openbsc/include/openbsc/gsm_subscriber.h @@ -71,8 +71,10 @@ enum gsm_subscriber_update_reason { GSM_SUBSCRIBER_UPDATE_EQUIPMENT, }; -struct gsm_subscriber *subscr_get(struct gsm_subscriber *subscr); -struct gsm_subscriber *subscr_put(struct gsm_subscriber *subscr); +#define subscr_get(subscr) _subscr_get(__FUNCTION__, subscr) +struct gsm_subscriber *_subscr_get(const char *func, struct gsm_subscriber *subscr); +#define subscr_put(subscr) _subscr_put(__FUNCTION__, subscr) +struct gsm_subscriber *_subscr_put(const char *func, struct gsm_subscriber *subscr); struct gsm_subscriber *subscr_get_by_tmsi(struct gsm_network *net, u_int32_t tmsi); struct gsm_subscriber *subscr_get_by_imsi(struct gsm_network *net, @@ -87,7 +89,8 @@ void subscr_get_channel(struct gsm_subscriber *subscr, int type, gsm_cbfn *cbfn, void *param); /* internal */ -struct gsm_subscriber *subscr_alloc(void); +#define subscr_alloc() _subscr_alloc(__FUNCTION__) +struct gsm_subscriber *_subscr_alloc(const char *func); extern struct llist_head active_subscribers; #endif /* _GSM_SUBSCR_H */ diff --git a/openbsc/src/gsm_subscriber_base.c b/openbsc/src/gsm_subscriber_base.c index bcf55d1..7fe2f21 100644 --- a/openbsc/src/gsm_subscriber_base.c +++ b/openbsc/src/gsm_subscriber_base.c @@ -113,7 +113,7 @@ static void subscr_send_paging_request(struct gsm_subscriber *subscr) } } -struct gsm_subscriber *subscr_alloc(void) +struct gsm_subscriber *_subscr_alloc(const char *func) { struct gsm_subscriber *s; @@ -123,6 +123,8 @@ struct gsm_subscriber *subscr_alloc(void) memset(s, 0, sizeof(*s)); llist_add_tail(&s->entry, &active_subscribers); + DEBUGP(DCC, "(from %s) new subscr allocated, setting usage to: 1\n", + func); s->use_count = 1; s->tmsi = GSM_RESERVED_TMSI; @@ -137,19 +139,19 @@ static void subscr_free(struct gsm_subscriber *subscr) talloc_free(subscr); } -struct gsm_subscriber *subscr_get(struct gsm_subscriber *subscr) +struct gsm_subscriber *_subscr_get(const char *func, struct gsm_subscriber *subscr) { subscr->use_count++; - DEBUGP(DCC, "subscr %s usage increases usage to: %d\n", - subscr->extension, subscr->use_count); + DEBUGP(DCC, "(from %s) subscr %s usage increases usage to: %d\n", + func, subscr->extension, subscr->use_count); return subscr; } -struct gsm_subscriber *subscr_put(struct gsm_subscriber *subscr) +struct gsm_subscriber *_subscr_put(const char *func, struct gsm_subscriber *subscr) { subscr->use_count--; - DEBUGP(DCC, "subscr %s usage decreased usage to: %d\n", - subscr->extension, subscr->use_count); + DEBUGP(DCC, "(from %s) subscr %s usage decreased usage to: %d\n", + func, subscr->extension, subscr->use_count); if (subscr->use_count <= 0) subscr_free(subscr); return NULL; From zecke at selfish.org Tue Nov 17 08:43:44 2009 From: zecke at selfish.org (Holger Freyther) Date: Tue, 17 Nov 2009 09:43:44 +0100 Subject: patch: subscriber usage debug In-Reply-To: References: Message-ID: <200911170943.44834.zecke@selfish.org> On Monday 16 November 2009 18:52:31 Andreas.Eversberg wrote: > this patch will give more detailed debug information about subscriber > usage. > > when subcriber structure is allocated, it will be shown on debug output. > subscr_get() and subscr_put() debug will also show the calling function > for better understanding. I don't like this one. It is something one can do with a gdb script (help commands), use the backtrace function and print the first stack, or in the future with things like systemtap. regards holger From Andreas.Eversberg at versatel.de Mon Nov 16 17:52:32 2009 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Mon, 16 Nov 2009 18:52:32 +0100 Subject: patch: fix of compiler warnings Message-ID: this patch fixes (not all) compiler warnings. diff --git a/openbsc/include/openbsc/talloc.h b/openbsc/include/openbsc/talloc.h index f7f7643..cd7ca17 100644 --- a/openbsc/include/openbsc/talloc.h +++ b/openbsc/include/openbsc/talloc.h @@ -189,4 +189,8 @@ char *talloc_asprintf_append_buffer(char *s, const char *fmt, ...) PRINTF_ATTRIB void talloc_set_abort_fn(void (*abort_fn)(const char *reason)); +void talloc_ctx_init(void); +void on_dso_load_token(void); +void on_dso_load_rrlp(void); + #endif diff --git a/openbsc/src/bsc_init.c b/openbsc/src/bsc_init.c index 815fe2b..3b451b1 100644 --- a/openbsc/src/bsc_init.c +++ b/openbsc/src/bsc_init.c @@ -433,8 +433,8 @@ int nm_state_event(enum nm_evt evt, u_int8_t obj_class, void *obj, static int sw_activ_rep(struct msgb *mb) { struct abis_om_fom_hdr *foh = msgb_l3(mb); - struct gsm_bts *bts = mb->trx->bts; - struct gsm_bts_trx *trx = gsm_bts_trx_num(bts, foh->obj_inst.trx_nr); +// struct gsm_bts *bts = mb->trx->bts; +// struct gsm_bts_trx *trx = gsm_bts_trx_num(bts, foh->obj_inst.trx_nr); switch (foh->obj_class) { diff --git a/openbsc/src/db.c b/openbsc/src/db.c index b86348c..59dac2c 100644 --- a/openbsc/src/db.c +++ b/openbsc/src/db.c @@ -265,7 +265,7 @@ static int get_equipment_by_subscr(struct gsm_subscriber *subscr) { dbi_result result; const char *string; - unsigned int cm1; + unsigned char cm1; const unsigned char *cm2, *cm3; struct gsm_equipment *equip = &subscr->equipment; diff --git a/openbsc/src/rtp_proxy.c b/openbsc/src/rtp_proxy.c index b92526e..42c2d15 100644 --- a/openbsc/src/rtp_proxy.c +++ b/openbsc/src/rtp_proxy.c @@ -676,7 +676,7 @@ int rtp_socket_proxy(struct rtp_socket *this, struct rtp_socket *other) int rtp_socket_upstream(struct rtp_socket *this, struct gsm_network *net, u_int32_t callref) { DEBUGP(DMUX, "rtp_socket_proxy(this=%p, callref=%lu)\n", - this, callref); + this, (unsigned long)callref); if (callref) { this->rx_action = RTP_RECV_UPSTREAM; diff --git a/openbsc/src/vty_interface.c b/openbsc/src/vty_interface.c index d623b3d..e3de43a 100644 --- a/openbsc/src/vty_interface.c +++ b/openbsc/src/vty_interface.c @@ -36,6 +36,8 @@ #include #include +int bsc_vty_init_extra(struct gsm_network *net); + static struct gsm_network *gsmnet; struct cmd_node net_node = { @@ -624,7 +626,7 @@ DEFUN(show_e1ts, "show e1_timeslot [line_nr] [ts_nr]", SHOW_STR "Display information about a E1 timeslot\n") { - struct e1inp_line *line; + struct e1inp_line *line = NULL; struct e1inp_ts *ts; int ts_nr; @@ -638,12 +640,14 @@ DEFUN(show_e1ts, return CMD_SUCCESS; } if (argc >= 1) { - int num = atoi(argv[0]); + int num = atoi(argv[0]), found = 0; llist_for_each_entry(line, &e1inp_line_list, list) { - if (line->num == num) + if (line->num == num) { + found = 1; break; + } } - if (!line || line->num != num) { + if (found < 0) { vty_out(vty, "E1 line %s is invalid%s", argv[0], VTY_NEWLINE); return CMD_WARNING; diff --git a/openbsc/tests/sms/sms_test.c b/openbsc/tests/sms/sms_test.c index fa09636..2ce2cc6 100644 --- a/openbsc/tests/sms/sms_test.c +++ b/openbsc/tests/sms/sms_test.c @@ -24,6 +24,7 @@ #include #include #include +#include #include int main(int argc, char** argv) diff --git a/openbsc/tests/timer/timer_test.c b/openbsc/tests/timer/timer_test.c index 26fcbc9..1515652 100644 --- a/openbsc/tests/timer/timer_test.c +++ b/openbsc/tests/timer/timer_test.c @@ -26,17 +26,17 @@ static void timer_fired(unsigned long data); static struct timer_list timer_one = { - .cb = timer_fired, + .cb = (void *)timer_fired, .data = (void*)1, }; static struct timer_list timer_two = { - .cb = timer_fired, + .cb = (void *)timer_fired, .data = (void*)2, }; static struct timer_list timer_three = { - .cb = timer_fired, + .cb = (void *)timer_fired, .data = (void*)3, }; From Andreas.Eversberg at versatel.de Tue Nov 17 08:39:26 2009 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Tue, 17 Nov 2009 09:39:26 +0100 Subject: AW: patch: fix of compiler warnings Message-ID: there is an error in this patch: + if (found < 0) { this is correct: + if (!found) { From zecke at selfish.org Tue Nov 17 09:19:55 2009 From: zecke at selfish.org (Holger Freyther) Date: Tue, 17 Nov 2009 10:19:55 +0100 Subject: patch: fix of compiler warnings In-Reply-To: References: Message-ID: <200911171019.56387.zecke@selfish.org> On Monday 16 November 2009 18:52:32 Andreas.Eversberg wrote: > diff --git a/openbsc/src/bsc_init.c b/openbsc/src/bsc_init.c > index 815fe2b..3b451b1 100644 > --- a/openbsc/src/bsc_init.c > +++ b/openbsc/src/bsc_init.c > @@ -433,8 +433,8 @@ int nm_state_event(enum nm_evt evt, u_int8_t > obj_class, void *obj, > static int sw_activ_rep(struct msgb *mb) > { > struct abis_om_fom_hdr *foh = msgb_l3(mb); > - struct gsm_bts *bts = mb->trx->bts; > - struct gsm_bts_trx *trx = gsm_bts_trx_num(bts, > foh->obj_inst.trx_nr); > +// struct gsm_bts *bts = mb->trx->bts; > +// struct gsm_bts_trx *trx = gsm_bts_trx_num(bts, > foh->obj_inst.trx_nr); was this intentional? Is the warning that these are unused? In this case we will just nuke the variable declaration. From laforge at gnumonks.org Fri Nov 20 13:11:56 2009 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 20 Nov 2009 14:11:56 +0100 Subject: patch: fix of compiler warnings In-Reply-To: <200911171019.56387.zecke@selfish.org> References: <200911171019.56387.zecke@selfish.org> Message-ID: <20091120131156.GR13105@prithivi.gnumonks.org> On Tue, Nov 17, 2009 at 10:19:55AM +0100, Holger Freyther wrote: > On Monday 16 November 2009 18:52:32 Andreas.Eversberg wrote: > > > diff --git a/openbsc/src/bsc_init.c b/openbsc/src/bsc_init.c > > index 815fe2b..3b451b1 100644 > > --- a/openbsc/src/bsc_init.c > > +++ b/openbsc/src/bsc_init.c > > @@ -433,8 +433,8 @@ int nm_state_event(enum nm_evt evt, u_int8_t > > obj_class, void *obj, > > static int sw_activ_rep(struct msgb *mb) > > { > > struct abis_om_fom_hdr *foh = msgb_l3(mb); > > - struct gsm_bts *bts = mb->trx->bts; > > - struct gsm_bts_trx *trx = gsm_bts_trx_num(bts, > > foh->obj_inst.trx_nr); > > +// struct gsm_bts *bts = mb->trx->bts; > > +// struct gsm_bts_trx *trx = gsm_bts_trx_num(bts, > > foh->obj_inst.trx_nr); > > was this intentional? Is the warning that these are unused? In this case we > will just nuke the variable declaration. they are still there to remind me that we should switch back to move some of the initialization into the software activate report (see the other mail) -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From Andreas.Eversberg at versatel.de Tue Nov 17 10:48:35 2009 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Tue, 17 Nov 2009 11:48:35 +0100 Subject: AW: patch: fix of compiler warnings Message-ID: i am not sure, if the variables bts and trx will be used in the future, so i left them as comments. -----Urspr?ngliche Nachricht----- Von: openbsc-bounces at lists.gnumonks.org [mailto:openbsc-bounces at lists.gnumonks.org] Im Auftrag von Holger Freyther Gesendet: Dienstag, 17. November 2009 10:20 An: openbsc at lists.gnumonks.org Betreff: Re: patch: fix of compiler warnings On Monday 16 November 2009 18:52:32 Andreas.Eversberg wrote: > diff --git a/openbsc/src/bsc_init.c b/openbsc/src/bsc_init.c > index 815fe2b..3b451b1 100644 > --- a/openbsc/src/bsc_init.c > +++ b/openbsc/src/bsc_init.c > @@ -433,8 +433,8 @@ int nm_state_event(enum nm_evt evt, u_int8_t > obj_class, void *obj, > static int sw_activ_rep(struct msgb *mb) > { > struct abis_om_fom_hdr *foh = msgb_l3(mb); > - struct gsm_bts *bts = mb->trx->bts; > - struct gsm_bts_trx *trx = gsm_bts_trx_num(bts, > foh->obj_inst.trx_nr); > +// struct gsm_bts *bts = mb->trx->bts; > +// struct gsm_bts_trx *trx = gsm_bts_trx_num(bts, > foh->obj_inst.trx_nr); was this intentional? Is the warning that these are unused? In this case we will just nuke the variable declaration. From Andreas.Eversberg at versatel.de Mon Nov 16 17:52:32 2009 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Mon, 16 Nov 2009 18:52:32 +0100 Subject: patch: fix of configuration file generation Message-ID: this patches fixes the generation of the config file. after saving of configuration, no location update was possible anymore. it is self explaining... diff --git a/openbsc/src/vty_interface.c b/openbsc/src/vty_interface.c index 9aa9706..c6e60c0 100644 --- a/openbsc/src/vty_interface.c +++ b/openbsc/src/vty_interface.c @@ -784,7 +784,7 @@ DEFUN(cfg_net_encryption, "encryption a5 (0|1|2)", "Enable or disable encryption (A5) for this network\n") { - gsmnet->auth_policy = atoi(argv[0]); + gsmnet->a5_encryption = atoi(argv[0]); return CMD_SUCCESS; } From zecke at selfish.org Tue Nov 17 08:52:05 2009 From: zecke at selfish.org (Holger Freyther) Date: Tue, 17 Nov 2009 09:52:05 +0100 Subject: patch: fix of configuration file generation In-Reply-To: References: Message-ID: <200911170952.05833.zecke@selfish.org> On Monday 16 November 2009 18:52:32 you wrote: > this patches fixes the generation of the config file. > > after saving of configuration, no location update was possible anymore. Great patches and I will apply most of them right now. I have one general question though. Do you think you could use "git commit" and send the result of "git format-patch"? This would suit my laziness a lot more as I could just apply patches out of my mailbox with "git am" :) thanks From Andreas.Eversberg at versatel.de Mon Nov 16 17:52:37 2009 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Mon, 16 Nov 2009 18:52:37 +0100 Subject: tests with subscriber usage Message-ID: hi, i did may tests with the "holger/subscr-ref-handling" branch. i had no subscriber usage leak within may hours of testing. about hunded calls were made with many out-of-range failures, hold/retrieve, and battery removal during call. at the end, all subscribers usage returned back to 0. i did not test SMS, just location updates and voice calls. regards, andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: From zecke at selfish.org Tue Nov 17 08:44:46 2009 From: zecke at selfish.org (Holger Freyther) Date: Tue, 17 Nov 2009 09:44:46 +0100 Subject: tests with subscriber usage In-Reply-To: References: Message-ID: <200911170944.47071.zecke@selfish.org> On Monday 16 November 2009 18:52:37 Andreas.Eversberg wrote: > hi, > > i did may tests with the "holger/subscr-ref-handling" branch. i had no > subscriber usage leak within may hours of testing. about hunded calls > were made with many out-of-range failures, hold/retrieve, and battery > removal during call. at the end, all subscribers usage returned back to > 0. > > i did not test SMS, just location updates and voice calls. Thanks, Harald has cherry-picked the one/two leak fixes to master already. I assume we will not see any subscriber leaks on the 26c3.. regards holger From stefreak at stefreak.de Tue Nov 17 18:30:39 2009 From: stefreak at stefreak.de (Steffen 'stefreak' Neubauer) Date: Tue, 17 Nov 2009 19:30:39 +0100 Subject: [PATCH] Implement TP-VPF-ENHANCED Message-ID: <20091117193039.5f983120@stefreak.de> Hello :) Now I've implemented the TP-VPF-ENHANCED. To achieve that I added some goto-stuff - i hope that's ok. I think it makes sense here. It's again untested, but compiles fine. I'm working at the moment on a way to test SMS-PDU decoding. If that's easier you can simply merge the branch tp-vp from git://github.com/stefreak/openbsc.git :) The patch is attached. Greetings, Steffen -------------- next part -------------- A non-text attachment was scrubbed... Name: patch.diff Type: text/x-patch Size: 3392 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From zecke at selfish.org Tue Nov 17 18:44:18 2009 From: zecke at selfish.org (Holger Freyther) Date: Tue, 17 Nov 2009 19:44:18 +0100 Subject: [PATCH] Implement TP-VPF-ENHANCED In-Reply-To: <20091117193039.5f983120@stefreak.de> References: <20091117193039.5f983120@stefreak.de> Message-ID: <200911171944.18175.zecke@selfish.org> On Tuesday 17 November 2009 19:30:39 Steffen 'stefreak' Neubauer wrote: > Hello :) > > Now I've implemented the TP-VPF-ENHANCED. To achieve that I added some > goto-stuff - i hope that's ok. I think it makes sense here. I think it is one of the cases where a function call makes more sense? From stefreak at stefreak.de Tue Nov 17 19:02:13 2009 From: stefreak at stefreak.de (Steffen 'stefreak' Neubauer) Date: Tue, 17 Nov 2009 20:02:13 +0100 Subject: [PATCH] Implement TP-VPF-ENHANCED In-Reply-To: <200911171944.18175.zecke@selfish.org> References: <20091117193039.5f983120@stefreak.de> <200911171944.18175.zecke@selfish.org> Message-ID: <20091117200213.1a9bbf51@stefreak.de> On Tue, 17 Nov 2009 19:44:18 +0100 Holger Freyther wrote: > I think it is one of the cases where a function call makes more sense? Hmm, really? All this stuff is only needed (as far as i know, of course ;)) for the validity-period decoding - nowhere else. Would you really put all those small VPF-implementations into their own functions? At the moment only the service centre time stamp decoding has it's own function because it's needed elsewhere. Isn't it clear enough with 'goto'? Greetings, Steffen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From zecke at selfish.org Wed Nov 18 08:43:48 2009 From: zecke at selfish.org (Holger Freyther) Date: Wed, 18 Nov 2009 09:43:48 +0100 Subject: [PATCH] Implement TP-VPF-ENHANCED In-Reply-To: <20091117200213.1a9bbf51@stefreak.de> References: <20091117193039.5f983120@stefreak.de> <200911171944.18175.zecke@selfish.org> <20091117200213.1a9bbf51@stefreak.de> Message-ID: <200911180943.49609.zecke@selfish.org> On Tuesday 17 November 2009 20:02:13 Steffen 'stefreak' Neubauer wrote: > On Tue, 17 Nov 2009 19:44:18 +0100 > > Holger Freyther wrote: > > I think it is one of the cases where a function call makes more sense? > > Hmm, really? All this stuff is only needed (as far as i know, of > course ;)) for the validity-period decoding - nowhere else. Would you > really put all those small VPF-implementations into their own > functions? At the moment only the service centre time stamp decoding > has it's own function because it's needed elsewhere. > Isn't it clear enough with 'goto'? Yes, I would put all these into static methods... the compiler will inline them for you. The problem with this amount of gotos is it is really hard to understand which ways you are jumping. E.g. within "enhanced" you will do a backward jump. The problem with that it is very hard to make sure that your jumping will end... if/else if and function calls are much easier to read. holger From stefreak at stefreak.de Wed Nov 18 17:29:07 2009 From: stefreak at stefreak.de (Steffen 'stefreak' Neubauer) Date: Wed, 18 Nov 2009 18:29:07 +0100 Subject: [PATCH] Implement TP-VPF-ENHANCED In-Reply-To: <200911180943.49609.zecke@selfish.org> References: <20091117193039.5f983120@stefreak.de> <200911171944.18175.zecke@selfish.org> <20091117200213.1a9bbf51@stefreak.de> <200911180943.49609.zecke@selfish.org> Message-ID: <20091118182907.7de4f10d@stefreak.de> On Wed, 18 Nov 2009 09:43:48 +0100 Holger Freyther wrote: > Yes, I would put all these into static methods... the compiler will > inline them for you. The problem with this amount of gotos is it is > really hard to understand which ways you are jumping. E.g. within > "enhanced" you will do a backward jump. The problem with that it is > very hard to make sure that your jumping will end... if/else if and > function calls are much easier to read. Okay, Thank You for your comments! The new patch is attached. Again, If that's easier you can simply merge my tp-vp branch on github. Thank You and Greetings, Steffen -------------- next part -------------- A non-text attachment was scrubbed... Name: patch.diff Type: text/x-patch Size: 7374 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From stefreak at stefreak.de Wed Nov 25 18:20:04 2009 From: stefreak at stefreak.de (Steffen 'stefreak' Neubauer) Date: Wed, 25 Nov 2009 19:20:04 +0100 Subject: [PATCH] Implement TP-VPF-ENHANCED In-Reply-To: <20091118182907.7de4f10d@stefreak.de> References: <20091117193039.5f983120@stefreak.de> <200911171944.18175.zecke@selfish.org> <20091117200213.1a9bbf51@stefreak.de> <200911180943.49609.zecke@selfish.org> <20091118182907.7de4f10d@stefreak.de> Message-ID: <20091125192004.1d713c95@stefreak> How is it? Won't someone apply the patch? Thank You, Steffen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From zecke at selfish.org Thu Nov 26 01:50:41 2009 From: zecke at selfish.org (Holger Freyther) Date: Thu, 26 Nov 2009 02:50:41 +0100 Subject: [PATCH] Implement TP-VPF-ENHANCED In-Reply-To: <20091125192004.1d713c95@stefreak> References: <20091117193039.5f983120@stefreak.de> <20091118182907.7de4f10d@stefreak.de> <20091125192004.1d713c95@stefreak> Message-ID: <200911260250.42210.zecke@selfish.org> On Wednesday 25 November 2009 19:20:04 Steffen 'stefreak' Neubauer wrote: > How is it? Won't someone apply the patch? I'm on the road, and I think Harald is only back from Vienna and soon flying to India as well... give us some time. z. From laforge at gnumonks.org Thu Nov 26 11:29:53 2009 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 26 Nov 2009 12:29:53 +0100 Subject: [PATCH] Implement TP-VPF-ENHANCED In-Reply-To: <20091118182907.7de4f10d@stefreak.de> References: <20091117193039.5f983120@stefreak.de> <200911171944.18175.zecke@selfish.org> <20091117200213.1a9bbf51@stefreak.de> <200911180943.49609.zecke@selfish.org> <20091118182907.7de4f10d@stefreak.de> Message-ID: <20091126112953.GB24517@prithivi.gnumonks.org> Thanks, applied your patch for VPF_ENHANCED. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From bouchtaoui at gmail.com Wed Nov 18 08:27:45 2009 From: bouchtaoui at gmail.com (Nordin) Date: Wed, 18 Nov 2009 09:27:45 +0100 Subject: [PATCH] Implement TP-VPF-ENHANCED In-Reply-To: <20091117193039.5f983120@stefreak.de> References: <20091117193039.5f983120@stefreak.de> Message-ID: <4B03B001.9070503@gmail.com> Steffen 'stefreak' Neubauer schreef: > Hello :) > > Now I've implemented the TP-VPF-ENHANCED. To achieve that I added some > goto-stuff - i hope that's ok. I think it makes sense here. > > Goto seems here not necessary, I think. Why don't you just put the code in each case: instead of jumping to a tag and go from there? Set the return value retval or something and when you break out the switch statement you return the retval. But that's just my humble opinion :) From zecke at selfish.org Tue Nov 17 20:11:36 2009 From: zecke at selfish.org (Holger Freyther) Date: Tue, 17 Nov 2009 21:11:36 +0100 Subject: [RFC] nanoBTS startup sequence (problems on coldstart) Message-ID: <200911172111.36551.zecke@selfish.org> Hi Harald, I have one problem with the BTS on cold start. OpenBSC is sending the RSL connect, Radio Carrier/Baseband attributes too early and we are receiving NACKs from the BTS and the RSL link is never established. The first question is if others have seen this problem? I have solved the problem my moving the OP start/set attributes/RSL connect of the RC and Baseband out of the state change code into the "Software Activated Report". Doing a quick check it seems to still work and solve my cold start problem. Do you think this is a legitimate workaround for the problem right now? In the future we probably should attempt to have a better state machine, report errors, retry and such things... regards holger From mailinglists at hellercom.de Wed Nov 18 11:21:39 2009 From: mailinglists at hellercom.de (Bjoern Heller) Date: Wed, 18 Nov 2009 12:21:39 +0100 Subject: [RFC] nanoBTS startup sequence (problems on coldstart) In-Reply-To: <200911172111.36551.zecke@selfish.org> References: <200911172111.36551.zecke@selfish.org> Message-ID: <4AAA4B59-A880-40BA-A163-742B0AD54DED@hellercom.de> Me2. Need to restart bsc_hack the first time after nanobts coldboot. Best Regards Bj?rn Heller Am 17.11.2009 um 21:11 schrieb Holger Freyther : > Hi Harald, > > I have one problem with the BTS on cold start. OpenBSC is sending > the RSL > connect, Radio Carrier/Baseband attributes too early and we are > receiving > NACKs from the BTS and the RSL link is never established. > > The first question is if others have seen this problem? I have > solved the > problem my moving the OP start/set attributes/RSL connect of the RC > and > Baseband out of the state change code into the "Software Activated > Report". > > Doing a quick check it seems to still work and solve my cold start > problem. Do > you think this is a legitimate workaround for the problem right now? > > In the future we probably should attempt to have a better state > machine, > report errors, retry and such things... > > regards > holger > From zecke at selfish.org Thu Nov 19 08:51:50 2009 From: zecke at selfish.org (Holger Freyther) Date: Thu, 19 Nov 2009 09:51:50 +0100 Subject: [RFC] nanoBTS startup sequence (problems on coldstart) In-Reply-To: <4AAA4B59-A880-40BA-A163-742B0AD54DED@hellercom.de> References: <200911172111.36551.zecke@selfish.org> <4AAA4B59-A880-40BA-A163-742B0AD54DED@hellercom.de> Message-ID: <200911190951.50941.zecke@selfish.org> On Wednesday 18 November 2009 12:21:39 Bjoern Heller wrote: > Me2. > Need to restart bsc_hack the first time after nanobts coldboot. could you please attempt to test the following patch? -------------- next part -------------- A non-text attachment was scrubbed... Name: bsc_start_hack.diff Type: text/x-patch Size: 2553 bytes Desc: not available URL: From mailinglists at hellercom.de Thu Nov 19 09:02:35 2009 From: mailinglists at hellercom.de (Bjoern Heller) Date: Thu, 19 Nov 2009 10:02:35 +0100 Subject: [RFC] nanoBTS startup sequence (problems on coldstart) In-Reply-To: <200911190951.50941.zecke@selfish.org> References: <200911172111.36551.zecke@selfish.org> <4AAA4B59-A880-40BA-A163-742B0AD54DED@hellercom.de> <200911190951.50941.zecke@selfish.org> Message-ID: Ill try later on today when Im at home. Best Regards Bj?rn Heller Am 19.11.2009 um 09:51 schrieb Holger Freyther : > On Wednesday 18 November 2009 12:21:39 Bjoern Heller wrote: >> Me2. >> Need to restart bsc_hack the first time after nanobts coldboot. > > could you please attempt to test the following patch? > > From 246tnt at gmail.com Fri Nov 20 15:09:41 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 20 Nov 2009 16:09:41 +0100 Subject: [RFC] nanoBTS startup sequence (problems on coldstart) In-Reply-To: <200911190951.50941.zecke@selfish.org> References: <200911172111.36551.zecke@selfish.org> <4AAA4B59-A880-40BA-A163-742B0AD54DED@hellercom.de> <200911190951.50941.zecke@selfish.org> Message-ID: <866320f70911200709y643dda56ge8182a2be3cd1d97@mail.gmail.com> On Thu, Nov 19, 2009 at 9:51 AM, Holger Freyther wrote: > On Wednesday 18 November 2009 12:21:39 Bjoern Heller wrote: >> Me2. >> Need to restart bsc_hack the first time after nanobts coldboot. > > could you please attempt to test the following patch? > > I have a nanoBTS at home and it takes two restart for it to work. I just got a another nanoBTS with a different SW version today and without the patch, it would not even start, even when trying multiple times (it seems to reset all OML stuff on disconnect ...), with it, it start reliably. Sylvain From 246tnt at gmail.com Fri Nov 20 22:37:55 2009 From: 246tnt at gmail.com (246tnt at gmail.com) Date: Fri, 20 Nov 2009 22:37:55 +0000 Subject: [RFC] nanoBTS startup sequence (problems on coldstart) In-Reply-To: <866320f70911200709y643dda56ge8182a2be3cd1d97@mail.gmail.com> Message-ID: <001485f85a0c7cd53b0478d520bf@google.com> > I just got a another nanoBTS with a different SW version today and > without the patch, it would not even start, even when trying multiple > times (it seems to reset all OML stuff on disconnect ...), with it, it > start reliably. i have mispoken. I also needed to add an SITE MANAGER OPSTART in case I get a "Disabled / Offline" status report for it. Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andreas.Eversberg at versatel.de Wed Nov 18 12:20:12 2009 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Wed, 18 Nov 2009 13:20:12 +0100 Subject: AW: [RFC] nanoBTS startup sequence (problems on coldstart) Message-ID: Me2 It is always the case with BS11: - boot BS11 (until finished) - run bsc_hack (not working) - run bsc_hack again (working) -----Urspr?ngliche Nachricht----- Von: openbsc-bounces at lists.gnumonks.org [mailto:openbsc-bounces at lists.gnumonks.org] Im Auftrag von Bjoern Heller Gesendet: Mittwoch, 18. November 2009 12:22 An: Holger Freyther Cc: openbsc at lists.gnumonks.org Betreff: Re: [RFC] nanoBTS startup sequence (problems on coldstart) Me2. Need to restart bsc_hack the first time after nanobts coldboot. Best Regards Bj?rn Heller From laforge at gnumonks.org Fri Nov 20 13:09:46 2009 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 20 Nov 2009 14:09:46 +0100 Subject: [RFC] nanoBTS startup sequence (problems on coldstart) In-Reply-To: <200911172111.36551.zecke@selfish.org> References: <200911172111.36551.zecke@selfish.org> Message-ID: <20091120130946.GQ13105@prithivi.gnumonks.org> On Tue, Nov 17, 2009 at 09:11:36PM +0100, Holger Freyther wrote: > Hi Harald, > > I have one problem with the BTS on cold start. OpenBSC is sending the RSL > connect, Radio Carrier/Baseband attributes too early and we are receiving > NACKs from the BTS and the RSL link is never established. > > The first question is if others have seen this problem? I have solved the > problem my moving the OP start/set attributes/RSL connect of the RC and > Baseband out of the state change code into the "Software Activated Report". Yes, this is what we had before. If you look at the revision log, it used to be this way and worked more reliably. I already spent way too much time trying to find out the correct state machine but failed. > Doing a quick check it seems to still work and solve my cold start problem. Do > you think this is a legitimate workaround for the problem right now? > > In the future we probably should attempt to have a better state machine, > report errors, retry and such things... Meanwhile I think it should be sufficient to return to the old code, as it was working quite reliably for many months. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From zecke at selfish.org Fri Nov 20 13:54:11 2009 From: zecke at selfish.org (Holger Freyther) Date: Fri, 20 Nov 2009 14:54:11 +0100 Subject: [RFC] nanoBTS startup sequence (problems on coldstart) In-Reply-To: <20091120130946.GQ13105@prithivi.gnumonks.org> References: <200911172111.36551.zecke@selfish.org> <20091120130946.GQ13105@prithivi.gnumonks.org> Message-ID: <200911201454.12002.zecke@selfish.org> On Friday 20 November 2009 14:09:46 Harald Welte wrote: > Meanwhile I think it should be sufficient to return to the old code, as it > was working quite reliably for many months. Should I revert the whole patch or just parts of it? From laforge at gnumonks.org Sun Nov 22 09:57:06 2009 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 22 Nov 2009 10:57:06 +0100 Subject: [RFC] nanoBTS startup sequence (problems on coldstart) In-Reply-To: <200911201454.12002.zecke@selfish.org> References: <200911172111.36551.zecke@selfish.org> <20091120130946.GQ13105@prithivi.gnumonks.org> <200911201454.12002.zecke@selfish.org> Message-ID: <20091122095706.GF13105@prithivi.gnumonks.org> On Fri, Nov 20, 2009 at 02:54:11PM +0100, Holger Freyther wrote: > On Friday 20 November 2009 14:09:46 Harald Welte wrote: > > > > Meanwhile I think it should be sufficient to return to the old code, as it > > was working quite reliably for many months. > > Should I revert the whole patch or just parts of it? simply use that new patch that you posted. The old change that I introduced changes multiple things in one patch, as far as I remember... so reverting it might not be a good idea. But at least the decision what to initialize when should be the same as it was before my changes. -- - 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 Nov 18 09:19:27 2009 From: zecke at selfish.org (Holger Freyther) Date: Wed, 18 Nov 2009 10:19:27 +0100 Subject: [PATCH] Release lchan directly when refcount drops to zero Message-ID: <200911181019.27564.zecke@selfish.org> Hi all, I have written this small patch yesterday. It is removing the "auto release" after timeout from lchan and will directly release the channel ones the ref count drops to zero. This means that any use of the lchan after a put_lchan is illegal (the code using a timeout used to workaround this issue). I have changed three call sites to follow this convention, I have added a BUG_ON into the abis_rsl method. From a quick test (Location Updating Request and a call) the BUG_ON in the abis_rsl.c is hit by: - The lchan release code (okay... a false warning and avoided by increasing use_count and decreasing it...) - CM Service Request Ack and such is sent without anyone holding a reference to it. I think this warning is safe to ignore for now as no one has simply claimed the channel. I plan to fix this in January/February when moving our MSC code over to the On Waves BSC abstraction. The benefit of this change is that we free our channels a lot earlier. I think this change would be beneficial for the 26C3 and I would like to hear opinions and see some testing with it. regards z. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-lchan-Release-the-channel-ones-its-usecount-drops-to.patch Type: text/x-patch Size: 8987 bytes Desc: not available URL: From 246tnt at gmail.com Wed Nov 18 21:40:57 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 18 Nov 2009 22:40:57 +0100 Subject: [PATCH] Release lchan directly when refcount drops to zero In-Reply-To: <200911181019.27564.zecke@selfish.org> References: <200911181019.27564.zecke@selfish.org> Message-ID: <866320f70911181340p43d9f458g25f0c8728e44b665@mail.gmail.com> You need to add #include to silent_call.c or it doesn't compile. (at least on my laptop). From zecke at selfish.org Thu Nov 19 08:31:58 2009 From: zecke at selfish.org (Holger Freyther) Date: Thu, 19 Nov 2009 09:31:58 +0100 Subject: [PATCH] Release lchan directly when refcount drops to zero In-Reply-To: <866320f70911181340p43d9f458g25f0c8728e44b665@mail.gmail.com> References: <200911181019.27564.zecke@selfish.org> <866320f70911181340p43d9f458g25f0c8728e44b665@mail.gmail.com> Message-ID: <200911190931.59002.zecke@selfish.org> On Wednesday 18 November 2009 22:40:57 Sylvain Munaut wrote: > You need to add #include to silent_call.c or it > doesn't compile. > (at least on my laptop). possible, these files were added after I made the patch. From laforge at gnumonks.org Fri Nov 20 13:04:35 2009 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 20 Nov 2009 14:04:35 +0100 Subject: [PATCH] Release lchan directly when refcount drops to zero In-Reply-To: <200911181019.27564.zecke@selfish.org> References: <200911181019.27564.zecke@selfish.org> Message-ID: <20091120130435.GP13105@prithivi.gnumonks.org> Hi zecke, On Wed, Nov 18, 2009 at 10:19:27AM +0100, Holger Freyther wrote: > Hi all, > > I have written this small patch yesterday. It is removing the "auto release" > after timeout from lchan and will directly release the channel ones the ref > count drops to zero. thanks for investigating this. The reason why we have this long timeout is mainly due to MO SMS. What happens in the MO SMS case is that we get a CM SERVICE REQUEST is that the channel stays active for a very long time (especially if you have a very long sms) before we get the actual CP-DATA. If our timeout is too low, then the channel will simply timeout while the SMS is being transmitted. So what do we do here in order to solve the issue ? Handle CM SERVICE REQUEST as a special case and manually increase it or start some special timer? The only idea I had was that we should be getting and ESTABLISH INDICATION on SAPI=3, but I'm not sure if that happens before the CP-DATA. So whatever change you make, if it survives sending a maximum-sized MO SMS ona SDCCH (plus even accounting for some L2 retransmissions), then I'm happy with it! 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 zecke at selfish.org Fri Nov 20 13:37:40 2009 From: zecke at selfish.org (Holger Freyther) Date: Fri, 20 Nov 2009 14:37:40 +0100 Subject: [PATCH] Release lchan directly when refcount drops to zero In-Reply-To: <20091120130435.GP13105@prithivi.gnumonks.org> References: <200911181019.27564.zecke@selfish.org> <20091120130435.GP13105@prithivi.gnumonks.org> Message-ID: <200911201437.40952.zecke@selfish.org> On Friday 20 November 2009 14:04:35 Harald Welte wrote: > Hi zecke, > > On Wed, Nov 18, 2009 at 10:19:27AM +0100, Holger Freyther wrote: > > Hi all, > > > > I have written this small patch yesterday. It is removing the "auto > > release" after timeout from lchan and will directly release the channel > > ones the ref count drops to zero. > > thanks for investigating this. > > The reason why we have this long timeout is mainly due to MO SMS. > > What happens in the MO SMS case is that we get a CM SERVICE REQUEST is that > the channel stays active for a very long time (especially if you have a > very long sms) before we get the actual CP-DATA. > > If our timeout is too low, then the channel will simply timeout while the > SMS is being transmitted. > > So what do we do here in order to solve the issue ? Handle CM SERVICE > REQUEST as a special case and manually increase it or start some special > timer? Hi LaF0rge, I'm not really following here. I have removed the lchan "auto release" timer for now and directly release when the refcount drops down to zero. The only timer that is active is the RSL timer we start in CHan ACTivate (or such). For the CM Service Request... In the future this, Locationg Updating Request and Paging Response (some more according to 08.08) would start the transaction and we would keep the channel open as long as the transaction is alive. We will introduce a "channel" leak only in the case where we will leak the transaction. But this is a bug. In any case I will try sending a real long SMS from my phone and try to observe what is happening. regards holger From laforge at gnumonks.org Sun Nov 22 09:59:35 2009 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 22 Nov 2009 10:59:35 +0100 Subject: [PATCH] Release lchan directly when refcount drops to zero In-Reply-To: <200911201437.40952.zecke@selfish.org> References: <200911181019.27564.zecke@selfish.org> <20091120130435.GP13105@prithivi.gnumonks.org> <200911201437.40952.zecke@selfish.org> Message-ID: <20091122095935.GG13105@prithivi.gnumonks.org> Hi Holger, On Fri, Nov 20, 2009 at 02:37:40PM +0100, Holger Freyther wrote: > I'm not really following here. I have removed the lchan "auto release" timer > for now and directly release when the refcount drops down to zero. The only > timer that is active is the RSL timer we start in CHan ACTivate (or such). > > For the CM Service Request... In the future this, Locationg Updating Request > and Paging Response (some more according to 08.08) would start the transaction > and we would keep the channel open as long as the transaction is alive. yes, that sounds great and it is definitely how it should be. But is this already working with your proposed patch? At least when I was trying last, simply reducing the timeout to 5 seconds already made MO SMS fail. If there meanwhile were some changes to the core code that make it work: Great! > We will introduce a "channel" leak only in the case where we will leak the > transaction. But this is a bug. ok, that's fine with me. > In any case I will try sending a real long SMS from my phone and try to > observe what is happening. ok, thanks. -- - 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 Nov 18 22:37:37 2009 From: 246tnt at gmail.com (246tnt at gmail.com) Date: Wed, 18 Nov 2009 22:37:37 +0000 Subject: Redudant channel assignement Message-ID: <000e0ce0d5d8c3e0d00478ace370@google.com> When making a call from my test phone (a T610 here), I see the BSC assigning more than one channel ... For example, with a MO call : <0010> abis_rsl.c:1182 Activating ARFCN(514) TS(2) SS(0) lctype TCH/F chan_nr=0x0a r=OTHER ra=0xe7 <0010> abis_rsl.c:1001 channel=(bts=0,trx=0,ts=2) chan_nr=0x0a CHANNEL ACTIVATE ACK <0010> abis_rsl.c:1182 Activating ARFCN(514) TS(3) SS(0) lctype TCH/F chan_nr=0x0b r=OTHER ra=0xf8 <0010> abis_rsl.c:1001 channel=(bts=0,trx=0,ts=3) chan_nr=0x0b CHANNEL ACTIVATE ACK <0010> abis_rsl.c:1182 Activating ARFCN(514) TS(4) SS(0) lctype TCH/F chan_nr=0x0c r=OTHER ra=0xe3 <0010> abis_rsl.c:1001 channel=(bts=0,trx=0,ts=4) chan_nr=0x0c CHANNEL ACTIVATE ACK <0001> abis_rsl.c:1286 channel=(bts=0,trx=0,ts=4) chan_nr=0x0c sapi=0 ESTABLISH INDICATION <0004> gsm_04_08.c:1280 <- CM SERVICE REQUEST serv_type=0x01 mi_type=0x04 M(874908265) ... <0010> abis_rsl.c:1001 channel=(bts=0,trx=0,ts=4) chan_nr=0x0c CHANNEL MODE MODIFY ACK <0010> abis_rsl.c:1526 channel=(bts=0,trx=0,ts=4) chan_nr=0x0c IPAC_DISCONNECT_IND CAUSE=0x0f(Normal event, unspecified) <0001> abis_rsl.c:1286 channel=(bts=0,trx=0,ts=4) chan_nr=0x0c sapi=0 RELEASE INDICATION <0010> abis_rsl.c:721 RF Channel Release CMD channel=(bts=0,trx=0,ts=4) chan_nr=0x0c <0010> abis_rsl.c:1001 channel=(bts=0,trx=0,ts=4) chan_nr=0x0c RF CHANNEL RELEASE ACK <0002> gsm_subscriber_base.c:150 subscr 201 usage decreased usage to: 0 <0010> abis_rsl.c:1001 channel=(bts=0,trx=0,ts=2) chan_nr=0x0a CONNECTION FAIL: CAUSE=0x01(Radio Link Failure) RELEASING. <0010> abis_rsl.c:721 RF Channel Release CMD channel=(bts=0,trx=0,ts=2) chan_nr=0x0a <0010> abis_rsl.c:1001 channel=(bts=0,trx=0,ts=2) chan_nr=0x0a RF CHANNEL RELEASE ACK <0010> abis_rsl.c:1001 channel=(bts=0,trx=0,ts=3) chan_nr=0x0b CONNECTION FAIL: CAUSE=0x01(Radio Link Failure) RELEASING. <0010> abis_rsl.c:721 RF Channel Release CMD channel=(bts=0,trx=0,ts=3) chan_nr=0x0b <0010> abis_rsl.c:1001 channel=(bts=0,trx=0,ts=3) chan_nr=0x0b RF CHANNEL RELEASE ACK <0010> abis_rsl.c:721 RF Channel Release CMD channel=(bts=0,trx=0,ts=2) chan_nr=0x0a <0010> abis_rsl.c:1001 channel=(bts=0,trx=0,ts=2) chan_nr=0x0a RF CHANNEL RELEASE ACK <0010> abis_rsl.c:721 RF Channel Release CMD channel=(bts=0,trx=0,ts=3) chan_nr=0x0b <0010> abis_rsl.c:1001 channel=(bts=0,trx=0,ts=3) chan_nr=0x0b RF CHANNEL RELEASE ACK As you see, there was 3 TCH assigned ... (and of course two of those ultimately failed with Radio Link Failure ...). Is anyone else seeing this ? Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Thu Nov 19 00:30:27 2009 From: 246tnt at gmail.com (246tnt at gmail.com) Date: Thu, 19 Nov 2009 00:30:27 +0000 Subject: Redudant channel assignement In-Reply-To: <000e0ce0d5d8c3e0d00478ace370@google.com> Message-ID: <001485f8954c3fbf5e0478ae7751@google.com> On Nov 18, 2009 11:37pm, 246tnt at gmail.com wrote: > When making a call from my test phone (a T610 here), I see the BSC > assigning more than one channel ... > For example, with a MO call : > abis_rsl.c:1182 Activating ARFCN(514) TS(2) SS(0) lctype TCH/F > chan_nr=0x0a r=OTHER ra=0xe7 > abis_rsl.c:1001 channel=(bts=0,trx=0,ts=2) chan_nr=0x0a CHANNEL ACTIVATE > ACK > abis_rsl.c:1182 Activating ARFCN(514) TS(3) SS(0) lctype TCH/F > chan_nr=0x0b r=OTHER ra=0xf8 > abis_rsl.c:1001 channel=(bts=0,trx=0,ts=3) chan_nr=0x0b CHANNEL ACTIVATE > ACK > abis_rsl.c:1182 Activating ARFCN(514) TS(4) SS(0) lctype TCH/F > chan_nr=0x0c r=OTHER ra=0xe3 > abis_rsl.c:1001 channel=(bts=0,trx=0,ts=4) chan_nr=0x0c CHANNEL ACTIVATE > ACK > abis_rsl.c:1286 channel=(bts=0,trx=0,ts=4) chan_nr=0x0c sapi=0 ESTABLISH > INDICATION It seems increasing the Tx-Integer values in the RACH IE of the SystemInformations message improve the situation. But it doesn't solve it completly. yet... still looking. Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Fri Nov 20 12:49:48 2009 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 20 Nov 2009 13:49:48 +0100 Subject: Redudant channel assignement In-Reply-To: <000e0ce0d5d8c3e0d00478ace370@google.com> References: <000e0ce0d5d8c3e0d00478ace370@google.com> Message-ID: <20091120124948.GN13105@prithivi.gnumonks.org> On Wed, Nov 18, 2009 at 10:37:37PM +0000, 246tnt at gmail.com wrote: > When making a call from my test phone (a T610 here), I see the BSC > assigning more than one channel ... yes, this is due to the fact that we do not check for the request reference. when your MS transmits the first RACH burst, it selects a particular request reference. all retransmissions carry the same request reference. So the BSC should be tracking for which request references it has already activated a channel, and only assign a new channel if there is not yet a channel for that request reference. Since there is no straight-forward way of keeping track of this without introducing some additional data structures, I simply skipped it when writing that part of the code. Of course it should be fixed at some point, and patches are appreciated. -- - 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 Fri Nov 20 21:12:49 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 20 Nov 2009 22:12:49 +0100 Subject: Redudant channel assignement In-Reply-To: <20091120124948.GN13105@prithivi.gnumonks.org> References: <000e0ce0d5d8c3e0d00478ace370@google.com> <20091120124948.GN13105@prithivi.gnumonks.org> Message-ID: <866320f70911201312o5c48ebd3n6fa6dcd166a47535@mail.gmail.com> On Fri, Nov 20, 2009 at 1:49 PM, Harald Welte wrote: > On Wed, Nov 18, 2009 at 10:37:37PM +0000, 246tnt at gmail.com wrote: >> When making a call from my test phone (a T610 here), I see the BSC >> assigning more than one channel ... > > yes, this is due to the fact that we do not check for the request reference. > > when your MS transmits the first RACH burst, it selects a particular request > reference. ?all retransmissions carry the same request reference. Nope, they dont. In gsm 04.08 3.3.1.1.1 about the RACH bursts they says : "a random reference which is drawn randomly from a uniform probability distribution for every new transmission." And that's why I observe, the "ra" is different for each try. But those attemps are _very_ close to each other, not time for the BSC to respond. Sylvain From laforge at gnumonks.org Fri Nov 20 23:15:50 2009 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 21 Nov 2009 00:15:50 +0100 Subject: Redudant channel assignement In-Reply-To: <866320f70911201312o5c48ebd3n6fa6dcd166a47535@mail.gmail.com> References: <000e0ce0d5d8c3e0d00478ace370@google.com> <20091120124948.GN13105@prithivi.gnumonks.org> <866320f70911201312o5c48ebd3n6fa6dcd166a47535@mail.gmail.com> Message-ID: <20091120231550.GY13105@prithivi.gnumonks.org> Hi Sylvain, On Fri, Nov 20, 2009 at 10:12:49PM +0100, Sylvain Munaut wrote: > "a random reference which is drawn randomly from a uniform probability > distribution for every new transmission." ok, thanks for the clarification. I somehow remembered that differently. > And that's why I observe, the "ra" is different for each try. But > those attemps are _very_ close to each other, not time for the BSC to > respond. ok, then maybe changing the parameters as suggested by Dieter is a good idea. We might also make it config file configurable. -- - 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 Nov 18 22:40:08 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 18 Nov 2009 23:40:08 +0100 Subject: [PATCH 1/4] [gsm_04_08_gprs] Display the identity type for GMM IDENTITY REQUEST Message-ID: <1258584011-26613-1-git-send-email-246tnt@gmail.com> From: Sylvain Munaut Signed-off-by: Sylvain Munaut --- openbsc/src/gsm_04_08_gprs.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/openbsc/src/gsm_04_08_gprs.c b/openbsc/src/gsm_04_08_gprs.c index cac28d7..dc1c69f 100644 --- a/openbsc/src/gsm_04_08_gprs.c +++ b/openbsc/src/gsm_04_08_gprs.c @@ -220,7 +220,7 @@ static int gsm48_tx_gmm_id_req(struct msgb *old_msg, u_int8_t id_type) struct msgb *msg = gsm48_msgb_alloc(); struct gsm48_hdr *gh; - DEBUGP(DMM, "-> GPRS IDENTITY REQUEST\n"); + DEBUGP(DMM, "-> GPRS IDENTITY REQUEST: mi_type=%02x\n", id_type); msg->tlli = old_msg->tlli; msg->trx = old_msg->trx; -- 1.6.5.1 From 246tnt at gmail.com Wed Nov 18 22:40:09 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 18 Nov 2009 23:40:09 +0100 Subject: [PATCH 2/4] [bsc_init] Don't set NM_ATT_IPACC_RLC_CFG_3 attribute In-Reply-To: <1258584011-26613-1-git-send-email-246tnt@gmail.com> References: <1258584011-26613-1-git-send-email-246tnt@gmail.com> Message-ID: <1258584011-26613-2-git-send-email-246tnt@gmail.com> From: Sylvain Munaut This is for EDGE model only and breaks init on older (eg. 139) models. EDGE is not advertised in the SI anyway ... Disabled for now. When GPRS is working, we can get back to it and do a proper check and init/advertise them properly Signed-off-by: Sylvain Munaut --- openbsc/src/bsc_init.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/openbsc/src/bsc_init.c b/openbsc/src/bsc_init.c index 20b6501..00f25d8 100644 --- a/openbsc/src/bsc_init.c +++ b/openbsc/src/bsc_init.c @@ -386,8 +386,12 @@ static unsigned char nanobts_attr_cell[] = { 0x00, 250, 0x00, 250, 2, /* MCS2 */ +#if 0 + /* EDGE model only, breaks older models. + * Should inquire the BTS capabilities */ NM_ATT_IPACC_RLC_CFG_3, 0, 1, 2, /* MCS2 */ +#endif }; static unsigned char nanobts_attr_nsvc0[] = { -- 1.6.5.1 From 246tnt at gmail.com Wed Nov 18 22:40:10 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 18 Nov 2009 23:40:10 +0100 Subject: [PATCH 3/4] [gprs] Fix hardcoded IP addresses in GPRS UDP communication In-Reply-To: <1258584011-26613-2-git-send-email-246tnt@gmail.com> References: <1258584011-26613-1-git-send-email-246tnt@gmail.com> <1258584011-26613-2-git-send-email-246tnt@gmail.com> Message-ID: <1258584011-26613-3-git-send-email-246tnt@gmail.com> From: Sylvain Munaut Note, there is still an ugly hack: We send packets to the first BTS we find and not the "right" one, mostly because I had no idea how to find the right one ... Signed-off-by: Sylvain Munaut --- openbsc/include/openbsc/gsm_data.h | 4 ++++ openbsc/src/bsc_init.c | 4 ++-- openbsc/src/input/ipaccess.c | 24 +++++++++++++++++++++++- 3 files changed, 29 insertions(+), 3 deletions(-) diff --git a/openbsc/include/openbsc/gsm_data.h b/openbsc/include/openbsc/gsm_data.h index ed36e9a..670df8f 100644 --- a/openbsc/include/openbsc/gsm_data.h +++ b/openbsc/include/openbsc/gsm_data.h @@ -2,6 +2,7 @@ #define _GSM_DATA_H #include +#include struct value_string { unsigned int value; @@ -346,6 +347,9 @@ struct gsm_bts { struct { u_int16_t site_id; u_int16_t bts_id; + + struct in_addr ina_local; + struct in_addr ina_remote; } ip_access; struct { struct { diff --git a/openbsc/src/bsc_init.c b/openbsc/src/bsc_init.c index 00f25d8..2526306 100644 --- a/openbsc/src/bsc_init.c +++ b/openbsc/src/bsc_init.c @@ -1045,8 +1045,8 @@ static void patch_nm_tables(struct gsm_bts *bts) nanobts_attr_nsvc0[3] = bts->gprs.nsvc[0].nsvci >> 8; nanobts_attr_nsvc0[4] = bts->gprs.nsvc[0].nsvci & 0xff; - /* FIXME: patch our own IP address as SGSN IP */ - //nanobts_attr_nsvc0[10] = + /* patch our own IP address as SGSN IP */ + memcpy(&nanobts_attr_nsvc0[10], &bts->ip_access.ina_local, 4); /* patch BVCI */ nanobts_attr_cell[12] = bts->gprs.cell.bvci >> 8; diff --git a/openbsc/src/input/ipaccess.c b/openbsc/src/input/ipaccess.c index fb13570..6ec4e0b 100644 --- a/openbsc/src/input/ipaccess.c +++ b/openbsc/src/input/ipaccess.c @@ -221,6 +221,20 @@ static int ipaccess_rcvmsg(struct e1inp_line *line, struct msgb *msg, } DEBUGP(DINP, "Identified BTS %u/%u/%u\n", site_id, bts_id, trx_id); if (bfd->priv_nr == 1) { + int rv; + socklen_t l = sizeof(struct sockaddr_in); + struct sockaddr_in sa; + + rv = getpeername(bfd->fd, (struct sockaddr *)&sa, &l); + if (rv || (l != sizeof(struct sockaddr_in))) + return -EINVAL; + bts->ip_access.ina_remote = sa.sin_addr; + + rv = getsockname(bfd->fd, (struct sockaddr *)&sa, &l); + if (rv || (l != sizeof(struct sockaddr_in))) + return -EINVAL; + bts->ip_access.ina_local = sa.sin_addr; + bts->oml_link = e1inp_sign_link_create(&line->ts[1-1], E1INP_SIGN_OML, bts->c0, bts->oml_tei, 0); @@ -513,11 +527,19 @@ static int handle_gprs_write(struct bsc_fd *bfd) int ipac_gprs_send(struct msgb *msg) { + struct gsm_bts *bts; struct sockaddr_in sin; int rc; + /* FIXME: Just take the first ip.access bts we find */ + llist_for_each_entry(bts, &e1h->gsmnet->bts_list, list) { + if (!is_ipaccess_bts(bts)) + continue; + break; + } + sin.sin_family = AF_INET; - inet_aton("192.168.100.111", &sin.sin_addr); + sin.sin_addr = bts->ip_access.ina_remote; sin.sin_port = htons(23000); rc = sendto(e1h->gprs_fd.fd, msg->data, msg->len, 0, -- 1.6.5.1 From 246tnt at gmail.com Wed Nov 18 22:40:11 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 18 Nov 2009 23:40:11 +0100 Subject: [PATCH 4/4] [gsm_04_08_gprs] Change GMM ATTACH REQUEST identity req logic In-Reply-To: <1258584011-26613-3-git-send-email-246tnt@gmail.com> References: <1258584011-26613-1-git-send-email-246tnt@gmail.com> <1258584011-26613-2-git-send-email-246tnt@gmail.com> <1258584011-26613-3-git-send-email-246tnt@gmail.com> Message-ID: <1258584011-26613-4-git-send-email-246tnt@gmail.com> From: Sylvain Munaut Instead of trying to guess what we need, we just try to authorize the user and the authorize method will check and do identity requests as needed. Signed-off-by: Sylvain Munaut --- openbsc/src/gsm_04_08_gprs.c | 13 +++++++------ 1 files changed, 7 insertions(+), 6 deletions(-) diff --git a/openbsc/src/gsm_04_08_gprs.c b/openbsc/src/gsm_04_08_gprs.c index dc1c69f..d954266 100644 --- a/openbsc/src/gsm_04_08_gprs.c +++ b/openbsc/src/gsm_04_08_gprs.c @@ -240,6 +240,10 @@ static int gsm48_gmm_authorize(struct sgsn_mm_ctx *ctx, struct msgb *msg) if (strlen(ctx->imei) && strlen(ctx->imsi)) { ctx->mm_state = GMM_REGISTERED_NORMAL; return gsm48_tx_gmm_att_ack(msg); + } else if (!strlen(ctx->imei)) { + return gsm48_tx_gmm_id_req(msg, GSM_MI_TYPE_IMEI); + } else if (!strlen(ctx->imsi)) { + return gsm48_tx_gmm_id_req(msg, GSM_MI_TYPE_IMSI); } return 0; @@ -371,8 +375,6 @@ static int gsm48_rx_gmm_att_req(struct msgb *msg) strncpy(ctx->imsi, mi_string, sizeof(ctx->imsi)); #endif } - /* we always want the IMEI, too */ - gsm48_tx_gmm_id_req(msg, GSM_MI_TYPE_IMEI); /* FIXME: Start some timer */ ctx->mm_state = GMM_COMMON_PROC_INIT; ctx->tlli = msg->tlli; @@ -383,8 +385,6 @@ static int gsm48_rx_gmm_att_req(struct msgb *msg) ctx = sgsn_mm_ctx_by_ptmsi(tmsi); if (!ctx) { ctx = sgsn_mm_ctx_alloc(msg->tlli, &ra_id); - /* Send MM INFO request for IMSI */ - gsm48_tx_gmm_id_req(msg, GSM_MI_TYPE_IMSI); /* FIXME: Start some timer */ ctx->mm_state = GMM_COMMON_PROC_INIT; ctx->tlli = msg->tlli; @@ -397,8 +397,9 @@ static int gsm48_rx_gmm_att_req(struct msgb *msg) /* FIXME: allocate a new P-TMSI (+ P-TMSI signature) */ /* FIXME: update the TLLI with the new local TLLI based on the P-TMSI */ - //return gsm48_tx_gmm_att_ack(msg); - return 0; + DEBUGPC(DMM, "\n"); + + return ctx ? gsm48_gmm_authorize(ctx, msg) : 0; err_inval: DEBUGPC(DMM, "\n"); -- 1.6.5.1 From laforge at gnumonks.org Fri Nov 20 09:21:17 2009 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 20 Nov 2009 10:21:17 +0100 Subject: [PATCH 4/4] [gsm_04_08_gprs] Change GMM ATTACH REQUEST identity req logic In-Reply-To: <1258584011-26613-4-git-send-email-246tnt@gmail.com> References: <1258584011-26613-1-git-send-email-246tnt@gmail.com> <1258584011-26613-2-git-send-email-246tnt@gmail.com> <1258584011-26613-3-git-send-email-246tnt@gmail.com> <1258584011-26613-4-git-send-email-246tnt@gmail.com> Message-ID: <20091120092117.GK13105@prithivi.gnumonks.org> On Wed, Nov 18, 2009 at 11:40:11PM +0100, Sylvain Munaut wrote: > From: Sylvain Munaut > > Instead of trying to guess what we need, we just try to > authorize the user and the authorize method will check > and do identity requests as needed. thanks, will apply. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Fri Nov 20 12:56:56 2009 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 20 Nov 2009 13:56:56 +0100 Subject: [PATCH 3/4] [gprs] Fix hardcoded IP addresses in GPRS UDP communication In-Reply-To: <1258584011-26613-3-git-send-email-246tnt@gmail.com> References: <1258584011-26613-1-git-send-email-246tnt@gmail.com> <1258584011-26613-2-git-send-email-246tnt@gmail.com> <1258584011-26613-3-git-send-email-246tnt@gmail.com> Message-ID: <20091120125656.GO13105@prithivi.gnumonks.org> On Wed, Nov 18, 2009 at 11:40:10PM +0100, Sylvain Munaut wrote: > From: Sylvain Munaut > > Note, there is still an ugly hack: We send packets to the > first BTS we find and not the "right" one, mostly because > I had no idea how to find the right one ... ok, I think we should wait for a proper solution, rather than replacing one hack with another one. > @@ -346,6 +347,9 @@ struct gsm_bts { > struct { > u_int16_t site_id; > u_int16_t bts_id; > + > + struct in_addr ina_local; > + struct in_addr ina_remote; > } ip_access; this makes sense, sure. > - /* FIXME: patch our own IP address as SGSN IP */ > - //nanobts_attr_nsvc0[10] = > + /* patch our own IP address as SGSN IP */ > + memcpy(&nanobts_attr_nsvc0[10], &bts->ip_access.ina_local, 4); that, too. > @@ -513,11 +527,19 @@ static int handle_gprs_write(struct bsc_fd *bfd) > > int ipac_gprs_send(struct msgb *msg) > { > + struct gsm_bts *bts; > struct sockaddr_in sin; > int rc; > > + /* FIXME: Just take the first ip.access bts we find */ > + llist_for_each_entry(bts, &e1h->gsmnet->bts_list, list) { > + if (!is_ipaccess_bts(bts)) > + continue; > + break; > + } > + msg->trx will be set, so you can simply dereference msg->trx->bts to get to the bts to which this should be sent. please change that, test it and resubmit. Thanks! -- - 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 Fri Nov 20 14:11:33 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 20 Nov 2009 15:11:33 +0100 Subject: [PATCH 3/4] [gprs] Fix hardcoded IP addresses in GPRS UDP communication In-Reply-To: <20091120125656.GO13105@prithivi.gnumonks.org> References: <1258584011-26613-1-git-send-email-246tnt@gmail.com> <1258584011-26613-2-git-send-email-246tnt@gmail.com> <1258584011-26613-3-git-send-email-246tnt@gmail.com> <20091120125656.GO13105@prithivi.gnumonks.org> Message-ID: <866320f70911200611v106d2ff0w78a78910201b12be@mail.gmail.com> Harald Welte wrote: >> Note, there is still an ugly hack: We send packets to the >> first BTS we find and not the "right" one, mostly because >> I had no idea how to find the right one ... > > ok, I think we should wait for a proper solution, rather than replacing one > hack with another one. Yes, I hesitated posting the patch, but the advantage of this hack was that it is automatic :) >> + /* FIXME: Just take the first ip.access bts we find */ >> + llist_for_each_entry(bts, &e1h->gsmnet->bts_list, list) { >> + if (!is_ipaccess_bts(bts)) >> + continue; >> + break; > > msg->trx will be set, so you can simply dereference msg->trx->bts to get to the > bts to which this should be sent. That was my first thought. But it's not set (or at least not always), leading to a seg fault when I tried that. For examples packets send with gprs_ns_tx_simple don't have it set. And I didn't see any clean way to get it from where those were generated. Sylvain From laforge at gnumonks.org Fri Nov 20 15:25:13 2009 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 20 Nov 2009 16:25:13 +0100 Subject: [PATCH 3/4] [gprs] Fix hardcoded IP addresses in GPRS UDP communication In-Reply-To: <866320f70911200611v106d2ff0w78a78910201b12be@mail.gmail.com> References: <1258584011-26613-1-git-send-email-246tnt@gmail.com> <1258584011-26613-2-git-send-email-246tnt@gmail.com> <1258584011-26613-3-git-send-email-246tnt@gmail.com> <20091120125656.GO13105@prithivi.gnumonks.org> <866320f70911200611v106d2ff0w78a78910201b12be@mail.gmail.com> Message-ID: <20091120152513.GW13105@prithivi.gnumonks.org> Hi Sylvain, On Fri, Nov 20, 2009 at 03:11:33PM +0100, Sylvain Munaut wrote: > >> + /* FIXME: Just take the first ip.access bts we find */ > >> + llist_for_each_entry(bts, &e1h->gsmnet->bts_list, list) { > >> + if (!is_ipaccess_bts(bts)) > >> + continue; > >> + break; > > > > msg->trx will be set, so you can simply dereference msg->trx->bts to get to the > > bts to which this should be sent. > > That was my first thought. But it's not set (or at least not always), > leading to a seg fault when I tried that. For examples packets send > with gprs_ns_tx_simple don't have it set. And I didn't see any clean way > to get it from where those were generated. ok, we need to fix those. I understand that the NS layer does not know yet which BTS has sent it. That's what the ns_link structure was intended for. However, what makes probably even more sense is to identify the BTS based on its source IP address in the input/ipaccess.c code. So for every packet we receive, we iterate over all BTS's and compare the source IP address. If we have a match, we assign msg->trx = bts->c0 and all higher layers have that knowledge and can use 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 laforge at gnumonks.org Fri Nov 20 09:21:03 2009 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 20 Nov 2009 10:21:03 +0100 Subject: [PATCH 2/4] [bsc_init] Don't set NM_ATT_IPACC_RLC_CFG_3 attribute In-Reply-To: <1258584011-26613-2-git-send-email-246tnt@gmail.com> References: <1258584011-26613-1-git-send-email-246tnt@gmail.com> <1258584011-26613-2-git-send-email-246tnt@gmail.com> Message-ID: <20091120092103.GJ13105@prithivi.gnumonks.org> On Wed, Nov 18, 2009 at 11:40:09PM +0100, Sylvain Munaut wrote: > From: Sylvain Munaut > > This is for EDGE model only and breaks init on older (eg. 139) > models. EDGE is not advertised in the SI anyway ... > > Disabled for now. When GPRS is working, we can get back to it > and do a proper check and init/advertise them properly thanks, will apply. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Fri Nov 20 09:20:51 2009 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 20 Nov 2009 10:20:51 +0100 Subject: [PATCH 1/4] [gsm_04_08_gprs] Display the identity type for GMM IDENTITY REQUEST In-Reply-To: <1258584011-26613-1-git-send-email-246tnt@gmail.com> References: <1258584011-26613-1-git-send-email-246tnt@gmail.com> Message-ID: <20091120092051.GI13105@prithivi.gnumonks.org> > - DEBUGP(DMM, "-> GPRS IDENTITY REQUEST\n"); > + DEBUGP(DMM, "-> GPRS IDENTITY REQUEST: mi_type=%02x\n", id_type); thanks, will apply. -- - 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 Nov 19 23:10:16 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 20 Nov 2009 00:10:16 +0100 Subject: Improper dispatch of MNCC_REL_CNF : callref cleared in gsm48_cc_tx_release ? Message-ID: <866320f70911191510p26cace88gab50559adf9c23c0@mail.gmail.com> Hi, Does anyone see a reason why callref would be cleared in gsm48_cc_tx_release ? That prevents proper dispatch of the subsequent REL_CNF (since trans->callref is now 0) and I don't really see what was the intent in putting it there ? Sylvain From zecke at selfish.org Fri Nov 20 17:13:33 2009 From: zecke at selfish.org (Holger Freyther) Date: Fri, 20 Nov 2009 18:13:33 +0100 Subject: On Waves branch status and the road ahead Message-ID: <200911201813.34094.zecke@selfish.org> Hey Guys, this is just a small head about the current work and how it relates to the OpenBSC project. So far I had developed in a branch and used rebase on it but I'm going to do regular releases so I have to stop modifying the history. Now I have the following branches: on-waves/mgcp: - This includes the MGCP media gateway implementation. The MSC in use has a mapping from the Circuit Identity Code (Multiplex + Timeslot) to an MGCP Endpoint. To ease development I have one bsc process and one mgcp one. To properly "connect" audio bsc and mgcp share a secret which is the RTP port to be used... E.g. I can bind all RTP ports ahead of time (also nice for tunneling data). There is some overlap with the current rtp proxy code but I'm not yet sure how these two fit together... So the future might be I include the MGCP code in the BSC and use the existing proxy code.. but I really don't know right now. on-waves/sccp: - This includes the SCCP implementation. It has a test case and is working quite reliable. Addressing (SSN) is achieved with something like a sockaddr and it is mostly following the socket semantic. Instead of accept and select I do have callbacks... this might change in the future. - There is no MTP* implementation in the code base... - The one "problem" with it is the memcpy... and "queuing" inside the code but both will be addressed over time. on-waves/gsm0808: - This is the current BSC app and GSM080 (BSSMAP/DTAP) code.. - This branch will rename the bssap.c to gsm_08_08.c and remove all traces of SCCP from it, some code will move from bsc_msc_ip.c to the bssap. - an API will be created that can be used by the bsc_msc_ip.c and the bsc_hack.c/gsm_04_08.c code. - In terms of OpenBSC I want this to be done after the congress to not create a mess right now. on-waves/bsc-master: - This will be my release branch. I will pull from the three branches, update version, put in hacks, or short term things that are necessary. - Think of it as a incubator for "master" as there is little danger of breaking things I have merged the MGCP and SCCP branches into master as well. I hope there is agreement (otherwise there is always git revert) z. From laforge at gnumonks.org Mon Nov 23 19:23:41 2009 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 23 Nov 2009 20:23:41 +0100 Subject: On Waves branch status and the road ahead In-Reply-To: <200911201813.34094.zecke@selfish.org> References: <200911201813.34094.zecke@selfish.org> Message-ID: <20091123192341.GS13105@prithivi.gnumonks.org> Hi zecke, thanks for the update. On Fri, Nov 20, 2009 at 06:13:33PM +0100, Holger Freyther wrote: > on-waves/mgcp: > - This includes the MGCP media gateway implementation. The MSC in use > has a mapping from the Circuit Identity Code (Multiplex + Timeslot) > to an MGCP Endpoint. To ease development I have one bsc process > and one mgcp one. To properly "connect" audio bsc and mgcp share > a secret which is the RTP port to be used... E.g. I can bind all > RTP ports ahead of time (also nice for tunneling data). > > There is some overlap with the current rtp proxy code but I'm not > yet sure how these two fit together... So the future might be I > include the MGCP code in the BSC and use the existing proxy code.. > but I really don't know right now. Ok, I think what should rather happen is that the RTP proxy should be moved into your MGCP process, as the RTP code should be a separate process anyway. > - In terms of OpenBSC I want this to be done after the congress to not > create a mess right now. yes, thanks for your consideration :) > as there is little danger of breaking things I have merged the MGCP and SCCP > branches into master as well. I hope there is agreement (otherwise there is > always git revert) this is fine. On a side note, the 'src' directory is getting quite a bit full and chaotic now. I think we should probably converge around something where we have src/common for common code, and then something like one directory for each program that we build. i.e. something like src/common src/libbsc src/bsc_hack src/ipaccess-config src/bs11-config src/bsc_mgcp 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 246tnt at gmail.com Fri Nov 20 23:19:12 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sat, 21 Nov 2009 00:19:12 +0100 Subject: nanoBTS without EFR support ? Message-ID: <866320f70911201519q6a61c065v89625b1390ff8fd1@mail.gmail.com> Hi, I was wondering if anyone heard of a nanoBTS without EFR support ? I have one here that responds with BIND_NACK if the codec is EFR but works ok if I set V1 Sylvain From zecke at selfish.org Sat Nov 21 17:26:50 2009 From: zecke at selfish.org (Holger Freyther) Date: Sat, 21 Nov 2009 18:26:50 +0100 Subject: nanoBTS without EFR support ? In-Reply-To: <866320f70911201519q6a61c065v89625b1390ff8fd1@mail.gmail.com> References: <866320f70911201519q6a61c065v89625b1390ff8fd1@mail.gmail.com> Message-ID: <200911211826.52041.zecke@selfish.org> On Saturday 21 November 2009 00:19:12 Sylvain Munaut wrote: > Hi, > > I was wondering if anyone heard of a nanoBTS without EFR support ? > > I have one here that responds with BIND_NACK if the codec is EFR but > works ok if I set V1 No idea, I just know it reboots when CRCX/binding EFR on a TCH/H. z. From 246tnt at gmail.com Sat Nov 21 18:05:41 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sat, 21 Nov 2009 19:05:41 +0100 Subject: nanoBTS without EFR support ? In-Reply-To: <200911211826.52041.zecke@selfish.org> References: <866320f70911201519q6a61c065v89625b1390ff8fd1@mail.gmail.com> <200911211826.52041.zecke@selfish.org> Message-ID: <866320f70911211005k6c7b97ecq1b73327ea1d4b1ff@mail.gmail.com> @Oystein: From the ML archive, I see you have a close version match, does EFR works on your nanoBTS ? A little more infos for reference: The two nanoBTS are both 1800 round model (non-edge). Both 139 but one is 139_ and the other is 139U. I can't see any visible difference in the PCBs of both. I found what I think is the jtag port to the ppc, I might try to dump the flash ... As far as I can tell, the only non-volatile storage are the 4 flash chips next to the MPC855. 4 chips of 1Mx16, that's 8Mo of firmware. The one where EFR doesn't work: - Marking on the side: nanoBTS model 139_ - ipaccess-find infos: Location 2='BTS_NBT131G' Equipment Version='111_029_23' Software Version='120a002_v149b42d0' The one where EFR works: - Marking on the side: nanoBTS model 139U - ipaccess-find infos: Location 2='BTS_NBT131G' Equipment Version='139_029_41' Software Version='120a352_v267b22d0' Sylvain From laforge at gnumonks.org Sun Nov 22 11:47:27 2009 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 22 Nov 2009 12:47:27 +0100 Subject: nanoBTS without EFR support ? In-Reply-To: <866320f70911201519q6a61c065v89625b1390ff8fd1@mail.gmail.com> References: <866320f70911201519q6a61c065v89625b1390ff8fd1@mail.gmail.com> Message-ID: <20091122114727.GH13105@prithivi.gnumonks.org> On Sat, Nov 21, 2009 at 12:19:12AM +0100, Sylvain Munaut wrote: > Hi, > > I was wondering if anyone heard of a nanoBTS without EFR support ? I think it is extremely unlikely, as all nanoBTS have been built long after EFR was introduced. I could imagine them not supporting AMR, but even that seems unlikely. > I have one here that responds with BIND_NACK if the codec is EFR but > works ok if I set V1 meybe it's related to the RTP PAYLOAD TYPE IE or something like that... -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From openbscuser at gmail.com Sun Nov 22 17:57:24 2009 From: openbscuser at gmail.com (=?UTF-8?Q?=E0=B2=A8=E0=B2=BE=E0=B2=97=E0=B3=87=E0=B2=B6=E0=B3=8D?=) Date: Sun, 22 Nov 2009 23:27:24 +0530 Subject: GSM Standard for CDR ? Message-ID: <1258912644.7799.0.camel@nsubrahm> Hi, Is there a GSM standard for Call Detail Record (CDR) ? I did Google for it, but I guess I am not using the right search terms. N. From openbscuser at gmail.com Mon Nov 23 02:31:26 2009 From: openbscuser at gmail.com (=?UTF-8?Q?=E0=B2=A8=E0=B2=BE=E0=B2=97=E0=B3=87=E0=B2=B6=E0=B3=8D?=) Date: Mon, 23 Nov 2009 08:01:26 +0530 Subject: Fail messages while applying patch Message-ID: <1258943487.12533.5.camel@nsubrahm> Hi, When applying patch (as described in Debian_Getting_Started page), I get messages as shown in screenshot. What do these mean ? N. -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot-Ubuntu-Mini [Running] - Sun VirtualBox.png Type: image/png Size: 26548 bytes Desc: not available URL: From mailinglists at hellercom.de Mon Nov 23 05:43:36 2009 From: mailinglists at hellercom.de (Bjoern Heller) Date: Mon, 23 Nov 2009 06:43:36 +0100 Subject: Fail messages while applying patch In-Reply-To: <1258943487.12533.5.camel@nsubrahm> References: <1258943487.12533.5.camel@nsubrahm> Message-ID: Hi, I think, you don`t need to apply the patch anymore in newer Kernel releases. regards Bjoern Am 23.11.2009 um 03:31 schrieb ??????: > Hi, > When applying patch (as described in Debian_Getting_Started page), I get > messages as shown in screenshot. What do these mean ? > > N. > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Bj?rn Heller Jabber: tec at jabber.hellercom.de -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Mon Nov 23 06:37:36 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Mon, 23 Nov 2009 07:37:36 +0100 Subject: Fail messages while applying patch In-Reply-To: References: <1258943487.12533.5.camel@nsubrahm> Message-ID: <866320f70911222237t42f2cbav65685b96a6b9ce83@mail.gmail.com> > But the miSDN is only needed for the BS-11. And I'm not sure if misdn will work in virtualbox. Does it have some kind of PCI pass through ? Sylvain From openbscuser at gmail.com Wed Nov 25 02:15:20 2009 From: openbscuser at gmail.com (=?UTF-8?Q?=E0=B2=A8=E0=B2=BE=E0=B2=97=E0=B3=87=E0=B2=B6=E0=B3=8D?=) Date: Wed, 25 Nov 2009 07:45:20 +0530 Subject: Fail messages while applying patch In-Reply-To: References: <1258943487.12533.5.camel@nsubrahm> Message-ID: <1259115320.9259.0.camel@nsubrahm> Thank you, Rohit for the link. N. On Mon, 2009-11-23 at 09:04 +0530, Rohit Joshi wrote: > It suggest patch found conflict in code. Read this to get started on > handling patch rejects http://elinux.org/Handling_Patch_Rejects > > > 2009/11/23 ?????? : > > Hi, > > When applying patch (as described in Debian_Getting_Started page), I get > > messages as shown in screenshot. What do these mean ? > > > > N. > > > > > From dekagramzla at gmail.com Mon Nov 23 12:26:33 2009 From: dekagramzla at gmail.com (Maciej Januszewski) Date: Mon, 23 Nov 2009 13:26:33 +0100 Subject: OpenBSC/LCR installation problem Message-ID: Hello Sorry for my ignorance but I am a complete newbie to the OpenBSC. We are trying to run the OpenBSC with the nanoBTS as an university project. I have tried to follow the step by step instructions from the OpenBSC wiki page (both Debian_Getting_Started and OpenBSC_LCR) but I have faced some problems during the LCR installation. I am putting a whole installation screen below because I am not sure which part of it might be relevant for diagnosing the problem. We have also tried this on 2.6.27.4 and 2.6.29.1 linux kernel versions (both with mISDN modules included, at least we believe so) and both gave the same problem.. I would really appreciate any suggestion for solving the problem. Thanks in advance. Sorry for some polish parts in it but it is due to our Debian version... ---------------------------------------------------------------------------- user at pc1123:~$ cd lcr user at pc1123:~/lcr$ sh autogen.sh autom4te: cannot open autom4te.cache/requests: Brak dost?pu aclocal: autom4te failed with exit status: 1 autom4te: cannot open autom4te.cache/requests: Brak dost?pu autoheader: '/usr/bin/autom4te' failed with exit status: 1 autom4te: cannot open autom4te.cache/requests: Permission denied automake: autoconf failed with exit status: 1 autom4te: cannot open autom4te.cache/requests: Permission denied user at pc1123:~/lcr$ su Has?o: pc1123:/home/user/lcr# $ ./configure --prefix=/opt/lcr --with-asterisk --with-gsm bash: $: command not found pc1123:/home/user/lcr# $ ./configure --prefix=/opt/lcr --with-asterisk --with-gsm bash: $: command not found pc1123:/home/user/lcr# ./configure --prefix=/opt/lcr --with-asterisk --with-gsm checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... no checking for mawk... mawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking dependency style of gcc... gcc3 checking how to run the C preprocessor... gcc -E checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... gcc3 checking for gcc... (cached) gcc checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ISO C89... (cached) none needed checking dependency style of gcc... (cached) gcc3 checking for a BSD-compatible install... /usr/bin/install -c checking whether make sets $(MAKE)... (cached) yes checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking asterisk/compiler.h usability... yes checking asterisk/compiler.h presence... yes checking for asterisk/compiler.h... yes checking openssl/rsa.h usability... no checking openssl/rsa.h presence... no checking for openssl/rsa.h... no checking for main in -lcrypto... no checking for openbsc/include/openbsc/gsm_data.h... yes checking for main in -lm... yes checking for main in -lncurses... yes checking for main in -lpthread... yes checking for dirent.h that defines DIR... yes checking for library containing opendir... none required checking for ANSI C header files... (cached) yes checking for sys/wait.h that is POSIX.1 compatible... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking netinet/in.h usability... yes checking netinet/in.h presence... yes checking for netinet/in.h... yes checking for stdlib.h... (cached) yes checking for string.h... (cached) yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/ioctl.h usability... yes checking sys/ioctl.h presence... yes checking for sys/ioctl.h... yes checking sys/socket.h usability... yes checking sys/socket.h presence... yes checking for sys/socket.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking for unistd.h... (cached) yes checking ctype.h usability... yes checking ctype.h presence... yes checking for ctype.h... yes checking assert.h usability... yes checking assert.h presence... yes checking for assert.h... yes checking mISDNuser/mbuffer.h usability... no checking mISDNuser/mbuffer.h presence... no checking for mISDNuser/mbuffer.h... no checking for assert.h... (cached) yes checking for stdbool.h that conforms to C99... yes checking for _Bool... yes checking for an ANSI C-conforming const... yes checking for inline... inline checking for pid_t... yes checking whether time.h and sys/time.h may both be included... yes checking whether struct tm is in sys/time.h or time.h... time.h checking vfork.h usability... no checking vfork.h presence... no checking for vfork.h... no checking for fork... yes checking for vfork... yes checking for working fork... yes checking for working vfork... (cached) yes checking whether gcc needs -traditional... no checking whether lstat dereferences a symlink specified with a trailing slash... yes checking whether lstat accepts an empty string... no checking whether lstat dereferences a symlink specified with a trailing slash... (cached) yes checking for stdlib.h... (cached) yes checking for GNU libc compatible malloc... yes checking for working memcmp... yes checking return type of signal handlers... void checking for AIX... no checking minix/config.h usability... no checking minix/config.h presence... no checking for minix/config.h... no checking whether it is safe to define __EXTENSIONS__... yes checking for working strnlen... yes checking for working strtod... yes checking for vprintf... yes checking for _doprnt... no checking for gettimeofday... yes checking for memmove... yes checking for memset... yes checking for mkdir... yes checking for socket... yes checking for strcasecmp... yes checking for strchr... yes checking for strerror... yes checking for strncasecmp... yes checking for strstr... yes checking for strtol... yes checking for strtoul... yes configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands pc1123:/home/user/lcr# make make all-am make[1]: Wej?cie do katalogu `/home/user/lcr' g++ -DHAVE_CONFIG_H -I. -DWITH_GSM -I./openbsc/include -Wall -I/usr/include/mISDNuser -DCONFIG_DATA="\"/usr/local/lcr\"" -DSHARE_DATA="\"/usr/local/lcr\"" -DLOG_DIR="\"/usr/local/lcr\"" -DEXTENSION_DATA="\"/usr/local/lcr/extensions\"" -g -O2 -MT gsm.o -MD -MP -MF .deps/gsm.Tpo -c -o gsm.o gsm.cpp In file included from main.h:135, from gsm.cpp:12: /usr/local/include/mbuffer.h:18:21: error: global.h: Nie ma takiego pliku ani katalogu /usr/local/include/mbuffer.h:19:29: error: enc_statistics.h: Nie ma takiego pliku ani katalogu In file included from main.h:135, from gsm.cpp:12: /usr/local/include/mbuffer.h:32: error: 'PictureStructure' does not name a type /usr/local/include/mbuffer.h:39: error: 'int64' does not name a type /usr/local/include/mbuffer.h:40: error: 'int64' does not name a type /usr/local/include/mbuffer.h:41: error: 'int64' does not name a type /usr/local/include/mbuffer.h:42: error: 'int64' does not name a type /usr/local/include/mbuffer.h:48: error: 'byte' does not name a type /usr/local/include/mbuffer.h:61: error: expected ';' before '*' token /usr/local/include/mbuffer.h:62: error: expected ';' before '*' token /usr/local/include/mbuffer.h:63: error: expected ';' before '*' token /usr/local/include/mbuffer.h:64: error: expected ';' before '*' token /usr/local/include/mbuffer.h:67: error: expected ';' before '*' token /usr/local/include/mbuffer.h:68: error: expected ';' before '*' token /usr/local/include/mbuffer.h:69: error: expected ';' before '*' token /usr/local/include/mbuffer.h:71: error: expected ';' before '*' token /usr/local/include/mbuffer.h:73: error: expected ';' before '*' token /usr/local/include/mbuffer.h:74: error: expected ';' before '*' token /usr/local/include/mbuffer.h:75: error: expected ';' before '*' token /usr/local/include/mbuffer.h:76: error: expected ';' before '*' token /usr/local/include/mbuffer.h:79: error: 'PicMotionParams' does not name a type /usr/local/include/mbuffer.h:80: error: 'PicMotionParams' does not name a type /usr/local/include/mbuffer.h:101: error: 'StatParameters' does not name a type /usr/local/include/mbuffer.h:111: error: expected ';' before '*' token /usr/local/include/mbuffer.h:114: error: expected ';' before '*' token /usr/local/include/mbuffer.h:122: error: 'byte' does not name a type /usr/local/include/mbuffer.h:160: error: expected ';' before '*' token /usr/local/include/mbuffer.h:161: error: expected ';' before '*' token /usr/local/include/mbuffer.h:179: error: variable or field 'init_dpb' declared void /usr/local/include/mbuffer.h:179: error: 'ImageParameters' was not declared in this scope /usr/local/include/mbuffer.h:179: error: 'p_Img' was not declared in this scope /usr/local/include/mbuffer.h:179: error: 'InputParameters' was not declared in this scope /usr/local/include/mbuffer.h:179: error: 'p_Inp' was not declared in this scope /usr/local/include/mbuffer.h:179: error: expected primary-expression before '*' token /usr/local/include/mbuffer.h:179: error: 'dpb' was not declared in this scope /usr/local/include/mbuffer.h:180: error: variable or field 'free_dpb' declared void /usr/local/include/mbuffer.h:180: error: 'ImageParameters' was not declared in this scope /usr/local/include/mbuffer.h:180: error: 'p_Img' was not declared in this scope /usr/local/include/mbuffer.h:180: error: 'InputParameters' was not declared in this scope /usr/local/include/mbuffer.h:180: error: 'p_Inp' was not declared in this scope /usr/local/include/mbuffer.h:180: error: expected primary-expression before '*' token /usr/local/include/mbuffer.h:180: error: 'dpb' was not declared in this scope /usr/local/include/mbuffer.h:182: error: variable or field 'free_frame_store' declared void /usr/local/include/mbuffer.h:182: error: 'ImageParameters' was not declared in this scope /usr/local/include/mbuffer.h:182: error: 'p_Img' was not declared in this scope /usr/local/include/mbuffer.h:182: error: 'InputParameters' was not declared in this scope /usr/local/include/mbuffer.h:182: error: 'p_Inp' was not declared in this scope /usr/local/include/mbuffer.h:182: error: expected primary-expression before '*' token /usr/local/include/mbuffer.h:182: error: 'f' was not declared in this scope /usr/local/include/mbuffer.h:183: error: 'ImageParameters' was not declared in this scope /usr/local/include/mbuffer.h:183: error: 'p_Img' was not declared in this scope /usr/local/include/mbuffer.h:183: error: 'InputParameters' was not declared in this scope /usr/local/include/mbuffer.h:183: error: 'p_Inp' was not declared in this scope /usr/local/include/mbuffer.h:183: error: 'PictureStructure' was not declared in this scope /usr/local/include/mbuffer.h:183: error: expected primary-expression before 'int' /usr/local/include/mbuffer.h:183: error: expected primary-expression before 'int' /usr/local/include/mbuffer.h:183: error: expected primary-expression before 'int' /usr/local/include/mbuffer.h:183: error: expected primary-expression before 'int' /usr/local/include/mbuffer.h:183: error: initializer expression list treated as compound expression /usr/local/include/mbuffer.h:184: error: variable or field 'free_storable_picture' declared void /usr/local/include/mbuffer.h:184: error: 'ImageParameters' was not declared in this scope /usr/local/include/mbuffer.h:184: error: 'p_Img' was not declared in this scope /usr/local/include/mbuffer.h:184: error: 'InputParameters' was not declared in this scope /usr/local/include/mbuffer.h:184: error: 'p_Inp' was not declared in this scope /usr/local/include/mbuffer.h:184: error: expected primary-expression before '*' token /usr/local/include/mbuffer.h:184: error: 'p' was not declared in this scope /usr/local/include/mbuffer.h:185: error: variable or field 'store_picture_in_dpb' declared void /usr/local/include/mbuffer.h:185: error: 'ImageParameters' was not declared in this scope /usr/local/include/mbuffer.h:185: error: 'p_Img' was not declared in this scope /usr/local/include/mbuffer.h:185: error: 'InputParameters' was not declared in this scope /usr/local/include/mbuffer.h:185: error: 'p_Inp' was not declared in this scope /usr/local/include/mbuffer.h:185: error: expected primary-expression before '*' token /usr/local/include/mbuffer.h:185: error: 'p' was not declared in this scope /usr/local/include/mbuffer.h:185: error: 'FrameFormat' was not declared in this scope /usr/local/include/mbuffer.h:185: error: 'output' was not declared in this scope /usr/local/include/mbuffer.h:186: error: variable or field 'replace_top_pic_with_frame' declared void /usr/local/include/mbuffer.h:186: error: 'ImageParameters' was not declared in this scope /usr/local/include/mbuffer.h:186: error: 'p_Img' was not declared in this scope /usr/local/include/mbuffer.h:186: error: 'InputParameters' was not declared in this scope /usr/local/include/mbuffer.h:186: error: 'p_Inp' was not declared in this scope /usr/local/include/mbuffer.h:186: error: expected primary-expression before '*' token /usr/local/include/mbuffer.h:186: error: 'p' was not declared in this scope /usr/local/include/mbuffer.h:186: error: 'FrameFormat' was not declared in this scope /usr/local/include/mbuffer.h:186: error: 'output' was not declared in this scope /usr/local/include/mbuffer.h:187: error: variable or field 'flush_dpb' declared void /usr/local/include/mbuffer.h:187: error: 'ImageParameters' was not declared in this scope /usr/local/include/mbuffer.h:187: error: 'p_Img' was not declared in this scope /usr/local/include/mbuffer.h:187: error: 'InputParameters' was not declared in this scope /usr/local/include/mbuffer.h:187: error: 'p_Inp' was not declared in this scope /usr/local/include/mbuffer.h:187: error: 'FrameFormat' was not declared in this scope /usr/local/include/mbuffer.h:187: error: 'output' was not declared in this scope /usr/local/include/mbuffer.h:188: error: variable or field 'dpb_split_field' declared void /usr/local/include/mbuffer.h:188: error: 'ImageParameters' was not declared in this scope /usr/local/include/mbuffer.h:188: error: 'p_Img' was not declared in this scope /usr/local/include/mbuffer.h:188: error: 'InputParameters' was not declared in this scope /usr/local/include/mbuffer.h:188: error: 'p_Inp' was not declared in this scope /usr/local/include/mbuffer.h:188: error: expected primary-expression before '*' token /usr/local/include/mbuffer.h:188: error: 'fs' was not declared in this scope /usr/local/include/mbuffer.h:189: error: variable or field 'dpb_combine_field' declared void /usr/local/include/mbuffer.h:189: error: 'ImageParameters' was not declared in this scope /usr/local/include/mbuffer.h:189: error: 'p_Img' was not declared in this scope /usr/local/include/mbuffer.h:189: error: 'InputParameters' was not declared in this scope /usr/local/include/mbuffer.h:189: error: 'p_Inp' was not declared in this scope /usr/local/include/mbuffer.h:189: error: expected primary-expression before '*' token /usr/local/include/mbuffer.h:189: error: 'fs' was not declared in this scope /usr/local/include/mbuffer.h:190: error: variable or field 'dpb_combine_field_yuv' declared void /usr/local/include/mbuffer.h:190: error: 'ImageParameters' was not declared in this scope /usr/local/include/mbuffer.h:190: error: 'p_Img' was not declared in this scope /usr/local/include/mbuffer.h:190: error: 'InputParameters' was not declared in this scope /usr/local/include/mbuffer.h:190: error: 'p_Inp' was not declared in this scope /usr/local/include/mbuffer.h:190: error: expected primary-expression before '*' token /usr/local/include/mbuffer.h:190: error: 'fs' was not declared in this scope /usr/local/include/mbuffer.h:191: error: variable or field 'init_lists' declared void /usr/local/include/mbuffer.h:191: error: 'Slice' was not declared in this scope /usr/local/include/mbuffer.h:191: error: 'currSlice' was not declared in this scope /usr/local/include/mbuffer.h:192: error: variable or field 'reorder_ref_pic_list' declared void /usr/local/include/mbuffer.h:192: error: 'Slice' was not declared in this scope /usr/local/include/mbuffer.h:192: error: 'currSlice' was not declared in this scope /usr/local/include/mbuffer.h:192: error: expected primary-expression before '*' token /usr/local/include/mbuffer.h:192: error: 'list' was not declared in this scope /usr/local/include/mbuffer.h:192: error: expected primary-expression before 'char' /usr/local/include/mbuffer.h:192: error: expected primary-expression before 'int' /usr/local/include/mbuffer.h:193: error: variable or field 'init_mbaff_lists' declared void /usr/local/include/mbuffer.h:193: error: 'Slice' was not declared in this scope /usr/local/include/mbuffer.h:193: error: 'currSlice' was not declared in this scope /usr/local/include/mbuffer.h:194: error: variable or field 'alloc_ref_pic_list_reordering_buffer' declared void /usr/local/include/mbuffer.h:194: error: 'Slice' was not declared in this scope /usr/local/include/mbuffer.h:194: error: 'currSlice' was not declared in this scope /usr/local/include/mbuffer.h:195: error: variable or field 'free_ref_pic_list_reordering_buffer' declared void /usr/local/include/mbuffer.h:195: error: 'Slice' was not declared in this scope /usr/local/include/mbuffer.h:195: error: 'currSlice' was not declared in this scope /usr/local/include/mbuffer.h:196: error: variable or field 'fill_frame_num_gap' declared void /usr/local/include/mbuffer.h:196: error: 'ImageParameters' was not declared in this scope /usr/local/include/mbuffer.h:196: error: 'p_Img' was not declared in this scope /usr/local/include/mbuffer.h:196: error: 'InputParameters' was not declared in this scope /usr/local/include/mbuffer.h:196: error: 'p_Inp' was not declared in this scope /usr/local/include/mbuffer.h:196: error: 'FrameFormat' was not declared in this scope /usr/local/include/mbuffer.h:196: error: 'output' was not declared in this scope /usr/local/include/mbuffer.h:199: error: variable or field 'compute_colocated' declared void /usr/local/include/mbuffer.h:199: error: 'Slice' was not declared in this scope /usr/local/include/mbuffer.h:199: error: 'currSlice' was not declared in this scope /usr/local/include/mbuffer.h:199: error: expected primary-expression before '*' token /usr/local/include/mbuffer.h:199: error: 'p' was not declared in this scope /usr/local/include/mbuffer.h:199: error: expected primary-expression before '*' token /usr/local/include/mbuffer.h:199: error: 'listX' was not declared in this scope /usr/local/include/mbuffer.h:202: error: variable or field 'compute_colocated_JV' declared void /usr/local/include/mbuffer.h:202: error: 'Slice' was not declared in this scope /usr/local/include/mbuffer.h:202: error: 'currSlice' was not declared in this scope /usr/local/include/mbuffer.h:202: error: expected primary-expression before '*' token /usr/local/include/mbuffer.h:202: error: 'p' was not declared in this scope /usr/local/include/mbuffer.h:202: error: expected primary-expression before '*' token /usr/local/include/mbuffer.h:202: error: 'listX' was not declared in this scope /usr/local/include/mbuffer.h:203: error: variable or field 'copy_storable_param_JV' declared void /usr/local/include/mbuffer.h:203: error: 'ImageParameters' was not declared in this scope /usr/local/include/mbuffer.h:203: error: 'p_Img' was not declared in this scope /usr/local/include/mbuffer.h:203: error: expected primary-expression before 'int' /usr/local/include/mbuffer.h:203: error: expected primary-expression before '*' token /usr/local/include/mbuffer.h:203: error: 'd' was not declared in this scope /usr/local/include/mbuffer.h:203: error: expected primary-expression before '*' token /usr/local/include/mbuffer.h:203: error: 's' was not declared in this scope In file included from main.h:150, from gsm.cpp:12: mISDN.h:57: error: field 'upqueue' has incomplete type gsm.cpp: In member function 'int Pgsm::bchannel_open(int)': gsm.cpp:135: error: aggregate 'sockaddr_mISDN addr' has incomplete type and cannot be defined gsm.cpp:136: error: aggregate 'mISDNhead act' has incomplete type and cannot be defined gsm.cpp:144: error: 'ISDN_P_B_RAW' was not declared in this scope gsm.cpp:171: error: 'PH_ACTIVATE_REQ' was not declared in this scope gsm.cpp:173: error: 'MISDN_HEADER_LEN' was not declared in this scope gsm.cpp: In member function 'void Pgsm::bchannel_send(unsigned int, unsigned int, unsigned char*, int)': gsm.cpp:240: error: 'MISDN_HEADER_LEN' was not declared in this scope gsm.cpp:241: error: 'buf' was not declared in this scope gsm.cpp:248: error: invalid use of incomplete type 'struct mISDNhead' mISDN.h:117: error: forward declaration of 'struct mISDNhead' gsm.cpp:248: error: 'PH_DATA_REQ' was not declared in this scope gsm.cpp:249: error: invalid use of incomplete type 'struct mISDNhead' mISDN.h:117: error: forward declaration of 'struct mISDNhead' gsm.cpp: In member function 'void Pgsm::trau_receive(void*)': gsm.cpp:312: error: 'PH_DATA_REQ' was not declared in this scope gsm.cpp: In member function 'virtual int Pgsm::handler()': gsm.cpp:1486: error: 'MISDN_HEADER_LEN' was not declared in this scope gsm.cpp:1487: error: 'buffer' was not declared in this scope gsm.cpp:1502: error: invalid use of incomplete type 'struct mISDNhead' mISDN.h:117: error: forward declaration of 'struct mISDNhead' gsm.cpp:1504: error: 'PH_DATA_CNF' was not declared in this scope gsm.cpp:1507: error: 'PH_DATA_IND' was not declared in this scope gsm.cpp:1510: error: 'PH_ACTIVATE_IND' was not declared in this scope gsm.cpp:1513: error: 'PH_DEACTIVATE_IND' was not declared in this scope gsm.cpp: In function 'int gsm_sock_open(char*)': gsm.cpp:1554: error: aggregate 'sockaddr_mISDN addr' has incomplete type and cannot be defined gsm.cpp:1555: error: aggregate 'mISDN_devinfo devinfo' has incomplete type and cannot be defined gsm.cpp:1559: error: 'IMGETCOUNT' was not declared in this scope gsm.cpp:1577: error: 'IMGETDEVINFO' was not declared in this scope gsm.cpp:1582: error: 'ISDN_P_TE_S0' was not declared in this scope gsm.cpp:1585: error: 'ISDN_P_TE_E1' was not declared in this scope gsm.cpp:1592: error: 'ISDN_P_TE_S0' was not declared in this scope make[1]: *** [gsm.o] B??d 1 make[1]: Opuszczenie katalogu `/home/user/lcr' make: *** [all] B??d 2 ------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Mon Nov 23 13:32:39 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Mon, 23 Nov 2009 14:32:39 +0100 Subject: OpenBSC/LCR installation problem In-Reply-To: References: Message-ID: <866320f70911230532s23e6b8a9y4c058042ebe54059@mail.gmail.com> Hi, Are you going to interconnect with ISDN network ? Because you might not need LCR and mISDN at all if you don't. Did you run openbsc as a standalone app already ? Sylvain From dekagramzla at gmail.com Mon Nov 23 17:00:32 2009 From: dekagramzla at gmail.com (Maciej Januszewski) Date: Mon, 23 Nov 2009 18:00:32 +0100 Subject: OpenBSC/LCR installation problem In-Reply-To: <866320f70911230532s23e6b8a9y4c058042ebe54059@mail.gmail.com> References: <866320f70911230532s23e6b8a9y4c058042ebe54059@mail.gmail.com> Message-ID: Actually I don't need the ISDN for now. I just thought that the OpenBSC is not a standalone app and I have to run it with (or by) the LCR. I believe that the installation of the OpenBSC was successful but I'm not sure how to run and test it. The only tutorial I have found on the OpenBSC wiki page was the OpenBSC_LCR one so I was sure its the only way to do it. My mistake. Is there any tutorial explaining how to run/configure OpenBSC as a standalone application ? Maciej Januszewski 2009/11/23 Sylvain Munaut <246tnt at gmail.com> > Hi, > > Are you going to interconnect with ISDN network ? > Because you might not need LCR and mISDN at all if you don't. > > Did you run openbsc as a standalone app already ? > > Sylvain > -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Mon Nov 23 19:19:42 2009 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 23 Nov 2009 20:19:42 +0100 Subject: OpenBSC, 16-in-1 SIM and COMP128v1 authentication Message-ID: <20091123191941.GR13105@prithivi.gnumonks.org> Hi! Today I spent some time investigating the cheap 16-in-1 SIM cards on which we can set our own Ki. This means that those cards can be used for cryptographic authentication with OpenBSC. Finally, we will have not only IMSI-based identification, but actual authentication! I've created a page in the Wiki about those cards: http://openbsc.gnumonks.org/trac/wiki/MagicSIM Using this information, I could send the RUN GSM ALGORITHM APDU to the card and retreive SRES + Kc. The result matched what I can also obtain using the COMP128v1 code from http://www.scard.org/gsm/a3a8.txt I will add Comp128v1 support to OpenBSC as soon as I have tested acutal authentication using this 16-in-1 SIM card. By the way: It would really be great if somebody could hack up a small command line program that can be used to program the Operator Name, Ki, ICCID, IMSI and preferred PLMN into the 16-in-1 SIM. 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 zero-kelvin at gmx.de Mon Nov 23 19:37:49 2009 From: zero-kelvin at gmx.de (dexter) Date: Mon, 23 Nov 2009 20:37:49 +0100 Subject: OpenBSC, 16-in-1 SIM and COMP128v1 authentication In-Reply-To: <20091123191941.GR13105@prithivi.gnumonks.org> References: <20091123191941.GR13105@prithivi.gnumonks.org> Message-ID: <4B0AE48D.7080902@gmx.de> Hi Harald. >By the way: It would really be great if somebody could hack up a small >command >line program that can be used to program the Operator Name, Ki, ICCID, >IMSI and >preferred PLMN into the 16-in-1 SIM. I know how to do that with SCRIPTOR. Should not be that difficult if the PCSC-Bugs will not spoilt it all. (Have seen the strangest things, APDUs with more than 8 byte payload do not transmit !?!? Lets hope the best ;-) I have done the development of my SIM-Sniffer / Protocol dissector. And i will start an own very basic SIM-Card implementation soon for experimental use with openBSC Do you have documentation of the card? We also can do some protocol traces. regards. Philipp From 246tnt at gmail.com Mon Nov 23 19:38:44 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Mon, 23 Nov 2009 20:38:44 +0100 Subject: OpenBSC, 16-in-1 SIM and COMP128v1 authentication In-Reply-To: <20091123191941.GR13105@prithivi.gnumonks.org> References: <20091123191941.GR13105@prithivi.gnumonks.org> Message-ID: <866320f70911231138l722b5567p57fd384a0b73b9fc@mail.gmail.com> > Today I spent some time investigating the cheap 16-in-1 SIM cards on which > we can set our own Ki. ?This means that those cards can be used for > cryptographic authentication with OpenBSC. ?Finally, we will have not only > IMSI-based identification, but actual authentication! I tested some of those last week end and when I verified they work, I ordered a 100 bulk pack so that if anyone is interested I could re-distribute them at events and such. (They're the bare card, no reader included, I mostly wanted 10 or so for myself to put in each of the test phone I use and didn't want to pay for useless readers ...) > I've created a page in the Wiki about those cards: > http://openbsc.gnumonks.org/trac/wiki/MagicSIM I have two models : - SuperSim 16-in-1 - Magic SIM 6-in-1 But it's weird, I didn't program them using the same EF/DF ... Me I just have a EF 3f00 / 000c that contains all the data and not in the same format. > Using this information, I could send the RUN GSM ALGORITHM APDU to the card and > retreive SRES + Kc. ?The result matched what I can also obtain using the > COMP128v1 code from http://www.scard.org/gsm/a3a8.txt Beware that in this code, the test software (main function) swapped Ki and RAND. > By the way: It would really be great if somebody could hack up a small command > line program that can be used to program the Operator Name, Ki, ICCID, IMSI and > preferred PLMN into the 16-in-1 SIM. I've written something like that but it's for the card model I have: http://www.246tnt.com/files/pySim.py It's not command line, I executed the function "format_sim" from an interactive python shell, I just wanted something easy where I could easily send manual command and quickly formats a bunch of cards. I'll see if I can make it more easy and adapt it to support both card model. Sylvain From zero-kelvin at gmx.de Sat Nov 28 10:12:58 2009 From: zero-kelvin at gmx.de (dexter) Date: Sat, 28 Nov 2009 11:12:58 +0100 Subject: OpenBSC, 16-in-1 SIM and COMP128v1 authentication In-Reply-To: <866320f70911231138l722b5567p57fd384a0b73b9fc@mail.gmail.com> References: <20091123191941.GR13105@prithivi.gnumonks.org> <866320f70911231138l722b5567p57fd384a0b73b9fc@mail.gmail.com> Message-ID: <4B10F7AA.8030207@gmx.de> Hi folks, Is here anybody in Berlin who would lend me his 16in1 Sim for a 2 or 3 days? I want to do some tests and maybe want to add functionality to set the operator parameters to my sim protocol analyser. btw.: I am really looking forward to meet you all at the congress. regards. Philipp From womax at gmx.ch Wed Nov 25 09:36:29 2009 From: womax at gmx.ch (WoMax) Date: Wed, 25 Nov 2009 10:36:29 +0100 Subject: nanoBTS 139 for sale Message-ID: <43A0EBE3F06E4A23A3CBF457AC566E47@hal3001> Sorry for this posting, but due a timewaster from berlin the last nanoBTS type 139 is for sale again. It is a siemens branded (MOGIS) nanoBTS type 139, pictures you can see on http://umts.zerber.us It is my last one, there is no PoE included, so the special price is 1900 euro plus shipping. I am currently not in switzerland, I try to get some TETRA equipment, so the shipment will be in the second week of december. Payment to my bank account or PayPal. I sold already a lot of this nanoBTS to members from the openBSC-Group for a good price, thank you to all of you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Wed Nov 25 19:47:28 2009 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 25 Nov 2009 20:47:28 +0100 Subject: Disabling RF for a TRX / Tracking abis NM state Message-ID: <20091125194728.GA22160@prithivi.gnumonks.org> Hi Holger! I'm currently reviewing changeset 2d501ea26a219176b1c556449e45ebd90d4accfb and just noticed that you introduce a new 'int rf_locked' member to struct gsm_bts_trx, which I believe is not needed. We are already tracking the administrative state of all objects in the BTS and mirror their state. The specific state you are looking for should be in gsm_bts_trx.nm_state.administrative I would appreciate if you could fix this. -- - 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 Thu Nov 26 00:44:45 2009 From: zecke at selfish.org (Holger Freyther) Date: Thu, 26 Nov 2009 01:44:45 +0100 Subject: Disabling RF for a TRX / Tracking abis NM state In-Reply-To: <20091125194728.GA22160@prithivi.gnumonks.org> References: <20091125194728.GA22160@prithivi.gnumonks.org> Message-ID: <200911260144.45262.zecke@selfish.org> On Wednesday 25 November 2009 20:47:28 Harald Welte wrote: > Hi Holger! > > I'm currently reviewing changeset 2d501ea26a219176b1c556449e45ebd90d4accfb > and just noticed that you introduce a new 'int rf_locked' member to struct > gsm_bts_trx, which I believe is not needed. > > We are already tracking the administrative state of all objects in the BTS > and mirror their state. > > The specific state you are looking for should be in > gsm_bts_trx.nm_state.administrative > > I would appreciate if you could fix this. > I will, honestly I was just too lazy to figure out if the state is updated, how it should be set on startup. I will try to fix it before FOSS.IN. z. From laforge at gnumonks.org Thu Nov 26 22:43:30 2009 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 26 Nov 2009 23:43:30 +0100 Subject: ARFCN 123 / System Information Type 1 Message-ID: <20091126224330.GT24517@prithivi.gnumonks.org> Hi All! While looking at a wireshark trace (with the newly discovered wireshark system information dissector, for which I'll submit a patch to wireshark later tonight), I just realized that in SI1 we still shend a Cell Allocation of a hardcoded ARFCN 123. So unless you run in GSM900 and you use ARFCN 123, the SI1 content will disagree with the actual radio carrier. This is likely to cause confusion with at least some phones. We already have code to generate the channel lists inside SI messages, but this code is so far not used in the master branch. So this is just a reminder "There is a known Issue". If you want to experiment with a supposed fix for it, try using the system_information branch. 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 laforge at gnumonks.org Thu Nov 26 22:54:21 2009 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 26 Nov 2009 23:54:21 +0100 Subject: Wireshark: Decoding of System Information on BCCH Message-ID: <20091126225421.GU24517@prithivi.gnumonks.org> Hi! As Dieter has noticed, GSM traces from gammu / nokia DCT3 phones show the complete SYS INFO decode inside wireshark. However, the RSL messages BCCH INFORMATION do not decode it. I've revolved this problem and submitted a patch to the wireshark team, you can get it from https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4268 Please note: This patch does not yet address the problem for the SI5/SI6 in SACCH FILLING. The solution is not as easy, since in this case a generic L3 IE is handed of to the GSM_A_DTAP rather than GSM_A_CCCH dissector. If anyone wants to help out with fixing this for the SACCH, I'm sure many OpenBSC users and wireshark guys will be happy to receive a patch/fix. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) -------------- next part -------------- A non-text attachment was scrubbed... Name: rsl-system_info.patch Type: text/x-diff Size: 521 bytes Desc: not available URL: From mohammad.halawah at smartmachine.net Mon Nov 30 13:52:14 2009 From: mohammad.halawah at smartmachine.net (Mohammad Halawah) Date: Mon, 30 Nov 2009 14:52:14 +0100 Subject: Howto collect MSISDN numbers Message-ID: <9787190E3DD5984A9C341CCD0861BDBE5C80FD@smfesrv1.smartmachine.int> Dear openBSC users, This project sounds interesting and promising. I would like to collect MSISDN (mobile numbers) for people attending a fundraising gallery. Then I send them SMS (using the MSISDN list I made) with 5 bucks donation link. Of course I can run with a pen and paper and do that, but instead I would like to use technology to help me. Is this possible to do with openBSC? Or even other GNURadio modules? I am not interested in: using openBSC to make/receive phone calls nor IMSI and TMSI. Bands of interest are: 900/1800 GSM 2100 UMTS In case this is not possible using GNU Radio modules. Is there commercial solutions to do that? Peace, Mohammad Halawah Project Engineer JETZT REGISTRIEREN: Viertelj?hrlicher Newsletter ?ber die Welt der mobilen L?sungen! http://www.smartmachine.net/newsletter.html REGISTER NOW: Quarterly newsletter about the world of mobile solutions! http://www.smartmachine.net/en/newsletter.html smartmachine Forschung & Entwicklung GmbH Sterneckstra?e 33 5020 Salzburg Austria O: + 43 662 880440-52 F: + 43 662 880440-99 M: + 43 664 1101 206 E: mohammad.halawah at smartmachine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Mon Nov 30 20:56:17 2009 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 30 Nov 2009 21:56:17 +0100 Subject: system_information branch updates Message-ID: <20091130205617.GA10213@prithivi.gnumonks.org> Hi! While enroute to FOSS.in in Bangalore, I took the time to test and debug the various issues I could find with the code in the system_information branch. At least in all of my tests, the system information messages, including rest octets and neighbor cell lists are looking perfectly fine. Especially now that with my latest patch, wireshark is able to dissect the SI messages properly, it is much easier to debug :) If you want to give it a try, I recommend using something like git revision 63b152ebb74355acfde76e9ce1113f2d823c0804 of that branch. Please note: We currently only support the relative bitmask format for the neighbor cell lists. That means, you cannot have neighbors with ARFCN's spanning a range of more than 111, i.e. your lowest and highest ARFCN have to be within a distance of 111 ARFCN's. Unless there are major objections, I intend to merge this branch ASAP (or rather do a 'git diff master..system_information' and apply the resulting diff as one commit to master) Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)