From zero-kelvin at gmx.de Tue Jul 2 18:52:29 2013 From: zero-kelvin at gmx.de (dexter) Date: Tue, 02 Jul 2013 20:52:29 +0200 Subject: UPDATE -- Osmocom Berlin User Group meeting -- NEXT MEETING In-Reply-To: <20130605121428.GA10030@nataraja.gnumonks.org> References: <502d01a9.mirider@mirider.augusta.de> <20120818115942.GV29525@prithivi.gnumonks.org> <51AF0097.10402@gmx.de> <20130605121428.GA10030@nataraja.gnumonks.org> Message-ID: <51D3216D.6040802@gmx.de> Hi All. Thank you for all who have sent me a +1 email. I think it is enough interest to continue the meetings on a regular, monthly basis. The meetings will take place always the 2nd wednesday of the month. Thus, the next meeting will be on the 10.07.2013! -------------------------8<------------------------- This is the announcement for the next Osmocom Berlin meeting. Jul 10, 8pm @ CCC Berlin, Marienstr. 11, 10117 Berlin There is no formal presentation scheduled for this meeting. If you are interested to show up, feel free to do so. There is no registration required. The meeting is free as in "free beer", despite no actual free beer being around. -------------------------8<------------------------- I am looking forward to see you there! regards. Philipp From holger at freyther.de Wed Jul 31 20:16:49 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Wed, 31 Jul 2013 22:16:49 +0200 Subject: SGSN Crash Report In-Reply-To: <000301ce77b9$cb9444f0$62bcced0$@net> References: <000601ce6edc$31323ec0$9396bc40$@net> <20130622075032.GB31037@nataraja.gnumonks.org> <001201ce6fc0$2c92df70$85b89e50$@net> <20130624054416.GB21497@xiaoyu.lan> <000301ce77b9$cb9444f0$62bcced0$@net> Message-ID: <20130731201649.GA1625@xiaoyu.lan> On Tue, Jul 02, 2013 at 11:51:49PM -0700, Caleb Pal wrote: > Holger, Hi, I have a reliable re-producer of the issue. It happens when the PCU is dead and we still receive segmented data from the GGSN. The re-producer is inside a branch of mine of the OsmoPCU code[1]. The commit message has some information about how to re-produce (what is missing is the ACL config of the SGSN to allow this test). Maybe you want to try to fix the issue based on this setup? kind regards holger [1] http://git.osmocom.org/osmo-pcu/commit/?h=zecke/features/emulator&id=a727a2e59e5590df01625ae5396e7c8a268c009c From dchardware at gmail.com Sun Jul 28 15:34:57 2013 From: dchardware at gmail.com (Sipos Csaba) Date: Sun, 28 Jul 2013 17:34:57 +0200 Subject: Osmo-nitb v_0.13.0.48-9e22 broke compatibility with Nokia InSite In-Reply-To: <20130630112152.GK23402@xiaoyu.lan> References: <417565018.20130629155826@freemail.hu> <20130629142041.GC3330@xiaoyu.lan> <1355509309.20130629235206@freemail.hu> <20130630060408.GH23402@xiaoyu.lan> <12210700172.20130630120006@freemail.hu> <20130630112152.GK23402@xiaoyu.lan> Message-ID: <351331868.20130728173457@freemail.hu> Hi Holger I've made some progress with the segfault problem regarding Nokia and patch: f5a079f739c57d8be7c59149fd45475c402a45fc It seems if I use "nokia_site skip-reset 1" in the config file, the problem is gone. I am pretty sure after these months, that the problem about the LAPD errors, this segfault problem and the multi-BTS problem is somewhere around the code that is responsible for this reset sequence, because if I turn it off, all problems are gone. Maybe the cause is that the code is not multi-BTS aware (the reset part). For example it sends the RESET code for one BTS (despite the first one got acked properly), but it wont send the RESET code to the other BTS. Another thing is that after the RESET code sent to a particular BTS (and recieved an ack), all LAPD connections should be disconnected and keep it that way, till the RESET_TIMER expires (because NOkia BTS sends garbage on the E1 during reset), then try the bootstrapping again. And this is what actually happens: 1. OpenBSC sends BTS_RESET 2. OpenBSC receives ACK. 3. OpenBSC closes the LAPD connections as it should. 4. But somehow the LAPD connection got restarted during the reset period (some data received from the BTS, there is a lot of unimplemented TRAU warnings because the data is garbage). The problem is that if I have to change some parameters, I have no choice but to use the NOkia reset code, otherwise the parameters are not going to be change in the BTS (despite the successful bootstrapping of OML and RSL). Otherwise the code seems to handle multi Nokia BTSes well. It seems that the solution is somewhere in the code responsible for the reset part. I hope I can get some help from someone who understands the code better. Once again, I am happy to do whatever it takes to sort this out. BR, Csaba > On Sun, Jun 30, 2013 at 12:00:06PM +0200, Sipos Csaba wrote: >> Thanks Holger, > Good Afternoon, >> <0018> input/lapd.c:628 LAPD DL-RELEASE confirm TEI=1 SAPI=62 > this releases the LAPD structures.. (and now sets dl->tx_hist to NULL) >> #0 0xb774c11d in lapd_send_i (line=1606, lctx=) at lapd_core.c:1802 >> 1802 if (!dl->tx_hist[h].msg) { > and it is accessed even after it has been released. Now I don't know > if this access would be legetimate but it is from 'dead' memory. > Could you please create a PCAP file of the communication on the line? > NITB has a config param for that and it should work for LAPD. From holger at freyther.de Sun Jul 28 16:32:09 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sun, 28 Jul 2013 18:32:09 +0200 Subject: Osmo-nitb v_0.13.0.48-9e22 broke compatibility with Nokia InSite In-Reply-To: <351331868.20130728173457@freemail.hu> References: <417565018.20130629155826@freemail.hu> <20130629142041.GC3330@xiaoyu.lan> <1355509309.20130629235206@freemail.hu> <20130630060408.GH23402@xiaoyu.lan> <12210700172.20130630120006@freemail.hu> <20130630112152.GK23402@xiaoyu.lan> <351331868.20130728173457@freemail.hu> Message-ID: <20130728163209.GC3624@xiaoyu.lan> On Sun, Jul 28, 2013 at 05:34:57PM +0200, Sipos Csaba wrote: > Hi Holger > > I've made some progress with the segfault problem regarding Nokia and > patch: f5a079f739c57d8be7c59149fd45475c402a45fc Hi, I can only provide you with debug aid. > It seems if I use "nokia_site skip-reset 1" in the config file, the > problem is gone. I am pretty sure after these months, that the problem > about the LAPD errors, this segfault problem and the multi-BTS problem > is somewhere around the code that is responsible for this reset > sequence, because if I turn it off, all problems are gone. * the reset will lead to LDAP release.. * some one is using the released link.. debug: * Set a breakpoint in the code that is relreasing the hist buff * Once it is hit set a watchpoint on the memory regions... * Figure out who is accessing it first.. * Then try to figure out if that is correct or not ** E.g. do we need to flush a queue> ... From dchardware at gmail.com Sun Jul 28 21:39:05 2013 From: dchardware at gmail.com (Sipos Csaba) Date: Sun, 28 Jul 2013 23:39:05 +0200 Subject: Osmo-nitb v_0.13.0.48-9e22 broke compatibility with Nokia InSite In-Reply-To: <20130728163209.GC3624@xiaoyu.lan> References: <417565018.20130629155826@freemail.hu> <20130629142041.GC3330@xiaoyu.lan> <1355509309.20130629235206@freemail.hu> <20130630060408.GH23402@xiaoyu.lan> <12210700172.20130630120006@freemail.hu> <20130630112152.GK23402@xiaoyu.lan> <351331868.20130728173457@freemail.hu> <20130728163209.GC3624@xiaoyu.lan> Message-ID: <1968404558.20130728233905@freemail.hu> Hey Holger, Thanks for the help. I am a little new in debugging so it might take a while, till I find out why the LAPD connection got reopened after OpenBSC receives the ack for the Nokia reset_req. Until we can figure it out what is the problem, there is a temporary solution. With "nokia_site skip-reset 1" in the config file and with the following modification in bts_nokia_site.c: static int shutdown_om(struct gsm_bts *bts) { /* TODO !? */ LOGP(DNM, LOGL_NOTICE, "Sending Nokia RESET_REQ before shutdown\n"); abis_nm_reset(bts, 1); return 0; } now the reset takes place not during the initialization, but during the shutdown. The result is the same: on the next OpenBSC run all Nokia BTS will be in a "clean restarted" state already, so despite the "skip-reset 1" both the OML and the RSL can be bootstrapped properly. This is not a final solution for sure, there is no exception handling, it doesn't wait for ACK or anything, but at least it seems it is working for now, and there is no LAPD errors and segfault failures neither, even with the "problematic" patch applied. Will test this in 1-2 days, and report back with the results. BR, Csaba > On Sun, Jul 28, 2013 at 05:34:57PM +0200, Sipos Csaba wrote: >> Hi Holger >> >> I've made some progress with the segfault problem regarding Nokia and >> patch: f5a079f739c57d8be7c59149fd45475c402a45fc > Hi, > I can only provide you with debug aid. >> It seems if I use "nokia_site skip-reset 1" in the config file, the >> problem is gone. I am pretty sure after these months, that the problem >> about the LAPD errors, this segfault problem and the multi-BTS problem >> is somewhere around the code that is responsible for this reset >> sequence, because if I turn it off, all problems are gone. > * the reset will lead to LDAP release.. > * some one is using the released link.. > debug: > * Set a breakpoint in the code that is relreasing the hist buff > * Once it is hit set a watchpoint on the memory regions... > * Figure out who is accessing it first.. > * Then try to figure out if that is correct or not > ** E.g. do we need to flush a queue> From holger at freyther.de Mon Jul 29 21:04:17 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 29 Jul 2013 23:04:17 +0200 Subject: Osmo-nitb v_0.13.0.48-9e22 broke compatibility with Nokia InSite In-Reply-To: <1968404558.20130728233905@freemail.hu> References: <417565018.20130629155826@freemail.hu> <20130629142041.GC3330@xiaoyu.lan> <1355509309.20130629235206@freemail.hu> <20130630060408.GH23402@xiaoyu.lan> <12210700172.20130630120006@freemail.hu> <20130630112152.GK23402@xiaoyu.lan> <351331868.20130728173457@freemail.hu> <20130728163209.GC3624@xiaoyu.lan> <1968404558.20130728233905@freemail.hu> Message-ID: <20130729210417.GC7983@xiaoyu.lan> On Sun, Jul 28, 2013 at 11:39:05PM +0200, Sipos Csaba wrote: > Hey Holger, > > Thanks for the help. I am a little new in debugging so it might take a > while, till I find out why the LAPD connection got reopened after > OpenBSC receives the ack for the Nokia reset_req. Just try, don't be afraid. We are happy to answer any self motivated technical question. We all had to learn how to use gdb and various other tools. > Will test this in 1-2 days, and report back with the results. great From dchardware at gmail.com Tue Jul 30 20:16:34 2013 From: dchardware at gmail.com (Sipos Csaba) Date: Tue, 30 Jul 2013 22:16:34 +0200 Subject: Osmo-nitb v_0.13.0.48-9e22 broke compatibility with Nokia InSite In-Reply-To: <20130729210417.GC7983@xiaoyu.lan> References: <417565018.20130629155826@freemail.hu> <20130629142041.GC3330@xiaoyu.lan> <1355509309.20130629235206@freemail.hu> <20130630060408.GH23402@xiaoyu.lan> <12210700172.20130630120006@freemail.hu> <20130630112152.GK23402@xiaoyu.lan> <351331868.20130728173457@freemail.hu> <20130728163209.GC3624@xiaoyu.lan> <1968404558.20130728233905@freemail.hu> <20130729210417.GC7983@xiaoyu.lan> Message-ID: <1225112845.20130730221634@freemail.hu> Hey Holger, Thanks for the support. If you or anybody can answer to one question, it would help the debugging very much: In your opinion without explicitly closing the OML and RSL lapd connection, it is possible, that even after a RELEASE CONFIRMed lapd connection got restarted improperly, if it receives data from the BTS? Because that is exactly what is happening: 1. OpenBSC send RESET_REQ to Nokia BTS 2. OpenBSC receives ACK from the BTS 3. OpenBSC releases the LAPD connection (but not closes it, like with Ctrl+C) 4. Some data received by OpenBSC via the E1 link, and the lapd connection for OML got restarted (despite we are in the RESET state and RESET_TIMER not expired yet) According to Dieter (who helped a lot), during the RESET NOkia BTS sends garbage on the E1 link, therefore during the reset it is wise not to listen on any timeslots, until the RESET_TIMER expires (15-20 seconds). According to him, it was working like this with mISDN, but there was no DAHDI when he wrote the Nokia related codes, and now he don't have much time to debug this issue. SO the problem is that the LAPD connection somehow got restarted though it shouldn't durin the RESET state. So this is where I am at the moment. BR, Csaba > Just try, don't be afraid. We are happy to answer any self motivated > technical question. We all had to learn how to use gdb and various > other tools. >> Will test this in 1-2 days, and report back with the results. > great From galersekali at gmail.com Mon Jul 1 05:23:52 2013 From: galersekali at gmail.com (anak galer) Date: Mon, 1 Jul 2013 12:23:52 +0700 Subject: have some good,anyone interested ? Message-ID: Hello folks I have some goods of the CDMA device, anyone is interested to research it? 1.Ceragon ODU 15HPS-1R-RFU-6H 2.Alcatel 9400AWY Cheers! From alexander.chemeris at gmail.com Wed Jul 3 06:19:45 2013 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Wed, 3 Jul 2013 10:19:45 +0400 Subject: [PATCH] Fix IE lengths in the sgsn code Message-ID: Hi all, Attached patch fixes lengths of MS Network Capability and MS Radio Access Capability elements. Original code was inconsistent about lengths and could lead to out of bounds write. Lengths were also inconsistent with the TS 24.008. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-sgsn-Fix-lengths-of-MS-Network-Capability-and-MS-Rad.patch Type: application/octet-stream Size: 2503 bytes Desc: not available URL: From holger at freyther.de Wed Jul 3 07:08:12 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Wed, 3 Jul 2013 09:08:12 +0200 Subject: [PATCH] Fix IE lengths in the sgsn code In-Reply-To: References: Message-ID: <20130703070812.GA6485@xiaoyu.lan> On Wed, Jul 03, 2013 at 10:19:45AM +0400, Alexander Chemeris wrote: > Hi all, > > Attached patch fixes lengths of MS Network Capability and MS Radio > Access Capability elements. > > Original code was inconsistent about lengths and could lead to out of > bounds write. Lengths were also inconsistent with the TS 24.008. Hi, maybe add a "Fixes Coverity CID 1040714" to the commit message, or at least "found by coverity"? the patches looks fine. holger From alexander.chemeris at gmail.com Wed Jul 3 07:28:16 2013 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Wed, 3 Jul 2013 11:28:16 +0400 Subject: [PATCH] Fix IE lengths in the sgsn code In-Reply-To: <20130703070812.GA6485@xiaoyu.lan> References: <20130703070812.GA6485@xiaoyu.lan> Message-ID: Hi, On Wed, Jul 3, 2013 at 11:08 AM, Holger Hans Peter Freyther wrote: > On Wed, Jul 03, 2013 at 10:19:45AM +0400, Alexander Chemeris wrote: >> Hi all, >> >> Attached patch fixes lengths of MS Network Capability and MS Radio >> Access Capability elements. >> >> Original code was inconsistent about lengths and could lead to out of >> bounds write. Lengths were also inconsistent with the TS 24.008. > > maybe add a "Fixes Coverity CID 1040714" to the commit message, or at > least "found by coverity"? I think it's a good idea, but it's up to you to establish the workflow. Feel free to add one of these lines to the commit message. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From holger at freyther.de Wed Jul 3 08:14:07 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Wed, 3 Jul 2013 10:14:07 +0200 Subject: [PATCH] Fix IE lengths in the sgsn code In-Reply-To: References: <20130703070812.GA6485@xiaoyu.lan> Message-ID: <20130703081407.GB6485@xiaoyu.lan> On Wed, Jul 03, 2013 at 11:28:16AM +0400, Alexander Chemeris wrote: > > I think it's a good idea, but it's up to you to establish the > workflow. Feel free to add one of these lines to the commit message. As long as it contains the "CID ..." it is fine. On the other hand could you please elaborate on why you picked "50"? This looks a bit too small. "MS Radio Access capability ... LV 6 - 52" -- Table 9.4.1 "The MS RA capability is a type 4 information element, with a maximum length of 52 octets." -- 10.5.5.12a So if I remove one byte for the length, then the Capa can still be 51 bytes? How do you end up with 50? holger PS: I didn't look at the other hunk and this size From alexander.chemeris at gmail.com Wed Jul 3 20:54:17 2013 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Thu, 4 Jul 2013 00:54:17 +0400 Subject: [PATCH] Fix IE lengths in the sgsn code In-Reply-To: <20130703081407.GB6485@xiaoyu.lan> References: <20130703070812.GA6485@xiaoyu.lan> <20130703081407.GB6485@xiaoyu.lan> Message-ID: On Wed, Jul 3, 2013 at 12:14 PM, Holger Hans Peter Freyther wrote: > On the other hand could > you please elaborate on why you picked "50"? This looks a bit too small. > > "MS Radio Access capability ... LV 6 - 52" > -- Table 9.4.1 > > > "The MS RA capability is a type 4 information element, with a maximum > length of 52 octets." > > -- 10.5.5.12a > > > So if I remove one byte for the length, then the Capa can still be 51 > bytes? How do you end up with 50? I based my calculations on the "Figure 10.5.128a/3GPP TS 24.008 MS Radio Access Capability information element". I.e. I assumed that 52 octets are in case of TLV, i.e. including IEI and Length octets. I'm not sure why do they include IEI for Type 4 (LV) IEs - probably for consistency. > PS: I didn't look at the other hunk and this size Same logic as above. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From holger at freyther.de Thu Jul 4 05:35:17 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Thu, 4 Jul 2013 07:35:17 +0200 Subject: [PATCH] Fix IE lengths in the sgsn code In-Reply-To: References: <20130703070812.GA6485@xiaoyu.lan> <20130703081407.GB6485@xiaoyu.lan> Message-ID: <20130704053517.GA25727@xiaoyu.lan> On Thu, Jul 04, 2013 at 12:54:17AM +0400, Alexander Chemeris wrote: > > "MS Radio Access capability ... LV 6 - 52" > > -- Table 9.4.1 > > So if I remove one byte for the length, then the Capa can still be 51 > > bytes? How do you end up with 50? > > I based my calculations on the "Figure 10.5.128a/3GPP TS 24.008 MS > Radio Access Capability information element". I.e. I assumed that 52 > octets are in case of TLV, i.e. including IEI and Length octets. I'm > not sure why do they include IEI for Type 4 (LV) IEs - probably for > consistency. But do you agree that if Table 9.4.1 claims that LV take up to 52 bytes that V can be either 51 or the table is wrong? holger From alexander.chemeris at gmail.com Thu Jul 4 06:05:51 2013 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Thu, 4 Jul 2013 10:05:51 +0400 Subject: [PATCH] Fix IE lengths in the sgsn code In-Reply-To: <20130704053517.GA25727@xiaoyu.lan> References: <20130703070812.GA6485@xiaoyu.lan> <20130703081407.GB6485@xiaoyu.lan> <20130704053517.GA25727@xiaoyu.lan> Message-ID: On Thu, Jul 4, 2013 at 9:35 AM, Holger Hans Peter Freyther wrote: > On Thu, Jul 04, 2013 at 12:54:17AM +0400, Alexander Chemeris wrote: >> > "MS Radio Access capability ... LV 6 - 52" >> > -- Table 9.4.1 > >> > So if I remove one byte for the length, then the Capa can still be 51 >> > bytes? How do you end up with 50? >> >> I based my calculations on the "Figure 10.5.128a/3GPP TS 24.008 MS >> Radio Access Capability information element". I.e. I assumed that 52 >> octets are in case of TLV, i.e. including IEI and Length octets. I'm >> not sure why do they include IEI for Type 4 (LV) IEs - probably for >> consistency. > > But do you agree that if Table 9.4.1 claims that LV take up to 52 > bytes that V can be either 51 or the table is wrong? Which version of the document are you looking at? I have "3GPP TS 24.008 V12.2.0 (2013-06)" and in the Table 9.4.1 it claims Length to be "6 - 51", which makes exactly 50 octets max without L octet. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From holger at freyther.de Thu Jul 4 11:18:25 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Thu, 4 Jul 2013 13:18:25 +0200 Subject: [PATCH] Fix IE lengths in the sgsn code In-Reply-To: References: <20130703070812.GA6485@xiaoyu.lan> <20130703081407.GB6485@xiaoyu.lan> <20130704053517.GA25727@xiaoyu.lan> Message-ID: <20130704111825.GC25727@xiaoyu.lan> On Thu, Jul 04, 2013 at 10:05:51AM +0400, Alexander Chemeris wrote: > Which version of the document are you looking at? > I have "3GPP TS 24.008 V12.2.0 (2013-06)" and in the Table 9.4.1 it > claims Length to be "6 - 51", which makes exactly 50 octets max without L octet. Interesting, I have 3GPP TS 24.008 version 7.6.0 Release 7, ETSI TS 124 008 V7.6.0 (2006-12). So they have fixed/changed this in newer versions. :) cheers holger From holger at freyther.de Wed Jul 3 08:16:05 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Wed, 3 Jul 2013 10:16:05 +0200 Subject: Dropping support for the HSL bts Message-ID: <20130703081605.GC6485@xiaoyu.lan> Good Morning Harald, do you mind if we drop support for the HSL BTS? The support is spewing out compile warnings, now turns up in coverity reports as well and we don't even know if it is working with the latest version of the software running on these BTS. holger From holger at freyther.de Wed Jul 3 14:10:35 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Wed, 3 Jul 2013 16:10:35 +0200 Subject: [PATCH] hsl: Remove the support for the HSL bts from OpenBSC In-Reply-To: <20130703081605.GC6485@xiaoyu.lan> References: <20130703081605.GC6485@xiaoyu.lan> Message-ID: <1372860635-19727-1-git-send-email-holger@freyther.de> From: Holger Hans Peter Freyther The support has been implemented for an old model, we were told that newer versions would be made incompatible with OpenBSC. Ther are various warnings in the code and coverity has found some new ones. Just remove the code as we don't know of anyone using this code. --- openbsc/doc/examples/osmo-nitb/hsl/openbsc.cfg | 90 ------- openbsc/include/openbsc/bss.h | 1 - openbsc/include/openbsc/gsm_data_shared.h | 4 - openbsc/osmoappdesc.py | 4 +- openbsc/src/libbsc/Makefile.am | 1 - openbsc/src/libbsc/abis_nm.c | 4 - openbsc/src/libbsc/abis_rsl.c | 6 - openbsc/src/libbsc/bsc_init.c | 25 +- openbsc/src/libbsc/bsc_vty.c | 48 ---- openbsc/src/libbsc/bts_hsl_femtocell.c | 309 ------------------------ openbsc/src/libbsc/bts_init.c | 1 - openbsc/src/libbsc/e1_config.c | 3 +- openbsc/src/libbsc/system_information.c | 4 - openbsc/src/libcommon/gsm_data.c | 4 - 14 files changed, 6 insertions(+), 498 deletions(-) delete mode 100644 openbsc/doc/examples/osmo-nitb/hsl/openbsc.cfg delete mode 100644 openbsc/src/libbsc/bts_hsl_femtocell.c diff --git a/openbsc/doc/examples/osmo-nitb/hsl/openbsc.cfg b/openbsc/doc/examples/osmo-nitb/hsl/openbsc.cfg deleted file mode 100644 index b0af855..0000000 --- a/openbsc/doc/examples/osmo-nitb/hsl/openbsc.cfg +++ /dev/null @@ -1,90 +0,0 @@ -! -! OpenBSC (0.9.11.261-32c0) configuration saved from vty -!! -password foo -! -line vty - no login -! -e1_input - e1_line 0 driver hsl -network - network country code 262 - mobile network code 42 - short name OpenBSC - long name OpenBSC - auth policy closed - location updating reject cause 13 - encryption a5 0 - neci 1 - paging any use tch 0 - rrlp mode none - mm info 0 - handover 0 - handover window rxlev averaging 10 - handover window rxqual averaging 1 - handover window rxlev neighbor averaging 10 - handover power budget interval 6 - handover power budget hysteresis 3 - handover maximum distance 9999 - timer t3101 10 - timer t3103 0 - timer t3105 0 - timer t3107 0 - timer t3109 4 - timer t3111 0 - timer t3113 60 - timer t3115 0 - timer t3117 0 - timer t3119 0 - timer t3122 0 - timer t3141 0 - dtx-used 1 - subscriber-keep-in-ram 0 - bts 0 - type hsl_femto - band DCS1800 - cell_identity 0 - location_area_code 1 - training_sequence_code 0 - base_station_id_code 0 - ms max power 15 - cell reselection hysteresis 4 - rxlev access min 0 - channel allocator ascending - rach tx integer 9 - rach max transmission 1 - hsl serial-number 8303701 - neighbor-list mode automatic - oml hsl line 0 - gprs mode none - trx 0 - rf_locked 0 - arfcn 871 - nominal power 23 - max_power_red 20 - rsl e1 tei 0 - timeslot 0 - phys_chan_config CCCH+SDCCH4 - hopping enabled 0 - timeslot 1 - phys_chan_config TCH/F - hopping enabled 0 - timeslot 2 - phys_chan_config TCH/F - hopping enabled 0 - timeslot 3 - phys_chan_config TCH/F - hopping enabled 0 - timeslot 4 - phys_chan_config TCH/F - hopping enabled 0 - timeslot 5 - phys_chan_config TCH/F - hopping enabled 0 - timeslot 6 - phys_chan_config TCH/F - hopping enabled 0 - timeslot 7 - phys_chan_config TCH/F - hopping enabled 0 diff --git a/openbsc/include/openbsc/bss.h b/openbsc/include/openbsc/bss.h index 1c6b5c3..49df547 100644 --- a/openbsc/include/openbsc/bss.h +++ b/openbsc/include/openbsc/bss.h @@ -13,7 +13,6 @@ extern int bts_init(void); extern int bts_model_bs11_init(void); extern int bts_model_rbs2k_init(void); extern int bts_model_nanobts_init(void); -extern int bts_model_hslfemto_init(void); extern int bts_model_nokia_site_init(void); extern int bts_model_sysmobts_init(void); #endif diff --git a/openbsc/include/openbsc/gsm_data_shared.h b/openbsc/include/openbsc/gsm_data_shared.h index 8e704d0..d3e5102 100644 --- a/openbsc/include/openbsc/gsm_data_shared.h +++ b/openbsc/include/openbsc/gsm_data_shared.h @@ -390,7 +390,6 @@ enum gsm_bts_type { GSM_BTS_TYPE_BS11, GSM_BTS_TYPE_NANOBTS, GSM_BTS_TYPE_RBS2000, - GSM_BTS_TYPE_HSL_FEMTO, GSM_BTS_TYPE_NOKIA_SITE, GSM_BTS_TYPE_OSMO_SYSMO, _NUM_GSM_BTS_TYPE @@ -628,9 +627,6 @@ struct gsm_bts { } tf; } rbs2000; struct { - unsigned long serno; - } hsl; - struct { uint8_t bts_type; unsigned int configured:1, skip_reset:1, diff --git a/openbsc/osmoappdesc.py b/openbsc/osmoappdesc.py index 19ec6c3..9d6fbe6 100644 --- a/openbsc/osmoappdesc.py +++ b/openbsc/osmoappdesc.py @@ -33,7 +33,7 @@ app_configs = { "mgcp": ["doc/examples/osmo-bsc_mgcp/mgcp.cfg"], "gbproxy": ["doc/examples/osmo-gbproxy/osmo-gbproxy.cfg"], "sgsn": ["doc/examples/osmo-sgsn/osmo-sgsn.cfg"], - "nitb": ["doc/examples/osmo-nitb/hsl/openbsc.cfg", + "nitb": ["doc/examples/osmo-nitb/nanobts/openbsc-multitrx.cfg", "doc/examples/osmo-nitb/nanobts/openbsc.cfg"] } @@ -47,6 +47,6 @@ apps = [(4242, "src/osmo-bsc/osmo-bsc", "OsmoBSC", "osmo-bsc"), ] vty_command = ["./src/osmo-nitb/osmo-nitb", "-c", - "doc/examples/osmo-nitb/hsl/openbsc.cfg"] + "doc/examples/osmo-nitb/nanobts/openbsc.cfg"] vty_app = apps[-1] diff --git a/openbsc/src/libbsc/Makefile.am b/openbsc/src/libbsc/Makefile.am index f5b1ff1..42fabab 100644 --- a/openbsc/src/libbsc/Makefile.am +++ b/openbsc/src/libbsc/Makefile.am @@ -12,7 +12,6 @@ libbsc_a_SOURCES = abis_nm.c abis_nm_vty.c \ bts_ipaccess_nanobts.c \ bts_siemens_bs11.c \ bts_nokia_site.c \ - bts_hsl_femtocell.c \ bts_unknown.c \ bts_sysmobts.c \ chan_alloc.c \ diff --git a/openbsc/src/libbsc/abis_nm.c b/openbsc/src/libbsc/abis_nm.c index adc2362..ee1fc9c 100644 --- a/openbsc/src/libbsc/abis_nm.c +++ b/openbsc/src/libbsc/abis_nm.c @@ -632,10 +632,6 @@ static int abis_nm_rcvmsg_fom(struct msgb *mb) osmo_signal_dispatch(SS_NM, S_NM_IPACC_RESTART_NACK, NULL); break; case NM_MT_SET_BTS_ATTR_ACK: - /* The HSL wants an OPSTART _after_ the SI has been set */ - if (sign_link->trx->bts->type == GSM_BTS_TYPE_HSL_FEMTO) { - abis_nm_opstart(sign_link->trx->bts, NM_OC_BTS, 255, 255, 255); - } break; } diff --git a/openbsc/src/libbsc/abis_rsl.c b/openbsc/src/libbsc/abis_rsl.c index 7aae590..41bfcdc 100644 --- a/openbsc/src/libbsc/abis_rsl.c +++ b/openbsc/src/libbsc/abis_rsl.c @@ -722,12 +722,6 @@ static int rsl_rf_chan_release(struct gsm_lchan *lchan, int error, rc = abis_rsl_sendmsg(msg); /* BTS will respond by RF CHAN REL ACK */ -#ifdef HSL_SR_1_0 - /* The HSL Femto seems to 'forget' sending a REL ACK for TS1...TS7 */ - if (lchan->ts->trx->bts->type == GSM_BTS_TYPE_HSL_FEMTO && lchan->ts->nr != 0) - rc = rsl_rx_rf_chan_rel_ack(lchan); -#endif - return rc; } diff --git a/openbsc/src/libbsc/bsc_init.c b/openbsc/src/libbsc/bsc_init.c index 2fb4f13..8fd72cf 100644 --- a/openbsc/src/libbsc/bsc_init.c +++ b/openbsc/src/libbsc/bsc_init.c @@ -38,7 +38,6 @@ /* global pointer to the gsm network data structure */ extern struct gsm_network *bsc_gsmnet; -extern int hsl_setup(struct gsm_network *gsmnet); /* Callback function for NACK on the OML NM */ static int oml_msg_nack(struct nm_nack_signal_data *nack) @@ -98,7 +97,7 @@ int bsc_shutdown_net(struct gsm_network *net) static int rsl_si(struct gsm_bts_trx *trx, enum osmo_sysinfo_type i, int si_len) { struct gsm_bts *bts = trx->bts; - int rc, j; + int rc; DEBUGP(DRR, "SI%s: %s\n", get_value_string(osmo_sitype_strs, i), osmo_hexdump(GSM_BTS_SI(bts, i), GSM_MACBLOCK_LEN)); @@ -108,26 +107,8 @@ static int rsl_si(struct gsm_bts_trx *trx, enum osmo_sysinfo_type i, int si_len) case SYSINFO_TYPE_5bis: case SYSINFO_TYPE_5ter: case SYSINFO_TYPE_6: - if (trx->bts->type == GSM_BTS_TYPE_HSL_FEMTO) { - /* HSL has mistaken SACCH INFO MODIFY for SACCH FILLING, - * so we need a special workaround here */ - /* This assumes a combined BCCH and TCH on TS1...7 */ - for (j = 0; j < 4; j++) - rsl_sacch_info_modify(&trx->ts[0].lchan[j], - osmo_sitype2rsl(i), - GSM_BTS_SI(bts, i), si_len); - for (j = 1; j < 8; j++) { - rsl_sacch_info_modify(&trx->ts[j].lchan[0], - osmo_sitype2rsl(i), - GSM_BTS_SI(bts, i), si_len); - rsl_sacch_info_modify(&trx->ts[j].lchan[1], - osmo_sitype2rsl(i), - GSM_BTS_SI(bts, i), si_len); - } - rc = 0; - } else - rc = rsl_sacch_filling(trx, osmo_sitype2rsl(i), - GSM_BTS_SI(bts, i), si_len); + rc = rsl_sacch_filling(trx, osmo_sitype2rsl(i), + GSM_BTS_SI(bts, i), si_len); break; default: rc = rsl_bcch_info(trx, osmo_sitype2rsl(i), diff --git a/openbsc/src/libbsc/bsc_vty.c b/openbsc/src/libbsc/bsc_vty.c index b98ef15..6c58ff1 100644 --- a/openbsc/src/libbsc/bsc_vty.c +++ b/openbsc/src/libbsc/bsc_vty.c @@ -276,8 +276,6 @@ static void bts_dump_vty(struct vty *vty, struct gsm_bts *bts) vty_out(vty, " Unit ID: %u/%u/0, OML Stream ID 0x%02x%s", bts->ip_access.site_id, bts->ip_access.bts_id, bts->oml_tei, VTY_NEWLINE); - else if (bts->type == GSM_BTS_TYPE_HSL_FEMTO) - vty_out(vty, " Serial Number: %lu%s", bts->hsl.serno, VTY_NEWLINE); else if (bts->type == GSM_BTS_TYPE_NOKIA_SITE) vty_out(vty, " Skip Reset: %d%s", bts->nokia.skip_reset, VTY_NEWLINE); @@ -560,11 +558,6 @@ static void config_write_bts_single(struct vty *vty, struct gsm_bts *bts) vty_out(vty, " oml ip.access stream_id %u line %u%s", bts->oml_tei, bts->oml_e1_link.e1_nr, VTY_NEWLINE); break; - case GSM_BTS_TYPE_HSL_FEMTO: - vty_out(vty, " hsl serial-number %lu%s", bts->hsl.serno, VTY_NEWLINE); - vty_out(vty, " oml hsl line %u%s", - bts->oml_e1_link.e1_nr, VTY_NEWLINE); - break; case GSM_BTS_TYPE_NOKIA_SITE: vty_out(vty, " nokia_site skip-reset %d%s", bts->nokia.skip_reset, VTY_NEWLINE); break; @@ -1665,25 +1658,6 @@ DEFUN(cfg_bts_rsl_ip, } -DEFUN(cfg_bts_serno, - cfg_bts_serno_cmd, - "hsl serial-number STRING", - "HSL BTS specific options\n" - "Set the HSL Serial Number of this BTS\n" - "Serial Number of this HSL BTS\n") -{ - struct gsm_bts *bts = vty->index; - - if (bts->type != GSM_BTS_TYPE_HSL_FEMTO) { - vty_out(vty, "%% BTS is not of HSL type%s", VTY_NEWLINE); - return CMD_WARNING; - } - - bts->hsl.serno = strtoul(argv[0], NULL, 10); - - return CMD_SUCCESS; -} - DEFUN(cfg_bts_nokia_site_skip_reset, cfg_bts_nokia_site_skip_reset_cmd, "nokia_site skip-reset (0|1)", @@ -1728,26 +1702,6 @@ DEFUN(cfg_bts_stream_id, return CMD_SUCCESS; } -DEFUN(cfg_bts_hsl_oml, - cfg_bts_hsl_oml_cmd, - "oml hsl line E1_LINE", - OML_STR "HSL femto Specific Options\n" - "Set OML link of this HSL femto BTS\n" - "Virtual E1/T1 line number\n") -{ - struct gsm_bts *bts = vty->index; - int linenr = atoi(argv[0]); - - if (!(bts->type == GSM_BTS_TYPE_HSL_FEMTO)) { - vty_out(vty, "%% BTS is not of HSL type%s", VTY_NEWLINE); - return CMD_WARNING; - } - - bts->oml_e1_link.e1_nr = linenr; - - return CMD_SUCCESS; -} - #define OML_E1_STR OML_STR "OML E1/T1 Configuration\n" DEFUN(cfg_bts_oml_e1, @@ -3084,10 +3038,8 @@ int bsc_vty_init(const struct log_info *cat) install_element(BTS_NODE, &cfg_bts_rsl_ip_cmd); install_element(BTS_NODE, &cfg_bts_timezone_cmd); install_element(BTS_NODE, &cfg_bts_no_timezone_cmd); - install_element(BTS_NODE, &cfg_bts_serno_cmd); install_element(BTS_NODE, &cfg_bts_nokia_site_skip_reset_cmd); install_element(BTS_NODE, &cfg_bts_stream_id_cmd); - install_element(BTS_NODE, &cfg_bts_hsl_oml_cmd); install_element(BTS_NODE, &cfg_bts_oml_e1_cmd); install_element(BTS_NODE, &cfg_bts_oml_e1_tei_cmd); install_element(BTS_NODE, &cfg_bts_challoc_cmd); diff --git a/openbsc/src/libbsc/bts_hsl_femtocell.c b/openbsc/src/libbsc/bts_hsl_femtocell.c deleted file mode 100644 index 1ce3eaa..0000000 --- a/openbsc/src/libbsc/bts_hsl_femtocell.c +++ /dev/null @@ -1,309 +0,0 @@ -/* OpenBSC support code for HSL Femtocell */ - -/* (C) 2011 by Harald Welte - * (C) 2011 by OnWaves - * - * All Rights Reserved - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU Affero General Public License as published by - * the Free Software Foundation; either version 3 of the License, or - * (at your option) any later version. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU Affero General Public License for more details. - * - * You should have received a copy of the GNU Affero General Public License - * along with this program. If not, see . - * - */ - -#include - -#include - -#include -#include -#include -#include -#include -#include -#include -#include -#include - -static int bts_model_hslfemto_start(struct gsm_network *net); -static void bts_model_hslfemto_e1line_bind_ops(struct e1inp_line *line); - -static struct gsm_bts_model model_hslfemto = { - .type = GSM_BTS_TYPE_HSL_FEMTO, - .start = bts_model_hslfemto_start, - .e1line_bind_ops = &bts_model_hslfemto_e1line_bind_ops, - .nm_att_tlvdef = { - .def = { - /* no HSL specific OML attributes that we know of */ - }, - }, -}; - - -static const uint8_t l1_msg[] = { -#ifdef HSL_SR_1_0 - 0x80, 0x8a, -#else - 0x81, 0x8a, -#endif - 0xC4, 0x0b, -}; - -static const uint8_t conn_trau_msg[] = { -#ifdef HSL_SR_1_0 - 0x80, 0x81, -#else - 0x81, 0x81, -#endif - 0xC1, 16, - 0x02, 0x00, 0x00, 0x00, 0xC0, 0xA8, 0xEA, 0x01, - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 -}; - -static const uint8_t conn_trau_msg2[] = { -#ifdef HSL_SR_1_0 - 0x80, 0x81, -#else - 0x81, 0x81, -#endif - 0xC1, 16, - 0x02, 0x00, 0xd4, 0x07, 0xC0, 0xA8, 0xEA, 0x01, - 0x38, 0xA4, 0x45, 0x00, 0x04, 0x59, 0x40, 0x00 -}; - -static uint8_t oml_arfcn_bsic[] = { -#ifdef HSL_SR_1_0 - 0x81, 0x80, 0x00, 10, -#else - 0x80, 0x80, 0x00, 10, -#endif - NM_MT_SET_BTS_ATTR, NM_OC_BTS, 0xff, 0xff, 0xff, - NM_ATT_BCCH_ARFCN, 0x03, 0x67, - NM_ATT_BSIC, 0x00 -}; - -static inline struct msgb *hsl_alloc_msgb(void) -{ - return msgb_alloc_headroom(1024, 127, "HSL"); -} - -static int hslfemto_bootstrap_om(struct gsm_bts *bts) -{ - struct msgb *msg; - - msg = hsl_alloc_msgb(); - msgb_put(msg, sizeof(l1_msg)); - memcpy(msg->data, l1_msg, sizeof(l1_msg)); - msg->dst = bts->c0->rsl_link; - abis_rsl_sendmsg(msg); - -#if 1 - msg = hsl_alloc_msgb(); - msgb_put(msg, sizeof(conn_trau_msg)); - memcpy(msg->data, conn_trau_msg, sizeof(conn_trau_msg)); - msg->dst = bts->c0->rsl_link; - abis_rsl_sendmsg(msg); -#endif - msg = hsl_alloc_msgb(); - msgb_put(msg, sizeof(conn_trau_msg2)); - memcpy(msg->data, conn_trau_msg2, sizeof(conn_trau_msg2)); - msg->dst = bts->c0->rsl_link; - abis_rsl_sendmsg(msg); - - *((uint16_t *)oml_arfcn_bsic+10) = htons(bts->c0->arfcn); - oml_arfcn_bsic[13] = bts->bsic; - - msg = hsl_alloc_msgb(); - msgb_put(msg, sizeof(oml_arfcn_bsic)); - memcpy(msg->data, oml_arfcn_bsic, sizeof(oml_arfcn_bsic)); - msg->dst = bts->c0->rsl_link; - abis_sendmsg(msg); - - /* Delay the OPSTART until after SI have been set via RSL */ - //abis_nm_opstart(bts, NM_OC_BTS, 255, 255, 255); - - return 0; -} - -/* Callback function to be called every time we receive a signal from INPUT */ -static int inp_sig_cb(unsigned int subsys, unsigned int signal, - void *handler_data, void *signal_data) -{ - struct input_signal_data *isd = signal_data; - - if (subsys != SS_L_INPUT) - return 0; - - switch (signal) { - case S_L_INP_TEI_UP: - switch (isd->link_type) { - case E1INP_SIGN_OML: - if (isd->trx->bts->type == GSM_BTS_TYPE_HSL_FEMTO) - hslfemto_bootstrap_om(isd->trx->bts); - break; - } - } - - return 0; -} - -static struct gsm_network *hsl_gsmnet; - -static int bts_model_hslfemto_start(struct gsm_network *net) -{ - model_hslfemto.features.data = &model_hslfemto._features_data[0]; - model_hslfemto.features.data_len = sizeof(model_hslfemto._features_data); - - gsm_btsmodel_set_feature(&model_hslfemto, BTS_FEAT_GPRS); - gsm_btsmodel_set_feature(&model_hslfemto, BTS_FEAT_EGPRS); - - osmo_signal_register_handler(SS_L_INPUT, inp_sig_cb, NULL); - - hsl_gsmnet = net; - return 0; -} - -int bts_model_hslfemto_init(void) -{ - return gsm_bts_model_register(&model_hslfemto); -} - -#define OML_UP 0x0001 -#define RSL_UP 0x0002 - -struct gsm_bts *find_bts_by_serno(struct gsm_network *net, uint64_t serno) -{ - struct gsm_bts *bts; - - llist_for_each_entry(bts, &net->bts_list, list) { - if (bts->type != GSM_BTS_TYPE_HSL_FEMTO) - continue; - - if (serno == bts->hsl.serno) - return bts; - } - return NULL; -} - -/* This function is called once the OML/RSL link becomes up. */ -static struct e1inp_sign_link * -hsl_sign_link_up(void *unit_data, struct e1inp_line *line, - enum e1inp_sign_type type) -{ - struct hsl_unit *dev = unit_data; - struct gsm_bts *bts; - - bts = find_bts_by_serno(hsl_gsmnet, dev->serno); - if (!bts) { - LOGP(DLINP, LOGL_ERROR, "Unable to find BTS config for " - "serial number %"PRIx64"\n", dev->serno); - return NULL; - } - DEBUGP(DLINP, "Identified HSL BTS Serial Number %"PRIx64"\n", dev->serno); - - /* we shouldn't hardcode it, but HSL femto also hardcodes it... */ - bts->oml_tei = 255; - bts->c0->rsl_tei = 0; - bts->oml_link = e1inp_sign_link_create(&line->ts[E1INP_SIGN_OML-1], - E1INP_SIGN_OML, bts->c0, - bts->oml_tei, 0); - bts->c0->rsl_link = e1inp_sign_link_create(&line->ts[E1INP_SIGN_OML-1], - E1INP_SIGN_RSL, bts->c0, - bts->c0->rsl_tei, 0); - e1inp_event(&line->ts[E1INP_SIGN_OML-1], S_L_INP_TEI_UP, 255, 0); - e1inp_event(&line->ts[E1INP_SIGN_OML-1], S_L_INP_TEI_UP, 0, 0); - bts->ip_access.flags |= OML_UP; - bts->ip_access.flags |= (RSL_UP << 0); - - return bts->oml_link; -} - -void hsl_drop_oml(struct gsm_bts *bts) -{ - if (!bts->oml_link) - return; - - e1inp_sign_link_destroy(bts->oml_link); - bts->oml_link = NULL; - - e1inp_sign_link_destroy(bts->c0->rsl_link); - bts->c0->rsl_link = NULL; - - bts->ip_access.flags = 0; -} - -static void hsl_sign_link_down(struct e1inp_line *line) -{ - /* No matter what link went down, we close both signal links. */ - struct e1inp_ts *ts = &line->ts[E1INP_SIGN_OML-1]; - struct e1inp_sign_link *link; - - llist_for_each_entry(link, &ts->sign.sign_links, list) { - struct gsm_bts *bts = link->trx->bts; - - hsl_drop_oml(bts); - /* Yes, we only use the first element of the list. */ - break; - } -} - -/* This function is called if we receive one OML/RSL message. */ -static int hsl_sign_link(struct msgb *msg) -{ - int ret = 0; - struct e1inp_sign_link *link = msg->dst; - struct e1inp_ts *e1i_ts = link->ts; - - switch (link->type) { - case E1INP_SIGN_OML: - if (!(link->trx->bts->ip_access.flags & OML_UP)) { - e1inp_event(e1i_ts, S_L_INP_TEI_UP, - link->tei, link->sapi); - link->trx->bts->ip_access.flags |= OML_UP; - } - ret = abis_nm_rcvmsg(msg); - break; - case E1INP_SIGN_RSL: - if (!(link->trx->bts->ip_access.flags & - (RSL_UP << link->trx->nr))) { - e1inp_event(e1i_ts, S_L_INP_TEI_UP, - link->tei, link->sapi); - link->trx->bts->ip_access.flags |= - (RSL_UP << link->trx->nr); - } - ret = abis_rsl_rcvmsg(msg); - break; - default: - LOGP(DLINP, LOGL_ERROR, "Unknown signal link type %d\n", - link->type); - msgb_free(msg); - break; - } - return ret; -} - -static struct e1inp_line_ops hsl_e1inp_line_ops = { - .cfg = { - .ipa = { - .addr = "0.0.0.0", - .role = E1INP_LINE_R_BSC, - }, - }, - .sign_link_up = hsl_sign_link_up, - .sign_link_down = hsl_sign_link_down, - .sign_link = hsl_sign_link, -}; - -static void bts_model_hslfemto_e1line_bind_ops(struct e1inp_line *line) -{ - e1inp_line_bind_ops(line, &hsl_e1inp_line_ops); -} diff --git a/openbsc/src/libbsc/bts_init.c b/openbsc/src/libbsc/bts_init.c index ae41ecc..d6b152a 100644 --- a/openbsc/src/libbsc/bts_init.c +++ b/openbsc/src/libbsc/bts_init.c @@ -23,7 +23,6 @@ int bts_init(void) bts_model_bs11_init(); bts_model_rbs2k_init(); bts_model_nanobts_init(); - bts_model_hslfemto_init(); bts_model_nokia_site_init(); bts_model_sysmobts_init(); /* Your new BTS here. */ diff --git a/openbsc/src/libbsc/e1_config.c b/openbsc/src/libbsc/e1_config.c index d3dff48..d82b009 100644 --- a/openbsc/src/libbsc/e1_config.c +++ b/openbsc/src/libbsc/e1_config.c @@ -185,8 +185,7 @@ int e1_reconfig_bts(struct gsm_bts *bts) /* skip signal link initialization, this is done later for these BTS. */ if (bts->type == GSM_BTS_TYPE_NANOBTS || - bts->type == GSM_BTS_TYPE_OSMO_SYSMO || - bts->type == GSM_BTS_TYPE_HSL_FEMTO) + bts->type == GSM_BTS_TYPE_OSMO_SYSMO) return e1inp_line_update(line); /* OML link */ diff --git a/openbsc/src/libbsc/system_information.c b/openbsc/src/libbsc/system_information.c index 88b81dc..c901a4a 100644 --- a/openbsc/src/libbsc/system_information.c +++ b/openbsc/src/libbsc/system_information.c @@ -596,7 +596,6 @@ static int generate_si5(uint8_t *output, struct gsm_bts *bts) switch (bts->type) { case GSM_BTS_TYPE_NANOBTS: case GSM_BTS_TYPE_OSMO_SYSMO: - case GSM_BTS_TYPE_HSL_FEMTO: *output++ = (l2_plen << 2) | 1; l2_plen++; break; @@ -632,7 +631,6 @@ static int generate_si5bis(uint8_t *output, struct gsm_bts *bts) switch (bts->type) { case GSM_BTS_TYPE_NANOBTS: case GSM_BTS_TYPE_OSMO_SYSMO: - case GSM_BTS_TYPE_HSL_FEMTO: *output++ = (l2_plen << 2) | 1; l2_plen++; break; @@ -677,7 +675,6 @@ static int generate_si5ter(uint8_t *output, struct gsm_bts *bts) switch (bts->type) { case GSM_BTS_TYPE_NANOBTS: case GSM_BTS_TYPE_OSMO_SYSMO: - case GSM_BTS_TYPE_HSL_FEMTO: *output++ = (l2_plen << 2) | 1; l2_plen++; break; @@ -714,7 +711,6 @@ static int generate_si6(uint8_t *output, struct gsm_bts *bts) switch (bts->type) { case GSM_BTS_TYPE_NANOBTS: case GSM_BTS_TYPE_OSMO_SYSMO: - case GSM_BTS_TYPE_HSL_FEMTO: *output++ = (l2_plen << 2) | 1; l2_plen++; break; diff --git a/openbsc/src/libcommon/gsm_data.c b/openbsc/src/libcommon/gsm_data.c index dd1d93b..5f7e32e 100644 --- a/openbsc/src/libcommon/gsm_data.c +++ b/openbsc/src/libcommon/gsm_data.c @@ -189,7 +189,6 @@ const struct value_string bts_type_names[_NUM_GSM_BTS_TYPE+1] = { { GSM_BTS_TYPE_BS11, "bs11" }, { GSM_BTS_TYPE_NANOBTS, "nanobts" }, { GSM_BTS_TYPE_RBS2000, "rbs2000" }, - { GSM_BTS_TYPE_HSL_FEMTO, "hsl_femto" }, { GSM_BTS_TYPE_NOKIA_SITE, "nokia_site" }, { GSM_BTS_TYPE_OSMO_SYSMO, "sysmobts" }, { 0, NULL } @@ -200,7 +199,6 @@ const struct value_string bts_type_descs[_NUM_GSM_BTS_TYPE+1] = { { GSM_BTS_TYPE_BS11, "Siemens BTS (BS-11 or compatible)" }, { GSM_BTS_TYPE_NANOBTS, "ip.access nanoBTS or compatible" }, { GSM_BTS_TYPE_RBS2000, "Ericsson RBS2000 Series" }, - { GSM_BTS_TYPE_HSL_FEMTO, "HSL 2.75G femto" }, { GSM_BTS_TYPE_NOKIA_SITE, "Nokia {Metro,Ultra,In}Site" }, { GSM_BTS_TYPE_OSMO_SYSMO, "sysmocom sysmoBTS" }, { 0, NULL } @@ -349,8 +347,6 @@ int gsm_set_bts_type(struct gsm_bts *bts, enum gsm_bts_type type) } switch (bts->type) { - case GSM_BTS_TYPE_HSL_FEMTO: - bts->c0->rsl_tei = 0; case GSM_BTS_TYPE_NANOBTS: case GSM_BTS_TYPE_OSMO_SYSMO: /* Set the default OML Stream ID to 0xff */ -- 1.7.10.4 From Max.Suraev at fairwaves.ru Wed Jul 3 15:57:00 2013 From: Max.Suraev at fairwaves.ru (=?UTF-8?B?4piO?=) Date: Wed, 03 Jul 2013 17:57:00 +0200 Subject: Dropping support for the HSL bts In-Reply-To: <20130703081605.GC6485@xiaoyu.lan> References: <20130703081605.GC6485@xiaoyu.lan> Message-ID: <51D449CC.1060801@fairwaves.ru> Speaking of which - anyone in Berlin have an HSL 2G femtocell which I can buy/borrow? -- best regards, Max, http://fairwaves.ru From laforge at gnumonks.org Wed Jul 3 20:01:35 2013 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 3 Jul 2013 22:01:35 +0200 Subject: Dropping support for the HSL bts In-Reply-To: <20130703081605.GC6485@xiaoyu.lan> References: <20130703081605.GC6485@xiaoyu.lan> Message-ID: <20130703200135.GI3322@nataraja.gnumonks.org> Hi Holger, On Wed, Jul 03, 2013 at 10:16:05AM +0200, Holger Hans Peter Freyther wrote: > Good Morning Harald, if you explicitly want me to respond, a Cc to my personal e-mail account might be a good idea, I'm not always following all mailing lists... > do you mind if we drop support for the HSL BTS? The support is > spewing out compile warnings, now turns up in coverity reports > as well and we don't even know if it is working with the latest > version of the software running on these BTS. no, please go ahead and remove it. The HSL femto is a discontinued product anyway, and the hostile reaction by the HSL CEO has rendered subsequent HSL femto firmware versions intentionally incompatible with OpenBSC anyway. So let's just remove some dead code... 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 pablo at gnumonks.org Thu Jul 4 22:23:54 2013 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Fri, 5 Jul 2013 00:23:54 +0200 Subject: Dropping support for the HSL bts In-Reply-To: <20130703200135.GI3322@nataraja.gnumonks.org> References: <20130703081605.GC6485@xiaoyu.lan> <20130703200135.GI3322@nataraja.gnumonks.org> Message-ID: <20130704222354.GA4246@localhost> Hi Harald and Holger, On Wed, Jul 03, 2013 at 10:01:35PM +0200, Harald Welte wrote: > Hi Holger, > > On Wed, Jul 03, 2013 at 10:16:05AM +0200, Holger Hans Peter Freyther wrote: > > Good Morning Harald, > > if you explicitly want me to respond, a Cc to my personal e-mail account > might be a good idea, I'm not always following all mailing lists... > > > do you mind if we drop support for the HSL BTS? The support is > > spewing out compile warnings, now turns up in coverity reports > > as well and we don't even know if it is working with the latest > > version of the software running on these BTS. > > no, please go ahead and remove it. The HSL femto is a discontinued > product anyway, and the hostile reaction by the HSL CEO has rendered > subsequent HSL femto firmware versions intentionally incompatible with > OpenBSC anyway. > > So let's just remove some dead code... I'll proceed to remove HSL support from libosmo-abis as well. Regards. From holger at freyther.de Fri Jul 5 05:29:15 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Fri, 5 Jul 2013 07:29:15 +0200 Subject: Dropping support for the HSL bts In-Reply-To: <20130704222354.GA4246@localhost> References: <20130703081605.GC6485@xiaoyu.lan> <20130703200135.GI3322@nataraja.gnumonks.org> <20130704222354.GA4246@localhost> Message-ID: <20130705052915.GC2519@xiaoyu.lan> On Fri, Jul 05, 2013 at 12:23:54AM +0200, Pablo Neira Ayuso wrote: Hi, > I'll proceed to remove HSL support from libosmo-abis as well. thanks, I already removed it (as part of looking through the coverity issues). If there was an issue with my removal please poke me. In coverity we have four more issues, it would be nice if you could have a look at the following: src/input/ipaccess.c: static int ipaccess_bts_cb(struct ipa_client_conn *link, struct msgb *msg) ... 862 } else if (link->port == IPA_TCP_PORT_OML) 863 e1i_ts = &link->line->ts[0]; 4. Condition "link->port == 3003", taking false branch 864 else if (link->port == IPA_TCP_PORT_RSL) 865 e1i_ts = &link->line->ts[1]; 866 867 /* look up for some existing signaling link. */ CID 1042352 (#1 of 1): Explicit null dereferenced (FORWARD_NULL) 5. var_deref_model: Passing null pointer "e1i_ts" to function "e1inp_lookup_sign_link(struct e1inp_ts *, uint8_t, uint8_t)", which dereferences it. [show details] 868 sign_link = e1inp_lookup_sign_link(e1i_ts, hh->proto, 0); port can probably only be IPA_TCP_PORT_OML|IPA_TCP_PORT_RSL. Can you confirm this is a false positive? Shall we add an else branch and add a OSMO_ASSERT(false) there? src/input/ipa.c: static int ipa_server_fd_cb(struct osmo_fd *ofd, unsigned int what) ... 4. Condition "link->accept_cb", taking true branch 324 if (link->accept_cb) 325 link->accept_cb(link, ret); 326 CID 1040692 (#1 of 1): Resource leak (RESOURCE_LEAK) 5. leaked_handle: Handle variable "ret" going out of scope leaks the handle. 327 return 0; Shall we have an else close(ret)? or should we enforce the presence of a accept_cb when the socket is bound? src/input/misdn.c: static int _mi_e1_line_update(struct e1inp_line *line) ... 649 ret = mi_e1_setup(line, 1); 12. Condition "ret", taking false branch 650 if (ret) CID 1040691 (#3 of 4): Resource leak (RESOURCE_LEAK) [select issue] 651 return ret; 652 CID 1040691 (#4 of 4): Resource leak (RESOURCE_LEAK) 13. leaked_handle: Handle variable "sk" going out of scope leaks the handle. 653 return 0; I would add a close(sk); in the code but I was not sure if mISDN requires this code to be open? src/input/ipaccess.c: static struct msgb * 713ipa_bts_id_resp(struct ipaccess_unit *dev, uint8_t *data, int len) 751 case IPAC_IDTAG_SWVERSION: CID 1040690 (#4 of 5): Copy into fixed size buffer (STRING_OVERFLOW) 15. fixed_size_dest: You might overrun the 64 byte fixed-size string "str" by copying "dev->swversion" without checking the length. 16. parameter_as_source: Note: This defect has an elevated risk because the source argument is a parameter of the current function. 752 strcpy(str, dev->swversion); 753 break; this appears to be a genuine issue. cheers holger From pablo at gnumonks.org Fri Jul 5 13:55:22 2013 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Fri, 5 Jul 2013 15:55:22 +0200 Subject: Dropping support for the HSL bts In-Reply-To: <20130705052915.GC2519@xiaoyu.lan> References: <20130703081605.GC6485@xiaoyu.lan> <20130703200135.GI3322@nataraja.gnumonks.org> <20130704222354.GA4246@localhost> <20130705052915.GC2519@xiaoyu.lan> Message-ID: <20130705135522.GB3468@localhost> Hi Holger, On Fri, Jul 05, 2013 at 07:29:15AM +0200, Holger Hans Peter Freyther wrote: > On Fri, Jul 05, 2013 at 12:23:54AM +0200, Pablo Neira Ayuso wrote: > > I'll proceed to remove HSL support from libosmo-abis as well. > > thanks, I already removed it (as part of looking through the > coverity issues). If there was an issue with my removal please > poke me. Looks good, thanks. > In coverity we have four more issues, it would be nice if you > could have a look at the following: > > > src/input/ipaccess.c: > static int ipaccess_bts_cb(struct ipa_client_conn *link, struct msgb *msg) > ... > 862 } else if (link->port == IPA_TCP_PORT_OML) > 863 e1i_ts = &link->line->ts[0]; > 4. Condition "link->port == 3003", taking false branch > 864 else if (link->port == IPA_TCP_PORT_RSL) > 865 e1i_ts = &link->line->ts[1]; > 866 > 867 /* look up for some existing signaling link. */ > > CID 1042352 (#1 of 1): Explicit null dereferenced (FORWARD_NULL) > 5. var_deref_model: Passing null pointer "e1i_ts" to function "e1inp_lookup_sign_link(struct e1inp_ts *, uint8_t, uint8_t)", which dereferences it. [show details] > 868 sign_link = e1inp_lookup_sign_link(e1i_ts, hh->proto, 0); > > port can probably only be IPA_TCP_PORT_OML|IPA_TCP_PORT_RSL. Can > you confirm this is a false positive? Shall we add an else branch > and add a OSMO_ASSERT(false) there? This should not ever happen. Added an assertion as you suggested and pushed the patch. > src/input/ipa.c: > > static int ipa_server_fd_cb(struct osmo_fd *ofd, unsigned int what) > ... > 4. Condition "link->accept_cb", taking true branch > 324 if (link->accept_cb) > 325 link->accept_cb(link, ret); > 326 > > CID 1040692 (#1 of 1): Resource leak (RESOURCE_LEAK) > 5. leaked_handle: Handle variable "ret" going out of scope leaks the handle. > 327 return 0; > > Shall we have an else close(ret)? or should we enforce the presence > of a accept_cb when the socket is bound? Should not happen either, but added the close as you suggested. > src/input/misdn.c: > static int _mi_e1_line_update(struct e1inp_line *line) > ... > 649 ret = mi_e1_setup(line, 1); > 12. Condition "ret", taking false branch > 650 if (ret) > CID 1040691 (#3 of 4): Resource leak (RESOURCE_LEAK) [select issue] > 651 return ret; > 652 > > CID 1040691 (#4 of 4): Resource leak (RESOURCE_LEAK) > 13. leaked_handle: Handle variable "sk" going out of scope leaks the handle. > 653 return 0; > > > I would add a close(sk); in the code but I was not sure if mISDN requires > this code to be open? I don't have any msidn card. It seems we don't have any ->close callback in the line set to close that socket, but I prefer to leave as is by now until I/someone else can confirm this. > src/input/ipaccess.c: > static struct msgb * > 713ipa_bts_id_resp(struct ipaccess_unit *dev, uint8_t *data, int len) > > 751 case IPAC_IDTAG_SWVERSION: > > CID 1040690 (#4 of 5): Copy into fixed size buffer (STRING_OVERFLOW) > 15. fixed_size_dest: You might overrun the 64 byte fixed-size string "str" by copying "dev->swversion" without checking the length. > 16. parameter_as_source: Note: This defect has an elevated risk because the source argument is a parameter of the current function. > 752 strcpy(str, dev->swversion); > 753 break; > > this appears to be a genuine issue. Those strings are set in the configuration path, I have fix it, no such an "elevated risk" as coverity spotted. Also pushed a couple of patches to fix compilation warnings. I have this warning as well: e1_input.c: In function 'write_pcap_packet': e1_input.c:163:6: warning: variable 'ret' set but not used [-Wunused-but-set-variable] I can fix it by returning error in abis_sendmsg and e1inp_rx_ts if it cannot write the traces to the pcap file (should only affect isdn-based BTSes) including some log message. Let me know if you have any issue with those. Thanks! From holger at freyther.de Fri Jul 5 17:24:49 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Fri, 5 Jul 2013 19:24:49 +0200 Subject: Dropping support for the HSL bts In-Reply-To: <20130705135522.GB3468@localhost> References: <20130703081605.GC6485@xiaoyu.lan> <20130703200135.GI3322@nataraja.gnumonks.org> <20130704222354.GA4246@localhost> <20130705052915.GC2519@xiaoyu.lan> <20130705135522.GB3468@localhost> Message-ID: <20130705172448.GA26428@xiaoyu.lan> On Fri, Jul 05, 2013 at 03:55:22PM +0200, Pablo Neira Ayuso wrote: > > Looks good, thanks. Thanks, thanks a lot for the speedy fix-up of things. Do you follow coverity reports for netfilter too? > > Should not happen either, but added the close as you suggested. OSMO_ASSERT(link->accept_cb) maybe? Coverity is still not happy about the ret (mostly because it doesn't find an assignment but then I would probably need to build every project as one thing). E.g. we don't check the return value of accept_cb, but if you want to, I can close this as a false positive now. > I don't have any msidn card. It seems we don't have any ->close > callback in the line set to close that socket, but I prefer to leave > as is by now until I/someone else can confirm this. I think 'sk' is only used to gain information about the mISDN device (it is a bit racy, as at the time we use it the card might be gone, I assume we can just close the sk after the last ioctl). > Those strings are set in the configuration path, I have fix it, no > such an "elevated risk" as coverity spotted. thanks. > Let me know if you have any issue with those. Coverity found another thing (so apparently it 'learns') src/input/dahdi.c 404 if (line->port_nr > ARRAY_SIZE(span_cfgs)) 405 return; 406 CID 1042368 (#1 of 1): Out-of-bounds read (OVERRUN) 3. overrun-local: Overrunning array "span_cfgs" of 128 4-byte elements at element index 128 (byte offset 512) using index "line->port_nr" (which evaluates to 128). 407 scfg = span_cfgs[line->port_nr]; So I think this needs to be a >=. Please use CID in the commit message when fixing it (or in case you are busy and ack that >= is the right fix I will make the commit). holger From pablo at gnumonks.org Sun Jul 7 23:28:44 2013 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Mon, 8 Jul 2013 01:28:44 +0200 Subject: Dropping support for the HSL bts In-Reply-To: <20130705172448.GA26428@xiaoyu.lan> References: <20130703081605.GC6485@xiaoyu.lan> <20130703200135.GI3322@nataraja.gnumonks.org> <20130704222354.GA4246@localhost> <20130705052915.GC2519@xiaoyu.lan> <20130705135522.GB3468@localhost> <20130705172448.GA26428@xiaoyu.lan> Message-ID: <20130707232844.GA10752@localhost> Hi Holger, On Fri, Jul 05, 2013 at 07:24:49PM +0200, Holger Hans Peter Freyther wrote: [...] > > Should not happen either, but added the close as you suggested. > > OSMO_ASSERT(link->accept_cb) maybe? Coverity is still not happy > about the ret (mostly because it doesn't find an assignment but > then I would probably need to build every project as one thing). > > E.g. we don't check the return value of accept_cb, but if you > want to, I can close this as a false positive now. Just pushed a patch for this, let's see if it calms down coverity. > > I don't have any msidn card. It seems we don't have any ->close > > callback in the line set to close that socket, but I prefer to leave > > as is by now until I/someone else can confirm this. > > I think 'sk' is only used to gain information about the mISDN device > (it is a bit racy, as at the time we use it the card might be gone, > I assume we can just close the sk after the last ioctl). > [...] > > CID 1042368 (#1 of 1): Out-of-bounds read (OVERRUN) > 3. overrun-local: Overrunning array "span_cfgs" of 128 4-byte elements at element index 128 (byte offset 512) using index "line->port_nr" (which evaluates to 128). > 407 scfg = span_cfgs[line->port_nr]; > > So I think this needs to be a >=. Please use CID in the commit message > when fixing it (or in case you are busy and ack that >= is the right > fix I will make the commit). I just noticed that you pushed two patches for this. Thanks. BTW, I'm hitting this compilation warning here: trau/osmo_ortp.c: In function 'osmo_rtcp_fd_cb': trau/osmo_ortp.c:207:2: warning: implicit declaration of function 'rtp_session_rtcp_recv' [-Wimplicit-function-declaration] I can find that function defined in a private header of ortp, any clue on why we need it there? From holger at freyther.de Wed Jul 10 17:23:38 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Wed, 10 Jul 2013 19:23:38 +0200 Subject: Dropping support for the HSL bts In-Reply-To: <20130707232844.GA10752@localhost> References: <20130703081605.GC6485@xiaoyu.lan> <20130703200135.GI3322@nataraja.gnumonks.org> <20130704222354.GA4246@localhost> <20130705052915.GC2519@xiaoyu.lan> <20130705135522.GB3468@localhost> <20130705172448.GA26428@xiaoyu.lan> <20130707232844.GA10752@localhost> Message-ID: <20130710172338.GK7719@xiaoyu.lan> On Mon, Jul 08, 2013 at 01:28:44AM +0200, Pablo Neira Ayuso wrote: > > Just pushed a patch for this, let's see if it calms down coverity. it is still confused as it is not capable of seeing who sets the accept_cb (i would need to build everything at once and it might be different). I have marked this as either false positive or intentional. libosmo-abis is the first repository with zero coverity issues. Well maybe tnt bet me and libosmo-dsp/osmo-gmr got there first. thank you very much for having a look and quick responses! holger From laforge at gnumonks.org Sun Jul 21 08:48:01 2013 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 21 Jul 2013 16:48:01 +0800 Subject: RTCP handling in libosmotrau In-Reply-To: <20130707232844.GA10752@localhost> References: <20130703081605.GC6485@xiaoyu.lan> <20130703200135.GI3322@nataraja.gnumonks.org> <20130704222354.GA4246@localhost> <20130705052915.GC2519@xiaoyu.lan> <20130705135522.GB3468@localhost> <20130705172448.GA26428@xiaoyu.lan> <20130707232844.GA10752@localhost> Message-ID: <20130721084801.GH5573@nataraja.gnumonks.org> Hi Pablo, On Mon, Jul 08, 2013 at 01:28:44AM +0200, Pablo Neira Ayuso wrote: > BTW, I'm hitting this compilation warning here: > > trau/osmo_ortp.c: In function 'osmo_rtcp_fd_cb': > trau/osmo_ortp.c:207:2: warning: implicit declaration of function > 'rtp_session_rtcp_recv' [-Wimplicit-function-declaration] > > I can find that function defined in a private header of ortp, any clue > on why we need it there? Please read the comment in the source above it: /* We probably don't need this at all, as * rtp_session_recvm_with_ts() will alway also poll the RTCP * file descriptor for new data */ Theoretically it is the right thing for the application/osmocore select loop handling to detect the arrival of a RTCP message on the socket and let the ortp library know. However, ortp seems to prefer to simply poll that file descriptor every time a RTP data frame arrives. So if you receive an RTCP message but not an RTP frame in a long time, that RTCP will get delayed witnhout any good reason. So I thought it might be a good idea to simply pass this information into the library. RTCP handling of libosmo-trau was never tested so far, AFAIK. 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 dchardware at gmail.com Thu Jul 4 22:11:13 2013 From: dchardware at gmail.com (Sipos Csaba) Date: Fri, 5 Jul 2013 00:11:13 +0200 Subject: Nokia InSite multiple BTSs with OpenBSC In-Reply-To: References: Message-ID: <481694510.20130705001113@freemail.hu> Dear Members, As I previously mentioned, I have two Nokia InSite BTS units that I want to set up for my university. One GSM900 and one GSM1800 unit, and I want to share some findings that can be useful for other users too. First, the informations about the DAHDI configuration at the end of the building page: http://openbsc.osmocom.org/trac/wiki/Building_OpenBSC It sais the following for system.conf: dchan=1 bchan=2-30 I wanted to point out that it is not necessary to define a dchan, because with BTSes this is not a traditional E1 line configuration where you share timeslots and you have to signal it via the traditional E1 signaling channel (dchan), because for every BTS there are dedicated timeslots for OMUSIG, TRXSIG and TCHs etc, that cannot be used by anybody else. And because we are not using that dchan, it is a waste of capacity to allocate it. My DAHDI system.conf looks like this: span=1,0,0,ccs,hdb3,crc4 bchan=1-31 and it works perfectly without a configured dchan (well its far from perfect but at least the problem is not with the E1 configuration). Because every BTS works like this, it would be wise the update that information. For T1 lines and other framing configurations (cas, ami etc.) it is the same. The second thing is that Nokia InSite units (probably others too) can be daisy chained. It is possible to share the first BTS units E1 connection for the daisy chained units with the integrated HDSL cross-connection interface. With this technique it is possible to share one E1 connection between 5 BTSes. But there is a slight problem. I figured out if the BTS is not connecting to the E1 directly, but via this HDSL interface, it needs more time before it can be configured via OML,RSL. So in bts_nokia_site.c the #DEFINE RESET_INTERVAL have to be raise from the current 15 seconds to at least 25 seconds, otherwise the unit is not going to came up. With this modification I was able to use the unity via this HDSL cross-connection interface. The third thing is multiple BTS operation. As I mentioned I want to use two InSite units with OpenBSC. But at the beginning of bts_nokie_site.c there is a big warning: I most certainly going to have problems with multi BTS operation. Despite the warning I tried with two units, and found an interesting thing: if I try to start the two units, only one of the two units are going to came up. But if I start the daisy chained unit first, then stop openbsc and immediately start openbsc again but now with the two unit config file, both BTSes are came up just fine, the phones can camp on both units. I don't know the real reason behind this behavior, but I have log and PCAP traces about the working and non-working scenarios. If someone interested in it I can share the results. Although a possible reason is that in bts_nokia_insite.c the shutdown routine is completely missing. It is not a good solution, but at least we should reset the BTS(es) and all the signalling channels in the shutdown state (like with BS11), until we figure out some proper way of shutting Nokia BTSes down. BR, Csaba From holger at freyther.de Fri Jul 5 07:04:20 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Fri, 5 Jul 2013 09:04:20 +0200 Subject: Nokia InSite multiple BTSs with OpenBSC In-Reply-To: <481694510.20130705001113@freemail.hu> References: <481694510.20130705001113@freemail.hu> Message-ID: <20130705070420.GE2519@xiaoyu.lan> On Fri, Jul 05, 2013 at 12:11:13AM +0200, Sipos Csaba wrote: > Dear Members, Good Morning, > First, the informations about the DAHDI configuration at the end of > the building page: > > http://openbsc.osmocom.org/trac/wiki/Building_OpenBSC > > It sais the following for system.conf: > > span=1,0,0,ccs,hdb3,crc4 > bchan=1-31 please create a wiki account (by mailing laforge) and add your additional information there. > But there is a slight problem. I figured out if the BTS is not > connecting to the E1 directly, but via this HDSL interface, it needs > more time before it can be configured via OML,RSL. So in > bts_nokia_site.c the #DEFINE RESET_INTERVAL have to be raise from the > current 15 seconds to at least 25 seconds, otherwise the unit is not > going to came up. With this modification I was able to use the unity > via this HDSL cross-connection interface. Can you try to come up with a patch to make this VTY configurable for the BTS type? In gsm_data.h we already have vendor specific fields and you could add one to the nokia section and add reset interval field. > The third thing is multiple BTS operation. As I mentioned I want to > use two InSite units with OpenBSC. But at the beginning of > bts_nokie_site.c there is a big warning: I most certainly going to I can't help on this part From dchardware at gmail.com Fri Jul 5 08:56:58 2013 From: dchardware at gmail.com (Sipos Csaba) Date: Fri, 5 Jul 2013 10:56:58 +0200 Subject: Nokia InSite multiple BTSs with OpenBSC In-Reply-To: <20130705070420.GE2519@xiaoyu.lan> References: <481694510.20130705001113@freemail.hu> <20130705070420.GE2519@xiaoyu.lan> Message-ID: <482078707.20130705105658@freemail.hu> Hi Holger, > please create a wiki account (by mailing laforge) and add your additional > information there. Will do. I am going to write a complete guide for InSite, how to setup the BTS, DAHDI, OpenBSC and the cross connections, and will share this with the community. MOst Nokia units uses the very same interfaces so it could be a help to others too, not to mention these indoor picocells are much easier to access, than talk, metro, felxi and other Nokia units. > Can you try to come up with a patch to make this VTY configurable > for the BTS type? In gsm_data.h we already have vendor specific fields > and you could add one to the nokia section and add reset interval field. I think it is not a problem to simply raise the already existing RESET_TIMER from 15 to 25 seconds, because it is not a problem if the code waits for all the BTSes 25 seconds. THe init will take a little longer, but with the longer RESET_TIMER every BTS will have the time to perform the initial reset and wait for the LAPD connection (OMUSIG and TRXSIG) to be started. Will read that part of the code you mentioned. >> The third thing is multiple BTS operation. As I mentioned I want to >> use two InSite units with OpenBSC. But at the beginning of >> bts_nokie_site.c there is a big warning: I most certainly going to > I can't help on this part I am reading the relevant code parts for a while but I am not a professional programmer. This is what the warning message sais: > TODO: Attention: There are some static variables used for states during > configuration. Those variables have to be moved to a BTS specific context, > otherwise there will most certainly be problems if more than one Nokia BTS > is used. I don't know what it means "move to a BTS specific context", but based on the fact I was able to set up two units with only the modification of the RESET_INTERVAL, it does not seems that much of a work, because it almost works well as it is. Because BS11 unit uses E1 and there is multi-unit support for that, I started to read the code for that type of BTS, but I don't see the difference between the insite and at BS11 code, where this "BTS specific context" lies. If you could just browse through the bts_nokia_insite.c code at least you could evaluate how big this work is, or how hard to do this task, because I can't determine that. I am happy to contribute with testing or remote access to the equipment. In a different post I will try to evaluate the difference between the successful and unsuccessful multi-unit startup, and provide the traces for these attempts, gather all the infos available to one place. BR, Csaba From peter at stuge.se Mon Jul 8 19:15:13 2013 From: peter at stuge.se (Peter Stuge) Date: Mon, 8 Jul 2013 21:15:13 +0200 Subject: Nokia InSite multiple BTSs with OpenBSC In-Reply-To: <482078707.20130705105658@freemail.hu> References: <481694510.20130705001113@freemail.hu> <20130705070420.GE2519@xiaoyu.lan> <482078707.20130705105658@freemail.hu> Message-ID: <20130708191513.12451.qmail@stuge.se> Sipos Csaba wrote: > > TODO: Attention: There are some static variables used for states during > > configuration. Those variables have to be moved to a BTS specific context, > > otherwise there will most certainly be problems if more than one Nokia BTS > > is used. > > I don't know what it means "move to a BTS specific context", but based > on the fact I was able to set up two units with only the modification > of the RESET_INTERVAL, it does not seems that much of a work, because > it almost works well as it is. It means that some real programming is needed. It's not a small change. It might work as-is with one phone camping to only one of the two BTSes at a time, but you will likely have corruptions if you have a bunch of phones on both BTSes at once. When using nitb with a multi-TRX MetroSite there is a similar pattern to what you describe - after the BTS is reset using the Nokia BTS Manager, nitb only ever manages to correctly initialize the first TRX. An error occurs and nitb exits. Restarting nitb sometimes allows it to initialize the second TRX, sometimes no. My guess is that failure or success depends on what phones are sending to the BTS meanwhile, but it could also be only a matter of timing. The nokia_site code can definitily be improved when it comes to startup/shutdown, but I don't know how well known the Nokia OML is. It would also be nice to listen to the BTS Manager serial port communication. If I understand correctly, many (all?) things that BTS Manager can do over serial are also possible over E1. //Peter From holger at freyther.de Fri Jul 5 05:43:15 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Fri, 5 Jul 2013 07:43:15 +0200 Subject: Coverity issues in lapd_core/gsm mncc Message-ID: <20130705054315.GD2519@xiaoyu.lan> Dear Andreas, the coverity prevent utility has found three inconsistencies in the lapd_core.c and the gsm_04_08.c and I think you are suited the best to comment on how to resolve them. src/gsm/lapd_core.c static int lapd_res_req(struct osmo_dlsap_prim *dp, struct lapd_msg_ctx *lctx) ... 1943 LOGP(DLLAPD, LOGL_INFO, "perform re-establishment (SABM) length=%d\n", 1944 msg->len); ... CID 1040665 (#1 of 1): Dereference before null check (REVERSE_INULL) check_after_deref: Null-checking "msg" suggests that it may be null, but it has already been dereferenced on all paths leading to the check. 1956 if (msg && msg->len) so we already dereferenced msg to print the length. So at this point, is it legetimate to a have NULL msgb or shall the null check be removed? src/libmsc/gsm_04_08.c static int gsm48_cc_rx_connect(struct gsm_trans *trans, struct msgb *msg) ... 2090 if (trans->subscr) { 2091 connect.fields |= MNCC_F_CONNECTED; 2092 strncpy(connect.connected.number, trans->subscr->extension, 2093 sizeof(connect.connected.number)-1); 2094 strncpy(connect.imsi, trans->subscr->imsi, 2095 sizeof(connect.imsi)-1); 2096 } ... CID 1040740 (#1 of 1): Dereference after null check (FORWARD_NULL) 6. var_deref_op: Dereferencing null pointer "trans->subscr". 2117 osmo_counter_inc(trans->subscr->net->stats.call.mt_connect); 2118 2119 return mncc_recvmsg(trans->subscr->net, trans, MNCC_SETUP_CNF, &connect); trans->subscr is conditionally dereferenced and then unconditionally, what is correct? static int gsm48_cc_rx_setup(struct gsm_trans *trans, struct msgb *msg) ... 1761 if (trans->subscr) { 1762 setup.fields |= MNCC_F_CALLING; 1763 strncpy(setup.calling.number, trans->subscr->extension, 1764 sizeof(setup.calling.number)-1); 1765 strncpy(setup.imsi, trans->subscr->imsi, 1766 sizeof(setup.imsi)-1); 1767 } ... CID 1040739 (#1 of 1): Dereference after null check (FORWARD_NULL) 14. var_deref_model: Passing null pointer "trans->subscr" to function "subscr_name(struct gsm_subscriber *)", which dereferences it. [show details] 1813 LOGP(DCC, LOGL_INFO, "Subscriber %s (%s) sends SETUP to %s\n", 1814 subscr_name(trans->subscr), trans->subscr->extension, 1815 setup.called.number); 1816 1817 osmo_counter_inc(trans->subscr->net->stats.call.mo_setup); Same thing as above. Can the null check be removed? Would you have the time to do that? From holger at freyther.de Fri Jul 5 17:34:58 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Fri, 5 Jul 2013 19:34:58 +0200 Subject: Coverity issues in lapd_core/gsm mncc In-Reply-To: <20130705054315.GD2519@xiaoyu.lan> References: <20130705054315.GD2519@xiaoyu.lan> Message-ID: <20130705173458.GB26428@xiaoyu.lan> On Fri, Jul 05, 2013 at 07:43:15AM +0200, Holger Hans Peter Freyther wrote: > Dear Andreas, Dear Andreas, we would also like to have your input on a mISDN file descriptor leak in the libosmo-abis code: src/input/misdn.c static int _mi_e1_line_update(struct e1inp_line *line) this function is not closing the 'sk' filedescriptor which is of type sk = socket(PF_ISDN, SOCK_RAW, ISDN_P_BASE); do we need to keep this one open or is this is a bug? Pablo and me currently do not have a mISDN setup, so we can not easily answer this question right now. Do you see anything wrong with this patch: diff --git a/src/input/misdn.c b/src/input/misdn.c index a72a21e..5966817 100644 --- a/src/input/misdn.c +++ b/src/input/misdn.c @@ -640,6 +640,7 @@ static int _mi_e1_line_update(struct e1inp_line *line) fprintf(stdout, " nrbchan: %d\n", devinfo.nrbchan); fprintf(stdout, " name: %s\n", devinfo.name); #endif + close(sk); if (!(devinfo.Dprotocols & (1 << ISDN_P_NT_E1))) { fprintf(stderr, "error: card is not of type E1 (NT-mode)\n"); thanks holger From andreas at eversberg.eu Sat Jul 6 08:19:52 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Sat, 06 Jul 2013 10:19:52 +0200 Subject: Coverity issues in lapd_core/gsm mncc In-Reply-To: <20130705173458.GB26428@xiaoyu.lan> References: <20130705054315.GD2519@xiaoyu.lan> <20130705173458.GB26428@xiaoyu.lan> Message-ID: <51D7D328.3040400@eversberg.eu> Holger Hans Peter Freyther wrote: > src/input/misdn.c > static int _mi_e1_line_update(struct e1inp_line *line) > > this function is not closing the 'sk' filedescriptor which is of type > sk = socket(PF_ISDN, SOCK_RAW, ISDN_P_BASE); > > do we need to keep this one open or is this is a bug? Pablo and me > currently do not have a mISDN setup, so we can not easily answer this > question right now. > hi holger, the socket is only used to get information about isdn interfaces, so it shall be closed, if not used anymore. your patch looks good to me. best regards, andreas From andreas at eversberg.eu Sat Jul 6 08:05:00 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Sat, 06 Jul 2013 10:05:00 +0200 Subject: Coverity issues in lapd_core/gsm mncc In-Reply-To: <20130705054315.GD2519@xiaoyu.lan> References: <20130705054315.GD2519@xiaoyu.lan> Message-ID: <51D7CFAC.9040105@eversberg.eu> Holger Hans Peter Freyther wrote: > Dear Andreas, > > the coverity prevent utility has found three inconsistencies in the > lapd_core.c and the gsm_04_08.c and I think you are suited the best > to comment on how to resolve them. > > > src/gsm/lapd_core.c > static int lapd_res_req(struct osmo_dlsap_prim *dp, struct lapd_msg_ctx *lctx) > ... > 1943 LOGP(DLLAPD, LOGL_INFO, "perform re-establishment (SABM) length=%d\n", > 1944 msg->len); > ... > this is really wrong. msg may be null. at least it depends on the upper layer how to provide msg (NULL or 0-length), see patch. > > CID 1040665 (#1 of 1): Dereference before null check (REVERSE_INULL) > check_after_deref: Null-checking "msg" suggests that it may be null, but it has already been dereferenced on all paths leading to the check. > 1956 if (msg && msg->len) > > so we already dereferenced msg to print the length. So at this point, > is it legetimate to a have NULL msgb or shall the null check be removed? > > also if msg exists with 0 lenght, it will not be used, so it must be freed, see patch. > src/libmsc/gsm_04_08.c > static int gsm48_cc_rx_connect(struct gsm_trans *trans, struct msgb *msg) > ... > 2090 if (trans->subscr) { > 2091 connect.fields |= MNCC_F_CONNECTED; > 2092 strncpy(connect.connected.number, trans->subscr->extension, > 2093 sizeof(connect.connected.number)-1); > 2094 strncpy(connect.imsi, trans->subscr->imsi, > 2095 sizeof(connect.imsi)-1); > 2096 } > ... > > CID 1040740 (#1 of 1): Dereference after null check (FORWARD_NULL) > 6. var_deref_op: Dereferencing null pointer "trans->subscr". > 2117 osmo_counter_inc(trans->subscr->net->stats.call.mt_connect); > 2118 > 2119 return mncc_recvmsg(trans->subscr->net, trans, MNCC_SETUP_CNF, &connect); > > trans->subscr is conditionally dereferenced and then unconditionally, > what is correct? > i think we can remove the check for trans->subscr, since all rx functions assume that it is set. instead it makes sense to add a sanity check (trans->subscr must be set) to gsm0408_rcv_cc before calling the rx function. > > static int gsm48_cc_rx_setup(struct gsm_trans *trans, struct msgb *msg) > ... > 1761 if (trans->subscr) { > 1762 setup.fields |= MNCC_F_CALLING; > 1763 strncpy(setup.calling.number, trans->subscr->extension, > 1764 sizeof(setup.calling.number)-1); > 1765 strncpy(setup.imsi, trans->subscr->imsi, > 1766 sizeof(setup.imsi)-1); > 1767 } > ... > CID 1040739 (#1 of 1): Dereference after null check (FORWARD_NULL) > 14. var_deref_model: Passing null pointer "trans->subscr" to function "subscr_name(struct gsm_subscriber *)", which dereferences it. [show details] > 1813 LOGP(DCC, LOGL_INFO, "Subscriber %s (%s) sends SETUP to %s\n", > 1814 subscr_name(trans->subscr), trans->subscr->extension, > 1815 setup.called.number); > 1816 > 1817 osmo_counter_inc(trans->subscr->net->stats.call.mo_setup); > > Same thing as above. Can the null check be removed? Would you have the > time to do that? > same as a bove. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: lapd.patch URL: From holger at freyther.de Sat Jul 6 09:42:17 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sat, 6 Jul 2013 11:42:17 +0200 Subject: Coverity issues in lapd_core/gsm mncc In-Reply-To: <51D7CFAC.9040105@eversberg.eu> References: <20130705054315.GD2519@xiaoyu.lan> <51D7CFAC.9040105@eversberg.eu> Message-ID: <20130706094217.GB10036@xiaoyu.lan> On Sat, Jul 06, 2013 at 10:05:00AM +0200, Andreas Eversberg wrote: > this is really wrong. msg may be null. at least it depends on the upper > layer how to provide msg (NULL or 0-length), see patch. but we have not hit this case yet (e.g. no re-establishment occured right now). Do you have an idea of why this doesn't crash right now? > i think we can remove the check for trans->subscr, since all rx > functions assume that it is set. instead it makes sense to add a sanity > check (trans->subscr must be set) to gsm0408_rcv_cc before calling the > rx function. okay. I will take care of that. > also if msg exists with 0 lenght, it will not be used, so it must be > freed, see patch. do you think you could extend the LAPD testcase for the case that would have crashed/leaked right now? msgb_free(NULL) is well defined, this means you do not need to have a NULL check there. > LOGP(DLLAPD, LOGL_INFO, "perform re-establishment (SABM) length=%d\n", > - msg->len); > + (msg) ? msg->len : 0); why the '(' and ')'? > + } else { > + if (msg) > + msgb_free(msg); msgb_free(msg) > dl->send_buffer = NULL; > + } From andreas at eversberg.eu Sat Jul 6 18:43:52 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Sat, 06 Jul 2013 20:43:52 +0200 Subject: Coverity issues in lapd_core/gsm mncc In-Reply-To: <20130706094217.GB10036@xiaoyu.lan> References: <20130705054315.GD2519@xiaoyu.lan> <51D7CFAC.9040105@eversberg.eu> <20130706094217.GB10036@xiaoyu.lan> Message-ID: <51D86568.4060508@eversberg.eu> Holger Hans Peter Freyther wrote: > but we have not hit this case yet (e.g. no re-establishment occured > right now). Do you have an idea of why this doesn't crash right now? this is because openbsc does not do re-establishment in case of a data link failure. osmocombb uses resume for assignment (which causes the same function as re-establishment), but for this case, lapdm.c will provide a zero-length msg. From holger at freyther.de Sun Jul 7 17:44:32 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sun, 7 Jul 2013 19:44:32 +0200 Subject: Coverity issues in lapd_core/gsm mncc In-Reply-To: <51D86568.4060508@eversberg.eu> References: <20130705054315.GD2519@xiaoyu.lan> <51D7CFAC.9040105@eversberg.eu> <20130706094217.GB10036@xiaoyu.lan> <51D86568.4060508@eversberg.eu> Message-ID: <20130707174432.GJ17761@xiaoyu.lan> On Sat, Jul 06, 2013 at 08:43:52PM +0200, Andreas Eversberg wrote: > this is because openbsc does not do re-establishment in case of a > data link failure. osmocombb uses resume for assignment (which > causes the same function as re-establishment), but for this case, > lapdm.c will provide a zero-length msg. Hi, so maybe it simplifies the code just to assume/assert that the msgb is present in the primitive? As you freed the msgb, this means that OsmocomBB currently leaks this msgb during the handling of assignment? thanks holger From andreas at eversberg.eu Sun Jul 7 19:07:32 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Sun, 07 Jul 2013 21:07:32 +0200 Subject: Coverity issues in lapd_core/gsm mncc In-Reply-To: <20130707174432.GJ17761@xiaoyu.lan> References: <20130705054315.GD2519@xiaoyu.lan> <51D7CFAC.9040105@eversberg.eu> <20130706094217.GB10036@xiaoyu.lan> <51D86568.4060508@eversberg.eu> <20130707174432.GJ17761@xiaoyu.lan> Message-ID: <51D9BC74.4070701@eversberg.eu> Holger Hans Peter Freyther wrote: > so maybe it simplifies the code just to assume/assert that the msgb > is present in the primitive? As you freed the msgb, this means that > OsmocomBB currently leaks this msgb during the handling of assignment? hi holger, lapdm.c takes the re-establishment message and forwards it to lapd_core.c, so we can assume that msg is set. i case there is data in the re-establishment msg, it is moved into send_buffer. in case of no data it must be freed. (currently i don't know why resume/re-establishment requires content in SABM message.) regards, andreas From holger at freyther.de Tue Jul 9 16:53:32 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Tue, 9 Jul 2013 18:53:32 +0200 Subject: Coverity issues in lapd_core/gsm mncc In-Reply-To: <51D9BC74.4070701@eversberg.eu> References: <20130705054315.GD2519@xiaoyu.lan> <51D7CFAC.9040105@eversberg.eu> <20130706094217.GB10036@xiaoyu.lan> <51D86568.4060508@eversberg.eu> <20130707174432.GJ17761@xiaoyu.lan> <51D9BC74.4070701@eversberg.eu> Message-ID: <20130709165332.GF3910@xiaoyu.lan> On Sun, Jul 07, 2013 at 09:07:32PM +0200, Andreas Eversberg wrote: > lapdm.c takes the re-establishment message and forwards it to > lapd_core.c, so we can assume that msg is set. i case there is data > in the re-establishment msg, it is moved into send_buffer. in case > of no data it must be freed. (currently i don't know why > resume/re-establishment requires content in SABM message.) okay, please send your final patch for this issue to the mailinglist for review. thanks holger From andreas at eversberg.eu Tue Jul 9 19:32:03 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Tue, 09 Jul 2013 21:32:03 +0200 Subject: Coverity issues in lapd_core/gsm mncc In-Reply-To: <20130709165332.GF3910@xiaoyu.lan> References: <20130705054315.GD2519@xiaoyu.lan> <51D7CFAC.9040105@eversberg.eu> <20130706094217.GB10036@xiaoyu.lan> <51D86568.4060508@eversberg.eu> <20130707174432.GJ17761@xiaoyu.lan> <51D9BC74.4070701@eversberg.eu> <20130709165332.GF3910@xiaoyu.lan> Message-ID: <51DC6533.1000702@eversberg.eu> Holger Hans Peter Freyther wrote: > On Sun, Jul 07, 2013 at 09:07:32PM +0200, Andreas Eversberg wrote: >> lapdm.c takes the re-establishment message and forwards it to >> lapd_core.c, so we can assume that msg is set. i case there is data >> in the re-establishment msg, it is moved into send_buffer. in case >> of no data it must be freed. (currently i don't know why >> resume/re-establishment requires content in SABM message.) > okay, please send your final patch for this issue to the mailinglist > for review. here it is. thanx for reviewing it. From jolly at eversberg.eu Tue Jul 9 18:25:24 2013 From: jolly at eversberg.eu (Andreas Eversberg) Date: Tue, 9 Jul 2013 20:25:24 +0200 Subject: [PATCH] LAPD: Free resume/re-establishment msgb if it carries no content Message-ID: lapdm.c takes the re-establishment message and forwards it to lapd_core.c, so we can assume that msgb is set at primitive. In case there is data in the re-establishment msg, it is moved into send_buffer. In case of no data (0 length), it must be freed. --- src/gsm/lapd_core.c | 6 ++++-- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/src/gsm/lapd_core.c b/src/gsm/lapd_core.c index 68b5e78..08143ed 100644 --- a/src/gsm/lapd_core.c +++ b/src/gsm/lapd_core.c @@ -1962,11 +1962,13 @@ static int lapd_res_req(struct osmo_dlsap_prim *dp, struct lapd_msg_ctx *lctx) if (dl->send_buffer) msgb_free(dl->send_buffer); dl->send_out = 0; - if (msg && msg->len) + if (msg->len) { /* Write data into the send buffer, to be sent first */ dl->send_buffer = msg; - else + } else { + msgb_free(msg); dl->send_buffer = NULL; + } /* Discard partly received L3 message */ if (dl->rcv_buffer) { -- 1.7.3.4 --------------030109030604040502010001-- From holger at freyther.de Wed Jul 10 18:29:33 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Wed, 10 Jul 2013 20:29:33 +0200 Subject: Coverity issues in lapd_core/gsm mncc In-Reply-To: <51DC6533.1000702@eversberg.eu> References: <20130705054315.GD2519@xiaoyu.lan> <51D7CFAC.9040105@eversberg.eu> <20130706094217.GB10036@xiaoyu.lan> <51D86568.4060508@eversberg.eu> <20130707174432.GJ17761@xiaoyu.lan> <51D9BC74.4070701@eversberg.eu> <20130709165332.GF3910@xiaoyu.lan> <51DC6533.1000702@eversberg.eu> Message-ID: <20130710182933.GN7719@xiaoyu.lan> On Tue, Jul 09, 2013 at 09:32:03PM +0200, Andreas Eversberg wrote: Hi, > + msgb_free(msg); msg = NULL; > dl->send_buffer = NULL; the patch didn't include Peter's feedback. I have now added the above for the reasons mentioned during the review of your patch. holger From andreas at eversberg.eu Wed Jul 10 19:23:13 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Wed, 10 Jul 2013 21:23:13 +0200 Subject: Coverity issues in lapd_core/gsm mncc In-Reply-To: <20130710182933.GN7719@xiaoyu.lan> References: <20130705054315.GD2519@xiaoyu.lan> <51D7CFAC.9040105@eversberg.eu> <20130706094217.GB10036@xiaoyu.lan> <51D86568.4060508@eversberg.eu> <20130707174432.GJ17761@xiaoyu.lan> <51D9BC74.4070701@eversberg.eu> <20130709165332.GF3910@xiaoyu.lan> <51DC6533.1000702@eversberg.eu> <20130710182933.GN7719@xiaoyu.lan> Message-ID: <51DDB4A1.3080100@eversberg.eu> Holger Hans Peter Freyther wrote: > the patch didn't include Peter's feedback. I have now added the above > for the reasons mentioned during the review of your patch. hi holger, hmm. i just don't see why to set msg to NULL. it is not used afterwards. later in the code it is overwritten anyway. regards, andreas From peter at stuge.se Sat Jul 6 09:42:49 2013 From: peter at stuge.se (Peter Stuge) Date: Sat, 6 Jul 2013 11:42:49 +0200 Subject: Coverity issues in lapd_core/gsm mncc In-Reply-To: <51D7CFAC.9040105@eversberg.eu> References: <20130705054315.GD2519@xiaoyu.lan> <51D7CFAC.9040105@eversberg.eu> Message-ID: <20130706094249.9526.qmail@stuge.se> Andreas Eversberg wrote: > +++ b/src/gsm/lapd_core.c > @@ -1950,7 +1950,7 @@ static int lapd_res_req(struct osmo_dlsap_prim *dp, struct lapd_msg_ctx *lctx) > struct lapd_msg_ctx nctx; > > LOGP(DLLAPD, LOGL_INFO, "perform re-establishment (SABM) length=%d\n", > - msg->len); > + (msg) ? msg->len : 0); > > /* be sure that history is empty */ > lapd_dl_flush_hist(dl); > @@ -1962,11 +1962,14 @@ static int lapd_res_req(struct osmo_dlsap_prim *dp, struct lapd_msg_ctx *lctx) > if (dl->send_buffer) > msgb_free(dl->send_buffer); > dl->send_out = 0; > - if (msg && msg->len) > + if (msg && msg->len) { > /* Write data into the send buffer, to be sent first */ > dl->send_buffer = msg; > - else > + } else { > + if (msg) > + msgb_free(msg); > dl->send_buffer = NULL; > + } Does msg also need to be set to NULL after the above msgb_free()? //Peter From holger at freyther.de Sat Jul 6 10:15:02 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sat, 6 Jul 2013 12:15:02 +0200 Subject: Coverity issues in lapd_core/gsm mncc In-Reply-To: <20130706094249.9526.qmail@stuge.se> References: <20130705054315.GD2519@xiaoyu.lan> <51D7CFAC.9040105@eversberg.eu> <20130706094249.9526.qmail@stuge.se> Message-ID: <20130706101502.GF10036@xiaoyu.lan> On Sat, Jul 06, 2013 at 11:42:49AM +0200, Peter Stuge wrote: > > Does msg also need to be set to NULL after the above msgb_free()? I think it is good practice to set it to NULL to get a clean segfault in case we add more code. :) From peter at stuge.se Sat Jul 6 12:02:43 2013 From: peter at stuge.se (Peter Stuge) Date: Sat, 6 Jul 2013 14:02:43 +0200 Subject: Coverity issues in lapd_core/gsm mncc In-Reply-To: <20130706101502.GF10036@xiaoyu.lan> References: <20130705054315.GD2519@xiaoyu.lan> <51D7CFAC.9040105@eversberg.eu> <20130706094249.9526.qmail@stuge.se> <20130706101502.GF10036@xiaoyu.lan> Message-ID: <20130706120243.14972.qmail@stuge.se> Holger Hans Peter Freyther wrote: > > Does msg also need to be set to NULL after the above msgb_free()? > > I think it is good practice to set it to NULL to get a clean segfault > in case we add more code. :) That's a good point too! I was thinking about if the variable is tested again later in the same function. //Peter From boardsofcanada at live.co.uk Fri Jul 5 10:47:10 2013 From: boardsofcanada at live.co.uk (Adam B) Date: Fri, 5 Jul 2013 11:47:10 +0100 Subject: Help with Asterisk setup to stop Openbsc registering handsets Message-ID: Dear Mailinglist I am having a spot of bother with setting up asterisk with openbsc. I have gone with a basic setup from scratch LCR/ASTERISK/SIP minus mISDN as I dont require it and it would not compile it to my current kernel version in ubuntu 12.04 without downgrading it. Anyway my problem is that I don't know how to prevent OpenBSC from using its own HLR and instead forward all phones that want to register to my nanoBTS to do so via Asterisk. This is causing me grief because asterisk is its verbose logs is providing me this error when I try to make a call: > -- Executing [8690 phones:1] Dial("SIP/IMSI466974600011287-00000000", > "SIP/IMSI466974104638690") in new stack > [Dec 18 16:00:49] WARNING[2934]: app_dial.c:2218 dial_exec_full: > Unable to create channel of type 'SIP' (cause 20 - Unknown) > == Everyone is busy/congested at this time (1:0/0/1) > -- Auto fallthrough, channel 'SIP/IMSI466974600011287-00000000' > status is 'CHANUNAVAIL' when I do show sip peers they are all offline because OpenBSC is registering my handsets and not passing on registration to Asterisk. I believe once OpenBSC is passing on registration all will be healthy with asterisk. I don't have my configurations with me at the moment snipit above is from a google search, hopefully some helpful soul will know my blunders without my configs Thank you all . Regards Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Fri Jul 5 12:02:05 2013 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 5 Jul 2013 14:02:05 +0200 Subject: Help with Asterisk setup to stop Openbsc registering handsets In-Reply-To: References: Message-ID: <20130705120205.GA28142@nataraja.gnumonks.org> On Fri, Jul 05, 2013 at 11:47:10AM +0100, Adam B wrote: > Anyway my problem is that I don't know how to prevent OpenBSC from > using its own HLR and instead forward all phones that want to register > to my nanoBTS to do so via Asterisk. This is how it is intended to function. You are using a NITB (network in the box), which is explicitly specified to include a HLR/AUC/VLR/MSC/BSC/SMSC functionality. > This is causing me grief because asterisk is its verbose logs is > providing me this error when I try to make a call: Then your configuration is inconsistent. Either you have provisioned a subscriber in the HLR (specifying his MSISDN as OsmoNITB 'extension'), then it should also be known to your Asterisk installation. Or you have not provisioned the subscriber, and then you never get a call. 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 alexander.chemeris at gmail.com Fri Jul 5 13:18:48 2013 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Fri, 5 Jul 2013 17:18:48 +0400 Subject: Help with Asterisk setup to stop Openbsc registering handsets In-Reply-To: References: Message-ID: Adam, On Fri, Jul 5, 2013 at 2:47 PM, Adam B wrote: > Anyway my problem is that I don't know how to prevent OpenBSC from using its > own HLR and instead forward all phones that want to register to my nanoBTS > to do so via Asterisk. Unfortunately, NITB doesn't have an external interface for registrations yet and thus LCR can't forward them to SIP. We use Freeswitch instead of Asterisk and there we configure Freeswitch in "gateway" mode. In this mode where FS doesn't take decision about a user availability bu itself, it just forwards all calls to relevant interface (LCR SIP interface in this case). Adding an external interface for user registration to NITB and converting it to SIP would be a great step towards a more SIP-friendly architecture. Feel free to contribute ;) -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From boardsofcanada at live.co.uk Fri Jul 5 14:47:36 2013 From: boardsofcanada at live.co.uk (Adam B) Date: Fri, 5 Jul 2013 15:47:36 +0100 Subject: Help with Asterisk setup to stop Openbsc registering handsets In-Reply-To: References: , Message-ID: Thanks guys for your help I've been using OpenBTS too long and assumed setting up asterisk with the nanoBTS with NITB would operate with similar configurations. I couldnt quite understand why there was no pairing of IMSI's in the asterisk configs but that is all self explanitory now and thus I now have calls routing through (all be it with no audio yet!) but I am sure that will be solved easily. I am mainly wanting to use Asterisk integration so I can use this to inject SMS's and have full control of the entire PDU to send different types of SMS. I chose Asterisk purely because I have a set up to do this with openBTS but wanting to upgrade to nanoBTS. Maybe I am trying to create something that has no doubt been done before but I can't find any documentation on how send a full SMS-Deliver PDU in to the nanoBTS. Any knowledge or pointers here would be great, this is something that I wouldnt mind to contribute to if there is not this type of capability already available. Regards Adam > From: alexander.chemeris at gmail.com > Date: Fri, 5 Jul 2013 17:18:48 +0400 > Subject: Re: Help with Asterisk setup to stop Openbsc registering handsets > To: boardsofcanada at live.co.uk > CC: openbsc at lists.osmocom.org > > Adam, > > On Fri, Jul 5, 2013 at 2:47 PM, Adam B wrote: > > Anyway my problem is that I don't know how to prevent OpenBSC from using its > > own HLR and instead forward all phones that want to register to my nanoBTS > > to do so via Asterisk. > > Unfortunately, NITB doesn't have an external interface for > registrations yet and thus LCR can't forward them to SIP. > > We use Freeswitch instead of Asterisk and there we configure > Freeswitch in "gateway" mode. In this mode where FS doesn't take > decision about a user availability bu itself, it just forwards all > calls to relevant interface (LCR SIP interface in this case). > > Adding an external interface for user registration to NITB and > converting it to SIP would be a great step towards a more SIP-friendly > architecture. Feel free to contribute ;) > > -- > Regards, > Alexander Chemeris. > CEO, Fairwaves LLC / ??? ??????? > http://fairwaves.ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.chemeris at gmail.com Sat Jul 6 14:05:51 2013 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Sat, 6 Jul 2013 18:05:51 +0400 Subject: Help with Asterisk setup to stop Openbsc registering handsets In-Reply-To: References: Message-ID: Adam, On Fri, Jul 5, 2013 at 6:47 PM, Adam B wrote: > I am mainly wanting to use Asterisk integration so I can use this to inject > SMS's and have full control of the entire PDU to send different types of > SMS. I chose Asterisk purely because I have a set up to do this with openBTS > but wanting to upgrade to nanoBTS. > > Maybe I am trying to create something that has no doubt been done before but > I can't find any documentation on how send a full SMS-Deliver PDU in to the > nanoBTS. Any knowledge or pointers here would be great, this is something > that I wouldnt mind to contribute to if there is not this type of capability > already available. NITB supports SMPP, but having SIP MESSAGE support would be a great thing, imho. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From andreas at eversberg.eu Sat Jul 6 15:36:11 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Sat, 06 Jul 2013 17:36:11 +0200 Subject: Help with Asterisk setup to stop Openbsc registering handsets In-Reply-To: References: Message-ID: <51D8396B.3040507@eversberg.eu> Alexander Chemeris wrote: > NITB supports SMPP, but having SIP MESSAGE support would be a great thing, imho. you could add your own call control (instead of mncc_builtin or mncc_sock (LCR)). then you would need to write a call control that links MNCC to SIP. this is what is done at LCR (gsm.cpp, gsm_bs.cpp, sip.cpp), you could use that code to parse and generate SIP/MNCC messages. if you want a separate process, you can use the MNCC socket, but then you gonna write what LCR already does. From alexander.chemeris at gmail.com Sat Jul 6 17:16:00 2013 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Sat, 6 Jul 2013 21:16:00 +0400 Subject: Help with Asterisk setup to stop Openbsc registering handsets In-Reply-To: <51D8396B.3040507@eversberg.eu> References: <51D8396B.3040507@eversberg.eu> Message-ID: On Sat, Jul 6, 2013 at 7:36 PM, Andreas Eversberg wrote: > Alexander Chemeris wrote: >> >> NITB supports SMPP, but having SIP MESSAGE support would be a great thing, >> imho. > > you could add your own call control (instead of mncc_builtin or mncc_sock > (LCR)). then you would need to write a call control that links MNCC to SIP. > this is what is done at LCR (gsm.cpp, gsm_bs.cpp, sip.cpp), you could use > that code to parse and generate SIP/MNCC messages. if you want a separate > process, you can use the MNCC socket, but then you gonna write what LCR > already does. Well, in this case we're speaking about SMS, so MNCC is not exactly related. SIP MESSAGE is a way to convey IM messages over SIP and there is a profile for sending SMS over SIP MESSAGE, specified by 3gpp. A short overview of this is available here: http://betelco.blogspot.ru/2009/10/sms-over-3gpp-ims-network.html Speaking of the SIP call control, having an mncc_sip with SIP as an external interface is also a good idea, imho. An important difference with mncc_sock in this case is that mncc_sip should be able to handle timeouts and error cases on both GSM and SIP sides gracefully. I.e. if a link with the SIP server is not 100% stable, it should maintain a consistent state on the GSM side. So to me it looks more like an extension to mncc_internal rather than mncc_sock. And for SIP side a high-level library like reSIProcate/DUM or SofiaSIP should be used to take care of all he corner and special cases of SIP protocol (re-transmission, forking, encryption, TCP support, etc). Then we would have an ideal SIP speaking solution, much better than OpenBTS. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From laforge at gnumonks.org Mon Jul 8 08:57:48 2013 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 8 Jul 2013 10:57:48 +0200 Subject: SMPP / SIP MESSAGE (was Re: Help with Asterisk setup to stop Openbsc registering handsets) In-Reply-To: References: Message-ID: <20130708085748.GD28142@nataraja.gnumonks.org> On Sat, Jul 06, 2013 at 06:05:51PM +0400, Alexander Chemeris wrote: > NITB supports SMPP, but having SIP MESSAGE support would be a great thing, imho. Anyone in need could write a SMPP to SIP MESSAGE translator, I presume. SMPP specifications are public, and there are free software protocol implementations in many programming languages. I prefer to have one interface in OsmoNITB and external translators for oter protocols _unless_ there is important information lost in translation due to different levels of interfaces, etc. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From pablo at gnumonks.org Fri Jul 5 13:28:05 2013 From: pablo at gnumonks.org (pablo at gnumonks.org) Date: Fri, 5 Jul 2013 15:28:05 +0200 Subject: [PATCH openBSC] libmgcp: add enum mgcp_type Message-ID: <1373030885-9564-1-git-send-email-pablo@gnumonks.org> From: Pablo Neira Ayuso This patch replaces the field 'is_transcoded' in the mgcp_endpoint structure by the enum mgcp_type, that can be further extended with new types. --- openbsc/include/openbsc/mgcp_internal.h | 7 ++++++- openbsc/src/libmgcp/mgcp_network.c | 34 +++++++++++++++++++++++-------- openbsc/src/libmgcp/mgcp_protocol.c | 8 ++++---- 3 files changed, 36 insertions(+), 13 deletions(-) diff --git a/openbsc/include/openbsc/mgcp_internal.h b/openbsc/include/openbsc/mgcp_internal.h index 455bb53..d5bd3dd 100644 --- a/openbsc/include/openbsc/mgcp_internal.h +++ b/openbsc/include/openbsc/mgcp_internal.h @@ -96,6 +96,11 @@ struct mgcp_rtp_tap { struct sockaddr_in forward; }; +enum mgcp_type { + MGCP_RTP_DEFAULT = 0, + MGCP_RTP_TRANSCODED, +}; + struct mgcp_endpoint { int allocated; uint32_t ci; @@ -119,7 +124,7 @@ struct mgcp_endpoint { */ struct mgcp_rtp_end trans_bts; struct mgcp_rtp_end trans_net; - int is_transcoded; + enum mgcp_type type; /* sequence bits */ struct mgcp_rtp_state net_state; diff --git a/openbsc/src/libmgcp/mgcp_network.c b/openbsc/src/libmgcp/mgcp_network.c index a2cfc23..7eaacf5 100644 --- a/openbsc/src/libmgcp/mgcp_network.c +++ b/openbsc/src/libmgcp/mgcp_network.c @@ -371,10 +371,19 @@ static int rtp_data_net(struct osmo_fd *fd, unsigned int what) endp->net_end.octets += rc; forward_data(fd->fd, &endp->taps[MGCP_TAP_NET_IN], buf, rc); - if (endp->is_transcoded) - return send_transcoder(&endp->trans_net, endp->cfg, proto == PROTO_RTP, &buf[0], rc); - else - return send_to(endp, DEST_BTS, proto == PROTO_RTP, &addr, &buf[0], rc); + + switch (endp->type) { + case MGCP_RTP_DEFAULT: + return send_to(endp, DEST_BTS, proto == PROTO_RTP, &addr, + buf, rc); + case MGCP_RTP_TRANSCODED: + return send_transcoder(&endp->trans_net, endp->cfg, + proto == PROTO_RTP, buf, rc); + default: + LOGP(DMGCP, LOGL_ERROR, "Bad MGCP type %u on endpoint %u\n", + endp->type, ENDPOINT_NUMBER(endp)); + } + return 0; } static void discover_bts(struct mgcp_endpoint *endp, int proto, struct sockaddr_in *addr) @@ -450,10 +459,19 @@ static int rtp_data_bts(struct osmo_fd *fd, unsigned int what) endp->bts_end.octets += rc; forward_data(fd->fd, &endp->taps[MGCP_TAP_BTS_IN], buf, rc); - if (endp->is_transcoded) - return send_transcoder(&endp->trans_bts, endp->cfg, proto == PROTO_RTP, &buf[0], rc); - else - return send_to(endp, DEST_NETWORK, proto == PROTO_RTP, &addr, &buf[0], rc); + + switch (endp->type) { + case MGCP_RTP_DEFAULT: + return send_to(endp, DEST_NETWORK, proto == PROTO_RTP, &addr, + buf, rc); + case MGCP_RTP_TRANSCODED: + return send_transcoder(&endp->trans_bts, endp->cfg, + proto == PROTO_RTP, buf, rc); + default: + LOGP(DMGCP, LOGL_ERROR, "Bad MGCP type %u on endpoint %u\n", + endp->type, ENDPOINT_NUMBER(endp)); + } + return 0; } static int rtp_data_transcoder(struct mgcp_rtp_end *end, struct mgcp_endpoint *_endp, diff --git a/openbsc/src/libmgcp/mgcp_protocol.c b/openbsc/src/libmgcp/mgcp_protocol.c index dc5e0f9..1e1841a 100644 --- a/openbsc/src/libmgcp/mgcp_protocol.c +++ b/openbsc/src/libmgcp/mgcp_protocol.c @@ -500,7 +500,7 @@ static int allocate_ports(struct mgcp_endpoint *endp) } /* remember that we have set up transcoding */ - endp->is_transcoded = 1; + endp->type = MGCP_RTP_TRANSCODED; } return 0; @@ -1014,7 +1014,7 @@ void mgcp_free_endp(struct mgcp_endpoint *endp) mgcp_rtp_end_reset(&endp->net_end); mgcp_rtp_end_reset(&endp->trans_net); mgcp_rtp_end_reset(&endp->trans_bts); - endp->is_transcoded = 0; + endp->type = MGCP_RTP_DEFAULT; memset(&endp->net_state, 0, sizeof(endp->net_state)); memset(&endp->bts_state, 0, sizeof(endp->bts_state)); @@ -1118,7 +1118,7 @@ static void create_transcoder(struct mgcp_endpoint *endp) int in_endp = ENDPOINT_NUMBER(endp); int out_endp = endp_back_channel(in_endp); - if (!endp->is_transcoded) + if (endp->type != MGCP_RTP_TRANSCODED) return; send_msg(endp, in_endp, endp->trans_bts.local_port, "CRCX", "sendrecv"); @@ -1140,7 +1140,7 @@ static void delete_transcoder(struct mgcp_endpoint *endp) int in_endp = ENDPOINT_NUMBER(endp); int out_endp = endp_back_channel(in_endp); - if (!endp->is_transcoded) + if (endp->type != MGCP_RTP_TRANSCODED) return; send_dlcx(endp, in_endp); -- 1.7.10.4 From peter at stuge.se Fri Jul 5 16:13:53 2013 From: peter at stuge.se (Peter Stuge) Date: Fri, 5 Jul 2013 18:13:53 +0200 Subject: [PATCH openBSC] libmgcp: add enum mgcp_type In-Reply-To: <1373030885-9564-1-git-send-email-pablo@gnumonks.org> References: <1373030885-9564-1-git-send-email-pablo@gnumonks.org> Message-ID: <20130705161353.25582.qmail@stuge.se> pablo at gnumonks.org wrote: > +++ b/openbsc/src/libmgcp/mgcp_network.c > @@ -371,10 +371,19 @@ static int rtp_data_net(struct osmo_fd *fd, unsigned int what) .. > + switch (endp->type) { > + case MGCP_RTP_DEFAULT: > + return send_to(endp, DEST_BTS, proto == PROTO_RTP, &addr, > + buf, rc); > + case MGCP_RTP_TRANSCODED: > + return send_transcoder(&endp->trans_net, endp->cfg, > + proto == PROTO_RTP, buf, rc); > + default: > + LOGP(DMGCP, LOGL_ERROR, "Bad MGCP type %u on endpoint %u\n", > + endp->type, ENDPOINT_NUMBER(endp)); > + } > + return 0; Please consider not having a default: case in the two switch () statements added by this patch. No default: case makes the compiler warn if a value is added to the enum in the future, without corresponding cases being added to the switch (). Since the pattern is to make each case return (I like it!) it would be easy to move the LOGP() to before the return 0; to still get a warning at runtime, even if the compile time warning was ignored. //Peter From holger at freyther.de Sat Jul 6 10:14:00 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sat, 6 Jul 2013 12:14:00 +0200 Subject: [PATCH openBSC] libmgcp: add enum mgcp_type In-Reply-To: <20130705161353.25582.qmail@stuge.se> References: <1373030885-9564-1-git-send-email-pablo@gnumonks.org> <20130705161353.25582.qmail@stuge.se> Message-ID: <20130706101400.GE10036@xiaoyu.lan> On Fri, Jul 05, 2013 at 06:13:53PM +0200, Peter Stuge wrote: > Please consider not having a default: case in the two switch () > statements added by this patch. > > No default: case makes the compiler warn if a value is added to the > enum in the future, without corresponding cases being added to the > switch (). I agree with that. :) From rp.labs at gmx.ch Sat Jul 6 09:01:53 2013 From: rp.labs at gmx.ch (Labs) Date: Sat, 06 Jul 2013 11:01:53 +0200 Subject: Nokia MetroSite EDGE Message-ID: <51D7DD01.7010406@gmx.ch> Hello, I just found this Nokia MetroSite on eBay DE for who is interested. It seems like there were 2 pieces and one was sold for 300 Euro. http://www.ebay.de/itm/NOKIA-Metrosite-EDGE-CS10-BTS-HVMD11-020586A-102-Basisstation-NEU-/150736808657?pt=LH_DefaultDomain_77&hash=item23189d2ad1 Cheers, R. From peter at stuge.se Sat Jul 6 12:00:12 2013 From: peter at stuge.se (Peter Stuge) Date: Sat, 6 Jul 2013 14:00:12 +0200 Subject: Nokia MetroSite EDGE In-Reply-To: <51D7DD01.7010406@gmx.ch> References: <51D7DD01.7010406@gmx.ch> Message-ID: <20130706120012.14811.qmail@stuge.se> Labs wrote: > I just found this Nokia MetroSite on eBay DE for who is interested. Thanks for the tip. The second unit sold quickly. Note that this is only the housing with the "BCF" controller. TRX and a power supply need to be bought separately. //Peter From peter at stuge.se Sat Jul 6 12:32:26 2013 From: peter at stuge.se (Peter Stuge) Date: Sat, 6 Jul 2013 14:32:26 +0200 Subject: Nokia MetroSite EDGE In-Reply-To: <20130706120012.14811.qmail@stuge.se> References: <51D7DD01.7010406@gmx.ch> <20130706120012.14811.qmail@stuge.se> Message-ID: <20130706123226.17396.qmail@stuge.se> Peter Stuge wrote: > Thanks for the tip. The second unit sold quickly. Note that this is > only the housing with the "BCF" controller. TRX and a power supply > need to be bought separately. And line card. //Peter From symack at gmail.com Sat Jul 6 21:59:09 2013 From: symack at gmail.com (Nick Khamis) Date: Sat, 6 Jul 2013 17:59:09 -0400 Subject: Nokia MetroSite EDGE In-Reply-To: <20130706123226.17396.qmail@stuge.se> References: <51D7DD01.7010406@gmx.ch> <20130706120012.14811.qmail@stuge.se> <20130706123226.17396.qmail@stuge.se> Message-ID: That's not fair. Everything is in Deutschland!!! What about Canada ey!!! ;) Nick from Toronto. From rp.labs at gmx.ch Sun Jul 7 06:52:17 2013 From: rp.labs at gmx.ch (Labs) Date: Sun, 07 Jul 2013 08:52:17 +0200 Subject: Nokia MetroSite EDGE In-Reply-To: References: <51D7DD01.7010406@gmx.ch> <20130706120012.14811.qmail@stuge.se> <20130706123226.17396.qmail@stuge.se> Message-ID: <51D91021.4080200@gmx.ch> On 07/06/2013 11:59 PM, Nick Khamis wrote: > That's not fair. Everything is in Deutschland!!! What about Canada ey!!! ;) > If you look carefully on eBay you will see that you can find a lot of Ericsson base stations on eBay in Canada and US. Also I saw many Huawei base sations in Canada that can work on 2G/3G/4G with the right cards and I also saw some RRUs (Remote Radio Unit). I am not sure if we can use the Huawei stuff with OpenBSC but we can try. Considering that now in EU they are widely deployed at some point maybe we can see them on eBay in EU. > Nick from Toronto. > Regards, R. From rp.labs at gmx.ch Sun Jul 7 06:45:58 2013 From: rp.labs at gmx.ch (Labs) Date: Sun, 07 Jul 2013 08:45:58 +0200 Subject: Nokia MetroSite EDGE In-Reply-To: <20130706123226.17396.qmail@stuge.se> References: <51D7DD01.7010406@gmx.ch> <20130706120012.14811.qmail@stuge.se> <20130706123226.17396.qmail@stuge.se> Message-ID: <51D90EA6.6060806@gmx.ch> On 07/06/2013 02:32 PM, Peter Stuge wrote: > Peter Stuge wrote: >> Thanks for the tip. The second unit sold quickly. Note that this is >> only the housing with the "BCF" controller. TRX and a power supply >> need to be bought separately. > > And line card. > I thought that something is missing when I saw the empty slots. The problem is that it is hard to get the parts considering that MetroSite was not so much deployed from what I know. > > //Peter > Regards, R. From holger at freyther.de Sun Jul 7 07:08:26 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sun, 7 Jul 2013 09:08:26 +0200 Subject: 7bit changes to libosmocore Message-ID: <20130707070826.GB17761@xiaoyu.lan> Dear LaF0rge, Andreas, I am really disappointed about the used process for this change. As an absolute minimum run "make check" after bigger changes. The run takes about 20 seconds (and that is probably 15s in the timer test), I have to spend way more time fixing the fall-out from that and it creates the impression that you do not value my time! I think Andreas should have posted this kind of change to the mailing list and ask for review. The way it was done is really unacceptable and the build is still broken. And to make it worse I think the change is wrong in several ways: 1.) The issue of the last '7bit' being 'empty' only applies to USSD/CB: "If the total number of characters to be sent equals (8n-1) where n=1,2,3 etc. then there are 7 spare bits at the end of the message. To avoid the situation where the receiving entity confuses 7 binary zero pad bits as the @ character, the carriage return or character (defined in subclause 7.1.1) shall be used for padding in this situation, just as for Cell Broadcast." In SMS one has both the octet length and the character length inside the messages. In USSD this information is not present. 2.) The semantic of the change is bad. + octet_len = response_len*7/8; + if (response_len*7%8 != 0) + octet_len++; + /* Warning, response_len indicates the amount of septets + * (characters), we need amount of octets occupied */ Every caller of gsm_7bit_encode now needs to consider adding this change, it is better to move this into gsm_utils.c. E.g. take a look at my branch called zecke/features/alpha-numeric for a gsm_7bit_encode_oct. Which comes with a testcase... and moves this responsibility into libosmocore and is based on the real octets written (instead of trying to figure it our afterwards). We all make money by working on Osmocom sub-projects and I really can't stand such amateurish work. Can we force reset master to before the merge and try again? cheers holger From holger at freyther.de Sun Jul 7 08:24:46 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sun, 7 Jul 2013 10:24:46 +0200 Subject: 7bit changes to libosmocore In-Reply-To: <20130707070826.GB17761@xiaoyu.lan> References: <20130707070826.GB17761@xiaoyu.lan> Message-ID: <20130707082446.GD17761@xiaoyu.lan> On Sun, Jul 07, 2013 at 09:08:26AM +0200, Holger Hans Peter Freyther wrote: > "If the total number of characters to be sent equals (8n-1) where > n=1,2,3 etc. then there are 7 spare bits at the end of the message. > To avoid the situation where the receiving entity confuses 7 binary > zero pad bits as the @ character, the carriage return or character > (defined in subclause 7.1.1) shall be used for padding in this situation, > just as for Cell Broadcast." And the change is incomplete as well: "If is intended to be the last character and the message (including the wanted ) ends on an octet boundary, then another must be added together with a padding bit 0. The receiving entity will perform the carriage return function twice, but this will not result in misoperation as the definition of in subclause 7.1.1 is identical to the definition of . The receiving entity shall remove the final character where the message ends on an octet boundary with as the last character." holger From holger at freyther.de Sun Jul 7 12:16:05 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sun, 7 Jul 2013 14:16:05 +0200 Subject: 7bit changes to libosmocore In-Reply-To: <20130707070826.GB17761@xiaoyu.lan> References: <20130707070826.GB17761@xiaoyu.lan> Message-ID: <20130707121605.GG17761@xiaoyu.lan> On Sun, Jul 07, 2013 at 09:08:26AM +0200, Holger Hans Peter Freyther wrote: > 2.) The semantic of the change is bad. > > + octet_len = response_len*7/8; > + if (response_len*7%8 != 0) > + octet_len++; > + /* Warning, response_len indicates the amount of septets > + * (characters), we need amount of octets occupied */ I have reverted the two changes and rebased my zecke/features/alpha-numeric branch. Please review the two commits of the branch. In regard to the USSD fixes I would propose the following: * We introduce a new API function that will handle the specifics of the USSD packing (last 7bit unused, last 7bit ). The signature could be: int gsm_7bit_encode_ussd(uint8_t *result, const char *data, int *octets_written); int gsm_7bit_decode_ussd(char *decoded, const uint8_t *user_data, uint8_t length); * Add a testcase for the above (e.g. '1234567\r' should result in a double \r\r). * Switch the USSD code in libosmocore over I would argue that writing a regression test is industry standard and basic software engineering but running "make check" after doing a change is absolutely basic. holger From andreas at eversberg.eu Sun Jul 7 12:41:50 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Sun, 07 Jul 2013 14:41:50 +0200 Subject: 7bit changes to libosmocore In-Reply-To: <20130707121605.GG17761@xiaoyu.lan> References: <20130707070826.GB17761@xiaoyu.lan> <20130707121605.GG17761@xiaoyu.lan> Message-ID: <51D9620E.9010607@eversberg.eu> hi holger, > * We introduce a new API function that will handle the specifics of > the USSD packing (last 7bit unused, last 7bit ). The signature > could be: > > int gsm_7bit_encode_ussd(uint8_t *result, const char *data, int *octets_written); > int gsm_7bit_decode_ussd(char *decoded, const uint8_t *user_data, uint8_t length); > > i just pushed a branch (jolly/7bit_ussd) i was working on the last hours. it is quite exactly what you prosed. > * Add a testcase for the above (e.g. '1234567\r' should result in a > double \r\r). > * Switch the USSD code in libosmocore over > > also it includes a test case. the result is similar to your proposal. currently i pushed everything togehter without propper splitting and commit log message. after review, i can do that. best regards, andreas From holger at freyther.de Sun Jul 7 13:09:21 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sun, 7 Jul 2013 15:09:21 +0200 Subject: 7bit changes to libosmocore In-Reply-To: <51D9620E.9010607@eversberg.eu> References: <20130707070826.GB17761@xiaoyu.lan> <20130707121605.GG17761@xiaoyu.lan> <51D9620E.9010607@eversberg.eu> Message-ID: <20130707130921.GH17761@xiaoyu.lan> On Sun, Jul 07, 2013 at 02:41:50PM +0200, Andreas Eversberg wrote: > hi holger, Dear Andreas, > i just pushed a branch (jolly/7bit_ussd) i was working on the last > hours. it is quite exactly what you prosed. I don't think it needs much splitting my comments are: * If it helps we can export 'shift' from the common function as well, maybe this simplifies your calculation. * I would write ('\r' << 1), it is more obvious than 0x1A and modern compilers propagate such constants. * The decoding, it might be easier to verify this condition on the encoded data? * In the encoding. If you change octets you also want to modify 'y' as the number of septets. > also it includes a test case. the result is similar to your proposal. What I don't understand is.. why the first broken version if you know it is not correct? It didn't save any of your time and it wasted plenty of mine. From andreas at eversberg.eu Sun Jul 7 13:56:48 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Sun, 07 Jul 2013 15:56:48 +0200 Subject: 7bit changes to libosmocore In-Reply-To: <20130707130921.GH17761@xiaoyu.lan> References: <20130707070826.GB17761@xiaoyu.lan> <20130707121605.GG17761@xiaoyu.lan> <51D9620E.9010607@eversberg.eu> <20130707130921.GH17761@xiaoyu.lan> Message-ID: <51D973A0.40008@eversberg.eu> Holger Hans Peter Freyther wrote: > On Sun, Jul 07, 2013 at 02:41:50PM +0200, Andreas Eversberg wrote: > >> hi holger, >> > Dear Andreas, > > >> i just pushed a branch (jolly/7bit_ussd) i was working on the last >> hours. it is quite exactly what you prosed. >> > I don't think it needs much splitting my comments are: > > * If it helps we can export 'shift' from the common function as well, > maybe this simplifies your calculation. > maybe, it will, but this would require export over two functions and still requires some calculations. i think it is simpler to understand the code, when using the number of characters for calculation. > * I would write ('\r' << 1), it is more obvious than 0x1A and modern > compilers propagate such constants. > > * The decoding, it might be easier to verify this condition on the > encoded data? > > * In the encoding. If you change octets you also want to modify 'y' > as the number of septets. > see my branch. >> also it includes a test case. the result is similar to your proposal. >> > What I don't understand is.. why the first broken version if you know > it is not correct? It didn't save any of your time and it wasted plenty > of mine. > if i would have known that it is not correct, i would have already fixed it. also it was not clear to me that SMS end USSD encoding is a bit different. From holger at freyther.de Sun Jul 7 16:37:57 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sun, 7 Jul 2013 18:37:57 +0200 Subject: 7bit changes to libosmocore In-Reply-To: <51D973A0.40008@eversberg.eu> References: <20130707070826.GB17761@xiaoyu.lan> <20130707121605.GG17761@xiaoyu.lan> <51D9620E.9010607@eversberg.eu> <20130707130921.GH17761@xiaoyu.lan> <51D973A0.40008@eversberg.eu> Message-ID: <20130707163757.GI17761@xiaoyu.lan> On Sun, Jul 07, 2013 at 03:56:48PM +0200, Andreas Eversberg wrote: > if i would have known that it is not correct, i would have already fixed > it. also it was not clear to me that SMS end USSD encoding is a bit > different. Well, just talking about the process (they way things were done). For your initial change you didn't even run "make check" and now after having wasted my time you do the fixup and contribute a testcase to the testsuite you didn't run in the first place. I am not happy about my time being wasted like this. From laforge at gnumonks.org Sun Jul 7 19:06:32 2013 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 7 Jul 2013 21:06:32 +0200 Subject: development process (was Re: 7bit changes to libosmocore) In-Reply-To: <20130707163757.GI17761@xiaoyu.lan> References: <20130707070826.GB17761@xiaoyu.lan> <20130707121605.GG17761@xiaoyu.lan> <51D9620E.9010607@eversberg.eu> <20130707130921.GH17761@xiaoyu.lan> <51D973A0.40008@eversberg.eu> <20130707163757.GI17761@xiaoyu.lan> Message-ID: <20130707190632.GU28142@nataraja.gnumonks.org> Dear Holger, I think you have iterated the point about 'wasted time' sufficiently enough. I understand you being upset, and the point has been driven home to everyone very clearly. I take responsibility for merging the 7bit changes. The 'make check' was unfortunately only discovered immediately after the push, and I sent a notice to Andreas that this needs fixing. The discussion of 'stability' vs. 'merging new developments' is a difficult one, and each project has to find its way around that. Linux had parallell stable an development trees for a long time, but this requires a lot more additional effort and people who actually work on 'stable' with time and discipline (and a motivation to do so, which often results from commercial use). I would personally satte: 1) there is no excuse for not running 'make check' to apply existing test cases against changes that are proposed for merging. No exception here. 2) patches requested to be merged should generally be sent through the applicable mailing list before merging them to master. No merge requests via private e-mail, and not just by mentioning a branch but by posting the entire patch set, patch for patch (git-send-email). This gives them much more visibility to more people. 2) for 'master' I would still want to see a more relaxed attitude than only accepting changes for which comprehensive test cases exist. That is too extreme. We need to balance stability vs. innovation here. Master may break things here and there. It's not a release for production use. 3) We should discuss whether we actually would like to start making formall releases (as opposed to asking everyone to use git master), and/or a stable branch which will only cherry-pick changes from master based on certain guidelines. Regards, Haradl -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Mon Jul 8 09:06:30 2013 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 8 Jul 2013 11:06:30 +0200 Subject: 7bit changes to libosmocore In-Reply-To: <20130707163757.GI17761@xiaoyu.lan> References: <20130707070826.GB17761@xiaoyu.lan> <20130707121605.GG17761@xiaoyu.lan> <51D9620E.9010607@eversberg.eu> <20130707130921.GH17761@xiaoyu.lan> <51D973A0.40008@eversberg.eu> <20130707163757.GI17761@xiaoyu.lan> Message-ID: <20130708090630.GE28142@nataraja.gnumonks.org> Hi Holger and Andreas, On Sun, Jul 07, 2013 at 06:37:57PM +0200, Holger Hans Peter Freyther wrote: > Well, just talking about the process (they way things were done). We can establish: * Andreas should have run 'make check' before asking me to merge * I should have run 'make check' ahead of the commit and not immediately after ;) My apologies for that. * I should have done more careful review of the 7bit changes * merge requests should not go in private mail but on the list, giving the entire team the ability to review before it is merged. So as a result, we introduce a new rule / process: * merge requests will go through the public mailing list, with the complete patch-set posted via git-send-email and an explicit statement that this is a request for review+merge. Let's try this for some time and see if we can avoid to cause this problem again. And in general, please try to keep a constructive atmosphere on the list, even under conditions of stress. Nobody here _intentionally_ wants to waste time of others. We have to work together on this, the Osmocom community is small enough that we cannot afford to loose any of you due to frustration. 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 peter at stuge.se Mon Jul 8 19:44:53 2013 From: peter at stuge.se (Peter Stuge) Date: Mon, 8 Jul 2013 21:44:53 +0200 Subject: 7bit changes to libosmocore In-Reply-To: <20130708090630.GE28142@nataraja.gnumonks.org> References: <20130707070826.GB17761@xiaoyu.lan> <20130707121605.GG17761@xiaoyu.lan> <51D9620E.9010607@eversberg.eu> <20130707130921.GH17761@xiaoyu.lan> <51D973A0.40008@eversberg.eu> <20130707163757.GI17761@xiaoyu.lan> <20130708090630.GE28142@nataraja.gnumonks.org> Message-ID: <20130708194453.15771.qmail@stuge.se> Harald Welte wrote: > We can establish: > > * Andreas should have run 'make check' before asking me to merge > * I should have run 'make check' ahead of the commit and not immediately > after ;) My apologies for that. .. > So as a result, we introduce a new rule / process: Maybe consider running 'make check' in a pre-receive hook on the server. I'm a big fan of Gerrit because it allows such verification to run asynchronously after a push. Gerrit sits between the developer and the official git repository. Everybody pushes to Gerrit, not to the actual repo. (Yes, when using a workflow that depends on gitolite or gitosis access control becomes an issue with Gerrit.) //Peter From alexander.chemeris at gmail.com Tue Jul 9 03:05:10 2013 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Tue, 9 Jul 2013 07:05:10 +0400 Subject: 7bit changes to libosmocore In-Reply-To: <20130708194453.15771.qmail@stuge.se> References: <20130707070826.GB17761@xiaoyu.lan> <20130707121605.GG17761@xiaoyu.lan> <51D9620E.9010607@eversberg.eu> <20130707130921.GH17761@xiaoyu.lan> <51D973A0.40008@eversberg.eu> <20130707163757.GI17761@xiaoyu.lan> <20130708090630.GE28142@nataraja.gnumonks.org> <20130708194453.15771.qmail@stuge.se> Message-ID: On Mon, Jul 8, 2013 at 11:44 PM, Peter Stuge wrote: > Harald Welte wrote: >> We can establish: >> >> * Andreas should have run 'make check' before asking me to merge >> * I should have run 'make check' ahead of the commit and not immediately >> after ;) My apologies for that. > .. >> So as a result, we introduce a new rule / process: > > Maybe consider running 'make check' in a pre-receive hook on the > server. > > I'm a big fan of Gerrit because it allows such verification to run > asynchronously after a push. Gerrit sits between the developer and > the official git repository. Everybody pushes to Gerrit, not to the > actual repo. (Yes, when using a workflow that depends on gitolite or > gitosis access control becomes an issue with Gerrit.) +1. It has much nicer interface for review as well. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From 246tnt at gmail.com Wed Jul 10 13:00:14 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 10 Jul 2013 15:00:14 +0200 Subject: 7bit changes to libosmocore In-Reply-To: <20130708194453.15771.qmail@stuge.se> References: <20130707070826.GB17761@xiaoyu.lan> <20130707121605.GG17761@xiaoyu.lan> <51D9620E.9010607@eversberg.eu> <20130707130921.GH17761@xiaoyu.lan> <51D973A0.40008@eversberg.eu> <20130707163757.GI17761@xiaoyu.lan> <20130708090630.GE28142@nataraja.gnumonks.org> <20130708194453.15771.qmail@stuge.se> Message-ID: Hi, > Maybe consider running 'make check' in a pre-receive hook on the > server. Not so easy ... it's not good practice to just allow anyone with push privilege to execute code on the server like that. So a good system with proper separation etc ... would be non-trivial. Also, this would slow down pushes to a crawl since you'd need to actually build the thing and its dependencies ... Cheers, Sylvain From laforge at gnumonks.org Wed Jul 10 15:52:16 2013 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 10 Jul 2013 17:52:16 +0200 Subject: 7bit changes to libosmocore In-Reply-To: References: <20130707070826.GB17761@xiaoyu.lan> <20130707121605.GG17761@xiaoyu.lan> <51D9620E.9010607@eversberg.eu> <20130707130921.GH17761@xiaoyu.lan> <51D973A0.40008@eversberg.eu> <20130707163757.GI17761@xiaoyu.lan> <20130708090630.GE28142@nataraja.gnumonks.org> <20130708194453.15771.qmail@stuge.se> Message-ID: <20130710155216.GA6004@nataraja.gnumonks.org> On Wed, Jul 10, 2013 at 03:00:14PM +0200, Sylvain Munaut wrote: > Hi, > > > Maybe consider running 'make check' in a pre-receive hook on the > > server. > > Not so easy ... it's not good practice to just allow anyone with push > privilege to execute code on the server like that. > So a good system with proper separation etc ... would be non-trivial. > Also, this would slow down pushes to a crawl since you'd need to > actually build the thing and its dependencies ... as an alternative, offer something like check_patch.pl of Linux kernel to the developer, but which not only checks for indentation/coding style but whihc also does the 'make check'. More reasonable and no load/security on the server. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From holger at freyther.de Wed Jul 10 17:00:45 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Wed, 10 Jul 2013 19:00:45 +0200 Subject: 7bit changes to libosmocore In-Reply-To: <20130710155216.GA6004@nataraja.gnumonks.org> References: <20130707070826.GB17761@xiaoyu.lan> <20130707121605.GG17761@xiaoyu.lan> <51D9620E.9010607@eversberg.eu> <20130707130921.GH17761@xiaoyu.lan> <51D973A0.40008@eversberg.eu> <20130707163757.GI17761@xiaoyu.lan> <20130708090630.GE28142@nataraja.gnumonks.org> <20130708194453.15771.qmail@stuge.se> <20130710155216.GA6004@nataraja.gnumonks.org> Message-ID: <20130710170045.GI7719@xiaoyu.lan> On Wed, Jul 10, 2013 at 05:52:16PM +0200, Harald Welte wrote: > as an alternative, offer something like check_patch.pl of Linux kernel > to the developer, but which not only checks for indentation/coding style > but whihc also does the 'make check'. More reasonable and no > load/security on the server. I think it is a social problem, so no technological solution exists. I will add redundancy and reply somewhere else with similar content but from my point of view one should do the following on a branch before asking it to be merged: 1.) rebase against origin/master 2.) Do not mix too many concerns, so maybe create different patch series 3.) go through each change for sanity checking, check the commit message (if the problem fixed is properly described and if a drunk guy in at 10:00 am will understand and have enough context what was attempted to be fixed, I learned this with WebKit and re-learned it with the paging changes in OpenBSC.. so through my own failure) 4.) Make sure that each commit passes make and make check (distcheck) 5.) Ask things to be merged. So we are all humans and we sometimes don't do the above, sometimes we are lucky and it doesn't get noticed. But in case it is not I think the following should be a social norm: 1.) Fix it 2.) Apologize 3.) Promise to be more careful in the future and attempt to really do it cheers holger From holger at freyther.de Wed Jul 10 17:07:55 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Wed, 10 Jul 2013 19:07:55 +0200 Subject: 7bit changes to libosmocore In-Reply-To: <20130710155216.GA6004@nataraja.gnumonks.org> References: <20130707070826.GB17761@xiaoyu.lan> <20130707121605.GG17761@xiaoyu.lan> <51D9620E.9010607@eversberg.eu> <20130707130921.GH17761@xiaoyu.lan> <51D973A0.40008@eversberg.eu> <20130707163757.GI17761@xiaoyu.lan> <20130708090630.GE28142@nataraja.gnumonks.org> <20130708194453.15771.qmail@stuge.se> <20130710155216.GA6004@nataraja.gnumonks.org> Message-ID: <20130710170755.GJ7719@xiaoyu.lan> On Wed, Jul 10, 2013 at 05:52:16PM +0200, Harald Welte wrote: > as an alternative, offer something like check_patch.pl of Linux kernel > to the developer, but which not only checks for indentation/coding style > but whihc also does the 'make check'. More reasonable and no > load/security on the server. In terms of technology. I see the following options: * Use the above script and push all commits of a branch (we want to test each commit) to Osmocom test repository and have travis-ci (a Ubuntu VM...) build it and we feed some info back. * We use gerrit for things we want to stage. Gerrit and a Jenkins would cooperate. There is ACL and user management. Everybody could signup with a OpenID... we could setup a VM with snapshot.. or limit the people that may push.. * Create a script to create debian packages and push them to build.opensuse.org and let them build things for us... cheers holger From Max.Suraev at fairwaves.ru Wed Jul 10 17:14:28 2013 From: Max.Suraev at fairwaves.ru (=?UTF-8?B?4piO?=) Date: Wed, 10 Jul 2013 19:14:28 +0200 Subject: 7bit changes to libosmocore In-Reply-To: <20130710170755.GJ7719@xiaoyu.lan> References: <20130707070826.GB17761@xiaoyu.lan> <20130707121605.GG17761@xiaoyu.lan> <51D9620E.9010607@eversberg.eu> <20130707130921.GH17761@xiaoyu.lan> <51D973A0.40008@eversberg.eu> <20130707163757.GI17761@xiaoyu.lan> <20130708090630.GE28142@nataraja.gnumonks.org> <20130708194453.15771.qmail@stuge.se> <20130710155216.GA6004@nataraja.gnumonks.org> <20130710170755.GJ7719@xiaoyu.lan> Message-ID: <51DD9674.5030604@fairwaves.ru> 10.07.2013 19:07, Holger Hans Peter Freyther ?????: > > * Create a script to create debian packages and push them to > build.opensuse.org and let them build things for us... > That would be the best IMO - in addition to smoothing out commit process this will make it much easier to install and maintain everything. -- best regards, Max, http://fairwaves.ru From alexander.chemeris at gmail.com Wed Jul 10 19:06:03 2013 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Wed, 10 Jul 2013 23:06:03 +0400 Subject: 7bit changes to libosmocore In-Reply-To: <20130710170755.GJ7719@xiaoyu.lan> References: <20130707070826.GB17761@xiaoyu.lan> <20130707121605.GG17761@xiaoyu.lan> <51D9620E.9010607@eversberg.eu> <20130707130921.GH17761@xiaoyu.lan> <51D973A0.40008@eversberg.eu> <20130707163757.GI17761@xiaoyu.lan> <20130708090630.GE28142@nataraja.gnumonks.org> <20130708194453.15771.qmail@stuge.se> <20130710155216.GA6004@nataraja.gnumonks.org> <20130710170755.GJ7719@xiaoyu.lan> Message-ID: On Wed, Jul 10, 2013 at 9:07 PM, Holger Hans Peter Freyther wrote: > * We use gerrit for things we want to stage. Gerrit and a Jenkins would > cooperate. There is ACL and user management. Everybody could signup > with a OpenID... we could setup a VM with snapshot.. or limit the people > that may push.. > > * Create a script to create debian packages and push them to > build.opensuse.org and let them build things for us... The latter is always a great thing to do (in addition to having an official PPA for Ubuntu). But it's not a substitution for the former. PS As I already voted - I believe in the Gerrit way of reviewing. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From laforge at gnumonks.org Wed Jul 10 20:16:22 2013 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 10 Jul 2013 22:16:22 +0200 Subject: building / make check / ... (was Re: 7bit changes to libosmocore) In-Reply-To: <20130710170755.GJ7719@xiaoyu.lan> References: <20130707121605.GG17761@xiaoyu.lan> <51D9620E.9010607@eversberg.eu> <20130707130921.GH17761@xiaoyu.lan> <51D973A0.40008@eversberg.eu> <20130707163757.GI17761@xiaoyu.lan> <20130708090630.GE28142@nataraja.gnumonks.org> <20130708194453.15771.qmail@stuge.se> <20130710155216.GA6004@nataraja.gnumonks.org> <20130710170755.GJ7719@xiaoyu.lan> Message-ID: <20130710201622.GE6004@nataraja.gnumonks.org> Hi Holger, On Wed, Jul 10, 2013 at 07:07:55PM +0200, Holger Hans Peter Freyther wrote: > In terms of technology. I see the following options: > > * Use the above script and push all commits of a branch (we want to test > each commit) to Osmocom test repository and have travis-ci (a Ubuntu > VM...) build it and we feed some info back. If at all, I'm more in favor of client-side builds. Something as simple as 'take this branch, use the kernel coding style check_patch script, build each and every commit (locally) and return some status, preferrably by simply sending mail to the user himself. Then that process can be run in background without monitoring output on the console. > * We use gerrit for things we want to stage. Gerrit and a Jenkins would > cooperate. There is ACL and user management. Everybody could signup > with a OpenID... we could setup a VM with snapshot.. or limit the people > that may push.. I'm really against such complex technology. That's not the kind of project I want to be involved in. And I hate web interfaces, they are always slow, require on-line connectivity and the use of a mouse. E-mail is so much more convenient. > * Create a script to create debian packages and push them to > build.opensuse.org and let them build things for us... sorry for being the naysayer again, but I reall dislike all this 'cloud' approach. I'd prefer to keep things simple and local, don't add external dependencies, etc. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From holger at freyther.de Thu Jul 11 05:52:08 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Thu, 11 Jul 2013 07:52:08 +0200 Subject: building / make check / ... (was Re: 7bit changes to libosmocore) In-Reply-To: <20130710201622.GE6004@nataraja.gnumonks.org> References: <51D9620E.9010607@eversberg.eu> <20130707130921.GH17761@xiaoyu.lan> <51D973A0.40008@eversberg.eu> <20130707163757.GI17761@xiaoyu.lan> <20130708090630.GE28142@nataraja.gnumonks.org> <20130708194453.15771.qmail@stuge.se> <20130710155216.GA6004@nataraja.gnumonks.org> <20130710170755.GJ7719@xiaoyu.lan> <20130710201622.GE6004@nataraja.gnumonks.org> Message-ID: <20130711055208.GB15643@xiaoyu.lan> On Wed, Jul 10, 2013 at 10:16:22PM +0200, Harald Welte wrote: > If at all, I'm more in favor of client-side builds. Something as simple > as 'take this branch, use the kernel coding style check_patch script, > build each and every commit (locally) and return some status, > preferrably by simply sending mail to the user himself. Then that > process can be run in background without monitoring output on the > console. I classified this as a social problem because if someone is repeatable not willing to run make and make check on the last commit, I doubt that he will run an extra script as part of his development process. Please be more careful, check your things because you ask/force others to spend time on it and most importantly learn from your mistakes. From laforge at gnumonks.org Thu Jul 11 06:43:55 2013 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 11 Jul 2013 08:43:55 +0200 Subject: building / make check / ... (was Re: 7bit changes to libosmocore) In-Reply-To: <20130711055208.GB15643@xiaoyu.lan> References: <20130707130921.GH17761@xiaoyu.lan> <51D973A0.40008@eversberg.eu> <20130707163757.GI17761@xiaoyu.lan> <20130708090630.GE28142@nataraja.gnumonks.org> <20130708194453.15771.qmail@stuge.se> <20130710155216.GA6004@nataraja.gnumonks.org> <20130710170755.GJ7719@xiaoyu.lan> <20130710201622.GE6004@nataraja.gnumonks.org> <20130711055208.GB15643@xiaoyu.lan> Message-ID: <20130711064355.GL6004@nataraja.gnumonks.org> Hi Holger, On Thu, Jul 11, 2013 at 07:52:08AM +0200, Holger Hans Peter Freyther wrote: > I classified this as a social problem because if someone is repeatable > not willing to run make and make check on the last commit, I doubt > that he will run an extra script as part of his development process. I would definitely [want] to use such a script. > From a technical point the above makes sense. Where would you keep > the script? Libosmocore and install it as part of it? A new repo? libosmocore seems fine. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From holger at freyther.de Thu Jul 11 11:58:26 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Thu, 11 Jul 2013 13:58:26 +0200 Subject: building / make check / ... (was Re: 7bit changes to libosmocore) In-Reply-To: <20130711064355.GL6004@nataraja.gnumonks.org> References: <51D973A0.40008@eversberg.eu> <20130707163757.GI17761@xiaoyu.lan> <20130708090630.GE28142@nataraja.gnumonks.org> <20130708194453.15771.qmail@stuge.se> <20130710155216.GA6004@nataraja.gnumonks.org> <20130710170755.GJ7719@xiaoyu.lan> <20130710201622.GE6004@nataraja.gnumonks.org> <20130711055208.GB15643@xiaoyu.lan> <20130711064355.GL6004@nataraja.gnumonks.org> Message-ID: <20130711115826.GF15643@xiaoyu.lan> On Thu, Jul 11, 2013 at 08:43:55AM +0200, Harald Welte wrote: > Hi Holger, > > On Thu, Jul 11, 2013 at 07:52:08AM +0200, Holger Hans Peter Freyther wrote: > > > I classified this as a social problem because if someone is repeatable > > not willing to run make and make check on the last commit, I doubt > > that he will run an extra script as part of his development process. > > I would definitely [want] to use such a script. A proof of concept requiring git 1.8 is like this (and it includes a todo list). #!/bin/sh # Say hello echo "Going to rebase your branch against master and testing" # TODO: # 1.) Check for git 1.8 for the -x option # 2.) Check/Find checkpatch.pl installed on the system or copy it # 3.) Make it work with OpenBSC and make -C openbsc/ as parameter # 4.) Integrate it to a Makefile.am (like make check-for-submit) # 5.) Install a trap handler to issue a git rebase --abort CHECKPATCH="checkpatch.pl - --no-signoff --ignore LONG_LINE" CMD="make check && make distcheck && (git format-patch --stdout HEAD^1..HEAD | $CHECKPATCH)" BRANCH="origin/master" EDITOR=/bin/true git rebase -i -x "$CMD" $BRANCH #> /dev/null 2>&1 RES=$? if [ $RES -eq 0 ]; then echo "All looks fine" else # Execute again... eval $CMD echo "Stuff isn't working!!!! Consider using git rebase --abort" exit 1 fi From pablo at gnumonks.org Mon Jul 8 03:09:46 2013 From: pablo at gnumonks.org (pablo at gnumonks.org) Date: Mon, 8 Jul 2013 05:09:46 +0200 Subject: [OpenBSC PATCHv2] libmgcp: add enum mgcp_type Message-ID: <1373252986-17304-1-git-send-email-pablo@gnumonks.org> From: Pablo Neira Ayuso This patch replaces the field 'is_transcoded' in the mgcp_endpoint structure by the enum mgcp_type, that can be further extended with new types. --- v2: remove default: case and move LOGP to before the return 0; as suggested by Peter. openbsc/include/openbsc/mgcp_internal.h | 7 ++++++- openbsc/src/libmgcp/mgcp_network.c | 34 +++++++++++++++++++++++-------- openbsc/src/libmgcp/mgcp_protocol.c | 8 ++++---- 3 files changed, 36 insertions(+), 13 deletions(-) diff --git a/openbsc/include/openbsc/mgcp_internal.h b/openbsc/include/openbsc/mgcp_internal.h index 455bb53..d5bd3dd 100644 --- a/openbsc/include/openbsc/mgcp_internal.h +++ b/openbsc/include/openbsc/mgcp_internal.h @@ -96,6 +96,11 @@ struct mgcp_rtp_tap { struct sockaddr_in forward; }; +enum mgcp_type { + MGCP_RTP_DEFAULT = 0, + MGCP_RTP_TRANSCODED, +}; + struct mgcp_endpoint { int allocated; uint32_t ci; @@ -119,7 +124,7 @@ struct mgcp_endpoint { */ struct mgcp_rtp_end trans_bts; struct mgcp_rtp_end trans_net; - int is_transcoded; + enum mgcp_type type; /* sequence bits */ struct mgcp_rtp_state net_state; diff --git a/openbsc/src/libmgcp/mgcp_network.c b/openbsc/src/libmgcp/mgcp_network.c index a2cfc23..e9b58b2 100644 --- a/openbsc/src/libmgcp/mgcp_network.c +++ b/openbsc/src/libmgcp/mgcp_network.c @@ -371,10 +371,19 @@ static int rtp_data_net(struct osmo_fd *fd, unsigned int what) endp->net_end.octets += rc; forward_data(fd->fd, &endp->taps[MGCP_TAP_NET_IN], buf, rc); - if (endp->is_transcoded) - return send_transcoder(&endp->trans_net, endp->cfg, proto == PROTO_RTP, &buf[0], rc); - else - return send_to(endp, DEST_BTS, proto == PROTO_RTP, &addr, &buf[0], rc); + + switch (endp->type) { + case MGCP_RTP_DEFAULT: + return send_to(endp, DEST_BTS, proto == PROTO_RTP, &addr, + buf, rc); + case MGCP_RTP_TRANSCODED: + return send_transcoder(&endp->trans_net, endp->cfg, + proto == PROTO_RTP, buf, rc); + } + + LOGP(DMGCP, LOGL_ERROR, "Bad MGCP type %u on endpoint %u\n", + endp->type, ENDPOINT_NUMBER(endp)); + return 0; } static void discover_bts(struct mgcp_endpoint *endp, int proto, struct sockaddr_in *addr) @@ -450,10 +459,19 @@ static int rtp_data_bts(struct osmo_fd *fd, unsigned int what) endp->bts_end.octets += rc; forward_data(fd->fd, &endp->taps[MGCP_TAP_BTS_IN], buf, rc); - if (endp->is_transcoded) - return send_transcoder(&endp->trans_bts, endp->cfg, proto == PROTO_RTP, &buf[0], rc); - else - return send_to(endp, DEST_NETWORK, proto == PROTO_RTP, &addr, &buf[0], rc); + + switch (endp->type) { + case MGCP_RTP_DEFAULT: + return send_to(endp, DEST_NETWORK, proto == PROTO_RTP, &addr, + buf, rc); + case MGCP_RTP_TRANSCODED: + return send_transcoder(&endp->trans_bts, endp->cfg, + proto == PROTO_RTP, buf, rc); + } + + LOGP(DMGCP, LOGL_ERROR, "Bad MGCP type %u on endpoint %u\n", + endp->type, ENDPOINT_NUMBER(endp)); + return 0; } static int rtp_data_transcoder(struct mgcp_rtp_end *end, struct mgcp_endpoint *_endp, diff --git a/openbsc/src/libmgcp/mgcp_protocol.c b/openbsc/src/libmgcp/mgcp_protocol.c index dc5e0f9..1e1841a 100644 --- a/openbsc/src/libmgcp/mgcp_protocol.c +++ b/openbsc/src/libmgcp/mgcp_protocol.c @@ -500,7 +500,7 @@ static int allocate_ports(struct mgcp_endpoint *endp) } /* remember that we have set up transcoding */ - endp->is_transcoded = 1; + endp->type = MGCP_RTP_TRANSCODED; } return 0; @@ -1014,7 +1014,7 @@ void mgcp_free_endp(struct mgcp_endpoint *endp) mgcp_rtp_end_reset(&endp->net_end); mgcp_rtp_end_reset(&endp->trans_net); mgcp_rtp_end_reset(&endp->trans_bts); - endp->is_transcoded = 0; + endp->type = MGCP_RTP_DEFAULT; memset(&endp->net_state, 0, sizeof(endp->net_state)); memset(&endp->bts_state, 0, sizeof(endp->bts_state)); @@ -1118,7 +1118,7 @@ static void create_transcoder(struct mgcp_endpoint *endp) int in_endp = ENDPOINT_NUMBER(endp); int out_endp = endp_back_channel(in_endp); - if (!endp->is_transcoded) + if (endp->type != MGCP_RTP_TRANSCODED) return; send_msg(endp, in_endp, endp->trans_bts.local_port, "CRCX", "sendrecv"); @@ -1140,7 +1140,7 @@ static void delete_transcoder(struct mgcp_endpoint *endp) int in_endp = ENDPOINT_NUMBER(endp); int out_endp = endp_back_channel(in_endp); - if (!endp->is_transcoded) + if (endp->type != MGCP_RTP_TRANSCODED) return; send_dlcx(endp, in_endp); -- 1.7.10.4 From holger at freyther.de Mon Jul 8 12:01:10 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 8 Jul 2013 14:01:10 +0200 Subject: [OpenBSC PATCHv2] libmgcp: add enum mgcp_type In-Reply-To: <1373252986-17304-1-git-send-email-pablo@gnumonks.org> References: <1373252986-17304-1-git-send-email-pablo@gnumonks.org> Message-ID: <20130708120110.GA15603@xiaoyu.lan> On Mon, Jul 08, 2013 at 05:09:46AM +0200, pablo at gnumonks.org wrote: > From: Pablo Neira Ayuso > > This patch replaces the field 'is_transcoded' in the mgcp_endpoint > structure by the enum mgcp_type, that can be further extended with > new types. thanks! I will queue/apply it. From laforge at gnumonks.org Mon Jul 8 08:22:49 2013 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 8 Jul 2013 10:22:49 +0200 Subject: [ADMIN] Wanted: List moderator Message-ID: <20130708082249.GY28142@nataraja.gnumonks.org> Dear Osmocom community, I'm currently looking for one or multiple volunteers who are willing to tend to the mailman 'moderator queue' of the various osmocom mailing lists (baseband-devel, openbsc, simtrace, tetra, osmocom-pcu, ...) Our lists are 'member posting only' to protect them from spam. This means that spammers will be caught in the list moderation queue together with the occasional legitimate message from a non-subscriber. You need to manually look over that queue in the mailman web interface, select those legitimate posts as 'approve' and 'defer' all others. The task requires very few minutes, but it requires them every day or second day. It is a perfect opportunity how non-developers can contribute to the project :) Please let me know if anyone is willing to take care of this. Thanks! 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 andrew at carrierdetect.com Mon Jul 8 09:14:23 2013 From: andrew at carrierdetect.com (Andrew Back) Date: Mon, 8 Jul 2013 10:14:23 +0100 Subject: [ADMIN] Wanted: List moderator In-Reply-To: <20130708082249.GY28142@nataraja.gnumonks.org> References: <20130708082249.GY28142@nataraja.gnumonks.org> Message-ID: Hi Harald, On 8 July 2013 09:22, Harald Welte wrote: > Dear Osmocom community, > > I'm currently looking for one or multiple volunteers who are willing to > tend to the mailman 'moderator queue' of the various osmocom mailing > lists (baseband-devel, openbsc, simtrace, tetra, osmocom-pcu, ...) > > Our lists are 'member posting only' to protect them from spam. This > means that spammers will be caught in the list moderation queue together > with the occasional legitimate message from a non-subscriber. > > You need to manually look over that queue in the mailman web interface, > select those legitimate posts as 'approve' and 'defer' all others. > > The task requires very few minutes, but it requires them every day or > second day. It is a perfect opportunity how non-developers can > contribute to the project :) > > Please let me know if anyone is willing to take care of this. Thanks! I'd be happy to do this. Best, Andrew -- Andrew Back http://carrierdetect.com From risky at mail.ru Mon Jul 8 10:01:28 2013 From: risky at mail.ru (Sergey V. Efimov) Date: Mon, 8 Jul 2013 14:01:28 +0400 Subject: [ADMIN] Wanted: List moderator In-Reply-To: References: <20130708082249.GY28142@nataraja.gnumonks.org> Message-ID: Hi All, So do I. With exception when I will need to take a couple of weeks for vacations. On Jul 8, 2013, at 1:14 PM, Andrew Back wrote: > Hi Harald, > > On 8 July 2013 09:22, Harald Welte wrote: >> Dear Osmocom community, >> >> I'm currently looking for one or multiple volunteers who are willing to >> tend to the mailman 'moderator queue' of the various osmocom mailing >> lists (baseband-devel, openbsc, simtrace, tetra, osmocom-pcu, ...) >> >> Our lists are 'member posting only' to protect them from spam. This >> means that spammers will be caught in the list moderation queue together >> with the occasional legitimate message from a non-subscriber. >> >> You need to manually look over that queue in the mailman web interface, >> select those legitimate posts as 'approve' and 'defer' all others. >> >> The task requires very few minutes, but it requires them every day or >> second day. It is a perfect opportunity how non-developers can >> contribute to the project :) >> >> Please let me know if anyone is willing to take care of this. Thanks! > > I'd be happy to do this. > > Best, > > Andrew > > -- > Andrew Back > http://carrierdetect.com > > From dchardware at gmail.com Mon Jul 8 09:09:59 2013 From: dchardware at gmail.com (Sipos Csaba) Date: Mon, 8 Jul 2013 11:09:59 +0200 Subject: Nokia MetroSite In-Reply-To: References: Message-ID: <991518176.20130708110959@freemail.hu> To the MetroSIte topic: I think we have a MetroSite unit with PSU, E1 card, TRE and 2 TRX. Nobody tried it out because we dont have a BSC, but I will try to hook it up to the E1 card and see if it works, I hope I can find a -48V DC supply :-) If it works I will happily set up access for developers if someone interested in it. In the mean time, I will going to do some multi unit tests with the two insite units and figure it out why sometimes both units came up, and the other time why only the first unit came up only. I think it is important to find why is this happening, because InSIte and MetroSite units can both be daisy chained, and due to the extensive network upgrades (in Europe) a lot of these units will be available on the markets (Vodafone and Telenor already dropped these units after the RAN upgrades in Hungary). But it is also true, that maybe a good development direction would be to support femto cells, that are easily and cheaply accessible to anyone, uses IP technology and In general it is easy to work with. BR, Csaba From dchardware at gmail.com Mon Jul 8 19:19:23 2013 From: dchardware at gmail.com (Sipos Csaba) Date: Mon, 8 Jul 2013 21:19:23 +0200 Subject: Nokia InSite handover In-Reply-To: References: Message-ID: <1034463714.20130708211923@freemail.hu> Today, after I successfully started two InSite BTS units on the same E1 line, I tried to test the OpenBSC handover function. I got a strange error message, that I have to enable RTP Proxy mode with "-P" in osmo-nitb. Because these units are running from E1, I just simply ask: do we have handover support for E1 based BTSs? Cell reselection and inter BTS voice calls, SMSs are working just fine. BR, Csaba From laforge at gnumonks.org Wed Jul 10 15:54:15 2013 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 10 Jul 2013 17:54:15 +0200 Subject: Nokia InSite handover In-Reply-To: <1034463714.20130708211923@freemail.hu> References: <1034463714.20130708211923@freemail.hu> Message-ID: <20130710155415.GB6004@nataraja.gnumonks.org> Hi, On Mon, Jul 08, 2013 at 09:19:23PM +0200, Sipos Csaba wrote: > I got a strange error message, that I have to enable RTP Proxy > mode with "-P" in osmo-nitb. That's of course funny. Please take some minutes of your time to look at the source code line that generates yoru error message. I'm sure (without looking) that the message will be printed if bts->model != SIEMENS_BS11. So you simply need to extend that to include all E1 based bts's. > Because these units are running from E1, I just simply ask: do we have > handover support for E1 based BTSs? yes, this was already working with the BS-11 a long time ago. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From dchardware at gmail.com Wed Jul 10 18:44:49 2013 From: dchardware at gmail.com (Sipos Csaba) Date: Wed, 10 Jul 2013 20:44:49 +0200 Subject: Nokia InSite handover In-Reply-To: <20130710155415.GB6004@nataraja.gnumonks.org> References: <1034463714.20130708211923@freemail.hu> <20130710155415.GB6004@nataraja.gnumonks.org> Message-ID: <645518606.20130710204449@freemail.hu> Hi Harald, > Hi, > On Mon, Jul 08, 2013 at 09:19:23PM +0200, Sipos Csaba wrote: >> I got a strange error message, that I have to enable RTP Proxy >> mode with "-P" in osmo-nitb. > That's of course funny. > Please take some minutes of your time to look at the source code line > that generates yoru error message. I'm sure (without looking) that > the message will be printed if bts->model != SIEMENS_BS11. So you > simply need to extend that to include all E1 based bts's. The part generates this message is the following: openbsc/openbsc/src/libbsc/bsc_vty.c #define HANDOVER_STR "Handover Options\n" DEFUN(cfg_net_handover, cfg_net_handover_cmd, "handover (0|1)", HANDOVER_STR "Don't perform in-call handover\n" "Perform in-call handover\n") { int enable = atoi(argv[0]); struct gsm_network *gsmnet = gsmnet_from_vty(vty); if (enable && ipacc_rtp_direct) { vty_out(vty, "%% Cannot enable handover unless RTP Proxy mode " "is enabled by using the -P command line option%s", VTY_NEWLINE); return CMD_WARNING; } gsmnet->handover.active = enable; return CMD_SUCCESS; } After I removed this check, I was able to start OpenBSC with handover=1, even the OpenBSC VTY said to "show network" that handover is On, but I was not able to do any handovers even when there was 30-40dB difference (RXlev) between the target and the source cell. The target was ate -50, the source was around -100, suddenly the phone jumped to the target cell, but after 3-4 seconds of terrible noise, both phones are dropped the call. I think it was a cell reselection not a failed handover, because there was no HO attempts in the statistics. >> Because these units are running from E1, I just simply ask: do we have >> handover support for E1 based BTSs? > yes, this was already working with the BS-11 a long time ago. If I can help resolve this issue, just let me know what to try. BR, Csaba From laforge at gnumonks.org Wed Jul 10 20:22:50 2013 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 10 Jul 2013 22:22:50 +0200 Subject: Nokia InSite handover In-Reply-To: <645518606.20130710204449@freemail.hu> References: <1034463714.20130708211923@freemail.hu> <20130710155415.GB6004@nataraja.gnumonks.org> <645518606.20130710204449@freemail.hu> Message-ID: <20130710202250.GF6004@nataraja.gnumonks.org> On Wed, Jul 10, 2013 at 08:44:49PM +0200, Sipos Csaba wrote: > if (enable && ipacc_rtp_direct) { this check should be conditional on using a nanobts/sysmobts, and not be present for E1 based bts's. > After I removed this check, I was able to start OpenBSC with > handover=1, even the OpenBSC VTY said to "show network" that handover > is On, but I was not able to do any handovers even when there was > 30-40dB difference (RXlev) between the target and the source cell. The > target was ate -50, the source was around -100, suddenly the phone > jumped to the target cell, but after 3-4 seconds of terrible noise, > both phones are dropped the call. I think it was a cell reselection > not a failed handover, because there was no HO attempts in the > statistics. You should enable debugging logging of the handover code and see what kind of messages you get. 'logging enable' 'lgging filter all 1' and 'logging level ho debug' should do the trick. Please have a look at handover_logic.c and handover_decision.c in the src/libbsc subdirectory of openbsc.git. If that doesn't help, you can also enable measurement debugging, and manually check if the measurement reports from the phone arrive at the bsc, if they contain measurements of the neighbor cell, and if the reported signal levels of the neighbor cell really are better than the original cell where you started the call, etc. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From dchardware at gmail.com Mon Jul 22 21:51:10 2013 From: dchardware at gmail.com (Sipos Csaba) Date: Mon, 22 Jul 2013 23:51:10 +0200 Subject: Nokia InSite handover In-Reply-To: <20130710202250.GF6004@nataraja.gnumonks.org> References: <1034463714.20130708211923@freemail.hu> <20130710155415.GB6004@nataraja.gnumonks.org> <645518606.20130710204449@freemail.hu> <20130710202250.GF6004@nataraja.gnumonks.org> Message-ID: <666305468.20130722235110@freemail.hu> Hi Harald, > this check should be conditional on using a nanobts/sysmobts, and not be > present for E1 based bts's. I just removed that check from the code and now it is possible to enable the HO functions without the RTP Proxy. > You should enable debugging logging of the handover code and see what > kind of messages you get. 'logging enable' 'lgging filter all 1' and > 'logging level ho debug' should do the trick. I did as you said, the result is interesting, I just paste the relevant log parts, the full dump (logging all debug) is attached. So I wanted to do inter-BTS handover (two Nokia InSite units, one GSM900 and one GSM1800), neighbors list configured. Two phones calling each other, each one is camped on different cell. The one that is camped on the GSM1800 unit tries to handover to the GSM900 unit. Here is what happens: <000c> handover_decision.c:203 (bts=0,trx=0,ts=2): Cell on ARFCN 123 is better: <000c> handover_logic.c:96 (old_lchan on BTS 0, new BTS 1) Starting handover <0004> abis_rsl.c:1165 (bts=1,trx=0,ts=2,ss=0) CHANNEL ACTIVATE ACK <000c> handover_logic.c:204 handover activate ack, send HO Command <0004> abis_rsl.c:1138 (bts=1,trx=0,ts=2,ss=0) HANDOVER DETECT access delay = 0 <0000> abis_rsl.c:1621 (bts=1,trx=0,ts=2,ss=0) SAPI=0 ESTABLISH INDICATION <0000> abis_rsl.c:1621 (bts=1,trx=0,ts=2,ss=0) SAPI=0 DATA INDICATION <0003> bsc_api.c:515 HANDOVER COMPLETE cause = Normal event <000c> handover_logic.c:261 Subscriber 244153333330126 HO from BTS 0->1 on ARFCN 885->123 <0000> chan_alloc.c:405 (bts=0,trx=0,ts=2,ss=0) starting release sequence <0000> abis_rsl.c:891 (bts=0,trx=0,ts=2,ss=0) RSL RLL RELEASE REQ (link_id=0x00, reason=1) <0004> abis_rsl.c:1069 (bts=0,trx=0,ts=2,ss=0): MEAS RES for inactive channel <0004> abis_rsl.c:1069 (bts=0,trx=0,ts=2,ss=0): MEAS RES for inactive channel <0004> abis_rsl.c:1069 (bts=0,trx=0,ts=2,ss=0): MEAS RES for inactive channel .. .. <0004> abis_rsl.c:1069 (bts=0,trx=0,ts=2,ss=0): MEAS RES for inactive channel <0004> abis_rsl.c:1069 (bts=0,trx=0,ts=2,ss=0): MEAS RES for inactive channel <0004> abis_rsl.c:1069 (bts=0,trx=0,ts=2,ss=0): MEAS RES for inactive channel <0004> abis_rsl.c:988 (bts=0,trx=0,ts=2,ss=0) CONNECTION FAIL: RELEASING CAUSE=0x01(Radio Link Failure) <0004> abis_rsl.c:679 (bts=0,trx=0,ts=2,ss=0) RF Channel Release CMD due error 1 <0004> abis_rsl.c:633 (bts=0,trx=0,ts=2,ss=0) DEACTivate SACCH CMD <0000> abis_rsl.c:891 (bts=0,trx=0,ts=2,ss=0) RSL RLL RELEASE REQ (link_id=0x40, reason=1) <0004> abis_rsl.c:1069 (bts=0,trx=0,ts=2,ss=0): MEAS RES for inactive channel <0004> abis_rsl.c:731 (bts=0,trx=0,ts=2,ss=0) RF CHANNEL RELEASE ACK <001a> trau_frame.c:196 unimplemented TRAU Frame Type 0x06 <-- a lot of "unimplemented TRAU Frame Type 0x06" --> <001a> trau_frame.c:275 unimplemented TRAU Frame Type 0x06 <0004> abis_rsl.c:988 (bts=0,trx=0,ts=3,ss=0) CONNECTION FAIL: RELEASING CAUSE=0x28(unknown 0x28) <0004> abis_rsl.c:679 (bts=0,trx=0,ts=3,ss=0) RF Channel Release CMD due error 1 <0004> abis_rsl.c:633 (bts=0,trx=0,ts=3,ss=0) DEACTivate SACCH CMD <0000> abis_rsl.c:891 (bts=0,trx=0,ts=3,ss=0) RSL RLL RELEASE REQ (link_id=0x40, reason=1) <0004> abis_rsl.c:731 (bts=0,trx=0,ts=3,ss=0) RF CHANNEL RELEASE ACK <0001> gsm_04_08.c:1265 (bts 0 trx 0 ts 3 ti 0 sub 12346) Sending 'MNCC_REL_IND' to MNCC. <0006> mncc_builtin.c:348 (call 1) Received message MNCC_REL_IND <0006> mncc_builtin.c:257 (call 1) Releasing remote with cause 47 <0006> mncc_builtin.c:52 (call 1) Call removed. <0006> gsm_04_08.c:2877 receive message MNCC_REL_REQ <0001> gsm_04_08.c:3063 (bts 0 trx 0 ts 2 ti 08 sub 12345) Received 'MNCC_REL_REQ' from MNCC in state 10 (ACTIVE) <0001> gsm_04_08.c:1739 starting timer T308 with 10 seconds <0001> gsm_04_08.c:1204 new state ACTIVE -> RELEASE_REQ <0001> gsm_04_08.c:113 (bts 1 trx 0 ts 2 ti 80) Sending 'RELEASE' to MS. <0001> gsm_04_08.c:1204 new state ACTIVE -> NULL <0000> abis_rsl.c:1621 (bts=1,trx=0,ts=2,ss=0) SAPI=0 DATA INDICATION <0001> gsm_04_08.c:3156 (bts 0 trx 0 ts 2 ti 8 sub 12345) Received 'RELEASE_COMPL' from MS in state 19 (RELEASE_REQ) <0001> gsm_04_08.c:1245 stopping pending timer T308 <0001> gsm_04_08.c:1265 (bts 1 trx 0 ts 2 ti 8 sub 12345) Sending 'MNCC_REL_CNF' to MNCC. <0006> mncc_builtin.c:348 (call 80000001) Received message MNCC_REL_CNF <0006> mncc_builtin.c:52 (call 80000001) Call removed. <0001> gsm_04_08.c:1204 new state RELEASE_REQ -> NULL <0000> chan_alloc.c:405 (bts=1,trx=0,ts=2,ss=0) starting release sequence <0003> gsm_04_08_utils.c:231 Sending Channel Release: Chan: Number: 0 Type: 2 <0004> abis_rsl.c:633 (bts=1,trx=0,ts=2,ss=0) DEACTivate SACCH CMD <0000> abis_rsl.c:1621 (bts=1,trx=0,ts=2,ss=0) SAPI=0 RELEASE INDICATION <0004> abis_rsl.c:679 (bts=1,trx=0,ts=2,ss=0) RF Channel Release CMD due error 0 <0004> abis_rsl.c:731 (bts=1,trx=0,ts=2,ss=0) RF CHANNEL RELEASE ACK <0004> abis_rsl.c:648 (bts=0,trx=0,ts=2,ss=0) is back in operation. <0004> abis_rsl.c:648 (bts=0,trx=0,ts=3,ss=0) is back in operation. In the moment when the phone handed over to the new serving BTS, the voice is completely noisy, and after a few seconds both phones got disconnected. This is the same with both directions, and "show statistics" shows that these handovers were all successful. My config: handover 1 handover window rxlev averaging 10 handover window rxqual averaging 1 handover window rxlev neighbor averaging 10 handover power budget interval 6 handover power budget hysteresis 3 # handover maximum distance 9999 timer t3101 10 timer t3103 6 timer t3105 2 timer t3107 0 timer t3109 4 timer t3111 9 timer t3113 60 timer t3115 0 timer t3117 0 timer t3119 0 timer t3141 0 timer t3122 5 bts 0 cell reselection hysteresis 4 periodic location update 6 neighbor-list mode manual neighbor-list add arfcn 123 rxlev access min 22 bts 1 cell reselection hysteresis 4 periodic location update 6 neighbor-list mode manual neighbor-list add arfcn 885 nokia_site skip-reset 1 rxlev access min 22 For OML and RSL I am using D channels, the traffic channels are B channels in the DAHDI config file. If someone has an idea what to do or try, it will be appreciated. Thanks, Csaba -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: nokia_failed_handover_log.txt URL: From priyankabehl at ymail.com Tue Jul 9 06:31:19 2013 From: priyankabehl at ymail.com (Priyanka Behl) Date: Tue, 9 Jul 2013 14:31:19 +0800 (SGT) Subject: Complete setup with just simulation Message-ID: <1373351479.46632.YahooMailNeo@web192606.mail.sg3.yahoo.com> Hi everyone, ? I have to setup a complete call with voice support and also a complete working GPRS network with just simulation and no physical base station, is it achievable? It would be great if someone could enlighten me on this. Thanks and regards, Priyanka -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Wed Jul 10 15:59:09 2013 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 10 Jul 2013 17:59:09 +0200 Subject: Complete setup with just simulation In-Reply-To: <1373351479.46632.YahooMailNeo@web192606.mail.sg3.yahoo.com> References: <1373351479.46632.YahooMailNeo@web192606.mail.sg3.yahoo.com> Message-ID: <20130710155909.GC6004@nataraja.gnumonks.org> Hi Priyanka, On Tue, Jul 09, 2013 at 02:31:19PM +0800, Priyanka Behl wrote: > I have to setup a complete call with voice support and also a complete > working GPRS network with just simulation and no physical base > station, is it achievable? It would be great if someone could > enlighten me on this. Of course it is achievable - it primarily depends on how much development effort you are capable / willing to do as part of the task, and particularly how close to the real world you need to be. For the GSM (voice/sms/ussd/...) side, connecting OsmocomBB with Osmo-BTS has been suggested several times. Instead of sending the messages over a real L1, you could send them over GSMTAP. Different ARFCN/timeslot/etc. can be encoded in the GSMTAP header, and you have nice debugging by the GSMTAP dissector in wireshark. I would guess that this can be done by a skilled developer in one week. For GPRS, a similar approach can be used. but: there is no MS-side implementation at all. You may be able to reuse higher layers like SNDCP and LLC from OsmoSGSN, as well as RLC/MAC message encoding and parsing from osmo-pcu. but you will definitely have to implement the full MS-side GPRS stack, mostly from scratch. We're talking about something in the oder of (few) months of development time. 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 alexander.chemeris at gmail.com Tue Jul 9 14:46:16 2013 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Tue, 9 Jul 2013 18:46:16 +0400 Subject: Fwd: DSP optimization In-Reply-To: References: Message-ID: Hi all, I'm moving this conversation from private to public. I think Sylvain and Andreas might be interested in participating. ---------- Forwarded message ---------- From: Thomas Tsou Date: Tue, Jul 9, 2013 at 2:51 AM Subject: Re: DSP optimization To: Alexander Chemeris On Mon, Jul 8, 2013 at 6:52 AM, Alexander Chemeris wrote: > Wow, optimization of 5-16x for Viterbi is huge indeed. I wonder what > would be results for our Atoms. Without SSE, just C only butterfly, the improvement is around 4x. SSE 3 (Atom) forces a small change on the normalization (not separated out yet), but the results weren't very far off from SSE 4.1 when I tested on Core 2 Duo. I might try to manipulate the interface to read in the state tables instead of the generator polynomials. That would really help with testing and integration, but I'm not sure yet. There are many ways to go here. > What is problematic with the runtime detection? CPU autodetection on > Linux should be as easy as reading /proc/cpuinfo. But I see an issue > is with correctly setting up build system to generate all version on > the same run. I think we could leave CPU autodetection for the > "everything else" milestone, using compile time selection for now. I think compile time detection is more appropriate. For GSM / LTE we're almost always dealing with fixed sized vectors and not odd calculations (e.g. 1023 size FFT), so it's unlikely that the results will change on repeated runs. /proc/cpuinfo parsing scripts I've seen have been prone to breakage. If you have a really good one, let me know. I usually prefer to run configure checks against the actual instruction, but that can get messy with a lot of checks. Anyhow, I'm not worrying about this now. > What repository will you push at? We need to have at least master > branch and dual-channel branch working with the optimizations. And I > believe everyone would be happy to see optimizations in the > libosmocore for the benefit of other projects as well. I don't foresee > any issues with a slight change in the API of libosmocore if it is > justified - just send an RFC/patch to the OpenBSC mailing list and it > will be reviewed. Non-Viterbi changes are sigProc.cpp changes only, so they are not branch-specific - they will probably merge into the oldest available OpenBTS releases. The Viterbi changes merge into Andreas's branch, which is a very large change. For now, somebody needs to write it, which is why I'm considering making the interfaces match. Attached are the standalone unit test cases for SSE 4.2. As previously mentioned, Atom needs SSE3 only. I'll add the ifdefs for those shortly. I don't know if there's an appropriate repository for these right now - linking libosmocore from the transceiver for comparison purposes only seems silly. I just generated a temporary tarball for the time being. Thomas -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru -------------- next part -------------- A non-text attachment was scrubbed... Name: sse-tests-0.1.tar.gz Type: application/x-gzip Size: 94422 bytes Desc: not available URL: From alexander.chemeris at gmail.com Tue Jul 9 14:54:51 2013 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Tue, 9 Jul 2013 18:54:51 +0400 Subject: DSP optimization In-Reply-To: References: Message-ID: Hi Thomas, > From: Thomas Tsou > On Mon, Jul 8, 2013 at 6:52 AM, Alexander Chemeris > wrote: > > I think compile time detection is more appropriate. Yes, that's fine for now. > /proc/cpuinfo parsing scripts I've seen have been prone to breakage. > If you have a really good one, let me know. I usually prefer to run > configure checks against the actual instruction, but that can get > messy with a lot of checks. Anyhow, I'm not worrying about this now. Sorry, I'm not aware of any. >> What repository will you push at? We need to have at least master >> branch and dual-channel branch working with the optimizations. And I >> believe everyone would be happy to see optimizations in the >> libosmocore for the benefit of other projects as well. I don't foresee >> any issues with a slight change in the API of libosmocore if it is >> justified - just send an RFC/patch to the OpenBSC mailing list and it >> will be reviewed. > > Non-Viterbi changes are sigProc.cpp changes only, so they are not > branch-specific - they will probably merge into the oldest available > OpenBTS releases. The Viterbi changes merge into Andreas's branch, > which is a very large change. For now, somebody needs to write it, > which is why I'm considering making the interfaces match. Could you publish them for review? It's hard to talk about a code without looking at it. > Attached are the standalone unit test cases for SSE 4.2. As previously > mentioned, Atom needs SSE3 only. I'll add the ifdefs for those > shortly. I don't know if there's an appropriate repository for these > right now - linking libosmocore from the transceiver for comparison > purposes only seems silly. I just generated a temporary tarball for > the time being. Ok, waiting for the updated version to test it on my Core 2 Duo and Atoms. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From tom at tsou.cc Wed Jul 10 15:05:13 2013 From: tom at tsou.cc (Thomas Tsou) Date: Wed, 10 Jul 2013 17:05:13 +0200 Subject: DSP optimization In-Reply-To: References: Message-ID: On Tue, Jul 9, 2013 at 4:54 PM, Alexander Chemeris wrote: >> From: Thomas Tsou >> Attached are the standalone unit test cases for SSE 4.2. As previously >> mentioned, Atom needs SSE3 only. I'll add the ifdefs for those >> shortly. I don't know if there's an appropriate repository for these >> right now - linking libosmocore from the transceiver for comparison >> purposes only seems silly. I just generated a temporary tarball for >> the time being. > > Ok, waiting for the updated version to test it on my Core 2 Duo and Atoms. Pushed for the time being to: https://github.com/ttsou/sse-tests.git To enable SSE4: ./configure --with-sse4 Vector 16-bit integer to floating point conversion is only enabled with SSE4. In general, the SSE type conversion benefits are marginal because the native conversion instructions operate on 32-bit widths, which requires a separate sign extension. If there is no dedicated instruction for sign extension (SSE3) then the benefits (if any) are reduced even more. Thomas From 246tnt at gmail.com Wed Jul 10 12:26:18 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 10 Jul 2013 14:26:18 +0200 Subject: DSP optimization In-Reply-To: References: Message-ID: Hi, >> I don't foresee >> any issues with a slight change in the API of libosmocore if it is >> justified - just send an RFC/patch to the OpenBSC mailing list and it >> will be reviewed. I _do_ see an issue with ABI and/or API change. The conv code is used in many projects with a bunch of different code so any change would need to have a very good justification of why it's needed and should be absolutely necessary. Also, it should be obvious but any change in libosmocore must stay compatible with all codes that have been supported until now and not just a subset of GSM/LTE specific codes. All the GSM channel coding will also be moving to libosmocore soonish to allow usage in other projects so keeping some specific stuff in osmo-bts will not be a viable option for long. Cheers, Sylvain From tom at tsou.cc Wed Jul 10 13:08:58 2013 From: tom at tsou.cc (Thomas Tsou) Date: Wed, 10 Jul 2013 15:08:58 +0200 Subject: DSP optimization In-Reply-To: References: Message-ID: On Wed, Jul 10, 2013 at 2:26 PM, Sylvain Munaut <246tnt at gmail.com> wrote: >>> I don't foresee >>> any issues with a slight change in the API of libosmocore if it is >>> justified - just send an RFC/patch to the OpenBSC mailing list and it >>> will be reviewed. > > I _do_ see an issue with ABI and/or API change. > > The conv code is used in many projects with a bunch of different code > so any change would need to have a very good justification of why it's > needed and should be absolutely necessary. This was the issue I was trying to raise. The patch (that doesn't exist) for the API change on osmo-bts alone is huge. I don't like any API breaking changes, and I have limited interest in making changes to osmo-bts. I do like compatibility layers though. > Also, it should be obvious but any change in libosmocore must stay > compatible with all codes that have been supported until now and not > just a subset of GSM/LTE specific codes. Aside from testing all the various combinations, I'm less concerned about structural (non-API) compatibility. The convolutional codes are defined by the trellis structure or, equivalently, shift register and generator polynomials. The Viterbi algorithm is fundamentally the same in all cases. Unless there are some truly bizarre cases, which you would know more about than I do, I see this as less of an issue. > All the GSM channel coding will also be moving to libosmocore soonish > to allow usage in other projects so keeping some specific stuff in > osmo-bts will not be a viable option for long. Leaving aside LTE code, the implementation in question only exists in the posted test cases. Thomas From 246tnt at gmail.com Wed Jul 10 13:46:36 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 10 Jul 2013 15:46:36 +0200 Subject: DSP optimization In-Reply-To: References: Message-ID: Hi, > This was the issue I was trying to raise. The patch (that doesn't > exist) for the API change on osmo-bts alone is huge. I don't like any > API breaking changes, and I have limited interest in making changes to > osmo-bts. I do like compatibility layers though. Yes, both adapting the code and/or adding compatibility layer are no issue. Ideally the code should just end up in libosmocore, (being compiled if supported), and just "work" with any code that previously worked, possibly fallbacking to the reference impl at runtime if something weird is not supported. And all in all be completely transparent to the user, just accelerating it if possible. >> Also, it should be obvious but any change in libosmocore must stay >> compatible with all codes that have been supported until now and not >> just a subset of GSM/LTE specific codes. > > Aside from testing all the various combinations, I'm less concerned > about structural (non-API) compatibility. The convolutional codes are > defined by the trellis structure or, equivalently, shift register and > generator polynomials. The Viterbi algorithm is fundamentally the same > in all cases. Unless there are some truly bizarre cases, which you > would know more about than I do, I see this as less of an issue. The treillis scan is very similar in all cases. The only thing to support is the puncturing during the scan (I wanted to avoid having the de-puncture first). It also currently supports progressive decoding (i.e. you can start decoding a message before you have all of it if you want, you just feed it chunk by chunk and it can resume where it left off). Most of the changes between variations come from the way the termination is handled but since that's always only a few symbols, that could be left alone unoptimized (assuming the internal state is compatible enough). Cheers, Sylvain From tom at tsou.cc Thu Jul 11 09:56:48 2013 From: tom at tsou.cc (Thomas Tsou) Date: Thu, 11 Jul 2013 11:56:48 +0200 Subject: DSP optimization In-Reply-To: References: Message-ID: On Wed, Jul 10, 2013 at 3:46 PM, Sylvain Munaut <246tnt at gmail.com> wrote: > Ideally the code should just end up in libosmocore, (being compiled if > supported), and > just "work" with any code that previously worked, possibly fallbacking > to the reference > impl at runtime if something weird is not supported. The optimized portions, PMU and BMU, can stand independently, and my preferred approach would be to integrate those pieces with the existing trellis parts intact. That assumes that the accumulated path metrics, branch metrics, and path decisions are each represented by contiguously allocated 16-bit values. The downside of such an approach is that it would probably take far more time to integrate than the time to actually create the optimizations. > The treillis scan is very similar in all cases. The only thing to > support is the puncturing during the scan (I wanted to avoid having > the de-puncture first). What is the benefit of this? I explicitly separated puncturing because puncturing is inherently not part of the Viterbi algorithm. Admittedly, though, I'm probably biased because for LTE I can remove the puncturing unit entirely and directly replace it with a rate-matching unit. The SSE optimization operates vertically through the trellis, so in-scan puncturing can be accommodated. > It also currently supports progressive decoding (i.e. you can start > decoding a message before you have all of it if you want, you just > feed it chunk by chunk and it can resume where it left off). If not enough bits exist to decode a message, why attempt to partially decode it instead of waiting for the other bits? I could add support for this; it's just not a use case that I ever encountered. > Most of the changes between variations come from the way the > termination is handled but since that's always only a few symbols, > that could be left alone unoptimized (assuming the internal state is > compatible enough). Right. I don't think termination cases (or tail cases in general) are worth handling with any optimized code. Thomas From 246tnt at gmail.com Sat Jul 13 18:46:21 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sat, 13 Jul 2013 20:46:21 +0200 Subject: DSP optimization In-Reply-To: References: Message-ID: Hi, > The optimized portions, PMU and BMU, can stand independently, and my > preferred approach would be to integrate those pieces with the > existing trellis parts intact. That assumes that the accumulated path > metrics, branch metrics, and path decisions are each represented by > contiguously allocated 16-bit values. Well, the internal state is "private" to the implementation so if there is need for change to better match the SSE and make it easier to match SSE/non-SSE code, that shouldn't be an issue. > The downside of such an approach > is that it would probably take far more time to integrate than the > time to actually create the optimizations. Well, that's often the case. Getting some proof of concept is "easy". The cleanup and proper integration is definitely a significant part of the work. >> The treillis scan is very similar in all cases. The only thing to >> support is the puncturing during the scan (I wanted to avoid having >> the de-puncture first). > > What is the benefit of this? I explicitly separated puncturing because > puncturing is inherently not part of the Viterbi algorithm. It was done inside the "common code" because all the protocols that were targeted but the initial code used it and it allowed better code re-use. Now some actually do it externally themselves (TETRA) and just set the 'puncture' to NULL. Now, it was done in-line vs two-steps to avoid an allocation and data movement. IIRC I tested both cases and the perf difference weren't significant. But I'm not strictly attached to it. If we have to change it into two steps were it's depunctured in a first loop then processed, it would be acceptable. >> It also currently supports progressive decoding (i.e. you can start >> decoding a message before you have all of it if you want, you just >> feed it chunk by chunk and it can resume where it left off). > > If not enough bits exist to decode a message, why attempt to partially > decode it instead of waiting for the other bits? I could add support > for this; it's just not a use case that I ever encountered. It was an effort to support "continuous" streams rather than single messages. Part of this capability also useful to support tail-biting codes where you need to basically feeding the data twice without resetting everything. But all that needed is to store offsets and support not resetting path costs, so nothing touching the 'core' of the loop so it shouldn't be an issue. Cheers, Sylvain From dchardware at gmail.com Tue Jul 9 17:12:20 2013 From: dchardware at gmail.com (Sipos Csaba) Date: Tue, 9 Jul 2013 19:12:20 +0200 Subject: Nokia Insite handover In-Reply-To: References: Message-ID: <485299328.20130709191220@freemail.hu> Hi Peter, > It means that some real programming is needed. It's not a small > change. It might work as-is with one phone camping to only one of the > two BTSes at a time, but you will likely have corruptions if you have > a bunch of phones on both BTSes at once. I was able to start two InSite units at the same time, probably because these units has only one TRX per BTS. I was even able to establish an inter-BTS voice call. Cell reselection and SMS was working fine also. But when I tried to enable handover, I got this strange message that I have to enable RTP proxy. If I do so, my voice calls are failing completely (not a surprise, these units are connecting through E1). I could really use a straight answer from any developer, that OpenBSC has handover support for non-IP (E1 based) units or not, because I am not trying to get this done if it is completely missing. > When using nitb with a multi-TRX MetroSite there is a similar pattern > to what you describe - after the BTS is reset using the Nokia BTS > Manager, nitb only ever manages to correctly initialize the first > TRX. An error occurs and nitb exits. Restarting nitb sometimes allows > it to initialize the second TRX, sometimes no. My guess is that > failure or success depends on what phones are sending to the BTS > meanwhile, but it could also be only a matter of timing. Today I was able to setup our MetroSite (2 GSM1800 TRXs) unit and encountered the very same problem: only the first TRX was initialized, though both TRXs are set up in the openbsc config file. For the start and stop process you absolutely right. Out of ten tries, usually 2-3 are successful if I try to start both InSite units, but the chances are better if I previously start openbsc with a single BTS config file, then hit Ctrl+C and start the mutli BTS config file. It is also interesting, that both TRXSIG lapd connections are ON according to the BTS manager with MetroSite, but the second TRX is just not working. > The nokia_site code can definitily be improved when it comes to > startup/shutdown, but I don't know how well known the Nokia OML is. > It would also be nice to listen to the BTS Manager serial port > communication. If I understand correctly, many (all?) things that > BTS Manager can do over serial are also possible over E1. I can do these traces if you let me know what commands are you interested in. For example I can tell you for sure, that the site reset request command sent by OpenBSC (bts_nokia_site.c to be specific) is doing exactly the same, when I hit "Enable Abis" in Nokia BTS Manager. BTW do you have Nokia units too? I am still open to give access to our MetroSite (or the InSite) units if a developer is interested in it. I also have a fine selection of Nokia BTS managers that includes almost all Nokia BTS types (InSite, MetroSite, UltraSite, Flexi HUB, MetroHUB, Flexi EDGE, Metro Hopper etc.) I am happy to share this with any developer, just PM me with an FTP server account and remember: the whole package is 2.2GB. Br, Csaba From rodent at rodent.za.net Tue Jul 9 20:47:04 2013 From: rodent at rodent.za.net (Roelf Diedericks) Date: Tue, 9 Jul 2013 22:47:04 +0200 Subject: sysmoBTS + NITB Message-ID: I have FINALLY gotten to play with my sysmoBTS acquired many months ago, and updated to the latest packages using okpg, and am running a NITB. GSM850 test setup in open mode A5/0, and I can SMS and call between devices. However, there is no audio, and BTS console logs reports many repeats of the following during an established call. <0006> tch.c:601 (bts=0,trx=0,ts=7,ss=0) Rx Payload Type EFR is unsupported <0006> tch.c:601 (bts=0,trx=0,ts=7,ss=0) Rx Payload Type EFR is unsupported <0006> tch.c:601 (bts=0,trx=0,ts=7,ss=0) Rx Payload Type EFR is unsupported From holger at freyther.de Wed Jul 10 14:28:24 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Wed, 10 Jul 2013 16:28:24 +0200 Subject: sysmoBTS + NITB In-Reply-To: References: Message-ID: <20130710142824.GF7719@xiaoyu.lan> On Tue, Jul 09, 2013 at 10:47:04PM +0200, Roelf Diedericks wrote: Hi, > I have FINALLY gotten to play with my sysmoBTS acquired many months ago, > and updated to the latest packages using okpg, and am running a NITB. great! > From the code @ > https://github.com/osmocom/osmo-bts/blob/master/src/osmo-bts-sysmo/tch.c > line:583 > I deduct that > > " #if defined(L1_HAS_EFR) && defined(USE_L1_RTP_MODE) " yes, the cruelpit is here: http://git.osmocom.org/osmo-bts/tree/src/osmo-bts-sysmo/femtobts.h#n35 The question is what "some bugs" mean. I can't tell you and it has not been a priority to figure that out. The original author doesn't remember either. :} > I'd have expected that EFR is fully supported? the DSP fully supports it and in general it should work. We use AMR most of the time so debugging this has not been a priority. In the osmo-nitb.cfg you can add the following for now (or do that through the vty configuration): mncc-int default-codec tch-f fr holger From rodent at rodent.za.net Wed Jul 10 14:43:59 2013 From: rodent at rodent.za.net (Roelf Diedericks) Date: Wed, 10 Jul 2013 16:43:59 +0200 Subject: sysmoBTS + NITB In-Reply-To: <20130710142824.GF7719@xiaoyu.lan> References: <20130710142824.GF7719@xiaoyu.lan> Message-ID: Many thanks Holger! That did the trick. Regards, Roelf. On Wed, Jul 10, 2013 at 4:28 PM, Holger Hans Peter Freyther < holger at freyther.de> wrote: > On Tue, Jul 09, 2013 at 10:47:04PM +0200, Roelf Diedericks wrote: > > Hi, > > > I have FINALLY gotten to play with my sysmoBTS acquired many months ago, > > and updated to the latest packages using okpg, and am running a NITB. > > great! > > > > From the code @ > > https://github.com/osmocom/osmo-bts/blob/master/src/osmo-bts-sysmo/tch.c > > line:583 > > I deduct that > > > > " #if defined(L1_HAS_EFR) && defined(USE_L1_RTP_MODE) " > > yes, the cruelpit is here: > > http://git.osmocom.org/osmo-bts/tree/src/osmo-bts-sysmo/femtobts.h#n35 > > The question is what "some bugs" mean. I can't tell you and it has > not been a priority to figure that out. The original author doesn't > remember either. :} > > > > > I'd have expected that EFR is fully supported? > > the DSP fully supports it and in general it should work. We use AMR > most of the time so debugging this has not been a priority. > > In the osmo-nitb.cfg you can add the following for now (or do that > through the vty configuration): > > mncc-int > default-codec tch-f fr > > > holger > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas at eversberg.eu Wed Jul 10 07:18:19 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Wed, 10 Jul 2013 09:18:19 +0200 Subject: Second call on encrypted connection Message-ID: <51DD0ABB.1030704@eversberg.eu> hi, while trying to do a second call (hold the first, dial another number), i found out that there is no acknowledge for a CM service request, when encyption is enabled. the attached patch will fix it. regards, andreas -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Fix-Handle-CM-service-request-on-already-secured-cha.patch URL: From jolly at eversberg.eu Wed Jul 10 06:58:03 2013 From: jolly at eversberg.eu (Andreas Eversberg) Date: Wed, 10 Jul 2013 08:58:03 +0200 Subject: [PATCH] Fix: Handle CM service request on already secured channel correctly Message-ID: A CM service request must be acknowledged also, when encryption is already enabled. Without encryption enabled, the security status is GSM_SECURITY_NOTAVAIL, which causes a CM service acknowledge. On initial CM service request, the security status is GSM_SECURITY_SUCCEED, if encryption is enabled. This will not lead to an acknowledge, because the cyphering command implies an acknowlege. An additional CM service request requires an acknowledge, so I added a new security status: GSM_SECURITY_ALREADY --- openbsc/include/openbsc/gsm_data.h | 1 + openbsc/src/libmsc/gsm_04_08.c | 3 ++- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/openbsc/include/openbsc/gsm_data.h b/openbsc/include/openbsc/gsm_data.h index d7db887..05e0490 100644 --- a/openbsc/include/openbsc/gsm_data.h +++ b/openbsc/include/openbsc/gsm_data.h @@ -21,6 +21,7 @@ enum gsm_security_event { GSM_SECURITY_NOAVAIL, GSM_SECURITY_AUTH_FAILED, GSM_SECURITY_SUCCEEDED, + GSM_SECURITY_ALREADY, }; struct msgb; diff --git a/openbsc/src/libmsc/gsm_04_08.c b/openbsc/src/libmsc/gsm_04_08.c index 58107e3..2ce0e8c 100644 --- a/openbsc/src/libmsc/gsm_04_08.c +++ b/openbsc/src/libmsc/gsm_04_08.c @@ -194,7 +194,7 @@ int gsm48_secure_channel(struct gsm_subscriber_connection *conn, int key_seq, status = GSM_SECURITY_NOAVAIL; } else if (conn->lchan->encr.alg_id > RSL_ENC_ALG_A5(0)) { DEBUGP(DMM, "Requesting to secure an already secure channel"); - status = GSM_SECURITY_SUCCEEDED; + status = GSM_SECURITY_ALREADY; } else if (!ms_cm2_a5n_support(subscr->equipment.classmark2, net->a5_encryption)) { DEBUGP(DMM, "Subscriber equipment doesn't support requested encryption"); @@ -856,6 +856,7 @@ static int _gsm48_rx_mm_serv_req_sec_cb( break; case GSM_SECURITY_NOAVAIL: + case GSM_SECURITY_ALREADY: rc = gsm48_tx_mm_serv_ack(conn); break; -- 1.8.1.5 --------------030304030609050702010202-- From holger at freyther.de Wed Jul 10 11:49:07 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Wed, 10 Jul 2013 13:49:07 +0200 Subject: Second call on encrypted connection In-Reply-To: <51DD0ABB.1030704@eversberg.eu> References: <51DD0ABB.1030704@eversberg.eu> Message-ID: <20130710114907.GA7719@xiaoyu.lan> On Wed, Jul 10, 2013 at 09:18:19AM +0200, Andreas Eversberg wrote: > hi, > > while trying to do a second call (hold the first, dial another number), > i found out that there is no acknowledge for a CM service request, when > encyption is enabled. the attached patch will fix it. looks reasonable, do you think it makes sense to add a case for GSM_SECURITY_ALREADY in _gsm0408_authorize_sec_cb? It certainly wouldn't hurt? From andreas at eversberg.eu Wed Jul 10 17:02:59 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Wed, 10 Jul 2013 19:02:59 +0200 Subject: Second call on encrypted connection In-Reply-To: <20130710114907.GA7719@xiaoyu.lan> References: <51DD0ABB.1030704@eversberg.eu> <20130710114907.GA7719@xiaoyu.lan> Message-ID: <51DD93C3.5020503@eversberg.eu> Holger Hans Peter Freyther wrote: > do you think it makes sense to add a case for GSM_SECURITY_ALREADY > GSM_SECURITY_ALREADY in > _gsm0408_authorize_sec_cb? It certainly wouldn't hurt? > > i think not, because GSM_SECURITY_ALREADY cannot happen at location updating, where the security is performed the first time, because location updating is always the first request from a mobile. (if location area changed.) but if i am wrong, it would be mandatory. From holger at freyther.de Wed Jul 10 18:26:59 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Wed, 10 Jul 2013 20:26:59 +0200 Subject: Second call on encrypted connection In-Reply-To: <51DD93C3.5020503@eversberg.eu> References: <51DD0ABB.1030704@eversberg.eu> <20130710114907.GA7719@xiaoyu.lan> <51DD93C3.5020503@eversberg.eu> Message-ID: <20130710182659.GM7719@xiaoyu.lan> On Wed, Jul 10, 2013 at 07:02:59PM +0200, Andreas Eversberg wrote: > i think not, because GSM_SECURITY_ALREADY cannot happen at location > updating, where the security is performed the first time, because > location updating is always the first request from a mobile. (if > location area changed.) but if i am wrong, it would be mandatory. Well, it should not happen (as the periodic LU timer should be stopped), but imagine the 'unsigned int' would be an 'enum', we would now have a warning about unhandled cases (e.g. not building a partition over the enum) and it is good practice to avoid it. a.) If it can happen support it b.) If it can not happen, use LOGL_ERROR so we potentially notice if it does happen and then we can re-consider. cheers holger From andreas at eversberg.eu Wed Jul 10 19:27:16 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Wed, 10 Jul 2013 21:27:16 +0200 Subject: Second call on encrypted connection In-Reply-To: <20130710182659.GM7719@xiaoyu.lan> References: <51DD0ABB.1030704@eversberg.eu> <20130710114907.GA7719@xiaoyu.lan> <51DD93C3.5020503@eversberg.eu> <20130710182659.GM7719@xiaoyu.lan> Message-ID: <51DDB594.5080906@eversberg.eu> Holger Hans Peter Freyther wrote: > it should not happen (as the periodic LU timer should be stopped), > but imagine the 'unsigned int' would be an 'enum', we would now have > a warning about unhandled cases (e.g. not building a partition over > the enum) and it is good practice to avoid it. there is a "default:", which will not cause any warning, since it handles all unhandled cases above. > a.) If it can happen support it > b.) If it can not happen, use LOGL_ERROR so we potentially notice > if it does happen and then we can re-consider. LOGL_ERROR makes sense. maybe it tuns out that there is a call setup that caused a cell re-selection and a location updating is sent right afterwards. From andreas at eversberg.eu Thu Jul 11 07:00:53 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Thu, 11 Jul 2013 09:00:53 +0200 Subject: Second call on encrypted connection In-Reply-To: <20130710182659.GM7719@xiaoyu.lan> References: <51DD0ABB.1030704@eversberg.eu> <20130710114907.GA7719@xiaoyu.lan> <51DD93C3.5020503@eversberg.eu> <20130710182659.GM7719@xiaoyu.lan> Message-ID: <51DE5825.60805@eversberg.eu> Holger Hans Peter Freyther wrote: > b.) If it can not happen, use LOGL_ERROR so we potentially notice > if it does happen and then we can re-consider. > hi holger, the new patch will give an error message, if location updating is received after CM service request, but it finishes location updating in case of this unexpected behavior. regards, andreas -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Fix-Handle-CM-service-request-on-already-secured-cha.patch URL: From jolly at eversberg.eu Wed Jul 10 06:58:03 2013 From: jolly at eversberg.eu (Andreas Eversberg) Date: Wed, 10 Jul 2013 08:58:03 +0200 Subject: [PATCH] Fix: Handle CM service request on already secured channel correctly Message-ID: A CM service request must be acknowledged also, when encryption is already enabled. Without encryption enabled, the security status is GSM_SECURITY_NOTAVAIL, which causes a CM service acknowledge. On initial CM service request, the security status is GSM_SECURITY_SUCCEED, if encryption is enabled. This will not lead to an acknowledge, because the cyphering command implies an acknowlege. An additional CM service request requires an acknowledge, so I added a new security status: GSM_SECURITY_ALREADY --- openbsc/include/openbsc/gsm_data.h | 1 + openbsc/src/libmsc/gsm_04_08.c | 8 +++++++- 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/openbsc/include/openbsc/gsm_data.h b/openbsc/include/openbsc/gsm_data.h index d7db887..05e0490 100644 --- a/openbsc/include/openbsc/gsm_data.h +++ b/openbsc/include/openbsc/gsm_data.h @@ -21,6 +21,7 @@ enum gsm_security_event { GSM_SECURITY_NOAVAIL, GSM_SECURITY_AUTH_FAILED, GSM_SECURITY_SUCCEEDED, + GSM_SECURITY_ALREADY, }; struct msgb; diff --git a/openbsc/src/libmsc/gsm_04_08.c b/openbsc/src/libmsc/gsm_04_08.c index 58107e3..3725eb9 100644 --- a/openbsc/src/libmsc/gsm_04_08.c +++ b/openbsc/src/libmsc/gsm_04_08.c @@ -194,7 +194,7 @@ int gsm48_secure_channel(struct gsm_subscriber_connection *conn, int key_seq, status = GSM_SECURITY_NOAVAIL; } else if (conn->lchan->encr.alg_id > RSL_ENC_ALG_A5(0)) { DEBUGP(DMM, "Requesting to secure an already secure channel"); - status = GSM_SECURITY_SUCCEEDED; + status = GSM_SECURITY_ALREADY; } else if (!ms_cm2_a5n_support(subscr->equipment.classmark2, net->a5_encryption)) { DEBUGP(DMM, "Subscriber equipment doesn't support requested encryption"); @@ -302,6 +302,11 @@ static int _gsm0408_authorize_sec_cb(unsigned int hooknum, unsigned int event, release_loc_updating_req(conn); break; + case GSM_SECURITY_ALREADY: + LOGP(DMM, LOGL_ERROR, "We don't expect LOCATION " + "UPDATING after CM SERVICE REQUEST\n"); + /* fall through */ + case GSM_SECURITY_NOAVAIL: case GSM_SECURITY_SUCCEEDED: /* We're all good */ @@ -856,6 +861,7 @@ static int _gsm48_rx_mm_serv_req_sec_cb( break; case GSM_SECURITY_NOAVAIL: + case GSM_SECURITY_ALREADY: rc = gsm48_tx_mm_serv_ack(conn); break; -- 1.8.1.5 --------------040306030909000104060200-- From nicolas.bouliane at nutaq.com Wed Jul 10 12:25:50 2013 From: nicolas.bouliane at nutaq.com (Nicolas J. Bouliane) Date: Wed, 10 Jul 2013 08:25:50 -0400 Subject: [PATCH] Set the clock calibration to the value read from the eeprom by default. Message-ID: <1373459150-18528-1-git-send-email-nicolas.bouliane@nutaq.com> From: "Nicolas J. Bouliane" Signed-off-by: Nicolas J. Bouliane --- src/osmo-bts-sysmo/l1_if.c | 1 + src/osmo-bts-sysmo/l1_if.h | 1 + src/osmo-bts-sysmo/main.c | 24 ++++++++++++++++++++++++ src/osmo-bts-sysmo/sysmobts_vty.c | 21 ++++++++++++++++++++- 4 files changed, 46 insertions(+), 1 deletion(-) diff --git a/src/osmo-bts-sysmo/l1_if.c b/src/osmo-bts-sysmo/l1_if.c index 16f1523..e16bb49 100644 --- a/src/osmo-bts-sysmo/l1_if.c +++ b/src/osmo-bts-sysmo/l1_if.c @@ -1267,6 +1267,7 @@ struct femtol1_hdl *l1if_open(void *priv) fl1h->priv = priv; fl1h->clk_cal = 0; + fl1h->clk_use_eeprom = 1; fl1h->ul_power_target = -75; /* dBm default */ fl1h->min_qual_rach = MIN_QUAL_RACH; fl1h->min_qual_norm = MIN_QUAL_NORM; diff --git a/src/osmo-bts-sysmo/l1_if.h b/src/osmo-bts-sysmo/l1_if.h index 7947ea2..cf8af7b 100644 --- a/src/osmo-bts-sysmo/l1_if.h +++ b/src/osmo-bts-sysmo/l1_if.h @@ -42,6 +42,7 @@ struct femtol1_hdl { struct gsm_time gsm_time; uint32_t hLayer1; /* handle to the L1 instance in the DSP */ uint32_t dsp_trace_f; + uint8_t clk_use_eeprom; int clk_cal; int ul_power_target; uint8_t clk_src; diff --git a/src/osmo-bts-sysmo/main.c b/src/osmo-bts-sysmo/main.c index 595a6eb..d535ac8 100644 --- a/src/osmo-bts-sysmo/main.c +++ b/src/osmo-bts-sysmo/main.c @@ -48,6 +48,7 @@ #define SYSMOBTS_RF_LOCK_PATH "/var/lock/bts_rf_lock" +#include "eeprom.h" #include "l1_if.h" /* FIXME: read from real hardware */ @@ -80,6 +81,27 @@ int bts_model_init(struct gsm_bts *bts) return 0; } +/* Set the clock calibration to the value + * read from the eeprom. + */ +void clk_cal_use_eeprom(struct gsm_bts *bts) +{ + int rc; + struct femtol1_hdl *hdl; + eeprom_RfClockCal_t rf_clk; + + hdl = bts->c0->role_bts.l1h; + + if (!hdl || !hdl->clk_use_eeprom) + return; + + rc = eeprom_ReadRfClockCal(&rf_clk); + if (rc != EEPROM_SUCCESS) + return; + else + hdl->clk_cal = rf_clk.iClkCor; +} + struct ipabis_link *link_init(struct gsm_bts *bts, const char *ip) { struct ipabis_link *link = talloc_zero(bts, struct ipabis_link); @@ -286,6 +308,8 @@ int main(int argc, char **argv) exit(1); } + clk_cal_use_eeprom(bts); + if (stat(SYSMOBTS_RF_LOCK_PATH, &st) == 0) { LOGP(DL1C, LOGL_NOTICE, "Not starting BTS due to RF_LOCK file present\n"); exit(23); diff --git a/src/osmo-bts-sysmo/sysmobts_vty.c b/src/osmo-bts-sysmo/sysmobts_vty.c index 5bc948e..21b7f89 100644 --- a/src/osmo-bts-sysmo/sysmobts_vty.c +++ b/src/osmo-bts-sysmo/sysmobts_vty.c @@ -111,6 +111,18 @@ DEFUN(cfg_trx_no_gsmtap_sapi, cfg_trx_no_gsmtap_sapi_cmd, return CMD_SUCCESS; } +DEFUN(cfg_trx_clkcal_eeprom, cfg_trx_clkcal_eeprom_cmd, + "clock-calibration eeprom", + "Use the eeprom clock calibration value\n") +{ + struct gsm_bts_trx *trx = vty->index; + struct femtol1_hdl *fl1h = trx_femtol1_hdl(trx); + + fl1h->clk_use_eeprom = 1; + + return CMD_SUCCESS; +} + DEFUN(cfg_trx_clkcal_def, cfg_trx_clkcal_def_cmd, "clock-calibration default", "Set the clock calibration value\n" "Default Clock DAC value\n") @@ -118,6 +130,7 @@ DEFUN(cfg_trx_clkcal_def, cfg_trx_clkcal_def_cmd, struct gsm_bts_trx *trx = vty->index; struct femtol1_hdl *fl1h = trx_femtol1_hdl(trx); + fl1h->clk_use_eeprom = 0; fl1h->clk_cal = 0xffff; return CMD_SUCCESS; @@ -132,6 +145,7 @@ DEFUN(cfg_trx_clkcal, cfg_trx_clkcal_cmd, struct gsm_bts_trx *trx = vty->index; struct femtol1_hdl *fl1h = trx_femtol1_hdl(trx); + fl1h->clk_use_eeprom = 0; fl1h->clk_cal = clkcal & 0xfff; return CMD_SUCCESS; @@ -145,6 +159,7 @@ DEFUN(cfg_trx_clkcal, cfg_trx_clkcal_cmd, struct gsm_bts_trx *trx = vty->index; struct femtol1_hdl *fl1h = trx_femtol1_hdl(trx); + fl1h->clk_use_eeprom = 0; fl1h->clk_cal = clkcal; return CMD_SUCCESS; @@ -476,7 +491,10 @@ void bts_model_config_write_trx(struct vty *vty, struct gsm_bts_trx *trx) struct femtol1_hdl *fl1h = trx_femtol1_hdl(trx); int i; - vty_out(vty, " clock-calibration %d%s", fl1h->clk_cal, + if (fl1h->clk_use_eeprom) + vty_out(vty, " clock-calibration eeprom%s", VTY_NEWLINE); + else + vty_out(vty, " clock-calibration %d%s", fl1h->clk_cal, VTY_NEWLINE); if (fl1h->calib_path) vty_out(vty, " trx-calibration-path %s%s", @@ -549,6 +567,7 @@ int bts_model_vty_init(struct gsm_bts *bts) install_element(BTS_NODE, &cfg_bts_no_auto_band_cmd); install_element(TRX_NODE, &cfg_trx_clkcal_cmd); + install_element(TRX_NODE, &cfg_trx_clkcal_eeprom_cmd); install_element(TRX_NODE, &cfg_trx_clkcal_def_cmd); install_element(TRX_NODE, &cfg_trx_clksrc_cmd); install_element(TRX_NODE, &cfg_trx_cal_path_cmd); -- 1.7.10.4 From holger at freyther.de Thu Jul 11 08:42:56 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Thu, 11 Jul 2013 10:42:56 +0200 Subject: [PATCH] Set the clock calibration to the value read from the eeprom by default. In-Reply-To: <1373459150-18528-1-git-send-email-nicolas.bouliane@nutaq.com> References: <1373459150-18528-1-git-send-email-nicolas.bouliane@nutaq.com> Message-ID: <20130711084256.GC15643@xiaoyu.lan> On Wed, Jul 10, 2013 at 08:25:50AM -0400, Nicolas J. Bouliane wrote: Hi, thanks. looks nice. > + uint8_t clk_use_eeprom; we don't have a boolean type and currently we use int but that doesn't matter. I will enqueue your change. From dmi3sol at gmail.com Thu Jul 11 06:49:32 2013 From: dmi3sol at gmail.com (Dmitri Soloviev) Date: Thu, 11 Jul 2013 10:49:32 +0400 Subject: patch for gsm0808.c Message-ID: Hi in order to decode Cipher Mode Command from Alcatel S-12, please accept a patch to gsm0808.c Without it OpenBSC rejects ciphering, and procedures are broken from MSC side @@ -305,6 +305,7 @@ [GSM0808_IE_CELL_IDENTIFIER] = { TLV_TYPE_TLV }, [GSM0808_IE_CHOSEN_CHANNEL] = { TLV_TYPE_TV }, [GSM0808_IE_LAYER_3_INFORMATION] = { TLV_TYPE_TLV }, + [GSM0808_IE_LAYER_3_HEADER_INFORMATION] = { TLV_TYPE_TLV }, [GSM0808_IE_SPEECH_VERSION] = { TLV_TYPE_TV }, [GSM0808_IE_CHOSEN_ENCR_ALG] = { TLV_TYPE_TV }, }, Right now there is a pilot with MNO, and Telscale SS7 Card runs code for A-interface gateway, converting BSSAP/SS7 to SCCPoverIP + rtp. It seems that such a gateway also has to adapt OpenBSC to each particular MSC. As an example, DTAP portion of Cipher Mode Complete must be removed for proper operation with S12. Code will published as soon as pilot succeeds. Best Regards, Dmitri -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gsm0808.patch Type: application/octet-stream Size: 478 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ciph_cmd_Alcatel_S12.pcap Type: application/octet-stream Size: 2184 bytes Desc: not available URL: From alexander.chemeris at gmail.com Thu Jul 11 07:19:31 2013 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Thu, 11 Jul 2013 11:19:31 +0400 Subject: patch for gsm0808.c In-Reply-To: References: Message-ID: On Thu, Jul 11, 2013 at 10:49 AM, Dmitri Soloviev wrote: > It seems that such a gateway also has to adapt OpenBSC to each particular > MSC. > As an example, DTAP portion of Cipher Mode Complete must be removed for > proper operation with S12. Could we specify MSC model in the config the same way we specify BTS model? Then we could have tweaks for each particular MSC with a simple "if()". -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From hwelte at sysmocom.de Thu Jul 11 07:23:17 2013 From: hwelte at sysmocom.de (Harald Welte) Date: Thu, 11 Jul 2013 09:23:17 +0200 Subject: patch for gsm0808.c In-Reply-To: References: Message-ID: <20130711072317.GN6004@nataraja.gnumonks.org> Dear Dmitri, thanks for your patch, it will of course be merged. On Thu, Jul 11, 2013 at 10:49:32AM +0400, Dmitri Soloviev wrote: > Right now there is a pilot with MNO, and Telscale SS7 Card runs code > for A-interface gateway, converting BSSAP/SS7 to SCCPoverIP + rtp. this is great news. Please let us know if you need any assistance. Did I ever send you the protocol traces that you asked for? > It seems that such a gateway also has to adapt OpenBSC to each > particular MSC. I'm not sure if this really belongs into the gateway, or if we shouldn't rather have this code in OsmoBSC itself. So far, OsmoBSC has been used (to my knowledge) with Altobridge, Zynetix (Globe Wireless) and Quortus. We can introduce a 'msc model' in osmo-bsc, similar to having a 'bts model', and then code e.g. generating 08.08 messages can selectively check on the msc->model to have vendor-specific kludges. > Code will published as soon as pilot succeeds. Great! -- - Harald Welte http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Schivelbeiner Str. 5 * 10439 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte From dmi3sol at gmail.com Thu Jul 11 07:38:55 2013 From: dmi3sol at gmail.com (Dmitri Soloviev) Date: Thu, 11 Jul 2013 11:38:55 +0400 Subject: patch for gsm0808.c In-Reply-To: <20130711072317.GN6004@nataraja.gnumonks.org> References: <20130711072317.GN6004@nataraja.gnumonks.org> Message-ID: Dear Harald, On Thu, Jul 11, 2013 at 11:23 AM, Harald Welte wrote: > Dear Dmitri, > > thanks for your patch, it will of course be merged. > > On Thu, Jul 11, 2013 at 10:49:32AM +0400, Dmitri Soloviev wrote: > > > Right now there is a pilot with MNO, and Telscale SS7 Card runs code > > for A-interface gateway, converting BSSAP/SS7 to SCCPoverIP + rtp. > > this is great news. Please let us know if you need any assistance. Did > I ever send you the protocol traces that you asked for? > not yet > > > It seems that such a gateway also has to adapt OpenBSC to each > > particular MSC. > > I'm not sure if this really belongs into the gateway, or if we shouldn't > rather have this code in OsmoBSC itself. > > So far, OsmoBSC has been used (to my knowledge) with Altobridge, Zynetix > (Globe Wireless) and Quortus. > > We can introduce a 'msc model' in osmo-bsc, similar to having a 'bts > model', and then code e.g. generating 08.08 messages can selectively > check on the msc->model to have vendor-specific kludges. > it's up to philosophy: if you are planning to keep a pure BSC code for SCCPoverIP, or SS7 A-Interface as well. In the second case, such a gateway is not needed at all, and my activities make no sence > > > Code will published as soon as pilot succeeds. > > Great! > > -- > - Harald Welte http://www.sysmocom.de/ > ======================================================================= > * sysmocom - systems for mobile communications GmbH > * Schivelbeiner Str. 5 > * 10439 Berlin, Germany > * Sitz / Registered office: Berlin, HRB 134158 B > * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ivan.Kluchnikov at fairwaves.ru Fri Jul 12 17:08:42 2013 From: Ivan.Kluchnikov at fairwaves.ru (Ivan Kluchnikov) Date: Fri, 12 Jul 2013 21:08:42 +0400 Subject: [PATCH] Add vty command for setting Access control classes Message-ID: Hi all, Attached patch adds vty command for setting Access control classes (GSM 02.11 Section 4 Access control) in RACH Control Parameters (GSM 04.08 Section 10.5.2.29 RACH Control Parameters). -- Regards, Ivan Kluchnikov. http://fairwaves.ru -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Added-vty-command-for-setting-Access-control-classes.patch Type: application/octet-stream Size: 3526 bytes Desc: not available URL: From peter at stuge.se Fri Jul 12 18:28:44 2013 From: peter at stuge.se (Peter Stuge) Date: Fri, 12 Jul 2013 20:28:44 +0200 Subject: [PATCH] Add vty command for setting Access control classes In-Reply-To: References: Message-ID: <20130712182844.12556.qmail@stuge.se> Ivan Kluchnikov wrote: > +DEFUN(cfg_bts_rach_ac_classes, cfg_bts_rach_ac_classes_cmd, > + "rach access control classes (0|1) (0|1) (0|1) (0|1) (0|1) (0|1) (0|1) (0|1) (0|1) (0|1) x (0|1) (0|1) (0|1) (0|1) (0|1)", > + RACH_STR > + "Access control classes\n" > + "Access control classes\n" > + "Access control classes\n" > + "Access is NOT barred for ACC 0\n" > + "Access is barred for ACC 0\n" > + "Access is NOT barred for ACC 1\n" .. The command looks pretty horrible. Do you think that there could be a better user interface than a single command with 16 parameters? I'd suggest something like: rach access control class (0..15) (0|1) //Peter From andreas at eversberg.eu Fri Jul 12 18:48:56 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Fri, 12 Jul 2013 20:48:56 +0200 Subject: [PATCH] Add vty command for setting Access control classes In-Reply-To: <20130712182844.12556.qmail@stuge.se> References: <20130712182844.12556.qmail@stuge.se> Message-ID: <51E04F98.6090009@eversberg.eu> Peter Stuge wrote: > The command looks pretty horrible. Do you think that there could be a > better user interface than a single command with 16 parameters? > > I'd suggest something like: rach access control class (0..15) (0|1) yes, it makes sense. also it would make sense to actually write the access classes to vty config, if "show running-configuration" or "write" is used. (see config_write_bts_single()) since "0" (not barred) is the default, i would suggest to only write the barred ("1") classes to config. this way the config is kept slim. From alexander.chemeris at gmail.com Fri Jul 12 19:07:12 2013 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Fri, 12 Jul 2013 23:07:12 +0400 Subject: [PATCH] Add vty command for setting Access control classes In-Reply-To: <51E04F98.6090009@eversberg.eu> References: <20130712182844.12556.qmail@stuge.se> <51E04F98.6090009@eversberg.eu> Message-ID: On Fri, Jul 12, 2013 at 10:48 PM, Andreas Eversberg wrote: > also it would make sense to actually write the access > classes to vty config, if "show running-configuration" or "write" is used. > (see config_write_bts_single()) Yes, this is a good point. Should be fixed. > since "0" (not barred) is the default, i would suggest to only write the > barred ("1") classes to config. this way the config is kept slim. See my e-mail to Peter. Looks like a matter of taste. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From alexander.chemeris at gmail.com Fri Jul 12 19:06:02 2013 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Fri, 12 Jul 2013 23:06:02 +0400 Subject: [PATCH] Add vty command for setting Access control classes In-Reply-To: <20130712182844.12556.qmail@stuge.se> References: <20130712182844.12556.qmail@stuge.se> Message-ID: On Fri, Jul 12, 2013 at 10:28 PM, Peter Stuge wrote: > > Ivan Kluchnikov wrote: > > +DEFUN(cfg_bts_rach_ac_classes, cfg_bts_rach_ac_classes_cmd, > > + "rach access control classes (0|1) (0|1) (0|1) (0|1) (0|1) (0|1) (0|1) (0|1) (0|1) (0|1) x (0|1) (0|1) (0|1) (0|1) (0|1)", > > + RACH_STR > > + "Access control classes\n" > > + "Access control classes\n" > > + "Access control classes\n" > > + "Access is NOT barred for ACC 0\n" > > + "Access is barred for ACC 0\n" > > + "Access is NOT barred for ACC 1\n" > .. > > The command looks pretty horrible. Do you think that there could be a > better user interface than a single command with 16 parameters? > > I'd suggest something like: rach access control class (0..15) (0|1) I like our way more, as it's a single line vs many-many lines. A single line doesn't occupy so much screen space and is easier to manipulate from VTY or over a slow satellite connection (happen frequently here). Also it gives you the whole picture in a single glance. Does it sound like a valid reason? -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From peter at stuge.se Fri Jul 12 19:27:00 2013 From: peter at stuge.se (Peter Stuge) Date: Fri, 12 Jul 2013 21:27:00 +0200 Subject: [PATCH] Add vty command for setting Access control classes In-Reply-To: References: <20130712182844.12556.qmail@stuge.se> Message-ID: <20130712192700.4229.qmail@stuge.se> Alexander Chemeris wrote: > > The command looks pretty horrible. Do you think that there could be a > > better user interface than a single command with 16 parameters? > > > > I'd suggest something like: rach access control class (0..15) (0|1) > > I like our way more, as it's a single line vs many-many lines. A > single line doesn't occupy so much screen space and is easier to > manipulate from VTY or over a slow satellite connection (happen > frequently here). Also it gives you the whole picture in a single > glance. > > Does it sound like a valid reason? No not the least. Compare: rach access control classes 0 1 1 0 0 1 0 0 1 0 0 0 1 1 0 with: rach access control class 1 1 rach access control class 2 1 rach access control class 5 0 rach access control class 5 1 rach access control class 8 1 rach access control class 13 1 rach access control class 14 1 I know which I find clearer, and easier to manipulate with a minimum of unwanted side effects. "The connectivity to my sites suck" really can't motivate such a bad user interface. Use mosh and/or train operators to deal with higher latency connections. //Peter PS. Did you notice the error in my 'class' commands? PPS. Did you notice the error in your 'classes' command? From peter at stuge.se Fri Jul 12 19:35:02 2013 From: peter at stuge.se (Peter Stuge) Date: Fri, 12 Jul 2013 21:35:02 +0200 Subject: [PATCH] Add vty command for setting Access control classes In-Reply-To: <20130712192700.4229.qmail@stuge.se> References: <20130712182844.12556.qmail@stuge.se> <20130712192700.4229.qmail@stuge.se> Message-ID: <20130712193502.5837.qmail@stuge.se> Peter Stuge wrote: > PS. Did you notice the error in my 'class' commands? > PPS. Did you notice the error in your 'classes' command? I hope this made my point clear. There is another option though; you could allow to specify ranges. rach access control classes 1-5,8-10,12,15 ...it just takes a few sscanf() calls in a loop. (No 0|1 at all, the given classes are allowed, others are barred.) //Peter From peter at stuge.se Fri Jul 12 19:41:55 2013 From: peter at stuge.se (Peter Stuge) Date: Fri, 12 Jul 2013 21:41:55 +0200 Subject: [PATCH] Add vty command for setting Access control classes In-Reply-To: <20130712193502.5837.qmail@stuge.se> References: <20130712182844.12556.qmail@stuge.se> <20130712192700.4229.qmail@stuge.se> <20130712193502.5837.qmail@stuge.se> Message-ID: <20130712194155.6629.qmail@stuge.se> Peter Stuge wrote: > Peter Stuge wrote: > > PS. Did you notice the error in my 'class' commands? > > PPS. Did you notice the error in your 'classes' command? > > I hope this made my point clear. > > There is another option though; you could allow to specify ranges. > > rach access control classes 1-5,8-10,12,15 I think it should still be called "rach access control class" however. //Peter From alexander.chemeris at gmail.com Sat Jul 13 05:49:35 2013 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Sat, 13 Jul 2013 09:49:35 +0400 Subject: [PATCH] Add vty command for setting Access control classes In-Reply-To: <20130712193502.5837.qmail@stuge.se> References: <20130712182844.12556.qmail@stuge.se> <20130712192700.4229.qmail@stuge.se> <20130712193502.5837.qmail@stuge.se> Message-ID: On Fri, Jul 12, 2013 at 11:35 PM, Peter Stuge wrote: > There is another option though; you could allow to specify ranges. > > rach access control classes 1-5,8-10,12,15 > > ...it just takes a few sscanf() calls in a loop. > > (No 0|1 at all, the given classes are allowed, others are barred.) That would be a nice option. I don't think we have time to implement parsing of that right now, but if someone makes this, we definitely vote for this way. Otherwise we'll stick to the way discussed above. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From alexander.chemeris at gmail.com Sat Jul 13 05:47:16 2013 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Sat, 13 Jul 2013 09:47:16 +0400 Subject: [PATCH] Add vty command for setting Access control classes In-Reply-To: <20130712192700.4229.qmail@stuge.se> References: <20130712182844.12556.qmail@stuge.se> <20130712192700.4229.qmail@stuge.se> Message-ID: On Fri, Jul 12, 2013 at 11:27 PM, Peter Stuge wrote: > Compare: > > rach access control classes 0 1 1 0 0 1 0 0 1 0 0 0 1 1 0 > > with: > > rach access control class 1 1 > rach access control class 2 1 > rach access control class 5 0 > rach access control class 5 1 > rach access control class 8 1 > rach access control class 13 1 > rach access control class 14 1 > > I know which I find clearer, and easier to manipulate with a minimum > of unwanted side effects. > > PS. Did you notice the error in my 'class' commands? > PPS. Did you notice the error in your 'classes' command? Ok, now it makes sense. I think we could even drop the last (0|1) and make it like that: rach access control class barred 1 rach access control class barred 2 rach access control class barred 5 (default being not barred) OTOH I like the idea that you could change value without removing a whole string, so may be make it even more user-friendly: rach access control class 1 barred rach access control class 2 barred rach access control class 5 allowed The idea is that "1" meaning "barred" is counter-intuitive and may lead to wrong setting. Even I will forget abut the trick in a couple of months. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From holger at freyther.de Sat Jul 13 05:58:37 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sat, 13 Jul 2013 07:58:37 +0200 Subject: [PATCH] Add vty command for setting Access control classes In-Reply-To: References: Message-ID: <20130713055837.GA15044@xiaoyu.lan> On Fri, Jul 12, 2013 at 09:08:42PM +0400, Ivan Kluchnikov wrote: > Hi all, > > Attached patch adds vty command for setting Access control classes (GSM > 02.11 Section 4 Access control) in RACH Control Parameters (GSM 04.08 > Section 10.5.2.29 > RACH Control Parameters). Hi, mutt doesn't allow me to comment on the patch (for inline patches this always works, for some attachments it does work too.. not for yours). My comments: * Peter is right, and use "barred"|"allowed" as well instead of 0,1. * The 'current' VTY rule is that unless there is a common prefix use '-' in the command. So it would be 'rach access-control-class" right now until we have someone else at 'access-control'.. * The code is missing a 'write' implementation. * You might want to write a VTY test[1] to test if the command is taking effect on the SIs. You will need to create a subclass for the NITB. * Please take a look at the kernel coding style * Great to have this feature, for things like Fusion this is a useful addition! * Great you patched pySIM for the ACC support. thanks holger [1] http://cgit.osmocom.org/openbsc/tree/openbsc/tests/vty_test_runner.py From alexander.chemeris at gmail.com Sat Jul 13 06:50:40 2013 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Sat, 13 Jul 2013 10:50:40 +0400 Subject: [PATCH] Add vty command for setting Access control classes In-Reply-To: <20130713055837.GA15044@xiaoyu.lan> References: <20130713055837.GA15044@xiaoyu.lan> Message-ID: Hi Holger, On Sat, Jul 13, 2013 at 9:58 AM, Holger Hans Peter Freyther wrote: > mutt doesn't allow me to comment on the patch (for inline patches this > always works, for some attachments it does work too.. not for yours). Probably because it's base64 encoded. > * The 'current' VTY rule is that unless there is a common prefix use > '-' in the command. So it would be 'rach access-control-class" right > now until we have someone else at 'access-control'.. Huh, is that a new rule? I see commands like "rach max transmission", "rach tx integer" and so on which do not use "-". Thanks for your other comments. We'll look into updating the patch. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From holger at freyther.de Sat Jul 13 09:46:58 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sat, 13 Jul 2013 11:46:58 +0200 Subject: [PATCH] Add vty command for setting Access control classes In-Reply-To: References: <20130713055837.GA15044@xiaoyu.lan> Message-ID: <20130713094658.GF4901@xiaoyu.lan> On Sat, Jul 13, 2013 at 10:50:40AM +0400, Alexander Chemeris wrote: > > * The 'current' VTY rule is that unless there is a common prefix use > > '-' in the command. So it would be 'rach access-control-class" right > > now until we have someone else at 'access-control'.. > > Huh, is that a new rule? Not exactly, the rule has been there before we used the VTY.. I just never used cisco stuff before. ;) > I see commands like "rach max transmission", "rach tx integer" and so > on which do not use "-". Yeah, we have plenty of violations (and I don't think it is worth fixing). For new ones just try to get it right. From alexander.chemeris at gmail.com Sat Jul 13 10:11:29 2013 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Sat, 13 Jul 2013 14:11:29 +0400 Subject: [PATCH] Add vty command for setting Access control classes In-Reply-To: <20130713094658.GF4901@xiaoyu.lan> References: <20130713055837.GA15044@xiaoyu.lan> <20130713094658.GF4901@xiaoyu.lan> Message-ID: On Sat, Jul 13, 2013 at 1:46 PM, Holger Hans Peter Freyther wrote: > > On Sat, Jul 13, 2013 at 10:50:40AM +0400, Alexander Chemeris wrote: > > > > * The 'current' VTY rule is that unless there is a common prefix use > > > '-' in the command. So it would be 'rach access-control-class" right > > > now until we have someone else at 'access-control'.. > > > > Huh, is that a new rule? > > Not exactly, the rule has been there before we used the VTY.. I just > never used cisco stuff before. ;) Me either :) > > I see commands like "rach max transmission", "rach tx integer" and so > > on which do not use "-". > > Yeah, we have plenty of violations (and I don't think it is worth > fixing). For new ones just try to get it right. Ok. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From Ivan.Kluchnikov at fairwaves.ru Thu Jul 25 14:19:24 2013 From: Ivan.Kluchnikov at fairwaves.ru (Ivan Kluchnikov) Date: Thu, 25 Jul 2013 18:19:24 +0400 Subject: [PATCH] Add vty command for setting Access control classes In-Reply-To: References: <20130713055837.GA15044@xiaoyu.lan> <20130713094658.GF4901@xiaoyu.lan> Message-ID: Hi all, This is new version of patch for review and merge: - more user-friendly interface for command: rach access-control-class 2 barred rach access-control-class 11 allowed - added 'write' implementation 2013/7/13 Alexander Chemeris > On Sat, Jul 13, 2013 at 1:46 PM, Holger Hans Peter Freyther > wrote: > > > > On Sat, Jul 13, 2013 at 10:50:40AM +0400, Alexander Chemeris wrote: > > > > > > * The 'current' VTY rule is that unless there is a common prefix use > > > > '-' in the command. So it would be 'rach access-control-class" > right > > > > now until we have someone else at 'access-control'.. > > > > > > Huh, is that a new rule? > > > > Not exactly, the rule has been there before we used the VTY.. I just > > never used cisco stuff before. ;) > > Me either :) > > > > I see commands like "rach max transmission", "rach tx integer" and so > > > on which do not use "-". > > > > Yeah, we have plenty of violations (and I don't think it is worth > > fixing). For new ones just try to get it right. > > Ok. > > -- > Regards, > Alexander Chemeris. > CEO, Fairwaves LLC / ??? ??????? > http://fairwaves.ru > -- Regards, Ivan Kluchnikov. http://fairwaves.ru -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Added-vty-command-for-setting-Access-control-classes.patch Type: application/octet-stream Size: 3560 bytes Desc: not available URL: From holger at freyther.de Thu Jul 25 14:33:15 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Thu, 25 Jul 2013 16:33:15 +0200 Subject: [PATCH] Add vty command for setting Access control classes In-Reply-To: References: <20130713055837.GA15044@xiaoyu.lan> <20130713094658.GF4901@xiaoyu.lan> Message-ID: <20130725143315.GA25649@xiaoyu.lan> On Thu, Jul 25, 2013 at 06:19:24PM +0400, Ivan Kluchnikov wrote: > - added 'write' implementation please write a VTY test for this routine. It is like 20 lines of python and will make sure that bitrot is detected early (a perfect way to secure your time investment). + if ((bts->si_common.rach_control.t3) != 0) ... + if ((bts->si_common.rach_control.t2 & 0xfb) != 0) ... you want to avoid executing the for loop? holger From Ivan.Kluchnikov at fairwaves.ru Thu Jul 25 15:21:55 2013 From: Ivan.Kluchnikov at fairwaves.ru (Ivan Kluchnikov) Date: Thu, 25 Jul 2013 19:21:55 +0400 Subject: [PATCH] Add vty command for setting Access control classes In-Reply-To: <20130725143315.GA25649@xiaoyu.lan> References: <20130713055837.GA15044@xiaoyu.lan> <20130713094658.GF4901@xiaoyu.lan> <20130725143315.GA25649@xiaoyu.lan> Message-ID: 2013/7/25 Holger Hans Peter Freyther > On Thu, Jul 25, 2013 at 06:19:24PM +0400, Ivan Kluchnikov wrote: > > > - added 'write' implementation > > please write a VTY test for this routine. It is like 20 lines of > python and will make sure that bitrot is detected early (a perfect > way to secure your time investment). > > Yes, I agree, tests are very important, I will try to write one for this command. > > + if ((bts->si_common.rach_control.t3) != 0) > ... > > + if ((bts->si_common.rach_control.t2 & 0xfb) != 0) > ... > > you want to avoid executing the for loop? > > Yes, do you think it is redundant part of the code? > > holger > > -- Regards, Ivan Kluchnikov. http://fairwaves.ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at freyther.de Fri Jul 26 04:27:18 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Fri, 26 Jul 2013 06:27:18 +0200 Subject: [PATCH] Add vty command for setting Access control classes In-Reply-To: References: <20130713055837.GA15044@xiaoyu.lan> <20130713094658.GF4901@xiaoyu.lan> <20130725143315.GA25649@xiaoyu.lan> Message-ID: <20130726042718.GA2673@xiaoyu.lan> On Thu, Jul 25, 2013 at 07:21:55PM +0400, Ivan Kluchnikov wrote: > 2013/7/25 Holger Hans Peter Freyther > Yes, I agree, tests are very important, I will try to write one for this > command. To help you I created the below snippet. You will just need to write a new test method in there to do config and show configure. E.g. you can issue all bar commands and verify that it shows up in the write terminal command, then allow them again and see that it goes away. diff --git a/openbsc/tests/vty_test_runner.py b/openbsc/tests/vty_test_runner.py index 3aa40f4..a3e29d3 100644 --- a/openbsc/tests/vty_test_runner.py +++ b/openbsc/tests/vty_test_runner.py @@ -55,6 +55,19 @@ class TestVTYBase(unittest.TestCase): self.vty = None osmoutil.end_proc(self.proc) +class TestVTYNITB(TestVTYBase): + + def vty_command(self): + return ["./src/osmo-nitb/osmo-nitb", "-c", + "doc/examples/osmo-nitb/nanobts/openbsc.cfg"] + + def vty_app(self): + return (4242, "./src/osmo-nitb/osmo-nitb", "OpenBSC", "nitb") + + def testShowNetwork(self): + res = self.vty.command("show network") + print res + class TestVTYNAT(TestVTYBase): @@ -138,6 +151,7 @@ if __name__ == '__main__': os.chdir(workdir) print "Running tests for specific VTY commands" suite = unittest.TestSuite() + suite.addTest(unittest.TestLoader().loadTestsFromTestCase(TestVTYNITB)) add_nat_test(suite, workdir) res = unittest.TextTestRunner(verbosity=verbose_level).run(suite) sys.exit(len(res.errors) + len(res.failures)) From peter at stuge.se Thu Jul 25 14:55:58 2013 From: peter at stuge.se (Peter Stuge) Date: Thu, 25 Jul 2013 16:55:58 +0200 Subject: [PATCH] Add vty command for setting Access control classes In-Reply-To: References: <20130713055837.GA15044@xiaoyu.lan> <20130713094658.GF4901@xiaoyu.lan> Message-ID: <20130725145558.14794.qmail@stuge.se> Ivan Kluchnikov wrote: > This is new version of patch for review and merge: > > - more user-friendly interface for command: > rach access-control-class 2 barred > rach access-control-class 11 allowed Yes, much better than before, but perhaps spend the half hour it takes to write that %d-%d parser using sscanf? > +++ b/openbsc/src/libbsc/bsc_vty.c .. > @@ -2059,6 +2067,51 @@ DEFUN(cfg_bts_rach_ec_allowed, cfg_bts_rach_ec_allowed_cmd, > return CMD_SUCCESS; > } > > +DEFUN(cfg_bts_rach_ac_class, cfg_bts_rach_ac_class_cmd, > + "rach access-control-class (0|1|2|3|4|5|6|7|8|9|11|12|13|14|15) (barred|allowed)", > + RACH_STR > + "Set access control class\n" > + "Access control class 0\n" > + "Access control class 1\n" > + "Access control class 2\n" > + "Access control class 3\n" > + "Access control class 4\n" > + "Access control class 5\n" > + "Access control class 6\n" > + "Access control class 7\n" > + "Access control class 8\n" > + "Access control class 9\n" > + "Access control class 11 for PLMN use\n" > + "Access control class 12 for security services\n" > + "Access control class 13 for public utilities (e.g. water/gas suppliers)\n" > + "Access control class 14 for emergency services\n" > + "Access control class 15 for PLMN staff\n" > + "barred to use access control class\n" > + "allowed to use access control class\n") > +{ Is that long array of strings correct? //Peter From Ivan.Kluchnikov at fairwaves.ru Thu Jul 25 15:29:37 2013 From: Ivan.Kluchnikov at fairwaves.ru (Ivan Kluchnikov) Date: Thu, 25 Jul 2013 19:29:37 +0400 Subject: [PATCH] Add vty command for setting Access control classes In-Reply-To: <20130725145558.14794.qmail@stuge.se> References: <20130713055837.GA15044@xiaoyu.lan> <20130713094658.GF4901@xiaoyu.lan> <20130725145558.14794.qmail@stuge.se> Message-ID: 2013/7/25 Peter Stuge > Ivan Kluchnikov wrote: > > This is new version of patch for review and merge: > > > > - more user-friendly interface for command: > > rach access-control-class 2 barred > > rach access-control-class 11 allowed > > Yes, much better than before, but perhaps spend the half hour it > takes to write that %d-%d parser using sscanf? > You are welcome :) If you implement %d-%d parser, I will change style of this VTY command. > > > > > +++ b/openbsc/src/libbsc/bsc_vty.c > .. > > @@ -2059,6 +2067,51 @@ DEFUN(cfg_bts_rach_ec_allowed, > cfg_bts_rach_ec_allowed_cmd, > > return CMD_SUCCESS; > > } > > > > +DEFUN(cfg_bts_rach_ac_class, cfg_bts_rach_ac_class_cmd, > > + "rach access-control-class (0|1|2|3|4|5|6|7|8|9|11|12|13|14|15) > (barred|allowed)", > > + RACH_STR > > + "Set access control class\n" > > + "Access control class 0\n" > > + "Access control class 1\n" > > + "Access control class 2\n" > > + "Access control class 3\n" > > + "Access control class 4\n" > > + "Access control class 5\n" > > + "Access control class 6\n" > > + "Access control class 7\n" > > + "Access control class 8\n" > > + "Access control class 9\n" > > + "Access control class 11 for PLMN use\n" > > + "Access control class 12 for security services\n" > > + "Access control class 13 for public utilities (e.g. water/gas > suppliers)\n" > > + "Access control class 14 for emergency services\n" > > + "Access control class 15 for PLMN staff\n" > > + "barred to use access control class\n" > > + "allowed to use access control class\n") > > +{ > > Is that long array of strings correct? > I think, yes, because it works. Do you know other way to do it? > > > //Peter > > -- Regards, Ivan Kluchnikov. http://fairwaves.ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at stuge.se Thu Jul 25 16:02:00 2013 From: peter at stuge.se (Peter Stuge) Date: Thu, 25 Jul 2013 18:02:00 +0200 Subject: [PATCH] Add vty command for setting Access control classes In-Reply-To: References: <20130713055837.GA15044@xiaoyu.lan> <20130713094658.GF4901@xiaoyu.lan> <20130725145558.14794.qmail@stuge.se> Message-ID: <20130725160200.20126.qmail@stuge.se> Ivan Kluchnikov wrote: > > Ivan Kluchnikov wrote: > > > This is new version of patch for review and merge: > > > > > > - more user-friendly interface for command: > > > rach access-control-class 2 barred > > > rach access-control-class 11 allowed > > > > Yes, much better than before, but perhaps spend the half hour it > > takes to write that %d-%d parser using sscanf? > > You are welcome :) > If you implement %d-%d parser, I will change style of this VTY command. Here you go. //Peter -------------- next part -------------- #include #ifndef MIN #define MIN(a, b) ((a) < (b) ? (a) : (b)) #endif /* MIN */ #ifndef MAX #define MAX(a, b) ((a) > (b) ? (a) : (b)) #endif /* MAX */ #ifndef ARRAY_SIZE #define ARRAY_SIZE(a) (sizeof (a) / sizeof (a)[0]) #endif /* ARRAY_SIZE */ int main(int argc,const char *argv[]) { int i,val[16]; int a,b,n1,n2; const char *p; if(argc<2) { fprintf(stderr,"usage: %s int[-int][,...]\n",*argv); return 1; } for(i=0;i References: <20130713055837.GA15044@xiaoyu.lan> <20130713094658.GF4901@xiaoyu.lan> <20130725145558.14794.qmail@stuge.se> <20130725160200.20126.qmail@stuge.se> Message-ID: <20130725161043.20895.qmail@stuge.se> Peter Stuge wrote: > if (',' == *p) > p++; Here it should actually also throw parse error if there is any other character than comma or end-of-input: if (',' == *p) p++; else if (*p) { fprintf(stderr, "invalid input at '%.5s'\n", p); return 4; } //Peter From peter at stuge.se Thu Jul 25 16:18:14 2013 From: peter at stuge.se (Peter Stuge) Date: Thu, 25 Jul 2013 18:18:14 +0200 Subject: [PATCH] Add vty command for setting Access control classes In-Reply-To: <20130725161043.20895.qmail@stuge.se> References: <20130713055837.GA15044@xiaoyu.lan> <20130713094658.GF4901@xiaoyu.lan> <20130725145558.14794.qmail@stuge.se> <20130725160200.20126.qmail@stuge.se> <20130725161043.20895.qmail@stuge.se> Message-ID: <20130725161814.21551.qmail@stuge.se> Peter Stuge wrote: > > if (',' == *p) > > p++; > > Here it should actually also throw parse error if there is any other > character than comma or end-of-input: And there was an off-by-one error for the upper bound of a range. I think I've caught all the issues in this version of the file. :) //Peter -------------- next part -------------- #include #ifndef MIN #define MIN(a, b) ((a) < (b) ? (a) : (b)) #endif /* MIN */ #ifndef MAX #define MAX(a, b) ((a) > (b) ? (a) : (b)) #endif /* MAX */ #ifndef ARRAY_SIZE #define ARRAY_SIZE(a) (sizeof (a) / sizeof (a)[0]) #endif /* ARRAY_SIZE */ int main(int argc,const char *argv[]) { int i,val[16]; int a,b,n1,n2; const char *p; if(argc<2) { fprintf(stderr,"usage: %s int[-int][,...]\n",*argv); return 1; } for(i=0;i References: <20130713055837.GA15044@xiaoyu.lan> <20130713094658.GF4901@xiaoyu.lan> <20130725145558.14794.qmail@stuge.se> <20130725160200.20126.qmail@stuge.se> <20130725161043.20895.qmail@stuge.se> <20130725161814.21551.qmail@stuge.se> Message-ID: Yes, the next step is to integrate this code into osmocore VTY code. 2013/7/25 Peter Stuge > Peter Stuge wrote: > > > if (',' == *p) > > > p++; > > > > Here it should actually also throw parse error if there is any other > > character than comma or end-of-input: > > And there was an off-by-one error for the upper bound of a range. > > I think I've caught all the issues in this version of the file. :) > > > //Peter > -- Regards, Ivan Kluchnikov. http://fairwaves.ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at stuge.se Thu Jul 25 17:03:46 2013 From: peter at stuge.se (Peter Stuge) Date: Thu, 25 Jul 2013 19:03:46 +0200 Subject: [PATCH] Add vty command for setting Access control classes In-Reply-To: References: <20130713094658.GF4901@xiaoyu.lan> <20130725145558.14794.qmail@stuge.se> <20130725160200.20126.qmail@stuge.se> <20130725161043.20895.qmail@stuge.se> <20130725161814.21551.qmail@stuge.se> Message-ID: <20130725170346.25452.qmail@stuge.se> Ivan Kluchnikov wrote: > Yes, the next step is to integrate this code into osmocore VTY code. It would be great if you do that! :) //Peter From holger at freyther.de Sat Jul 13 15:24:55 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sat, 13 Jul 2013 17:24:55 +0200 Subject: [PATCH] smpp: Move the coding/mode detection into a utils file Message-ID: <1373729095-21290-1-git-send-email-holger@freyther.de> From: Holger Hans Peter Freyther Make sure to not ever have issues with this code again, move the utility code to a new file and create a basic testcase. The method currently has 100% line and branch coverage. --- openbsc/.gitignore | 1 + openbsc/configure.ac | 1 + openbsc/src/libmsc/Makefile.am | 2 +- openbsc/src/libmsc/smpp_openbsc.c | 36 +------------------ openbsc/src/libmsc/smpp_smsc.h | 5 +++ openbsc/tests/Makefile.am | 4 +++ openbsc/tests/smpp/Makefile.am | 12 +++++++ openbsc/tests/smpp/smpp_test.c | 73 +++++++++++++++++++++++++++++++++++++++ openbsc/tests/smpp/smpp_test.err | 2 ++ openbsc/tests/smpp/smpp_test.ok | 1 + openbsc/tests/testsuite.at | 8 +++++ 11 files changed, 109 insertions(+), 36 deletions(-) create mode 100644 openbsc/tests/smpp/Makefile.am create mode 100644 openbsc/tests/smpp/smpp_test.c create mode 100644 openbsc/tests/smpp/smpp_test.err create mode 100644 openbsc/tests/smpp/smpp_test.ok diff --git a/openbsc/.gitignore b/openbsc/.gitignore index 53c8a4a..3743f69 100644 --- a/openbsc/.gitignore +++ b/openbsc/.gitignore @@ -61,6 +61,7 @@ tests/timer/timer_test tests/gprs/gprs_test tests/abis/abis_test tests/si/si_test +tests/smpp/smpp_test tests/atconfig tests/atlocal diff --git a/openbsc/configure.ac b/openbsc/configure.ac index 3dd2212..8997e2e 100644 --- a/openbsc/configure.ac +++ b/openbsc/configure.ac @@ -160,6 +160,7 @@ AC_OUTPUT( tests/gprs/Makefile tests/si/Makefile tests/abis/Makefile + tests/smpp/Makefile doc/Makefile doc/examples/Makefile Makefile) diff --git a/openbsc/src/libmsc/Makefile.am b/openbsc/src/libmsc/Makefile.am index 7faee43..c36ba92 100644 --- a/openbsc/src/libmsc/Makefile.am +++ b/openbsc/src/libmsc/Makefile.am @@ -19,5 +19,5 @@ libmsc_a_SOURCES = auth.c \ osmo_msc.c if BUILD_SMPP -libmsc_a_SOURCES += smpp_smsc.c smpp_openbsc.c smpp_vty.c +libmsc_a_SOURCES += smpp_smsc.c smpp_openbsc.c smpp_vty.c smpp_utils.c endif diff --git a/openbsc/src/libmsc/smpp_openbsc.c b/openbsc/src/libmsc/smpp_openbsc.c index 1744b0e..a3d2487 100644 --- a/openbsc/src/libmsc/smpp_openbsc.c +++ b/openbsc/src/libmsc/smpp_openbsc.c @@ -78,9 +78,6 @@ static struct tlv_t *find_tlv(struct tlv_t *head, uint16_t tag) return NULL; } -#define MODE_7BIT 7 -#define MODE_8BIT 8 - /*! \brief convert from submit_sm_t to gsm_sms */ static int submit_to_sms(struct gsm_sms **psms, struct gsm_network *net, const struct submit_sm_t *submit) @@ -468,39 +465,8 @@ static int deliver_to_esme(struct osmo_esme *esme, struct gsm_sms *sms, /* Figure out SMPP DCS from TP-DCS */ dcs = sms->data_coding_scheme; - if ((dcs & 0xF0) == 0xF0) { - if (dcs & 0x04) { - /* bit 2 == 1: 8bit data */ - deliver.data_coding = 0x02; - mode = MODE_8BIT; - } else { - /* bit 2 == 0: default alphabet */ - deliver.data_coding = 0x01; - mode = MODE_7BIT; - } - } else if ((dcs & 0xE0) == 0) { - switch (dcs & 0xC) { - case 0: - deliver.data_coding = 0x01; - mode = MODE_7BIT; - break; - case 4: - deliver.data_coding = 0x02; - mode = MODE_8BIT; - break; - case 8: - deliver.data_coding = 0x08; /* UCS-2 */ - mode = MODE_8BIT; - break; - default: - goto unknown_mo; - } - } else { -unknown_mo: - LOGP(DLSMS, LOGL_ERROR, "SMPP MO Unknown Data Coding 0x%02x\n", - dcs); + if (smpp_determine_scheme(dcs, &deliver.data_coding, &mode) == -1) return -1; - } /* Transparently pass on DCS via SMPP if requested */ if (esme->acl->dcs_transparent) diff --git a/openbsc/src/libmsc/smpp_smsc.h b/openbsc/src/libmsc/smpp_smsc.h index 86fbeb5..028e572 100644 --- a/openbsc/src/libmsc/smpp_smsc.h +++ b/openbsc/src/libmsc/smpp_smsc.h @@ -15,6 +15,9 @@ #define SMPP_SYS_ID_LEN 16 #define SMPP_PASSWD_LEN 16 +#define MODE_7BIT 7 +#define MODE_8BIT 8 + enum esme_read_state { READ_ST_IN_LEN = 0, READ_ST_IN_MSG = 1, @@ -124,4 +127,6 @@ int smpp_route_pfx_add(struct osmo_smpp_acl *acl, const struct osmo_smpp_addr *pfx); int smpp_route_pfx_del(struct osmo_smpp_acl *acl, const struct osmo_smpp_addr *pfx); + +int smpp_determine_scheme(uint8_t dcs, uint8_t *data_coding, int *mode); #endif diff --git a/openbsc/tests/Makefile.am b/openbsc/tests/Makefile.am index c0e48df..c9afeed 100644 --- a/openbsc/tests/Makefile.am +++ b/openbsc/tests/Makefile.am @@ -4,6 +4,10 @@ if BUILD_NAT SUBDIRS += bsc-nat endif +if BUILD_SMPP +SUBDIRS += smpp +endif + # The `:;' works around a Bash 3.2 bug when the output is not writeable. $(srcdir)/package.m4: $(top_srcdir)/configure.ac diff --git a/openbsc/tests/smpp/Makefile.am b/openbsc/tests/smpp/Makefile.am new file mode 100644 index 0000000..eb25965 --- /dev/null +++ b/openbsc/tests/smpp/Makefile.am @@ -0,0 +1,12 @@ +AM_CPPFLAGS = $(all_includes) -I$(top_srcdir)/include -I$(top_srcdir)/src/libmsc +AM_CFLAGS=-Wall -ggdb3 $(LIBOSMOCORE_CFLAGS) $(LIBOSMOGSM_CFLAGS) $(LIBOSMOSCCP_CFLAGS) $(LIBOSMOABIS_CFLAGS) $(COVERAGE_CFLAGS) +AM_LDFLAGS = $(COVERAGE_LDFLAGS) + +EXTRA_DIST = smpp_test.ok smpp_test.err + +noinst_PROGRAMS = smpp_test + +smpp_test_SOURCES = smpp_test.c \ + $(top_srcdir)/src/libmsc/smpp_utils.c +smpp_test_LDADD = $(LIBOSMOCORE_LIBS) \ + $(top_srcdir)/src/libcommon/libcommon.a diff --git a/openbsc/tests/smpp/smpp_test.c b/openbsc/tests/smpp/smpp_test.c new file mode 100644 index 0000000..62fa9d2 --- /dev/null +++ b/openbsc/tests/smpp/smpp_test.c @@ -0,0 +1,73 @@ +/* + * (C) 2013 by Holger Hans Peter Freyther + * All Rights Reserved + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU Affero General Public License as published by + * the Free Software Foundation; either version 3 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU Affero General Public License for more details. + * + * You should have received a copy of the GNU Affero General Public License + * along with this program. If not, see . + * + */ + +#include +#include + +#include + +#include +#include + +#include "smpp_smsc.h" + +struct coding_test { + uint8_t dcs; + uint8_t coding; + int mode; + int res; +}; + +static struct coding_test codecs[] = { + { .dcs = 0xf6 , .coding = 0x02, .mode = MODE_8BIT, .res = 0 }, + { .dcs = 0xf2 , .coding = 0x01, .mode = MODE_7BIT, .res = 0 }, + { .dcs = 0x02 , .coding = 0x01, .mode = MODE_7BIT, .res = 0 }, + { .dcs = 0x06 , .coding = 0x02, .mode = MODE_8BIT, .res = 0 }, + { .dcs = 0x0A , .coding = 0x08, .mode = MODE_8BIT, .res = 0 }, + { .dcs = 0x0E , .coding = 0xFF, .mode = 0xFF, .res = -1 }, + { .dcs = 0xE0 , .coding = 0xFF, .mode = 0xFF, .res = -1 }, +}; + +static void test_coding_scheme(void) +{ + int i; + printf("Testing coding scheme support\n"); + + for (i = 0; i < ARRAY_SIZE(codecs); ++i) { + uint8_t coding; + int mode, res; + + res = smpp_determine_scheme(codecs[i].dcs, &coding, &mode); + OSMO_ASSERT(res == codecs[i].res); + if (res != -1) { + OSMO_ASSERT(mode == codecs[i].mode); + OSMO_ASSERT(coding == codecs[i].coding); + } + } +} + +int main(int argc, char **argv) +{ + osmo_init_logging(&log_info); + log_set_use_color(osmo_stderr_target, 0); + log_set_print_filename(osmo_stderr_target, 0); + + test_coding_scheme(); + return EXIT_SUCCESS; +} diff --git a/openbsc/tests/smpp/smpp_test.err b/openbsc/tests/smpp/smpp_test.err new file mode 100644 index 0000000..ec966ba --- /dev/null +++ b/openbsc/tests/smpp/smpp_test.err @@ -0,0 +1,2 @@ +SMPP MO Unknown Data Coding 0x0e +SMPP MO Unknown Data Coding 0xe0 diff --git a/openbsc/tests/smpp/smpp_test.ok b/openbsc/tests/smpp/smpp_test.ok new file mode 100644 index 0000000..fd44804 --- /dev/null +++ b/openbsc/tests/smpp/smpp_test.ok @@ -0,0 +1 @@ +Testing coding scheme support diff --git a/openbsc/tests/testsuite.at b/openbsc/tests/testsuite.at index e649f03..ea3fa1c 100644 --- a/openbsc/tests/testsuite.at +++ b/openbsc/tests/testsuite.at @@ -40,6 +40,14 @@ cat $abs_srcdir/bsc-nat/bsc_nat_test.ok > expout AT_CHECK([$abs_top_builddir/tests/bsc-nat/bsc_nat_test], [], [expout], [ignore]) AT_CLEANUP +AT_SETUP([smpp]) +AT_KEYWORDS([smpp]) +AT_CHECK([test "$enable_smpp_test" != no || exit 77]) +cat $abs_srcdir/smpp/smpp_test.ok > expout +cat $abs_srcdir/smpp/smpp_test.err > experr +AT_CHECK([$abs_top_builddir/tests/smpp/smpp_test], [], [expout], [experr]) +AT_CLEANUP + AT_SETUP([si]) AT_KEYWORDS([si]) cat $abs_srcdir/si/si_test.ok > expout -- 1.8.3.2 From alexander.chemeris at gmail.com Sat Jul 13 15:45:18 2013 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Sat, 13 Jul 2013 19:45:18 +0400 Subject: osmo-trx peculiarities in dual-channel mode Message-ID: Hi Thomas, What is the reason you disabled setting power attenuation an receive gain for the second trx? Since both channels in UmTRX are independent, it should be possible to control tx power and rx gain independently. In the "SETPOWER" command handler: if (mPrimary) mRadioInterface->setPowerAttenuation(dbPwr); In the "SETRXGAIN" it's even stranger, as it's set twice in case of primary trx: newGain = mRadioInterface->setRxGain(newGain); mEnergyThreshold = INIT_ENERGY_THRSHD; if (mPrimary) newGain = mRadioInterface->setRxGain(newGain); -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From ttsou at vt.edu Sat Jul 13 16:39:08 2013 From: ttsou at vt.edu (Thomas Tsou) Date: Sat, 13 Jul 2013 18:39:08 +0200 Subject: osmo-trx peculiarities in dual-channel mode In-Reply-To: References: Message-ID: On Sat, Jul 13, 2013 at 5:45 PM, Alexander Chemeris wrote: > What is the reason you disabled setting power attenuation an receive > gain for the second trx? Since both channels in UmTRX are independent, > it should be possible to control tx power and rx gain independently. > > In the "SETPOWER" command handler: > if (mPrimary) > mRadioInterface->setPowerAttenuation(dbPwr); The control interface was setup for OpenBTS, which does not make a distinction between independent channel gain. So I locked both gain settings to the primary channel (the one that initializes the device). For better osmo-bts usage, I split the gain settings in the same way that we discussed for the tuning setting. Note that this breaks OpenBTS usage, but that fix should really be in core and not the transceiver. git://github.com/ttsou/openbts-p2.8.git umtrx_dual_test > In the "SETRXGAIN" it's even stranger, as it's set twice in case of primary trx: > newGain = mRadioInterface->setRxGain(newGain); > mEnergyThreshold = INIT_ENERGY_THRSHD; > if (mPrimary) > newGain = mRadioInterface->setRxGain(newGain); Very strange indeed. That's a bug. Fixed in the same patch. Thomas From alexander.chemeris at gmail.com Sat Jul 13 17:43:20 2013 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Sat, 13 Jul 2013 21:43:20 +0400 Subject: osmo-trx peculiarities in dual-channel mode In-Reply-To: References: Message-ID: On Sat, Jul 13, 2013 at 8:39 PM, Thomas Tsou wrote: > On Sat, Jul 13, 2013 at 5:45 PM, Alexander Chemeris > wrote: >> What is the reason you disabled setting power attenuation an receive >> gain for the second trx? Since both channels in UmTRX are independent, >> it should be possible to control tx power and rx gain independently. >> >> In the "SETPOWER" command handler: >> if (mPrimary) >> mRadioInterface->setPowerAttenuation(dbPwr); > > The control interface was setup for OpenBTS, which does not make a > distinction between independent channel gain. So I locked both gain > settings to the primary channel (the one that initializes the device). > > For better osmo-bts usage, I split the gain settings in the same way > that we discussed for the tuning setting. Note that this breaks > OpenBTS usage, but that fix should really be in core and not the > transceiver. > > git://github.com/ttsou/openbts-p2.8.git umtrx_dual_test Well, since we don't control the core of OpenBTS, could we make the transceiver compatible with both ways? Also setting the Tx/Rx gains is a proper way for Multi-ARFCN version where ARFCN are actually on the same TRX. So we have to make this compatible with both ways anyway. E.g. we could introduce a new command to configure transceiver regarding TRXs. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From tom at tsou.cc Sat Jul 13 18:05:38 2013 From: tom at tsou.cc (Thomas Tsou) Date: Sat, 13 Jul 2013 20:05:38 +0200 Subject: osmo-trx peculiarities in dual-channel mode In-Reply-To: References: Message-ID: On Sat, Jul 13, 2013 at 7:43 PM, Alexander Chemeris wrote: > On Sat, Jul 13, 2013 at 8:39 PM, Thomas Tsou wrote: >> For better osmo-bts usage, I split the gain settings in the same way >> that we discussed for the tuning setting. Note that this breaks >> OpenBTS usage, but that fix should really be in core and not the >> transceiver. >> >> git://github.com/ttsou/openbts-p2.8.git umtrx_dual_test > > Well, since we don't control the core of OpenBTS, could we make the > transceiver compatible with both ways? We would need to change the gain control interface or set something at compile time. Basically, right now there is no way for the transceiver to distinguish between a set-all-gains and set-channel-gain request. > Also setting the Tx/Rx gains is a proper way for Multi-ARFCN version > where ARFCN are actually on the same TRX. So we have to make this > compatible with both ways anyway. E.g. we could introduce a new > command to configure transceiver regarding TRXs. Assuming OpenBTS core cannot be touched, we can either add a new set-channal-gain command or a second boolean argument on the existing SETRXGAIN command. For the latter case, OpenBTS would ignore the second argument. Thomas From alexander.chemeris at gmail.com Sat Jul 13 18:27:49 2013 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Sat, 13 Jul 2013 22:27:49 +0400 Subject: osmo-trx peculiarities in dual-channel mode In-Reply-To: References: Message-ID: On Sat, Jul 13, 2013 at 10:05 PM, Thomas Tsou wrote: > On Sat, Jul 13, 2013 at 7:43 PM, Alexander Chemeris > wrote: >> On Sat, Jul 13, 2013 at 8:39 PM, Thomas Tsou wrote: >> Also setting the Tx/Rx gains is a proper way for Multi-ARFCN version >> where ARFCN are actually on the same TRX. So we have to make this >> compatible with both ways anyway. E.g. we could introduce a new >> command to configure transceiver regarding TRXs. > > Assuming OpenBTS core cannot be touched, we can either add a new > set-channal-gain command or a second boolean argument on the existing > SETRXGAIN command. For the latter case, OpenBTS would ignore the > second argument. Yes, that's the best way imho. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From holger at freyther.de Sun Jul 14 05:59:27 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sun, 14 Jul 2013 07:59:27 +0200 Subject: Any BS11 user please test the following patch Message-ID: <20130714055927.GA5267@xiaoyu.lan> Hi, Coverity pointed out a missing break. I have added it now but the fix might break BS11 code that relied on this broken functionality. Could anyone with a BS11 please test this? I will integrate the change in a week. holger From holger at moiji-mobile.com Sun Jul 14 05:55:53 2013 From: holger at moiji-mobile.com (Holger Hans Peter Freyther) Date: Sun, 14 Jul 2013 07:55:53 +0200 Subject: [PATCH] oml: Add a missing break switch for NM_OC_BS11 Message-ID: It appears to me that for NM_OC_BS11 mo was either NULL or the one mo value from NM_OC_BS11_RACK. The break inside the nested switch case didn't break from the outer one. Fixes Coverity: CID 1040728 --- openbsc/src/libcommon/gsm_data_shared.c | 1 + 1 file changed, 1 insertion(+) diff --git a/openbsc/src/libcommon/gsm_data_shared.c b/openbsc/src/libcommon/gsm_data_shared.c index 9a50f6b..1b0814c 100644 --- a/openbsc/src/libcommon/gsm_data_shared.c +++ b/openbsc/src/libcommon/gsm_data_shared.c @@ -390,6 +390,7 @@ gsm_objclass2mo(struct gsm_bts *bts, uint8_t obj_class, default: return NULL; } + break; case NM_OC_BS11_RACK: mo = &bts->bs11.rack.mo; break; -- 1.8.3.2 From symack at gmail.com Sun Jul 14 21:28:56 2013 From: symack at gmail.com (Nick Khamis) Date: Sun, 14 Jul 2013 17:28:56 -0400 Subject: Any BS11 user please test the following patch In-Reply-To: <20130714055927.GA5267@xiaoyu.lan> References: <20130714055927.GA5267@xiaoyu.lan> Message-ID: Ahhhh yes!!! Missing breaks..... From holger at freyther.de Mon Jul 15 05:49:42 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 15 Jul 2013 07:49:42 +0200 Subject: Any BS11 user please test the following patch In-Reply-To: References: <20130714055927.GA5267@xiaoyu.lan> Message-ID: <20130715054942.GT4387@xiaoyu.lan> On Sun, Jul 14, 2013 at 05:28:56PM -0400, Nick Khamis wrote: > Ahhhh yes!!! Missing breaks..... there are more to come... in contrast to this one most of the other ones should not happen in reality though(tm). From andreas at eversberg.eu Tue Jul 16 14:39:13 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Tue, 16 Jul 2013 16:39:13 +0200 Subject: Any BS11 user please test the following patch In-Reply-To: <20130714055927.GA5267@xiaoyu.lan> References: <20130714055927.GA5267@xiaoyu.lan> Message-ID: <51E55B11.60302@eversberg.eu> Holger Hans Peter Freyther wrote: > Coverity pointed out a missing break. I have added it now but the > fix might break BS11 code that relied on this broken functionality. > > Could anyone with a BS11 please test this? I will integrate the > change in a week. > hi, if noone else has a working setup, i could test it. is this patch already submitted (to master)? if this patch breaks functionality, what malfunction would i expect? andreas From andreas at eversberg.eu Thu Jul 18 06:53:35 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Thu, 18 Jul 2013 08:53:35 +0200 Subject: Any BS11 user please test the following patch In-Reply-To: <20130714055927.GA5267@xiaoyu.lan> References: <20130714055927.GA5267@xiaoyu.lan> Message-ID: <51E790EF.7070303@eversberg.eu> Holger Hans Peter Freyther wrote: > Coverity pointed out a missing break. I have added it now but the > fix might break BS11 code that relied on this broken functionality. > > Could anyone with a BS11 please test this? I will integrate the > change in a week. > > hi holger, tests showed: the "break" statement does not break the functionality. during normal operation, this point of code is not reached. i had to remove TX antenna to generate an alarm, so the "break" statement was reached. bs11 worked fine after restoring antenna. regards, andreas From alexander.chemeris at gmail.com Sun Jul 14 20:01:08 2013 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Mon, 15 Jul 2013 00:01:08 +0400 Subject: Fixing power off in osmo-trx Message-ID: Hi Thomas, I've made some progress in making osmo-trx able to power off/on without restart. At this moment it's almost there - the only big remaining issue I see is some bug with UHD device start/stop. It seems we do not re-initialize it properly and assert (num_rd == OUTCHUNK) fails. I hope you could fix that. I completely re-wrote Thread class to make starting/stopping threads a synchronous reliable operation. I also introduced shutdown() function to FIFOServiceLoopThread, ControlServiceLoopThread and TransmitPriorityQueueServiceLoopThread. This method takes care of un-blocking a thread from a blocking read from a queue or a socket. Few bugs in the other code is fixed as well. Details are below, please review the patches. Patch set is checked into https://github.com/fairwaves/osmo-trx under achemeris/stable_threads and achemeris/poweroff_hack branches. > commit c5da6607b4d17706380de72e0814e28f03624c51 > Author: Alexander Chemeris > Date: Sun Jul 14 14:57:14 2013 +0400 > > Transceiver52M: Fix crash in uhd_device destructor due to deleting statically allocated memory. This is a genuine bug, should be fixed upstream. > commit dbd27a60b6ed99fd6fd2339ffafccc0d759fa2fc > Author: Alexander Chemeris > Date: Sat Jul 13 21:26:39 2013 +0400 > > CommonLibs: Fix compile time warnings. Fixes annoying warning. > commit 8eaa40dd6c2a783306d809aec98c2937e15068f3 > Author: Alexander Chemeris > Date: Sun Jul 14 16:23:32 2013 +0400 > > Transceiver52M: Remove unused thread mAlignRadioServiceLoopThread; This actually leads to crash when Thread class is abstract. > commit b8646946526903d2bbfa657690936b9bcba80ca5 > Author: Alexander Chemeris > Date: Sat Jul 13 22:29:12 2013 +0400 > > CommonLibs: DEBUG: Mark interthread classes which are not used in OsmoTRX. I've added this comments just to simplify debugging. I.e. I don't want to debug interthread primitives which we do not use. > commit 69b6a6dfcd882df180e9d5e9856225f4b1d2eeed > Author: Alexander Chemeris > Date: Sun Jul 14 01:43:04 2013 +0400 > > CommonLibs: Allow NULLs to be retrieved from InterthreadQueue. > > We need a way to stop InterthreadQueue blocking read to be able to shutdown > a thread. The easiest way to do that is to push NULL to the queue, but the > original implementation will just ignore that and continue blocking. After > the change the blocking read() will exit with NULL result which is perfectly > fine with us. > > Ideally we should change all methods of InterthreadQueue to return a status > value to indicate normal exits, timeouts, etc. Right now the only way to > indicate an error is returning NULL, which could be a valid operation. > > commit d4a8c1360e5d54188b648766dde199fa37f2ed27 > Author: Alexander Chemeris > Date: Sun Jul 14 02:00:00 2013 +0400 > > CommonLibs: Add shutdown() method to the DatagramSocket class. > > This method is useful to abort a blocking operations on a socket during shutdown. > > commit 302a9198df85e4f771368f24d8445dec7c8b2203 > Author: Alexander Chemeris > Date: Sun Jul 14 12:04:44 2013 +0400 > > CommonLibs: Signal::wait() should return the value which pthread_cond_timedwait() returns. > > commit e279124660a2add686e6c9266d18a9bb0cf43258 > Author: Alexander Chemeris > Date: Sun Jul 14 12:38:25 2013 +0400 > > CommonLibs: Rewrite Threads class to be predictable during start/stop. > > Current implementation strictly synchronize thread startup and shutdown > to make sure a thread is actually started on startThread() exit and > that it's stopped on stopThread() exit (or an error is returned). > > I also changed the Thread class to be used as a parent class for > an actual thread. This way we could provide much better logical > separation between variables used by different threads. Which will > (hopefully) reduce number of issues with inter-thread communications. > > commit de202e343564913e0591de10850e617d7de55b6b > Author: Alexander Chemeris > Date: Sun Jul 14 12:42:52 2013 +0400 > > Transceiver52M: Port all threads to the new Thread interface. > > Also note that we introduced shutdown() method for Transceiver threads which > implement proper shutdown of threads when they are in blocking read state. > This involves using shutdown() on sockets and pushing NULL to queues. > > With this change we should be able to start/stop transceiver channels at > arbitrary moments. > > commit 129ad76b15f1fdf0588d5a24fe2d0f7ef3df274e > Author: Alexander Chemeris > Date: Sun Jul 14 12:48:37 2013 +0400 > > Transceiver52M: Delay is no longer needed at the transceiver exit, threads should shut down cleanly. > > commit 604f65e69f2317dd5dc1aeb8faf3c107cd8a2231 > Author: Alexander Chemeris > Date: Sun Jul 14 13:22:31 2013 +0400 > > CommonLibs: Port InterthreadTest and SocketsTest to the new Thread API. > > commit c4038ef54c806c8c00f7fa28bc2b8b200bc3356f > Author: Alexander Chemeris > Date: Sun Jul 14 13:24:16 2013 +0400 > > CommonLibs: Adding a new ThreadsTest testsuite. > > It's very basic at this moment. We should add a stress-test for thread > start/stop at least. This is the meat of the branch. At this stage everything works fine, threads are shutdown properly, but power off command still doesn't power off the transceiver. > commit c0f0da4ec8e0068a562f427a89a899bf190bc74a > Author: Alexander Chemeris > Date: Sun Jul 14 23:07:31 2013 +0400 > > Transceiver52M: HACK: Exit transceiver on POWEROFF command. > > This hack allows OsmoBTS to correctly restart itself with different parameters. > We assume that transceiver is run as a service and will be restarted on exit. > > commit 806a64b1df40871543e9ae34386463d08a564147 > Author: Alexander Chemeris > Date: Sun Jul 14 22:58:55 2013 +0400 > > Transceiver52M: Start and stop all threads on POWERON/POWEROFF. > > This change reveals some issue with the UHD start/stop code. Specifically, > we get a failed assert in RadioInterface::pullBuffer() (num_rd == OUTCHUNK > with num_rd=0) with the POWERON/POWEROFF/POWERON sequence. These patches implements actual power off command. They are split into a separate branch, because they lead to assert failure I mentioned above. In my setup it's 100% reproducible. I hope you could fix that. > commit 4c39dd4b492b439742911aa70623d41ad634d7f4 > Author: Alexander Chemeris > Date: Sun Jul 14 22:45:40 2013 +0400 > > Transceiver52M: Introduce usage counting for DriveLoop and RadioInterface. > > The reason is to allow them to be started from any TRX. I.e. they are started > when the first TRX starts and stopped when the last TRX stops. This hack is a workaround for the assert failure above - it shuts down the complete transceiver in a hope that it will be restarted by external means. Meant as to be used in production while we don't have the assert failure fixed. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From ttsou at vt.edu Mon Jul 15 10:35:32 2013 From: ttsou at vt.edu (Thomas Tsou) Date: Mon, 15 Jul 2013 12:35:32 +0200 Subject: Fixing power off in osmo-trx In-Reply-To: References: Message-ID: On Sun, Jul 14, 2013 at 10:01 PM, Alexander Chemeris wrote: > I've made some progress in making osmo-trx able to power off/on > without restart. At this moment it's almost there - the only big > remaining issue I see is some bug with UHD device start/stop. It seems > we do not re-initialize it properly and assert (num_rd == OUTCHUNK) > fails. I hope you could fix that. This is a very positive patch set. As you very well know, the power on/off handling was in a ugly state. One of the remaining issue with UHD start/stop is that the device clock is reset to zero at restart, but not all of the timestamp counters are reset in radioInterface. The radioInterface is not stopped at all until deallocation since 'POWEROFF' is an empty command. I've only looked at the outer thread interface changes, but the ability to tear down individual threads (instead of uncontrolled stack unwinding) makes the remaining issues much more straightforward. There's a fair amount of old code that was probably never written with restart in mind, but I don't see any issues with cleaning that up. Thomas From alexander.chemeris at gmail.com Mon Jul 15 11:19:15 2013 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Mon, 15 Jul 2013 15:19:15 +0400 Subject: Fixing power off in osmo-trx In-Reply-To: References: Message-ID: On Mon, Jul 15, 2013 at 2:35 PM, Thomas Tsou wrote: > On Sun, Jul 14, 2013 at 10:01 PM, Alexander Chemeris > wrote: >> I've made some progress in making osmo-trx able to power off/on >> without restart. At this moment it's almost there - the only big >> remaining issue I see is some bug with UHD device start/stop. It seems >> we do not re-initialize it properly and assert (num_rd == OUTCHUNK) >> fails. I hope you could fix that. > > This is a very positive patch set. As you very well know, the power > on/off handling was in a ugly state. One of the remaining issue with > UHD start/stop is that the device clock is reset to zero at restart, > but not all of the timestamp counters are reset in radioInterface. The > radioInterface is not stopped at all until deallocation since > 'POWEROFF' is an empty command. I made an attempt to implement it in the 806a64b1 patch. If you check out this commit, you should get the assert during TURN ON/OFF/ON sequence. To start/stop transceiver I use scripts attached to this e-mail. > I've only looked at the outer thread interface changes, but the > ability to tear down individual threads (instead of uncontrolled stack > unwinding) makes the remaining issues much more straightforward. > There's a fair amount of old code that was probably never written with > restart in mind, but I don't see any issues with cleaning that up. For the old code we could use "compatibility" mode where we don't shutdown or exit on shutdown. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru -------------- next part -------------- A non-text attachment was scrubbed... Name: transceiver_send_dual_shutdown.py Type: application/octet-stream Size: 4007 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: transceiver_send_dual_start.py Type: application/octet-stream Size: 6440 bytes Desc: not available URL: From tom at tsou.cc Mon Jul 15 18:54:22 2013 From: tom at tsou.cc (Thomas Tsou) Date: Mon, 15 Jul 2013 20:54:22 +0200 Subject: Fixing power off in osmo-trx In-Reply-To: References: Message-ID: On Mon, Jul 15, 2013 at 1:19 PM, Alexander Chemeris < alexander.chemeris at gmail.com> wrote: > On Mon, Jul 15, 2013 at 2:35 PM, Thomas Tsou wrote: >> This is a very positive patch set. As you very well know, the power >> on/off handling was in a ugly state. One of the remaining issue with >> UHD start/stop is that the device clock is reset to zero at restart, >> but not all of the timestamp counters are reset in radioInterface. The >> radioInterface is not stopped at all until deallocation since >> 'POWEROFF' is an empty command. > > I made an attempt to implement it in the 806a64b1 patch. If you check > out this commit, you should get the assert during TURN ON/OFF/ON > sequence. To start/stop transceiver I use scripts attached to this > e-mail. There does seem to be something strange going on with UHD. After restart and clock reset the device is reporting time correctly, but subsequent packets do not reflect the change. We've had similar issues before due to lingering packets in the socket buffers, but the same fix (flushing buffers after issuing STREAM_MODE_STOP) doesn't fix the issue. Rx timestamp 10.3679 Rx timestamp 10.3698 ----POWEROFF---- ----POWERON---- UHD device time 0.00440694 Rx timestamp 10.3732 This may be a bug in UHD, or some oddity in the UHD streamer interface. I'm going to try it with an outside test case. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.chemeris at gmail.com Tue Jul 16 02:47:11 2013 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Tue, 16 Jul 2013 06:47:11 +0400 Subject: Fixing power off in osmo-trx In-Reply-To: References: Message-ID: On Mon, Jul 15, 2013 at 10:54 PM, Thomas Tsou wrote: > On Mon, Jul 15, 2013 at 1:19 PM, Alexander Chemeris > wrote: >> On Mon, Jul 15, 2013 at 2:35 PM, Thomas Tsou wrote: >>> This is a very positive patch set. As you very well know, the power >>> on/off handling was in a ugly state. One of the remaining issue with >>> UHD start/stop is that the device clock is reset to zero at restart, >>> but not all of the timestamp counters are reset in radioInterface. The >>> radioInterface is not stopped at all until deallocation since >>> 'POWEROFF' is an empty command. >> >> I made an attempt to implement it in the 806a64b1 patch. If you check >> out this commit, you should get the assert during TURN ON/OFF/ON >> sequence. To start/stop transceiver I use scripts attached to this >> e-mail. > > There does seem to be something strange going on with UHD. After restart and > clock reset the device is reporting time correctly, but subsequent packets > do not reflect the change. We've had similar issues before due to lingering > packets in the socket buffers, but the same fix (flushing buffers after > issuing STREAM_MODE_STOP) doesn't fix the issue. > > Rx timestamp 10.3679 > Rx timestamp 10.3698 > ----POWEROFF---- > ----POWERON---- > UHD device time 0.00440694 > Rx timestamp 10.3732 > > This may be a bug in UHD, or some oddity in the UHD streamer interface. I'm > going to try it with an outside test case. Worst case we should be able to align the transceiver clock with UHD instead of resetting UHD clock. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From jolly at eversberg.eu Mon Jul 15 08:35:30 2013 From: jolly at eversberg.eu (Andreas Eversberg) Date: Mon, 15 Jul 2013 10:35:30 +0200 Subject: [PATCH 1/7] Remove obsolete osmo-bts-bb code Message-ID: <1373877336-27883-1-git-send-email-jolly@eversberg.eu> --- configure.ac | 1 - src/Makefile.am | 2 +- src/osmo-bts-bb/Makefile.am | 8 -- src/osmo-bts-bb/l1ctl.c | 304 -------------------------------------------- src/osmo-bts-bb/main.c | 215 ------------------------------- 5 files changed, 1 insertion(+), 529 deletions(-) delete mode 100644 src/osmo-bts-bb/Makefile.am delete mode 100644 src/osmo-bts-bb/l1ctl.c delete mode 100644 src/osmo-bts-bb/main.c diff --git a/configure.ac b/configure.ac index 5abed70..1ca0dbe 100644 --- a/configure.ac +++ b/configure.ac @@ -54,7 +54,6 @@ AC_OUTPUT( src/Makefile src/common/Makefile src/osmo-bts-sysmo/Makefile -dnl src/osmo-bts-bb/Makefile include/Makefile include/osmo-bts/Makefile tests/Makefile diff --git a/src/Makefile.am b/src/Makefile.am index 92bbed9..e2eab0d 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -1,4 +1,4 @@ -SUBDIRS = common #osmo-bts-bb +SUBDIRS = common if ENABLE_SYSMOBTS SUBDIRS += osmo-bts-sysmo diff --git a/src/osmo-bts-bb/Makefile.am b/src/osmo-bts-bb/Makefile.am deleted file mode 100644 index 022931a..0000000 --- a/src/osmo-bts-bb/Makefile.am +++ /dev/null @@ -1,8 +0,0 @@ -AM_CPPFLAGS = $(all_includes) -I$(top_srcdir)/include -AM_CFLAGS = -Wall $(LIBOSMOCORE_CFLAGS) -LDADD = $(LIBOSMOCORE_LIBS) - -bin_PROGRAMS = osmo-bts-bb - -osmo_bts_bb_SOURCES = main.c -osmo_bts_bb_LDADD = $(top_builddir)/src/common/libbts.a $(LDADD) diff --git a/src/osmo-bts-bb/l1ctl.c b/src/osmo-bts-bb/l1ctl.c deleted file mode 100644 index ccba37b..0000000 --- a/src/osmo-bts-bb/l1ctl.c +++ /dev/null @@ -1,304 +0,0 @@ -/* Layer1 control code, talking L1CTL protocol with L1 on the phone */ - -/* (C) 2010 by Holger Hans Peter Freyther - * (C) 2010 by Harald Welte - * (C) 2011 by Andreas Eversberg - * - * All Rights Reserved - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; either version 2 of the License, or - * (at your option) any later version. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License along - * with this program; if not, write to the Free Software Foundation, Inc., - * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. - * - */ - -#include -#include -#include -#include - -#include - -#include - -#include -#include -#include -#include -#include -#include -#include -#include -#include - -#include -#include -#include -#include -#include -#include -#include -#include - -static struct msgb *osmo_l1_alloc(uint8_t msg_type) -{ - struct l1ctl_hdr *l1h; - struct msgb *msg = msgb_alloc_headroom(256, 4, "osmo_l1"); - - if (!msg) { - LOGP(DL1C, LOGL_ERROR, "Failed to allocate memory.\n"); - return NULL; - } - - msg->l1h = msgb_put(msg, sizeof(*l1h)); - l1h = (struct l1ctl_hdr *) msg->l1h; - l1h->msg_type = msg_type; - - return msg; -} - - -static int osmo_make_band_arfcn(struct osmocom_ms *ms, uint16_t arfcn) -{ - /* TODO: Include the band */ - return arfcn; -} - -/* Receive L1CTL_DATA_IND (Data Indication from L1) */ -int rx_ph_data_ind(struct osmocom_ms *ms, struct msgb *msg) -{ - struct l1ctl_info_dl *dl, dl_cpy; - struct l1ctl_data_ind *ccch; - struct lapdm_entity *le; - struct rx_meas_stat *meas = &ms->meas; - uint8_t chan_type, chan_ts, chan_ss; - uint8_t gsmtap_chan_type; - struct gsm_time tm; - struct osmobts_ms *bts_ms = container_of(ms, struct osmobts_ms, ms); - struct osmobts_lchan *lchan; - - if (msgb_l3len(msg) < sizeof(*ccch)) { - LOGP(DL1C, LOGL_ERROR, "MSG too short Data Ind: %u\n", - msgb_l3len(msg)); - msgb_free(msg); - return -1; - } - - dl = (struct l1ctl_info_dl *) msg->l1h; - msg->l2h = dl->payload; - ccch = (struct l1ctl_data_ind *) msg->l2h; - - gsm_fn2gsmtime(&tm, ntohl(dl->frame_nr)); - rsl_dec_chan_nr(dl->chan_nr, &chan_type, &chan_ss, &chan_ts); - lchan = bts_ms->trx->slot[chan_ts].lchan[chan_ss]; - if (!lchan) { - LOGP(DL1C, LOGL_ERROR, "Data IND for non existing lchan\n"); - msgb_free(msg); - return -1; - } - LOGP(DL1C, LOGL_NOTICE, "RX: %s | %s(%.4u/%.2u/%.2u) %d dBm\n", - rsl_chan_nr_str(dl->chan_nr), - hexdump(ccch->data, sizeof(ccch->data)), - tm.t1, tm.t2, tm.t3, (int)dl->rx_level-110); - - meas->last_fn = ntohl(dl->frame_nr); - meas->frames++; - meas->snr += dl->snr; - meas->berr += dl->num_biterr; - meas->rxlev += dl->rx_level; - - if (dl->fire_crc >= 2) { - LOGP(DL1C, LOGL_NOTICE, "Dropping frame with %u bit errors\n", - dl->num_biterr); - msgb_free(msg); - return 0; - } - - /* send CCCH data via GSMTAP */ - gsmtap_chan_type = chantype_rsl2gsmtap(chan_type, dl->link_id); - gsmtap_sendmsg(ntohs(dl->band_arfcn), chan_ts, gsmtap_chan_type, chan_ss, - tm.fn, dl->rx_level-110, dl->snr, ccch->data, - sizeof(ccch->data)); - - /* determine LAPDm entity based on SACCH or not */ - if (dl->link_id & 0x40) - le = &lchan->l2_entity.lapdm_acch; - else - le = &lchan->l2_entity.lapdm_dcch; - /* make local stack copy of l1ctl_info_dl, as LAPDm will - * overwrite skb hdr */ - memcpy(&dl_cpy, dl, sizeof(dl_cpy)); - - /* pull the L1 header from the msgb */ - msgb_pull(msg, msg->l2h - (msg->l1h-sizeof(struct l1ctl_hdr))); - msg->l1h = NULL; - - /* send it up into LAPDm */ - l2_ph_data_ind(msg, le, &dl_cpy); - - return 0; -} - -/* Receive L1CTL_DATA_CONF (Data Confirm from L1) */ -static int rx_ph_data_conf(struct osmocom_ms *ms, struct msgb *msg) -{ - struct l1ctl_info_dl *dl; - struct lapdm_entity *le; - uint8_t chan_type, chan_ts, chan_ss; - struct osmobts_ms *bts_ms = container_of(ms, struct osmobts_ms, ms); - struct osmobts_lchan *lchan; - - dl = (struct l1ctl_info_dl *) msg->l1h; - - rsl_dec_chan_nr(dl->chan_nr, &chan_type, &chan_ss, &chan_ts); - lchan = bts_ms->trx->slot[chan_ts].lchan[chan_ss]; - if (!lchan) { - LOGP(DL1C, LOGL_ERROR, "Data IND for non existing lchan\n"); - msgb_free(msg); - return -1; - } - - /* determine LAPDm entity based on SACCH or not */ - if (dl->link_id & 0x40) - le = &lchan->l2_entity.lapdm_acch; - else - le = &lchan->l2_entity.lapdm_dcch; - - /* send it up into LAPDm */ - l2_ph_data_conf(msg, le); - - return 0; -} - -/* Transmit L1CTL_DATA_REQ */ -int l1ctl_tx_data_req(struct osmocom_ms *ms, struct msgb *msg, - uint8_t chan_nr, uint8_t link_id) -{ - struct l1ctl_hdr *l1h; - struct l1ctl_info_ul *l1i_ul; - uint8_t chan_type, chan_ts, chan_ss; - uint8_t gsmtap_chan_type; - - if (msgb_l2len(msg) > GSM_MACBLOCK_LEN) { - LOGP(DL1C, LOGL_ERROR, "L1 cannot handle message length " - "> 23 (%u)\n", msgb_l2len(msg)); - msgb_free(msg); - return -EINVAL; - } else if (msgb_l2len(msg) < GSM_MACBLOCK_LEN) - LOGP(DL1C, LOGL_ERROR, "L1 message length < 23 (%u) " - "doesn't seem right!\n", msgb_l2len(msg)); - - /* send copy via GSMTAP */ - rsl_dec_chan_nr(chan_nr, &chan_type, &chan_ss, &chan_ts); - gsmtap_chan_type = chantype_rsl2gsmtap(chan_type, link_id); - gsmtap_sendmsg(0|0x4000, chan_ts, gsmtap_chan_type, chan_ss, - 0, 127, 255, msg->l2h, msgb_l2len(msg)); - - LOGP(DL1C, LOGL_NOTICE, "TX: %s | %s\n", rsl_chan_nr_str(chan_nr), - hexdump(msg->l2h, msgb_l2len(msg))); - - /* prepend uplink info header */ - l1i_ul = (struct l1ctl_info_ul *) msgb_push(msg, sizeof(*l1i_ul)); - - l1i_ul->chan_nr = chan_nr; - l1i_ul->link_id = link_id; - - /* prepend l1 header */ - msg->l1h = msgb_push(msg, sizeof(*l1h)); - l1h = (struct l1ctl_hdr *) msg->l1h; - l1h->msg_type = L1CTL_DATA_REQ; - - printf("todo: transcode message\n"); - - return osmo_send_l1(ms, msg); -} - -/* Transmit L1CTL_RESET_REQ */ -int l1ctl_tx_reset_req(struct osmocom_ms *ms, uint8_t type) -{ - struct msgb *msg; - struct l1ctl_reset *res; - - msg = osmo_l1_alloc(L1CTL_RESET_REQ); - if (!msg) - return -1; - - LOGP(DL1C, LOGL_INFO, "Tx Reset Req (%u)\n", type); - res = (struct l1ctl_reset *) msgb_put(msg, sizeof(*res)); - res->type = type; - - return osmo_send_l1(ms, msg); -} - -/* Receive L1CTL_RESET_IND */ -static int rx_l1_reset(struct osmocom_ms *ms) -{ - LOGP(DL1C, LOGL_INFO, "Layer1 Reset indication\n"); - dispatch_signal(SS_L1CTL, S_L1CTL_RESET, ms); - - return 0; -} - -/* Receive incoming data from L1 using L1CTL format */ -int l1ctl_recv(struct osmocom_ms *ms, struct msgb *msg) -{ - int rc = 0; - struct l1ctl_hdr *l1h; - struct l1ctl_info_dl *dl; - - if (msgb_l2len(msg) < sizeof(*dl)) { - LOGP(DL1C, LOGL_ERROR, "Short Layer2 message: %u\n", - msgb_l2len(msg)); - msgb_free(msg); - return -1; - } - - l1h = (struct l1ctl_hdr *) msg->l1h; - - /* move the l1 header pointer to point _BEHIND_ l1ctl_hdr, - as the l1ctl header is of no interest to subsequent code */ - msg->l1h = l1h->data; - - switch (l1h->msg_type) { - case L1CTL_DATA_IND: - rc = rx_ph_data_ind(ms, msg); - break; - case L1CTL_DATA_CONF: - rc = rx_ph_data_conf(ms, msg); - break; - case L1CTL_RESET_IND: - case L1CTL_RESET_CONF: - rc = rx_l1_reset(ms); - msgb_free(msg); - break; - default: - LOGP(DL1C, LOGL_ERROR, "Unknown MSG: %u\n", l1h->msg_type); - msgb_free(msg); - break; - } - - return rc; -} - -int l1ctl_tx_param_req(struct osmocom_ms *ms, uint8_t ta, uint8_t tx_power) -{ - return -ENOTSUP; -} - -int l1ctl_tx_rach_req(struct osmocom_ms *ms, uint8_t ra, uint16_t offset, - uint8_t combined) -{ - return -ENOTSUP; -} - - diff --git a/src/osmo-bts-bb/main.c b/src/osmo-bts-bb/main.c deleted file mode 100644 index 7300b68..0000000 --- a/src/osmo-bts-bb/main.c +++ /dev/null @@ -1,215 +0,0 @@ -/* (C) 2011 by Andreas Eversberg - * - * All Rights Reserved - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; either version 2 of the License, or - * (at your option) any later version. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License along - * with this program; if not, write to the Free Software Foundation, Inc., - * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. - * - */ - -#include -#include -#include -#include -#include -#include -//#include -#include -#include -#include -#include - -#include - -#define _GNU_SOURCE -#include -#include -#include -#include -#include -#include -#include -#include - -struct log_target *stderr_target; -char *debugs = "DL1C:DLAPDM:DABIS:DOML:DRSL:DSUM"; - -void *l23_ctx = NULL; -static struct osmocom_bts *bts; -int debug_set = 0; -char *software_version = "0.0"; -uint8_t abis_mac[6] = { 0, 1, 2, 3, 4, 5 }; -char *bsc_host = "localhost"; -char *bts_id = "1801/0"; -int quit = 0; - -// FIXME this is a hack -static void get_mac(void) -{ - struct if_nameindex *ifn = if_nameindex(); - struct ifreq ifr; - int sock; - int ret; - - sock = socket(AF_INET, SOCK_STREAM, 0); - if (sock < 0) - return; - - memset(&ifr, 0, sizeof(ifr)); - if (!ifn) - return; - while (ifn->if_name) { - strncpy(ifr.ifr_name, ifn->if_name, sizeof(ifr.ifr_name)-1); - ret = ioctl(sock, SIOCGIFHWADDR, &ifr); - if (ret == 0 && !!memcmp(ifr.ifr_hwaddr.sa_data, - "\0\0\0\0\0\0", 6)) { - memcpy(abis_mac, ifr.ifr_hwaddr.sa_data, 6); - printf("Using MAC address of %s: " - "'%02x:%02x:%02x:%02x:%02x:%02x'\n", - ifn->if_name, - abis_mac[0], abis_mac[1], abis_mac[2], - abis_mac[3], abis_mac[4], abis_mac[5]); - break; - } - ifn++; - } -// if_freenameindex(ifn); -} - -static void print_usage(const char *app) -{ - printf("Usage: %s [option]\n", app); - printf(" -h --help this text\n"); - printf(" -d --debug Change debug flags. (-d %s)\n", debugs); - printf(" -i --bsc-ip IP address of the BSC\n"); -} - -static void handle_options(int argc, char **argv) -{ - while (1) { - int option_index = 0, c; - static struct option long_options[] = { - {"help", 0, 0, 'h'}, - {"debug", 1, 0, 'd'}, - {"bsc-ip", 1, 0, 'i'}, - {0, 0, 0, 0}, - }; - - c = getopt_long(argc, argv, "hd:i:", - long_options, &option_index); - if (c == -1) - break; - - switch (c) { - case 'h': - print_usage(argv[0]); - exit(0); - case 'd': - log_parse_category_mask(stderr_target, optarg); - debug_set = 1; - break; - case 'i': - bsc_host = strdup(optarg); - break; - default: - break; - } - } -} - -void sighandler(int sigset) -{ - if (sigset == SIGHUP || sigset == SIGPIPE) - return; - - fprintf(stderr, "Signal %d recevied.\n", sigset); - - /* in case there is a lockup during exit */ - signal(SIGINT, SIG_DFL); - signal(SIGHUP, SIG_DFL); - signal(SIGTERM, SIG_DFL); - signal(SIGPIPE, SIG_DFL); - - quit = 1; -// dispatch_signal(SS_GLOBAL, S_GLOBAL_SHUTDOWN, NULL); -} - -int main(int argc, char **argv) -{ - int ret; - struct hostent *hostent; - struct in_addr *ina; - uint32_t bsc_ip; - uint8_t maskv_tx[2], maskv_rx[2]; - - printf("((*))\n"); - printf(" |\n"); - printf(" / \\ OsmoBTS\n"); - - get_mac(); - bts_support_init(); - - srand(time(NULL)); - - log_init(&log_info); - stderr_target = log_target_create_stderr(); - log_add_target(stderr_target); - log_set_all_filter(stderr_target, 1); - - l23_ctx = talloc_named_const(NULL, 1, "layer2 context"); - - handle_options(argc, argv); - - if (!debug_set) - log_parse_category_mask(stderr_target, debugs); - log_set_log_level(stderr_target, LOGL_INFO); - - hostent = gethostbyname(bsc_host); - if (!hostent) { - fprintf(stderr, "Failed to resolve BSC hostname '%s'.\n", - bsc_host); - } - ina = (struct in_addr *) hostent->h_addr; - bsc_ip = ntohl(ina->s_addr); - printf("Using BSC at IP: '%d.%d.%d.%d'\n", bsc_ip >> 24, - (bsc_ip >> 16) & 0xff, (bsc_ip >> 8) & 0xff, bsc_ip & 0xff); - - printf("Using BTS ID: '%s'\n", bts_id); - bts = create_bts(1, bts_id); - if (!bts) - exit(-1); - maskv_tx[0] = 0x55; - maskv_rx[0] = 0x55; - ret = create_ms(bts->trx[0], 1, maskv_tx, maskv_rx); - if (ret < 0) - goto fail; - ret = abis_open(&bts->link, bsc_ip); - if (ret < 0) - goto fail; - - signal(SIGINT, sighandler); - signal(SIGHUP, sighandler); - signal(SIGTERM, sighandler); - signal(SIGPIPE, sighandler); - - while (!quit) { - work_bts(bts); - osmo_select_main(0); - } - -fail: - destroy_bts(bts); - - return 0; -} -- 1.8.1.5 From jolly at eversberg.eu Mon Jul 15 08:35:31 2013 From: jolly at eversberg.eu (Andreas Eversberg) Date: Mon, 15 Jul 2013 10:35:31 +0200 Subject: [PATCH 2/7] Add PH-/MPH-/TCH-SAP interface to common part of osmo-bts In-Reply-To: <1373877336-27883-1-git-send-email-jolly@eversberg.eu> References: <1373877336-27883-1-git-send-email-jolly@eversberg.eu> Message-ID: <1373877336-27883-2-git-send-email-jolly@eversberg.eu> Instead of handling primitives directly at layer 1 specific code, osmo-bts handles primitives at common code. Therefore a new file 'l1sap.c' is added and integrated. The l1sap.c file: - receives PH-DATA indications and forwards them to layer 2. - checks for RF link loss and notifies BSC. - receives TCH indications and forwards them via RTP. - receives PH-RTS indications and sends PH-DATA requests with content according to its logical channel. - receives TCH-RTS indications and sends TCH requests with content received via RTP or loopback from TCH indications. - send MPH-INFO requests to activate, deactivate and modify logical channels and handles their confirms. - receives MPH-INFO indications with measurements from tranceiver. - forwards received and transmitted PH-DATA to GSMTAP. Therefore some obsolete bts_model_* calls have been replaced by bts_model_l1sap_down to send primitves down to layer 1 specific code. --- include/osmo-bts/bts.h | 2 + include/osmo-bts/bts_model.h | 12 +- include/osmo-bts/gsm_data.h | 1 + include/osmo-bts/l1sap.h | 71 +++ include/osmo-bts/rsl.h | 2 +- include/osmo-bts/vty.h | 4 +- src/common/Makefile.am | 2 +- src/common/bts.c | 8 + src/common/l1sap.c | 948 ++++++++++++++++++++++++++++++++++++++ src/common/logging.c | 4 +- src/common/measurement.c | 5 + src/common/pcu_sock.c | 15 +- src/common/rsl.c | 29 +- src/common/vty.c | 131 +++++- src/osmo-bts-sysmo/l1_if.c | 6 + src/osmo-bts-sysmo/main.c | 2 +- src/osmo-bts-sysmo/oml.c | 4 +- src/osmo-bts-sysmo/sysmobts_vty.c | 27 -- tests/stubs.c | 3 + 19 files changed, 1204 insertions(+), 72 deletions(-) create mode 100644 include/osmo-bts/l1sap.h create mode 100644 src/common/l1sap.c diff --git a/include/osmo-bts/bts.h b/include/osmo-bts/bts.h index 583c1eb..6b91c82 100644 --- a/include/osmo-bts/bts.h +++ b/include/osmo-bts/bts.h @@ -27,5 +27,7 @@ int lchan_init_lapdm(struct gsm_lchan *lchan); void load_timer_start(struct gsm_bts *bts); +struct gsm_time *get_time(struct gsm_bts *bts); + #endif /* _BTS_H */ diff --git a/include/osmo-bts/bts_model.h b/include/osmo-bts/bts_model.h index bfa6bd8..3b2855a 100644 --- a/include/osmo-bts/bts_model.h +++ b/include/osmo-bts/bts_model.h @@ -12,8 +12,6 @@ int bts_model_init(struct gsm_bts *bts); -struct gsm_time *bts_model_get_time(struct gsm_bts *bts); - int bts_model_check_oml(struct gsm_bts *bts, uint8_t msg_type, struct tlv_parsed *old_attr, struct tlv_parsed *new_attr, void *obj); @@ -27,20 +25,14 @@ int bts_model_opstart(struct gsm_bts *bts, struct gsm_abis_mo *mo, int bts_model_chg_adm_state(struct gsm_bts *bts, struct gsm_abis_mo *mo, void *obj, uint8_t adm_state); -int bts_model_rsl_chan_act(struct gsm_lchan *lchan, struct tlv_parsed *tp); -int bts_model_rsl_chan_rel(struct gsm_lchan *lchan); -int bts_model_rsl_deact_sacch(struct gsm_lchan *lchan); -int bts_model_rsl_mode_modify(struct gsm_lchan *lchan); - int bts_model_trx_deact_rf(struct gsm_bts_trx *trx); int bts_model_trx_close(struct gsm_bts_trx *trx); -void bts_model_rtp_rx_cb(struct osmo_rtp_socket *rs, const uint8_t *rtp_pl, - unsigned int rtp_pl_len); - int bts_model_vty_init(struct gsm_bts *bts); void bts_model_config_write_bts(struct vty *vty, struct gsm_bts *bts); void bts_model_config_write_trx(struct vty *vty, struct gsm_bts_trx *trx); +int bts_model_l1sap_down(struct gsm_bts_trx *trx, struct osmo_phsap_prim *l1sap); + #endif diff --git a/include/osmo-bts/gsm_data.h b/include/osmo-bts/gsm_data.h index c6cd7e4..980f8ef 100644 --- a/include/osmo-bts/gsm_data.h +++ b/include/osmo-bts/gsm_data.h @@ -58,6 +58,7 @@ struct gsm_bts_role_bts { struct { uint8_t tc4_ctr; } si; + struct gsm_time gsm_time; uint8_t radio_link_timeout; /* used by the sysmoBTS to adjust band */ diff --git a/include/osmo-bts/l1sap.h b/include/osmo-bts/l1sap.h new file mode 100644 index 0000000..a1dc303 --- /dev/null +++ b/include/osmo-bts/l1sap.h @@ -0,0 +1,71 @@ +#ifndef L1SAP_H +#define L1SAP_H + +/* timeslot and subslot from chan_nr */ +#define L1SAP_CHAN2TS(chan_nr) (chan_nr & 7) +#define L1SAP_CHAN2SS_TCHH(chan_nr) ((chan_nr >> 3) & 1) +#define L1SAP_CHAN2SS_SDCCH4(chan_nr) ((chan_nr >> 3) & 3) +#define L1SAP_CHAN2SS_SDCCH8(chan_nr) ((chan_nr >> 3) & 7) + +/* logical channel from chan_nr + link_id */ +#define L1SAP_IS_LINK_SACCH(link_id) ((link_id & 0xC0) == 0x40) +#define L1SAP_IS_CHAN_TCHF(chan_nr) ((chan_nr & 0xf8) == 0x08) +#define L1SAP_IS_CHAN_TCHH(chan_nr) ((chan_nr & 0xf0) == 0x10) +#define L1SAP_IS_CHAN_SDCCH4(chan_nr) ((chan_nr & 0xe0) == 0x20) +#define L1SAP_IS_CHAN_SDCCH8(chan_nr) ((chan_nr & 0xc0) == 0x40) +#define L1SAP_IS_CHAN_BCCH(chan_nr) ((chan_nr & 0xf8) == 0x80) +#define L1SAP_IS_CHAN_RACH(chan_nr) ((chan_nr & 0xf8) == 0x88) +#define L1SAP_IS_CHAN_AGCH_PCH(chan_nr) ((chan_nr & 0xf8) == 0x90) + +/* rach type from ra */ +#define L1SAP_IS_PACKET_RACH(ra) ((ra & 0xf0) == 0x70) + +/* CCCH block from frame number */ +#define L1SAP_FN2CCCHBLOCK(fn) ((fn % 51) / 5 - 1) + +/* PTCH layout from frame number */ +#define L1SAP_FN2MACBLOCK(fn) ((fn % 52) / 4) +#define L1SAP_FN2PTCCHBLOCK(fn) ((fn / 52) & 7) +#define L1SAP_IS_PTCCH(fn) ((fn % 52) == 12) + +/* subslot from any chan_nr */ +static inline uint8_t l1sap_chan2ss(uint8_t chan_nr) +{ + if (L1SAP_IS_CHAN_SDCCH8(chan_nr)) + return L1SAP_CHAN2SS_SDCCH8(chan_nr); + if (L1SAP_IS_CHAN_SDCCH4(chan_nr)) + return L1SAP_CHAN2SS_SDCCH4(chan_nr); + if (L1SAP_IS_CHAN_TCHH(chan_nr)) + return L1SAP_CHAN2SS_TCHH(chan_nr); + return 0; +} + + +/* allocate a msgb containing a osmo_phsap_prim + optional l2 data */ +struct msgb *l1sap_msgb_alloc(unsigned int l2_len); + +/* any L1 prim received from bts model */ +int l1sap_up(struct gsm_bts_trx *trx, struct osmo_phsap_prim *l1sap); + +/* pcu (socket interface) sends us a data request primitive */ +int l1sap_pdch_req(struct gsm_bts_trx_ts *ts, int is_ptcch, uint32_t fn, + uint16_t arfcn, uint8_t block_nr, uint8_t *data, uint8_t len); + +/* call-back function for incoming RTP */ +void l1sap_rtp_rx_cb(struct osmo_rtp_socket *rs, const uint8_t *rtp_pl, + unsigned int rtp_pl_len); + +/* channel control */ +int l1sap_chan_act(struct gsm_bts_trx *trx, uint8_t chan_nr); +int l1sap_chan_rel(struct gsm_bts_trx *trx, uint8_t chan_nr); +int l1sap_chan_deact_sacch(struct gsm_bts_trx *trx, uint8_t chan_nr); +int l1sap_chan_modify(struct gsm_bts_trx *trx, uint8_t chan_nr); + +extern const struct value_string gsmtap_sapi_names[]; +extern struct gsmtap_inst *gsmtap; +extern uint32_t gsmtap_sapi_mask; +extern uint8_t gsmtap_sapi_acch; + +#define msgb_l1sap_prim(msg) ((struct osmo_phsap_prim *)(msg)->l1h) + +#endif /* L1SAP_H */ diff --git a/include/osmo-bts/rsl.h b/include/osmo-bts/rsl.h index 251cd23..eae7845 100644 --- a/include/osmo-bts/rsl.h +++ b/include/osmo-bts/rsl.h @@ -7,7 +7,7 @@ int rsl_tx_chan_rqd(struct gsm_bts_trx *trx, struct gsm_time *gtime, uint8_t ra, uint8_t acc_delay); int rsl_tx_est_ind(struct gsm_lchan *lchan, uint8_t link_id, uint8_t *data, int len); -int rsl_tx_chan_act_ack(struct gsm_lchan *lchan, struct gsm_time *gtime); +int rsl_tx_chan_act_ack(struct gsm_lchan *lchan); int rsl_tx_chan_act_nack(struct gsm_lchan *lchan, uint8_t cause); int rsl_tx_conn_fail(struct gsm_lchan *lchan, uint8_t cause); int rsl_tx_rf_rel_ack(struct gsm_lchan *lchan); diff --git a/include/osmo-bts/vty.h b/include/osmo-bts/vty.h index 1bc7e71..9b113a8 100644 --- a/include/osmo-bts/vty.h +++ b/include/osmo-bts/vty.h @@ -15,8 +15,10 @@ extern struct cmd_element ournode_end_cmd; enum node_type bts_vty_go_parent(struct vty *vty); int bts_vty_is_config_node(struct vty *vty, int node); -int bts_vty_init(const struct log_info *cat); +int bts_vty_init(struct gsm_bts *bts, const struct log_info *cat); extern struct vty_app_info bts_vty_info; +char *osmo_str_tolower(const char *in); + #endif diff --git a/src/common/Makefile.am b/src/common/Makefile.am index b2f6f8e..1c6ff9e 100644 --- a/src/common/Makefile.am +++ b/src/common/Makefile.am @@ -5,4 +5,4 @@ LDADD = $(LIBOSMOCORE_LIBS) $(LIBOSMOTRAU_LIBS) noinst_LIBRARIES = libbts.a libbts_a_SOURCES = gsm_data_shared.c sysinfo.c logging.c abis.c oml.c bts.c \ rsl.c vty.c paging.c measurement.c amr.c lchan.c \ - load_indication.c pcu_sock.c + load_indication.c pcu_sock.c l1sap.c diff --git a/src/common/bts.c b/src/common/bts.c index e899ebd..c495fcd 100644 --- a/src/common/bts.c +++ b/src/common/bts.c @@ -239,3 +239,11 @@ int bts_supports_cipher(struct gsm_bts_role_bts *bts, int rsl_cipher) sup = (1 << (rsl_cipher - 2)) & bts->support.ciphers; return sup > 0; } + +struct gsm_time *get_time(struct gsm_bts *bts) +{ + struct gsm_bts_role_bts *btsb = bts->role; + + return &btsb->gsm_time; +} + diff --git a/src/common/l1sap.c b/src/common/l1sap.c new file mode 100644 index 0000000..ad833ea --- /dev/null +++ b/src/common/l1sap.c @@ -0,0 +1,948 @@ +/* L1 SAP primitives */ + +/* (C) 2011 by Harald Welte + * (C) 2013 by Andreas Eversberg + * + * All Rights Reserved + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU Affero General Public License as published by + * the Free Software Foundation; either version 3 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU Affero General Public License + * along with this program. If not, see . + * + */ + +#include +#include +#include +#include + +#include +#include + +#include +#include +#include +#include +#include + +#include + +#include +#include +#include +#include +#include +#include +#include +#include + +static int l1sap_down(struct gsm_bts_trx *trx, struct osmo_phsap_prim *l1sap); + +static const uint8_t fill_frame[GSM_MACBLOCK_LEN] = { + 0x03, 0x03, 0x01, 0x2B, 0x2B, 0x2B, 0x2B, 0x2B, 0x2B, 0x2B, + 0x2B, 0x2B, 0x2B, 0x2B, 0x2B, 0x2B, 0x2B, 0x2B, 0x2B, 0x2B, + 0x2B, 0x2B, 0x2B +}; + +/* allocate a msgb containing a osmo_phsap_prim + optional l2 data */ +struct msgb *l1sap_msgb_alloc(unsigned int l2_len) +{ + struct msgb *msg = msgb_alloc(sizeof(struct osmo_phsap_prim) + l2_len, + "l1sap_prim"); + + if (!msg) + return NULL; + + msg->l1h = msgb_put(msg, sizeof(struct osmo_phsap_prim)); + + return msg; +} + +static int l1sap_tx_ciph_req(struct gsm_bts_trx *trx, uint8_t chan_nr, + uint8_t downlink, uint8_t uplink) +{ + struct osmo_phsap_prim l1sap_ciph; + + osmo_prim_init(&l1sap_ciph.oph, SAP_GSM_PH, PRIM_MPH_INFO, + PRIM_OP_REQUEST, NULL); + l1sap_ciph.u.info.type = PRIM_INFO_ACT_CIPH; + l1sap_ciph.u.info.u.ciph_req.chan_nr = chan_nr; + l1sap_ciph.u.info.u.ciph_req.downlink = downlink; + l1sap_ciph.u.info.u.ciph_req.uplink = uplink; + + return l1sap_down(trx, &l1sap_ciph); +} + + +/* check if the message is a GSM48_MT_RR_CIPH_M_CMD, and if yes, enable + * uni-directional de-cryption on the uplink. We need this ugly layering + * violation as we have no way of passing down L3 metadata (RSL CIPHERING CMD) + * to this point in L1 */ +static int check_for_ciph_cmd(struct msgb *msg, struct gsm_lchan *lchan, + uint8_t chan_nr) +{ + + /* only do this if we are in the right state */ + switch (lchan->ciph_state) { + case LCHAN_CIPH_NONE: + case LCHAN_CIPH_RX_REQ: + break; + default: + return 0; + } + + /* First byte (Address Field) of LAPDm header) */ + if (msg->data[0] != 0x03) + return 0; + /* First byte (protocol discriminator) of RR */ + if ((msg->data[3] & 0xF) != GSM48_PDISC_RR) + return 0; + /* 2nd byte (msg type) of RR */ + if ((msg->data[4] & 0x3F) != GSM48_MT_RR_CIPH_M_CMD) + return 0; + + l1sap_tx_ciph_req(lchan->ts->trx, chan_nr, 0, 1); + + return 1; +} + +struct gsmtap_inst *gsmtap = NULL; +uint32_t gsmtap_sapi_mask = 0; +uint8_t gsmtap_sapi_acch = 0; + +const struct value_string gsmtap_sapi_names[] = { + { GSMTAP_CHANNEL_BCCH, "BCCH" }, + { GSMTAP_CHANNEL_CCCH, "CCCH" }, + { GSMTAP_CHANNEL_RACH, "RACH" }, + { GSMTAP_CHANNEL_AGCH, "AGCH" }, + { GSMTAP_CHANNEL_PCH, "PCH" }, + { GSMTAP_CHANNEL_SDCCH, "SDCCH" }, + { GSMTAP_CHANNEL_TCH_F, "TCH/F" }, + { GSMTAP_CHANNEL_TCH_H, "TCH/H" }, + { GSMTAP_CHANNEL_PACCH, "PACCH" }, + { GSMTAP_CHANNEL_PDCH, "PDTCH" }, + { GSMTAP_CHANNEL_PTCCH, "PTCCH" }, + { GSMTAP_CHANNEL_CBCH51,"CBCH" }, + { GSMTAP_CHANNEL_ACCH, "SACCH" }, + { 0, NULL } +}; + +static int to_gsmtap(struct gsm_bts_trx *trx, struct osmo_phsap_prim *l1sap) +{ + struct msgb *msg = l1sap->oph.msg; + uint8_t *data; + int len; + uint8_t chan_type = 0, tn = 0, ss = 0; + uint32_t fn; + uint8_t chan_nr, link_id; + uint16_t uplink = GSMTAP_ARFCN_F_UPLINK; + + if (!gsmtap) + return 0; + + switch (OSMO_PRIM_HDR(&l1sap->oph)) { + case OSMO_PRIM(PRIM_PH_DATA, PRIM_OP_REQUEST): + uplink = 0; + /* fall through */ + case OSMO_PRIM(PRIM_PH_DATA, PRIM_OP_INDICATION): + data = msg->data + sizeof(struct osmo_phsap_prim); + len = msg->len - sizeof(struct osmo_phsap_prim); + fn = l1sap->u.data.fn; + tn = L1SAP_CHAN2TS(l1sap->u.data.chan_nr); + chan_nr = l1sap->u.data.chan_nr; + link_id = l1sap->u.data.link_id; + if (L1SAP_IS_CHAN_TCHF(chan_nr)) { + if (trx->ts[tn].pchan == GSM_PCHAN_PDCH) { + if (L1SAP_IS_PTCCH(fn)) { + chan_type = GSMTAP_CHANNEL_PTCCH; + ss = L1SAP_FN2PTCCHBLOCK(fn); + if (l1sap->oph.primitive + == PRIM_OP_INDICATION) { + if (data[0] == 7) + return -EINVAL; + data++; + len--; + } + } else { + chan_type = GSMTAP_CHANNEL_PACCH; + } + } else + chan_type = GSMTAP_CHANNEL_TCH_F; + } else if (L1SAP_IS_CHAN_TCHH(chan_nr)) { + ss = L1SAP_CHAN2SS_TCHH(chan_nr); + chan_type = GSMTAP_CHANNEL_TCH_H; + } else if (L1SAP_IS_CHAN_SDCCH4(chan_nr)) { + ss = L1SAP_CHAN2SS_SDCCH4(chan_nr); + chan_type = GSMTAP_CHANNEL_SDCCH; + } else if (L1SAP_IS_CHAN_SDCCH8(chan_nr)) { + ss = L1SAP_CHAN2SS_SDCCH8(chan_nr); + chan_type = GSMTAP_CHANNEL_SDCCH; + } else if (L1SAP_IS_CHAN_BCCH(chan_nr)) { + chan_type = GSMTAP_CHANNEL_BCCH; + } else if (L1SAP_IS_CHAN_AGCH_PCH(chan_nr)) { +#warning Set BS_AG_BLKS_RES + /* The sapi depends on DSP configuration, not + * on the actual SYSTEM INFORMATION 3. */ + if (L1SAP_FN2CCCHBLOCK(fn) >= 1) + chan_type = GSMTAP_CHANNEL_PCH; + else + chan_type = GSMTAP_CHANNEL_AGCH; + } + if (L1SAP_IS_LINK_SACCH(link_id)) + chan_type |= GSMTAP_CHANNEL_ACCH; + break; + case OSMO_PRIM(PRIM_PH_RACH, PRIM_OP_INDICATION): + chan_type = GSMTAP_CHANNEL_RACH; + fn = l1sap->u.rach_ind.fn; + tn = L1SAP_CHAN2TS(l1sap->u.rach_ind.chan_nr); + chan_nr = l1sap->u.rach_ind.chan_nr; + if (L1SAP_IS_CHAN_TCHH(chan_nr)) + ss = L1SAP_CHAN2SS_TCHH(chan_nr); + else if (L1SAP_IS_CHAN_SDCCH4(chan_nr)) + ss = L1SAP_CHAN2SS_SDCCH4(chan_nr); + else if (L1SAP_IS_CHAN_SDCCH8(chan_nr)) + ss = L1SAP_CHAN2SS_SDCCH8(chan_nr); + data = &l1sap->u.rach_ind.ra; + len = 1; + break; + default: + return -ENOTSUP; + } + + if (len == 0) + return 0; + if ((chan_type & GSMTAP_CHANNEL_ACCH)) { + if (!gsmtap_sapi_acch) + return 0; + } else { + if (!((1 << (chan_type & 31)) & gsmtap_sapi_mask)) + return 0; + } + + gsmtap_send(gsmtap, trx->arfcn | uplink, tn, chan_type, ss, fn, 0, 0, + data, len); + + return 0; +} + +/* time information received from bts model */ +static int l1sap_info_time_ind(struct gsm_bts_trx *trx, + struct osmo_phsap_prim *l1sap, + struct info_time_ind_param *info_time_ind) +{ + struct gsm_bts *bts = trx->bts; + struct gsm_bts_role_bts *btsb = bts->role; + + DEBUGP(DL1P, "MPH_INFO time ind %u\n", info_time_ind->fn); + + /* Update our data structures with the current GSM time */ + gsm_fn2gsmtime(&btsb->gsm_time, info_time_ind->fn); + + /* Update time on PCU interface */ + pcu_tx_time_ind(info_time_ind->fn); + + /* check if the measurement period of some lchan has ended + * and pre-compute the respective measurement */ + trx_meas_check_compute(trx, info_time_ind->fn - 1); + + /* increment 'total' for every possible rach */ + if (bts->c0->ts[0].pchan != GSM_PCHAN_CCCH_SDCCH4 + || (info_time_ind->fn % 51) < 27) + btsb->load.rach.total++; + + return 0; +} + +/* measurement information received from bts model */ +static int l1sap_info_meas_ind(struct gsm_bts_trx *trx, + struct osmo_phsap_prim *l1sap, + struct info_meas_ind_param *info_meas_ind) +{ + struct bts_ul_meas ulm; + struct gsm_lchan *lchan; + + DEBUGP(DL1P, "MPH_INFO meas ind chan_nr=%02x\n", + info_meas_ind->chan_nr); + + lchan = &trx->ts[L1SAP_CHAN2TS(info_meas_ind->chan_nr)] + .lchan[l1sap_chan2ss(info_meas_ind->chan_nr)]; + + /* in the GPRS case we are not interested in measurement + * processing. The PCU will take care of it */ + if (lchan->type == GSM_LCHAN_PDTCH) + return 0; + + memset(&ulm, 0, sizeof(ulm)); + ulm.ta_offs_qbits = info_meas_ind->ta_offs_qbits; + ulm.ber10k = info_meas_ind->ber10k; + ulm.inv_rssi = info_meas_ind->inv_rssi; + + lchan_new_ul_meas(lchan, &ulm); + + return 0; +} + +/* any L1 MPH_INFO indication prim recevied from bts model */ +static int l1sap_mph_info_ind(struct gsm_bts_trx *trx, + struct osmo_phsap_prim *l1sap, struct mph_info_param *info) +{ + int rc = 0; + + switch (info->type) { + case PRIM_INFO_TIME: + rc = l1sap_info_time_ind(trx, l1sap, &info->u.time_ind); + break; + case PRIM_INFO_MEAS: + rc = l1sap_info_meas_ind(trx, l1sap, &info->u.meas_ind); + break; + default: + LOGP(DL1P, LOGL_NOTICE, "unknown MPH_INFO ind type %d\n", + info->type); + break; + } + + return rc; +} + +/* activation confirm received from bts model */ +static int l1sap_info_act_cnf(struct gsm_bts_trx *trx, + struct osmo_phsap_prim *l1sap, + struct info_act_cnf_param *info_act_cnf) +{ + struct gsm_lchan *lchan; + + LOGP(DL1P, LOGL_INFO, "activate confirm chan_nr=%02x trx=%d\n", + info_act_cnf->chan_nr, trx->nr); + + lchan = &trx->ts[L1SAP_CHAN2TS(info_act_cnf->chan_nr)] + .lchan[l1sap_chan2ss(info_act_cnf->chan_nr)]; + + if (info_act_cnf->cause) + rsl_tx_chan_act_nack(lchan, info_act_cnf->cause); + else + rsl_tx_chan_act_ack(lchan); + + return 0; +} + +/* activation confirm received from bts model */ +static int l1sap_info_rel_cnf(struct gsm_bts_trx *trx, + struct osmo_phsap_prim *l1sap, + struct info_act_cnf_param *info_act_cnf) +{ + struct gsm_lchan *lchan; + + LOGP(DL1P, LOGL_INFO, "deactivate confirm chan_nr=%02x trx=%d\n", + info_act_cnf->chan_nr, trx->nr); + + lchan = &trx->ts[L1SAP_CHAN2TS(info_act_cnf->chan_nr)] + .lchan[l1sap_chan2ss(info_act_cnf->chan_nr)]; + + rsl_tx_rf_rel_ack(lchan); + + return 0; +} + +/* any L1 MPH_INFO confirm prim recevied from bts model */ +static int l1sap_mph_info_cnf(struct gsm_bts_trx *trx, + struct osmo_phsap_prim *l1sap, struct mph_info_param *info) +{ + int rc = 0; + + switch (info->type) { + case PRIM_INFO_ACTIVATE: + rc = l1sap_info_act_cnf(trx, l1sap, &info->u.act_cnf); + break; + case PRIM_INFO_DEACTIVATE: + rc = l1sap_info_rel_cnf(trx, l1sap, &info->u.act_cnf); + break; + default: + LOGP(DL1P, LOGL_NOTICE, "unknown MPH_INFO cnf type %d\n", + info->type); + break; + } + + return rc; +} + +/* PH-RTS-IND prim recevied from bts model */ +static int l1sap_ph_rts_ind(struct gsm_bts_trx *trx, + struct osmo_phsap_prim *l1sap, struct ph_data_param *rts_ind) +{ + struct msgb *msg = l1sap->oph.msg; + struct gsm_time g_time; + struct gsm_lchan *lchan; + uint8_t chan_nr, link_id; + uint8_t tn, ss; + uint32_t fn; + uint8_t *p, *si; + struct lapdm_entity *le; + struct osmo_phsap_prim pp; + int rc; + + chan_nr = rts_ind->chan_nr; + link_id = rts_ind->link_id; + fn = rts_ind->fn; + tn = L1SAP_CHAN2TS(chan_nr); + + gsm_fn2gsmtime(&g_time, fn); + + DEBUGP(DL1P, "Rx PH-RTS.ind %02u/%02u/%02u chan_nr=%d link_id=%d\n", + g_time.t1, g_time.t2, g_time.t3, chan_nr, link_id); + + if (trx->ts[tn].pchan == GSM_PCHAN_PDCH) { + if (L1SAP_IS_PTCCH(rts_ind->fn)) { + pcu_tx_rts_req(&trx->ts[tn], 1, fn, 1 /* ARFCN */, + L1SAP_FN2PTCCHBLOCK(fn)); + + return 0; + } + pcu_tx_rts_req(&trx->ts[tn], 0, fn, 0 /* ARFCN */, + L1SAP_FN2MACBLOCK(fn)); + + return 0; + } + + /* reuse PH-RTS.ind for PH-DATA.req */ + if (!msg) { + LOGP(DL1P, LOGL_FATAL, "RTS without msg to be reused. Please " + "fix!\n"); + abort(); + } + msgb_trim(msg, sizeof(*l1sap)); + osmo_prim_init(&l1sap->oph, SAP_GSM_PH, PRIM_PH_DATA, PRIM_OP_REQUEST, + msg); + msg->l2h = msg->l1h + sizeof(*l1sap); + + if (L1SAP_IS_CHAN_BCCH(chan_nr)) { + p = msgb_put(msg, GSM_MACBLOCK_LEN); + /* get them from bts->si_buf[] */ + si = bts_sysinfo_get(trx->bts, &g_time); + if (si) + memcpy(p, si, GSM_MACBLOCK_LEN); + else + memcpy(p, fill_frame, GSM_MACBLOCK_LEN); + } else if (!(chan_nr & 0x80)) { /* only TCH/F, TCH/H, SDCCH/4 and SDCCH/8 have C5 bit cleared */ + if (L1SAP_IS_CHAN_TCHH(chan_nr)) + ss = L1SAP_CHAN2SS_TCHH(chan_nr); /* TCH/H */ + else if (L1SAP_IS_CHAN_SDCCH4(chan_nr)) + ss = L1SAP_CHAN2SS_SDCCH4(chan_nr); /* SDCCH/4 */ + else if (L1SAP_IS_CHAN_SDCCH8(chan_nr)) + ss = L1SAP_CHAN2SS_SDCCH8(chan_nr); /* SDCCH/8 */ + else + ss = 0; /* TCH/F */ + lchan = &trx->ts[tn].lchan[ss]; + if (L1SAP_IS_LINK_SACCH(link_id)) { + p = msgb_put(msg, GSM_MACBLOCK_LEN); + /* L1-header, if not set/modified by layer 1 */ + p[0] = lchan->ms_power; + p[1] = lchan->rqd_ta; + le = &lchan->lapdm_ch.lapdm_acch; + } else + le = &lchan->lapdm_ch.lapdm_dcch; + rc = lapdm_phsap_dequeue_prim(le, &pp); + if (rc < 0) { + if (L1SAP_IS_LINK_SACCH(link_id)) { + /* No SACCH data from LAPDM pending, send SACCH filling */ + uint8_t *si = lchan_sacch_get(lchan, &g_time); + if (si) { + /* The +2 is empty space where the DSP inserts the L1 hdr */ + memcpy(p + 2, si, GSM_MACBLOCK_LEN - 2); + } else + memcpy(p + 2, fill_frame, GSM_MACBLOCK_LEN - 2); + } else if ((!L1SAP_IS_CHAN_TCHF(chan_nr) && !L1SAP_IS_CHAN_TCHH(chan_nr)) + || lchan->rsl_cmode == RSL_CMOD_SPD_SIGN) { + /* send fill frame only, if not TCH/x != Signalling, otherwise send empty frame */ + p = msgb_put(msg, GSM_MACBLOCK_LEN); + memcpy(p, fill_frame, GSM_MACBLOCK_LEN); + } /* else the message remains empty, so TCH frames are sent */ + } else { + /* The +2 is empty space where the DSP inserts the L1 hdr */ + if (L1SAP_IS_LINK_SACCH(link_id)) + memcpy(p + 2, pp.oph.msg->data + 2, GSM_MACBLOCK_LEN - 2); + else { + p = msgb_put(msg, GSM_MACBLOCK_LEN); + memcpy(p, pp.oph.msg->data, GSM_MACBLOCK_LEN); + /* check if it is a RR CIPH MODE CMD. if yes, enable RX ciphering */ + check_for_ciph_cmd(pp.oph.msg, lchan, chan_nr); + } + msgb_free(pp.oph.msg); + } + } else if (L1SAP_IS_CHAN_AGCH_PCH(chan_nr)) { + p = msgb_put(msg, GSM_MACBLOCK_LEN); +#warning Set BS_AG_BLKS_RES + /* The sapi depends on DSP configuration, not + * on the actual SYSTEM INFORMATION 3. */ + struct gsm_bts_role_bts *btsb = trx->bts->role; + if (L1SAP_FN2CCCHBLOCK(fn) >= 1) { + /* PCH */ + paging_gen_msg(btsb->paging_state, p, &g_time); + } else { + /* AGCH */ + /* special queue of messages from IMM ASS CMD */ + struct msgb *amsg = bts_agch_dequeue(trx->bts); + if (!amsg) + memcpy(p, fill_frame, GSM_MACBLOCK_LEN); + else { + memcpy(p, amsg->data, amsg->len); + msgb_free(amsg); + } + } + } + + DEBUGP(DL1P, "Tx PH-DATA.req %02u/%02u/%02u chan_nr=%d link_id=%d\n", + g_time.t1, g_time.t2, g_time.t3, chan_nr, link_id); + + l1sap_down(trx, l1sap); + + /* don't free, because we forwarded data */ + return 1; +} + +/* TCH-RTS-IND prim recevied from bts model */ +static int l1sap_tch_rts_ind(struct gsm_bts_trx *trx, + struct osmo_phsap_prim *l1sap, struct ph_tch_param *rts_ind) +{ + struct msgb *resp_msg; + struct osmo_phsap_prim *resp_l1sap, empty_l1sap; + struct gsm_time g_time; + struct gsm_lchan *lchan; + uint8_t chan_nr; + uint8_t tn, ss; + uint32_t fn; + + chan_nr = rts_ind->chan_nr; + fn = rts_ind->fn; + tn = L1SAP_CHAN2TS(chan_nr); + + gsm_fn2gsmtime(&g_time, fn); + + DEBUGP(DL1P, "Rx TCH-RTS.ind %02u/%02u/%02u chan_nr=%d\n", + g_time.t1, g_time.t2, g_time.t3, chan_nr); + + /* get timeslot and subslot */ + tn = L1SAP_CHAN2TS(chan_nr); + if (L1SAP_IS_CHAN_TCHH(chan_nr)) + ss = L1SAP_CHAN2SS_TCHH(chan_nr); /* TCH/H */ + else + ss = 0; /* TCH/F */ + lchan = &trx->ts[tn].lchan[ss]; + + if (!lchan->loopback && lchan->abis_ip.rtp_socket) { + osmo_rtp_socket_poll(lchan->abis_ip.rtp_socket); + /* FIXME: we _assume_ that we never miss TDMA + * frames and that we always get to this point + * for every to-be-transmitted voice frame. A + * better solution would be to compute + * rx_user_ts based on how many TDMA frames have + * elapsed since the last call */ + lchan->abis_ip.rtp_socket->rx_user_ts += GSM_RTP_DURATION; + } + /* get a msgb from the dl_tx_queue */ + resp_msg = msgb_dequeue(&lchan->dl_tch_queue); + if (!resp_msg) { + LOGP(DL1P, LOGL_DEBUG, "%s DL TCH Tx queue underrun\n", + gsm_lchan_name(lchan)); + resp_l1sap = &empty_l1sap; + } else { + resp_msg->l2h = resp_msg->data; + msgb_push(resp_msg, sizeof(*resp_l1sap)); + resp_msg->l1h = resp_msg->data; + resp_l1sap = msgb_l1sap_prim(resp_msg); + } + + memset(resp_l1sap, 0, sizeof(*resp_l1sap)); + osmo_prim_init(&resp_l1sap->oph, SAP_GSM_PH, PRIM_TCH, PRIM_OP_REQUEST, + resp_msg); + resp_l1sap->u.tch.chan_nr = chan_nr; + resp_l1sap->u.tch.fn = fn; + + DEBUGP(DL1P, "Tx TCH.req %02u/%02u/%02u chan_nr=%d\n", + g_time.t1, g_time.t2, g_time.t3, chan_nr); + + l1sap_down(trx, resp_l1sap); + + return 0; +} + +/* DATA received from bts model */ +static int l1sap_ph_data_ind(struct gsm_bts_trx *trx, + struct osmo_phsap_prim *l1sap, struct ph_data_param *data_ind) +{ + struct msgb *msg = l1sap->oph.msg; + struct gsm_time g_time; + struct gsm_lchan *lchan; + struct lapdm_entity *le; + uint8_t *data = msg->l2h; + int len = msgb_l2len(msg); + uint8_t chan_nr, link_id; + uint8_t tn, ss; + uint32_t fn; + int8_t rssi; + + rssi = data_ind->rssi; + chan_nr = data_ind->chan_nr; + link_id = data_ind->link_id; + fn = data_ind->fn; + tn = L1SAP_CHAN2TS(chan_nr); + ss = l1sap_chan2ss(chan_nr); + + gsm_fn2gsmtime(&g_time, fn); + + DEBUGP(DL1P, "Rx PH-DATA.ind %02u/%02u/%02u chan_nr=%d link_id=%d\n", + g_time.t1, g_time.t2, g_time.t3, chan_nr, link_id); + + if (trx->ts[tn].pchan == GSM_PCHAN_PDCH) { + if (len == 0) + return -EINVAL; + if (L1SAP_IS_PTCCH(fn)) { + pcu_tx_data_ind(&trx->ts[tn], 1, fn, + 0 /* ARFCN */, L1SAP_FN2PTCCHBLOCK(fn), + data, len, rssi); + + return 0; + } + /* drop incomplete UL block */ + if (data[0] != 7) + return 0; + /* PDTCH / PACCH frame handling */ + pcu_tx_data_ind(&trx->ts[tn], 0, fn, 0 /* ARFCN */, + L1SAP_FN2MACBLOCK(fn), data + 1, len - 1, rssi); + + return 0; + } + + lchan = &trx->ts[tn].lchan[ss]; + + /* bad frame */ + if (len == 0) { + if (L1SAP_IS_LINK_SACCH(link_id) && lchan->s > 0) { + /* count down radio link counter S */ + lchan->s--; + DEBUGP(DMEAS, "counting down radio link counter S=%d\n", + lchan->s); + if (lchan->s == 0) + rsl_tx_conn_fail(lchan, + RSL_ERR_RADIO_LINK_FAIL); + } + + return -EINVAL; + } + + if (L1SAP_IS_LINK_SACCH(link_id)) { + struct gsm_bts_role_bts *btsb = trx->bts->role; + + le = &lchan->lapdm_ch.lapdm_acch; + /* count up radio link counter S */ + if (lchan->s < btsb->radio_link_timeout) { + lchan->s += 2; + if (lchan->s > btsb->radio_link_timeout) + lchan->s = btsb->radio_link_timeout; + DEBUGP(DMEAS, "counting up radio link counter S=%d\n", + lchan->s); + } + /* save the SACCH L1 header in the lchan struct for RSL MEAS RES */ + if (len < 2) { + LOGP(DL1P, LOGL_NOTICE, "SACCH with size %u<2 !?!\n", + len); + return -EINVAL; + } + /* Some brilliant engineer decided that the ordering of + * fields on the Um interface is different from the + * order of fields in RLS. See TS 04.04 (Chapter 7.2) + * vs. TS 08.58 (Chapter 9.3.10). */ + lchan->meas.l1_info[0] = data[0] << 3; + lchan->meas.l1_info[0] |= ((data[0] >> 5) & 1) << 2; + lchan->meas.l1_info[1] = data[1]; + lchan->meas.flags |= LC_UL_M_F_L1_VALID; + } else + le = &lchan->lapdm_ch.lapdm_dcch; + + /* if this is the first valid message after enabling Rx + * decryption, we have to enable Tx encryption */ + if (lchan->ciph_state == LCHAN_CIPH_RX_CONF) { + /* HACK: check if it's an I frame, in order to + * ignore some still buffered/queued UI frames received + * before decryption was enabled */ + if (data[0] == 0x01 && (data[1] & 0x01) == 0) { + l1sap_tx_ciph_req(trx, chan_nr, 1, 0); + } + } + + /* SDCCH, SACCH and FACCH all go to LAPDm */ + msgb_pull(msg, (msg->l2h - msg->data)); + msg->l1h = NULL; + lapdm_phsap_up(&l1sap->oph, le); + + /* don't free, because we forwarded data */ + return 1; +} + +/* TCH received from bts model */ +static int l1sap_tch_ind(struct gsm_bts_trx *trx, struct osmo_phsap_prim *l1sap, + struct ph_tch_param *tch_ind) +{ + struct msgb *msg = l1sap->oph.msg; + struct gsm_time g_time; + struct gsm_lchan *lchan; + uint8_t tn, ss, chan_nr; + uint32_t fn; + + chan_nr = tch_ind->chan_nr; + fn = tch_ind->fn; + tn = L1SAP_CHAN2TS(chan_nr); + if (L1SAP_IS_CHAN_TCHH(chan_nr)) + ss = L1SAP_CHAN2SS_TCHH(chan_nr); + else + ss = 0; + lchan = &trx->ts[tn].lchan[ss]; + + gsm_fn2gsmtime(&g_time, fn); + + DEBUGP(DL1P, "Rx TCH.ind %02u/%02u/%02u chan_nr=%d\n", + g_time.t1, g_time.t2, g_time.t3, chan_nr); + + msgb_pull(msg, sizeof(*l1sap)); + + /* hand msg to RTP code for transmission */ + if (lchan->abis_ip.rtp_socket) + osmo_rtp_send_frame(lchan->abis_ip.rtp_socket, + msg->data, msg->len, 160); + + /* if loopback is enabled, also queue received RTP data */ + if (lchan->loopback) { + struct msgb *tmp; + int count = 0; + + /* make sure the queue doesn't get too long */ + llist_for_each_entry(tmp, &lchan->dl_tch_queue, list) + count++; + while (count >= 1) { + tmp = msgb_dequeue(&lchan->dl_tch_queue); + msgb_free(tmp); + count--; + } + + msgb_enqueue(&lchan->dl_tch_queue, msg); + } + + return 0; +} + +/* RACH received from bts model */ +static int l1sap_ph_rach_ind(struct gsm_bts_trx *trx, + struct osmo_phsap_prim *l1sap, struct ph_rach_ind_param *rach_ind) +{ + struct gsm_bts *bts = trx->bts; + struct gsm_bts_role_bts *btsb = bts->role; + struct lapdm_channel *lc; + + DEBUGP(DL1P, "Rx PH-RA.ind"); + + lc = &trx->ts[0].lchan[4].lapdm_ch; + if (!lc) { + LOGP(DL1P, LOGL_ERROR, "unable to resolve LAPD channel\n"); + return -ENODEV; + } + + /* check for under/overflow / sign */ + if (rach_ind->acc_delay > btsb->max_ta) { + LOGP(DL1P, LOGL_INFO, "ignoring RACH request %u > max_ta(%u)\n", + rach_ind->acc_delay, btsb->max_ta); + return 0; + } + + /* check for packet access */ + if (trx == bts->c0 + && L1SAP_IS_PACKET_RACH(rach_ind->ra)) { + LOGP(DL1P, LOGL_INFO, "RACH for packet access\n"); + pcu_tx_rach_ind(bts, rach_ind->acc_delay << 2, + rach_ind->ra, rach_ind->fn); + + return 0; + } + + LOGP(DL1P, LOGL_INFO, "RACH for RR access (toa=%d, ra=%d)\n", + rach_ind->acc_delay, rach_ind->ra); + lapdm_phsap_up(&l1sap->oph, &lc->lapdm_dcch); + + return 0; +} + +/* any L1 prim received from bts model */ +int l1sap_up(struct gsm_bts_trx *trx, struct osmo_phsap_prim *l1sap) +{ + struct msgb *msg = l1sap->oph.msg; + int rc = 0; + + switch (OSMO_PRIM_HDR(&l1sap->oph)) { + case OSMO_PRIM(PRIM_MPH_INFO, PRIM_OP_INDICATION): + rc = l1sap_mph_info_ind(trx, l1sap, &l1sap->u.info); + break; + case OSMO_PRIM(PRIM_MPH_INFO, PRIM_OP_CONFIRM): + rc = l1sap_mph_info_cnf(trx, l1sap, &l1sap->u.info); + break; + case OSMO_PRIM(PRIM_PH_RTS, PRIM_OP_INDICATION): + rc = l1sap_ph_rts_ind(trx, l1sap, &l1sap->u.data); + break; + case OSMO_PRIM(PRIM_TCH_RTS, PRIM_OP_INDICATION): + rc = l1sap_tch_rts_ind(trx, l1sap, &l1sap->u.tch); + break; + case OSMO_PRIM(PRIM_PH_DATA, PRIM_OP_INDICATION): + to_gsmtap(trx, l1sap); + rc = l1sap_ph_data_ind(trx, l1sap, &l1sap->u.data); + break; + case OSMO_PRIM(PRIM_TCH, PRIM_OP_INDICATION): + rc = l1sap_tch_ind(trx, l1sap, &l1sap->u.tch); + break; + case OSMO_PRIM(PRIM_PH_RACH, PRIM_OP_INDICATION): + to_gsmtap(trx, l1sap); + rc = l1sap_ph_rach_ind(trx, l1sap, &l1sap->u.rach_ind); + break; + default: + LOGP(DL1P, LOGL_NOTICE, "unknown prim %d op %d\n", + l1sap->oph.primitive, l1sap->oph.operation); + break; + } + + /* Special return value '1' means: do not free */ + if (rc != 1 && msg) + msgb_free(msg); + + return rc; +} + +/* any L1 prim sent to bts model */ +static int l1sap_down(struct gsm_bts_trx *trx, struct osmo_phsap_prim *l1sap) +{ + if (OSMO_PRIM_HDR(&l1sap->oph) == + OSMO_PRIM(PRIM_PH_DATA, PRIM_OP_REQUEST)) + to_gsmtap(trx, l1sap); + + return bts_model_l1sap_down(trx, l1sap); +} + +/* pcu (socket interface) sends us a data request primitive */ +int l1sap_pdch_req(struct gsm_bts_trx_ts *ts, int is_ptcch, uint32_t fn, + uint16_t arfcn, uint8_t block_nr, uint8_t *data, uint8_t len) +{ + struct msgb *msg; + struct osmo_phsap_prim *l1sap; + struct gsm_time g_time; + + gsm_fn2gsmtime(&g_time, fn); + + DEBUGP(DL1P, "TX packet data %02u/%02u/%02u is_ptcch=%d trx=%d ts=%d " + "block_nr=%d, arfcn=%d, len=%d\n", g_time.t1, g_time.t2, + g_time.t3, is_ptcch, ts->trx->nr, ts->nr, block_nr, arfcn, len); + + msg = l1sap_msgb_alloc(len); + l1sap = msgb_l1sap_prim(msg); + osmo_prim_init(&l1sap->oph, SAP_GSM_PH, PRIM_PH_DATA, PRIM_OP_REQUEST, + msg); + l1sap->u.data.chan_nr = 0x08 | ts->nr; + l1sap->u.data.link_id = 0x00; + l1sap->u.data.fn = fn; + msg->l2h = msgb_put(msg, len); + memcpy(msg->l2h, data, len); + + return l1sap_down(ts->trx, l1sap); +} + +/*! \brief call-back function for incoming RTP */ +void l1sap_rtp_rx_cb(struct osmo_rtp_socket *rs, const uint8_t *rtp_pl, + unsigned int rtp_pl_len) +{ + struct gsm_lchan *lchan = rs->priv; + struct msgb *msg, *tmp; + struct osmo_phsap_prim *l1sap; + int count = 0; + + msg = l1sap_msgb_alloc(rtp_pl_len); + if (!msg) + return; + memcpy(msgb_put(msg, rtp_pl_len), rtp_pl, rtp_pl_len); + msgb_pull(msg, sizeof(*l1sap)); + + + /* make sure the queue doesn't get too long */ + llist_for_each_entry(tmp, &lchan->dl_tch_queue, list) + count++; + while (count >= 2) { + tmp = msgb_dequeue(&lchan->dl_tch_queue); + msgb_free(tmp); + count--; + } + + msgb_enqueue(&lchan->dl_tch_queue, msg); +} + +static int l1sap_chan_act_dact_modify(struct gsm_bts_trx *trx, uint8_t chan_nr, + enum osmo_mph_info_type type, uint8_t sacch_only) +{ + struct osmo_phsap_prim l1sap; + + memset(&l1sap, 0, sizeof(l1sap)); + osmo_prim_init(&l1sap.oph, SAP_GSM_PH, PRIM_MPH_INFO, PRIM_OP_REQUEST, + NULL); + l1sap.u.info.type = type; + l1sap.u.info.u.act_req.chan_nr = chan_nr; + l1sap.u.info.u.act_req.sacch_only = sacch_only; + + return l1sap_down(trx, &l1sap); +} + +int l1sap_chan_act(struct gsm_bts_trx *trx, uint8_t chan_nr) +{ + struct gsm_bts_role_bts *btsb = trx->bts->role; + struct gsm_lchan *lchan = &trx->ts[L1SAP_CHAN2TS(chan_nr)] + .lchan[l1sap_chan2ss(chan_nr)]; + + LOGP(DL1P, LOGL_INFO, "activating channel chan_nr=%02x trx=%d\n", + chan_nr, trx->nr); + + lchan->sacch_deact = 0; + lchan->s = btsb->radio_link_timeout; + + return l1sap_chan_act_dact_modify(trx, chan_nr, PRIM_INFO_ACTIVATE, 0); +} + +int l1sap_chan_rel(struct gsm_bts_trx *trx, uint8_t chan_nr) +{ + LOGP(DL1P, LOGL_INFO, "deactivating channel chan_nr=%02x trx=%d\n", + chan_nr, trx->nr); + + return l1sap_chan_act_dact_modify(trx, chan_nr, PRIM_INFO_DEACTIVATE, + 0); +} + +int l1sap_chan_deact_sacch(struct gsm_bts_trx *trx, uint8_t chan_nr) +{ + struct gsm_lchan *lchan = &trx->ts[L1SAP_CHAN2TS(chan_nr)] + .lchan[l1sap_chan2ss(chan_nr)]; + + LOGP(DL1P, LOGL_INFO, "deactivating sacch chan_nr=%02x trx=%d\n", + chan_nr, trx->nr); + + lchan->sacch_deact = 1; + + return l1sap_chan_act_dact_modify(trx, chan_nr, PRIM_INFO_DEACTIVATE, + 1); +} + +int l1sap_chan_modify(struct gsm_bts_trx *trx, uint8_t chan_nr) +{ + LOGP(DL1P, LOGL_INFO, "modifying channel chan_nr=%02x trx=%d\n", + chan_nr, trx->nr); + + return l1sap_chan_act_dact_modify(trx, chan_nr, PRIM_INFO_MODIFY, 0); +} diff --git a/src/common/logging.c b/src/common/logging.c index 98fd205..f56846e 100644 --- a/src/common/logging.c +++ b/src/common/logging.c @@ -69,8 +69,8 @@ static struct log_info_cat bts_log_info_cat[] = { [DL1C] = { .name = "DL1C", .description = "Layer 1", - .loglevel = LOGL_INFO, - .enabled = 1, + .color = "\033[1;32m", + .enabled = 1, .loglevel = LOGL_NOTICE, }, [DL1P] = { .name = "DL1P", diff --git a/src/common/measurement.c b/src/common/measurement.c index 774962d..ff80a9f 100644 --- a/src/common/measurement.c +++ b/src/common/measurement.c @@ -89,6 +89,11 @@ static int is_meas_complete(enum gsm_phys_chan_config pchan, unsigned int ts, /* receive a L1 uplink measurement from L1 */ int lchan_new_ul_meas(struct gsm_lchan *lchan, struct bts_ul_meas *ulm) { + /* in the GPRS case we are not interested in measurement + * processing. The PCU will take care of it */ + if (lchan->type == GSM_LCHAN_PDTCH) + return 0; + DEBUGP(DMEAS, "%s adding measurement, num_ul_meas=%d\n", gsm_lchan_name(lchan), lchan->meas.num_ul_meas); diff --git a/src/common/pcu_sock.c b/src/common/pcu_sock.c index a90caac..76ecf22 100644 --- a/src/common/pcu_sock.c +++ b/src/common/pcu_sock.c @@ -39,7 +39,7 @@ #include #include #include -#include +#include uint32_t trx_get_hlayer1(struct gsm_bts_trx *trx); @@ -57,10 +57,6 @@ static const char *sapi_string[] = { [PCU_IF_SAPI_PTCCH] = "PTCCH", }; -/* FIXME: common l1if include ? */ -int l1if_pdch_req(struct gsm_bts_trx_ts *ts, int is_ptcch, uint32_t fn, - uint16_t arfcn, uint8_t block_nr, uint8_t *data, uint8_t len); - static int pcu_sock_send(struct gsm_network *net, struct msgb *msg); /* FIXME: move this to libosmocore */ int osmo_unixsock_listen(struct osmo_fd *bfd, int type, const char *path); @@ -511,7 +507,7 @@ static int pcu_rx_data_req(struct gsm_bts *bts, uint8_t msg_type, } ts = &trx->ts[data_req->ts_nr]; is_ptcch = (data_req->sapi == PCU_IF_SAPI_PTCCH); - rc = l1if_pdch_req(ts, is_ptcch, data_req->fn, data_req->arfcn, + rc = l1sap_pdch_req(ts, is_ptcch, data_req->fn, data_req->arfcn, data_req->block_nr, data_req->data, data_req->len); break; default: @@ -544,9 +540,9 @@ static int pcu_rx_act_req(struct gsm_bts *bts, return -EINVAL; } if (act_req->activate) - bts_model_rsl_chan_act(lchan, NULL); + l1sap_chan_act(trx, gsm_lchan2chan_nr(lchan)); else - bts_model_rsl_chan_rel(lchan); + l1sap_chan_rel(trx, gsm_lchan2chan_nr(lchan)); return 0; } @@ -650,7 +646,8 @@ static void pcu_sock_close(struct pcu_sock_state *state) ts = &trx->ts[j]; if (ts->mo.nm_state.operational == NM_OPSTATE_ENABLED && ts->pchan == GSM_PCHAN_PDCH) - bts_model_rsl_chan_rel(ts->lchan); + l1sap_chan_rel(trx, + gsm_lchan2chan_nr(ts->lchan)); } } diff --git a/src/common/rsl.c b/src/common/rsl.c index 616ae0d..150f686 100644 --- a/src/common/rsl.c +++ b/src/common/rsl.c @@ -41,9 +41,9 @@ #include #include #include -#include #include #include +#include //#define FAKE_CIPH_MODE_COMPL @@ -499,8 +499,9 @@ int rsl_tx_rf_rel_ack(struct gsm_lchan *lchan) } /* 8.4.2 sending CHANnel ACTIVation ACKnowledge */ -int rsl_tx_chan_act_ack(struct gsm_lchan *lchan, struct gsm_time *gtime) +int rsl_tx_chan_act_ack(struct gsm_lchan *lchan) { + struct gsm_time *gtime = get_time(lchan->ts->trx->bts); struct msgb *msg; uint8_t chan_nr = gsm_lchan2chan_nr(lchan); uint8_t ie[2]; @@ -760,14 +761,12 @@ static int rsl_rx_chan_activ(struct msgb *msg) dch->chan_nr, type, lchan->tch_mode); /* actually activate the channel in the BTS */ - return bts_model_rsl_chan_act(msg->lchan, &tp); + return l1sap_chan_act(lchan->ts->trx, dch->chan_nr); } /* 8.4.14 RF CHANnel RELease is received */ -static int rsl_rx_rf_chan_rel(struct gsm_lchan *lchan) +static int rsl_rx_rf_chan_rel(struct gsm_lchan *lchan, uint8_t chan_nr) { - int rc; - if (lchan->abis_ip.rtp_socket) { rsl_tx_ipac_dlcx_ind(lchan, RSL_ERR_NORMAL_UNSPEC); osmo_rtp_socket_free(lchan->abis_ip.rtp_socket); @@ -775,11 +774,11 @@ static int rsl_rx_rf_chan_rel(struct gsm_lchan *lchan) msgb_queue_flush(&lchan->dl_tch_queue); } - rc = bts_model_rsl_chan_rel(lchan); + l1sap_chan_rel(lchan->ts->trx, chan_nr); lapdm_channel_exit(&lchan->lapdm_ch); - return rc; + return 0; } #ifdef FAKE_CIPH_MODE_COMPL @@ -962,10 +961,10 @@ static int rsl_tx_mode_modif_ack(struct gsm_lchan *lchan) /* 8.4.9 MODE MODIFY */ static int rsl_rx_mode_modif(struct msgb *msg) { + struct abis_rsl_dchan_hdr *dch = msgb_l2(msg); struct gsm_lchan *lchan = msg->lchan; struct rsl_ie_chan_mode *cm; struct tlv_parsed tp; - int rc; rsl_tlv_parse(&tp, msgb_l3(msg), msgb_l3len(msg)); @@ -1005,12 +1004,12 @@ static int rsl_rx_mode_modif(struct msgb *msg) /* 9.3.53 MultiRate Control */ /* 9.3.54 Supported Codec Types */ - rc = bts_model_rsl_mode_modify(msg->lchan); + l1sap_chan_modify(lchan->ts->trx, dch->chan_nr); /* FIXME: delay this until L1 says OK? */ - rsl_tx_mode_modif_ack(msg->lchan); + rsl_tx_mode_modif_ack(lchan); - return rc; + return 0; } /* 8.4.20 SACCH INFO MODify */ @@ -1314,7 +1313,7 @@ static int rsl_rx_ipac_XXcx(struct msgb *msg) OSMO_RTP_P_JITBUF, btsb->rtp_jitter_buf_ms); lchan->abis_ip.rtp_socket->priv = lchan; - lchan->abis_ip.rtp_socket->rx_cb = &bts_model_rtp_rx_cb; + lchan->abis_ip.rtp_socket->rx_cb = &l1sap_rtp_rx_cb; if (connect_ip && connect_port) { /* if CRCX specifies a remote IP, we can bind() @@ -1646,13 +1645,13 @@ static int rsl_rx_dchan(struct gsm_bts_trx *trx, struct msgb *msg) ret = rsl_rx_chan_activ(msg); break; case RSL_MT_RF_CHAN_REL: - ret = rsl_rx_rf_chan_rel(msg->lchan); + ret = rsl_rx_rf_chan_rel(msg->lchan, dch->chan_nr); break; case RSL_MT_SACCH_INFO_MODIFY: ret = rsl_rx_sacch_inf_mod(msg); break; case RSL_MT_DEACTIVATE_SACCH: - ret = bts_model_rsl_deact_sacch(msg->lchan); + ret = l1sap_chan_deact_sacch(trx, dch->chan_nr); break; case RSL_MT_ENCR_CMD: ret = rsl_rx_encr_cmd(msg); diff --git a/src/common/vty.c b/src/common/vty.c index 5eddc8d..4daa92c 100644 --- a/src/common/vty.c +++ b/src/common/vty.c @@ -22,12 +22,15 @@ #include #include #include +#include #include #include #include #include #include +#include +#include #include @@ -42,7 +45,7 @@ #include #include #include - +#include enum node_type bts_vty_go_parent(struct vty *vty) { @@ -171,10 +174,38 @@ DEFUN(cfg_bts_trx, cfg_bts_trx_cmd, return CMD_SUCCESS; } +/* FIXME: move to libosmocore ? */ +static char buf_casecnvt[256]; +char *osmo_str_tolower(const char *in) +{ + int len, i; + + if (!in) + return NULL; + + len = strlen(in); + if (len > sizeof(buf_casecnvt)) + len = sizeof(buf_casecnvt); + + for (i = 0; i < len; i++) { + buf_casecnvt[i] = tolower(in[i]); + if (in[i] == '\0') + break; + } + if (i < sizeof(buf_casecnvt)) + buf_casecnvt[i] = '\0'; + + /* just to make sure we're always zero-terminated */ + buf_casecnvt[sizeof(buf_casecnvt)-1] = '\0'; + + return buf_casecnvt; +} + static void config_write_bts_single(struct vty *vty, struct gsm_bts *bts) { struct gsm_bts_role_bts *btsb = bts_role_bts(bts); struct gsm_bts_trx *trx; + int i; vty_out(vty, "bts %u%s", bts->nr, VTY_NEWLINE); if (bts->description) @@ -190,6 +221,17 @@ static void config_write_bts_single(struct vty *vty, struct gsm_bts *bts) vty_out(vty, " paging lifetime %u%s", paging_get_lifetime(btsb->paging_state), VTY_NEWLINE); + for (i = 0; i < 32; i++) { + if (gsmtap_sapi_mask & (1 << i)) { + const char *name = get_value_string(gsmtap_sapi_names, i); + vty_out(vty, " gsmtap-sapi %s%s", osmo_str_tolower(name), VTY_NEWLINE); + } + } + if (gsmtap_sapi_acch) { + const char *name = get_value_string(gsmtap_sapi_names, GSMTAP_CHANNEL_ACCH); + vty_out(vty, " gsmtap-sapi %s%s", osmo_str_tolower(name), VTY_NEWLINE); + } + bts_model_config_write_bts(vty, bts); llist_for_each_entry(trx, &bts->trx_list, list) { @@ -475,6 +517,36 @@ static struct gsm_lchan *resolve_lchan(struct gsm_network *net, "logical channel commands\n" \ "logical channel number\n" +DEFUN(cfg_trx_gsmtap_sapi, cfg_trx_gsmtap_sapi_cmd, + "HIDDEN", "HIDDEN") +{ + int sapi; + + sapi = get_string_value(gsmtap_sapi_names, argv[0]); + + if (sapi == GSMTAP_CHANNEL_ACCH) + gsmtap_sapi_acch = 1; + else + gsmtap_sapi_mask |= (1 << sapi); + + return CMD_SUCCESS; +} + +DEFUN(cfg_trx_no_gsmtap_sapi, cfg_trx_no_gsmtap_sapi_cmd, + "HIDDEN", "HIDDEN") +{ + int sapi; + + sapi = get_string_value(gsmtap_sapi_names, argv[0]); + + if (sapi == GSMTAP_CHANNEL_ACCH) + gsmtap_sapi_acch = 0; + else + gsmtap_sapi_mask &= ~(1 << sapi); + + return CMD_SUCCESS; +} + DEFUN(bts_t_t_l_jitter_buf, bts_t_t_l_jitter_buf_cmd, "bts <0-0> trx <0-0> ts <0-7> lchan <0-1> rtp jitter-buffer <0-10000>", @@ -501,8 +573,58 @@ DEFUN(bts_t_t_l_jitter_buf, return CMD_SUCCESS; } -int bts_vty_init(const struct log_info *cat) +DEFUN(bts_t_t_l_loopback, + bts_t_t_l_loopback_cmd, + "bts <0-0> trx <0-0> ts <0-7> lchan <0-1> loopback", + BTS_T_T_L_STR "Set loopback\n") { + struct gsm_network *net = gsmnet_from_vty(vty); + struct gsm_lchan *lchan; + + lchan = resolve_lchan(net, argv, 0); + if (!lchan) { + vty_out(vty, "%% can't find BTS%s", VTY_NEWLINE); + return CMD_WARNING; + } + lchan->loopback = 1; + + return CMD_SUCCESS; +} + +DEFUN(no_bts_t_t_l_loopback, + no_bts_t_t_l_loopback_cmd, + "no bts <0-0> trx <0-0> ts <0-7> lchan <0-1> loopback", + NO_STR BTS_T_T_L_STR "Set loopback\n") +{ + struct gsm_network *net = gsmnet_from_vty(vty); + struct gsm_lchan *lchan; + + lchan = resolve_lchan(net, argv, 0); + if (!lchan) { + vty_out(vty, "%% can't find BTS%s", VTY_NEWLINE); + return CMD_WARNING; + } + lchan->loopback = 0; + + return CMD_SUCCESS; +} + +int bts_vty_init(struct gsm_bts *bts, const struct log_info *cat) +{ + cfg_trx_gsmtap_sapi_cmd.string = vty_cmd_string_from_valstr(bts, gsmtap_sapi_names, + "gsmtap-sapi (", + "|",")", VTY_DO_LOWER); + cfg_trx_gsmtap_sapi_cmd.doc = vty_cmd_string_from_valstr(bts, gsmtap_sapi_names, + "GSMTAP SAPI\n", + "\n", "", 0); + + cfg_trx_no_gsmtap_sapi_cmd.string = vty_cmd_string_from_valstr(bts, gsmtap_sapi_names, + "no gsmtap-sapi (", + "|",")", VTY_DO_LOWER); + cfg_trx_no_gsmtap_sapi_cmd.doc = vty_cmd_string_from_valstr(bts, gsmtap_sapi_names, + NO_STR "GSMTAP SAPI\n", + "\n", "", 0); + install_element_ve(&show_bts_cmd); logging_vty_add_cmds(cat); @@ -520,12 +642,17 @@ int bts_vty_init(const struct log_info *cat) install_element(BTS_NODE, &cfg_bts_paging_queue_size_cmd); install_element(BTS_NODE, &cfg_bts_paging_lifetime_cmd); + install_element(BTS_NODE, &cfg_trx_gsmtap_sapi_cmd); + install_element(BTS_NODE, &cfg_trx_no_gsmtap_sapi_cmd); + /* add and link to TRX config node */ install_element(BTS_NODE, &cfg_bts_trx_cmd); install_node(&trx_node, config_write_dummy); install_default(TRX_NODE); install_element(ENABLE_NODE, &bts_t_t_l_jitter_buf_cmd); + install_element(ENABLE_NODE, &bts_t_t_l_loopback_cmd); + install_element(ENABLE_NODE, &no_bts_t_t_l_loopback_cmd); return 0; } diff --git a/src/osmo-bts-sysmo/l1_if.c b/src/osmo-bts-sysmo/l1_if.c index 16f1523..6efb9d6 100644 --- a/src/osmo-bts-sysmo/l1_if.c +++ b/src/osmo-bts-sysmo/l1_if.c @@ -1303,3 +1303,9 @@ int l1if_close(struct femtol1_hdl *fl1h) l1if_transport_close(MQ_SYS_WRITE, fl1h); return 0; } + +/* temporary stub to make this patch compile */ +int bts_model_l1sap_down(struct gsm_bts_trx *trx, struct osmo_phsap_prim *l1sap) +{ + return -ENOTSUP; +} diff --git a/src/osmo-bts-sysmo/main.c b/src/osmo-bts-sysmo/main.c index 595a6eb..7e7f761 100644 --- a/src/osmo-bts-sysmo/main.c +++ b/src/osmo-bts-sysmo/main.c @@ -255,7 +255,7 @@ int main(int argc, char **argv) bts_log_init(NULL); vty_init(&bts_vty_info); - bts_vty_init(&bts_log_info); + bts_vty_init(bts, &bts_log_info); handle_options(argc, argv); diff --git a/src/osmo-bts-sysmo/oml.c b/src/osmo-bts-sysmo/oml.c index faef025..aeddad7 100644 --- a/src/osmo-bts-sysmo/oml.c +++ b/src/osmo-bts-sysmo/oml.c @@ -868,10 +868,8 @@ static int sapi_activate_cb(struct gsm_lchan *lchan, int status) if (lchan->state != LCHAN_S_ACT_REQ) return 0; - struct gsm_time *time; lchan_set_state(lchan, LCHAN_S_ACTIVE); - time = bts_model_get_time(lchan->ts->trx->bts); - rsl_tx_chan_act_ack(lchan, time); + rsl_tx_chan_act_ack(lchan); /* set the initial ciphering parameters for both directions */ l1if_set_ciphering(fl1h, lchan, 0); diff --git a/src/osmo-bts-sysmo/sysmobts_vty.c b/src/osmo-bts-sysmo/sysmobts_vty.c index 5bc948e..61deda4 100644 --- a/src/osmo-bts-sysmo/sysmobts_vty.c +++ b/src/osmo-bts-sysmo/sysmobts_vty.c @@ -444,33 +444,6 @@ void bts_model_config_write_bts(struct vty *vty, struct gsm_bts *bts) vty_out(vty, " auto-band%s", VTY_NEWLINE); } -/* FIXME: move to libosmocore ? */ -static char buf_casecnvt[256]; -char *osmo_str_tolower(const char *in) -{ - int len, i; - - if (!in) - return NULL; - - len = strlen(in); - if (len > sizeof(buf_casecnvt)) - len = sizeof(buf_casecnvt); - - for (i = 0; i < len; i++) { - buf_casecnvt[i] = tolower(in[i]); - if (in[i] == '\0') - break; - } - if (i < sizeof(buf_casecnvt)) - buf_casecnvt[i] = '\0'; - - /* just to make sure we're always zero-terminated */ - buf_casecnvt[sizeof(buf_casecnvt)-1] = '\0'; - - return buf_casecnvt; -} - void bts_model_config_write_trx(struct vty *vty, struct gsm_bts_trx *trx) { struct femtol1_hdl *fl1h = trx_femtol1_hdl(trx); diff --git a/tests/stubs.c b/tests/stubs.c index c46bb4a..c0089c5 100644 --- a/tests/stubs.c +++ b/tests/stubs.c @@ -46,3 +46,6 @@ int l1if_pdch_req(struct gsm_bts_trx_ts *ts, int is_ptcch, uint32_t fn, uint32_t trx_get_hlayer1(struct gsm_bts_trx *trx) { return 0; } + +int bts_model_l1sap_down(struct gsm_bts_trx *trx, struct osmo_phsap_prim *l1sap) +{ return 0; } -- 1.8.1.5 From holger at freyther.de Mon Jul 15 10:52:32 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 15 Jul 2013 12:52:32 +0200 Subject: [PATCH 2/7] Add PH-/MPH-/TCH-SAP interface to common part of osmo-bts In-Reply-To: <1373877336-27883-2-git-send-email-jolly@eversberg.eu> References: <1373877336-27883-1-git-send-email-jolly@eversberg.eu> <1373877336-27883-2-git-send-email-jolly@eversberg.eu> Message-ID: <20130715105232.GZ4387@xiaoyu.lan> On Mon, Jul 15, 2013 at 10:35:31AM +0200, Andreas Eversberg wrote: > Instead of handling primitives directly at layer 1 specific code, > osmo-bts handles primitives at common code. Therefore a new file > 'l1sap.c' is added and integrated. make distcheck... is faili... From andreas at eversberg.eu Mon Jul 15 14:58:53 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Mon, 15 Jul 2013 16:58:53 +0200 Subject: [PATCH 2/7] Add PH-/MPH-/TCH-SAP interface to common part of osmo-bts In-Reply-To: <20130715105232.GZ4387@xiaoyu.lan> References: <1373877336-27883-1-git-send-email-jolly@eversberg.eu> <1373877336-27883-2-git-send-email-jolly@eversberg.eu> <20130715105232.GZ4387@xiaoyu.lan> Message-ID: <51E40E2D.8080302@eversberg.eu> Holger Hans Peter Freyther wrote: > make distcheck... is faili... > what message do you get? my distcheck looks weird: ... checking for LIBOSMOCORE... yes checking for LIBOSMOVTY... yes checking for LIBOSMOTRAU... yes checking for LIBOSMOGSM... yes checking whether to enable sysmocom-bts hardware support... no 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 openbsc/gsm_data_shared.h usability... no checking openbsc/gsm_data_shared.h presence... no checking for openbsc/gsm_data_shared.h... no configure: error: openbsc/gsm_data_shared.h can not be found in /files/projects/gsm/osmo-bts/osmo-bts-0.3.0.34-ea0c/../openbsc/openbsc/include make: *** [distcheck] Error 1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at freyther.de Mon Jul 15 15:13:33 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 15 Jul 2013 17:13:33 +0200 Subject: [PATCH 2/7] Add PH-/MPH-/TCH-SAP interface to common part of osmo-bts In-Reply-To: <51E40E2D.8080302@eversberg.eu> References: <1373877336-27883-1-git-send-email-jolly@eversberg.eu> <1373877336-27883-2-git-send-email-jolly@eversberg.eu> <20130715105232.GZ4387@xiaoyu.lan> <51E40E2D.8080302@eversberg.eu> Message-ID: <20130715151333.GD4387@xiaoyu.lan> On Mon, Jul 15, 2013 at 04:58:53PM +0200, Andreas Eversberg wrote: > > make distcheck... is faili... > > > what message do you get? my distcheck looks weird: Really? After the issues/thread we had last week? You are supposed to do these checks before asking people to review. If make distcheck doesn't work for you, you should ask before posting your patches. From andreas at eversberg.eu Mon Jul 15 17:35:12 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Mon, 15 Jul 2013 19:35:12 +0200 Subject: [PATCH 2/7] Add PH-/MPH-/TCH-SAP interface to common part of osmo-bts In-Reply-To: <20130715151333.GD4387@xiaoyu.lan> References: <1373877336-27883-1-git-send-email-jolly@eversberg.eu> <1373877336-27883-2-git-send-email-jolly@eversberg.eu> <20130715105232.GZ4387@xiaoyu.lan> <51E40E2D.8080302@eversberg.eu> <20130715151333.GD4387@xiaoyu.lan> Message-ID: <51E432D0.9030306@eversberg.eu> Holger Hans Peter Freyther wrote: > Really? After the issues/thread we had last week? You are supposed > to do these checks before asking people to review. If make distcheck > doesn't work for you, you should ask before posting your patches it workes, if i link openbsc to the osmo-bts directory: ln -s path/to/openbsc/ . attached is the corrected version. include/osmo-bts/l1sap.h was not added to the makefile of include/osmo-bts. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0002-Add-PH-MPH-TCH-SAP-interface-to-common-part-of-osmo-.patch URL: From holger at freyther.de Mon Jul 15 17:38:19 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 15 Jul 2013 19:38:19 +0200 Subject: [PATCH 2/7] Add PH-/MPH-/TCH-SAP interface to common part of osmo-bts In-Reply-To: <51E432D0.9030306@eversberg.eu> References: <1373877336-27883-1-git-send-email-jolly@eversberg.eu> <1373877336-27883-2-git-send-email-jolly@eversberg.eu> <20130715105232.GZ4387@xiaoyu.lan> <51E40E2D.8080302@eversberg.eu> <20130715151333.GD4387@xiaoyu.lan> <51E432D0.9030306@eversberg.eu> Message-ID: <20130715173819.GM4387@xiaoyu.lan> On Mon, Jul 15, 2013 at 07:35:12PM +0200, Andreas Eversberg wrote: > ln -s path/to/openbsc/ . > > attached is the corrected version. include/osmo-bts/l1sap.h was not > added to the makefile of include/osmo-bts. You could have taken a look at the build log of the jenkins and see the DISTCHECK_CONFIGURE_FLAGS environment variable in use. These flags will be passed to configure. Do the other patches pass make distcheck too? From andreas at eversberg.eu Mon Jul 15 18:04:34 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Mon, 15 Jul 2013 20:04:34 +0200 Subject: [PATCH 2/7] Add PH-/MPH-/TCH-SAP interface to common part of osmo-bts In-Reply-To: <20130715173819.GM4387@xiaoyu.lan> References: <1373877336-27883-1-git-send-email-jolly@eversberg.eu> <1373877336-27883-2-git-send-email-jolly@eversberg.eu> <20130715105232.GZ4387@xiaoyu.lan> <51E40E2D.8080302@eversberg.eu> <20130715151333.GD4387@xiaoyu.lan> <51E432D0.9030306@eversberg.eu> <20130715173819.GM4387@xiaoyu.lan> Message-ID: <51E439B2.5090408@eversberg.eu> Holger Hans Peter Freyther wrote: > Do the other patches pass make distcheck too? > yes, every patch works. i did a "git reset --hard" for scrolling back patch by patch. is there a more elegant way to test every patch? From holger at freyther.de Mon Jul 15 18:41:24 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 15 Jul 2013 20:41:24 +0200 Subject: [PATCH 2/7] Add PH-/MPH-/TCH-SAP interface to common part of osmo-bts In-Reply-To: <51E439B2.5090408@eversberg.eu> References: <1373877336-27883-1-git-send-email-jolly@eversberg.eu> <1373877336-27883-2-git-send-email-jolly@eversberg.eu> <20130715105232.GZ4387@xiaoyu.lan> <51E40E2D.8080302@eversberg.eu> <20130715151333.GD4387@xiaoyu.lan> <51E432D0.9030306@eversberg.eu> <20130715173819.GM4387@xiaoyu.lan> <51E439B2.5090408@eversberg.eu> Message-ID: <20130715184124.GN4387@xiaoyu.lan> On Mon, Jul 15, 2013 at 08:04:34PM +0200, Andreas Eversberg wrote: > yes, every patch works. i did a "git reset --hard" for scrolling back > patch by patch. is there a more elegant way to test every patch? With git 1.8 one can do git rebase -i -x "CMD FOR EVERY CHANGE" origin/master, the script I posted yesterday is using it From jolly at eversberg.eu Mon Jul 15 08:35:32 2013 From: jolly at eversberg.eu (Andreas Eversberg) Date: Mon, 15 Jul 2013 10:35:32 +0200 Subject: [PATCH 3/7] Remove direct handling of L1 prims and bts_model_* calls from sysmo code In-Reply-To: <1373877336-27883-1-git-send-email-jolly@eversberg.eu> References: <1373877336-27883-1-git-send-email-jolly@eversberg.eu> Message-ID: <1373877336-27883-3-git-send-email-jolly@eversberg.eu> Instead of handling primitves itself, sysmo-bts code sends and receives PH-/MPH-/TCH primitves to and from common code. --- src/osmo-bts-sysmo/l1_if.c | 1092 +++++++++++++++++-------------------- src/osmo-bts-sysmo/l1_if.h | 13 +- src/osmo-bts-sysmo/main.c | 3 +- src/osmo-bts-sysmo/oml.c | 46 +- src/osmo-bts-sysmo/sysmobts_vty.c | 94 ---- src/osmo-bts-sysmo/tch.c | 117 +--- 6 files changed, 559 insertions(+), 806 deletions(-) diff --git a/src/osmo-bts-sysmo/l1_if.c b/src/osmo-bts-sysmo/l1_if.c index 6efb9d6..f2e4440 100644 --- a/src/osmo-bts-sysmo/l1_if.c +++ b/src/osmo-bts-sysmo/l1_if.c @@ -32,21 +32,17 @@ #include #include #include -#include -#include #include #include -#include - #include #include #include -#include #include #include #include #include +#include #include #include @@ -63,98 +59,6 @@ extern int pcu_direct; #define MIN_QUAL_RACH 5.0f /* at least 5 dB C/I */ #define MIN_QUAL_NORM -0.5f /* at least -1 dB C/I */ -/* mapping from femtobts L1 SAPI to GSMTAP channel type */ -static const uint8_t l1sapi2gsmtap_cht[GsmL1_Sapi_NUM] = { - [GsmL1_Sapi_Idle] = 255, - [GsmL1_Sapi_Fcch] = 255, - [GsmL1_Sapi_Sch] = 255, - [GsmL1_Sapi_Sacch] = GSMTAP_CHANNEL_SDCCH | GSMTAP_CHANNEL_ACCH, - [GsmL1_Sapi_Sdcch] = GSMTAP_CHANNEL_SDCCH, - [GsmL1_Sapi_Bcch] = GSMTAP_CHANNEL_BCCH, - [GsmL1_Sapi_Pch] = GSMTAP_CHANNEL_PCH, - [GsmL1_Sapi_Agch] = GSMTAP_CHANNEL_AGCH, - [GsmL1_Sapi_Cbch] = GSMTAP_CHANNEL_CBCH51, - [GsmL1_Sapi_Rach] = GSMTAP_CHANNEL_RACH, - [GsmL1_Sapi_TchF] = 255, - [GsmL1_Sapi_FacchF] = GSMTAP_CHANNEL_TCH_F, - [GsmL1_Sapi_TchH] = 255, - [GsmL1_Sapi_FacchH] = GSMTAP_CHANNEL_TCH_H, - [GsmL1_Sapi_Nch] = GSMTAP_CHANNEL_CCCH, - [GsmL1_Sapi_Pdtch] = GSMTAP_CHANNEL_PACCH, - [GsmL1_Sapi_Pacch] = GSMTAP_CHANNEL_PACCH, - [GsmL1_Sapi_Pbcch] = 255, - [GsmL1_Sapi_Pagch] = 255, - [GsmL1_Sapi_Ppch] = 255, - [GsmL1_Sapi_Pnch] = 255, - [GsmL1_Sapi_Ptcch] = GSMTAP_CHANNEL_PTCCH, - [GsmL1_Sapi_Prach] = 255, -}; - -static void tx_to_gsmtap(struct femtol1_hdl *fl1h, struct msgb *msg) -{ - struct gsm_bts_trx *trx = fl1h->priv; - GsmL1_Prim_t *l1p = msgb_l1prim(msg); - GsmL1_PhDataReq_t *data_req = &l1p->u.phDataReq; - - if (fl1h->gsmtap) { - uint8_t ss, chan_type; - if (data_req->subCh == 0x1f) - ss = 0; - else - ss = data_req->subCh; - - if (!(fl1h->gsmtap_sapi_mask & (1 << data_req->sapi))) - return; - - chan_type = l1sapi2gsmtap_cht[data_req->sapi]; - if (chan_type == 255) - return; - - gsmtap_send(fl1h->gsmtap, trx->arfcn, data_req->u8Tn, - chan_type, ss, data_req->u32Fn, 0, 0, - data_req->msgUnitParam.u8Buffer, - data_req->msgUnitParam.u8Size); - } -} - -static void ul_to_gsmtap(struct femtol1_hdl *fl1h, struct msgb *msg) -{ - struct gsm_bts_trx *trx = fl1h->priv; - GsmL1_Prim_t *l1p = msgb_l1prim(msg); - GsmL1_PhDataInd_t *data_ind = &l1p->u.phDataInd; - int skip = 0; - - if (fl1h->gsmtap) { - uint8_t ss, chan_type; - if (data_ind->subCh == 0x1f) - ss = 0; - else - ss = data_ind->subCh; - - if (!(fl1h->gsmtap_sapi_mask & (1 << data_ind->sapi))) - return; - - chan_type = l1sapi2gsmtap_cht[data_ind->sapi]; - if (chan_type == 255) - return; - if (chan_type == GSMTAP_CHANNEL_PACCH - || chan_type == GSMTAP_CHANNEL_PDCH) { - if (data_ind->msgUnitParam.u8Buffer[0] - != GsmL1_PdtchPlType_Full) - return; - skip = 1; - } - - gsmtap_send(fl1h->gsmtap, trx->arfcn | GSMTAP_ARFCN_F_UPLINK, - data_ind->u8Tn, chan_type, ss, data_ind->u32Fn, - data_ind->measParam.fRssi, - data_ind->measParam.fLinkQuality, - data_ind->msgUnitParam.u8Buffer + skip, - data_ind->msgUnitParam.u8Size - skip); - } -} - - struct wait_l1_conf { struct llist_head list; /* internal linked list */ struct osmo_timer_list timer; /* timer for L1 timeout */ @@ -314,74 +218,442 @@ empty_req_from_rts_ind(GsmL1_Prim_t *l1p, return empty_req; } -/* obtain a ptr to the lapdm_channel for a given hLayer2 */ -static struct lapdm_channel * -get_lapdm_chan_by_hl2(struct gsm_bts_trx *trx, uint32_t hLayer2) -{ - struct gsm_lchan *lchan; +static const uint8_t fill_frame[GSM_MACBLOCK_LEN] = { + 0x03, 0x03, 0x01, 0x2B, 0x2B, 0x2B, 0x2B, 0x2B, 0x2B, 0x2B, + 0x2B, 0x2B, 0x2B, 0x2B, 0x2B, 0x2B, 0x2B, 0x2B, 0x2B, 0x2B, + 0x2B, 0x2B, 0x2B +}; - lchan = l1if_hLayer_to_lchan(trx, hLayer2); - if (!lchan) - return NULL; +static void dump_meas_res(int ll, GsmL1_MeasParam_t *m) +{ + LOGPC(DL1C, ll, ", Meas: RSSI %-3.2f dBm, Qual %-3.2f dB, " + "BER %-3.2f, Timing %d\n", m->fRssi, m->fLinkQuality, + m->fBer, m->i16BurstTiming); +} - return &lchan->lapdm_ch; +static int process_meas_res(struct gsm_bts_trx *trx, uint8_t chan_nr, + GsmL1_MeasParam_t *m) +{ + struct osmo_phsap_prim l1sap; + + memset(&l1sap, 0, sizeof(l1sap)); + osmo_prim_init(&l1sap.oph, SAP_GSM_PH, PRIM_MPH_INFO, + PRIM_OP_INDICATION, NULL); + l1sap.u.info.type = PRIM_INFO_MEAS; + l1sap.u.info.u.meas_ind.chan_nr = chan_nr; + l1sap.u.info.u.meas_ind.ta_offs_qbits = m->i16BurstTiming; + l1sap.u.info.u.meas_ind.ber10k = (unsigned int) (m->fBer * 100); + l1sap.u.info.u.meas_ind.inv_rssi = (uint8_t) (m->fRssi * -1); + + return l1sap_up(trx, &l1sap); } -/* check if the message is a GSM48_MT_RR_CIPH_M_CMD, and if yes, enable - * uni-directional de-cryption on the uplink. We need this ugly layering - * violation as we have no way of passing down L3 metadata (RSL CIPHERING CMD) - * to this point in L1 */ -static int check_for_ciph_cmd(struct femtol1_hdl *fl1h, - struct msgb *msg, struct gsm_lchan *lchan) +/* primitive from common part */ +int bts_model_l1sap_down(struct gsm_bts_trx *trx, struct osmo_phsap_prim *l1sap) { + struct femtol1_hdl *fl1 = trx_femtol1_hdl(trx); + struct msgb *msg = l1sap->oph.msg; + uint32_t u32Fn; + uint8_t u8Tn, subCh, u8BlockNbr = 0, sapi, ss; + uint8_t chan_nr, link_id; + int rc = 0; + struct msgb *nmsg = NULL; + GsmL1_Prim_t *l1p; + struct gsm_lchan *lchan; + + switch (OSMO_PRIM_HDR(&l1sap->oph)) { + case OSMO_PRIM(PRIM_PH_DATA, PRIM_OP_REQUEST): + if (!msg) { + LOGP(DL1C, LOGL_FATAL, "PH-DATA.req without msg. " + "Please fix!\n"); + abort(); + } + chan_nr = l1sap->u.data.chan_nr; + link_id = l1sap->u.data.link_id; + u32Fn = l1sap->u.data.fn; + u8Tn = L1SAP_CHAN2TS(chan_nr); + subCh = 0x1f; + if (L1SAP_IS_LINK_SACCH(link_id)) { + sapi = GsmL1_Sapi_Sacch; + if (!L1SAP_IS_CHAN_TCHF(chan_nr)) + subCh = l1sap_chan2ss(chan_nr); + } else if (L1SAP_IS_CHAN_TCHF(chan_nr)) { + if (trx->ts[u8Tn].pchan == GSM_PCHAN_PDCH) { + if (L1SAP_IS_PTCCH(u32Fn)) { + sapi = GsmL1_Sapi_Ptcch; + u8BlockNbr = L1SAP_FN2PTCCHBLOCK(u32Fn); + } else { + sapi = GsmL1_Sapi_Pdtch; + u8BlockNbr = L1SAP_FN2MACBLOCK(u32Fn); + } + } else { + sapi = GsmL1_Sapi_FacchF; + u8BlockNbr = (u32Fn % 13) >> 2; + } + } else if (L1SAP_IS_CHAN_TCHH(chan_nr)) { + subCh = L1SAP_CHAN2SS_TCHH(chan_nr); + sapi = GsmL1_Sapi_FacchH; + u8BlockNbr = (u32Fn % 26) >> 3; + } else if (L1SAP_IS_CHAN_SDCCH4(chan_nr)) { + subCh = L1SAP_CHAN2SS_SDCCH4(chan_nr); + sapi = GsmL1_Sapi_Sdcch; + } else if (L1SAP_IS_CHAN_SDCCH8(chan_nr)) { + subCh = L1SAP_CHAN2SS_SDCCH8(chan_nr); + sapi = GsmL1_Sapi_Sdcch; + } else if (L1SAP_IS_CHAN_BCCH(chan_nr)) { + sapi = GsmL1_Sapi_Bcch; + } else if (L1SAP_IS_CHAN_AGCH_PCH(chan_nr)) { +#warning Set BS_AG_BLKS_RES + /* The sapi depends on DSP configuration, not + * on the actual SYSTEM INFORMATION 3. */ + u8BlockNbr = L1SAP_FN2CCCHBLOCK(u32Fn); + if (u8BlockNbr >= 1) + sapi = GsmL1_Sapi_Pch; + else + sapi = GsmL1_Sapi_Agch; + } else { + LOGP(DL1C, LOGL_NOTICE, "unknown prim %d op %d " + "chan_nr %d link_id %d\n", l1sap->oph.primitive, + l1sap->oph.operation, chan_nr, link_id); + rc = -EINVAL; + goto done; + } + + msgb_pull(msg, sizeof(*l1sap)); + + /* create new message */ + nmsg = l1p_msgb_alloc(); + l1p = msgb_l1prim(nmsg); + if (msg->len) { + /* data request */ + GsmL1_PhDataReq_t *data_req = &l1p->u.phDataReq; + GsmL1_MsgUnitParam_t *msu_param; + + l1p->id = GsmL1_PrimId_PhDataReq; + + data_req->hLayer1 = fl1->hLayer1; + data_req->u8Tn = u8Tn; + data_req->u32Fn = u32Fn; + data_req->sapi = sapi; + data_req->subCh = subCh; + data_req->u8BlockNbr = u8BlockNbr; + msu_param = &data_req->msgUnitParam; + msu_param->u8Size = msg->len; + memcpy(msu_param->u8Buffer, msg->data, msg->len); + } else { + /* empty frame */ + GsmL1_PhEmptyFrameReq_t *empty_req = + &l1p->u.phEmptyFrameReq; + + l1p->id = GsmL1_PrimId_PhEmptyFrameReq; + + empty_req->hLayer1 = fl1->hLayer1; + empty_req->u8Tn = u8Tn; + empty_req->u32Fn = u32Fn; + empty_req->sapi = sapi; + empty_req->subCh = subCh; + empty_req->u8BlockNbr = u8BlockNbr; + } + + /* send message to DSP's queue */ + osmo_wqueue_enqueue(&fl1->write_q[MQ_L1_WRITE], nmsg); + break; + case OSMO_PRIM(PRIM_TCH, PRIM_OP_REQUEST): + chan_nr = l1sap->u.tch.chan_nr; + u32Fn = l1sap->u.tch.fn; + u8Tn = L1SAP_CHAN2TS(chan_nr); + u8BlockNbr = (u32Fn % 13) >> 2; + if (L1SAP_IS_CHAN_TCHH(chan_nr)) { + ss = subCh = L1SAP_CHAN2SS_TCHH(chan_nr); + sapi = GsmL1_Sapi_TchH; + } else { + subCh = 0x1f; + ss = 0; + sapi = GsmL1_Sapi_TchF; + } + + lchan = &trx->ts[u8Tn].lchan[ss]; + + /* create new message and fill data */ + if (msg) { + msgb_pull(msg, sizeof(*l1sap)); + /* create new message */ + nmsg = l1p_msgb_alloc(); + if (!nmsg) { + rc = -ENOMEM; + goto done; + } + l1p = msgb_l1prim(nmsg); + l1if_tch_encode(lchan, + l1p->u.phDataReq.msgUnitParam.u8Buffer, + &l1p->u.phDataReq.msgUnitParam.u8Size, + msg->data, msg->len); + } + + /* no message/data, we generate an empty traffic msg */ + if (!nmsg) + nmsg = gen_empty_tch_msg(lchan); + + /* no traffic message, we generate an empty msg */ + if (!nmsg) { + nmsg = l1p_msgb_alloc(); + if (!nmsg) { + rc = -ENOMEM; + goto done; + } + } + + l1p = msgb_l1prim(nmsg); - /* only do this if we are in the right state */ - switch (lchan->ciph_state) { - case LCHAN_CIPH_NONE: - case LCHAN_CIPH_RX_REQ: + /* if we provide data, or if data is already in nmsg */ + if (l1p->u.phDataReq.msgUnitParam.u8Size) { + /* data request */ + GsmL1_PhDataReq_t *data_req = &l1p->u.phDataReq; + + l1p->id = GsmL1_PrimId_PhDataReq; + + data_req->hLayer1 = fl1->hLayer1; + data_req->u8Tn = u8Tn; + data_req->u32Fn = u32Fn; + data_req->sapi = sapi; + data_req->subCh = subCh; + data_req->u8BlockNbr = u8BlockNbr; + } else { + /* empty frame */ + GsmL1_PhEmptyFrameReq_t *empty_req = + &l1p->u.phEmptyFrameReq; + + l1p->id = GsmL1_PrimId_PhEmptyFrameReq; + + empty_req->hLayer1 = fl1->hLayer1; + empty_req->u8Tn = u8Tn; + empty_req->u32Fn = u32Fn; + empty_req->sapi = sapi; + empty_req->subCh = subCh; + empty_req->u8BlockNbr = u8BlockNbr; + } + /* send message to DSP's queue */ + osmo_wqueue_enqueue(&fl1->write_q[MQ_L1_WRITE], nmsg); + break; + case OSMO_PRIM(PRIM_MPH_INFO, PRIM_OP_REQUEST): + switch (l1sap->u.info.type) { + case PRIM_INFO_ACT_CIPH: + chan_nr = l1sap->u.info.u.ciph_req.chan_nr; + u8Tn = L1SAP_CHAN2TS(chan_nr); + ss = l1sap_chan2ss(chan_nr); + lchan = &trx->ts[u8Tn].lchan[ss]; + if (l1sap->u.info.u.ciph_req.downlink) { + l1if_set_ciphering(fl1, lchan, 1); + lchan->ciph_state = LCHAN_CIPH_RX_REQ; + } + if (l1sap->u.info.u.ciph_req.uplink) { + l1if_set_ciphering(fl1, lchan, 0); + lchan->ciph_state = LCHAN_CIPH_TXRX_REQ; + } + break; + case PRIM_INFO_ACTIVATE: + case PRIM_INFO_DEACTIVATE: + case PRIM_INFO_MODIFY: + chan_nr = l1sap->u.info.u.act_req.chan_nr; + u8Tn = L1SAP_CHAN2TS(chan_nr); + ss = l1sap_chan2ss(chan_nr); + lchan = &trx->ts[u8Tn].lchan[ss]; + if (l1sap->u.info.type == PRIM_INFO_ACTIVATE) + l1if_rsl_chan_act(lchan); + else if (l1sap->u.info.type == PRIM_INFO_MODIFY) + l1if_rsl_mode_modify(lchan); + else if (l1sap->u.info.u.act_req.sacch_only) + l1if_rsl_deact_sacch(lchan); + else + l1if_rsl_chan_rel(lchan); + break; + default: + LOGP(DL1C, LOGL_NOTICE, "unknown MPH-INFO.req %d\n", + l1sap->u.info.type); + rc = -EINVAL; + goto done; + } break; default: - return 0; + LOGP(DL1C, LOGL_NOTICE, "unknown prim %d op %d\n", + l1sap->oph.primitive, l1sap->oph.operation); + rc = -EINVAL; + goto done; } - /* First byte (Address Field) of LAPDm header) */ - if (msg->data[0] != 0x03) - return 0; - /* First byte (protocol discriminator) of RR */ - if ((msg->data[3] & 0xF) != GSM48_PDISC_RR) - return 0; - /* 2nd byte (msg type) of RR */ - if ((msg->data[4] & 0x3F) != GSM48_MT_RR_CIPH_M_CMD) +done: + if (msg) + msgb_free(msg); + return rc; +} + +static int handle_mph_time_ind(struct femtol1_hdl *fl1, + GsmL1_MphTimeInd_t *time_ind) +{ + struct gsm_bts_trx *trx = fl1->priv; + struct gsm_bts *bts = trx->bts; + struct osmo_phsap_prim l1sap; + uint32_t fn; + + /* increment the primitive count for the alive timer */ + fl1->alive_prim_cnt++; + + /* ignore every time indication, except for c0 */ + if (trx != bts->c0) { return 0; + } - lchan->ciph_state = LCHAN_CIPH_RX_REQ; - l1if_set_ciphering(fl1h, lchan, 0); + fn = time_ind->u32Fn; - return 1; + memset(&l1sap, 0, sizeof(l1sap)); + osmo_prim_init(&l1sap.oph, SAP_GSM_PH, PRIM_MPH_INFO, + PRIM_OP_INDICATION, NULL); + l1sap.u.info.type = PRIM_INFO_TIME; + l1sap.u.info.u.time_ind.fn = fn; + + return l1sap_up(trx, &l1sap); } -static const uint8_t fill_frame[GSM_MACBLOCK_LEN] = { - 0x03, 0x03, 0x01, 0x2B, 0x2B, 0x2B, 0x2B, 0x2B, 0x2B, 0x2B, - 0x2B, 0x2B, 0x2B, 0x2B, 0x2B, 0x2B, 0x2B, 0x2B, 0x2B, 0x2B, - 0x2B, 0x2B, 0x2B -}; +static uint8_t chan_nr_by_sapi(enum gsm_phys_chan_config pchan, + GsmL1_Sapi_t sapi, GsmL1_SubCh_t subCh, + uint8_t u8Tn, uint32_t u32Fn) +{ + uint8_t cbits = 0; + switch (sapi) { + case GsmL1_Sapi_Bcch: + cbits = 0x10; + break; + case GsmL1_Sapi_Sacch: + switch(pchan) { + case GSM_PCHAN_TCH_F: + cbits = 0x01; + break; + case GSM_PCHAN_TCH_H: + cbits = 0x02 + subCh; + break; + case GSM_PCHAN_CCCH_SDCCH4: + cbits = 0x04 + subCh; + break; + case GSM_PCHAN_SDCCH8_SACCH8C: + cbits = 0x08 + subCh; + break; + default: + LOGP(DL1C, LOGL_ERROR, "SACCH for pchan %d?\n", + pchan); + return 0; + } + break; + case GsmL1_Sapi_Sdcch: + switch(pchan) { + case GSM_PCHAN_CCCH_SDCCH4: + cbits = 0x04 + subCh; + break; + case GSM_PCHAN_SDCCH8_SACCH8C: + cbits = 0x08 + subCh; + break; + default: + LOGP(DL1C, LOGL_ERROR, "SDCCH for pchan %d?\n", + pchan); + return 0; + } + break; + case GsmL1_Sapi_Agch: + case GsmL1_Sapi_Pch: + cbits = 0x12; + break; + case GsmL1_Sapi_TchF: + cbits = 0x01; + break; + case GsmL1_Sapi_TchH: + cbits = 0x02 + subCh; + break; + case GsmL1_Sapi_FacchF: + cbits = 0x01; + break; + case GsmL1_Sapi_FacchH: + cbits = 0x02 + subCh; + break; + case GsmL1_Sapi_Pdtch: + case GsmL1_Sapi_Pacch: + switch(pchan) { + case GSM_PCHAN_PDCH: + cbits = 0x01; + break; + default: + LOGP(DL1C, LOGL_ERROR, "PDTCH for pchan %d?\n", + pchan); + return 0; + } + break; + case GsmL1_Sapi_Ptcch: + if (!L1SAP_IS_PTCCH(u32Fn)) { + LOGP(DL1C, LOGL_FATAL, "Not expecting PTCCH at frame " + "number other than 12, got it at %u (%u). " + "Please fix!\n", u32Fn % 52, u32Fn); + abort(); + } + switch(pchan) { + case GSM_PCHAN_PDCH: + cbits = 0x01; + break; + default: + LOGP(DL1C, LOGL_ERROR, "PTCCH for pchan %d?\n", + pchan); + return 0; + } + break; + default: + return 0; + } + + return (cbits << 3) | u8Tn; +} static int handle_ph_readytosend_ind(struct femtol1_hdl *fl1, - GsmL1_PhReadyToSendInd_t *rts_ind) + GsmL1_PhReadyToSendInd_t *rts_ind, + struct msgb *l1p_msg) { struct gsm_bts_trx *trx = fl1->priv; struct gsm_bts *bts = trx->bts; - struct gsm_bts_role_bts *btsb = bts->role; + struct osmo_phsap_prim *l1sap; + struct gsm_time g_time; + uint8_t chan_nr, link_id; + uint32_t fn; + int rc; struct msgb *resp_msg; GsmL1_PhDataReq_t *data_req; GsmL1_MsgUnitParam_t *msu_param; - struct lapdm_entity *le; - struct gsm_lchan *lchan; - struct gsm_time g_time; uint32_t t3p; - uint8_t *si; - struct osmo_phsap_prim pp; - int rc; + + /* in case we need to forward primitive to common part*/ + chan_nr = chan_nr_by_sapi(trx->ts[rts_ind->u8Tn].pchan, rts_ind->sapi, + rts_ind->subCh, rts_ind->u8Tn, rts_ind->u32Fn); + if (chan_nr) { + fn = rts_ind->u32Fn; + if (rts_ind->sapi == GsmL1_Sapi_Sacch) + link_id = 0x40; + else + link_id = 0; + rc = msgb_trim(l1p_msg, sizeof(*l1sap)); + if (rc < 0) + MSGB_ABORT(l1p_msg, "No room for primitive\n"); + l1sap = msgb_l1sap_prim(l1p_msg); + if (rts_ind->sapi == GsmL1_Sapi_TchF + || rts_ind->sapi == GsmL1_Sapi_TchH) { + osmo_prim_init(&l1sap->oph, SAP_GSM_PH, PRIM_TCH_RTS, + PRIM_OP_INDICATION, l1p_msg); + l1sap->u.tch.chan_nr = chan_nr; + l1sap->u.tch.fn = fn; + } else { + osmo_prim_init(&l1sap->oph, SAP_GSM_PH, PRIM_PH_RTS, + PRIM_OP_INDICATION, l1p_msg); + l1sap->u.data.link_id = link_id; + l1sap->u.data.chan_nr = chan_nr; + l1sap->u.data.fn = fn; + } + + return l1sap_up(trx, l1sap); + } gsm_fn2gsmtime(&g_time, rts_ind->u32Fn); @@ -389,57 +661,6 @@ static int handle_ph_readytosend_ind(struct femtol1_hdl *fl1, g_time.t1, g_time.t2, g_time.t3, get_value_string(femtobts_l1sapi_names, rts_ind->sapi)); - /* In case of TCH downlink trasnmission, we already have a l1 - * primitive msgb pre-allocated and pre-formatted in the - * dl_tch_queue. All we need to do is to pull it off the queue - * and transmit it */ - switch (rts_ind->sapi) { - case GsmL1_Sapi_TchF: - case GsmL1_Sapi_TchH: - /* resolve the L2 entity using rts_ind->hLayer2 */ - lchan = l1if_hLayer_to_lchan(trx, rts_ind->hLayer2); - if (!lchan) - break; - - if (!lchan->loopback && lchan->abis_ip.rtp_socket) { - osmo_rtp_socket_poll(lchan->abis_ip.rtp_socket); - /* FIXME: we _assume_ that we never miss TDMA - * frames and that we always get to this point - * for every to-be-transmitted voice frame. A - * better solution would be to compute - * rx_user_ts based on how many TDMA frames have - * elapsed since the last call */ - lchan->abis_ip.rtp_socket->rx_user_ts += GSM_RTP_DURATION; - } - /* get a msgb from the dl_tx_queue */ - resp_msg = msgb_dequeue(&lchan->dl_tch_queue); - /* if there is none, try to generate empty TCH frame - * like AMR SID_BAD */ - if (!resp_msg) { - LOGP(DL1C, LOGL_DEBUG, "%s DL TCH Tx queue underrun\n", - gsm_lchan_name(lchan)); - resp_msg = gen_empty_tch_msg(lchan); - /* if there really is none, break here and send empty */ - if (!resp_msg) - break; - } - - /* fill header */ - data_req_from_rts_ind(msgb_l1prim(resp_msg), rts_ind); - /* actually transmit it */ - goto tx; - break; - case GsmL1_Sapi_Pdtch: - case GsmL1_Sapi_Pacch: - return pcu_tx_rts_req(&trx->ts[rts_ind->u8Tn], 0, - rts_ind->u32Fn, rts_ind->u16Arfcn, rts_ind->u8BlockNbr); - case GsmL1_Sapi_Ptcch: - return pcu_tx_rts_req(&trx->ts[rts_ind->u8Tn], 1, - rts_ind->u32Fn, rts_ind->u16Arfcn, rts_ind->u8BlockNbr); - default: - break; - } - /* in all other cases, we need to allocate a new PH-DATA.ind * primitive msgb and start to fill it */ resp_msg = l1p_msgb_alloc(); @@ -451,6 +672,7 @@ static int handle_ph_readytosend_ind(struct femtol1_hdl *fl1, switch (rts_ind->sapi) { case GsmL1_Sapi_Sch: + gsm_fn2gsmtime(&g_time, rts_ind->u32Fn); /* compute T3prime */ t3p = (g_time.t3 - 1) / 10; /* fill SCH burst with data */ @@ -460,87 +682,6 @@ static int handle_ph_readytosend_ind(struct femtol1_hdl *fl1, msu_param->u8Buffer[2] = (g_time.t1 << 7) | (g_time.t2 << 2) | (t3p >> 1); msu_param->u8Buffer[3] = (t3p & 1); break; - case GsmL1_Sapi_Bcch: - /* get them from bts->si_buf[] */ - si = bts_sysinfo_get(bts, &g_time); - if (si) - memcpy(msu_param->u8Buffer, si, GSM_MACBLOCK_LEN); - else - memcpy(msu_param->u8Buffer, fill_frame, GSM_MACBLOCK_LEN); - break; - case GsmL1_Sapi_Sacch: - /* resolve the L2 entity using rts_ind->hLayer2 */ - lchan = l1if_hLayer_to_lchan(trx, rts_ind->hLayer2); - le = &lchan->lapdm_ch.lapdm_acch; - /* if the DSP is taking care of power control - * (ul_power_target==0), then this value will be - * overridden. */ - msu_param->u8Buffer[0] = lchan->ms_power; - rc = lapdm_phsap_dequeue_prim(le, &pp); - if (rc < 0) { - /* No SACCH data from LAPDM pending, send SACCH filling */ - uint8_t *si = lchan_sacch_get(lchan, &g_time); - if (si) { - /* The +2 is empty space where the DSP inserts the L1 hdr */ - memcpy(msu_param->u8Buffer+2, si, GSM_MACBLOCK_LEN-2); - } else - memcpy(msu_param->u8Buffer+2, fill_frame, GSM_MACBLOCK_LEN-2); - } else { - /* The +2 is empty space where the DSP inserts the L1 hdr */ - memcpy(msu_param->u8Buffer+2, pp.oph.msg->data, GSM_MACBLOCK_LEN-2); - msgb_free(pp.oph.msg); - } - break; - case GsmL1_Sapi_Sdcch: - /* resolve the L2 entity using rts_ind->hLayer2 */ - lchan = l1if_hLayer_to_lchan(trx, rts_ind->hLayer2); - le = &lchan->lapdm_ch.lapdm_dcch; - rc = lapdm_phsap_dequeue_prim(le, &pp); - if (rc < 0) - memcpy(msu_param->u8Buffer, fill_frame, GSM_MACBLOCK_LEN); - else { - memcpy(msu_param->u8Buffer, pp.oph.msg->data, GSM_MACBLOCK_LEN); - /* check if it is a RR CIPH MODE CMD. if yes, enable RX ciphering */ - check_for_ciph_cmd(fl1, pp.oph.msg, lchan); - msgb_free(pp.oph.msg); - } - break; - case GsmL1_Sapi_Agch: - /* special queue of messages from IMM ASS CMD */ - { - struct msgb *msg = bts_agch_dequeue(bts); - if (!msg) - memcpy(msu_param->u8Buffer, fill_frame, GSM_MACBLOCK_LEN); - else { - memcpy(msu_param->u8Buffer, msg->data, msg->len); - msgb_free(msg); - } - } - break; - case GsmL1_Sapi_Pch: - rc = paging_gen_msg(btsb->paging_state, msu_param->u8Buffer, &g_time); - break; - case GsmL1_Sapi_TchF: - case GsmL1_Sapi_TchH: - /* only hit in case we have a RTP underflow, as real TCH - * frames are handled way above */ - goto empty_frame; - break; - case GsmL1_Sapi_FacchF: - case GsmL1_Sapi_FacchH: - /* resolve the L2 entity using rts_ind->hLayer2 */ - lchan = l1if_hLayer_to_lchan(trx, rts_ind->hLayer2); - le = &lchan->lapdm_ch.lapdm_dcch; - rc = lapdm_phsap_dequeue_prim(le, &pp); - if (rc < 0) - goto empty_frame; - else { - memcpy(msu_param->u8Buffer, pp.oph.msg->data, GSM_MACBLOCK_LEN); - /* check if it is a RR CIPH MODE CMD. if yes, enable RX ciphering */ - check_for_ciph_cmd(fl1, pp.oph.msg, lchan); - msgb_free(pp.oph.msg); - } - break; case GsmL1_Sapi_Prach: goto empty_frame; break; @@ -548,13 +689,12 @@ static int handle_ph_readytosend_ind(struct femtol1_hdl *fl1, memcpy(msu_param->u8Buffer, fill_frame, GSM_MACBLOCK_LEN); break; } -tx: - - tx_to_gsmtap(fl1, resp_msg); +tx: /* transmit */ osmo_wqueue_enqueue(&fl1->write_q[MQ_L1_WRITE], resp_msg); + msgb_free(l1p_msg); return 0; empty_frame: @@ -564,143 +704,38 @@ empty_frame: goto tx; } -static int handle_mph_time_ind(struct femtol1_hdl *fl1, - GsmL1_MphTimeInd_t *time_ind) -{ - struct gsm_bts_trx *trx = fl1->priv; - struct gsm_bts *bts = trx->bts; - struct gsm_bts_role_bts *btsb = bts->role; - - int frames_expired = time_ind->u32Fn - fl1->gsm_time.fn; - - /* update time on PCU interface */ - pcu_tx_time_ind(time_ind->u32Fn); - - /* Update our data structures with the current GSM time */ - gsm_fn2gsmtime(&fl1->gsm_time, time_ind->u32Fn); - - /* check if the measurement period of some lchan has ended - * and pre-compute the respective measurement */ - trx_meas_check_compute(fl1->priv, time_ind->u32Fn -1); - - /* increment the primitive count for the alive timer */ - fl1->alive_prim_cnt++; - - /* increment number of RACH slots that have passed by since the - * last time indication */ - if (trx == bts->c0) { - unsigned int num_rach_per_frame; - /* 27 / 51 taken from TS 05.01 Figure 3 */ - if (bts->c0->ts[0].pchan == GSM_PCHAN_CCCH_SDCCH4) - num_rach_per_frame = 27; - else - num_rach_per_frame = 51; - - btsb->load.rach.total += frames_expired * num_rach_per_frame; - } - - return 0; -} - -/* determine LAPDm entity inside LAPDm channel for given L1 sapi */ -static struct lapdm_entity *le_by_l1_sapi(struct lapdm_channel *lc, GsmL1_Sapi_t sapi) -{ - switch (sapi) { - case GsmL1_Sapi_Sacch: - return &lc->lapdm_acch; - default: - return &lc->lapdm_dcch; - } -} - -static uint8_t gen_link_id(GsmL1_Sapi_t l1_sapi, uint8_t lapdm_sapi) -{ - uint8_t c_bits = 0; - - if (l1_sapi == GsmL1_Sapi_Sacch) - c_bits = 0x40; - - return c_bits | (lapdm_sapi & 7); -} - -static void dump_meas_res(int ll, GsmL1_MeasParam_t *m) -{ - LOGPC(DL1C, ll, ", Meas: RSSI %-3.2f dBm, Qual %-3.2f dB, " - "BER %-3.2f, Timing %d\n", m->fRssi, m->fLinkQuality, - m->fBer, m->i16BurstTiming); -} - -static int process_meas_res(struct gsm_lchan *lchan, GsmL1_MeasParam_t *m) -{ - struct bts_ul_meas ulm; - - /* in the GPRS case we are not interested in measurement - * processing. The PCU will take care of it */ - if (lchan->type == GSM_LCHAN_PDTCH) - return 0; - - ulm.ta_offs_qbits = m->i16BurstTiming; - ulm.ber10k = (unsigned int) (m->fBer * 100); - ulm.inv_rssi = (uint8_t) (m->fRssi * -1); - - return lchan_new_ul_meas(lchan, &ulm); -} - -/* process radio link timeout counter S */ -static void radio_link_timeout(struct gsm_lchan *lchan, int bad_frame) -{ - struct gsm_bts_role_bts *btsb = lchan->ts->trx->bts->role; - - /* if link loss criterion already reached */ - if (lchan->s == 0) { - DEBUGP(DMEAS, "%s radio link counter S already 0.\n", - gsm_lchan_name(lchan)); - return; - } - - if (bad_frame) { - /* count down radio link counter S */ - lchan->s--; - DEBUGP(DMEAS, "%s counting down radio link counter S=%d\n", - gsm_lchan_name(lchan), lchan->s); - if (lchan->s == 0) - rsl_tx_conn_fail(lchan, RSL_ERR_RADIO_LINK_FAIL); - return; - } - - if (lchan->s < btsb->radio_link_timeout) { - /* count up radio link counter S */ - lchan->s += 2; - if (lchan->s > btsb->radio_link_timeout) - lchan->s = btsb->radio_link_timeout; - DEBUGP(DMEAS, "%s counting up radio link counter S=%d\n", - gsm_lchan_name(lchan), lchan->s); - } -} - static int handle_ph_data_ind(struct femtol1_hdl *fl1, GsmL1_PhDataInd_t *data_ind, struct msgb *l1p_msg) { struct gsm_bts_trx *trx = fl1->priv; - struct osmo_phsap_prim pp; - struct gsm_lchan *lchan; - struct lapdm_entity *le; - struct msgb *msg; - int rc = 0; - - ul_to_gsmtap(fl1, l1p_msg); + struct osmo_phsap_prim *l1sap; + uint8_t chan_nr, link_id; + uint32_t fn; + uint8_t *data, len; + int rc; - lchan = l1if_hLayer_to_lchan(fl1->priv, data_ind->hLayer2); - if (!lchan) { - LOGP(DL1C, LOGL_ERROR, "unable to resolve lchan by hLayer2\n"); - return -ENODEV; + /* chan_nr and link_id */ + chan_nr = chan_nr_by_sapi(trx->ts[data_ind->u8Tn].pchan, data_ind->sapi, + data_ind->subCh, data_ind->u8Tn, data_ind->u32Fn); + if (!chan_nr) { + LOGP(DL1C, LOGL_ERROR, "PH-DATA-INDICATION for unknown sapi " + "%d\n", data_ind->sapi); + return ENOTSUP; } + fn = data_ind->u32Fn; + if (data_ind->sapi == GsmL1_Sapi_Sacch) + link_id = 0x40; + else + link_id = 0; - process_meas_res(lchan, &data_ind->measParam); + /* uplink measurement */ + process_meas_res(trx, chan_nr, &data_ind->measParam); if (data_ind->measParam.fLinkQuality < fl1->min_qual_norm - && data_ind->msgUnitParam.u8Size != 0) - return 0; + && data_ind->msgUnitParam.u8Size != 0) { + msgb_free(l1p_msg); + return 0; + } DEBUGP(DL1C, "Rx PH-DATA.ind %s (hL2 %08x): %s", get_value_string(femtobts_l1sapi_names, data_ind->sapi), @@ -709,165 +744,85 @@ static int handle_ph_data_ind(struct femtol1_hdl *fl1, GsmL1_PhDataInd_t *data_i data_ind->msgUnitParam.u8Size)); dump_meas_res(LOGL_DEBUG, &data_ind->measParam); - switch (data_ind->sapi) { - case GsmL1_Sapi_Sacch: - radio_link_timeout(lchan, (data_ind->msgUnitParam.u8Size == 0)); - if (data_ind->msgUnitParam.u8Size == 0) - break; - /* save the SACCH L1 header in the lchan struct for RSL MEAS RES */ - if (data_ind->msgUnitParam.u8Size < 2) { - LOGP(DL1C, LOGL_NOTICE, "SACCH with size %u<2 !?!\n", - data_ind->msgUnitParam.u8Size); - break; - } - /* Some brilliant engineer decided that the ordering of - * fields on the Um interface is different from the - * order of fields in RLS. See TS 04.04 (Chapter 7.2) - * vs. TS 08.58 (Chapter 9.3.10). */ - lchan->meas.l1_info[0] = data_ind->msgUnitParam.u8Buffer[0] << 3; - lchan->meas.l1_info[0] |= ((data_ind->msgUnitParam.u8Buffer[0] >> 5) & 1) << 2; - lchan->meas.l1_info[1] = data_ind->msgUnitParam.u8Buffer[1]; - lchan->meas.flags |= LC_UL_M_F_L1_VALID; - /* fall-through */ - case GsmL1_Sapi_Sdcch: - case GsmL1_Sapi_FacchF: - case GsmL1_Sapi_FacchH: - /* Check and Re-check for the SACCH */ - if (data_ind->msgUnitParam.u8Size == 0) { - LOGP(DL1C, LOGL_NOTICE, "%s %s data is null.\n", - gsm_lchan_name(lchan), - get_value_string(femtobts_l1sapi_names, data_ind->sapi)); - break; - } - - /* if this is the first valid message after enabling Rx - * decryption, we have to enable Tx encryption */ - if (lchan->ciph_state == LCHAN_CIPH_RX_CONF) { - /* HACK: check if it's an I frame, in order to - * ignore some still buffered/queued UI frames received - * before decryption was enabled */ - if (data_ind->msgUnitParam.u8Buffer[0] == 0x01 && - (data_ind->msgUnitParam.u8Buffer[1] & 0x01) == 0) { - l1if_set_ciphering(fl1, lchan, 1); - lchan->ciph_state = LCHAN_CIPH_TXRX_REQ; - } - } - - /* SDCCH, SACCH and FACCH all go to LAPDm */ - le = le_by_l1_sapi(&lchan->lapdm_ch, data_ind->sapi); - /* allocate and fill LAPDm primitive */ - msg = msgb_alloc_headroom(128, 64, "PH-DATA.ind"); - osmo_prim_init(&pp.oph, SAP_GSM_PH, PRIM_PH_DATA, - PRIM_OP_INDICATION, msg); - - /* copy over actual MAC block */ - msg->l2h = msgb_put(msg, data_ind->msgUnitParam.u8Size); - memcpy(msg->l2h, data_ind->msgUnitParam.u8Buffer, - data_ind->msgUnitParam.u8Size); - - /* LAPDm requires those... */ - pp.u.data.chan_nr = gsm_lchan2chan_nr(lchan); - pp.u.data.link_id = gen_link_id(data_ind->sapi, 0); - - /* feed into the LAPDm code of libosmogsm */ - rc = lapdm_phsap_up(&pp.oph, le); - break; - case GsmL1_Sapi_TchF: - case GsmL1_Sapi_TchH: - /* TCH speech frame handling */ - rc = l1if_tch_rx(lchan, l1p_msg); - break; - case GsmL1_Sapi_Pdtch: - case GsmL1_Sapi_Pacch: - /* drop incomplete UL block */ - if (!data_ind->msgUnitParam.u8Size - || data_ind->msgUnitParam.u8Buffer[0] - != GsmL1_PdtchPlType_Full) - break; - /* PDTCH / PACCH frame handling */ - rc = pcu_tx_data_ind(&trx->ts[data_ind->u8Tn], 0, - data_ind->u32Fn, data_ind->u16Arfcn, - data_ind->u8BlockNbr, - data_ind->msgUnitParam.u8Buffer + 1, - data_ind->msgUnitParam.u8Size - 1, - (int8_t) (data_ind->measParam.fRssi)); - break; - case GsmL1_Sapi_Ptcch: - /* PTCCH frame handling */ - rc = pcu_tx_data_ind(&trx->ts[data_ind->u8Tn], 1, - data_ind->u32Fn, data_ind->u16Arfcn, - data_ind->u8BlockNbr, - data_ind->msgUnitParam.u8Buffer, - data_ind->msgUnitParam.u8Size, - (int8_t) (data_ind->measParam.fRssi)); - break; - default: - LOGP(DL1C, LOGL_NOTICE, "Rx PH-DATA.ind for unknown L1 SAPI %s\n", - get_value_string(femtobts_l1sapi_names, data_ind->sapi)); - break; - } - - return rc; + /* check for TCH */ + if (data_ind->sapi == GsmL1_Sapi_TchF + || data_ind->sapi == GsmL1_Sapi_TchH) { + /* TCH speech frame handling */ + return l1if_tch_rx(trx, chan_nr, l1p_msg); + } + + /* get data pointer and length */ + data = data_ind->msgUnitParam.u8Buffer; + len = data_ind->msgUnitParam.u8Size; + /* pull lower header part before data */ + msgb_pull(l1p_msg, data - l1p_msg->data); + /* trim remaining data to it's size, to get rid of upper header part */ + rc = msgb_trim(l1p_msg, len); + if (rc < 0) + MSGB_ABORT(l1p_msg, "No room for primitive data\n"); + l1p_msg->l2h = l1p_msg->data; + /* push new l1 header */ + l1p_msg->l1h = msgb_push(l1p_msg, sizeof(*l1sap)); + /* fill header */ + l1sap = msgb_l1sap_prim(l1p_msg); + osmo_prim_init(&l1sap->oph, SAP_GSM_PH, PRIM_PH_DATA, PRIM_OP_INDICATION, + l1p_msg); + l1sap->u.data.link_id = link_id; + l1sap->u.data.chan_nr = chan_nr; + l1sap->u.data.fn = fn; + + return l1sap_up(trx, l1sap); } -static int handle_ph_ra_ind(struct femtol1_hdl *fl1, GsmL1_PhRaInd_t *ra_ind) +static int handle_ph_ra_ind(struct femtol1_hdl *fl1, GsmL1_PhRaInd_t *ra_ind, + struct msgb *l1p_msg) { struct gsm_bts_trx *trx = fl1->priv; struct gsm_bts *bts = trx->bts; struct gsm_bts_role_bts *btsb = bts->role; - struct osmo_phsap_prim pp; - struct lapdm_channel *lc; - uint8_t acc_delay; + struct osmo_phsap_prim *l1sap; + uint32_t fn; + uint8_t ra, acc_delay; + int rc; /* increment number of busy RACH slots, if required */ if (trx == bts->c0 && ra_ind->measParam.fRssi >= btsb->load.rach.busy_thresh) btsb->load.rach.busy++; - if (ra_ind->measParam.fLinkQuality < fl1->min_qual_rach) + if (ra_ind->measParam.fLinkQuality < fl1->min_qual_rach) { + msgb_free(l1p_msg); return 0; + } - /* increment number of RACH slots with valid RACH burst */ - if (trx == bts->c0) - btsb->load.rach.access++; - - DEBUGP(DL1C, "Rx PH-RA.ind"); dump_meas_res(LOGL_DEBUG, &ra_ind->measParam); - lc = get_lapdm_chan_by_hl2(fl1->priv, ra_ind->hLayer2); - if (!lc) { - LOGP(DL1C, LOGL_ERROR, "unable to resolve LAPD channel by hLayer2\n"); - return -ENODEV; + if (ra_ind->msgUnitParam.u8Size != 1) { + LOGP(DL1C, LOGL_ERROR, "PH-RACH-INDICATION has %d bits\n", + ra_ind->sapi); + msgb_free(l1p_msg); + return 0; } + fn = ra_ind->u32Fn; + ra = ra_ind->msgUnitParam.u8Buffer[0]; /* check for under/overflow / sign */ if (ra_ind->measParam.i16BurstTiming < 0) acc_delay = 0; else acc_delay = ra_ind->measParam.i16BurstTiming >> 2; - if (acc_delay > btsb->max_ta) { - LOGP(DL1C, LOGL_INFO, "ignoring RACH request %u > max_ta(%u)\n", - acc_delay, btsb->max_ta); - return 0; - } - - /* check for packet access */ - if (trx == bts->c0 - && (ra_ind->msgUnitParam.u8Buffer[0] & 0xf0) == 0x70) { - LOGP(DL1C, LOGL_INFO, "RACH for packet access\n"); - return pcu_tx_rach_ind(bts, ra_ind->measParam.i16BurstTiming, - ra_ind->msgUnitParam.u8Buffer[0], ra_ind->u32Fn); - } - - osmo_prim_init(&pp.oph, SAP_GSM_PH, PRIM_PH_RACH, - PRIM_OP_INDICATION, NULL); - - pp.u.rach_ind.ra = ra_ind->msgUnitParam.u8Buffer[0]; - pp.u.rach_ind.fn = ra_ind->u32Fn; - pp.u.rach_ind.acc_delay = acc_delay; - - return lapdm_phsap_up(&pp.oph, &lc->lapdm_dcch); + rc = msgb_trim(l1p_msg, sizeof(*l1sap)); + if (rc < 0) + MSGB_ABORT(l1p_msg, "No room for primitive data\n"); + l1sap = msgb_l1sap_prim(l1p_msg); + osmo_prim_init(&l1sap->oph, SAP_GSM_PH, PRIM_PH_RACH, PRIM_OP_INDICATION, + l1p_msg); + l1sap->u.rach_ind.ra = ra; + l1sap->u.rach_ind.acc_delay = acc_delay; + l1sap->u.rach_ind.fn = fn; + + return l1sap_up(trx, l1sap); } /* handle any random indication from the L1 */ @@ -885,21 +840,19 @@ static int l1if_handle_ind(struct femtol1_hdl *fl1, struct msgb *msg) case GsmL1_PrimId_PhConnectInd: break; case GsmL1_PrimId_PhReadyToSendInd: - rc = handle_ph_readytosend_ind(fl1, &l1p->u.phReadyToSendInd); + return handle_ph_readytosend_ind(fl1, &l1p->u.phReadyToSendInd, msg); break; case GsmL1_PrimId_PhDataInd: - rc = handle_ph_data_ind(fl1, &l1p->u.phDataInd, msg); + return handle_ph_data_ind(fl1, &l1p->u.phDataInd, msg); break; case GsmL1_PrimId_PhRaInd: - rc = handle_ph_ra_ind(fl1, &l1p->u.phRaInd); + return handle_ph_ra_ind(fl1, &l1p->u.phRaInd, msg); break; default: break; } - /* Special return value '1' means: do not free */ - if (rc != 1) - msgb_free(msg); + msgb_free(msg); return rc; } @@ -1203,46 +1156,6 @@ int l1if_set_trace_flags(struct femtol1_hdl *hdl, uint32_t flags) return osmo_wqueue_enqueue(&hdl->write_q[MQ_SYS_WRITE], msg); } -/* send packet data request to L1 */ -int l1if_pdch_req(struct gsm_bts_trx_ts *ts, int is_ptcch, uint32_t fn, - uint16_t arfcn, uint8_t block_nr, uint8_t *data, uint8_t len) -{ - struct gsm_bts_trx *trx = ts->trx; - struct femtol1_hdl *fl1h = trx_femtol1_hdl(trx); - struct msgb *msg; - GsmL1_Prim_t *l1p; - GsmL1_PhDataReq_t *data_req; - GsmL1_MsgUnitParam_t *msu_param; - struct gsm_time g_time; - - gsm_fn2gsmtime(&g_time, fn); - - DEBUGP(DL1P, "TX packet data %02u/%02u/%02u is_ptcch=%d trx=%d ts=%d " - "block_nr=%d, arfcn=%d, len=%d\n", g_time.t1, g_time.t2, - g_time.t3, is_ptcch, ts->trx->nr, ts->nr, block_nr, arfcn, len); - - msg = l1p_msgb_alloc(); - l1p = msgb_l1prim(msg); - l1p->id = GsmL1_PrimId_PhDataReq; - data_req = &l1p->u.phDataReq; - data_req->hLayer1 = fl1h->hLayer1; - data_req->sapi = (is_ptcch) ? GsmL1_Sapi_Ptcch : GsmL1_Sapi_Pdtch; - data_req->subCh = GsmL1_SubCh_NA; - data_req->u8BlockNbr = block_nr; - data_req->u8Tn = ts->nr; - data_req->u32Fn = fn; - msu_param = &data_req->msgUnitParam; - msu_param->u8Size = len; - memcpy(msu_param->u8Buffer, data, len); - - tx_to_gsmtap(fl1h, msg); - - /* transmit */ - osmo_wqueue_enqueue(&fl1h->write_q[MQ_L1_WRITE], msg); - - return 0; -} - struct femtol1_hdl *l1if_open(void *priv) { struct femtol1_hdl *fl1h; @@ -1290,10 +1203,6 @@ struct femtol1_hdl *l1if_open(void *priv) return NULL; } - fl1h->gsmtap = gsmtap_source_init("localhost", GSMTAP_UDP_PORT, 1); - if (fl1h->gsmtap) - gsmtap_source_add_sink(fl1h->gsmtap); - return fl1h; } @@ -1304,8 +1213,3 @@ int l1if_close(struct femtol1_hdl *fl1h) return 0; } -/* temporary stub to make this patch compile */ -int bts_model_l1sap_down(struct gsm_bts_trx *trx, struct osmo_phsap_prim *l1sap) -{ - return -ENOTSUP; -} diff --git a/src/osmo-bts-sysmo/l1_if.h b/src/osmo-bts-sysmo/l1_if.h index 7947ea2..388f1fb 100644 --- a/src/osmo-bts-sysmo/l1_if.h +++ b/src/osmo-bts-sysmo/l1_if.h @@ -50,9 +50,6 @@ struct femtol1_hdl { char *calib_path; struct llist_head wlc_list; - struct gsmtap_inst *gsmtap; - uint32_t gsmtap_sapi_mask; - void *priv; /* user reference */ struct osmo_timer_list alive_timer; @@ -97,7 +94,9 @@ uint32_t l1if_lchan_to_hLayer(struct gsm_lchan *lchan); struct gsm_lchan *l1if_hLayer_to_lchan(struct gsm_bts_trx *trx, uint32_t hLayer); /* tch.c */ -int l1if_tch_rx(struct gsm_lchan *lchan, struct msgb *l1p_msg); +void l1if_tch_encode(struct gsm_lchan *lchan, uint8_t *data, uint8_t *len, + const uint8_t *rtp_pl, unsigned int rtp_pl_len); +int l1if_tch_rx(struct gsm_bts_trx *trx, uint8_t chan_nr, struct msgb *l1p_msg); int l1if_tch_fill(struct gsm_lchan *lchan, uint8_t *l1_buffer); struct msgb *gen_empty_tch_msg(struct gsm_lchan *lchan); @@ -106,6 +105,12 @@ int l1if_set_ciphering(struct femtol1_hdl *fl1h, struct gsm_lchan *lchan, int dir_downlink); +/* channel control */ +int l1if_rsl_chan_act(struct gsm_lchan *lchan); +int l1if_rsl_chan_rel(struct gsm_lchan *lchan); +int l1if_rsl_deact_sacch(struct gsm_lchan *lchan); +int l1if_rsl_mode_modify(struct gsm_lchan *lchan); + /* calibration loading */ int calib_load(struct femtol1_hdl *fl1h); diff --git a/src/osmo-bts-sysmo/main.c b/src/osmo-bts-sysmo/main.c index 7e7f761..465f99d 100644 --- a/src/osmo-bts-sysmo/main.c +++ b/src/osmo-bts-sysmo/main.c @@ -45,6 +45,7 @@ #include #include #include +#include #define SYSMOBTS_RF_LOCK_PATH "/var/lock/bts_rf_lock" @@ -254,6 +255,7 @@ int main(int argc, char **argv) bts_log_init(NULL); + bts = gsm_bts_alloc(tall_bts_ctx); vty_init(&bts_vty_info); bts_vty_init(bts, &bts_log_info); @@ -271,7 +273,6 @@ int main(int argc, char **argv) } } - bts = gsm_bts_alloc(tall_bts_ctx); if (bts_init(bts) < 0) { fprintf(stderr, "unable to to open bts\n"); exit(1); diff --git a/src/osmo-bts-sysmo/oml.c b/src/osmo-bts-sysmo/oml.c index aeddad7..399576e 100644 --- a/src/osmo-bts-sysmo/oml.c +++ b/src/osmo-bts-sysmo/oml.c @@ -35,11 +35,27 @@ #include #include #include +#include #include "l1_if.h" #include "femtobts.h" #include "utils.h" +static int mph_info_chan_confirm(struct gsm_lchan *lchan, + enum osmo_mph_info_type type, uint8_t cause) +{ + struct osmo_phsap_prim l1sap; + + memset(&l1sap, 0, sizeof(l1sap)); + osmo_prim_init(&l1sap.oph, SAP_GSM_PH, PRIM_MPH_INFO, PRIM_OP_CONFIRM, + NULL); + l1sap.u.info.type = type; + l1sap.u.info.u.act_cnf.chan_nr = gsm_lchan2chan_nr(lchan); + l1sap.u.info.u.act_cnf.cause = cause; + + return l1sap_up(lchan->ts->trx, &l1sap); +} + enum sapi_cmd_type { SAPI_CMD_ACTIVATE, SAPI_CMD_CONFIG_CIPHERING, @@ -858,7 +874,7 @@ static int sapi_activate_cb(struct gsm_lchan *lchan, int status) if (status != GsmL1_Status_Success) { lchan_set_state(lchan, LCHAN_S_BROKEN); sapi_clear_queue(&lchan->sapi_cmds); - rsl_tx_chan_act_nack(lchan, RSL_ERR_EQUIPMENT_FAIL); + mph_info_chan_confirm(lchan, PRIM_INFO_ACTIVATE, RSL_ERR_EQUIPMENT_FAIL); return -1; } @@ -869,7 +885,7 @@ static int sapi_activate_cb(struct gsm_lchan *lchan, int status) return 0; lchan_set_state(lchan, LCHAN_S_ACTIVE); - rsl_tx_chan_act_ack(lchan); + mph_info_chan_confirm(lchan, PRIM_INFO_ACTIVATE, 0); /* set the initial ciphering parameters for both directions */ l1if_set_ciphering(fl1h, lchan, 0); @@ -891,7 +907,6 @@ static void enqueue_sapi_act_cmd(struct gsm_lchan *lchan, int sapi, int dir) int lchan_activate(struct gsm_lchan *lchan, enum gsm_lchan_state lchan_state) { - struct gsm_bts_role_bts *btsb = lchan->ts->trx->bts->role; struct femtol1_hdl *fl1h = trx_femtol1_hdl(lchan->ts->trx); const struct lchan_sapis *s4l = &sapis_for_lchan[lchan->type]; unsigned int i; @@ -920,8 +935,6 @@ int lchan_activate(struct gsm_lchan *lchan, enum gsm_lchan_state lchan_state) #warning "FIXME: Should this be in sapi_activate_cb?" lchan_init_lapdm(lchan); - lchan->s = btsb->radio_link_timeout; - return 0; } @@ -1177,7 +1190,7 @@ int l1if_set_ciphering(struct femtol1_hdl *fl1h, return 0; } -int bts_model_rsl_mode_modify(struct gsm_lchan *lchan) +int l1if_rsl_mode_modify(struct gsm_lchan *lchan) { if (lchan->state != LCHAN_S_ACTIVE) return -1; @@ -1286,7 +1299,7 @@ static int sapi_deactivate_cb(struct gsm_lchan *lchan, int status) gsm_lchan_name(lchan)); lchan_set_state(lchan, LCHAN_S_BROKEN); sapi_clear_queue(&lchan->sapi_cmds); - rsl_tx_rf_rel_ack(lchan); + mph_info_chan_confirm(lchan, PRIM_INFO_DEACTIVATE, 0); return -1; } @@ -1298,7 +1311,7 @@ static int sapi_deactivate_cb(struct gsm_lchan *lchan, int status) return 0; lchan_set_state(lchan, LCHAN_S_NONE); - rsl_tx_rf_rel_ack(lchan); + mph_info_chan_confirm(lchan, PRIM_INFO_DEACTIVATE, 0); return 0; } @@ -1358,7 +1371,7 @@ static int lchan_deactivate_sapis(struct gsm_lchan *lchan) LOGP(DL1C, LOGL_ERROR, "%s all SAPIs already released?\n", gsm_lchan_name(lchan)); lchan_set_state(lchan, LCHAN_S_BROKEN); - rsl_tx_rf_rel_ack(lchan); + mph_info_chan_confirm(lchan, PRIM_INFO_DEACTIVATE, 0); } return res; @@ -1398,13 +1411,6 @@ static int lchan_deactivate_sacch(struct gsm_lchan *lchan) return 0; } -struct gsm_time *bts_model_get_time(struct gsm_bts *bts) -{ - struct femtol1_hdl *fl1h = trx_femtol1_hdl(bts->c0); - - return &fl1h->gsm_time; -} - /* callback from OML */ int bts_model_check_oml(struct gsm_bts *bts, uint8_t msg_type, struct tlv_parsed *old_attr, struct tlv_parsed *new_attr, @@ -1457,17 +1463,17 @@ int bts_model_chg_adm_state(struct gsm_bts *bts, struct gsm_abis_mo *mo, mo->nm_state.administrative = adm_state; return oml_mo_statechg_ack(mo); } -int bts_model_rsl_chan_act(struct gsm_lchan *lchan, struct tlv_parsed *tp) + +int l1if_rsl_chan_act(struct gsm_lchan *lchan) { //uint8_t mode = *TLVP_VAL(tp, RSL_IE_CHAN_MODE); //uint8_t type = *TLVP_VAL(tp, RSL_IE_ACT_TYPE); - lchan->sacch_deact = 0; lchan_activate(lchan, LCHAN_S_ACT_REQ); return 0; } -int bts_model_rsl_chan_rel(struct gsm_lchan *lchan) +int l1if_rsl_chan_rel(struct gsm_lchan *lchan) { /* A duplicate RF Release Request, ignore it */ if (lchan->state == LCHAN_S_REL_REQ) @@ -1476,7 +1482,7 @@ int bts_model_rsl_chan_rel(struct gsm_lchan *lchan) return 0; } -int bts_model_rsl_deact_sacch(struct gsm_lchan *lchan) +int l1if_rsl_deact_sacch(struct gsm_lchan *lchan) { /* Only de-activate the SACCH if the lchan is active */ if (lchan->state != LCHAN_S_ACTIVE) diff --git a/src/osmo-bts-sysmo/sysmobts_vty.c b/src/osmo-bts-sysmo/sysmobts_vty.c index 61deda4..998ed80 100644 --- a/src/osmo-bts-sysmo/sysmobts_vty.c +++ b/src/osmo-bts-sysmo/sysmobts_vty.c @@ -83,34 +83,6 @@ DEFUN(cfg_bts_no_auto_band, cfg_bts_no_auto_band_cmd, return CMD_SUCCESS; } -DEFUN(cfg_trx_gsmtap_sapi, cfg_trx_gsmtap_sapi_cmd, - "HIDDEN", "HIDDEN") -{ - struct gsm_bts_trx *trx = vty->index; - struct femtol1_hdl *fl1h = trx_femtol1_hdl(trx); - int sapi; - - sapi = get_string_value(femtobts_l1sapi_names, argv[0]); - - fl1h->gsmtap_sapi_mask |= (1 << sapi); - - return CMD_SUCCESS; -} - -DEFUN(cfg_trx_no_gsmtap_sapi, cfg_trx_no_gsmtap_sapi_cmd, - "HIDDEN", "HIDDEN") -{ - struct gsm_bts_trx *trx = vty->index; - struct femtol1_hdl *fl1h = trx_femtol1_hdl(trx); - int sapi; - - sapi = get_string_value(femtobts_l1sapi_names, argv[0]); - - fl1h->gsmtap_sapi_mask &= ~(1 << sapi); - - return CMD_SUCCESS; -} - DEFUN(cfg_trx_clkcal_def, cfg_trx_clkcal_def_cmd, "clock-calibration default", "Set the clock calibration value\n" "Default Clock DAC value\n") @@ -397,44 +369,6 @@ DEFUN(set_tx_power, set_tx_power_cmd, return CMD_SUCCESS; } -DEFUN(loopback, loopback_cmd, - "trx <0-0> <0-7> loopback <0-1>", - TRX_STR - "Timeslot number\n" - "Set TCH loopback\n" - "Logical Channel Number\n") -{ - int trx_nr = atoi(argv[0]); - int ts_nr = atoi(argv[1]); - int lchan_nr = atoi(argv[2]); - struct gsm_bts_trx *trx = gsm_bts_trx_num(vty_bts, trx_nr); - struct gsm_bts_trx_ts *ts = &trx->ts[ts_nr]; - struct gsm_lchan *lchan = &ts->lchan[lchan_nr]; - - lchan->loopback = 1; - - return CMD_SUCCESS; -} - -DEFUN(no_loopback, no_loopback_cmd, - "no trx <0-0> <0-7> loopback <0-1>", - NO_STR TRX_STR - "Timeslot number\n" - "Set TCH loopback\n" - "Logical Channel Number\n") -{ - int trx_nr = atoi(argv[0]); - int ts_nr = atoi(argv[1]); - int lchan_nr = atoi(argv[2]); - struct gsm_bts_trx *trx = gsm_bts_trx_num(vty_bts, trx_nr); - struct gsm_bts_trx_ts *ts = &trx->ts[ts_nr]; - struct gsm_lchan *lchan = &ts->lchan[lchan_nr]; - - lchan->loopback = 0; - - return CMD_SUCCESS; -} - void bts_model_config_write_bts(struct vty *vty, struct gsm_bts *bts) { @@ -447,7 +381,6 @@ void bts_model_config_write_bts(struct vty *vty, struct gsm_bts *bts) void bts_model_config_write_trx(struct vty *vty, struct gsm_bts_trx *trx) { struct femtol1_hdl *fl1h = trx_femtol1_hdl(trx); - int i; vty_out(vty, " clock-calibration %d%s", fl1h->clk_cal, VTY_NEWLINE); @@ -463,14 +396,6 @@ void bts_model_config_write_trx(struct vty *vty, struct gsm_bts_trx *trx) VTY_NEWLINE); vty_out(vty, " min-qual-norm %.0f%s", fl1h->min_qual_norm * 10.0f, VTY_NEWLINE); - - for (i = 0; i < 32; i++) { - if (fl1h->gsmtap_sapi_mask & (1 << i)) { - const char *name = get_value_string(femtobts_l1sapi_names, i); - vty_out(vty, " gsmtap-sapi %s%s", osmo_str_tolower(name), - VTY_NEWLINE); - } - } } int bts_model_vty_init(struct gsm_bts *bts) @@ -492,20 +417,6 @@ int bts_model_vty_init(struct gsm_bts *bts) NO_STR TRX_STR DSP_TRACE_F_STR, "\n", "", 0); - cfg_trx_gsmtap_sapi_cmd.string = vty_cmd_string_from_valstr(bts, femtobts_l1sapi_names, - "gsmtap-sapi (", - "|",")", VTY_DO_LOWER); - cfg_trx_gsmtap_sapi_cmd.doc = vty_cmd_string_from_valstr(bts, femtobts_l1sapi_names, - "GSMTAP SAPI\n", - "\n", "", 0); - - cfg_trx_no_gsmtap_sapi_cmd.string = vty_cmd_string_from_valstr(bts, femtobts_l1sapi_names, - "no gsmtap-sapi (", - "|",")", VTY_DO_LOWER); - cfg_trx_no_gsmtap_sapi_cmd.doc = vty_cmd_string_from_valstr(bts, femtobts_l1sapi_names, - NO_STR "GSMTAP SAPI\n", - "\n", "", 0); - install_element_ve(&show_dsp_trace_f_cmd); install_element_ve(&show_sys_info_cmd); install_element_ve(&show_trx_clksrc_cmd); @@ -515,9 +426,6 @@ int bts_model_vty_init(struct gsm_bts *bts) install_element(ENABLE_NODE, &activate_lchan_cmd); install_element(ENABLE_NODE, &set_tx_power_cmd); - install_element(ENABLE_NODE, &loopback_cmd); - install_element(ENABLE_NODE, &no_loopback_cmd); - install_element(BTS_NODE, &cfg_bts_auto_band_cmd); install_element(BTS_NODE, &cfg_bts_no_auto_band_cmd); @@ -525,8 +433,6 @@ int bts_model_vty_init(struct gsm_bts *bts) install_element(TRX_NODE, &cfg_trx_clkcal_def_cmd); install_element(TRX_NODE, &cfg_trx_clksrc_cmd); install_element(TRX_NODE, &cfg_trx_cal_path_cmd); - install_element(TRX_NODE, &cfg_trx_gsmtap_sapi_cmd); - install_element(TRX_NODE, &cfg_trx_no_gsmtap_sapi_cmd); install_element(TRX_NODE, &cfg_trx_ul_power_target_cmd); install_element(TRX_NODE, &cfg_trx_min_qual_rach_cmd); install_element(TRX_NODE, &cfg_trx_min_qual_norm_cmd); diff --git a/src/osmo-bts-sysmo/tch.c b/src/osmo-bts-sysmo/tch.c index c6c782f..da62c84 100644 --- a/src/osmo-bts-sysmo/tch.c +++ b/src/osmo-bts-sysmo/tch.c @@ -39,6 +39,7 @@ #include #include #include +#include #include #include @@ -416,7 +417,7 @@ static int rtppayload_to_l1_amr(uint8_t *l1_payload, const uint8_t *rtp_payload, #define RTP_MSGB_ALLOC_SIZE 512 -/*! \brief call-back function for incoming RTP +/*! \brief function for incoming RTP via TCH.req * \param rs RTP Socket * \param[in] rtp_pl buffer containing RTP payload * \param[in] rtp_pl_len length of \a rtp_pl @@ -428,14 +429,9 @@ static int rtppayload_to_l1_amr(uint8_t *l1_payload, const uint8_t *rtp_payload, * yet, as things like the frame number, etc. are unknown at the time we * pre-fill the primtive. */ -void bts_model_rtp_rx_cb(struct osmo_rtp_socket *rs, const uint8_t *rtp_pl, - unsigned int rtp_pl_len) +void l1if_tch_encode(struct gsm_lchan *lchan, uint8_t *data, uint8_t *len, + const uint8_t *rtp_pl, unsigned int rtp_pl_len) { - struct gsm_lchan *lchan = rs->priv; - struct msgb *msg; - GsmL1_Prim_t *l1p; - GsmL1_PhDataReq_t *data_req; - GsmL1_MsgUnitParam_t *msu_param; uint8_t *payload_type; uint8_t *l1_payload; int rc; @@ -443,22 +439,8 @@ void bts_model_rtp_rx_cb(struct osmo_rtp_socket *rs, const uint8_t *rtp_pl, DEBUGP(DRTP, "%s RTP IN: %s\n", gsm_lchan_name(lchan), osmo_hexdump(rtp_pl, rtp_pl_len)); - /* skip processing of incoming RTP frames if we are in loopback mode */ - if (lchan->loopback) - return; - - msg = l1p_msgb_alloc(); - if (!msg) { - LOGP(DRTP, LOGL_ERROR, "%s: Failed to allocate Rx payload.\n", - gsm_lchan_name(lchan)); - return; - } - - l1p = msgb_l1prim(msg); - data_req = &l1p->u.phDataReq; - msu_param = &data_req->msgUnitParam; - payload_type = &msu_param->u8Buffer[0]; - l1_payload = &msu_param->u8Buffer[1]; + payload_type = &data[0]; + l1_payload = &data[1]; switch (lchan->tch_mode) { case GSM48_CMODE_SPEECH_V1: @@ -493,40 +475,17 @@ void bts_model_rtp_rx_cb(struct osmo_rtp_socket *rs, const uint8_t *rtp_pl, if (rc < 0) { LOGP(DRTP, LOGL_ERROR, "%s unable to parse RTP payload\n", gsm_lchan_name(lchan)); - msgb_free(msg); return; } - msu_param->u8Size = rc + 1; + *len = rc + 1; DEBUGP(DRTP, "%s RTP->L1: %s\n", gsm_lchan_name(lchan), - osmo_hexdump(msu_param->u8Buffer, msu_param->u8Size)); - - /* make sure the number of entries in the dl_tch_queue is never - * more than 3 */ - { - struct msgb *tmp; - int count = 0; - - llist_for_each_entry(tmp, &lchan->dl_tch_queue, list) - count++; - - DEBUGP(DL1C, "%s DL TCH queue length = %u\n", - gsm_lchan_name(lchan), count); - - while (count >= 2) { - tmp = msgb_dequeue(&lchan->dl_tch_queue); - msgb_free(tmp); - count--; - } - } - - /* enqueue msgb to be transmitted to L1 */ - msgb_enqueue(&lchan->dl_tch_queue, msg); + osmo_hexdump(data, *len)); } /*! \brief receive a traffic L1 primitive for a given lchan */ -int l1if_tch_rx(struct gsm_lchan *lchan, struct msgb *l1p_msg) +int l1if_tch_rx(struct gsm_bts_trx *trx, uint8_t chan_nr, struct msgb *l1p_msg) { GsmL1_Prim_t *l1p = msgb_l1prim(l1p_msg); GsmL1_PhDataInd_t *data_ind = &l1p->u.phDataInd; @@ -534,50 +493,15 @@ int l1if_tch_rx(struct gsm_lchan *lchan, struct msgb *l1p_msg) uint8_t *payload = data_ind->msgUnitParam.u8Buffer + 1; uint8_t payload_len; struct msgb *rmsg = NULL; + struct gsm_lchan *lchan = &trx->ts[L1SAP_CHAN2TS(chan_nr)].lchan[l1sap_chan2ss(chan_nr)]; if (data_ind->msgUnitParam.u8Size < 1) { - LOGP(DL1C, LOGL_ERROR, "%s Rx Payload size 0\n", - gsm_lchan_name(lchan)); + LOGP(DL1C, LOGL_ERROR, "chan_nr %d Rx Payload size 0\n", + chan_nr); return -EINVAL; } payload_len = data_ind->msgUnitParam.u8Size - 1; - if (lchan->loopback) { - GsmL1_Prim_t *rl1p; - GsmL1_PhDataReq_t *data_req; - GsmL1_MsgUnitParam_t *msu_param; - - struct msgb *tmp; - int count = 0; - - /* generate a new msgb from the paylaod */ - rmsg = l1p_msgb_alloc(); - if (!rmsg) - return -ENOMEM; - - rl1p = msgb_l1prim(rmsg); - data_req = &rl1p->u.phDataReq; - msu_param = &data_req->msgUnitParam; - - memcpy(msu_param->u8Buffer, - data_ind->msgUnitParam.u8Buffer, - data_ind->msgUnitParam.u8Size); - msu_param->u8Size = data_ind->msgUnitParam.u8Size; - - /* make sure the queue doesn't get too long */ - llist_for_each_entry(tmp, &lchan->dl_tch_queue, list) - count++; - while (count >= 1) { - tmp = msgb_dequeue(&lchan->dl_tch_queue); - msgb_free(tmp); - count--; - } - - msgb_enqueue(&lchan->dl_tch_queue, rmsg); - - return 0; - } - switch (payload_type) { case GsmL1_TchPlType_Fr: #if defined(L1_HAS_EFR) && defined(USE_L1_RTP_MODE) @@ -624,13 +548,20 @@ int l1if_tch_rx(struct gsm_lchan *lchan, struct msgb *l1p_msg) } if (rmsg) { + struct osmo_phsap_prim *l1sap; + LOGP(DL1C, LOGL_DEBUG, "%s Rx -> RTP: %s\n", gsm_lchan_name(lchan), osmo_hexdump(rmsg->data, rmsg->len)); - /* hand rmsg to RTP code for transmission */ - if (lchan->abis_ip.rtp_socket) - osmo_rtp_send_frame(lchan->abis_ip.rtp_socket, - rmsg->data, rmsg->len, 160); - msgb_free(rmsg); + + /* add l1sap header */ + rmsg->l2h = rmsg->data; + msgb_push(rmsg, sizeof(*l1sap)); + rmsg->l1h = rmsg->data; + l1sap = msgb_l1sap_prim(rmsg); + osmo_prim_init(&l1sap->oph, SAP_GSM_PH, PRIM_TCH, PRIM_OP_INDICATION, rmsg); + l1sap->u.tch.chan_nr = chan_nr; + + return l1sap_up(trx, l1sap); } return 0; -- 1.8.1.5 From jolly at eversberg.eu Mon Jul 15 08:35:33 2013 From: jolly at eversberg.eu (Andreas Eversberg) Date: Mon, 15 Jul 2013 10:35:33 +0200 Subject: [PATCH 4/7] Add GSMTAP option and initialization to main.c of sysmobts In-Reply-To: <1373877336-27883-1-git-send-email-jolly@eversberg.eu> References: <1373877336-27883-1-git-send-email-jolly@eversberg.eu> Message-ID: <1373877336-27883-4-git-send-email-jolly@eversberg.eu> --- src/osmo-bts-sysmo/main.c | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/src/osmo-bts-sysmo/main.c b/src/osmo-bts-sysmo/main.c index 465f99d..6ba3b85 100644 --- a/src/osmo-bts-sysmo/main.c +++ b/src/osmo-bts-sysmo/main.c @@ -37,6 +37,8 @@ #include #include #include +#include +#include #include #include @@ -59,6 +61,7 @@ static const char *config_file = "osmo-bts.cfg"; static int daemonize = 0; static unsigned int dsp_trace = 0x71c00020; static int rt_prio = -1; +static char *gsmtap_ip = 0; int bts_model_init(struct gsm_bts *bts) { @@ -115,6 +118,7 @@ static void print_help() " -w --hw-version Print the targeted HW Version\n" " -M --pcu-direct Force PCU to access message queue for " "PDCH dchannel directly\n" + " -i --gsmtap-ip The destination IP used for GSMTAP.\n" ); } @@ -146,10 +150,11 @@ static void handle_options(int argc, char **argv) { "hw-version", 0, 0, 'w' }, { "pcu-direct", 0, 0, 'M' }, { "realtime", 1, 0, 'r' }, + { "gsmtap-ip", 1, 0, 'i' }, { 0, 0, 0, 0 } }; - c = getopt_long(argc, argv, "hc:d:Dc:sTVe:p:w:Mr:", + c = getopt_long(argc, argv, "hc:d:Dc:sTVe:p:w:Mr:i:", long_options, &option_idx); if (c == -1) break; @@ -194,6 +199,9 @@ static void handle_options(int argc, char **argv) case 'r': rt_prio = atoi(optarg); break; + case 'i': + gsmtap_ip = optarg; + break; default: break; } @@ -273,6 +281,15 @@ int main(int argc, char **argv) } } + if (gsmtap_ip) { + gsmtap = gsmtap_source_init(gsmtap_ip, GSMTAP_UDP_PORT, 1); + if (!gsmtap) { + fprintf(stderr, "Failed during gsmtap_init()\n"); + exit(1); + } + gsmtap_source_add_sink(gsmtap); + } + if (bts_init(bts) < 0) { fprintf(stderr, "unable to to open bts\n"); exit(1); -- 1.8.1.5 From jolly at eversberg.eu Mon Jul 15 08:35:34 2013 From: jolly at eversberg.eu (Andreas Eversberg) Date: Mon, 15 Jul 2013 10:35:34 +0200 Subject: [PATCH 5/7] Correctly fill system information messages from BSC In-Reply-To: <1373877336-27883-1-git-send-email-jolly@eversberg.eu> References: <1373877336-27883-1-git-send-email-jolly@eversberg.eu> Message-ID: <1373877336-27883-5-git-send-email-jolly@eversberg.eu> SI 5*/6 require L2 header of 0x03,0x03. All SI might be less than 23 octets, so they need to be filled with 0x2b. --- src/common/rsl.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/src/common/rsl.c b/src/common/rsl.c index 150f686..128990d 100644 --- a/src/common/rsl.c +++ b/src/common/rsl.c @@ -314,6 +314,7 @@ static int rsl_rx_bcch_info(struct gsm_bts_trx *trx, struct msgb *msg) if (len > sizeof(sysinfo_buf_t)) len = sizeof(sysinfo_buf_t); bts->si_valid |= (1 << osmo_si); + memset(bts->si_buf[osmo_si], 0x2b, sizeof(sysinfo_buf_t)); memcpy(bts->si_buf[osmo_si], TLVP_VAL(&tp, RSL_IE_FULL_BCCH_INFO), len); LOGP(DRSL, LOGL_INFO, " Rx RSL BCCH INFO (SI%s)\n", @@ -323,6 +324,7 @@ static int rsl_rx_bcch_info(struct gsm_bts_trx *trx, struct msgb *msg) if (len > sizeof(sysinfo_buf_t)) len = sizeof(sysinfo_buf_t); bts->si_valid |= (1 << osmo_si); + memset(bts->si_buf[osmo_si], 0x2b, sizeof(sysinfo_buf_t)); memcpy(bts->si_buf[osmo_si], TLVP_VAL(&tp, RSL_IE_L3_INFO), len); LOGP(DRSL, LOGL_INFO, " Rx RSL BCCH INFO (SI%s)\n", @@ -437,6 +439,7 @@ static int rsl_rx_sacch_fill(struct gsm_bts_trx *trx, struct msgb *msg) bts->si_valid |= (1 << osmo_si); bts->si_buf[osmo_si][0] = 0x03; /* C/R + EA */ bts->si_buf[osmo_si][1] = 0x03; /* UI frame */ + memset(bts->si_buf[osmo_si]+2, 0x2b, sizeof(sysinfo_buf_t)-2); memcpy(bts->si_buf[osmo_si]+2, TLVP_VAL(&tp, RSL_IE_L3_INFO), len); LOGP(DRSL, LOGL_INFO, " Rx RSL SACCH FILLING (SI%s)\n", @@ -727,8 +730,9 @@ static int rsl_rx_chan_activ(struct msgb *msg) if (copy_len > sizeof(sysinfo_buf_t)-2) copy_len = sizeof(sysinfo_buf_t)-2; lchan->si.valid |= (1 << osmo_si); - lchan->si.buf[osmo_si][0] = 0x00; + lchan->si.buf[osmo_si][0] = 0x03; lchan->si.buf[osmo_si][1] = 0x03; + memset(lchan->si.buf[osmo_si]+2, 0x2b, sizeof(sysinfo_buf_t)-2); memcpy(lchan->si.buf[osmo_si]+2, cur, copy_len); cur += si_len; @@ -1046,8 +1050,9 @@ static int rsl_rx_sacch_inf_mod(struct msgb *msg) if (len > sizeof(sysinfo_buf_t)-2) len = sizeof(sysinfo_buf_t)-2; lchan->si.valid |= (1 << osmo_si); - lchan->si.buf[osmo_si][0] = 0x00; + lchan->si.buf[osmo_si][0] = 0x03; lchan->si.buf[osmo_si][1] = 0x03; + memset(lchan->si.buf[osmo_si]+2, 0x2b, sizeof(sysinfo_buf_t)-2); memcpy(lchan->si.buf[osmo_si]+2, TLVP_VAL(&tp, RSL_IE_L3_INFO), len); LOGP(DRSL, LOGL_INFO, "%s Rx RSL SACCH FILLING (SI%s)\n", -- 1.8.1.5 From jolly at eversberg.eu Mon Jul 15 08:35:35 2013 From: jolly at eversberg.eu (Andreas Eversberg) Date: Mon, 15 Jul 2013 10:35:35 +0200 Subject: [PATCH 6/7] sysmobts: Clean up transitions for lchan cipher state In-Reply-To: <1373877336-27883-1-git-send-email-jolly@eversberg.eu> References: <1373877336-27883-1-git-send-email-jolly@eversberg.eu> Message-ID: <1373877336-27883-6-git-send-email-jolly@eversberg.eu> There are three transitions: 1. LCHAN_CIPH_NONE -> LCHAN_CIPH_RX_REQ -> LCHAN_CIPH_RX_CONF It is used to enable ciphering in RX (uplink) direction only. 2. LCHAN_CIPH_RX_CONF -> LCHAN_CIPH_RX_CONF_TX_REQ -> LCHAN_CIPH_RXTX_CONF It is used to additionally enable ciphering in TX (downlink) direction. 3. LCHAN_CIPH_NONE -> LCHAN_CIPH_RXTX_REQ -> LCHAN_CIPH_RX_CONF_TX_REQ -> LCHAN_CIPH_RXTX_CONF It is used to enable ciphering in both TX and RX directions. This is used when the channel is activated with encryption already enabled. (assignment or handover) In order to follow the order of these transitions, the RX direction must always be set before the TX direction. If no cipher key is set (A5/0), ciphering is set to ALG 0, but lchan cipher state remains at LCHAN_CIPH_NONE. --- include/osmo-bts/gsm_data.h | 5 +++-- src/common/l1sap.c | 1 - src/common/rsl.c | 1 - src/osmo-bts-sysmo/l1_if.c | 9 ++++++--- src/osmo-bts-sysmo/oml.c | 19 +++++++++++++++---- 5 files changed, 24 insertions(+), 11 deletions(-) diff --git a/include/osmo-bts/gsm_data.h b/include/osmo-bts/gsm_data.h index 980f8ef..3949292 100644 --- a/include/osmo-bts/gsm_data.h +++ b/include/osmo-bts/gsm_data.h @@ -69,8 +69,9 @@ enum lchan_ciph_state { LCHAN_CIPH_NONE, LCHAN_CIPH_RX_REQ, LCHAN_CIPH_RX_CONF, - LCHAN_CIPH_TXRX_REQ, - LCHAN_CIPH_TXRX_CONF, + LCHAN_CIPH_RXTX_REQ, + LCHAN_CIPH_RX_CONF_TX_REQ, + LCHAN_CIPH_RXTX_CONF, }; #define bts_role_bts(x) ((struct gsm_bts_role_bts *)(x)->role) diff --git a/src/common/l1sap.c b/src/common/l1sap.c index ad833ea..b6621e0 100644 --- a/src/common/l1sap.c +++ b/src/common/l1sap.c @@ -94,7 +94,6 @@ static int check_for_ciph_cmd(struct msgb *msg, struct gsm_lchan *lchan, /* only do this if we are in the right state */ switch (lchan->ciph_state) { case LCHAN_CIPH_NONE: - case LCHAN_CIPH_RX_REQ: break; default: return 0; diff --git a/src/common/rsl.c b/src/common/rsl.c index 128990d..91e5099 100644 --- a/src/common/rsl.c +++ b/src/common/rsl.c @@ -890,7 +890,6 @@ static int rsl_rx_encr_cmd(struct msgb *msg) /* push a fake RLL DATA REQ header */ rsl_rll_push_l3(msg, RSL_MT_DATA_REQ, dch->chan_nr, link_id, 1); - #ifdef FAKE_CIPH_MODE_COMPL if (lchan->encr.alg_id != RSL_ENC_ALG_A5(0)) { struct ciph_mod_compl *cmc; diff --git a/src/osmo-bts-sysmo/l1_if.c b/src/osmo-bts-sysmo/l1_if.c index f2e4440..b262b28 100644 --- a/src/osmo-bts-sysmo/l1_if.c +++ b/src/osmo-bts-sysmo/l1_if.c @@ -442,14 +442,17 @@ int bts_model_l1sap_down(struct gsm_bts_trx *trx, struct osmo_phsap_prim *l1sap) u8Tn = L1SAP_CHAN2TS(chan_nr); ss = l1sap_chan2ss(chan_nr); lchan = &trx->ts[u8Tn].lchan[ss]; - if (l1sap->u.info.u.ciph_req.downlink) { + if (l1sap->u.info.u.ciph_req.uplink) { l1if_set_ciphering(fl1, lchan, 1); lchan->ciph_state = LCHAN_CIPH_RX_REQ; } - if (l1sap->u.info.u.ciph_req.uplink) { + if (l1sap->u.info.u.ciph_req.downlink) { l1if_set_ciphering(fl1, lchan, 0); - lchan->ciph_state = LCHAN_CIPH_TXRX_REQ; + lchan->ciph_state = LCHAN_CIPH_RX_CONF_TX_REQ; } + if (l1sap->u.info.u.ciph_req.downlink + && l1sap->u.info.u.ciph_req.uplink) + lchan->ciph_state = LCHAN_CIPH_RXTX_REQ; break; case PRIM_INFO_ACTIVATE: case PRIM_INFO_DEACTIVATE: diff --git a/src/osmo-bts-sysmo/oml.c b/src/osmo-bts-sysmo/oml.c index 399576e..c16f7c5 100644 --- a/src/osmo-bts-sysmo/oml.c +++ b/src/osmo-bts-sysmo/oml.c @@ -888,8 +888,12 @@ static int sapi_activate_cb(struct gsm_lchan *lchan, int status) mph_info_chan_confirm(lchan, PRIM_INFO_ACTIVATE, 0); /* set the initial ciphering parameters for both directions */ - l1if_set_ciphering(fl1h, lchan, 0); l1if_set_ciphering(fl1h, lchan, 1); + l1if_set_ciphering(fl1h, lchan, 0); + if (lchan->encr.alg_id) + lchan->ciph_state = LCHAN_CIPH_RXTX_REQ; + else + lchan->ciph_state = LCHAN_CIPH_NONE; return 0; } @@ -1028,9 +1032,16 @@ static int chmod_modif_compl_cb(struct gsm_bts_trx *trx, struct msgb *l1_msg) LOGPC(DL1C, LOGL_INFO, "RX_REQ -> RX_CONF\n"); lchan->ciph_state = LCHAN_CIPH_RX_CONF; break; - case LCHAN_CIPH_TXRX_REQ: - LOGPC(DL1C, LOGL_INFO, "TX_REQ -> TX_CONF\n"); - lchan->ciph_state = LCHAN_CIPH_TXRX_CONF; + case LCHAN_CIPH_RX_CONF_TX_REQ: + LOGPC(DL1C, LOGL_INFO, "RX_CONF_TX_REQ -> RXTX_CONF\n"); + lchan->ciph_state = LCHAN_CIPH_RXTX_CONF; + break; + case LCHAN_CIPH_RXTX_REQ: + LOGPC(DL1C, LOGL_INFO, "RXTX_REQ -> RX_CONF_TX_REQ\n"); + lchan->ciph_state = LCHAN_CIPH_RX_CONF_TX_REQ; + break; + case LCHAN_CIPH_NONE: + LOGPC(DL1C, LOGL_INFO, "\n"); break; default: LOGPC(DL1C, LOGL_INFO, "unhandled state %u\n", lchan->ciph_state); -- 1.8.1.5 From jolly at eversberg.eu Mon Jul 15 08:35:36 2013 From: jolly at eversberg.eu (Andreas Eversberg) Date: Mon, 15 Jul 2013 10:35:36 +0200 Subject: [PATCH 7/7] sysmobts: Forward CMR from L1 (Phone) to RTP payload In-Reply-To: <1373877336-27883-1-git-send-email-jolly@eversberg.eu> References: <1373877336-27883-1-git-send-email-jolly@eversberg.eu> Message-ID: <1373877336-27883-7-git-send-email-jolly@eversberg.eu> --- src/osmo-bts-sysmo/tch.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/osmo-bts-sysmo/tch.c b/src/osmo-bts-sysmo/tch.c index da62c84..901c48c 100644 --- a/src/osmo-bts-sysmo/tch.c +++ b/src/osmo-bts-sysmo/tch.c @@ -257,7 +257,7 @@ static struct msgb *l1_to_rtppayload_amr(uint8_t *l1_payload, uint8_t payload_le if (!msg) return NULL; -#if 0 +#if 1 uint8_t cmr_idx = l1_payload[1]; /* CMR == Unset means CMR was not transmitted at this TDMA */ -- 1.8.1.5 From andreas at eversberg.eu Mon Jul 15 10:07:58 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Mon, 15 Jul 2013 12:07:58 +0200 Subject: 7 patches Message-ID: <51E3C9FE.3090303@eversberg.eu> hi, these 7 patches have been tested with sysmobts and osmo-bts (trx interface). it works with calls and gprs. before applying any of these patches, i suggest to double check it with a different test setup. regards, andreas From holger at freyther.de Fri Jul 26 10:12:53 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Fri, 26 Jul 2013 12:12:53 +0200 Subject: 7 patches In-Reply-To: <51E3C9FE.3090303@eversberg.eu> References: <51E3C9FE.3090303@eversberg.eu> Message-ID: <20130726101253.GA27988@xiaoyu.lan> On Mon, Jul 15, 2013 at 12:07:58PM +0200, Andreas Eversberg wrote: > hi, > > these 7 patches have been tested with sysmobts and osmo-bts (trx > interface). it works with calls and gprs. before applying any of these > patches, i suggest to double check it with a different test setup. Hi, I don't have much time to do QA in spare my time. So this is very brief: * Doing the stress-testing I described on 4th and 6th of May. A compiled sysmobts binary with your changes is crashing on a talloc_free. zecke/hacks/stress-testing, executing allocate-all-channels will crash the code. I am confident that this is not due a binary incompatible change to the header files (we need to bump the so version of libosmocore in the next cycle) * You are undoing all the lchan->s changes we did based on my review we did from 12th of March to 15th of March. To be honest I find this quite offensive. * The extra msgb_alloc/memcpy to go from primitive to native is wasteful. One should re-write the header around the payload. * The change to introduce the primitives is too big. Otherwise the above two issues could have been spotted with review. My proposal is to introduce primitives inside the sysmoBTS code piece by piece in one primitive per patch. E.g. introduce a 'native' primitive and the l1sapup, then start converting that to other primitives until there are no native primitives left. Avoid creating a thousand lines switch/case statement. Modern compilers will nicely inline small static methods. The benefit is that each change can be easily reviewed and stress tested (e.g. compare it with the changeset I did for the sapi queuing), and one avoids such things like undoing lchan->s changes that are burried somewhere in the patch. cheers holger From andreas at eversberg.eu Fri Jul 26 11:37:05 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Fri, 26 Jul 2013 13:37:05 +0200 Subject: 7 patches In-Reply-To: <20130726101253.GA27988@xiaoyu.lan> References: <51E3C9FE.3090303@eversberg.eu> <20130726101253.GA27988@xiaoyu.lan> Message-ID: <51F25F61.5030404@eversberg.eu> Holger Hans Peter Freyther wrote: > * Doing the stress-testing I described on 4th and 6th of May. A > compiled sysmobts binary with your changes is crashing on a > talloc_free. zecke/hacks/stress-testing, executing allocate-all-channels > will crash the code. I am confident that this is not due a binary > incompatible change to the header files (we need to bump the > so version of libosmocore in the next cycle) > > * You are undoing all the lchan->s changes we did based on my review > we did from 12th of March to 15th of March. To be honest I find > this quite offensive. > > * The extra msgb_alloc/memcpy to go from primitive to native is > wasteful. One should re-write the header around the payload. > > * The change to introduce the primitives is too big. Otherwise the > above two issues could have been spotted with review. My proposal > is to introduce primitives inside the sysmoBTS code piece by > piece in one primitive per patch. > > E.g. introduce a 'native' primitive and the l1sapup, then start > converting that to other primitives until there are no native > primitives left. Avoid creating a thousand lines switch/case > statement. Modern compilers will nicely inline small static > methods. > > The benefit is that each change can be easily reviewed and stress > tested (e.g. compare it with the changeset I did for the sapi queuing), > and one avoids such things like undoing lchan->s changes that are > burried somewhere in the patch. > hi holger, i am currently out of time, but i will hopefully find the time to take a look at it and provide reworked patches. regards, andreas From andreas at eversberg.eu Sun Jul 28 11:01:21 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Sun, 28 Jul 2013 13:01:21 +0200 Subject: 7 patches In-Reply-To: <20130726101253.GA27988@xiaoyu.lan> References: <51E3C9FE.3090303@eversberg.eu> <20130726101253.GA27988@xiaoyu.lan> Message-ID: <51F4FA01.6000609@eversberg.eu> Holger Hans Peter Freyther wrote: > * The extra msgb_alloc/memcpy to go from primitive to native is > wasteful. One should re-write the header around the payload. > > * The change to introduce the primitives is too big. Otherwise the > above two issues could have been spotted with review. My proposal > is to introduce primitives inside the sysmoBTS code piece by > piece in one primitive per patch. > hi holger, i started splitting the l1sap implementation into parts. the first part is just cover the BCCH RTS/REQ messages. these are moved from osmo-bts-sysmo code to common code. i pushed a new branch where i will commit each part. see last commit of jolly/l1sap_parts branch. in this commit i found a solution to convert a l1sap message to l1p (sysmo-bts) message without memcpy: the l1p structure is not just a header+payload, but a structure that includes the payload as fixed element. i needed to expand the headroom and tail of a message (allocated at l1sap.c), so the l1p structure can be casted over the existing message. the payload will then be at the right spot inside the l1p structure. the structure's data around the payload will be cleared. before the actual casting of structure is done, the l1sap header is pulled (data points to payload) and the length is trimmed to 0. push/clear part of the l1p structure that is in front of the actual payload: temp = l1p->u.phDataReq.msgUnitParam.u8Buffer; msgb_push(msg, temp - (uint8_t *)l1p); memset(msg->data, 0, msg->len); put the actual payload that is already inside message: msgb_put(msg, len); NOTE: 'len' is the actual lenght of payload put/clear the rest of of the structure that is behind the actual payload. memset(msg->tail, 0, sizeof(*l1p) - msg->len); msgb_put(msg, sizeof(*l1p) - msg->len); msg->l1h = msg->data; regards, andreas From holger at freyther.de Sun Jul 28 14:37:45 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sun, 28 Jul 2013 16:37:45 +0200 Subject: 7 patches In-Reply-To: <51F4FA01.6000609@eversberg.eu> References: <51E3C9FE.3090303@eversberg.eu> <20130726101253.GA27988@xiaoyu.lan> <51F4FA01.6000609@eversberg.eu> Message-ID: <20130728143745.GB3624@xiaoyu.lan> On Sun, Jul 28, 2013 at 01:01:21PM +0200, Andreas Eversberg wrote: > i started splitting the l1sap implementation into parts. the first part > is just cover the BCCH RTS/REQ messages. these are moved from > osmo-bts-sysmo code to common code. i pushed a new branch where i will > commit each part. see last commit of jolly/l1sap_parts branch. it is still way too big... * e.g... it adds handling for TCH.. when you are just starting with the BCCH... >> primitives left. Avoid creating a thousand lines switch/case >> statement. Modern compilers will nicely inline small static >> methods. * you really don't need to put everything into a single method. Try to put unrelated things into separate methods. Nobody can understand a method that has 1000 lines of codes and tons of if/else in it. From andreas at eversberg.eu Mon Jul 29 08:04:31 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Mon, 29 Jul 2013 10:04:31 +0200 Subject: 7 patches In-Reply-To: <20130728143745.GB3624@xiaoyu.lan> References: <51E3C9FE.3090303@eversberg.eu> <20130726101253.GA27988@xiaoyu.lan> <51F4FA01.6000609@eversberg.eu> <20130728143745.GB3624@xiaoyu.lan> Message-ID: <51F6220F.3020906@eversberg.eu> Holger Hans Peter Freyther wrote: > it is still way too big... > > * e.g... it adds handling for TCH.. when you are just starting with > the BCCH... > * you really don't need to put everything into a single method. Try > to put unrelated things into separate methods. Nobody can understand > a method that has 1000 lines of codes and tons of if/else in it. > i did some seperation: - first i committed the l1sap interface header, because it includes all macros that are relevant for for later primitives. - then the actual BCCH implementation, which includes the base parts of the l1sap interface. - last the gsmtap support for the l1sap message primitives. the function is now splitted. i think that later this gsmtap support should be placed at the end of all primitives patches. what do you think? From andreas at eversberg.eu Tue Jul 16 17:58:17 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Tue, 16 Jul 2013 19:58:17 +0200 Subject: GPRS roaming Message-ID: <51E589B9.3060809@eversberg.eu> hi harald, i know that you talked about before so maybe you can give me a hint. i like to make osmo-sgsn allow roaming (different PLMN of the phone than the one in the RAI of the BTS). regards, andreas From admin at manateeshome.com Wed Jul 17 01:15:37 2013 From: admin at manateeshome.com (Pierre Kim) Date: Wed, 17 Jul 2013 10:15:37 +0900 Subject: GPRS roaming In-Reply-To: <51E589B9.3060809@eversberg.eu> References: <51E589B9.3060809@eversberg.eu> Message-ID: <000001ce828b$26d7b960$74872c20$@manateeshome.com> http://git.osmocom.org/openbsc/commit/?id=eafe22ca7290280fca0f8d31d70239fd0b 0dbb9d You can comment that line out. Regards, Pierre -----Original Message----- From: openbsc-bounces at lists.osmocom.org [mailto:openbsc-bounces at lists.osmocom.org] On Behalf Of Andreas Eversberg Sent: Wednesday, July 17, 2013 2:58 AM To: Harald Welte; OpenBSC Mailing List Subject: GPRS roaming hi harald, i know that you talked about before so maybe you can give me a hint. i like to make osmo-sgsn allow roaming (different PLMN of the phone than the one in the RAI of the BTS). regards, andreas From andreas at eversberg.eu Wed Jul 17 11:14:47 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Wed, 17 Jul 2013 13:14:47 +0200 Subject: GPRS roaming In-Reply-To: <000001ce828b$26d7b960$74872c20$@manateeshome.com> References: <51E589B9.3060809@eversberg.eu> <000001ce828b$26d7b960$74872c20$@manateeshome.com> Message-ID: <51E67CA7.5020504@eversberg.eu> Pierre Kim wrote: > http://git.osmocom.org/openbsc/commit/?id=eafe22ca7290280fca0f8d31d70239fd0b > 0dbb9d > > You can comment that line out. > > hi pierre, thanks for this hint. i just remove the return statement and it works. best regards, andreas From Max.Suraev at fairwaves.ru Wed Jul 17 11:53:55 2013 From: Max.Suraev at fairwaves.ru (=?UTF-8?B?4piO?=) Date: Wed, 17 Jul 2013 13:53:55 +0200 Subject: GPRS roaming In-Reply-To: <51E67CA7.5020504@eversberg.eu> References: <51E589B9.3060809@eversberg.eu> <000001ce828b$26d7b960$74872c20$@manateeshome.com> <51E67CA7.5020504@eversberg.eu> Message-ID: <51E685D3.9090100@fairwaves.ru> 17.07.2013 13:14, Andreas Eversberg ?????: > Pierre Kim wrote: >> http://git.osmocom.org/openbsc/commit/?id=eafe22ca7290280fca0f8d31d70239fd0b >> 0dbb9d >> >> You can comment that line out. >> >> > hi pierre, > > thanks for this hint. i just remove the return statement and it works. > Should we make that configurable perhaps? -- best regards, Max, http://fairwaves.ru From andreas at eversberg.eu Wed Jul 17 13:13:26 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Wed, 17 Jul 2013 15:13:26 +0200 Subject: GPRS roaming In-Reply-To: <51E685D3.9090100@fairwaves.ru> References: <51E589B9.3060809@eversberg.eu> <000001ce828b$26d7b960$74872c20$@manateeshome.com> <51E67CA7.5020504@eversberg.eu> <51E685D3.9090100@fairwaves.ru> Message-ID: <51E69876.7030409@eversberg.eu> ? wrote: > Should we make that configurable perhaps? > > yes, maybe use HLR to check if subscriber exists and is authorized. i thing about three types of authorizations: - auth-policy allow-all - auth-policy allow-equal-network - auth-policy allow-hlr From laforge at gnumonks.org Sun Jul 21 07:47:00 2013 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 21 Jul 2013 15:47:00 +0800 Subject: GPRS roaming In-Reply-To: <51E589B9.3060809@eversberg.eu> References: <51E589B9.3060809@eversberg.eu> Message-ID: <20130721074700.GE5573@nataraja.gnumonks.org> Dear Andreas, On Tue, Jul 16, 2013 at 07:58:17PM +0200, Andreas Eversberg wrote: > i know that you talked about before so maybe you can give me a hint. i > like to make osmo-sgsn allow roaming (different PLMN of the phone than > the one in the RAI of the BTS). I've cleaned up and merged some patches that make this vty configurable in git commit 3dfb549a6f31ea2252014db1075a7195da2d4ff7. Please also see the ACL mode, which is safer than running a completely open GPRS network that accepts any IMSI. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From alexander.chemeris at gmail.com Sun Jul 21 18:44:34 2013 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Sun, 21 Jul 2013 22:44:34 +0400 Subject: GPRS roaming In-Reply-To: <20130721074700.GE5573@nataraja.gnumonks.org> References: <51E589B9.3060809@eversberg.eu> <20130721074700.GE5573@nataraja.gnumonks.org> Message-ID: Hi Harald, On Sun, Jul 21, 2013 at 11:47 AM, Harald Welte wrote: > On Tue, Jul 16, 2013 at 07:58:17PM +0200, Andreas Eversberg wrote: >> i know that you talked about before so maybe you can give me a hint. i >> like to make osmo-sgsn allow roaming (different PLMN of the phone than >> the one in the RAI of the BTS). > > I've cleaned up and merged some patches that make this vty configurable > in git commit 3dfb549a6f31ea2252014db1075a7195da2d4ff7. Please also see > the ACL mode, which is safer than running a completely open GPRS > network that accepts any IMSI. Thank you for fixing this, as we often use open SGSN roaming in our testing environment. Just as an idea for making this simple ACL better - it could be a regexp on IMSI. Then you could easily specify ranges of IMSIs with a short and clear command. This works very well in OpenBTS for example. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From holger at freyther.de Mon Jul 22 05:52:12 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 22 Jul 2013 07:52:12 +0200 Subject: GPRS roaming In-Reply-To: References: <51E589B9.3060809@eversberg.eu> <20130721074700.GE5573@nataraja.gnumonks.org> Message-ID: <20130722055212.GA22852@xiaoyu.lan> On Sun, Jul 21, 2013 at 10:44:34PM +0400, Alexander Chemeris wrote: > Just as an idea for making this simple ACL better - it could be a > regexp on IMSI. Then you could easily specify ranges of IMSIs with a > short and clear command. This works very well in OpenBTS for example. patches welcome. There are quite some regexp examples in the nat From laforge at gnumonks.org Mon Jul 22 09:00:12 2013 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 22 Jul 2013 17:00:12 +0800 Subject: GPRS roaming In-Reply-To: References: <51E589B9.3060809@eversberg.eu> <20130721074700.GE5573@nataraja.gnumonks.org> Message-ID: <57404aeb-2816-46b9-9ce8-55f770ac5092@email.android.com> Linking a regular expression matching library seems excessive and an additional dependency for no good reason. Feel free to implement a simple prefix match, possibly by reusing code from the smpp route matching. Also, rather than that a real async hlr interface is needed. There are many areas where contributions are welcome. So far I yet have to see anyone else making any reasonably sized contribution to the sgsn. This always makes me sad. Not even the past and current llc sequence number / tlli problems which should have been visible to any user seem to have encouraged much in terms of submitting fixes :/ -- Sent from my mobile phone. Please excuse my brevity. From holger at freyther.de Mon Jul 22 10:36:44 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 22 Jul 2013 12:36:44 +0200 Subject: Increasing contributions Re: GPRS roaming In-Reply-To: <57404aeb-2816-46b9-9ce8-55f770ac5092@email.android.com> References: <51E589B9.3060809@eversberg.eu> <20130721074700.GE5573@nataraja.gnumonks.org> <57404aeb-2816-46b9-9ce8-55f770ac5092@email.android.com> Message-ID: <20130722103644.GI22852@xiaoyu.lan> On Mon, Jul 22, 2013 at 05:00:12PM +0800, Harald Welte wrote: Hi, > Also, rather than that a real async hlr interface is needed. There are many areas where contributions are welcome. So far I yet have to see anyone else making any reasonably sized contribution to the sgsn. This always makes me sad. Not even the past and current llc sequence number / tlli problems which should have been visible to any user seem to have encouraged much in terms of submitting fixes :/ we see an increased use of OpenBSC while the amount of devs mostly stay the same. I wondered about ways to handle or improve this. The below is a list of random thoughts. * I started with specifying simple tasks and offering guidance when someone wants to implement that. One could go to Universities and hacker spaces to find people motivated to try it. So if there is 1/10 success rate on such projects it would already be positive. * Obstacles. One needs to have access to a base station to do meaningful work. Now thanks to you there are plenty of individuals with a BS11, and then there are Nokia/Ericsson/nanoBTS and sysmoBTS out there. We also have public events like the XXC3, Camp, OHM. So maybe we should be more active in announcing that we want implementers at these events? Or maybe even hold a two day event in Berlin to ask interested people to implement things? * Seek for monetary support. Sure some of our commercial users, use the software because it is of zero cost and would never pay a dime for anything. But maybe there are others that want to contribute some money for features? We could do some more ads that companies like sysmocom offer high class, cost-effective customisations to OpenBSC. * Adopt a more shiny/structured website. On the one hand the wiki is a manifestation that users don't even correct content after they found a solution but maybe we can do things to make the entry for developers/contributors more easy. In fact I had already set-up the software powers a book like this[1]. Maybe we can start with a couple of 'unreliable' guides to {GSM, OpenBSC, Testing}. I had also planned to create such material for the employee's of sysmocom. * Adopt a model like it is/was(?) used by PackageKit. Contributors do get direct access.. the public needs to wait a penalty time to see the code. It makes it clear that value contributors more than users. > Linking a regular expression matching library seems excessive and an additional dependency for no good reason. Feel free to implement a simple prefix match, possibly by reusing code from the smpp route matching. man regcomp, it is part of posix. [1] http://book.seaside.st/book From laforge at gnumonks.org Tue Jul 23 02:44:34 2013 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 23 Jul 2013 10:44:34 +0800 Subject: Increasing contributions Re: GPRS roaming In-Reply-To: <20130722103644.GI22852@xiaoyu.lan> References: <51E589B9.3060809@eversberg.eu> <20130721074700.GE5573@nataraja.gnumonks.org> <57404aeb-2816-46b9-9ce8-55f770ac5092@email.android.com> <20130722103644.GI22852@xiaoyu.lan> Message-ID: <20130723024434.GF5825@nataraja.gnumonks.org> Hi Holger, On Mon, Jul 22, 2013 at 12:36:44PM +0200, Holger Hans Peter Freyther wrote: > * I started with specifying simple tasks and offering guidance when > someone wants to implement that. One could go to Universities and > hacker spaces to find people motivated to try it. So if there is > 1/10 success rate on such projects it would already be positive. Good idea. > * Obstacles. One needs to have access to a base station to do meaningful > work. Now thanks to you there are plenty of individuals with a BS11, > and then there are Nokia/Ericsson/nanoBTS and sysmoBTS out there. We > also have public events like the XXC3, Camp, OHM. So maybe we should > be more active in announcing that we want implementers at these > events? > Or maybe even hold a two day event in Berlin to ask interested people > to implement things? Might be worth trying, but I don't think there will be many people whom we don't already know that would travel to Berlin just to work on some code. > * Seek for monetary support. Sure some of our commercial users, use > the software because it is of zero cost and would never pay a dime > for anything. But maybe there are others that want to contribute some > money for features? We could do some more ads that companies like > sysmocom offer high class, cost-effective customisations to OpenBSC. I don't like that option. If at all, it would be the business interest of such companies to do so (and they are free to do so), but not something that should be advertised on / in relation to the OpenBSC project and/or websites. If at all, we could have a wiki page that contains a simple list of businesses who are able to provide commercial customization / support / R&D related to openbsc. > * Adopt a model like it is/was(?) used by PackageKit. Contributors > do get direct access.. the public needs to wait a penalty time to > see the code. It makes it clear that value contributors more than > users. I dislike that even more. > man regcomp, it is part of posix. 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 peter at stuge.se Tue Jul 23 02:53:54 2013 From: peter at stuge.se (Peter Stuge) Date: Tue, 23 Jul 2013 04:53:54 +0200 Subject: Increasing contributions Re: GPRS roaming In-Reply-To: <20130723024434.GF5825@nataraja.gnumonks.org> References: <51E589B9.3060809@eversberg.eu> <20130721074700.GE5573@nataraja.gnumonks.org> <57404aeb-2816-46b9-9ce8-55f770ac5092@email.android.com> <20130722103644.GI22852@xiaoyu.lan> <20130723024434.GF5825@nataraja.gnumonks.org> Message-ID: <20130723025354.14567.qmail@stuge.se> Harald Welte wrote: > If at all, we could have a wiki page that contains a simple list of > businesses who are able to provide commercial customization / support / > R&D related to openbsc. I think this is a good approach. I've seen it work well in other projects. //Peter From alexander.chemeris at gmail.com Mon Jul 22 12:11:28 2013 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Mon, 22 Jul 2013 16:11:28 +0400 Subject: GPRS roaming In-Reply-To: <57404aeb-2816-46b9-9ce8-55f770ac5092@email.android.com> References: <51E589B9.3060809@eversberg.eu> <20130721074700.GE5573@nataraja.gnumonks.org> <57404aeb-2816-46b9-9ce8-55f770ac5092@email.android.com> Message-ID: On Mon, Jul 22, 2013 at 1:00 PM, Harald Welte wrote: > Linking a regular expression matching library seems excessive and an additional dependency > for no good reason. Feel free to implement a simple prefix match, possibly by reusing code > from the smpp route matching. Ok. Thanks for the suggestion. > Also, rather than that a real async hlr interface is needed. There are many areas where > contributions are welcome. So far I yet have to see anyone else making any reasonably sized > contribution to the sgsn. This always makes me sad. Not even the past and current llc > sequence number / tlli problems which should have been visible to any user seem to have > encouraged much in terms of submitting fixes :/ Well, that's not surprising, given the (low) number of users of OpenBSC in general and (negligible) number of people willing to have GPRS. As I said, we need to do more work on making Osmocom more visible and increasing community. So far Osmocom is far behind OpenBTS in terms of visibility, community size, number of paying clients, etc. You may disagree, but IMHO the way to improve situatioin is to have support for cheaper hardware (hello SDR) and easy to use support for SIP. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From peter at stuge.se Tue Jul 23 00:50:14 2013 From: peter at stuge.se (Peter Stuge) Date: Tue, 23 Jul 2013 02:50:14 +0200 Subject: GPRS roaming In-Reply-To: References: <51E589B9.3060809@eversberg.eu> <20130721074700.GE5573@nataraja.gnumonks.org> <57404aeb-2816-46b9-9ce8-55f770ac5092@email.android.com> Message-ID: <20130723005014.4195.qmail@stuge.se> Alexander Chemeris wrote: > > So far I yet have to see anyone else making any reasonably sized > > contribution to the sgsn. > > Well, that's not surprising, given the (low) number of users of > OpenBSC in general and (negligible) number of people willing to > have GPRS. Do you mean "wanting" ? In that case my experience disagrees with you; henever I've run a network with OpenBSC there was always at least one person asking for data. > As I said, we need to do more work on making Osmocom more visible > and increasing community. So far Osmocom is far behind OpenBTS in > terms of visibility, community size, number of paying clients, etc. Community is what it is. There seem to be very few competent developers in both projects. Paying clients have nothing to do with the open source projects as such, since the projects are not a company. Companies which want to market products and solutions based on osmocom projects are free to do so. > You may disagree, but IMHO the way to improve situatioin is to have > support for cheaper hardware (hello SDR) and easy to use support for SIP. No - that is just the way to increase the number of paying clients for your particular company. And besides, I find lcr quite easy to use. With literally no telco background other than two years of playing with SIP I managed to learn it in about a day at the camp in 2011. I taught lcr to one other person in about two hours some months ago. It is not very complicated. Really, what osmocom needs is IMNSHO competent contributions. How you pay for them is your problem, if you want to contribute something. //Peter From peter at stuge.se Tue Jul 23 00:59:52 2013 From: peter at stuge.se (Peter Stuge) Date: Tue, 23 Jul 2013 02:59:52 +0200 Subject: GPRS roaming In-Reply-To: <20130723005014.4195.qmail@stuge.se> References: <51E589B9.3060809@eversberg.eu> <20130721074700.GE5573@nataraja.gnumonks.org> <57404aeb-2816-46b9-9ce8-55f770ac5092@email.android.com> <20130723005014.4195.qmail@stuge.se> Message-ID: <20130723005952.5053.qmail@stuge.se> Peter Stuge wrote: > Community is what it is. There seem to be very few competent > developers in both projects. To clarify, I consider most if not all developers in both projects competent - there are just very few of them. //Peter From peter at stuge.se Tue Jul 23 00:38:17 2013 From: peter at stuge.se (Peter Stuge) Date: Tue, 23 Jul 2013 02:38:17 +0200 Subject: GPRS roaming In-Reply-To: <57404aeb-2816-46b9-9ce8-55f770ac5092@email.android.com> References: <51E589B9.3060809@eversberg.eu> <20130721074700.GE5573@nataraja.gnumonks.org> <57404aeb-2816-46b9-9ce8-55f770ac5092@email.android.com> Message-ID: <20130723003817.3155.qmail@stuge.se> Harald Welte wrote: > Linking a regular expression matching library seems excessive Holger mentioned using the regex support in libc and it works fine, it's just not PCRE. (I personally think that's a good thing.) //Peter From holger at freyther.de Mon Jul 22 05:57:07 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 22 Jul 2013 07:57:07 +0200 Subject: GPRS roaming In-Reply-To: <20130721074700.GE5573@nataraja.gnumonks.org> References: <51E589B9.3060809@eversberg.eu> <20130721074700.GE5573@nataraja.gnumonks.org> Message-ID: <20130722055707.GB22852@xiaoyu.lan> On Sun, Jul 21, 2013 at 03:47:00PM +0800, Harald Welte wrote: > I've cleaned up and merged some patches that make this vty configurable > in git commit 3dfb549a6f31ea2252014db1075a7195da2d4ff7. Please also see > the ACL mode, which is safer than running a completely open GPRS > network that accepts any IMSI. Thank you for noticing the doctest errors (I will need to figure out why the build doesn't fail with them) and fixing them! From dchardware at gmail.com Wed Jul 17 17:23:32 2013 From: dchardware at gmail.com (Sipos Csaba) Date: Wed, 17 Jul 2013 19:23:32 +0200 Subject: DAHDI and LAPd errors In-Reply-To: References: Message-ID: <1612638570.20130717192332@freemail.hu> Dear Members, From the beginning I am having various LAPd related error messages with Nokia InSite and a DAHDI E1 card. The LAPd connection resets itself several times before a working OML and RSL connection is made. I don't know, maybe this is due to a change in the DAHDI code. I am getting lapd errors during the BTS initialization like this one: ^[[0;m^[[1;36mTue Jul 16 13:55:10 2013 <0005> bsc_init.c:91 shutting down OML for BTS 0 ^[[0;mTue Jul 16 13:55:14 2013 <0018> input/lapd.c:159 LAPD state change on TEI 1: NONE -> ASSIGNED ^[[0;mTue Jul 16 13:55:14 2013 <0018> input/lapd.c:212 LAPD Allocating SAP for SAPI=62 / TEI=1 ^[[0;mTue Jul 16 13:55:14 2013 <0018> input/lapd.c:223 k=1 N200=3 N201=260 T200=1.0 T203=10.0 ^[[0;mTue Jul 16 13:55:14 2013 <0018> lapd_core.c:292 Init DL layer: sequence range = 128, k = 1, history range = 2 ^[[0;mTue Jul 16 13:55:14 2013 <0018> lapd_core.c:229 new state LAPD_STATE_NULL -> LAPD_STATE_IDLE ^[[0;mTue Jul 16 13:55:14 2013 <0018> input/lapd.c:485 LAPD DL-ESTABLISH request TEI=1 SAPI=62 ^[[0;mTue Jul 16 13:55:14 2013 <0018> lapd_core.c:2171 Message DL-ESTABLISH-REQUEST received in state LAPD_STATE_IDLE ^[[0;mTue Jul 16 13:55:14 2013 <0018> lapd_core.c:1685 perform normal establishm. (SABM) ^[[0;mTue Jul 16 13:55:14 2013 <0018> lapd_core.c:229 new state LAPD_STATE_IDLE -> LAPD_STATE_SABM_SENT ^[[0;mTue Jul 16 13:55:14 2013 <0018> input/lapd.c:600 TX: fa 03 7f ^[[0;mTue Jul 16 13:55:14 2013 <0018> lapd_core.c:198 start T200 ^[[0;m^[[1;38mTue Jul 16 13:55:14 2013 <001d> sms_queue.c:220 Attempting to send 20 SMS ^[[0;m^[[1;38mTue Jul 16 13:55:14 2013 <001d> sms_queue.c:280 SMSqueue added 0 messages in 0 rounds ^[[0;mTue Jul 16 13:55:15 2013 <0018> lapd_core.c:551 Timeout T200 (0x822cb80) state=5 ^[[0;mTue Jul 16 13:55:15 2013 <0018> input/lapd.c:600 TX: fa 03 7f ^[[0;mTue Jul 16 13:55:15 2013 <0018> lapd_core.c:198 start T200 ^[[0;mTue Jul 16 13:55:16 2013 <0018> lapd_core.c:551 Timeout T200 (0x822cb80) state=5 ^[[0;mTue Jul 16 13:55:16 2013 <0018> input/lapd.c:600 TX: fa 03 7f ^[[0;mTue Jul 16 13:55:16 2013 <0018> lapd_core.c:198 start T200 ^[[0;mTue Jul 16 13:55:17 2013 <0018> lapd_core.c:551 Timeout T200 (0x822cb80) state=5 ^[[0;mTue Jul 16 13:55:17 2013 <0018> input/lapd.c:600 TX: fa 03 7f ^[[0;mTue Jul 16 13:55:17 2013 <0018> lapd_core.c:198 start T200 ^[[0;mTue Jul 16 13:55:18 2013 <0018> lapd_core.c:551 Timeout T200 (0x822cb80) state=5 ^[[0;mTue Jul 16 13:55:18 2013 <0018> input/lapd.c:628 LAPD DL-RELEASE indication TEI=1 SAPI=62 ^[[0;mTue Jul 16 13:55:18 2013 <0018> lapd_core.c:307 Resetting LAPDm instance ^[[0;mTue Jul 16 13:55:18 2013 <0018> lapd_core.c:229 new state LAPD_STATE_SABM_SENT -> LAPD_STATE_IDLE ^[[0;mTue Jul 16 13:55:18 2013 <0018> lapd_core.c:384 sending MDL-ERROR-IND cause 1 ^[[0;mTue Jul 16 13:55:18 2013 <0018> lapd_core.c:229 new state LAPD_STATE_IDLE -> LAPD_STATE_IDLE ^[[0;m^[[1;36mTue Jul 16 13:55:33 2013 <0005> bsc_init.c:91 shutting down OML for BTS 0 Anyway, it would be nice to know a recommended DAHDI version and/or kernel version which is used during the development or something. For example - as I mentioned it earlier - DAHDI 2.7.x breaks the compatibility with OpenBSC due to the changed addressing scheme. BR, Csaba From holger at freyther.de Sun Jul 28 20:01:04 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sun, 28 Jul 2013 22:01:04 +0200 Subject: TLLI problems and proposed solution Message-ID: <20130728200104.GD3624@xiaoyu.lan> Dear LaF0rge, I pushed "zecke/features/emulator" to the osmo-pcu repository. All it does is to send a static GPRS Attach for a foreign TLLI. Looking at the communication with Wireshark one will see: Identity Requests messages.. always with N(U) = 0 and in the SGSN log one can see: <0012> gprs_llc.c:773 LLC RX: unknown TLLI 0xadf11820, creating LLME on the fly ... <0012> gprs_llc.c:357 LLC TX: unknown TLLI 0xedf11820, creating LLME on the fly What happens is the following: When receiving the GPRS Attach we create a LLME for the 'foreign' TLLI, but the look-up will never compare tlli/old_tlli with the foreign one. It will always be localized. The smallest change is this one: diff --git a/openbsc/src/gprs/gprs_llc.c b/openbsc/src/gprs/gprs_llc.c index 8af5367..52727ce 100644 --- a/openbsc/src/gprs/gprs_llc.c +++ b/openbsc/src/gprs/gprs_llc.c @@ -777,9 +777,10 @@ int gprs_llc_rcvmsg(struct msgb *msg, struct tlv_parsed *tv) (llhp.cmd == GPRS_LLC_XID || llhp.cmd == GPRS_LLC_UI)) { struct gprs_llc_llme *llme; /* FIXME: don't use the TLLI but the 0xFFFF unassigned? */ - llme = llme_alloc(msgb_tlli(msg)); + llme = llme_alloc(tlli_foreign2local(msgb_tlli(msg))); LOGP(DLLC, LOGL_DEBUG, "LLC RX: unknown TLLI 0x%08x, " - "creating LLME on the fly\n", msgb_tlli(msg)); + "creating LLME on the fly\n", + tlli_foreign2local(msgb_tlli(msg))); lle = &llme->lle[llhp.sapi]; } else { LOGP(DLLC, LOGL_NOTICE, (but one could move that into llme_alloc and then it works for RX/TX). After this patch the Identity Request requests will have an increasting N(U) and the tlli in the message will be 0xadf11820. The SGSN will still print: <0012> gprs_llc.c:142 TLLI 0xadf11820 is foreign, converting to local TLLI 0xedf11820 So this means that for the entire GPRS attach procedure we will use the initial foreign TLLI.... so somehow... the code in the MM handling... /* Even if there is no P-TMSI allocated, the MS will switch from * foreign TLLI to local TLLI */ ctx->tlli_new = gprs_tmsi2tlli(ctx->p_tmsi, TLLI_LOCAL); /* Inform LLC layer about new TLLI but keep old active */ gprs_llgmm_assign(ctx->llme, ctx->tlli, ctx->tlli_new, GPRS_ALGO_GEA0, NULL); So this tlli_new does not appear to be used at all and I don't see how/where we would use/create the OLD_TLLI IE? Is it implemented? holger From holger at freyther.de Sun Jul 28 20:54:08 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sun, 28 Jul 2013 22:54:08 +0200 Subject: TLLI problems and proposed solution In-Reply-To: <20130728200104.GD3624@xiaoyu.lan> References: <20130728200104.GD3624@xiaoyu.lan> Message-ID: <20130728205408.GE3624@xiaoyu.lan> On Sun, Jul 28, 2013 at 10:01:04PM +0200, Holger Hans Peter Freyther wrote: > /* Even if there is no P-TMSI allocated, the MS will switch from > * foreign TLLI to local TLLI */ > ctx->tlli_new = gprs_tmsi2tlli(ctx->p_tmsi, TLLI_LOCAL); > > /* Inform LLC layer about new TLLI but keep old active */ > gprs_llgmm_assign(ctx->llme, ctx->tlli, ctx->tlli_new, > GPRS_ALGO_GEA0, NULL); > > > So this tlli_new does not appear to be used at all and I don't see how/where > we would use/create the OLD_TLLI IE? Is it implemented? Okay, this appears to be incomplete. We would need to put dup.tlli in the gprs_llc.c code if we want to send a TLLI (but then the PCU doesn't appear to be bale to look-up the old tbf based on the IE_TLLI). We do have: struct sgsn_mm_ctx { tlli; tlli_new; struct gprs_llc_llme { tlli; old_tlli; } } 1.) During the attach msgb_tlli(msg) will be the foriegn tlli 2.) We will generate a tlli_new based on the reported tmsi... 3.) We will llgm_assign the tlli_new and tlli. 4.) msgb_tlli(msg) will still point to the foreign tlli 5.) We send a Identity Request 6.) gprs_llc will not provide a dup.tlli 7.) bssgp_tx_dl_ud will use msgb_tlli(msg) and not put a IE_TLLI Do you have some documentation/brain-dump on how tlli/tlli_new, tlli and old_tlli interact with each other? E.g. at which point should the tlli_new be used? In terms of a patch (which is likely to break the PCU as it does not support the old tlli): 1.) Use tlli_foreign2local in the look-up. 2.) Sent the tlli_old if it is not UNASSIGNED and if it is different to the msgb_tlli(msg). I would also like to assert that msgb_tlli(msg) is not equal to mmctx->llme->tlli/old_tlli. 3.) Use the newly assigned tlli as the default. I would like to apply the last hunk first as it is solving creating a LLME on the fly on the TX path and instead re-uses the one created when receiving the first message. diff --git a/openbsc/src/gprs/gprs_gmm.c b/openbsc/src/gprs/gprs_gmm.c index f7a5cde..eaf9ecd 100644 --- a/openbsc/src/gprs/gprs_gmm.c +++ b/openbsc/src/gprs/gprs_gmm.c @@ -760,6 +760,7 @@ static int gsm48_rx_gmm_att_req(struct sgsn_mm_ctx *ctx, struct msgb *msg, /* Inform LLC layer about new TLLI but keep old active */ gprs_llgmm_assign(ctx->llme, ctx->tlli, ctx->tlli_new, GPRS_ALGO_GEA0, NULL); + ctx->tlli = ctx->llme->tlli; DEBUGPC(DMM, "\n"); return gsm48_gmm_authorize(ctx, GMM_T3350_MODE_ATT); @@ -989,6 +990,7 @@ static int gsm48_rx_gmm_ra_upd_req(struct sgsn_mm_ctx *mmctx, struct msgb *msg, /* Inform LLC layer about new TLLI but keep old active */ gprs_llgmm_assign(mmctx->llme, mmctx->tlli, mmctx->tlli_new, GPRS_ALGO_GEA0, NULL); + mmctx->tlli = mmctx->llme->tlli; /* Look at PDP Context Status IE and see if MS's view of * activated/deactivated NSAPIs agrees with our view */ diff --git a/openbsc/src/gprs/gprs_llc.c b/openbsc/src/gprs/gprs_llc.c index 8af5367..ee99d16 100644 --- a/openbsc/src/gprs/gprs_llc.c +++ b/openbsc/src/gprs/gprs_llc.c @@ -48,6 +48,9 @@ static int _bssgp_tx_dl_ud(struct msgb *msg, struct sgsn_mm_ctx *mmctx) * not yet have a MMC context (e.g. XID negotiation of primarly * LLC connection fro GMM sapi). */ if (mmctx) { + if (msgb_tlli(msg) != mmctx->llme->old_tlli + && mmctx->llme->old_tlli != 0xffffffff) + dup.tlli = &mmctx->llme->old_tlli; dup.imsi = mmctx->imsi; dup.drx_parms = mmctx->drx_parms; dup.ms_ra_cap.len = mmctx->ms_radio_access_capa.len; @@ -154,7 +157,7 @@ static struct gprs_llc_lle *lle_by_tlli_sapi(uint32_t tlli, uint8_t sapi) tlli = tlli_foreign2local(tlli); llist_for_each_entry(llme, &gprs_llc_llmes, list) { - if (llme->tlli == tlli || llme->old_tlli == tlli) + if (llme->tlli == tlli || tlli_foreign2local(llme->old_tlli) == tlli) return &llme->lle[sapi]; } return NULL; From laforge at gnumonks.org Mon Jul 29 02:19:26 2013 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 29 Jul 2013 10:19:26 +0800 Subject: TLLI problems and proposed solution In-Reply-To: <20130728205408.GE3624@xiaoyu.lan> References: <20130728200104.GD3624@xiaoyu.lan> <20130728205408.GE3624@xiaoyu.lan> Message-ID: <20130729021926.GD6319@nataraja.gnumonks.org> Hi Holger, thanks a lot for debugging. On Sun, Jul 28, 2013 at 10:54:08PM +0200, Holger Hans Peter Freyther wrote: > On Sun, Jul 28, 2013 at 10:01:04PM +0200, Holger Hans Peter Freyther wrote: > > > /* Even if there is no P-TMSI allocated, the MS will switch from > > * foreign TLLI to local TLLI */ > > ctx->tlli_new = gprs_tmsi2tlli(ctx->p_tmsi, TLLI_LOCAL); > > > > /* Inform LLC layer about new TLLI but keep old active */ > > gprs_llgmm_assign(ctx->llme, ctx->tlli, ctx->tlli_new, > > GPRS_ALGO_GEA0, NULL); > > > > > > So this tlli_new does not appear to be used at all and I don't see > > how/where we would use/create the OLD_TLLI IE? Is it implemented? It seems the BSSGP TLLI (old) is not implemented at this point, as dup->tlli is not set, as you indicated. > Okay, this appears to be incomplete. We would need to put dup.tlli in the > gprs_llc.c code if we want to send a TLLI (but then the PCU doesn't appear > to be bale to look-up the old tbf based on the IE_TLLI). dup->tlli should be set to the old TLLI, _if_ there has just been a change of TLLI. So basically at the time the gprs_llgmm_assign(old_tmsi=0xffffffff, new_tmsi=....) is happening when we get the RAU_COMPLETE / ATTACH_COMPLETE in GMM. At that point, the next BSSGP_DL_UD should have the "TLLI (old)" IE. Only at that point we can be sure that any further messages from the MS will contain only the new TLLI, which is indicated by the BSSGP spec: If an SGSN provides a second TLLI, indicating that an MS has recently changed its TLLI, this shall be considered as the "old" TLLI. A BSS uses the "old" TLLI to locate an MS's existing context. Subsequent uplink data transfers for this MS shall reference the current TLLI, and not the old TLLI. What strikes me as odd is that after we have received such a RAU_COMPLETE / ATTACH_COMPLETE, the SGSN is not sending any further GMM messages to the MS. So the BSSGP-DL-UD with the old TLLI is not sent until maybe a long time later, when the SGSN has something to transmit again. Meanwhile, the MS ca happily be sending uplink messages with the new TLLI. I'm not really sure if a PCU really needs this, at least not as long as we always include the IMSI as part of BSSGP Downlink Unitdata. At that point, the PCU can look-up its MS-contaxt based on the IMSI. The spec says: The SGSN shall include the IMSI in the PDU. As an exception, the SGSN may omit the IMSI in the PDU if the mobile station identified by the TLLI is in MM non-DRX mode period (i.e. during a GMM procedure for GPRS attach or routing area updating defined in GSM 24.008 [11]) and the SGSN does not have a valid IMSI. So this would be the case if we get an ATTACH_REQ or RAU_REQ with P-TMSI only, but have not yet sent the IDENTITY REQUEST or not received the IDENTITY RESPONSE yet. At that point, we don't issue any llgmm_assign() requests to LLC yet, and thus are guaranteed that we always know the IMSI at the time we have a TLLI change. Do you agree? > Do you have some documentation/brain-dump on how tlli/tlli_new, tlli > and old_tlli interact with each other? E.g. at which point should the > tlli_new be used? The tlli_new in the mm-context is only used to call the gprs_llgmm_assign() function (resembling 1:1 a LLGMM-ASSIGN.req primitive in 04.64). So in theory, we should not need to keep it in the mmcontext, but I think it's better to keep it, if not only for debugging aid ;) The higher layers of the SGSN (GMM, etc.) don't need the tlli_new for any other reason. Basically, at time of receiving/processing the ATTACH or the RA UPDATE, we a) generate the new (always local, ptmsi derived) TLLI and store it in mmctx->tlli_new. b) issue a LLGMM-ASSIGN.req primitive to LLC, where tlli_old = mmctx->tlli and tlli_new = tlli_new. This is the following clause in the spec: If TLLI Old ? all 1's and TLLI New ? all 1's then TLLI Old and TLLI New are assigned, and TLLI New shall be used when (re-)transmitting LLC frames. Both TLLI Old and TLLI New shall be accepted when received from the peer. It shall be treated as a TLLI change according to subclause 8.3.2. Later, when we get the ATTACH_COMPLETE / RAU_COMPLETE from the MS, we a) set mmctx->tlli = mmctx->tlli_new b) issue a LLGMM-ASSIGN.req primitive to LLC with old TMSI 0xffffffff and new TMSI = mmctx->tlli_new. According to spec, this is the following case: If TLLI Old = all 1's and TLLI New ? all 1's then TLLI New shall be assigned and used when (re-)transmitting LLC frames. If a TLLI Old ? all 1's was assigned to the LLME, then TLLI Old is unassigned. Only TLLI New shall be accepted when received from the peer. It shall be treated as a TLLI change according to subclause 8.3.2. If TLLI Old = all 1's was assigned to the LLME, then this shall be treated as a TLLI assignment according to subclause 8.3.1, and the LLGMM-ASSIGN-REQ shall be the first primitive sent by GMM in order to enable LLC to process requests from layer 3. So basically, the _intended_ functionality is to accept both old and new TLLI for the time until we receive the ATTACH_COMPLETE / RAU_COMPLETE. After that point, the MS is permitted to only use the new TLLI. If we do a P-TMSI allocation (which we do as PTMSI_ALLOC is #defined), then the new TLLI will be completely different (LOCAL, derived from new P-TMSI) than the old one (LOCAL or foreign, based on old P-TMSI). If you disable PTMSI_ALLOC, then the new TLLI will just be the local version of the intiially (potentially) foreign TLLI. The foreign/local handling in gprs_llc is different from the spec as it predates my full undestanding of specified the TLLI handling. So when we look-up a LLME based on TLLI, we _always_ convert from foreign2local during a lookup, which is not according to spec. At the time window during which the foreign _and_ local TLLI shall be accepted, old_tlli should be the foreign one and tlli should be the (new) local one, i.e. the lookup works even without any foreign2local conversion of the lookup key. > 1.) During the attach msgb_tlli(msg) will be the foriegn tlli > 2.) We will generate a tlli_new based on the reported tmsi... > 3.) We will llgm_assign the tlli_new and tlli. > 4.) msgb_tlli(msg) will still point to the foreign tlli > 5.) We send a Identity Request > 6.) gprs_llc will not provide a dup.tlli > 7.) bssgp_tx_dl_ud will use msgb_tlli(msg) and not put a IE_TLLI Which I so far assume to be what the code should do. The Identity request should still use the foreign TLLI, as we didn't send a ATTACH ACCEPT, ATTACH REJECT, RAU ACCEPT or RAU REJECT yet. The MS will continue to use the foreign TLLI until those messages are recieved: Quote from 04.08 4.7.1.4. i) If the MS has stored a valid P-TMSI, the MS shall derive a foreign TLLI from that P-TMSI and shall use it for transmission of the: - ATTACH REQUEST message of any GPRS combined/non-combined attach procedure; other GMM messages sent during this procedure shall be transmitted using the same foreign TLLI until the ATTACH ACCEPT message or the ATTACH REJECT message is received; and - ROUTING AREA UPDATE REQUEST message of a combined/non-combined RAU procedure if the MS has entered a new routing area, or if the GPRS update status is not equal to GU1 UPDATED. Other GMM messages sent during this procedure shall be transmitted using the same foreign TLLI, until the ROUTING AREA UPDATE ACCEPT message or the ROUTING AREA UPDATE REJECT message is received. After a successful GPRS attach or routing area update procedure, independent whether a new P-TMSI is assigned, if the MS has stored a valid P-TMSI then the MS shall derive a local TLLI from the stored P-TMSI and shall use it for addressing at lower layers. So the question is: What should be done for downlink messages at this point. "After receipt of the acknowledgement, the network shall use the local TLLI for addressing at lower layers. So during this time, using the msgb_tlli(msg) [which is the old, foreign TLLI received from the MS] as the TLLI in downlink messages like IDENTITY REQUEST seems 100% correct to me. > In terms of a patch (which is likely to break the PCU as it does > not support the old tlli): > > 1.) Use tlli_foreign2local in the look-up. This would continue to use the current logic, which is more liberal than the spec [see above]. A better approach might be to remove the tlli_foreign2local() in the lle_by_tlli_sapi() function. This way we ensure that a) the foreign TLLI is matched because it is the msgb_tlli() at the time the LLME was allocated b) the old and new TLLI is matched after the first gprs_llgmm_assign() call. c) only the new TLLI is matched after the second gprs_llgmm_assign() call at RAU/ATTACH COMPLETE time IIRC, the foreign2local logic was introduced by me before we had a gprs_llgmm_assign() primitive and before I fully understood the spec in this part. It should be removed. > 2.) Sent the tlli_old if it is not UNASSIGNED and if it is > different to the msgb_tlli(msg). see above, I'm not quite sure if that would work. Irrespective of BSSGP spec compliance with non-osmo PCUs, in osmo-pcu we can always look-up by IMSI. > I would also like to assert > that msgb_tlli(msg) is not equal to mmctx->llme->tlli/old_tlli. makes sense, particularly once we remove the foreign2local logic. > 3.) Use the newly assigned tlli as the default. from which point on? Only _after_ the RAU_COMPLETE / ATTACH_COMPLETE, which I believe we already do now. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From holger at freyther.de Mon Jul 29 06:26:32 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 29 Jul 2013 08:26:32 +0200 Subject: TLLI problems and proposed solution In-Reply-To: <20130729021926.GD6319@nataraja.gnumonks.org> References: <20130728200104.GD3624@xiaoyu.lan> <20130728205408.GE3624@xiaoyu.lan> <20130729021926.GD6319@nataraja.gnumonks.org> Message-ID: <20130729062632.GB18025@xiaoyu.lan> On Mon, Jul 29, 2013 at 10:19:26AM +0800, Harald Welte wrote: > dup->tlli should be set to the old TLLI, _if_ there has just been a > change of TLLI. So basically at the time the > gprs_llgmm_assign(old_tmsi=0xffffffff, new_tmsi=....) is happening when > we get the RAU_COMPLETE / ATTACH_COMPLETE in GMM. At that point, the > next BSSGP_DL_UD should have the "TLLI (old)" IE. Only at that point we > can be sure that any further messages from the MS will contain only the > new TLLI, which is indicated by the BSSGP spec: Okay. That does make sense. Thanks for going through the specs. > I'm not really sure if a PCU really needs this, at least not as long as > we always include the IMSI as part of BSSGP Downlink Unitdata. At that > point, the PCU can look-up its MS-contaxt based on the IMSI. The spec > says: The osmo-pcu is broken in this regard. It will only use the TLLI to identify the temporary block flow (tbf). I will shuffle the code around to resolve that limitation and create unit tests for that. > So this would be the case if we get an ATTACH_REQ or RAU_REQ with P-TMSI > only, but have not yet sent the IDENTITY REQUEST or not received the > IDENTITY RESPONSE yet. At that point, we don't issue any llgmm_assign() > requests to LLC yet, and thus are guaranteed that we always know the > IMSI at the time we have a TLLI change. > > Do you agree? Yes, but we do issue llgm_assign in that case (and that is the case I can simulate right now). I think the llgm_assign should just be for the foriegn tlli we received (and not from the one dervied by the P-TMSI that we didn't allocate). > The tlli_new in the mm-context is only used to call the > gprs_llgmm_assign() function (resembling 1:1 a LLGMM-ASSIGN.req > primitive in 04.64). So in theory, we should not need to keep it in the > mmcontext, but I think it's better to keep it, if not only for > debugging aid ;) okay, this duplication confused me a bit. > > The higher layers of the SGSN (GMM, etc.) don't need the tlli_new for > any other reason. Basically, at time of receiving/processing the ATTACH > or the RA UPDATE, we > If TLLI Old ? all 1's and TLLI New ? all 1's then TLLI Old and TLLI > New are assigned, and TLLI New shall be used when (re-)transmitting > LLC frames. Both TLLI Old and TLLI New shall be accepted when > received from the peer. It shall be treated as a TLLI change > according to subclause 8.3.2. but for the above ATTACH case with a unknown P-TMSI/TLLI. We will do the assignment but use TLLI Old for the transmissionof any frame. > Later, when we get the ATTACH_COMPLETE / RAU_COMPLETE from the MS, > we > > a) set mmctx->tlli = mmctx->tlli_new > b) issue a LLGMM-ASSIGN.req primitive to LLC with old TMSI 0xffffffff > and new TMSI = mmctx->tlli_new. According to spec, this is the > following case: > > If TLLI Old = all 1's and TLLI New ? all 1's then TLLI New shall be > assigned and used when (re-)transmitting LLC frames. If a TLLI Old ? > all 1's was assigned to the LLME, then TLLI Old is unassigned. Only > TLLI New shall be accepted when received from the peer. It shall be > treated as a TLLI change according to subclause 8.3.2. but that means that llme->old_tlli will be all 1's and that even if we want to.. in gprs_llc we could not set dup.tlli to the previous tlli? So the next download unitdata can not have the IE_TLLI set? > The foreign/local handling in gprs_llc is different from the spec as it > predates my full undestanding of specified the TLLI handling. So when > we look-up a LLME based on TLLI, we _always_ convert from foreign2local > during a lookup, which is not according to spec. At the time window > during which the foreign _and_ local TLLI shall be accepted, old_tlli > should be the foreign one and tlli should be the (new) local one, i.e. > the lookup works even without any foreign2local conversion of the lookup > key. Okay, I will modify the lle_by_tlli_sapi look-up to not use the foreign conversion at all. This would fix my case.. but given the lack of unit tests I don't know what I break. :) > This would continue to use the current logic, which is more liberal than > the spec [see above]. A better approach might be to remove the > tlli_foreign2local() in the lle_by_tlli_sapi() function. This way we > ensure that okay. > see above, I'm not quite sure if that would work. Irrespective of BSSGP > spec compliance with non-osmo PCUs, in osmo-pcu we can always look-up by > IMSI. which we don't[1]. The TBF is only searched by tlli. But that is for another mailinglist.. > > > I would also like to assert > > that msgb_tlli(msg) is not equal to mmctx->llme->tlli/old_tlli. > > makes sense, particularly once we remove the foreign2local logic. okay. > > > 3.) Use the newly assigned tlli as the default. > > from which point on? Only _after_ the RAU_COMPLETE / ATTACH_COMPLETE, > which I believe we already do now. yeah, nothing to be done here. thanks for the clarifications holger [1] http://git.osmocom.org/osmo-pcu/tree/src/gprs_bssgp_pcu.cpp#n151 From holger at freyther.de Mon Jul 29 08:12:12 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 29 Jul 2013 10:12:12 +0200 Subject: TLLI problems and proposed solution In-Reply-To: <20130729062632.GB18025@xiaoyu.lan> References: <20130728200104.GD3624@xiaoyu.lan> <20130728205408.GE3624@xiaoyu.lan> <20130729021926.GD6319@nataraja.gnumonks.org> <20130729062632.GB18025@xiaoyu.lan> Message-ID: <20130729081212.GA18752@xiaoyu.lan> On Mon, Jul 29, 2013 at 08:26:32AM +0200, Holger Hans Peter Freyther wrote: Hi, > Okay, I will modify the lle_by_tlli_sapi look-up to not use the > foreign conversion at all. This would fix my case.. but given the > lack of unit tests I don't know what I break. :) > > makes sense, particularly once we remove the foreign2local logic. > > okay. the patches implement the above two. My case with pcu_emu appears to work correctly (N(U) is counting up) and I have not looked into anything beyond that. If somebody at OHM or somewhere else could/want to apply this to their SGSN installation it would be greatly appreciated. kind regards holger From holger at moiji-mobile.com Mon Jul 29 07:06:46 2013 From: holger at moiji-mobile.com (Holger Hans Peter Freyther) Date: Mon, 29 Jul 2013 09:06:46 +0200 Subject: [PATCH 1/2] gprs_llc: Lookup lle based on the real TLLI Message-ID: During the GPRS Attach procedure we might have a foreign tlli and in the RX create a LLME on the fly for this tlli. The GMM GPRS Attach handling code will then assign a new TLLI and keep the foreign tlli as the llme->old_tlli. When the GMM is sending the identity request the msgb_tlli will point to the foreign tlli. The GPRS LLC code will then try to find that foreign tlli but due the conversion this will not be found. Instead a new ad-hoc LLE/LLME will be created on the fly for each message (this means there are duplicate LLE/LLMEs in the list). Make the code more strict and remove the tlli_foreign2local change from the look-up routine. This will make the GPRS LLC code find the right LLE/LLME and the N(U) will be handled correctly. Addresses: <0012> gprs_llc.c:773 LLC RX: unknown TLLI 0xadf11820, creating LLME on the fly ... <0012> gprs_llc.c:357 LLC TX: unknown TLLI 0xedf11820, creating LLME on the fly Reproducable: Use pcu_emu (gprs attach) and observe with wireshark. --- openbsc/src/gprs/gprs_llc.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/openbsc/src/gprs/gprs_llc.c b/openbsc/src/gprs/gprs_llc.c index 8af5367..57e557a 100644 --- a/openbsc/src/gprs/gprs_llc.c +++ b/openbsc/src/gprs/gprs_llc.c @@ -147,12 +147,10 @@ static inline uint32_t tlli_foreign2local(uint32_t tlli) } /* lookup LLC Entity based on DLCI (TLLI+SAPI tuple) */ -static struct gprs_llc_lle *lle_by_tlli_sapi(uint32_t tlli, uint8_t sapi) +static struct gprs_llc_lle *lle_by_tlli_sapi(const uint32_t tlli, uint8_t sapi) { struct gprs_llc_llme *llme; - tlli = tlli_foreign2local(tlli); - llist_for_each_entry(llme, &gprs_llc_llmes, list) { if (llme->tlli == tlli || llme->old_tlli == tlli) return &llme->lle[sapi]; -- 1.8.3.2 --UugvWAfsgieZRqgk Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="0002-gprs_llc-Assert-that-we-send-frames-with-either-tlli.patch" From holger at moiji-mobile.com Mon Jul 29 08:09:12 2013 From: holger at moiji-mobile.com (Holger Hans Peter Freyther) Date: Mon, 29 Jul 2013 10:09:12 +0200 Subject: [PATCH 2/2] gprs_llc: Assert that we send frames with either tlli or old_tlli Message-ID: In case we have access to the context verify that the selected msgb_tlli is either the old_tlli or the tlli. It is wrong to use any other TLLI. --- openbsc/src/gprs/gprs_llc.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/openbsc/src/gprs/gprs_llc.c b/openbsc/src/gprs/gprs_llc.c index 57e557a..c3bd9d2 100644 --- a/openbsc/src/gprs/gprs_llc.c +++ b/openbsc/src/gprs/gprs_llc.c @@ -52,6 +52,10 @@ static int _bssgp_tx_dl_ud(struct msgb *msg, struct sgsn_mm_ctx *mmctx) dup.drx_parms = mmctx->drx_parms; dup.ms_ra_cap.len = mmctx->ms_radio_access_capa.len; dup.ms_ra_cap.v = mmctx->ms_radio_access_capa.buf; + + /* make sure we only send it to the right llme */ + OSMO_ASSERT(msgb_tlli(msg) == mmctx->llme->tlli + || msgb_tlli(msg) == mmctx->llme->old_tlli); } memcpy(&dup.qos_profile, qos_profile_default, sizeof(qos_profile_default)); -- 1.8.3.2 --UugvWAfsgieZRqgk-- From holger at freyther.de Mon Jul 29 20:53:18 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 29 Jul 2013 22:53:18 +0200 Subject: TLLI problems and proposed solution In-Reply-To: <20130729081212.GA18752@xiaoyu.lan> References: <20130728200104.GD3624@xiaoyu.lan> <20130728205408.GE3624@xiaoyu.lan> <20130729021926.GD6319@nataraja.gnumonks.org> <20130729062632.GB18025@xiaoyu.lan> <20130729081212.GA18752@xiaoyu.lan> Message-ID: <20130729205318.GA7983@xiaoyu.lan> On Mon, Jul 29, 2013 at 10:12:12AM +0200, Holger Hans Peter Freyther wrote: > If somebody at OHM or somewhere else could/want to apply this to their > SGSN installation it would be greatly appreciated. Hi, I was doing a GPRS Attach and PDP Context Activation with one of the sysmocom GSM modules and my E71. Without the patches applied the E71 fails to re-attach after a SGSN/PCU re-start with the same symptom (all our identity requests are sent with N(U) = 0). If you don't mind I will push these two changes to master. I did this without a GGSN running and ran into the PDP Activcation Timeout... and a warning/backtrace. The below should fix it but I don't have time to verify that tonight. <000f> sgsn_libgtp.c:265 Received CREATE PDP CTX CONF, cause=-1(unknown 0xffffffff) <000f> sgsn_libgtp.c:269 Create PDP ctx req timed out <000f> gprs_sgsn.c:259 freeing PDP context that still has a libgtp handle attached to it, this shouldn't happen! backtrace() returned 11 addresses /home/ich/install/openbsc/lib/libosmocore.so.4(osmo_generate_backtrace+0x16) [0xb72fba36] ./src/gprs/osmo-sgsn() [0x804d364] ./src/gprs/osmo-sgsn() [0x804f859] /home/ich/install/openbsc/lib/libgtp.so.0(gtp_retrans+0x87) [0xb730de97] ./src/gprs/osmo-sgsn() [0x804f446] /home/ich/install/openbsc/lib/libosmocore.so.4(osmo_timers_update+0xb1) [0xb72f7b91] /home/ich/install/openbsc/lib/libosmocore.so.4(osmo_select_main+0x14b) [0xb72f7e8b] ./src/gprs/osmo-sgsn() [0x804a0d1] /lib/i386-linux-gnu/i686/cmov/libc.so.6(__libc_start_main+0xf5) [0xb70af8f5] ./src/gprs/osmo-sgsn() [0x804a17d] diff --git a/openbsc/src/gprs/sgsn_libgtp.c b/openbsc/src/gprs/sgsn_libgtp.c index f2eb35d..bdab082 100644 --- a/openbsc/src/gprs/sgsn_libgtp.c +++ b/openbsc/src/gprs/sgsn_libgtp.c @@ -294,6 +294,9 @@ reject: pctx->state = PDP_STATE_NONE; if (pdp) pdp_freepdp(pdp); + OSMO_ASSERT(pdp == pctx->lib); + pctx->lib = NULL; + /* Send PDP CTX ACT REJ to MS */ rc = gsm48_tx_gsm_act_pdp_rej(pctx->mm, pctx->ti, reject_cause, 0, NULL); From laforge at gnumonks.org Tue Jul 30 00:03:49 2013 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 30 Jul 2013 08:03:49 +0800 Subject: TLLI problems and proposed solution In-Reply-To: <20130729205318.GA7983@xiaoyu.lan> References: <20130728200104.GD3624@xiaoyu.lan> <20130728205408.GE3624@xiaoyu.lan> <20130729021926.GD6319@nataraja.gnumonks.org> <20130729062632.GB18025@xiaoyu.lan> <20130729081212.GA18752@xiaoyu.lan> <20130729205318.GA7983@xiaoyu.lan> Message-ID: <20130730000349.GC5940@nataraja.gnumonks.org> Hi Holger, On Mon, Jul 29, 2013 at 10:53:18PM +0200, Holger Hans Peter Freyther wrote: > I was doing a GPRS Attach and PDP Context Activation with one of the > sysmocom GSM modules and my E71. Without the patches applied the E71 > fails to re-attach after a SGSN/PCU re-start with the same symptom > (all our identity requests are sent with N(U) = 0). If you don't mind > I will push these two changes to master. Sure, go ahead. that's what I meant by 'be brave' :) Thanks. > I did this without a GGSN running and ran into the PDP Activcation > Timeout... and a warning/backtrace. The below should fix it but I don't > have time to verify that tonight. This seems to be a bogus warning. We do properly free the pdp library handle, but we don't set pctx->lib to NULL in this path, see the below suggested patch. From laforge at gnumonks.org Mon Jul 29 23:58:10 2013 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 30 Jul 2013 07:58:10 +0800 Subject: [PATCH] SGSN: set pctx->lib = NULL after calling pdp_freepdp(pctx->lib) Message-ID: If we don't do this, we will generate a bogus warning in gprs_sgsn:sgsn_pdp_ctx_free() when we release a pctx which still has the lib pointer set to non-NULL. At the same point, we introduce an OSMO_ASSERT() to verify that the pctx->lib really equals the pdp context which libgtp reported to us. --- openbsc/src/gprs/sgsn_libgtp.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/openbsc/src/gprs/sgsn_libgtp.c b/openbsc/src/gprs/sgsn_libgtp.c index f2eb35d..c244e2c 100644 --- a/openbsc/src/gprs/sgsn_libgtp.c +++ b/openbsc/src/gprs/sgsn_libgtp.c @@ -264,6 +264,10 @@ static int create_pdp_conf(struct pdp_t *pdp, void *cbp, int cause) DEBUGP(DGPRS, "Received CREATE PDP CTX CONF, cause=%d(%s)\n", cause, get_value_string(gtp_cause_strs, cause)); + /* make sure that libgtp doesn't call us with inconsistent + * pointers */ + OSMO_ASSERT(pctx->lib == pdp); + /* Check for cause value if it was really successful */ if (cause < 0) { LOGP(DGPRS, LOGL_NOTICE, "Create PDP ctx req timed out\n"); @@ -292,8 +296,13 @@ static int create_pdp_conf(struct pdp_t *pdp, void *cbp, int cause) reject: pctx->state = PDP_STATE_NONE; - if (pdp) + if (pdp) { pdp_freepdp(pdp); + /* unlink the now non-existing library handle from the + * pdp context */ + pctx->lib = NULL; + } + /* Send PDP CTX ACT REJ to MS */ rc = gsm48_tx_gsm_act_pdp_rej(pctx->mm, pctx->ti, reject_cause, 0, NULL); -- 1.8.3.2 -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From holger at freyther.de Tue Jul 30 06:38:44 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Tue, 30 Jul 2013 08:38:44 +0200 Subject: TLLI problems and proposed solution In-Reply-To: <20130730000349.GC5940@nataraja.gnumonks.org> References: <20130728200104.GD3624@xiaoyu.lan> <20130728205408.GE3624@xiaoyu.lan> <20130729021926.GD6319@nataraja.gnumonks.org> <20130729062632.GB18025@xiaoyu.lan> <20130729081212.GA18752@xiaoyu.lan> <20130729205318.GA7983@xiaoyu.lan> <20130730000349.GC5940@nataraja.gnumonks.org> Message-ID: <20130730063844.GA14730@xiaoyu.lan> On Tue, Jul 30, 2013 at 08:03:49AM +0800, Harald Welte wrote: > This seems to be a bogus warning. We do properly free the pdp library > handle, but we don't set pctx->lib to NULL in this path, see the below > suggested patch. The warning is actually right. gtp.c: if (gsn->cb_conf) gsn->cb_conf(qmsg->type, EOF, NULL, qmsg->cbp); the NULL is the pdp context here > + OSMO_ASSERT(pctx->lib == pdp); did fail because of that. I will check and free pctx->lib as well and push it in a couple of minutes. From holger at freyther.de Tue Jul 30 07:20:38 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Tue, 30 Jul 2013 09:20:38 +0200 Subject: TLLI problems and proposed solution In-Reply-To: <20130730000349.GC5940@nataraja.gnumonks.org> References: <20130728200104.GD3624@xiaoyu.lan> <20130728205408.GE3624@xiaoyu.lan> <20130729021926.GD6319@nataraja.gnumonks.org> <20130729062632.GB18025@xiaoyu.lan> <20130729081212.GA18752@xiaoyu.lan> <20130729205318.GA7983@xiaoyu.lan> <20130730000349.GC5940@nataraja.gnumonks.org> Message-ID: <20130730072038.GC14730@xiaoyu.lan> On Tue, Jul 30, 2013 at 08:03:49AM +0800, Harald Welte wrote: > > Sure, go ahead. that's what I meant by 'be brave' :) The engineer in me.. used git gui blame on the file and I found the commit that added the foreign tlli lookup. commit f0901f0067e363c0ced6254db1b45a9771640412 Author: Harald Welte Date: Sun Dec 26 10:39:26 2010 +0100 [SGSN] Fix processing of RA Update Request regarding TLLI In case we get a RA UPD REQ on a new cell (both served by the same SGSN), the LLC stack should not allocate a ne LLE/LLME, as the latter would reset the V(u)sent / V(u)recv to zero and make the MS discard our responses. Instead, whenever the LLC stack sees a foreign TLLI, it should always convert it to the local TLLI before doing any lookup for a LLE/LLME. I had to move some code around but what I essentialy do is. 1.) I do the lookup based on the tlli... 2.) if the tlli is foreign.. I convert it and make another lookup 3.) I create the LLME on the fly or return NULL Or shall we do this... "oh we know this subscriber already" at a higher level in GMM? E.g. notice that it is a routing area update... and then free the new llme and do a tlli assignment for the foreign tlli? diff --git a/openbsc/src/gprs/gprs_llc.c b/openbsc/src/gprs/gprs_llc.c index c3bd9d2..b637acb 100644 --- a/openbsc/src/gprs/gprs_llc.c +++ b/openbsc/src/gprs/gprs_llc.c @@ -36,6 +36,54 @@ #include #include +enum gprs_llc_cmd { + GPRS_LLC_NULL, + GPRS_LLC_RR, + GPRS_LLC_ACK, + GPRS_LLC_RNR, + GPRS_LLC_SACK, + GPRS_LLC_DM, + GPRS_LLC_DISC, + GPRS_LLC_UA, + GPRS_LLC_SABM, + GPRS_LLC_FRMR, + GPRS_LLC_XID, + GPRS_LLC_UI, +}; + +static const struct value_string llc_cmd_strs[] = { + { GPRS_LLC_NULL, "NULL" }, + { GPRS_LLC_RR, "RR" }, + { GPRS_LLC_ACK, "ACK" }, + { GPRS_LLC_RNR, "RNR" }, + { GPRS_LLC_SACK, "SACK" }, + { GPRS_LLC_DM, "DM" }, + { GPRS_LLC_DISC, "DISC" }, + { GPRS_LLC_UA, "UA" }, + { GPRS_LLC_SABM, "SABM" }, + { GPRS_LLC_FRMR, "FRMR" }, + { GPRS_LLC_XID, "XID" }, + { GPRS_LLC_UI, "UI" }, + { 0, NULL } +}; + +struct gprs_llc_hdr_parsed { + uint8_t sapi; + uint8_t is_cmd:1, + ack_req:1, + is_encrypted:1; + uint32_t seq_rx; + uint32_t seq_tx; + uint32_t fcs; + uint32_t fcs_calc; + uint8_t *data; + uint16_t data_len; + uint16_t crc_length; + enum gprs_llc_cmd cmd; +}; + +static struct gprs_llc_llme *llme_alloc(uint32_t tlli); + /* Entry function from upper level (LLC), asking us to transmit a BSSGP PDU * to a remote MS (identified by TLLI) at a BTS identified by its BVCI and NSEI */ static int _bssgp_tx_dl_ud(struct msgb *msg, struct sgsn_mm_ctx *mmctx) @@ -162,6 +210,43 @@ static struct gprs_llc_lle *lle_by_tlli_sapi(const uint32_t tlli, uint8_t sapi) return NULL; } +/* lookup LLC Entity for RX based on DLCI (TLLI+SAPI tuple) */ +static struct gprs_llc_lle *lle_for_rx_by_tlli_sapi(const uint32_t tlli, + uint8_t sapi, enum gprs_llc_cmd cmd) +{ + struct gprs_llc_lle *lle; + + /* We already know about this TLLI */ + lle = lle_by_tlli_sapi(tlli, sapi); + if (lle) + return lle; + + /* Maybe it is a routing area update but we already know this sapi? */ + if (gprs_tlli_type(tlli) == TLLI_FOREIGN) { + lle = lle_by_tlli_sapi(tlli_foreign2local(tlli), sapi); + if (lle) + return lle; + } + + /* 7.2.1.1 LLC belonging to unassigned TLLI+SAPI shall be discarded, + * except UID and XID frames with SAPI=1 */ + if (sapi == GPRS_SAPI_GMM && + (cmd == GPRS_LLC_XID || cmd == GPRS_LLC_UI)) { + struct gprs_llc_llme *llme; + /* FIXME: don't use the TLLI but the 0xFFFF unassigned? */ + llme = llme_alloc(tlli); + LOGP(DLLC, LOGL_DEBUG, "LLC RX: unknown TLLI 0x%08x, " + "creating LLME on the fly\n", tlli); + lle = &llme->lle[sapi]; + return lle; + } + + LOGP(DLLC, LOGL_NOTICE, + "unknown TLLI(0x%08x)/SAPI(%d): Silently dropping\n", + tlli, sapi); + return NULL; +} + static void lle_init(struct gprs_llc_llme *llme, uint8_t sapi) { struct gprs_llc_lle *lle = &llme->lle[sapi]; @@ -201,52 +286,6 @@ static void llme_free(struct gprs_llc_llme *llme) talloc_free(llme); } -enum gprs_llc_cmd { - GPRS_LLC_NULL, - GPRS_LLC_RR, - GPRS_LLC_ACK, - GPRS_LLC_RNR, - GPRS_LLC_SACK, - GPRS_LLC_DM, - GPRS_LLC_DISC, - GPRS_LLC_UA, - GPRS_LLC_SABM, - GPRS_LLC_FRMR, - GPRS_LLC_XID, - GPRS_LLC_UI, -}; - -static const struct value_string llc_cmd_strs[] = { - { GPRS_LLC_NULL, "NULL" }, - { GPRS_LLC_RR, "RR" }, - { GPRS_LLC_ACK, "ACK" }, - { GPRS_LLC_RNR, "RNR" }, - { GPRS_LLC_SACK, "SACK" }, - { GPRS_LLC_DM, "DM" }, - { GPRS_LLC_DISC, "DISC" }, - { GPRS_LLC_UA, "UA" }, - { GPRS_LLC_SABM, "SABM" }, - { GPRS_LLC_FRMR, "FRMR" }, - { GPRS_LLC_XID, "XID" }, - { GPRS_LLC_UI, "UI" }, - { 0, NULL } -}; - -struct gprs_llc_hdr_parsed { - uint8_t sapi; - uint8_t is_cmd:1, - ack_req:1, - is_encrypted:1; - uint32_t seq_rx; - uint32_t seq_tx; - uint32_t fcs; - uint32_t fcs_calc; - uint8_t *data; - uint16_t data_len; - uint16_t crc_length; - enum gprs_llc_cmd cmd; -}; - #define LLC_ALLOC_SIZE 16384 #define UI_HDR_LEN 3 #define N202 4 @@ -770,25 +809,9 @@ int gprs_llc_rcvmsg(struct msgb *msg, struct tlv_parsed *tv) } /* find the LLC Entity for this TLLI+SAPI tuple */ - lle = lle_by_tlli_sapi(msgb_tlli(msg), llhp.sapi); - - /* 7.2.1.1 LLC belonging to unassigned TLLI+SAPI shall be discarded, - * except UID and XID frames with SAPI=1 */ - if (!lle) { - if (llhp.sapi == GPRS_SAPI_GMM && - (llhp.cmd == GPRS_LLC_XID || llhp.cmd == GPRS_LLC_UI)) { - struct gprs_llc_llme *llme; - /* FIXME: don't use the TLLI but the 0xFFFF unassigned? */ - llme = llme_alloc(msgb_tlli(msg)); - LOGP(DLLC, LOGL_DEBUG, "LLC RX: unknown TLLI 0x%08x, " - "creating LLME on the fly\n", msgb_tlli(msg)); - lle = &llme->lle[llhp.sapi]; - } else { - LOGP(DLLC, LOGL_NOTICE, - "unknown TLLI/SAPI: Silently dropping\n"); - return 0; - } - } + lle = lle_for_rx_by_tlli_sapi(msgb_tlli(msg), llhp.sapi, llhp.cmd); + if (!lle) + return 0; /* decrypt information field + FCS, if needed! */ if (llhp.is_encrypted) { From holger at freyther.de Tue Jul 30 08:05:24 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Tue, 30 Jul 2013 10:05:24 +0200 Subject: TLLI problems and proposed solution In-Reply-To: <20130730072038.GC14730@xiaoyu.lan> References: <20130728200104.GD3624@xiaoyu.lan> <20130728205408.GE3624@xiaoyu.lan> <20130729021926.GD6319@nataraja.gnumonks.org> <20130729062632.GB18025@xiaoyu.lan> <20130729081212.GA18752@xiaoyu.lan> <20130729205318.GA7983@xiaoyu.lan> <20130730000349.GC5940@nataraja.gnumonks.org> <20130730072038.GC14730@xiaoyu.lan> Message-ID: <20130730080524.GE14730@xiaoyu.lan> On Tue, Jul 30, 2013 at 09:20:38AM +0200, Holger Hans Peter Freyther wrote: > Or shall we do this... "oh we know this subscriber already" at a > higher level in GMM? E.g. notice that it is a routing area update... > and then free the new llme and do a tlli assignment for the foreign > tlli? The patch is not enough.. I ran into the newly added ASSERT about the TLLI. 1.) E71 attach to a network and create a PDP context.. 2.) Restart SGSN/GGSN 3.) Phone tries Activate/Deactivate PDP Context.. we send a GMM status with impl. detached.. E71 sends a SM Status for protocol error 4.) Re-open the browser app... it tries GPRS Attach for a foreign tlli (based on the old one).. we find it.. the state doesn't match so there is re-transmission going on.. once we have the righ seq. number the RX will find the 'right' LLME.. but on TX for the foreign TLLI we create a LLME on the fly and run into the assert... I can now extend the second phase of look-ups and soften the assert a bit but I do wonder if that is the correct thing to do. I added the below diff.. but it is probably better to check if one could combine these llme's at a higher level? Or at least free the old LLME and use the new one? My last problem right now is that LLC data is not sent to the GGSN.. :} <0012> gprs_llc.c:543 LLC SAPI=1 C FCS=0xd85a2cCMD=UI DATA <0012> gprs_llc.c:194 TLLI 0xa44240f7 is foreign, converting to local TLLI 0xe44240f7 <0012> gprs_llc.c:409 LLC TX: unknown TLLI 0xa44240f7, creating LLME on the fly Assert failed msgb_tlli(msg) == mmctx->llme->tlli || msgb_tlli(msg) == mmctx->llme->old_tlli gprs_llc.c:106 backtrace() returned 20 addresses /home/ich/install/openbsc/lib/libosmocore.so.4(osmo_generate_backtrace+0x16) [0xb7bb6a36] /home/ich/source/gsm/openbsc/openbsc/src/gprs/osmo-sgsn() [0x8049dc5] /home/ich/source/gsm/openbsc/openbsc/src/gprs/osmo-sgsn() [0x8052085] /home/ich/source/gsm/openbsc/openbsc/src/gprs/osmo-sgsn() [0x804a326] /home/ich/source/gsm/openbsc/openbsc/src/gprs/osmo-sgsn() [0x804a8ff] /home/ich/source/gsm/openbsc/openbsc/src/gprs/osmo-sgsn() [0x804ac42] /home/ich/source/gsm/openbsc/openbsc/src/gprs/osmo-sgsn() [0x804b3e5] /home/ich/source/gsm/openbsc/openbsc/src/gprs/osmo-sgsn() [0x804bd9f] /home/ich/source/gsm/openbsc/openbsc/src/gprs/osmo-sgsn() [0x804d23c] /home/ich/source/gsm/openbsc/openbsc/src/gprs/osmo-sgsn() [0x8052a24] /home/ich/source/gsm/openbsc/openbsc/src/gprs/osmo-sgsn(bssgp_prim_cb+0x55) [0x804f5d4] /home/ich/install/openbsc/lib/libosmogb.so.2(bssgp_rcvmsg+0x3b8) [0xb7b626b8] /home/ich/source/gsm/openbsc/openbsc/src/gprs/osmo-sgsn() [0x804f521] /home/ich/install/openbsc/lib/libosmogb.so.2(gprs_ns_rcvmsg+0x8c7) [0xb7b5ecf7] /home/ich/install/openbsc/lib/libosmogb.so.2(+0x4311) [0xb7b5f311] /home/ich/install/openbsc/lib/libosmocore.so.4(osmo_select_main+0x192) [0xb7bb2ed2] /home/ich/source/gsm/openbsc/openbsc/src/gprs/osmo-sgsn() [0x804fbfd] /lib/i386-linux-gnu/i686/cmov/libc.so.6(__libc_start_main+0xf5) [0xb796a8f5] /home/ich/source/gsm/openbsc/openbsc/src/gprs/osmo-sgsn() [0x8049ded] Program received signal SIGABRT, Aborted. 0xb7fde424 in __kernel_vsyscall () (gdb) bt #0 0xb7fde424 in __kernel_vsyscall () #1 0xb797f83f in __GI_raise (sig=sig at entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #2 0xb7982cf3 in __GI_abort () at abort.c:90 #3 0x08049dca in _bssgp_tx_dl_ud (mmctx=, msg=) at gprs_llc.c:105 #4 0x08052085 in gprs_llc_tx_ui (msg=0x8092ba8, sapi=1 '\001', command=1, mmctx=0x8092700) at gprs_llc.c:417 #5 0x0804a326 in gsm48_gmm_sendmsg (msg=0x8092ba8, command=1, mm=0x8092700) at gprs_gmm.c:241 #6 0x0804a8ff in gsm48_tx_gmm_id_req (mm=0x8092700, id_type=2 '\002') at gprs_gmm.c:454 #7 0x0804ac42 in gsm48_gmm_authorize (ctx=0x8092700, t3350_mode=GMM_T3350_MODE_ATT) at gprs_gmm.c:560 #8 0x0804b3e5 in gsm48_rx_gmm_att_req (ctx=0x8092700, msg=0x8090f98, llme=0x8091ce8) at gprs_gmm.c:765 #9 0x0804bd9f in gsm0408_rcv_gmm (mmctx=0x0, msg=0x8090f98, llme=0x8091ce8) at gprs_gmm.c:1039 #10 0x0804d23c in gsm0408_gprs_rcvmsg (msg=msg at entry=0x8090f98, llme=0x8091ce8) at gprs_gmm.c:1566 #11 0x08052a24 in gprs_llc_rcvmsg (msg=0x8090f98, tv=0xbfffdcb0) at gprs_llc.c:874 #12 0x0804f5d4 in bssgp_prim_cb (oph=oph at entry=0xbfffdc8c, ctx=ctx at entry=0x0) at sgsn_main.c:114 #13 0xb7b626b8 in bssgp_rx_ul_ud (tp=0xbfffdcb0, msg=0x8090f98, ctx=) at gprs_bssgp.c:398 #14 bssgp_rx_ptp (bctx=0x8091a08, tp=0xbfffdcb0, msg=0x8090f98) at gprs_bssgp.c:820 #15 bssgp_rcvmsg (msg=0x8090f98) at gprs_bssgp.c:1016 #16 0x0804f521 in sgsn_ns_cb (event=GPRS_NS_EVT_UNIT_DATA, nsvc=0x8090740, msg=0x8090f98, bvci=1801) at sgsn_main.c:92 #17 0xb7b5ecf7 in gprs_ns_rx_unitdata (msg=0x8090f98, nsvc=0x8090740) at gprs_ns.c:616 #18 gprs_ns_rcvmsg (nsi=nsi at entry=0x807fd38, msg=msg at entry=0x8090f98, saddr=saddr at entry=0xbfffedc0, ll=ll at entry=GPRS_NS_LL_UDP) at gprs_ns.c:841 #19 0xb7b5f311 in handle_nsip_read (bfd=0x807fd58) at gprs_ns.c:991 diff --git a/openbsc/src/gprs/gprs_llc.c b/openbsc/src/gprs/gprs_llc.c index b637acb..f0930f6 100644 --- a/openbsc/src/gprs/gprs_llc.c +++ b/openbsc/src/gprs/gprs_llc.c @@ -84,6 +84,22 @@ struct gprs_llc_hdr_parsed { static struct gprs_llc_llme *llme_alloc(uint32_t tlli); +/* If the TLLI is foreign, return its local version */ +static inline uint32_t tlli_foreign2local(uint32_t tlli) +{ + uint32_t new_tlli; + + if (gprs_tlli_type(tlli) == TLLI_FOREIGN) { + new_tlli = tlli | 0x40000000; + DEBUGP(DLLC, "TLLI 0x%08x is foreign, converting to " + "local TLLI 0x%08x\n", tlli, new_tlli); + } else + new_tlli = tlli; + + return new_tlli; +} + + /* Entry function from upper level (LLC), asking us to transmit a BSSGP PDU * to a remote MS (identified by TLLI) at a BTS identified by its BVCI and NSEI */ static int _bssgp_tx_dl_ud(struct msgb *msg, struct sgsn_mm_ctx *mmctx) @@ -103,7 +119,8 @@ static int _bssgp_tx_dl_ud(struct msgb *msg, struct sgsn_mm_ctx *mmctx) /* make sure we only send it to the right llme */ OSMO_ASSERT(msgb_tlli(msg) == mmctx->llme->tlli - || msgb_tlli(msg) == mmctx->llme->old_tlli); + || msgb_tlli(msg) == mmctx->llme->old_tlli + || tlli_foreign2local(msgb_tlli(msg)) == mmctx->llme->tlli); } memcpy(&dup.qos_profile, qos_profile_default, sizeof(qos_profile_default)); @@ -183,21 +200,6 @@ static const struct gprs_llc_params llc_default_params[] = { LLIST_HEAD(gprs_llc_llmes); void *llc_tall_ctx; -/* If the TLLI is foreign, return its local version */ -static inline uint32_t tlli_foreign2local(uint32_t tlli) -{ - uint32_t new_tlli; - - if (gprs_tlli_type(tlli) == TLLI_FOREIGN) { - new_tlli = tlli | 0x40000000; - DEBUGP(DLLC, "TLLI 0x%08x is foreign, converting to " - "local TLLI 0x%08x\n", tlli, new_tlli); - } else - new_tlli = tlli; - - return new_tlli; -} - /* lookup LLC Entity based on DLCI (TLLI+SAPI tuple) */ static struct gprs_llc_lle *lle_by_tlli_sapi(const uint32_t tlli, uint8_t sapi) { @@ -224,8 +226,12 @@ static struct gprs_llc_lle *lle_for_rx_by_tlli_sapi(const uint32_t tlli, /* Maybe it is a routing area update but we already know this sapi? */ if (gprs_tlli_type(tlli) == TLLI_FOREIGN) { lle = lle_by_tlli_sapi(tlli_foreign2local(tlli), sapi); - if (lle) + if (lle) { + LOGP(DLLC, LOGL_NOTICE, + "LLC RX: Found a local entry for TLLI 0x%08x\n", + tlli); return lle; + } } /* 7.2.1.1 LLC belonging to unassigned TLLI+SAPI shall be discarded, @@ -403,6 +409,8 @@ int gprs_llc_tx_ui(struct msgb *msg, uint8_t sapi, int command, /* look-up or create the LL Entity for this (TLLI, SAPI) tuple */ lle = lle_by_tlli_sapi(msgb_tlli(msg), sapi); + if (!lle) + lle = lle_by_tlli_sapi(tlli_foreign2local(msgb_tlli(msg)), sapi); if (!lle) { struct gprs_llc_llme *llme; LOGP(DLLC, LOGL_ERROR, "LLC TX: unknown TLLI 0x%08x, " From holger at freyther.de Tue Jul 30 09:03:12 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Tue, 30 Jul 2013 11:03:12 +0200 Subject: TLLI problems and proposed solution In-Reply-To: <20130730080524.GE14730@xiaoyu.lan> References: <20130728200104.GD3624@xiaoyu.lan> <20130728205408.GE3624@xiaoyu.lan> <20130729021926.GD6319@nataraja.gnumonks.org> <20130729062632.GB18025@xiaoyu.lan> <20130729081212.GA18752@xiaoyu.lan> <20130729205318.GA7983@xiaoyu.lan> <20130730000349.GC5940@nataraja.gnumonks.org> <20130730072038.GC14730@xiaoyu.lan> <20130730080524.GE14730@xiaoyu.lan> Message-ID: <20130730090312.GI14730@xiaoyu.lan> On Tue, Jul 30, 2013 at 10:05:24AM +0200, Holger Hans Peter Freyther wrote: > I added the below diff.. but it is probably better to check if one could > combine these llme's at a higher level? Or at least free the old LLME > and use the new one? My last problem right now is that LLC data is not > sent to the GGSN.. :} *aehm* i had a hacked-up libgtp... for doing some perf measurements of tun0... I am currently attempting to watch youtube on my E71.. but it is buffering a lot and the 10s PDU lifetime does not appear big eough.. so there are a lot of re-transmissions going on. > /* make sure we only send it to the right llme */ > OSMO_ASSERT(msgb_tlli(msg) == mmctx->llme->tlli > - || msgb_tlli(msg) == mmctx->llme->old_tlli); > + || msgb_tlli(msg) == mmctx->llme->old_tlli > + || tlli_foreign2local(msgb_tlli(msg)) == mmctx->llme->tlli); and add the same for the old_tlli. :} From laforge at gnumonks.org Tue Jul 30 17:25:05 2013 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 31 Jul 2013 01:25:05 +0800 Subject: TLLI problems and proposed solution In-Reply-To: <20130730072038.GC14730@xiaoyu.lan> References: <20130728200104.GD3624@xiaoyu.lan> <20130728205408.GE3624@xiaoyu.lan> <20130729021926.GD6319@nataraja.gnumonks.org> <20130729062632.GB18025@xiaoyu.lan> <20130729081212.GA18752@xiaoyu.lan> <20130729205318.GA7983@xiaoyu.lan> <20130730000349.GC5940@nataraja.gnumonks.org> <20130730072038.GC14730@xiaoyu.lan> Message-ID: <20130730172505.GK5732@nataraja.gnumonks.org> Hi Holger, On Tue, Jul 30, 2013 at 09:20:38AM +0200, Holger Hans Peter Freyther wrote: > The engineer in me.. used git gui blame on the file and I found the commit > that added the foreign tlli lookup. thanks. > 1.) I do the lookup based on the tlli... > 2.) if the tlli is foreign.. I convert it and make another lookup > 3.) I create the LLME on the fly or return NULL seems reasonable. > Or shall we do this... "oh we know this subscriber already" at a > higher level in GMM? E.g. notice that it is a routing area update... > and then free the new llme and do a tlli assignment for the foreign > tlli? That is probably the cleaner approach. I'm wondering why there is no information in the spec regarding that case, or at least why I haven't been stumbling accross it. If it is done at LLC level, it seems the more 'defensive' / tolerant approach, because we don't expect the first LLC message on a new BTS to be a GMM/RAU message. I'm not sure if this is guaranteed by the specs. If the first LLC message on the new cell is a user data message, then the GMM/RAU based approach of adressing this problem would not work. 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 Mon Jul 29 10:39:18 2013 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 29 Jul 2013 18:39:18 +0800 Subject: TLLI problems and proposed solution In-Reply-To: <20130729062632.GB18025@xiaoyu.lan> References: <20130728200104.GD3624@xiaoyu.lan> <20130728205408.GE3624@xiaoyu.lan> <20130729021926.GD6319@nataraja.gnumonks.org> <20130729062632.GB18025@xiaoyu.lan> Message-ID: <20130729103918.GE6919@nataraja.gnumonks.org> Hi Holger, On Mon, Jul 29, 2013 at 08:26:32AM +0200, Holger Hans Peter Freyther wrote: > Okay. That does make sense. Thanks for going through the specs. No problem, I looked at this TLLI issue again and again over the years, and still there seem to be some bugs in the code :/ > > I'm not really sure if a PCU really needs this, at least not as long as > > we always include the IMSI as part of BSSGP Downlink Unitdata. At that > > point, the PCU can look-up its MS-contaxt based on the IMSI. The spec > > says: > > The osmo-pcu is broken in this regard. It will only use the TLLI to > identify the temporary block flow (tbf). I will shuffle the code > around to resolve that limitation and create unit tests for that. This is indeed broken. The TBF should be looked up by the IMSI. Looking it up by TLLI should only be neccessary if the BSSGP-DL-UD has no IMSI in it (e.g. the IDENTITY REEQUEST (IMSI) after an ATTACH REQUEST with unknown P-TMSI). > > So this would be the case if we get an ATTACH_REQ or RAU_REQ with P-TMSI > > only, but have not yet sent the IDENTITY REQUEST or not received the > > IDENTITY RESPONSE yet. At that point, we don't issue any llgmm_assign() > > requests to LLC yet, and thus are guaranteed that we always know the > > IMSI at the time we have a TLLI change. > > > > Do you agree? > > Yes, but we do issue llgm_assign in that case (and that is the case > I can simulate right now). I think the llgm_assign should just be for > the foriegn tlli we received (and not from the one dervied by the > P-TMSI that we didn't allocate). But the LLGMM-ASSIGN.req that we issue at that point (with old and new tlli != 0xffffffff) explicitly enables both old and new IMSI for uplink, see my other mail. This is what I believe to be the right thing at that point. In this case (old and new != all-1) both the new and the old tlli are accepted. > > If TLLI Old ? all 1's and TLLI New ? all 1's then TLLI Old and TLLI > > New are assigned, and TLLI New shall be used when (re-)transmitting > > LLC frames. Both TLLI Old and TLLI New shall be accepted when > > received from the peer. It shall be treated as a TLLI change > > according to subclause 8.3.2. > > but for the above ATTACH case with a unknown P-TMSI/TLLI. We will do > the assignment but use TLLI Old for the transmissionof any frame. Yes, we basically override the LLC logic of "accept old and new in Rx, use new in tx" specifically by setting msgb_tlli(msg) manually to the old tlli. The point is, until the GMM message assigning a new P-TMSI has been successfully received by the MS, the MS has no clue what the new TLLI might be. So until the SGSN knows that this GMM message has been successfully received by the MS, the SGSN should continue to use the old TLLI in downlink. Only once the MS has acknowledged in GMM that the new P-TMSI has been received (by RAU_COMPLETE / ATTACH_COMPLETE), the SGSN knows that the MS has successfully switched to the new TLLI. Also, at the same time, any frame that wer receive from the MS using the new TLLI will implicitly tell us (even at the LLC layer, without involving GMM) that the MS has received the new P-TMSI, because it starts to use it. The specs seem to have some contradiction here. If you look at 24.008 it says in 4.7.1.4.1: Although the MS derives a local TLLI for addressing at lower layers, the network should not assume that it will receive only LLC frames using a local TLLI. Immediately after the successful GPRS attach or routing area update procedure, the network must be prepared to continue accepting LLC frames from the MS still using the foreign TLLI. Which is a bit odd. Why would we receive old TLLI _after_ the respective COMPLETE messages? But at least for downlink, it is pretty clear: In both cases, the MS shall acknowledge the reception of the assigned P-TMSI to the network. After receipt of the acknowledgement, the network shall use the local TLLI for addressing at lower layers. Furthermore: Upon receipt of a GMM message containing a new P-TMSI the MS shall consider the new P-TMSI and new RAI and also the old P-TMSI and old RAI as valid in order to react to paging requests and downlink transmission of LLC frames. For uplink transmission of LLC frames the new P-TMSI shall be used. i.e. the ATTACH_COMPLETE/RAU_COMPLETE should be the first message with the new TLLI. And: The MS shall consider the old P-TMSI and old RAI as invalid as soon as an LLC frame is received with the local TLLI derived from the new P-TMSI. So maybe we should send an empty frame (LLGMM-TRIGGER.req? but that exists only on the MS side of LLC, not the SGSN side) in downlink after the RAU_COMPLETE / ATTACH_COMPLETE with the new TLLI? However, the transmission is unreliable and it could get lost. So I guess there's no point in even trying to send a message with new TLLI to the MS, if we don't get a layer3-acknowledgement back. So the only really odd part is that 04.64 states that after LLGMM-ASSIGN(old!=ff, new!=ff) we should use the new TLLI for downlink transmit, while 24.008 states that we should continue to use the old TLLI for downlink transmit until we receive the ATTACH_COMPLETE and/or first uplink LLC message with new TLLI. As I don't know of what use the 04.64-specified behavior (receive old+new, transmit with new only) should be, I think it might be wrong and actually the behavior should be that tx should be done with old TLLI. In order to still have LLGMM-ASSIGN.req like specified in 04.64 _and_ fulfill the 24.008 requirements, we override the outgoing TLLI by using msgb_tlli(msg) = mmctx->tlli (which is the old tlli) in GMM. > > Later, when we get the ATTACH_COMPLETE / RAU_COMPLETE from the MS, > > we > > > > a) set mmctx->tlli = mmctx->tlli_new > > b) issue a LLGMM-ASSIGN.req primitive to LLC with old TMSI 0xffffffff > > and new TMSI = mmctx->tlli_new. According to spec, this is the > > following case: > > > > If TLLI Old = all 1's and TLLI New ? all 1's then TLLI New shall be > > assigned and used when (re-)transmitting LLC frames. If a TLLI Old ? > > all 1's was assigned to the LLME, then TLLI Old is unassigned. Only > > TLLI New shall be accepted when received from the peer. It shall be > > treated as a TLLI change according to subclause 8.3.2. > > but that means that llme->old_tlli will be all 1's and that even if > we want to.. in gprs_llc we could not set dup.tlli to the previous tlli? > So the next download unitdata can not have the IE_TLLI set? yes, this appears to be correct (and thus maybe good that dup.tlli is not set in current code). In order to do this as per spec (which is stupid, as the PCU has the IMSI to identify the MS), we would probably have to keep a flag in the LLME indicating that 'recently the old tlli was unassigned'. During transmission of the next downlink frame (which may be hours later!) we then include that 'very_old_tlli' as second IE_TLLI in the BSSGP-DL-UD. However, if it is really that much later, then there is no TBF anymore in the PCU anyway ;) So this all only makes sense if the SGSN is _soon_ after the TLLI/P-TMSI change sending moere data (signalling or user-data) in downlink. As TBFs have a very short life-time, I would currently argue to simply ignore (+ document) this behavior for Gb. Make sure that osmo-pcu uses the ISMI if present, and hope that other PCU implementors also do it that way. > Okay, I will modify the lle_by_tlli_sapi look-up to not use the > foreign conversion at all. This would fix my case.. Great. I will do some manual testing with sysmobts/osmo-pcu/osmo-sgsn using that patch later tonight. > but given the lack of unit tests I don't know what I break. :) ah well, just be brave :) 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 Mon Jul 29 02:35:47 2013 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 29 Jul 2013 10:35:47 +0800 Subject: TLLI problems and proposed solution In-Reply-To: <20130728200104.GD3624@xiaoyu.lan> References: <20130728200104.GD3624@xiaoyu.lan> Message-ID: <20130729023547.GE6319@nataraja.gnumonks.org> Hi Holger, just to explicitly respond to this sentence in your first message on the subject: On Sun, Jul 28, 2013 at 10:01:04PM +0200, Holger Hans Peter Freyther wrote: > So this means that for the entire GPRS attach procedure we will use the > initial foreign TLLI.... Which I believe is correct. The RAU_COMPLETE / ATTACH_COMPLETE should be the first message in downlink containing the new TLLI from my point of view. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From holger at freyther.de Mon Jul 29 06:08:18 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 29 Jul 2013 08:08:18 +0200 Subject: TLLI problems and proposed solution In-Reply-To: <20130729023547.GE6319@nataraja.gnumonks.org> References: <20130728200104.GD3624@xiaoyu.lan> <20130729023547.GE6319@nataraja.gnumonks.org> Message-ID: <20130729060818.GA18025@xiaoyu.lan> On Mon, Jul 29, 2013 at 10:35:47AM +0800, Harald Welte wrote: > Hi Holger, > > just to explicitly respond to this sentence in your first message on the > subject: > > On Sun, Jul 28, 2013 at 10:01:04PM +0200, Holger Hans Peter Freyther wrote: > > So this means that for the entire GPRS attach procedure we will use the > > initial foreign TLLI.... > > Which I believe is correct. The RAU_COMPLETE / ATTACH_COMPLETE should be > the first message in downlink containing the new TLLI from my point of > view. Thank you for the detailed answer (in the other email). But doesn't this mean that the gprs_llgmm_assign in gsm48_rx_gmm_att_req is a bit early? E.g. something like this: diff --git a/openbsc/src/gprs/gprs_gmm.c b/openbsc/src/gprs/gprs_gmm.c index f7a5cde..b981fb7 100644 --- a/openbsc/src/gprs/gprs_gmm.c +++ b/openbsc/src/gprs/gprs_gmm.c @@ -758,7 +758,7 @@ static int gsm48_rx_gmm_att_req(struct sgsn_mm_ctx *ctx, struct msgb *msg, ctx->tlli_new = gprs_tmsi2tlli(ctx->p_tmsi, TLLI_LOCAL); /* Inform LLC layer about new TLLI but keep old active */ - gprs_llgmm_assign(ctx->llme, ctx->tlli, ctx->tlli_new, + gprs_llgmm_assign(ctx->llme, 0xffffffff,, ctx->tlli, GPRS_ALGO_GEA0, NULL); DEBUGPC(DMM, "\n"); and then in GMM_ATTACH_COMPLETE we will assign tlli_new? From laforge at gnumonks.org Mon Jul 29 10:04:05 2013 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 29 Jul 2013 18:04:05 +0800 Subject: TLLI problems and proposed solution In-Reply-To: <20130729060818.GA18025@xiaoyu.lan> References: <20130728200104.GD3624@xiaoyu.lan> <20130729023547.GE6319@nataraja.gnumonks.org> <20130729060818.GA18025@xiaoyu.lan> Message-ID: <20130729100405.GD6919@nataraja.gnumonks.org> Hi Holger, On Mon, Jul 29, 2013 at 08:08:18AM +0200, Holger Hans Peter Freyther wrote: > > Which I believe is correct. The RAU_COMPLETE / ATTACH_COMPLETE should be > > the first message in downlink containing the new TLLI from my point of > > view. > > Thank you for the detailed answer (in the other email). But doesn't this > mean that the gprs_llgmm_assign in gsm48_rx_gmm_att_req is a bit early? > > E.g. something like this: > > /* Inform LLC layer about new TLLI but keep old active */ > - gprs_llgmm_assign(ctx->llme, ctx->tlli, ctx->tlli_new, > + gprs_llgmm_assign(ctx->llme, 0xffffffff,, ctx->tlli, Why? This would be the following case: LLGMM-ASSIGN.req (7.2.1.1 of 04.64): The TLLI Old and TLLI New parameters shall be interpreted as follows: If TLLI Old = all 1's and TLLI New ? all 1's then TLLI New shall be assigned and used when (re-)transmitting LLC frames. If a TLLI Old ? all 1's was assigned to the LLME, then TLLI Old is unassigned. Only TLLI New shall be accepted when received from the peer. It shall be treated as a TLLI change according to subclause 8.3.2. This would mean that the tlli_old (which is stored in the LLME up to the call to your proposed "gprs_llgmm_assign(ctx->llme, 0xffffffff, ctx->tlli") would no longer be accepted on the Rx side. However, what we want at this point is to accept old _and_ new TLLI, which is: LLGMM-ASSIGN.req (7.2.1.1 of 04.64): The TLLI Old and TLLI New parameters shall be interpreted as follows: If TLLI Old ? all 1's and TLLI New ? all 1's then TLLI Old and TLLI New are assigned, and TLLI New shall be used when (re-)transmitting LLC frames. Both TLLI Old and TLLI New shall be accepted when received from the peer. It shall be treated as a TLLI change according to subclause 8.3.2. So we accept both old and new from the MS, which is what we want. However, to my understanding, we actually don't want to use the new TLLI for TX, which is why we use msgb_tlli(msg) = old_tlli to explicitly request that tlli to be used. So I still think that at least _this_ part of the existing code is doing it right. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From holger at freyther.de Mon Jul 29 11:21:00 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 29 Jul 2013 13:21:00 +0200 Subject: TLLI problems and proposed solution In-Reply-To: <20130729100405.GD6919@nataraja.gnumonks.org> References: <20130728200104.GD3624@xiaoyu.lan> <20130729023547.GE6319@nataraja.gnumonks.org> <20130729060818.GA18025@xiaoyu.lan> <20130729100405.GD6919@nataraja.gnumonks.org> Message-ID: <20130729112100.GC18752@xiaoyu.lan> On Mon, Jul 29, 2013 at 06:04:05PM +0800, Harald Welte wrote: > Hi Holger, Good Evening, > > /* Inform LLC layer about new TLLI but keep old active */ > > - gprs_llgmm_assign(ctx->llme, ctx->tlli, ctx->tlli_new, > > + gprs_llgmm_assign(ctx->llme, 0xffffffff,, ctx->tlli, > > Why? Well, in case of GPRS Attach of a roaming subscriber: ctx->tlli_new is the local TLLI based on the P-TMSI we didn't assign ctx->tlli is the foreign TLLI based on this P-TMSI. In that case tlli_new will never be used in the traffic, e.g. we would assig a new P-TMSI based on the GPRS Attach. Given how much/little I understand right now.. the tlli_new will not be used by us or the phone during the attachment procedure. > LLGMM-ASSIGN.req (7.2.1.1 of 04.64): > The TLLI Old and TLLI New parameters shall be interpreted as follows: > If TLLI Old = all 1's and TLLI New ? all 1's then TLLI New shall be > assigned and used when (re-)transmitting LLC frames. If a TLLI Old ? > all 1's was assigned to the LLME, then TLLI Old is unassigned. Only > TLLI New shall be accepted when received from the peer. It shall be > treated as a TLLI change according to subclause 8.3.2. > > This would mean that the tlli_old (which is stored in the LLME up to the > call to your proposed "gprs_llgmm_assign(ctx->llme, 0xffffffff, ctx->tlli") > would no longer be accepted on the Rx side. So I assume that: llme->old_tlli = 0xff...; llme->tlli = a foreign TLLI; gprs_llgmm_assign(llme, 0xff.., llme->tlli); this would be the "TLLI Assignment 8.3.1" case? It would also reset all the lle's. > So I still think that at least _this_ part of the existing code is doing > it right. Okay, it is certainly not a bug and might even be correct. So there is no point in changing this code. From bnt2025 at googlemail.com Wed Jul 31 22:26:32 2013 From: bnt2025 at googlemail.com (Ash Gibbons) Date: Wed, 31 Jul 2013 23:26:32 +0100 Subject: Adding SDR Drivers Message-ID: Hello, I am wonder how to add support for other Transceivers, in particular the BladeRF ( http://nuand.com/ ). If anyone has a start point for me to learn how to do this, it would be fantastic! Many thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: