From laforge at gnumonks.org Tue Jun 1 06:03:19 2010 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 1 Jun 2010 08:03:19 +0200 Subject: GPRS/SGSN progress update Message-ID: <20100601060319.GK25919@prithivi.gnumonks.org> Hi all, I've been working on the SGSN code again for two days, and there is quite a bit of progress, even if it doesn't really make much difference in what you can do. I'm still working on the signalling plane, an we still cannot send/receive user plane packets (the actual TCP/IP). However, a number of bugs / misunderstandings have been fixed: 1) When we send BSSGP Downlink-Unitdata, we have to always include the IMSI of the target phone, as well as the "MS Radio Access Capabilities" IE. This is apparently needed for the BTS to know when and how it can schedule packets to be sent on the radio interface. However, I personally think it's an ugly layering violation. All this information is part of the "GMM State" in the SGSN, i.e. higher than layer3. It now needs to be passed through LLC down into BSSGP, where it is used :( 2) LLC UI Frames have sequence numbers that need to be incremented with every frame. 3) Some phones apparently don't like it if they don't get a P-TMSI allocated during GPRS ATTACH and ROUTEING AREA UPDATE. According to the spec, it's optional and I thought I could skip that feature to make things easier initially. 4) There are two levels of C/R (Command/Response) bits, one at the LLC and the other at the BSSGP layer. The LLC bit is now set correctly, but the BSSGP C/R packet seems to be set even wrong by the BTS. However, I'm now simulating the behaviour of exissting Gb protocol traces 5) The 04.08 GMM timers T3350 and T3370 have been implemented properly, including re-transmissions of the according MM frames 6) As part of P-TMSI Reallocation, there are time windows when the SGSN has to consider both the old and the newly allocated P-TMSI are valid simultaneously Finally, I've found one other bug that I'm about to fix now: When we assign a new P-TMSI, this implicitly means that the TLLI will change, too. Since the TLLI changes, the LLC protocol created a new "LL Entity" data structure and re-started the sequence number at 0, resulting in all messages being dropped in the phone until the sequence number is higher than the previous one. I have some hope that this is the last bug before I can see packets on the data plane coming out the TUN device on OpenGGSN. After that, there are still the following major TODOs: * actually check the HLR rather than accepting every IMSI * implement BSSGP flow control for BVC and MS level * implement SNDCP fragmentation/reassembly Followed by more optional features, such as * implement SNDCP header compression * implement SNDCP payload compression * implement LLC re-transmissions * implement GEA3 encryption Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: Digital signature URL: From laforge at gnumonks.org Thu Jun 3 19:40:30 2010 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 3 Jun 2010 21:40:30 +0200 Subject: GPRS/SGSN progress update In-Reply-To: <20100601060319.GK25919@prithivi.gnumonks.org> References: <20100601060319.GK25919@prithivi.gnumonks.org> Message-ID: <20100603194030.GO17351@prithivi.gnumonks.org> Hi again, this is an incremental update to the one released two days ago. I've now just established the first couple of HTTP connections from a Android G1 phone through a self-hosted combination of nanoBTS, OpenBSC, OsmoSGSN and OpenGGSN. The setup is still very flaky and I'm hunting down some crashes of OsmoSGSN, we also still take shortcuts everywhere in the spec and e.g. only implement SNDCP fragmentation on the downlink and no fragment re-assembly on the uplink. But we're slowly getting there. I hope this work will be completed and stabilize through the next couple of weeks. Also, the performance is probably really bad, there are many linear list searches and lookups at the inter-layer transitions of the GPRS protocol stack. But I have lots of ideas how to simplify this by introducing direct pointer references (as opposed to lookup-by-identifier) between the various state structures of each respective layer. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From 246tnt at gmail.com Thu Jun 10 07:47:08 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Thu, 10 Jun 2010 09:47:08 +0200 Subject: GPRS/SGSN progress update In-Reply-To: <20100603194030.GO17351@prithivi.gnumonks.org> References: <20100601060319.GK25919@prithivi.gnumonks.org> <20100603194030.GO17351@prithivi.gnumonks.org> Message-ID: Hi, I tried the gprs yesterday, and in the end, it worked quite well albeit slow (but that's GPRS I guess :p) I had to fix a couple of crashes (both of SGSN and of the BTS, the latter being due to malformed packets) and the fixes are in my sylvain/pending branch. Also, a couple of 'gotcha' I hit for future reference: - Even if running on the same machine, the SGSN & GGSN GTP interfaces need to have different IPs or they'll try to bind to the same ports and fail. - Using 'TCH/F_PDCH' channel config doesn't work (that's what I used with the old gprs branch a long time ago). You need to use 'PDCH' Finally a list of the IPs in the configuration and what they mean (I stumbled a little when trying to setup all those :): ----- In openbsc.cfg: gprs nsvc 0 local udp port 23000 gprs nsvc 0 remote udp port 23000 gprs nsvc 0 remote ip A.B.C.D A.B.C.D -> This is the IPs of the SGSN that will be sent to the BTS (and the BTS will try to connect to it obviously ...) In osmo_sgsn.cfg: gtp local-ip A.B.C.D ggsn 0 remote-ip W.X.Y.Z A.B.C.D -> This is the local ip of the SGSN where the GTP link (between GGSN & SGSN) will be bound to. W.X.Y.Z -> This is the ip of the GGSN for the GTP link. As I mentionned earlier, even if both SGSN & GGSN are running on the same machine, they need to be different (using ip aliases or whatever) encapsulation udp local-ip A.B.C.D encapsulation udp local-port 23000 A.B.C.D -> This is the ip/port the BTS will connect to. Must obviously match the 'gprs nsvc 0 remote' config in openbsc.cfg In ggsn.conf: listen A.B.C.D A.B.C.D -> This is the local IP for the GTP link of the GGSN. Must match the 'ggsn 0 remote-ip' of osmo_sgsn.cfg ----- Sylvain From laforge at gnumonks.org Thu Jun 10 12:34:03 2010 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 10 Jun 2010 14:34:03 +0200 Subject: GPRS/SGSN progress update In-Reply-To: References: <20100601060319.GK25919@prithivi.gnumonks.org> <20100603194030.GO17351@prithivi.gnumonks.org> Message-ID: <20100610123403.GE19751@prithivi.gnumonks.org> Hi Sylvain, thanks for reproducing the GPRS setup, it is always useful to know it works for other people, too. On Thu, Jun 10, 2010 at 09:47:08AM +0200, Sylvain Munaut wrote: > I tried the gprs yesterday, and in the end, it worked quite well > albeit slow (but that's GPRS I guess :p) You can cofigure multiple timeslots as PDCH. It will work transparently as the load distribution is done by the BTS alone. I'm happy (though surprised) it worked for you fine. The biggest problems at the moment are * no defragmentation of fragmented SNDCP PDU's in the MS->network direction * lack of BSSGP flow control (implementing it right now) > I had to fix a couple of crashes (both of SGSN and of the BTS, the > latter being due to malformed packets) and the fixes are in my > sylvain/pending branch. I'm happy to look at them. > Also, a couple of 'gotcha' I hit for future reference: > - Even if running on the same machine, the SGSN & GGSN GTP interfaces > need to have different IPs or they'll try to bind to the same ports > and fail. Yes, that is almost expected. We could add config options to bind to non-standard ports to fix this - but at the cost of having to manually click 'decode as...' every time in wireshark. > - Using 'TCH/F_PDCH' channel config doesn't work (that's what I used > with the old gprs branch a long time ago). You need to use 'PDCH' This is true and known. a TCH/F_PDCH combination will need an explicit ip.access proprietary RSL "PDCH ACTIVATE" message, and although I have written some code for dynamic PDCH/TCH_F allocation in OpenBSC, this has never been tested (and i believe it's out of the master branch). > Finally a list of the IPs in the configuration and what they mean (I > stumbled a little when trying to setup all those :): It would be great if you could work on an article on the wiki how to set this up. The configuration/vty commands should be stable and I don't expect this to change anymore. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From 246tnt at gmail.com Thu Jun 10 22:54:36 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 11 Jun 2010 00:54:36 +0200 Subject: GPRS/SGSN progress update In-Reply-To: <20100610123403.GE19751@prithivi.gnumonks.org> References: <20100601060319.GK25919@prithivi.gnumonks.org> <20100603194030.GO17351@prithivi.gnumonks.org> <20100610123403.GE19751@prithivi.gnumonks.org> Message-ID: Hi, > I'm happy (though surprised) it worked for you fine. Yup I was too to see that now it actually _worked_. Last time I tried it was still the separate gprs branch. A quick speed test gives a breathtaking 4.3 ko/s :) Here are a few weird message I still get from time to time on the nanoBTS telnet interface: --- 13113:DBG:RM:dlTbfUtilsTerminateExtendedUlTbf() 9:DBG:RM:dlTbfUtilsTerminateExtendedUlTbf() --- And some on sgsn process as well (no relation with the telnet ones): --- <0016> gprs_bssgp.c:349 BSSGP TLLI=0xcedb4983 Rx UL-UD missing mandatory IE <0016> gprs_bssgp_util.c:105 BSSGP BVCI=0 Tx STATUS, cause=Missing mandatory IE --- > It would be great if you could work on an article on the wiki how to > set this up. ?The configuration/vty commands should be stable and I > don't expect this to change anymore. Ok, done at http://openbsc.osmocom.org/trac/wiki/OpenBSC_GPRS Cheers, Sylvain From holger at freyther.de Fri Jun 11 00:59:59 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Fri, 11 Jun 2010 08:59:59 +0800 Subject: GPRS/SGSN progress update In-Reply-To: References: <20100601060319.GK25919@prithivi.gnumonks.org> <20100603194030.GO17351@prithivi.gnumonks.org> <20100610123403.GE19751@prithivi.gnumonks.org> Message-ID: <4C118A8F.4020407@freyther.de> On 06/11/2010 06:54 AM, Sylvain Munaut wrote: > Hi, > > --- > 13113:DBG:RM:dlTbfUtilsTerminateExtendedUlTbf() > 9:DBG:RM:dlTbfUtilsTerminateExtendedUlTbf() > What did you enable on the telnet interface? From 246tnt at gmail.com Fri Jun 11 06:20:35 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 11 Jun 2010 08:20:35 +0200 Subject: GPRS/SGSN progress update In-Reply-To: <4C118A8F.4020407@freyther.de> References: <20100601060319.GK25919@prithivi.gnumonks.org> <20100603194030.GO17351@prithivi.gnumonks.org> <20100610123403.GE19751@prithivi.gnumonks.org> <4C118A8F.4020407@freyther.de> Message-ID: > What did you enable on the telnet interface? dbgcontrol on From laforge at gnumonks.org Fri Jun 11 12:18:00 2010 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 11 Jun 2010 14:18:00 +0200 Subject: GPRS/SGSN progress update In-Reply-To: References: <20100601060319.GK25919@prithivi.gnumonks.org> <20100603194030.GO17351@prithivi.gnumonks.org> <20100610123403.GE19751@prithivi.gnumonks.org> Message-ID: <20100611121800.GG3680@prithivi.gnumonks.org> Hi Sylvain, On Fri, Jun 11, 2010 at 12:54:36AM +0200, Sylvain Munaut wrote: > Here are a few weird message I still get from time to time on the > nanoBTS telnet interface: > > --- > 13113:DBG:RM:dlTbfUtilsTerminateExtendedUlTbf() > 9:DBG:RM:dlTbfUtilsTerminateExtendedUlTbf() This definitely relates to TBF (temporary block flow), a concept on the air interface. So I'm not quite sure how the Gb interface (SGSN side) would have any direct contact with TBF's. > And some on sgsn process as well (no relation with the telnet ones): > > --- > <0016> gprs_bssgp.c:349 BSSGP TLLI=0xcedb4983 Rx UL-UD missing mandatory IE > <0016> gprs_bssgp_util.c:105 BSSGP BVCI=0 Tx STATUS, cause=Missing mandatory IE Ok, we should probably print which IE we think is missing, or even better, we should add some functionality that can put such supposedly-erroneous packets in a pcap file. Once we have a simple function that can be called for this, we can use it all over the code. > Ok, done at http://openbsc.osmocom.org/trac/wiki/OpenBSC_GPRS Thanks. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From jmercury313 at gmail.com Wed Jun 2 14:36:50 2010 From: jmercury313 at gmail.com (jason mercury) Date: Wed, 2 Jun 2010 17:36:50 +0300 Subject: IMEI collection problem and virtual power Message-ID: Hi to all, I have problem with collecting imei numbers of cellphones which try to register to the nanoBTS. All imsi numbers of subscribers are saved in Subscriber table but only very small number of imei numbers are stored. What do you thin about this? Could you offer any solution. Moreover, I want to ask something about virtual power. Is there virtual power property (for example my actual power is tx 100mW but MS feels that it is 10W). If we have how can I use it? Thanks. Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: From zecke at selfish.org Wed Jun 2 15:11:41 2010 From: zecke at selfish.org (Holger Freyther) Date: Wed, 02 Jun 2010 23:11:41 +0800 Subject: IMEI collection problem and virtual power In-Reply-To: References: Message-ID: <4C0674AD.7020500@selfish.org> On 06/02/2010 10:36 PM, jason mercury wrote: > Hi to all, > > I have problem with collecting imei numbers of cellphones which try to > register to the nanoBTS. All imsi numbers of subscribers are saved in > Subscriber table but only very small number of imei numbers are stored. > What do you thin about this? Could you offer any solution. The imei+software version (imeisw) should be requested during a location updating request, the first thing you could do is to use wireshark and check if you see identity requests for the imei, and also if you see the identity response for it. z. From jmercury313 at gmail.com Thu Jun 3 11:59:17 2010 From: jmercury313 at gmail.com (jason mercury) Date: Thu, 3 Jun 2010 14:59:17 +0300 Subject: nanoBTS specs Message-ID: Hi to all, I want to learn max. Rx input power of nanoBTS. Does anybody know about it or have datasheet of nanoBTS?(Both 900 and 1800) Thanks. Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Thu Jun 3 16:32:21 2010 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 3 Jun 2010 18:32:21 +0200 Subject: OpenBTS OML sequencing / startup problems Message-ID: <20100603163221.GJ17351@prithivi.gnumonks.org> Hi zecke, one of the things that I've been thinking about earlier today while talking with Roch was the fact that we do the A-bis OML overlapping / asynchronously, i.e. if we send a 'set attribute ...' or 'opstart' message, we never wait for the acknowledgement before sending the next message. While this might be efficient and compliant with the specification, it is likely to expose bugs like race conditions in software that has never been tested against it. So one of the ideas would be to make the abis_nm.c layer queue up messages during abis_nm_sendmsg() and determine based on the messagetype if it is a message that we're expecting an ACK/NACK as response. If yes, delay transmission of further enqueued OML messages until such ACK/NACK is received. Of course, there probably should also be a timer whose expiration should generate at least a log file entry (and after which we continue with the next message from the queue) I'm not sure if you feel in the mood for implementing something like this or not. I can also stop with GPRS work and have a look at it. This request/response tracking would probably also be useful once we extend our ability to send OML messages from e.g. external applications. We could then notice who submitted the message and deliver the result back to the caller without having to consider re-ordering or something like that. Regards, Harlad -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From zecke at selfish.org Fri Jun 4 11:33:11 2010 From: zecke at selfish.org (Holger Freyther) Date: Fri, 04 Jun 2010 19:33:11 +0800 Subject: OpenBTS OML sequencing / startup problems In-Reply-To: <20100603163221.GJ17351@prithivi.gnumonks.org> References: <20100603163221.GJ17351@prithivi.gnumonks.org> Message-ID: <4C08E477.1020806@selfish.org> On 06/04/2010 12:32 AM, Harald Welte wrote: > Hi zecke, > So one of the ideas would be to make the abis_nm.c layer queue up messages > during abis_nm_sendmsg() and determine based on the messagetype if it is > a message that we're expecting an ACK/NACK as response. If yes, delay > transmission of further enqueued OML messages until such ACK/NACK is > received. Of course, there probably should also be a timer whose expiration > should generate at least a log file entry (and after which we continue with > the next message from the queue) Hi, interesting thought... I think the request/response tracking is a good idea and fairly easy to implement with only one pending message and we will certainly need it... and in one way it feels natural to use it in the abis_nm layer as well in another way it feels weird to have submitted two messages of the same kind and the bsc_init should not do it. I can put it on my list, I was a bit busy with private stuff and will probably have a computer-less weekend but I can commit to do it early next week. From bertoncello at netzing.de Fri Jun 4 09:37:22 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Fri, 4 Jun 2010 11:37:22 +0200 Subject: Setting the power of a BTS Message-ID: <20100604113722.12ba9492@debian503.nsag> Hi, List! I'm new to OpenBSC, and I'm experimenting some configuration of the program. Now I have to try to change the power of the BaseStation, so that I can set how far mobile phones can catch the signal of my BaseStation. I thought, I can change the values of "ms max power" or "nominal power", but I don't see any difference. Is it possible to do what I try? If yes, how? Thanks for any help! -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at netzing.de NETZING Solutions AG Tel.: 0351/41381 - 0 Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12 HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag at netzing.de _______________________________________________________________________ From bouchtaoui at gmail.com Fri Jun 4 10:13:39 2010 From: bouchtaoui at gmail.com (Nordin) Date: Fri, 04 Jun 2010 12:13:39 +0200 Subject: Setting the power of a BTS In-Reply-To: <20100604113722.12ba9492@debian503.nsag> References: <20100604113722.12ba9492@debian503.nsag> Message-ID: <4C08D1D3.7030204@gmail.com> Hello Luca, in the config file, set "max_power_red 0' This means the amount to reduce the power is 0 (which means it's the max power). So if you want to attenuate the power, you have to raise the value e.g. 12. By the way, I assume you're using nanobts. Greetings, Nordin. On 4-6-2010 11:37, Luca Bertoncello wrote: > Hi, List! > > I'm new to OpenBSC, and I'm experimenting some configuration of the > program. > Now I have to try to change the power of the BaseStation, so that I can > set how far mobile phones can catch the signal of my BaseStation. > > I thought, I can change the values of "ms max power" or "nominal > power", but I don't see any difference. > > Is it possible to do what I try? If yes, how? > > Thanks for any help! > From bertoncello at netzing.de Fri Jun 4 12:42:35 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Fri, 4 Jun 2010 14:42:35 +0200 Subject: Setting the power of a BTS In-Reply-To: <4C08D1D3.7030204@gmail.com> References: <20100604113722.12ba9492@debian503.nsag> <4C08D1D3.7030204@gmail.com> Message-ID: <20100604144235.503a7c5a@debian503.nsag> Am Fri, 04 Jun 2010 12:13:39 +0200 schrieb Nordin : > in the config file, set "max_power_red 0' > This means the amount to reduce the power is 0 (which means it's the > max power). So if you want to attenuate the power, you have to raise > the value e.g. 12. > By the way, I assume you're using nanobts. Hi, Nordin! Thanks for your answer. I read the documentation again, and I have another question. Does the value of max_power_red works together with "nominal power"? I tried to set "nominal power" to 100 and max_power_red to 0, and then to increase max_power_red. I don't see any difference if I search the net with my phone... What am I doing wrong? Thanks -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at netzing.de NETZING Solutions AG Tel.: 0351/41381 - 0 Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12 HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag at netzing.de _______________________________________________________________________ From bouchtaoui at gmail.com Fri Jun 4 13:03:16 2010 From: bouchtaoui at gmail.com (Nordin) Date: Fri, 04 Jun 2010 15:03:16 +0200 Subject: Setting the power of a BTS In-Reply-To: <20100604144235.503a7c5a@debian503.nsag> References: <20100604113722.12ba9492@debian503.nsag> <4C08D1D3.7030204@gmail.com> <20100604144235.503a7c5a@debian503.nsag> Message-ID: <4C08F994.6020109@gmail.com> According to OpenBSC wiki: "How many dBm is the nominal power of this BTS. This setting is only used as a base for computing power levels displayed to the user. " So this one is just to calculate the powervalue to be displayed for you, so I assume it does nothing more than that. But how do you test by the way? On 4-6-2010 14:42, Luca Bertoncello wrote: > Am Fri, 04 Jun 2010 12:13:39 +0200 > schrieb Nordin: > > >> in the config file, set "max_power_red 0' >> This means the amount to reduce the power is 0 (which means it's the >> max power). So if you want to attenuate the power, you have to raise >> the value e.g. 12. >> By the way, I assume you're using nanobts. >> > Hi, Nordin! > > Thanks for your answer. > > I read the documentation again, and I have another question. Does the > value of max_power_red works together with "nominal power"? > > I tried to set "nominal power" to 100 and max_power_red to 0, and then > to increase max_power_red. > I don't see any difference if I search the net with my phone... > > What am I doing wrong? > > Thanks > From bertoncello at netzing.de Fri Jun 4 13:10:44 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Fri, 4 Jun 2010 15:10:44 +0200 Subject: Setting the power of a BTS In-Reply-To: <4C08F994.6020109@gmail.com> References: <20100604113722.12ba9492@debian503.nsag> <4C08D1D3.7030204@gmail.com> <20100604144235.503a7c5a@debian503.nsag> <4C08F994.6020109@gmail.com> Message-ID: <20100604151044.7aaa1c81@debian503.nsag> Am Fri, 04 Jun 2010 15:03:16 +0200 schrieb Nordin : > According to OpenBSC wiki: > "How many dBm is the nominal power of this BTS. This setting is only > used as a base for computing power levels displayed to the user. " > So this one is just to calculate the powervalue to be displayed for > you, so I assume it does nothing more than that. > > But how do you test by the way? It's difficult to explain, but I just want to restrict (or enlarge) the field in which is my BaseStation to find. Is it possible? Thanks -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at netzing.de NETZING Solutions AG Tel.: 0351/41381 - 0 Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12 HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag at netzing.de _______________________________________________________________________ From bouchtaoui at gmail.com Fri Jun 4 14:00:36 2010 From: bouchtaoui at gmail.com (Nordin) Date: Fri, 04 Jun 2010 16:00:36 +0200 Subject: Setting the power of a BTS In-Reply-To: <20100604151044.7aaa1c81@debian503.nsag> References: <20100604113722.12ba9492@debian503.nsag> <4C08D1D3.7030204@gmail.com> <20100604144235.503a7c5a@debian503.nsag> <4C08F994.6020109@gmail.com> <20100604151044.7aaa1c81@debian503.nsag> Message-ID: <4C090704.1090001@gmail.com> On 4-6-2010 15:10, Luca Bertoncello wrote: > Am Fri, 04 Jun 2010 15:03:16 +0200 > schrieb Nordin: > > >> According to OpenBSC wiki: >> "How many dBm is the nominal power of this BTS. This setting is only >> used as a base for computing power levels displayed to the user. " >> So this one is just to calculate the powervalue to be displayed for >> you, so I assume it does nothing more than that. >> >> But how do you test by the way? >> > It's difficult to explain, but I just want to restrict (or enlarge) the > field in which is my BaseStation to find. > > Is it possible? > Sorry, still don't know what you mean. > Thanks > From cleb at defcon-3.net Fri Jun 4 14:14:41 2010 From: cleb at defcon-3.net (Caleb Pal) Date: Fri, 4 Jun 2010 14:14:41 +0000 Subject: Setting the power of a BTS In-Reply-To: <4C090704.1090001@gmail.com> References: <20100604113722.12ba9492@debian503.nsag> <4C08D1D3.7030204@gmail.com> <20100604144235.503a7c5a@debian503.nsag> <4C08F994.6020109@gmail.com><20100604151044.7aaa1c81@debian503.nsag><4C090704.1090001@gmail.com> Message-ID: <1728995980-1275660881-cardhu_decombobulator_blackberry.rim.net-758705618-@bda772.bisx.prod.on.blackberry> I believe he wants to limit the range of his bts by decreasing the downlink power. Regards Caleb Sent from my Verizon Wireless BlackBerry -----Original Message----- From: Nordin Date: Fri, 04 Jun 2010 16:00:36 To: Subject: Re: Setting the power of a BTS On 4-6-2010 15:10, Luca Bertoncello wrote: > Am Fri, 04 Jun 2010 15:03:16 +0200 > schrieb Nordin: > > >> According to OpenBSC wiki: >> "How many dBm is the nominal power of this BTS. This setting is only >> used as a base for computing power levels displayed to the user. " >> So this one is just to calculate the powervalue to be displayed for >> you, so I assume it does nothing more than that. >> >> But how do you test by the way? >> > It's difficult to explain, but I just want to restrict (or enlarge) the > field in which is my BaseStation to find. > > Is it possible? > Sorry, still don't know what you mean. > Thanks > From risky at mail.ru Fri Jun 4 14:18:04 2010 From: risky at mail.ru (Sergey V. Efimoff) Date: Fri, 4 Jun 2010 18:18:04 +0400 Subject: Setting the power of a BTS In-Reply-To: <4C090704.1090001@gmail.com> References: <20100604113722.12ba9492@debian503.nsag> <4C08D1D3.7030204@gmail.com> <20100604144235.503a7c5a@debian503.nsag> <4C08F994.6020109@gmail.com> <20100604151044.7aaa1c81@debian503.nsag> <4C090704.1090001@gmail.com> Message-ID: <3E5E6B6C-2E2F-436D-9A26-FF05B8C1359C@mail.ru> As far as I understand, he means that he wants to control BTS cover area. On Jun 4, 2010, at 6:00 PM, Nordin wrote: > On 4-6-2010 15:10, Luca Bertoncello wrote: >> Am Fri, 04 Jun 2010 15:03:16 +0200 >> schrieb Nordin: >> >> >>> According to OpenBSC wiki: >>> "How many dBm is the nominal power of this BTS. This setting is only >>> used as a base for computing power levels displayed to the user. " >>> So this one is just to calculate the powervalue to be displayed for >>> you, so I assume it does nothing more than that. >>> >>> But how do you test by the way? >>> >> It's difficult to explain, but I just want to restrict (or enlarge) the >> field in which is my BaseStation to find. >> >> Is it possible? >> > > Sorry, still don't know what you mean. > >> Thanks >> > > From bouchtaoui at gmail.com Fri Jun 4 14:35:48 2010 From: bouchtaoui at gmail.com (Nordin) Date: Fri, 04 Jun 2010 16:35:48 +0200 Subject: Setting the power of a BTS In-Reply-To: <3E5E6B6C-2E2F-436D-9A26-FF05B8C1359C@mail.ru> References: <20100604113722.12ba9492@debian503.nsag> <4C08D1D3.7030204@gmail.com> <20100604144235.503a7c5a@debian503.nsag> <4C08F994.6020109@gmail.com> <20100604151044.7aaa1c81@debian503.nsag> <4C090704.1090001@gmail.com> <3E5E6B6C-2E2F-436D-9A26-FF05B8C1359C@mail.ru> Message-ID: <4C090F44.7000601@gmail.com> Ok, but to my knowledge the only way to do that is by modifying the "max_power_red" in the config file or through VTY terminal. You should use a dummy load with your BTS, this limits the range within a meter, so you don't get trouble with the government ;-) Or use farada's cage or something... On 4-6-2010 16:18, Sergey V. Efimoff wrote: > As far as I understand, he means that he wants to control BTS cover area. > > On Jun 4, 2010, at 6:00 PM, Nordin wrote: > > >> On 4-6-2010 15:10, Luca Bertoncello wrote: >> >>> Am Fri, 04 Jun 2010 15:03:16 +0200 >>> schrieb Nordin: >>> >>> >>> >>>> According to OpenBSC wiki: >>>> "How many dBm is the nominal power of this BTS. This setting is only >>>> used as a base for computing power levels displayed to the user. " >>>> So this one is just to calculate the powervalue to be displayed for >>>> you, so I assume it does nothing more than that. >>>> >>>> But how do you test by the way? >>>> >>>> >>> It's difficult to explain, but I just want to restrict (or enlarge) the >>> field in which is my BaseStation to find. >>> >>> Is it possible? >>> >>> >> Sorry, still don't know what you mean. >> >> >>> Thanks >>> >>> >> >> > > From stuart at bluewave.im Fri Jun 4 15:28:51 2010 From: stuart at bluewave.im (Stuart Baggs) Date: Fri, 4 Jun 2010 16:28:51 +0100 Subject: Setting the power of a BTS In-Reply-To: <3E5E6B6C-2E2F-436D-9A26-FF05B8C1359C@mail.ru> References: <20100604113722.12ba9492@debian503.nsag> <4C08D1D3.7030204@gmail.com> <20100604144235.503a7c5a@debian503.nsag> <4C08F994.6020109@gmail.com> <20100604151044.7aaa1c81@debian503.nsag> <4C090704.1090001@gmail.com> <3E5E6B6C-2E2F-436D-9A26-FF05B8C1359C@mail.ru> Message-ID: <07DFA102-9DD8-472C-AD7A-29AD6CD6C1AF@bluewave.im> The only two ways to control a cells coverage area is to set the subscriber max distance attribute or reduce the BTS / MS TX power. On 4 Jun 2010, at 15:18, Sergey V. Efimoff wrote: > As far as I understand, he means that he wants to control BTS cover area. > > On Jun 4, 2010, at 6:00 PM, Nordin wrote: > >> On 4-6-2010 15:10, Luca Bertoncello wrote: >>> Am Fri, 04 Jun 2010 15:03:16 +0200 >>> schrieb Nordin: >>> >>> >>>> According to OpenBSC wiki: >>>> "How many dBm is the nominal power of this BTS. This setting is only >>>> used as a base for computing power levels displayed to the user. " >>>> So this one is just to calculate the powervalue to be displayed for >>>> you, so I assume it does nothing more than that. >>>> >>>> But how do you test by the way? >>>> >>> It's difficult to explain, but I just want to restrict (or enlarge) the >>> field in which is my BaseStation to find. >>> >>> Is it possible? >>> >> >> Sorry, still don't know what you mean. >> >>> Thanks >>> >> >> > > > From stuart at bluewave.im Fri Jun 4 14:08:00 2010 From: stuart at bluewave.im (Stuart Baggs) Date: Fri, 4 Jun 2010 15:08:00 +0100 Subject: Setting the power of a BTS In-Reply-To: <20100604151044.7aaa1c81@debian503.nsag> References: <20100604113722.12ba9492@debian503.nsag> <4C08D1D3.7030204@gmail.com> <20100604144235.503a7c5a@debian503.nsag> <4C08F994.6020109@gmail.com> <20100604151044.7aaa1c81@debian503.nsag> Message-ID: <66498BCE-3194-477F-BD9C-E6F3DF28E762@bluewave.im> Sorry for the short reply, I'm on my mobile. There are two elements that govern how far your network will work. In a standard deployment of a nanoBTS, this will always be the EIRP of the BTS. On a macro network it's usually down to the subscribers maximum EIRP (30dBM at GSM 1800). There's various other factors such as receive diversity (both polarity and spatial which I won't discuss here). The setting you need to change is the max power reduction of each TRX. By setting this to 0, you will be TXing at 23dBm (200mw) on an 1800 nanoBTS. Best Regards Stuart Baggs Managing Director BlueWave Communications Ltd Sent from my iPhone On 4 Jun 2010, at 14:10, Luca Bertoncello wrote: > Am Fri, 04 Jun 2010 15:03:16 +0200 > schrieb Nordin : > >> According to OpenBSC wiki: >> "How many dBm is the nominal power of this BTS. This setting is only >> used as a base for computing power levels displayed to the user. " >> So this one is just to calculate the powervalue to be displayed for >> you, so I assume it does nothing more than that. >> >> But how do you test by the way? > > It's difficult to explain, but I just want to restrict (or enlarge) > the > field in which is my BaseStation to find. > > Is it possible? > > Thanks > -- > _______________________________________________________________________ > Luca Bertoncello > Entwicklung Mail: > bertoncello at netzing.de > > > NETZING Solutions AG Tel.: 0351/41381 - 0 > Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12 > HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag at netzing.de > _______________________________________________________________________ > > From laforge at gnumonks.org Sat Jun 5 17:10:09 2010 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 5 Jun 2010 19:10:09 +0200 Subject: Future of the HLR Message-ID: <20100605171009.GA30598@prithivi.gnumonks.org> Hi all! One of the issues I want to adress in the coming weeks is the HLR. At the moment, we don't have an HLR in the traditional GSM sense. We have something that corresponds to the same function, but without all of the usual interfaces. This is not a problem in itself, as we do not intend to interwork the internal-MSC of the OpenBSC with a traditional HLR at this point. The current implemnetation just synchronously calls subscriber_get(), which does a database lookup. It expects this lookup to succeed synchronously, which is only true as long as nobody else is accessing the hlr.sqlite3 database simultaneously. This is problem 'A'. Simultaneous accesses to the database could either be manual updates, or the 'hlrsync.pl' script, or some other kind of user interface to the database. The problem gets worse if we now start to have a SGSN. The SGSN currently does not access hlr.sqlite3. But if I start to implement it, we will have concurrent accesses from bsc_hack and osmo-sgsn to the sqlite3 database, which means that problem 'A' will become worse. So what needs to be done: 1) Accesses like subscriber_get() need to become asynchronous, i.e. at the time we search for a subscriber we simply issue a call and do some state transition. Once the database process is finished retrieving the subscriber data, we can continue the operation. 2) Introduce an actual message-based protocol between the HLR database process and the OpenBSC and OsmoSGSN software. Both of those fit together quite nicely. And rather than inventing our own protocol, we should directly use the GSM MAP (09.02) messages intended for the respective operations. That might sound complex, but we can leave out the other parts of SS7 (MTP, SCCP, TCAP) for now. But if we already start to encode the information elements and messages themselves according to MAP, we would have a very clear migration path towards * turning our HLR into something that can interoperate with real GSM networks * allowing our Layer3/MSC code in OpenBSC to use a real GSM HLR The MAP asn.1 code can be processed quite nicely by asn1c, thus it should be possible to integrate with our C code quite nicely. I'm right now studying TCAP and how it is being used by MAP in order to determine if (and how much of) TCAP we would need. After that is finished, I'll likely start working on a minimal HLR process (using the sqlite3 database backend) and then convert the OpenBSC code to asynchonous MAP-based subscriber lookups. 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 bouchtaoui at gmail.com Mon Jun 7 13:51:29 2010 From: bouchtaoui at gmail.com (Nordin) Date: Mon, 07 Jun 2010 15:51:29 +0200 Subject: UMTS support?? Message-ID: <4C0CF961.8070509@gmail.com> Well guys, Just being curious, are there any plans for UMTS support? I remember Harald said something about an ASN.1 PER was an obstacle to start for UMTS support. Are there also nanoBTS for UMTS, I only know of 2G devices... It was just quite on the list :p Greetz, Nordin :-) From laforge at gnumonks.org Mon Jun 7 19:21:39 2010 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 7 Jun 2010 21:21:39 +0200 Subject: UMTS support?? In-Reply-To: <4C0CF961.8070509@gmail.com> References: <4C0CF961.8070509@gmail.com> Message-ID: <20100607192139.GG27115@prithivi.gnumonks.org> On Mon, Jun 07, 2010 at 03:51:29PM +0200, Nordin wrote: > Just being curious, are there any plans for UMTS support? There are lots of plans but only 24 hours per day and very few developers. So as soon as you or anyone else starts working on it, we will be happy to merge it :) > I remember Harald said something about an ASN.1 PER was an obstacle > to start for UMTS support. ASN.1 PER makes things a bit more uncomfortable but its definitely possible nonetheless. Either by implementing those few message types by hand as hex-coded templates in C, or by using a Erlang program linked to a C process (the C interface for sending/receiving messages to/from Erlang processes is quite small and easy to use) or by adding the respective bits to asn1c. > Are there also nanoBTS for UMTS, I only know of 2G devices... > It was just quite on the list :p Well, there are various 3G femtocells out there, including Alcatel/Lucent model (using RANAP), Ubiquisys (using UMA) and ip.access/Cisco using URSL. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From bouchtaoui at gmail.com Tue Jun 8 12:32:52 2010 From: bouchtaoui at gmail.com (Nordin) Date: Tue, 08 Jun 2010 14:32:52 +0200 Subject: UMTS support?? In-Reply-To: <20100607192139.GG27115@prithivi.gnumonks.org> References: <4C0CF961.8070509@gmail.com> <20100607192139.GG27115@prithivi.gnumonks.org> Message-ID: <4C0E3874.2030700@gmail.com> Ok guys, Does anyone has a Node B <---> RNC trace to analize it in Wireshark? Especially for an ipaccess BTS (or Node B) as there's a good chance to purchase one. I saw one I'm interested in that has a productnr: 206 A from ipaccess. If someone already played with such device can provide me a pcap trace, I'll study it and can give a try to kickstart UMTS support :p Peace. From laforge at gnumonks.org Wed Jun 9 06:18:16 2010 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 9 Jun 2010 08:18:16 +0200 Subject: UMTS support?? In-Reply-To: <4C0E3874.2030700@gmail.com> References: <4C0CF961.8070509@gmail.com> <20100607192139.GG27115@prithivi.gnumonks.org> <4C0E3874.2030700@gmail.com> Message-ID: <20100609061816.GJ4173@prithivi.gnumonks.org> On Tue, Jun 08, 2010 at 02:32:52PM +0200, Nordin wrote: > If someone already played with such device can provide me a pcap > trace, I'll study it and can give a try to kickstart UMTS support > :p You can look at the USRL dissector that is part of the wireshark sources that ip.access had to release under GPL. You can find it at http://ftp.gpl-devices.org/pub/vendors/ipaccess/wireshark/ -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From milos.prodanovic at gmail.com Wed Jun 9 18:35:16 2010 From: milos.prodanovic at gmail.com (Milos Prodanovic) Date: Wed, 9 Jun 2010 20:35:16 +0200 Subject: UMTS support?? In-Reply-To: <4C0CF961.8070509@gmail.com> References: <4C0CF961.8070509@gmail.com> Message-ID: I have some experience with ASN.1 coding/decoding, but not with PER, and I have no experience with any 3gpp or mobile documents or standards. I'm interested to look at ASN.1 PER encoding in spare time, if someone can point me to documents that explain where ASN.1 is used (the purpose), and to point me to documents that holds ASN.1 syntax needed for this purpose. On Mon, Jun 7, 2010 at 3:51 PM, Nordin wrote: > Well guys, > > Just being curious, are there any plans for UMTS support? > I remember Harald said something about an ASN.1 PER was an obstacle to > start for UMTS support. > Are there also nanoBTS for UMTS, I only know of 2G devices... > It was just quite on the list :p > > Greetz, > > Nordin :-) > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bouchtaoui at gmail.com Thu Jun 10 10:42:00 2010 From: bouchtaoui at gmail.com (Nordin) Date: Thu, 10 Jun 2010 12:42:00 +0200 Subject: UMTS support?? In-Reply-To: References: <4C0CF961.8070509@gmail.com> Message-ID: <4C10C178.5030008@gmail.com> On 9-6-2010 20:35, Milos Prodanovic wrote: > I have some experience with ASN.1 coding/decoding, but not with PER, and I > have no experience with any 3gpp or mobile documents or standards. > > I'm interested to look at ASN.1 PER encoding in spare time, if someone can > point me to documents that explain where ASN.1 is used (the purpose), and to > point me to documents that holds ASN.1 syntax needed for this purpose. > I'm currently studying the UMTS specs to get a general understanding and focus on the Iub interface part to find the basic messages that are similar to the OML/RSL part of GSM. As far as I understand there are parts, if not all, of the messages encoded in ASN.1 PER, even unaligned as Harald already told us before. I don't know much of the details, maybe Harald can put more light on this. You might want to experiment with PER encoded messages to play with and on the wiki you can find pdfs about ASN.1 and PER. http://en.wikipedia.org/wiki/Packed_Encoding_Rules But at the moment I found these interesting docs about Iub interface, that's like the GSM's Abis interface for UMTS: http://www.3gpp.org/ftp/Specs/archive/25_series/25.430/25430-650.zip http://www.3gpp.org/ftp/Specs/archive/25_series/25.433/25433-6h0.zip (this is a huge file, almost 1000 pages!) http://www.3gpp.org/ftp/Specs/archive/25_series/25.435/25435-650.zip http://www.3gpp.org/ftp/Specs/archive/25_series/25.427/25427-680.zip As far as I understand we can divide Iub into two networklayers, one is the Radio Network Layer and the other is Transport Network Layer. According to the specs the Tansport Network Layer is based on ATM/AALx /etc.. or SCTP/IP combination, but I assume ip.access's 3G femtocell (the one I want to focus on) is just based on tcp/ip, just like the nanobts. The Radio Network Layer can be split in two parts, the Control Plane and the User Plane. The Control Plane is based on NBAP which is doing signaling for Node B, just like OML for the BTS. So I think that's an important part to start with as this part is to control the Node B to get it on the air. The other part is the User Plane and is based on Common channels and Dedicated channels, comaparable with the RSL layer. Also for those who didn't know yet, UMTS doesn't work with channels/timeslots like GSM, it works with so called cells. I don't know the details yet, but what I remember is that you have to configure each cell for a certain purpose, like DCH, PCH etc... That's what I found about the UMTS so far, if I misunderstood some things about the UMTS, don't hesitate to correct me. If someone can add more information about it in plain English, that would be great, cause all the new acronyms makes me a bit dizzy. Peace... > On Mon, Jun 7, 2010 at 3:51 PM, Nordin wrote: > > >> Well guys, >> >> Just being curious, are there any plans for UMTS support? >> I remember Harald said something about an ASN.1 PER was an obstacle to >> start for UMTS support. >> Are there also nanoBTS for UMTS, I only know of 2G devices... >> It was just quite on the list :p >> >> Greetz, >> >> Nordin :-) >> >> >> >> > From dragos.vingarzan at gmail.com Thu Jun 10 15:51:41 2010 From: dragos.vingarzan at gmail.com (Dragos Vingarzan) Date: Thu, 10 Jun 2010 17:51:41 +0200 Subject: UMTS support?? In-Reply-To: <4C10C178.5030008@gmail.com> References: <4C0CF961.8070509@gmail.com> <4C10C178.5030008@gmail.com> Message-ID: <4C110A0D.3020707@gmail.com> was also looking on the Iub specs today and my head hurts :(. For femtos the default interface would be Iuh, which from what I understand is the Home Node B adapted version of the NodeB Iub. Then you'd need a sort of Access Controller in the form of an Home Node B Gateway as the next hop, but otherwise it seems to be less of packaging hassle, or? http://www.tech-invite.com/Ti-3gpp-standards-25b.html#ts-25444 - data transport in 10 pages, CS with RTP multiplexed in UDP/IP, PS with GTP-U/UDP/IP http://www.tech-invite.com/Ti-3gpp-standards-25b.html#ts-25468 - RANAP User Adaptation - SCTP/IP http://www.tech-invite.com/Ti-3gpp-standards-25b.html#ts-25469 - Home Node B Application Part - SCTP/IP I was wondering if you looked at this too... I know that Iub would be the real deal and fortunately this femto has it too. Also probably the advantages are offset but what you loose by requiring one more box, the Home Node B Gw. Cheers, -Dragos Nordin wrote: > On 9-6-2010 20:35, Milos Prodanovic wrote: >> I have some experience with ASN.1 coding/decoding, but not with PER, >> and I >> have no experience with any 3gpp or mobile documents or standards. >> >> I'm interested to look at ASN.1 PER encoding in spare time, if >> someone can >> point me to documents that explain where ASN.1 is used (the purpose), >> and to >> point me to documents that holds ASN.1 syntax needed for this purpose. >> > > I'm currently studying the UMTS specs to get a general understanding > and focus on the Iub interface part to find the basic messages that > are similar to the OML/RSL part of GSM. As far as I understand there > are parts, if not all, of the messages encoded in ASN.1 PER, even > unaligned as Harald already told us before. I don't know much of the > details, maybe Harald can put more light on this. > > You might want to experiment with PER encoded messages to play with > and on the wiki you can find pdfs about ASN.1 and PER. > http://en.wikipedia.org/wiki/Packed_Encoding_Rules > > But at the moment I found these interesting docs about Iub interface, > that's like the GSM's Abis interface for UMTS: > http://www.3gpp.org/ftp/Specs/archive/25_series/25.430/25430-650.zip > http://www.3gpp.org/ftp/Specs/archive/25_series/25.433/25433-6h0.zip > (this is a huge file, almost 1000 pages!) > http://www.3gpp.org/ftp/Specs/archive/25_series/25.435/25435-650.zip > http://www.3gpp.org/ftp/Specs/archive/25_series/25.427/25427-680.zip > > As far as I understand we can divide Iub into two networklayers, one > is the Radio Network Layer and the other is Transport Network Layer. > According to the specs the Tansport Network Layer is based on ATM/AALx > /etc.. or SCTP/IP combination, but I assume ip.access's 3G femtocell > (the one I want to focus on) is just based on tcp/ip, just like the > nanobts. > > The Radio Network Layer can be split in two parts, the Control Plane > and the User Plane. The Control Plane is based on NBAP which is doing > signaling for Node B, just like OML for the BTS. So I think that's an > important part to start with as this part is to control the Node B to > get it on the air. > The other part is the User Plane and is based on Common channels and > Dedicated channels, comaparable with the RSL layer. > > Also for those who didn't know yet, UMTS doesn't work with > channels/timeslots like GSM, it works with so called cells. I don't > know the details yet, but what I remember is that you have to > configure each cell for a certain purpose, like DCH, PCH etc... > > That's what I found about the UMTS so far, if I misunderstood some > things about the UMTS, don't hesitate to correct me. If someone can > add more information about it in plain English, that would be great, > cause all the new acronyms makes me a bit dizzy. > > Peace... > > >> On Mon, Jun 7, 2010 at 3:51 PM, Nordin wrote: >> >> >>> Well guys, >>> >>> Just being curious, are there any plans for UMTS support? >>> I remember Harald said something about an ASN.1 PER was an obstacle to >>> start for UMTS support. >>> Are there also nanoBTS for UMTS, I only know of 2G devices... >>> It was just quite on the list :p >>> >>> Greetz, >>> >>> Nordin :-) >>> >>> >>> >>> >> > > > -- Best Regards, Dragos Vingarzan From laforge at gnumonks.org Tue Jun 8 05:48:07 2010 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 8 Jun 2010 07:48:07 +0200 Subject: Encryption branch Message-ID: <20100608054807.GJ27115@prithivi.gnumonks.org> Dear Sylvaion, I've tried my best to forward-port your 'sylvain/encryption' branch to current OpenBSC, and you can find the result in laforge/encryption. I haven't yet had time to test it, but I wouldn't be surprised to see something break, considering that your code predated the introduction of 'gsm_subscriber_connection'. Unfortunately merging the branch to master is also not really an option right now, as it is likely to cause trouble with the BSC/MSC split, as we will have to align our encryption support with how the A-Interface between BSC and MSC handles things. Nonetheless, I really would like to see this feature move ahead. There is definitely a demand for it in the research community. 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 Tue Jun 8 06:35:24 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Tue, 08 Jun 2010 14:35:24 +0800 Subject: Encryption branch In-Reply-To: <20100608054807.GJ27115@prithivi.gnumonks.org> References: <20100608054807.GJ27115@prithivi.gnumonks.org> Message-ID: <4C0DE4AC.40307@freyther.de> On 06/08/2010 01:48 PM, Harald Welte wrote: > > Unfortunately merging the branch to master is also not really an option right > now, as it is likely to cause trouble with the BSC/MSC split, as we will > have to align our encryption support with how the A-Interface between BSC > and MSC handles things. Hi, merge whatever is ready. In case I have a patch and need some days to stabilize I will ask on this list to hold stuff back. Today I tried to merge some bigger RF Channel Release changes... but I see that I need to kill the refcounts before doing that... z. From laforge at gnumonks.org Wed Jun 9 06:20:10 2010 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 9 Jun 2010 08:20:10 +0200 Subject: Encryption branch / BSC-MSC split In-Reply-To: <4C0DE4AC.40307@freyther.de> References: <20100608054807.GJ27115@prithivi.gnumonks.org> <4C0DE4AC.40307@freyther.de> Message-ID: <20100609062010.GK4173@prithivi.gnumonks.org> On Tue, Jun 08, 2010 at 02:35:24PM +0800, Holger Hans Peter Freyther wrote: > > Unfortunately merging the branch to master is also not really an option right > > now, as it is likely to cause trouble with the BSC/MSC split, as we will > > have to align our encryption support with how the A-Interface between BSC > > and MSC handles things. > > Hi, > > merge whatever is ready. well, it is not ready (as it is untested right now and I had to do lots of manual fixes during rebase) ... and it introduces lots of layer3 code (encryption command, etc) in the regular gsm_04_08.c file... so I'd _really_ prefer to see the BSC/MSC split happenign before causing more obstacles that we need to separate soon later. > In case I have a patch and need some days to stabilize I will ask on this > list to hold stuff back. Today I tried to merge some bigger RF Channel > Release changes... but I see that I need to kill the refcounts before doing > that... Let me know if there's something I can help with. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From 246tnt at gmail.com Wed Jun 9 07:43:07 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 9 Jun 2010 09:43:07 +0200 Subject: Encryption branch / BSC-MSC split In-Reply-To: <20100609062010.GK4173@prithivi.gnumonks.org> References: <20100608054807.GJ27115@prithivi.gnumonks.org> <4C0DE4AC.40307@freyther.de> <20100609062010.GK4173@prithivi.gnumonks.org> Message-ID: Hi Harald, One thing I didn't yet figure out is the HLR part on how to have a neat interface to store retrieve keys / authentication methods available and previous tuples. What's currently implemented is not good, I misuse the AuthTuple thing to store current authentication and not possible tuples to use when we don't know Ki. > well, it is not ready (as it is untested right now and I had to do lots of > manual fixes during rebase) ... and it introduces lots of layer3 code > (encryption command, etc) in the regular gsm_04_08.c file... Should those go elsewhere ? How should it be split ? I put gsm48_secure_channel (and supporting code) in gsm_04_08.c mainly because it needs to be called when there is a location update request (among other cases) and the loc update handling code is entirely in gsm_04_08.c I guess I must read on on what exactly is MSC domain and what is BSC domain, so far I mostly focused on 04.08 without paying attention to who is supposed to handle what ... Cheers, Sylvain From zecke at selfish.org Wed Jun 9 08:56:46 2010 From: zecke at selfish.org (Holger Freyther) Date: Wed, 09 Jun 2010 16:56:46 +0800 Subject: Encryption branch / BSC-MSC split In-Reply-To: References: <20100608054807.GJ27115@prithivi.gnumonks.org> <4C0DE4AC.40307@freyther.de> <20100609062010.GK4173@prithivi.gnumonks.org> Message-ID: <4C0F574E.9090606@selfish.org> On 06/09/2010 03:43 PM, Sylvain Munaut wrote: Hi both of you, > I guess I must read on on what exactly is MSC domain and what is BSC > domain, so far I mostly focused on 04.08 without paying attention to > who is supposed to handle what ... I have not read the code but the split is actual quite easy. Most of it is not in the BSC domain at all. The MSC will send a GSM08.08 message called Cipher Mode Command. It contains the key we will embed into the RSL message. E.g. this is when the subscriber has been authenticated (e.g. the IMSI still in the VLR, or the TMSI making sense). The Authentication Request is simply wrapped in DTAP and there is nothing special with it from the BSC point of view. Actually everything that is needed for the BSC/MSC split is already inside the GSM 04.08 utils, so anything you put into gsm_04_08.c does not create a problem... (at one point i will replace the gsm48_sendmsg with bsc_dtap_send). In regard to the MSC side... what will/should change is: 1.) no ref counting for lchan (maybe I start/finish it today) 2.) no direct paging calls, it should go through the subscriber code I had already checked-in.. 3.) better lchan management and this is where encyrption comes in. When we have a new connection, we should run it through auth first... and then hand it to the subsystem. please poke me if that does not make sense to you... z. From 246tnt at gmail.com Wed Jun 9 09:45:58 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 9 Jun 2010 11:45:58 +0200 Subject: Encryption branch / BSC-MSC split In-Reply-To: <4C0F574E.9090606@selfish.org> References: <20100608054807.GJ27115@prithivi.gnumonks.org> <4C0DE4AC.40307@freyther.de> <20100609062010.GK4173@prithivi.gnumonks.org> <4C0F574E.9090606@selfish.org> Message-ID: Hi, > The Authentication Request is simply wrapped in DTAP and there is > nothing special with it from the BSC point of view. Actually everything > that is needed for the BSC/MSC split is already inside the GSM 04.08 > utils, so anything you put into gsm_04_08.c does not create a problem... > (at one point i will replace the gsm48_sendmsg with bsc_dtap_send). Ok, when I look back at the code, most of it was gsm_04_08.c only. But not all of it. I needed some change in the paging system because once a paging succeded, I needed to be able to 'inject' myself before the callback was called. (So that I could secure the channel in the meantime). > ? ? ? ?3.) better lchan management and this is where encyrption comes > ? ? ? ? ? ?in. When we have a new connection, we should run it through > ? ? ? ? ? ?auth first... and then hand it to the subsystem. One thing that makes a 'transparent' implementation tricky is that a CIPHER MODE COMMAND is considered to be an implicit CM SERVICE ACCEPT. So what the code did it to offer a simple function to call whenever you wanted to secure the channel and offer a callback with the result. Sylvain From zecke at selfish.org Wed Jun 9 09:58:13 2010 From: zecke at selfish.org (Holger Freyther) Date: Wed, 09 Jun 2010 17:58:13 +0800 Subject: Encryption branch / BSC-MSC split In-Reply-To: References: <20100608054807.GJ27115@prithivi.gnumonks.org> <4C0DE4AC.40307@freyther.de> <20100609062010.GK4173@prithivi.gnumonks.org> <4C0F574E.9090606@selfish.org> Message-ID: <4C0F65B5.1070408@selfish.org> On 06/09/2010 05:45 PM, Sylvain Munaut wrote: > Ok, when I look back at the code, most of it was gsm_04_08.c only. But > not all of it. I needed some change in the paging system because once > a paging succeded, I needed to be able to 'inject' myself before the > callback was called. (So that I could secure the channel in the > meantime). Makes sense. This will certainly be more easy with the split but we need a dispatcher in the MSC code. That is doing auditing, then does other stuff, then hands it over to the subsystem, once the subsystem is done, we can hand it to the next one or close (leaving SMS during a phonecall out of the picture). > > >> 3.) better lchan management and this is where encyrption comes >> in. When we have a new connection, we should run it through >> auth first... and then hand it to the subsystem. > > One thing that makes a 'transparent' implementation tricky is that a > CIPHER MODE COMMAND is considered to be an implicit CM SERVICE ACCEPT. > So what the code did it to offer a simple function to call whenever > you wanted to secure the channel and offer a callback with the result. Oh, I didn't know that, that is funny. Well we have two settings here... one is if we want encryption on, the second is if that subscriber can do encryption. With what I have in mind, you would get the subscriber connection (currently embedded in the lchan) on a new connection and then your function can decide to close the channel, or to secure it and then hand it to someone else. From 246tnt at gmail.com Wed Jun 9 12:13:08 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 9 Jun 2010 14:13:08 +0200 Subject: Encryption branch / BSC-MSC split In-Reply-To: <4C0F65B5.1070408@selfish.org> References: <20100608054807.GJ27115@prithivi.gnumonks.org> <4C0DE4AC.40307@freyther.de> <20100609062010.GK4173@prithivi.gnumonks.org> <4C0F574E.9090606@selfish.org> <4C0F65B5.1070408@selfish.org> Message-ID: > Well we have two settings here... > one is if we want encryption on, the second is if that subscriber can do > encryption. With what I have in mind, you would get the subscriber > connection (currently embedded in the lchan) on a new connection and > then your function can decide to close the channel, or to secure it and > then hand it to someone else. That's what the code does now. Basically the caller calls the 'secure channel' function and provides a call back. What the secure does is : - Check if auth/encryption is requested (from the vty config). - If it is, and if the MS reported supporting it in ClassMark2, and if the subscriber has auth information in the DB, then it starts the auth(if needed), then cipher start. - Once done, the call back is called with a status : . NO_AVAIL : For some reason, it's not supported (no keys for subscribers or no CM2 support or not configured ...) But the channel is up and ready . FAIL : It should have been supported but the client failed to pass authentication, channel is closed. . OK : All OK. I've taken Harald's forward port and modded a couple of things, I'll test that tonight. The support for ciphering on MS initiated call and location update doesn't require paging system change. Sylvain From laforge at gnumonks.org Wed Jun 9 12:10:25 2010 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 9 Jun 2010 14:10:25 +0200 Subject: Encryption branch / BSC-MSC split In-Reply-To: References: <20100608054807.GJ27115@prithivi.gnumonks.org> <4C0DE4AC.40307@freyther.de> <20100609062010.GK4173@prithivi.gnumonks.org> Message-ID: <20100609121025.GV4173@prithivi.gnumonks.org> Hi Sylvain, On Wed, Jun 09, 2010 at 09:43:07AM +0200, Sylvain Munaut wrote: > One thing I didn't yet figure out is the HLR part on how to have a > neat interface to store retrieve keys / authentication methods > available and previous tuples. What's currently implemented is not > good, I misuse the AuthTuple thing to store current authentication and > not possible tuples to use when we don't know Ki. I have to check your code. My idea was to have two tables, one for actual keys (ki), and the other one for auth tuples. The tuples would probably need a 'last used' counter, so we can make sure we don't use the most recently used tuples again. Once we move to a 'more real' HLR, there will be an asynchronous request from MSC to HLR to obtain authentication tuples. Those tuples are then stored in the MSC-internal (volatile) VLR. > > well, it is not ready (as it is untested right now and I had to do lots of > > manual fixes during rebase) ... and it introduces lots of layer3 code > > (encryption command, etc) in the regular gsm_04_08.c file... > > Should those go elsewhere ? How should it be split ? We right now have gsm_04_08.c and gsm_04_08_utils.c... The _utils.c is used from both 'real BSC' and bsc_hack, and the plain 04_08.c is used only by the bsc_hack. So you actually have it in the right file, I was wrong. Thus, we could merge it. However, this part will nonetheless probably change a lot once we make the split... > I put gsm48_secure_channel (and supporting code) in gsm_04_08.c mainly > because it needs to be called when there is a location update request > (among other cases) and the loc update handling code is entirely in > gsm_04_08.c sure. > I guess I must read on on what exactly is MSC domain and what is BSC > domain, so far I mostly focused on 04.08 without paying attention to > who is supposed to handle what ... I think in general it's quite simple. The BSC handles RR (like channel request, immediate assign, paging), whereas MM, CC, SMS, etc. are handled by the MSC. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From 246tnt at gmail.com Wed Jun 9 12:25:14 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 9 Jun 2010 14:25:14 +0200 Subject: Encryption branch / BSC-MSC split In-Reply-To: <20100609121025.GV4173@prithivi.gnumonks.org> References: <20100608054807.GJ27115@prithivi.gnumonks.org> <4C0DE4AC.40307@freyther.de> <20100609062010.GK4173@prithivi.gnumonks.org> <20100609121025.GV4173@prithivi.gnumonks.org> Message-ID: Hi, > I have to check your code. ?My idea was to have two tables, one for actual > keys (ki), and the other one for auth tuples. ?The tuples would probably > need a 'last used' counter, so we can make sure we don't use the most > recently used tuples again. I've just made some changes to my code (compiles but not tested yet): - I have renamed the table AuthTuples to AuthLastTuples and use it to store the last used tuple (whatever the algorithm used, either comp128v1 or xor or ...). This will be useful so that we don't do the 'AUTH' part each time and just re-use the session key a couple of times before renewing it. - In a future commit, I'll add a AuthKnownTuples table and all the code required to implement a new 'algo_id' that would use only known tuples. It will have a last_used timestamp and some function to 'pick' a random one to use. Trying to do both 'functions' in a single table resulted in a big mess so I think they're better off splitted. > So you actually have it in the right file, I was wrong. ?Thus, we could > merge it. ?However, this part will nonetheless probably change a lot > once we make the split... Really ? In the end, it just sends messages so I would think that as holger said, only the gsm48_sendmsg will be replaced with bsc_dtap_send or something. I think the async HLR change will have much more impact. I'll test my updated code tonight and push it to my encryption if it doesn't break. Sylvain From 246tnt at gmail.com Thu Jun 10 10:37:28 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Thu, 10 Jun 2010 12:37:28 +0200 Subject: Encryption branch / BSC-MSC split In-Reply-To: References: <20100608054807.GJ27115@prithivi.gnumonks.org> <4C0DE4AC.40307@freyther.de> <20100609062010.GK4173@prithivi.gnumonks.org> <20100609121025.GV4173@prithivi.gnumonks.org> Message-ID: Hi, > I'll test my updated code tonight and push it to my encryption if it > doesn't break. First off, I tested the code in sylvain/encryption (which is mostly some minor db fixes from me and the code you fw-ported) and it works fine. (you also need my pending branch of libosmocore as I put the utility classmark2 a5 testing func there) The current limitations are : * Support only 'none' & 'comp128v1' as authentication method. - I need to add 'xor' (for the racal test sim) and 'knowntuples' (for sims with unknown Ki) * Does the authentication part each time currently - I need to add support for using the last tuple. Mostly implies storing the key_seq somewhere from LOC_UPD_REQ until it's needed. * Only support ciphering for Location Updates & MS-initiated calls. I'll probably do those first two tonight, should be simple enough. For the last one : The current flow for a network initiated call/sms is : - Somewhere, paging_request is called (from gsm_04_08 or gsm_04_11) with a given call back - [paging is done] - Then in gsm_04_08_utils handle_paging_resp: - We dispatch an event SS_PAGING - Stop the paging (which calls the call back) What I would do (and imho helps the bsc/msc split) is create a 'msc_paging_request' somewhere that would wrap the paging. The flow would then be: - Somewhere, msc_paging_request is called (from gsm_04_08 or gsm_04_11) with a given call back. - msc_paging_request calls paging_request with a cb_msc_paging. - [paging is done] - gsm_04_08_utils would _not_ dispatch then SS_PAGING event it self, it would just call back cb_msc_paging given in paging_request - Inside cb_msc_paging, I would then dispatch SS_PAGING event and call the original call back. Then to add the auth part, I could just modify cb_msc_paging to call secure channel if required. Sylvain From laforge at gnumonks.org Thu Jun 10 15:39:13 2010 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 10 Jun 2010 17:39:13 +0200 Subject: Encryption branch / BSC-MSC split In-Reply-To: References: <20100608054807.GJ27115@prithivi.gnumonks.org> <4C0DE4AC.40307@freyther.de> <20100609062010.GK4173@prithivi.gnumonks.org> <20100609121025.GV4173@prithivi.gnumonks.org> Message-ID: <20100610153913.GS19751@prithivi.gnumonks.org> Hi Sylvain, On Thu, Jun 10, 2010 at 12:37:28PM +0200, Sylvain Munaut wrote: > > I'll test my updated code tonight and push it to my encryption if it > > doesn't break. > > First off, I tested the code in sylvain/encryption (which is mostly > some minor db fixes from me and the code you fw-ported) and it works > fine. Great. As zecke can probably consider possible BSC/MSC merge fallout from all of this, I will lean back and let him decide if/how to merge your encryption branch. Zecke: hope this is fine with you. > (you also need my pending branch of libosmocore as I put the > utility classmark2 a5 testing func there) ok, i have merged this already. > What I would do (and imho helps the bsc/msc split) is create a > 'msc_paging_request' somewhere that would wrap the paging. The flow > would then be: > - Somewhere, msc_paging_request is called (from gsm_04_08 or > gsm_04_11) with a given call back. > - msc_paging_request calls paging_request with a cb_msc_paging. > - [paging is done] > - gsm_04_08_utils would _not_ dispatch then SS_PAGING event it self, > it would just call back cb_msc_paging given in paging_request > - Inside cb_msc_paging, I would then dispatch SS_PAGING event and > call the original call back. > > Then to add the auth part, I could just modify cb_msc_paging to call > secure channel if required. This makes a lot of sense with me and is probably pretty much how a normal MSC-internal dispatch for paging would look like. On top of this you would then have a transaction table and once all transactions are completed, you close the channel. Once again probably best to coordinate with zecke on this, I have never studied the bsc_msc_ip in detail so far (and prefer to focus on GPRS for now until I'm satisfied with it) Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From 246tnt at gmail.com Thu Jun 10 23:05:53 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 11 Jun 2010 01:05:53 +0200 Subject: Encryption branch / BSC-MSC split In-Reply-To: <20100610153913.GS19751@prithivi.gnumonks.org> References: <20100608054807.GJ27115@prithivi.gnumonks.org> <4C0DE4AC.40307@freyther.de> <20100609062010.GK4173@prithivi.gnumonks.org> <20100609121025.GV4173@prithivi.gnumonks.org> <20100610153913.GS19751@prithivi.gnumonks.org> Message-ID: Hi, Ok, I've finished what I wanted to do before a possible merge. It now supports Kc re-use and XOR algorithm. Missing things (KnownTuples / MT-Calls encryption) should be pluggable easily afterwards without core code change. I think it'd be good if someone else could confirm it works as expected tough. To test: * Enable encryption in openbsc.cfg : network encryption a5 1 * Put some Ki. (Currently either xor or comp128v1 sims, KnownTuples not supported yet). Easy to do with the VTY interface. openbsc> enable openbsc# subscriber imsi 001010123456789 a3a8 comp128v1 5e4ab35891375d2aee812e67c309a629 > Great. ?As zecke can probably consider possible BSC/MSC merge fallout > from all of this, I will lean back and let him decide if/how to merge > your encryption branch. ?Zecke: hope this is fine with you. Zecke: Ok, I think you can have a look at the current code. It shouldn't have any impact on BSC/MSC split. The impact will come later to support MT-calls encryption but I'll wait for your subscr_get_channel modifs to be done before I look at this. Cheers, Sylvain From zecke at selfish.org Fri Jun 11 01:19:04 2010 From: zecke at selfish.org (Holger Freyther) Date: Fri, 11 Jun 2010 09:19:04 +0800 Subject: Encryption branch / BSC-MSC split In-Reply-To: References: <20100608054807.GJ27115@prithivi.gnumonks.org> <4C0DE4AC.40307@freyther.de> <20100609062010.GK4173@prithivi.gnumonks.org> <20100609121025.GV4173@prithivi.gnumonks.org> <20100610153913.GS19751@prithivi.gnumonks.org> Message-ID: <4C118F08.90903@selfish.org> On 06/11/2010 07:05 AM, Sylvain Munaut wrote: > Zecke: Ok, I think you can have a look at the current code. It > shouldn't have any impact on BSC/MSC split. > The impact will come later to support MT-calls encryption but I'll > wait for your subscr_get_channel modifs to be done before I look at > this. Hi, yeah, please go ahead and merge. The only impact with the BSC/MSC split is that we will have a single point of entry for a new channel, so adding securing there will be easier. z. From bertoncello at netzing.de Wed Jun 9 09:01:20 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Wed, 9 Jun 2010 11:01:20 +0200 Subject: Rejecting cause Message-ID: <20100609110120.2b2f5b1b@debian503.nsag> Hi, all! If I try to change to my Test-Network with my mobile phone (not known from network and not yet authorized!!) I can't change (of course). Then I authorize my phone and I try again. It does not work. I have to turn off and on my phone in order to change to the network. I got the information that I can solve this problem by changing the reject cause (location updating reject cause). Unfortunately I don't know any cause that say the phone "OK, try again later", so that my phone will try again later. Can someone help me and say me a code? I have to give a numeric code, but I don't know any. It was suggested to send a "network failure" or "congestion" or "overload", but I don't know the code for these cause... Thanks for your help! -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at netzing.de NETZING Solutions AG Tel.: 0351/41381 - 0 Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12 HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag at netzing.de _______________________________________________________________________ From zecke at selfish.org Wed Jun 9 09:05:28 2010 From: zecke at selfish.org (Holger Freyther) Date: Wed, 09 Jun 2010 17:05:28 +0800 Subject: Rejecting cause In-Reply-To: <20100609110120.2b2f5b1b@debian503.nsag> References: <20100609110120.2b2f5b1b@debian503.nsag> Message-ID: <4C0F5958.9040307@selfish.org> On 06/09/2010 05:01 PM, Luca Bertoncello wrote: > Hi, all! > > If I try to change to my Test-Network with my mobile phone (not known > from network and not yet authorized!!) I can't change (of course). > Then I authorize my phone and I try again. What phone is that? > Can someone help me and say me a code? I have to give a numeric code, > but I don't know any. It was suggested to send a "network failure" or > "congestion" or "overload", but I don't know the code for these cause... Please see GSM 04.08 "Table 10.5.95/GSM 04.08: Reject Cause information element". E.g. congestion would be 22. Feel free to change the code to take different names and have a map from name to number in the code. z. From downtherabbithol3 at gmail.com Wed Jun 9 14:52:27 2010 From: downtherabbithol3 at gmail.com (Rabbit) Date: Wed, 9 Jun 2010 15:52:27 +0100 Subject: bts for sale Message-ID: Sorry for the intrusion but I thought maybe someone here would be interested. I have two ipaccess bts 165au to sell. Both are fully working with POE. I'm also including the ipaccess software and manuals. Software: BTS installer, BTS Manager, IPaccess BSC which runs on redhat(all rpm files). Also have an msc which runs on windows but you'll need a license and dongle to make it work or defeat the dongle. Documentations are PDFs. You can pick it up in London or can ship it. pics: http://tinypic.com/3ia3muxg -------------- next part -------------- An HTML attachment was scrubbed... URL: From bouchtaoui at gmail.com Wed Jun 9 15:30:44 2010 From: bouchtaoui at gmail.com (Nordin) Date: Wed, 09 Jun 2010 17:30:44 +0200 Subject: bts for sale In-Reply-To: References: Message-ID: <4C0FB3A4.60102@gmail.com> Can I get a copy of the software, just for research purpose? :) I'd like to know how "Listen Network" feature work. regards, Nordin. On 9-6-2010 16:52, Rabbit wrote: > Sorry for the intrusion but I thought maybe someone here would be > interested. I have two ipaccess bts 165au to sell. Both are fully working > with POE. I'm also including the ipaccess software and manuals. Software: > BTS installer, BTS Manager, IPaccess BSC which runs on redhat(all rpm > files). Also have an msc which runs on windows but you'll need a license and > dongle to make it work or defeat the dongle. Documentations are PDFs. You > can pick it up in London or can ship it. > > pics: http://tinypic.com/3ia3muxg > > From laforge at gnumonks.org Thu Jun 10 13:00:34 2010 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 10 Jun 2010 15:00:34 +0200 Subject: bts for sale In-Reply-To: <4C0FB3A4.60102@gmail.com> References: <4C0FB3A4.60102@gmail.com> Message-ID: <20100610130034.GL19751@prithivi.gnumonks.org> Dear Nordin, On Wed, Jun 09, 2010 at 05:30:44PM +0200, Nordin wrote: > Can I get a copy of the software, just for research purpose? > :) Please be careful. This mailing list is not a place to trade / share or otherwise discuss illegitimatley copied software. If the seller has legitimate software and he is able to sell valid licenses, everything is fine (but still a bit off-topic on the list). This is a mailing list to discuss the development of Free Software implementations of the GSM protocols! > I'd like to know how "Listen Network" feature work. It is implemented in ipaccess-config, so there is no need for the ip.access-provided software. Their software will also not tell you how that feature works. That is implemented inside the ip.access firmware, and it is doing nothing else what a normal phone (or OsmocomBB) do for scanning the power of ARFCNs, locking onto their signal and reading system information messages. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From bouchtaoui at gmail.com Thu Jun 10 13:25:49 2010 From: bouchtaoui at gmail.com (Nordin) Date: Thu, 10 Jun 2010 15:25:49 +0200 Subject: bts for sale In-Reply-To: <20100610130034.GL19751@prithivi.gnumonks.org> References: <4C0FB3A4.60102@gmail.com> <20100610130034.GL19751@prithivi.gnumonks.org> Message-ID: <4C10E7DD.4080908@gmail.com> On 10-6-2010 15:00, Harald Welte wrote: > Dear Nordin, > > On Wed, Jun 09, 2010 at 05:30:44PM +0200, Nordin wrote: > >> Can I get a copy of the software, just for research purpose? >> :) >> > Please be careful. This mailing list is not a place to trade / share or > otherwise discuss illegitimatley copied software. > > If the seller has legitimate software and he is able to sell valid > licenses, everything is fine (but still a bit off-topic on the list). > > This is a mailing list to discuss the development of Free Software > implementations of the GSM protocols! > Ok Harald, sorry about that. >> I'd like to know how "Listen Network" feature work. >> > It is implemented in ipaccess-config, so there is no need for the > ip.access-provided software. Their software will also not tell you > how that feature works. That is implemented inside the ip.access > firmware, and it is doing nothing else what a normal phone (or > OsmocomBB) do for scanning the power of ARFCNs, locking onto their > signal and reading system information messages. > Aah good to know, I'll play with that, thank you. From jmercury313 at gmail.com Wed Jun 9 15:09:02 2010 From: jmercury313 at gmail.com (jason mercury) Date: Wed, 9 Jun 2010 18:09:02 +0300 Subject: Rejecting cause Message-ID: Hi , I have same problem with Luca. I could not attach my phone (Nokia N79) to the network unless I close and re-open my phone. When authorized=0 I could not see any location update reject log related my phone on the screen. Changing reject cause was helpful for some other phones but It did not work for N79. I have seen a error message on the bsc_hack screen I think that this can be related to the problem: <0000> abis_rsl.c:1237 (bts=0,trx=0,ts=0,ss=0) ERROR INDICATION cause=Timer T200 expired (N200+1) times Please help. Thanks. Jason. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bouchtaoui at gmail.com Wed Jun 9 15:26:08 2010 From: bouchtaoui at gmail.com (Nordin) Date: Wed, 09 Jun 2010 17:26:08 +0200 Subject: Rejecting cause In-Reply-To: References: Message-ID: <4C0FB290.9030407@gmail.com> Try to change the lac-code and try again. On 9-6-2010 17:09, jason mercury wrote: > Hi , > > I have same problem with Luca. I could not attach my phone (Nokia N79) to > the network unless I close and re-open my phone. When authorized=0 I could > not see any location update reject log related my phone on the screen. > Changing reject cause was helpful for some other phones but It did not work > for N79. I have seen a error message on the bsc_hack screen I think that > this can be related to the problem: > > <0000> abis_rsl.c:1237 (bts=0,trx=0,ts=0,ss=0) ERROR INDICATION cause=Timer > T200 expired (N200+1) times > > Please help. Thanks. > > Jason. > > From dragos.vingarzan at gmail.com Wed Jun 9 21:14:57 2010 From: dragos.vingarzan at gmail.com (Dragos Vingarzan) Date: Wed, 9 Jun 2010 23:14:57 +0200 Subject: Hello, UMTS support and HSS/HLR Message-ID: Hi guys, wow, finally found this project/list :). First a bit of background: working at Fraunhofer FOKUS, in Berlin; "maintaining" openimscore.org (when I still find the time); working on openepc.net; currently doing some prototypes for the LTE access part - MME/HSS/eNodeB - only Layer 3 and up. What brings me here is that I have a need for getting a test-bed setup as complete as possible, without black-boxes.The ultimate dream is to have everything from radio to application layers running on COTS hardware for test-bed purposes (nothing commercial). Obviously I am coming from the upper layers to the lower ones, as we had to satisfy first the Application Server guys. So far we've done prototypes for P/I/S-CSCF, HSS(Cx,Sh) and some light MGCF, BGCF/etc with the OpenIMSCore. With OpenEPC we are adding some PDN-Gw, ANGw(SGw/ePDG), PCRF, PCEF, BBERF, ANDSF, HSS (Sp) and working on the afore-mentioned MME, HSS(S6a,etc), eNodeB. Of course, all are prototypes, but we try to make them as inter-operable as economically feasible. Now I am also very interested in UMTS. We're demo-ing EPS hand-overs and the sort between WiFi, LTE (just using it as an air bridge for now) and 3G, but we use commercial 3G, which is quite frustrating as it seems to have a directly proportional probability to fail with the number of phones present in the demo room. However, I do have an Oyster 3G femto from ip.access and would very much like to explore on how can I use it in an environment completely under control. I know about other BTS alternatives, but I really just need the PS part and I need good data-rates. (CS is out of scope for me as it's supposed to be phased out at a point and we have already the all-IP stuff on top, even like 3GPP likes to see it) I see that I am not the only one interested. Now I am still trying to get some more documentation from ip.access. If any of you already figured out how to do the basic operations or at least what is required, I would really appreciate the pointers. Then regarding the HLR - it seems that you have some troubles with it. Well, we have done a couple of HSSs in the past 5 or so years, which is supposed to be an HLR evolution suitable for all-IP environments. So we have all the irrelevant, but required, DB back-end, provisioning interfaces or AKA authentication sorted. Unfortunately it only has support for Diameter, with RADIUS on the road-map due to integration with non-3GPP trusted access networks (WPA with EAP-SIM/EAP-AKA). Also these days I am trying to add support for LTE network attachments through the S6a Diameter interface. If you can provide me with some quick requirements to what you need for the HLR, I hope that we could help. Cheers, -Dragos -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Thu Jun 10 13:18:16 2010 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 10 Jun 2010 15:18:16 +0200 Subject: Hello, UMTS support and HSS/HLR In-Reply-To: References: Message-ID: <20100610131816.GM19751@prithivi.gnumonks.org> Hi Dragos, On Wed, Jun 09, 2010 at 11:14:57PM +0200, Dragos Vingarzan wrote: > wow, finally found this project/list :). Great :) > First a bit of background: working at Fraunhofer FOKUS, in Berlin; > "maintaining" openimscore.org (when I still find the time); working on > openepc.net; currently doing some prototypes for the LTE access part - > MME/HSS/eNodeB - only Layer 3 and up. As far as I have been told, those projects have 'open' in their name but are not Open Source / Free Software. If this is the case, please make this clear to this list before people put in their valuable time to help you and are later only disappointed... - we're used to Free Software only here. > However, I do have an Oyster 3G femto from ip.access and would very much > like to explore on how can I use it in an environment completely under > control. I know about other BTS alternatives, but I really just need the PS > part and I need good data-rates. (CS is out of scope for me as it's supposed > to be phased out at a point and we have already the all-IP stuff on top, > even like 3GPP likes to see it) > > I see that I am not the only one interested. Now I am still trying to get > some more documentation from ip.access. If any of you already figured out > how to do the basic operations or at least what is required, I would really > appreciate the pointers. Dieter, myself and others have been looking at it, and I think we already know everything needed to support the Oyster3G. So talking its protocol is not that much of a difficulty.... however, integrating it with the OsmoSGSN (which is only now starting to be functional for GPRS and EDGE) and the not-really-independent MSC part inside OpenBSC are bigger unresolved areas. Our problem is that we simply don't have the time to do this, and unfortunately no company so far seems to have had a commercial interest to fund this work either (as opposed to the majority of our other OpenBSC work in 2G / 2.5G area). As indicated in my previous mail, the protocols that Oyster3G are used are all implemented in the wireshark dissectors of ip.access. They even include the XML files from which the dissectors are generated. Sure, this is not a full reference manual, but still a lot of information. > If you can provide me with some quick requirements to what you need for the > HLR, I hope that we could help. At the moment only GSM+GPRS requirements, i.e. the "C interface" as per the ETSI/3GPP specs. Also, the difficulty is not implementing the HLR, but how to implement the protocols (MAP over TCAP over SCCP) within our existing architecture ("C only, no multi-threading, keep it simple/stupid"). My current attempts are using asn1c and generating three shared libraries: * one for the asn1c runtime functions (which it typically creates symlinks) * one for the asn1c-generated MAP asn1 functions * one for the asn1c-generated TCAP asn1 functions Then those libraries could be linked from all our projects that need MAP access, use it in combination with our existing SCCP implementation and (hopefully) be happy... 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 dragos.vingarzan at gmail.com Thu Jun 10 15:20:46 2010 From: dragos.vingarzan at gmail.com (Dragos Vingarzan) Date: Thu, 10 Jun 2010 17:20:46 +0200 Subject: Hello, UMTS support and HSS/HLR In-Reply-To: <20100610131816.GM19751@prithivi.gnumonks.org> References: <20100610131816.GM19751@prithivi.gnumonks.org> Message-ID: <4C1102CE.1050208@gmail.com> Hi Harald, You are right about the "open" lingo used in our marketing materials, where sometimes it just means that we are standards aligned. So let me try and clarify it: - Open Source IMS Core - all GPLv2 - Open EPC - not GPL for now, but for all parts that I am talking about contributing here, I am already in the process of publishing under GPL There are 2 parts to why we can't make it all open source for now: 1. Sometimes we make the big vendors uncomfortable when we open source something that can server signaling for a million subscribers on one standard workstation. Then we get a lot of bullying with patents and stuff, although we just want to help with technology adoptions. You also have the non-commercial usage disclaimer, similar that we are running since 2006 on our open source websites and file headers. We actually have it there because some think we're competing with them and send the lawyers. 2. We make significant financial investments to be able to demo complete scenarios, over all layers. So we would like to have usually a 2 year interval to recover the initial investments, while the respective technologies are still new and there is still a potential to capitalize from the industry players that building such components. After that it is open source. So, long story short: - anything related to LTE and the new 3GPP concepts, it would stay close in the near future and will open up as the R&D demand slows (mainly OpenEPC) - anything else related to GSM, UMTS, IMS is open source (OpenIMSCore and parts of OpenEPC that have interfaces to the 2/3G Access Networks) What drives me here is the need to have the 2/3G access do-able with affordable BTS/NodeB hardware and open source software. For this I don't have any other agenda than to be able to deploy our EPC/IMS-in-a-bottle test-bed prototypes together with controllable access. For the Oyster3G/OsmoSGSN integration, I can understand the resource shortage as I am finding it difficult to finance developments even for LTE, so I guess for 2G it is pretty dry. However, the good part is that I have the summer to figure UMTS and LTE out. For UMTS I am now arranging to get 1 intern-ship student and maybe also 1 part-time graduate to help out. So we hope to be able to put some efforts behind it. Definitely it won't have the quality that you put out, but it's much better than nothing, right? Myself I will have to concentrate on doing the same for LTE with eNodeB/MME/SGw parts, so I hope that some interfaces there are not wildly different and we could reuse parts of them. Now regarding MAP... ugh, ugly. I agree that you need it if you want to be able to use at some point a real HLR, but it will be a pain. If you do get something out of it I would be very interested in making a module for our HSS with it. Otherwise I am just as much in the dark on what the protocol needs to do in order to inter-operator properly and we usualy take something of a different approach than you with ASN.1. We rather build something small and not so much reusable, but just for the task at hand and defer anything else for later. The kind of doing 90% of the protocol in 10% of the time with minimal dependencies and get back to it when you have someone really interested in more. But, what about doing it with stuff that is already available for now? I mean, you are at the both ends of the communication so you could use whatever works for now. And here comes the crazy thought: Diameter, which although is further in the specs and only replaces MAP from Rel6 I guess and not even there entirely. I saw your request for traces on MAP and well, it sounds awfully familiar with the stuff in TS 29.272, the S6a interface between the HSS and the MME: Update-Location-Request/Answer, Cancel-Location-Request/Answer, Purge-UE,ME-Identity-Check. Besides, the DB structures behind are the same with some alternatives for authentication info and new features. Here is what I have added for the S6a to the Diameter constants in the CDiameterPeer stack http://svn.berlios.de/viewcvs/openimscore/ser_ims/trunk/modules/cdp/diameter_epc.h?r1=920&r2=952 as to give you some ideas on what data is exchanged. Anyway, it's a crazy idea because this Diameter stack is far from KISS, although it's not nearly as crazily-elaborated as OpenDiameter for example, but still multi-process, own managed shared memory, etc so that it would have a scalable performance. Cheers, -Dragos Harald Welte wrote: > Hi Dragos, > > On Wed, Jun 09, 2010 at 11:14:57PM +0200, Dragos Vingarzan wrote: > > >> wow, finally found this project/list :). >> > > Great :) > > >> First a bit of background: working at Fraunhofer FOKUS, in Berlin; >> "maintaining" openimscore.org (when I still find the time); working on >> openepc.net; currently doing some prototypes for the LTE access part - >> MME/HSS/eNodeB - only Layer 3 and up. >> > > As far as I have been told, those projects have 'open' in their name > but are not Open Source / Free Software. If this is the case, please make > this clear to this list before people put in their valuable time to help > you and are later only disappointed... - we're used to Free Software only > here. > > >> However, I do have an Oyster 3G femto from ip.access and would very much >> like to explore on how can I use it in an environment completely under >> control. I know about other BTS alternatives, but I really just need the PS >> part and I need good data-rates. (CS is out of scope for me as it's supposed >> to be phased out at a point and we have already the all-IP stuff on top, >> even like 3GPP likes to see it) >> >> I see that I am not the only one interested. Now I am still trying to get >> some more documentation from ip.access. If any of you already figured out >> how to do the basic operations or at least what is required, I would really >> appreciate the pointers. >> > > Dieter, myself and others have been looking at it, and I think we already > know everything needed to support the Oyster3G. So talking its protocol > is not that much of a difficulty.... however, integrating it with the > OsmoSGSN (which is only now starting to be functional for GPRS and EDGE) > and the not-really-independent MSC part inside OpenBSC are bigger unresolved > areas. > > Our problem is that we simply don't have the time to do this, and > unfortunately no company so far seems to have had a commercial interest > to fund this work either (as opposed to the majority of our other > OpenBSC work in 2G / 2.5G area). > > As indicated in my previous mail, the protocols that Oyster3G are used > are all implemented in the wireshark dissectors of ip.access. They even > include the XML files from which the dissectors are generated. Sure, > this is not a full reference manual, but still a lot of information. > > >> If you can provide me with some quick requirements to what you need for the >> HLR, I hope that we could help. >> > > At the moment only GSM+GPRS requirements, i.e. the "C interface" as per > the ETSI/3GPP specs. Also, the difficulty is not implementing the HLR, > but how to implement the protocols (MAP over TCAP over SCCP) within our > existing architecture ("C only, no multi-threading, keep it simple/stupid"). > > My current attempts are using asn1c and generating three shared libraries: > * one for the asn1c runtime functions (which it typically creates symlinks) > * one for the asn1c-generated MAP asn1 functions > * one for the asn1c-generated TCAP asn1 functions > > Then those libraries could be linked from all our projects that need MAP > access, use it in combination with our existing SCCP implementation and > (hopefully) be happy... > > Regards, > Harald > -- Best Regards, Dragos Vingarzan From zecke at selfish.org Tue Jun 15 04:59:21 2010 From: zecke at selfish.org (Holger Freyther) Date: Tue, 15 Jun 2010 12:59:21 +0800 Subject: Operation management in the MSC code Message-ID: <4C1708A9.4010202@selfish.org> Hi, I am going through the SMS code right now and try to convert it to the BSC API and there is something that is quite bad. There are many paths were sending a SMS can end, some do not free the SMS, some not the transaction, some do not remove lock on the channel. I would like to make the radical proposal to solve that. 1.) kill the transaction... 2.) generalize it with the "operation". Right now we do have two operations, one for LU, one for AUTH, we should have them for USSD, SMS and CC as well. Each gsm_subscriber_connection (MSC data) has an operation manager, when a lchan is opened we will attempt to create an operation for the initial message, at the end of one operation the operation manager will check if all operations are completed and then send a clear using the BSC API. The consequence of that is: 1.) we get rid of the refcount and can close channels faster 2.) we will notice... when we run into a timeout and should not... I know this will be a bigger change on the MSC side of things but what do you guys think about it? z. From Andreas.Eversberg at versatel.de Tue Jun 15 07:43:02 2010 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Tue, 15 Jun 2010 09:43:02 +0200 Subject: AW: Operation management in the MSC code Message-ID: >1.) kill the transaction... >2.) generalize it with the "operation". Right now we do have two >operations, one for LU, one for AUTH, we should have them for USSD, SMS >and CC as well. hi holger, the "transaction" represents the instance of calling party / called party / sms sender / ... will the states of it be moved to the "operation"? (e.g. call state, transaction_id, callref, protocol) in this case the call control / sms must use "operation" instance instead. i currently use "transaction" in osmocom-bb for call control and later sms and supplementary services. i think that the sms code should be re-usable in osmocom-bb, so the "operation" instance should be equal (defined in libosmocore) and the sms function sould be available in something like a "libsms", like the "libvty". note: osmocom-bb is at a point where SMS could be sent and received, if a shared sms library would be available. andreas From zecke at selfish.org Tue Jun 15 08:15:58 2010 From: zecke at selfish.org (Holger Freyther) Date: Tue, 15 Jun 2010 16:15:58 +0800 Subject: AW: Operation management in the MSC code In-Reply-To: References: Message-ID: <4C1736BE.40101@selfish.org> On 06/15/2010 03:43 PM, Andreas.Eversberg wrote: >> 1.) kill the transaction... >> 2.) generalize it with the "operation". Right now we do have two >> operations, one for LU, one for AUTH, we should have them for USSD, SMS >> and CC as well. > > hi holger, > > the "transaction" represents the instance of calling party / called > party / sms sender / ... will the states of it be moved to the > "operation"? (e.g. call state, transaction_id, callref, protocol) in > this case the call control / sms must use "operation" instance instead. Sure, we will keep the state, either inside the MSC per (SCCP) Connection state, or inside an operation. In any case "operation" or "transaction" are just two different names... the main reasons for change are 1.) Make sure all code using transaction/operation has a clear Success, Failure, Timeout semantic (the SMS code is failing here). 2.) Make sure that when the last transaction on a connection is done, the connection is cleared (all resources allocated at the BSC will be released). If we want to stick with the "transaction" name and code we should.. 1.) move the list anchor into the subscriber_connection.. 2.) plant some timers... like we do for the LU and AUTH(i didn't check) 3.) make trans_free check if the transaction list is empty and send a clear request... at which point no more transactions can be created on that connection... Regarding new (SMS) code, the main lesson to learn is probably: Have Success/Failure/Timeout in mind and free the channel in any of these states... From laforge at gnumonks.org Tue Jun 15 15:30:29 2010 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 15 Jun 2010 17:30:29 +0200 Subject: AW: Operation management in the MSC code In-Reply-To: <4C1736BE.40101@selfish.org> References: <4C1736BE.40101@selfish.org> Message-ID: <20100615153029.GP7613@prithivi.gnumonks.org> On Tue, Jun 15, 2010 at 04:15:58PM +0800, Holger Freyther wrote: > Regarding new (SMS) code, the main lesson to learn is probably: Have > Success/Failure/Timeout in mind and free the channel in any of these > states... sure. The current SMS implementation was always only a quick hack to make it work at all. At some point, new code should be written with MAP SMS semantics in mind, i.e. anticipate that SMS are sent from an external process by procedures that resemble the SMS-MAP as defined in Section 4 of 03.47. I'm not referring to the actual encoding, but by the flow of events / procedures, i.e. : * Forward MT SMS * Forward MO SMS * SC Alert This basically means an external entity (the Service Center SC) sends a SMS to the MSC, identifying the subscriber by its MSISDN. The MSC needs to decide if there is already a radio channel or if it needs to do paging. It does the paging (if needed), delivers the message and if everything works fine, it reports back to the SC. The timer at the SC side is specified between 15 to 180 seconds in total. MO-SMS is relatively similar, but in inverse direction. The SC Alert seems to be used for notifying the SC that a MS (that previously was unreachable or had a memory-full condition) is now available again. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Tue Jun 15 08:20:35 2010 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 15 Jun 2010 10:20:35 +0200 Subject: Operation management in the MSC code In-Reply-To: <4C1708A9.4010202@selfish.org> References: <4C1708A9.4010202@selfish.org> Message-ID: <20100615082035.GC7613@prithivi.gnumonks.org> On Tue, Jun 15, 2010 at 12:59:21PM +0800, Holger Freyther wrote: > I would like to make the radical proposal to solve that. > > 1.) kill the transaction... > 2.) generalize it with the "operation". Right now we do have two > operations, one for LU, one for AUTH, we should have them for USSD, SMS > and CC as well. I think location updating and authentication (as well as anything else that is part of MM or RR) need to be treated differently than the real transactions (like SMS, CC, SS, ...) For one part: they don't have a transaction identifier, so you can never have multiple of them at the same time. For the other part: They occur at specific times as mandated by the specification, so they cannot happen in any order like SMS transfers or call related transactions. > Each gsm_subscriber_connection (MSC data) has an operation manager, when > a lchan is opened we will attempt to create an operation for the initial > message, at the end of one operation the operation manager will check if > all operations are completed and then send a clear using the BSC API. how would you take care of ordering / sequencing? How to decide which operation is exclusive and which operations can operate simultaneously? Especially in CC, eight call control 'operations' would be able to exist at the same 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 r.zahoransky at gmx.de Tue Jun 15 12:19:08 2010 From: r.zahoransky at gmx.de (Richard Zahoransky) Date: Tue, 15 Jun 2010 14:19:08 +0200 Subject: open bsc and lcr: layer_3 thread read socket error Message-ID: <20100615121908.308790@gmx.net> Hello, my name is Richard and I am working on OpenBSC and LCR for my university. We plan to deploy a GSM-Network on the campus for research. We have successfully installed OpenBSC, Asterisk, LCR and mISDN. Lcr starts correctly (as far as I can say). The nanoBTS connects to OpenBSC and boot up. On the local machine, we can place outgoing calls with asterisk but when we dial from the cellphones, the lcr prints out: "layer3_thread read socket error No space left on device". I don't know if this is an error in LCR, OpenBSC, mISDN or just in my own config files. We ran through the How-to "OpenBSC_LCR" on http://openbsc.osmocom.org/trac/wiki: gsm is enabled in options.conf GSM interface is active in interface.conf mISDN_l1loop interfaces are created and the routing.conf looks also as described: ----------------------routing.conf (lcr)---------------------- [main] interface=GSM : remote application=asterisk context=btsctrl #interface=xyz : goto ruleset=xyz extern : goto ruleset=extern intern : goto ruleset=intern : disconnect cause=31 ------------------------------------------------------------- the rest of the file is untouched. on the local asterisk, the chan_lcr.so is loaded. the context btsctrl is defined is the extensions.conf: ----------------------extension.conf (asterisk)-------------- [default] exten => _0.,1,Dial(SIP/10${EXTEN}@comsys02) [btsctrl] exten => _X.,1,Set,CALLERID(num)=5552342 exten => _X.,n,dial(SIP/10${EXTEN}@comsys02) ------------------------------------------------------------- it connects to the remote asterisk server as user comsys02, defined in sip.conf ----------------------sip.conf (asterisk)-------------------- register => comsys02:xxx at 132.230.4.8/comsys02 [general] port=5060 bindaddr=0.0.0.0 [btsctrl] type=friend context=default secret=xxx host=dynamic [comsys02] type=friend context=btsctrl username=comsys02 fromuser=comsys02 secret=xxx host=132.230.4.8 qualify=yes nat=yes ------------------------------------------------------------- now everything seems to work, but when i dial a number, it prints out: "layer3_thread read socket error No space left on device", many times per second. On the phone I hear static noise. lcradmin prints out the following: ACTION (match) action remote line 8 EP(1): ACTION remote (setup) number 076719235 remote as* EP(1): SETUP ACKNOWLEDGE to CH(1) EP(1): TONE to CH(1) directory default name dialing EP(1): TONE to CH(1) directory default name cause_10 EP(1): DISCONNECT to CH(1) cause value=16 location=1-Lo* CH(1): MNCC_DISC_REQ LCR<-BSC port 1 progress coding=3 * CH(1): MNCC_REL_IND LCR<-BSC port 1 cause coding=0 loca* EP(1): RELEASE from CH(1) cause value=31 location=1-Loc* EP(1): ACTION hangup and the local asterisk output is: NOTICE[10941]: chan_lcr.c:1731 handle_retry: [call=NULL ast=NULL] Retry to open socket. NOTICE[10941]: chan_lcr.c:364 send_message: [call=NULL ast=NULL] Sending MESSAGE_NEWREF to socket. maybe someone also encountered this problem or can help us with the configuration many thanks in advance and best regards, richard From zecke at selfish.org Tue Jun 15 13:02:12 2010 From: zecke at selfish.org (Holger Freyther) Date: Tue, 15 Jun 2010 21:02:12 +0800 Subject: open bsc and lcr: layer_3 thread read socket error In-Reply-To: <20100615121908.308790@gmx.net> References: <20100615121908.308790@gmx.net> Message-ID: <4C1779D4.5030501@selfish.org> On 06/15/2010 08:19 PM, Richard Zahoransky wrote: > Hello, > > my name is Richard and I am working on OpenBSC and LCR for my university. We plan to deploy a GSM-Network on the campus for research. Hi, where is that university located? I can't help with LCR but as a general hint you can use strace and at least see which filedescriptor returned that error, it might be a hint. Have you tested the BTS with something like bsc_hack? Does this work? From Andreas.Eversberg at versatel.de Tue Jun 15 14:58:19 2010 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Tue, 15 Jun 2010 16:58:19 +0200 Subject: AW: open bsc and lcr: layer_3 thread read socket error Message-ID: hi, first try the bsc_hack. it has a bult-in MSC, so you can call from mobile phone to mobile phone. if this works, try to use LCR without asterisk. if you have no ISDN card, then you can also dial via LCR from mobile to mobile. if this works, then try asterisk... andreas On 06/15/2010 08:19 PM, Richard Zahoransky wrote: > Hello, > > my name is Richard and I am working on OpenBSC and LCR for my university. We plan to deploy a GSM-Network on the campus for research. From laforge at gnumonks.org Tue Jun 15 15:08:38 2010 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 15 Jun 2010 17:08:38 +0200 Subject: open bsc and lcr: layer_3 thread read socket error In-Reply-To: <20100615121908.308790@gmx.net> References: <20100615121908.308790@gmx.net> Message-ID: <20100615150838.GO7613@prithivi.gnumonks.org> Hi Richard, On Tue, Jun 15, 2010 at 02:19:08PM +0200, Richard Zahoransky wrote: > my name is Richard and I am working on OpenBSC and LCR for my university. We > plan to deploy a GSM-Network on the campus for research. This is great news and exactly one of the reasons why we wrote OpenBSC in the first place. > We have successfully installed OpenBSC, Asterisk, LCR and mISDN. Lcr starts > correctly (as far as I can say). The nanoBTS connects to OpenBSC and boot up. > On the local machine, we can place outgoing calls with asterisk but when we > dial from the cellphones, the lcr prints out: "layer3_thread read socket > error No space left on device". I don't know if this is an error in LCR, > OpenBSC, mISDN or just in my own config files. I think rather than starting with the full setup, you should keep it simple for the beginning. Have you ever tried to run OpenBSC in stand-alone mode, i.e. not linked against lcr? Sure, you will only have a GSM island without connection to the outside world, but it is a good way to ensure that nanoBTS and OpenBSC work together as expected, and that your openbsc.cfg is correct. Once that is working, you can move to the lcr variant, and once that works, start interfacing asterisk with it. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From r.zahoransky at gmx.de Wed Jun 16 14:39:29 2010 From: r.zahoransky at gmx.de (Richard Zahoransky) Date: Wed, 16 Jun 2010 16:39:29 +0200 Subject: open bsc and lcr: layer_3 thread read socket error Message-ID: <20100616143929.24620@gmx.net> -------- Original-Nachricht -------- > Datum: Tue, 15 Jun 2010 21:02:12 +0800 > Von: Holger Freyther > An: openbsc at lists.gnumonks.org > Betreff: Re: open bsc and lcr: layer_3 thread read socket error > On 06/15/2010 08:19 PM, Richard Zahoransky wrote: > > Hello, > > > > my name is Richard and I am working on OpenBSC and LCR for my > university. We plan to deploy a GSM-Network on the campus for research. > > Hi, > > where is that university located? It is the Albert-Ludwigs-Universit?t in Freiburg, Baden-W?rttemberg, Germany. > I can't help with LCR but as a general > hint you can use strace and at least see which filedescriptor returned > that error, it might be a hint. > > Have you tested the BTS with something like bsc_hack? Does this work? > Yes, bsc_hack works with no problems. Thank you for your advice! We have solved the problem. We simply didn't load the mISDN_dsp module. We did not integrate the mISDN_l1loop into the kernel but start it with insmod mISDN_l1loop.ko (located in a subfolder of the mISDN-Folder after running 'make') Still, if we load the l1loop with -nchannel=30 the lcr would somtimes print out the already said error message but it doesn't hang. It is then still possible to place a phone call from the cell phones. As workaround, we load the module with 8 channels instead of 30. It seems to work without the error message. Only one error is left. LCR prints: 'ERROR Port 1 already in use by LCR. You can't use a NT port multiple times.' On startup. Outgoing calls work but we still have to test incoming calls. From zecke at selfish.org Wed Jun 16 10:30:11 2010 From: zecke at selfish.org (Holger Freyther) Date: Wed, 16 Jun 2010 18:30:11 +0800 Subject: Status of the BSC/MSC API split Message-ID: <4C18A7B3.5060109@selfish.org> Hi all, here is just a small information of what is going on and what will happen in the near future. Done: - Create bsc_api.c for the BSC API handling - Create osmo_msc.c for the callbacks... - Start to remove lchan usage from MSC code What will happen: - No MSC code will directly touch/use/know about the lchan - Move the gsm48_recvmsg into the BSC API and dispatch - The transaction will be anchored inside the subscriber con and no transactions will clear the channel immediately - Need to add API for Cipher, Handover, Assignment handling - pick a better name for subscriber_connection. What can happen after this: - We can reimplement the bottom of the BSC API with SCCP and have a true MSC codebase... If any of you is adding new L3 code, please do not use the LCHAN directly but the subscriber connection. thanks holger From nico at ngolde.de Wed Jun 16 13:22:30 2010 From: nico at ngolde.de (Nico Golde) Date: Wed, 16 Jun 2010 15:22:30 +0200 Subject: [PATCH] * gmtime(NULL) returns NULL at least in glibc and *can not* be used as time(NULL). Since we compare two time_t values when checking the validity period this can be replaced by time(NULL) Message-ID: <1276694550-16977-1-git-send-email-nico@ngolde.de> --- openbsc/src/gsm_04_11.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/openbsc/src/gsm_04_11.c b/openbsc/src/gsm_04_11.c index ee0aba5..5a2b231 100644 --- a/openbsc/src/gsm_04_11.c +++ b/openbsc/src/gsm_04_11.c @@ -305,7 +305,7 @@ static unsigned long gsm340_vp_absolute(u_int8_t *sms_vp) unsigned long minutes; expires = gsm340_scts(sms_vp); - now = mktime(gmtime(NULL)); + now = time(NULL); if (expires <= now) minutes = 0; else -- 1.7.1 From laforge at gnumonks.org Mon Jun 21 11:51:52 2010 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 21 Jun 2010 13:51:52 +0200 Subject: [PATCH] * gmtime(NULL) returns NULL at least in glibc and *can not* be used as time(NULL). Since we compare two time_t values when checking the validity period this can be replaced by time(NULL) In-Reply-To: <1276694550-16977-1-git-send-email-nico@ngolde.de> References: <1276694550-16977-1-git-send-email-nico@ngolde.de> Message-ID: <20100621115152.GD14304@prithivi.gnumonks.org> Thanks, fix applied! -- - 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 Jun 17 08:56:41 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Thu, 17 Jun 2010 16:56:41 +0800 Subject: Request for help on the BSC API Message-ID: <4C19E349.7000307@freyther.de> Hi, I landed the first big change, the gsm48_rcvmsg is now inside the bsc_api.c. And on first msg the BSC API will call the compl_l3 (COMPLETE LAYER3) callback. This method will always be called for any new connection and is the perfect place to enable encryption.. I would be very happy if someone could take the task and change the osmo_msc.c and gsm_04_08.c to first make use of the ACCEPT/REJECT policy and then enable the auth/security on this new connection and then dispatch the original message (but CM Service Reject). Another task would be to move the Cipher Mode code into the BSC API, the gsm_04_08.c code should not directly change the attributes in the lchan and should not send the cipher mode RR message. The next thing to kill is the unconditional usage of &lchan->conn as I will start allocating the conn dynamically... (one conn can have multiple lchan's for handover and early assignment). I will now work on refcounting and moving the transaction into the subscriber connection...(some other work before) so I will probably not make it before sunday as I will be out of town. regards holger From 246tnt at gmail.com Thu Jun 17 20:47:48 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Thu, 17 Jun 2010 22:47:48 +0200 Subject: Request for help on the BSC API In-Reply-To: <4C19E349.7000307@freyther.de> References: <4C19E349.7000307@freyther.de> Message-ID: > I landed the first big change, the gsm48_rcvmsg is now inside the > bsc_api.c. And on first msg the BSC API will call the compl_l3 (COMPLETE > LAYER3) callback. This method will always be called for any new > connection and is the perfect place to enable encryption.. Looking into it, however I'm not yet sure how it will turn out because of the quirks of encryption I mentionned on IRC. Namely: - ciph mode command is implicit cm serv accept - need to extract key_seq from the various possible message - not all incoming message can trigger the auth procedure. (IMSI DETACH for example doesn't support it AFAICT) So it'll have to somehow be a three step process: - Pre-treatment of the first message (possibly the end of the treatment if nothing else supported or if it's a reject of some kind) - Run the auth/ciphering procedure (and possibly other could be plugged in, like the class mark or identity request procedure) but then again, there are interaction between those, they're not fully isolated. - Proceed with the rest of the first message (but need some feed back from the other procedure that have been run ...) I'm wondering : Can those 'initial l3 messages' sometime appear 'in the middle' of an already established channel ? > Another task would be to move the Cipher Mode code into the BSC API, the > gsm_04_08.c code should not directly change the attributes in the lchan > and should not send the cipher mode RR message. Ok, I'm on it. My current approach will be to just implement cipher related BSSMAP messages of GSM 08.08 as function calls back & forth the msc / bsc domain. This way for a real worlds msc connection, it would just need to implement the wrapping / unwrapping of those in a real SCCP/BSSMAP connection. (that's the idea if I understood the code correctly) Sylvain From bertoncello at netzing.de Thu Jun 17 14:20:42 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Thu, 17 Jun 2010 16:20:42 +0200 Subject: Problem compiling OpenBSC on Kubuntu Hardy Message-ID: <20100617162042.5f7ec17b@Luca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, List! I'm trying to compile OpenBSC (last version from GIT) on my KUbuntu Hardy (8.04). Unfortunately, I get this error: make[3]: Betrete Verzeichnis '/home/lucabert/BSC/openbsc/openbsc/src' gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I.. -Wall -I/usr/local/include/ -I/usr/local/include/ -g -O2 -MT gsm_04_11.o -MD -MP -MF .deps/gsm_04_11.Tpo -c -o gsm_04_11.o gsm_04_11.c gsm_04_11.c:357:16: Fehler: ung?ltiger Suffix ?b111? an Ganzzahlkonstante gsm_04_11.c:358:8: Fehler: ung?ltiger Suffix ?b000? an Ganzzahlkonstante gsm_04_11.c:360:8: Fehler: ung?ltiger Suffix ?b001? an Ganzzahlkonstante gsm_04_11.c:362:8: Fehler: ung?ltiger Suffix ?b010? an Ganzzahlkonstante gsm_04_11.c:364:8: Fehler: ung?ltiger Suffix ?b011? an Ganzzahlkonstante gsm_04_11.c: In Funktion ?gsm340_rx_tpdu?: gsm_04_11.c:563: Warnung: Vergleich ist durch beschr?nkten Wertebereich des Datentyps stets ?unwahr? make[3]: *** [gsm_04_11.o] Fehler 1 make[3]: Verlasse Verzeichnis '/home/lucabert/BSC/openbsc/openbsc/src' make[2]: *** [all-recursive] Fehler 1 make[2]: Verlasse Verzeichnis '/home/lucabert/BSC/openbsc/openbsc/src' make[1]: *** [all-recursive] Fehler 1 make[1]: Verlasse Verzeichnis '/home/lucabert/BSC/openbsc/openbsc' make: *** [all] Fehler 2 I see the line in gsm_04_11.c and it seems OK. What is the problem? Ubuntu Hardy uses gcc 4.2.4. Thanks a lot! - -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at netzing.de NETZING Solutions AG Tel.: 0351/41381 - 0 Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12 HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag at netzing.de _______________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFMGi88AXzltVKV/2wRAvkcAKCehGaHly78lnO1j7DXdzk72lPycgCfYVzd 9RIkN4/q3i3Es4Y0HIFLJpk= =u1eY -----END PGP SIGNATURE----- From zecke at selfish.org Thu Jun 17 14:26:26 2010 From: zecke at selfish.org (Holger Freyther) Date: Thu, 17 Jun 2010 22:26:26 +0800 Subject: Problem compiling OpenBSC on Kubuntu Hardy In-Reply-To: <20100617162042.5f7ec17b@Luca> References: <20100617162042.5f7ec17b@Luca> Message-ID: <4C1A3092.1070300@selfish.org> On 06/17/2010 10:20 PM, Luca Bertoncello wrote: > Hi, List! > > gsm_04_11.c:364:8: Fehler: ung?ltiger Suffix ?b011? an Ganzzahlkonstante Your compiler does not like to have numbers in binary, please prepare a patch (I say that once a month and then nothing happens) to use these in hex. From stefan at datenfreihafen.org Thu Jun 17 14:30:29 2010 From: stefan at datenfreihafen.org (Stefan Schmidt) Date: Thu, 17 Jun 2010 16:30:29 +0200 Subject: Problem compiling OpenBSC on Kubuntu Hardy In-Reply-To: <20100617162042.5f7ec17b@Luca> References: <20100617162042.5f7ec17b@Luca> Message-ID: <20100617143029.GC4791@excalibur.local> Hello. On Thu, 2010-06-17 at 16:20, Luca Bertoncello wrote: > > I'm trying to compile OpenBSC (last version from GIT) on my KUbuntu > Hardy (8.04). > Unfortunately, I get this error: > > make[3]: Betrete Verzeichnis '/home/lucabert/BSC/openbsc/openbsc/src' > gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I.. -Wall -I/usr/local/include/ -I/usr/local/include/ -g -O2 -MT gsm_04_11.o -MD -MP -MF .deps/gsm_04_11.Tpo -c -o gsm_04_11.o gsm_04_11.c > gsm_04_11.c:357:16: Fehler: ung?ltiger Suffix ?b111? an Ganzzahlkonstante > gsm_04_11.c:358:8: Fehler: ung?ltiger Suffix ?b000? an Ganzzahlkonstante > gsm_04_11.c:360:8: Fehler: ung?ltiger Suffix ?b001? an Ganzzahlkonstante > gsm_04_11.c:362:8: Fehler: ung?ltiger Suffix ?b010? an Ganzzahlkonstante > gsm_04_11.c:364:8: Fehler: ung?ltiger Suffix ?b011? an Ganzzahlkonstante As non-german speaker would not know what this means let me jump in here. It seems gcc gets confused with using something like 0b011 as a constant. Which is a bit strange as this is actually a gcc extension to my best knowledge to use not only decimal and hex but also bit. > gsm_04_11.c: In Funktion ?gsm340_rx_tpdu?: > gsm_04_11.c:563: Warnung: Vergleich ist durch beschr?nkten Wertebereich des Datentyps stets ?unwahr? > make[3]: *** [gsm_04_11.o] Fehler 1 > make[3]: Verlasse Verzeichnis '/home/lucabert/BSC/openbsc/openbsc/src' > make[2]: *** [all-recursive] Fehler 1 > make[2]: Verlasse Verzeichnis '/home/lucabert/BSC/openbsc/openbsc/src' > make[1]: *** [all-recursive] Fehler 1 > make[1]: Verlasse Verzeichnis '/home/lucabert/BSC/openbsc/openbsc' > make: *** [all] Fehler 2 > > I see the line in gsm_04_11.c and it seems OK. What is the problem? > Ubuntu Hardy uses gcc 4.2.4. Hmm, easiest thing to try is changing them into decimal values and see if that fixes it for you. regards Stefan Schmidt From Andreas.Eversberg at versatel.de Thu Jun 17 14:32:38 2010 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Thu, 17 Jun 2010 16:32:38 +0200 Subject: AW: Problem compiling OpenBSC on Kubuntu Hardy Message-ID: diff --git a/openbsc/src/gsm_04_11.c b/openbsc/src/gsm_04_11.c index 57d8089..faa5f69 100644 --- a/openbsc/src/gsm_04_11.c +++ b/openbsc/src/gsm_04_11.c @@ -340,14 +340,14 @@ static unsigned long gsm340_validity_period(u_int8_t sms_vpf, u_int8_t *sms_vp) /* ignore additional fi */ if (fi & (1<<7)) sms_vp++; /* read validity period format */ - switch (fi & 0b111) { - case 0b000: + switch (fi & 0x7) { + case 0x0: return gsm340_vp_default(); /* no vpf specified */ - case 0b001: + case 0x1: return gsm340_vp_relative(sms_vp); - case 0b010: + case 0x2: return gsm340_vp_relative_integer(sms_vp); - case 0b011: + case 0x3: return gsm340_vp_relative_semioctet(sms_vp); default: /* The GSM spec says that the SC should reject any ---------- -----Urspr?ngliche Nachricht----- Von: openbsc-bounces at lists.gnumonks.org [mailto:openbsc-bounces at lists.gnumonks.org] Im Auftrag von Holger Freyther Gesendet: Donnerstag, 17. Juni 2010 16:26 An: openbsc at lists.gnumonks.org Betreff: Re: Problem compiling OpenBSC on Kubuntu Hardy On 06/17/2010 10:20 PM, Luca Bertoncello wrote: > Hi, List! > > gsm_04_11.c:364:8: Fehler: ung?ltiger Suffix ?b011? an Ganzzahlkonstante Your compiler does not like to have numbers in binary, please prepare a patch (I say that once a month and then nothing happens) to use these in hex. From bertoncello at netzing.de Thu Jun 17 14:45:45 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Thu, 17 Jun 2010 16:45:45 +0200 Subject: Problem compiling OpenBSC on Kubuntu Hardy In-Reply-To: References: Message-ID: <20100617164545.503fe74b@Luca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Thu, 17 Jun 2010 16:32:38 +0200 schrieb "Andreas.Eversberg" : > diff --git a/openbsc/src/gsm_04_11.c b/openbsc/src/gsm_04_11.c > index 57d8089..faa5f69 100644 > --- a/openbsc/src/gsm_04_11.c > +++ b/openbsc/src/gsm_04_11.c > @@ -340,14 +340,14 @@ static unsigned long > gsm340_validity_period(u_int8_t sms_vpf, u_int8_t *sms_vp) /* ignore > additional fi */ if (fi & (1<<7)) sms_vp++; > /* read validity period format */ > - switch (fi & 0b111) { > - case 0b000: > + switch (fi & 0x7) { > + case 0x0: > return gsm340_vp_default(); /* no vpf > specified */ > - case 0b001: > + case 0x1: > return gsm340_vp_relative(sms_vp); > - case 0b010: > + case 0x2: > return gsm340_vp_relative_integer(sms_vp); > - case 0b011: > + case 0x3: > return gsm340_vp_relative_semioctet(sms_vp); > default: > /* The GSM spec says that the SC should > reject any ---------- It works! Thanks a lot! I hope, it will be added to the next version of OpenBSC... :D Greetings! - -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at netzing.de NETZING Solutions AG Tel.: 0351/41381 - 0 Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12 HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag at netzing.de _______________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFMGjUbAXzltVKV/2wRAgHgAJ4tByDgVi/L/X5RvXYkbFUbPkaUgwCZAU9j GvKMBy7uRAM5/FxaGfRdHT0= =PtT0 -----END PGP SIGNATURE----- From laforge at gnumonks.org Thu Jun 17 15:40:46 2010 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 17 Jun 2010 17:40:46 +0200 Subject: Problem compiling OpenBSC on Kubuntu Hardy In-Reply-To: References: Message-ID: <20100617154046.GU22244@prithivi.gnumonks.org> Thanks Andreas, I've applied your patch to master. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Fri Jun 18 05:40:10 2010 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 18 Jun 2010 07:40:10 +0200 Subject: Last openbsc version known-working for BS-11? Message-ID: <20100618054010.GE2060@prithivi.gnumonks.org> Hi! This is to all those BS-11 users out there: What was the last version (git version number preferrably) of OpenBSC that has been working fine for you? I've tried today. Everything seems to work fine from the OpenBSC side, i.e. OML and RSL are initialized. On the Air interface howerver, I can only see the carrier (RxLev) on the ARFCN go high, but the phones never get further than decoding the BSIC. They don't list the network in the network selection, and they never consider selecting this cell if it is part of a bigger network. I thought of some problem in the SYstem Information, but after checking them manually in wireshark (from the bsc_hack generated pcap file), there seems no obvious mistake. So I'm suspecting some kind of regression in current OpenBSC. Thus my question for feedback: Which version did you last use successfully with the BS-11? Thanks, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Fri Jun 18 06:28:27 2010 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 18 Jun 2010 08:28:27 +0200 Subject: Last openbsc version known-working for BS-11? In-Reply-To: <20100618054010.GE2060@prithivi.gnumonks.org> References: <20100618054010.GE2060@prithivi.gnumonks.org> Message-ID: <20100618062827.GF2060@prithivi.gnumonks.org> On Fri, Jun 18, 2010 at 07:40:10AM +0200, Harald Welte wrote: > I've tried today. Everything seems to work fine from the OpenBSC side, > i.e. OML and RSL are initialized. On the Air interface howerver, I can > only see the carrier (RxLev) on the ARFCN go high, but the phones never > get further than decoding the BSIC. They don't list the network in the > network selection, and they never consider selecting this cell if it is > part of a bigger network. > > I thought of some problem in the SYstem Information, but after checking them > manually in wireshark (from the bsc_hack generated pcap file), there seems > no obvious mistake. > > So I'm suspecting some kind of regression in current OpenBSC. Thus my > question for feedback: Which version did you last use successfully with > the BS-11? I've now looked at this with OsmocomBB, and what I get when using layer23 on the ARFCN is: Starting FCCH Recognition FB0 (9:4): TOA= 4224, Power= -47dBm, Angle= -367Hz FB1 (19:8): TOA= 9183, Power= -47dBm, Angle= -47Hz =>FB @ FNR 18 fn_offset=18 qbits=1548 Synchronize_TDMA LOST!SB1 (42:1): TOA= 29, Power= -47dBm, Angle= 65Hz => SB 0x019122fd: BSIC=63 fn=770488(581/ 4/31) qbits=24 and from that on: <000b> l1ctl.c:100 SCH: SNR: 1 TDMA: (0581/04/31) bsic: 63 <000b> l1ctl.c:158 BCCH (0581/00/02) 01 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b <000b> l1ctl.c:162 Dropping frame with 38 bit errors <000b> l1ctl.c:158 PCH/AGCH (0581/04/06) 15 06 21 00 01 00 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b <000b> l1ctl.c:162 Dropping frame with 34 bit errors <000b> l1ctl.c:158 PCH/AGCH (0581/10/12) 15 06 21 00 01 00 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b <000b> l1ctl.c:162 Dropping frame with 43 bit errors <000b> l1ctl.c:158 PCH/AGCH (0581/14/16) 15 06 21 00 01 00 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b <000b> l1ctl.c:162 Dropping frame with 45 bit errors <000b> l1ctl.c:158 BCCH (0581/25/02) 01 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b <000b> l1ctl.c:162 Dropping frame with 41 bit errors <000b> l1ctl.c:158 PCH/AGCH (0581/03/06) 15 06 21 00 01 00 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b <000b> l1ctl.c:162 Dropping frame with 51 bit errors <000b> l1ctl.c:158 PCH/AGCH (0581/09/12) 15 06 21 00 01 02 2b 2b 2b 2b 2b 2b 2b 2b b9 37 2b 2b 2b 2b 2b 2b 2b All the messages have a large number of biterrors, whether they're sent on bcch or not. The BCCH frames also seem to be set to anything to the specified SI / BCCH PAYLOAD Any ideas? -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From bertoncello at netzing.de Fri Jun 18 12:57:33 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Fri, 18 Jun 2010 14:57:33 +0200 Subject: Bug in OpenBSC? Message-ID: <20100618145733.4e5061a7@Luca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, list! I have a NanoBTS connected to my KUbuntu Hardy. I compiled the last version of OpenBSC from GIT (0.9.0.860-71d36) and it runs. Now, if I give (from Telnet) the command "sms send pending" I get in the Log the following message: <0012> db.c:157 DBI: 1: ambiguous column name: id And, if I send a "subscriber" command (extension, name, etc.) I get: <0012> db.c:157 DBI: 1: ambiguous column name: updated Maybe there are some problem with the SQL-queries? The same version on Debian lenny does not have problem. Thanks a lot! - -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at netzing.de NETZING Solutions AG Tel.: 0351/41381 - 0 Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12 HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag at netzing.de _______________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFMG20/AXzltVKV/2wRAmF6AKCTrG6E8Tw2yYN5fx1nECuv/9UYwQCgsOE0 1CMPlGxfpXa4WlEtHwa+ciA= =63FZ -----END PGP SIGNATURE----- From laforge at gnumonks.org Sun Jun 20 14:08:25 2010 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 20 Jun 2010 16:08:25 +0200 Subject: State of Frequency Hopping in OpenBSC Message-ID: <20100620140825.GE3485@prithivi.gnumonks.org> Hi! I've now merged the 'laforge/hopping' branch to master, and wanted to update you on the state of frequency hopping support: First, the bad news: It is still not working with the BS-11 :( All OML attributes that I can think of are set correctly, they have been verified from wireshark, and the BTS acknowledges all those attributes. On RSL, the channels are activated the right way, and even the SYSTEM INFORMATIO 1 (cell channel allocation) as well as the chennel description and mobile allocation parts of the IMMEDIATE ASSIGN are encoded correctly. Still, the MS and BTS fail to establish any hopping channel. Dieter is now trying to get the BS-11 hopping configuration working with his Racal 6113. If that works, the protocol trace should reveal where we still do something wrong. If you want to play with it: The BTS attributes as well as the TRX attributes are not yet 100% finished like they should be. So you need to apply the attached patch as a hack on top of master. Please note that the bs11_attr_radio_trx1 contains hard-coded ARFCN 117 and 119, i.e. you will have to modify this unless your hopping sequence also only consists of those two ARFCN. I've also attached a config file for your reference. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) -------------- next part -------------- A non-text attachment was scrubbed... Name: hopping.patch Type: text/x-diff Size: 2039 bytes Desc: not available URL: -------------- next part -------------- ! ! OpenBSC (0.9.0.845-57c4) configuration saved from vty !! password foo ! line vty no login ! network network country code 1 mobile network code 1 short name OpenBSC long name OpenBSC auth policy closed location updating reject cause 13 encryption a5 0 neci 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 0 timer t3111 0 timer t3113 60 timer t3115 0 timer t3117 0 timer t3119 0 timer t3141 0 bts 0 type bs11 band GSM900 cell_identity 0 location_area_code 1 training_sequence_code 7 base_station_id_code 63 ms max power 15 cell reselection hysteresis 4 rxlev access min 0 channel allocator descending rach tx integer 9 rach max transmission 7 oml e1 line 0 timeslot 1 sub-slot full oml e1 tei 25 gprs mode none trx 0 rf_locked 0 arfcn 121 nominal power 24 max_power_red 12 rsl e1 line 0 timeslot 1 sub-slot full rsl e1 tei 1 timeslot 0 phys_chan_config CCCH hopping enabled 0 e1 line 0 timeslot 1 sub-slot full timeslot 1 phys_chan_config TCH/F hopping enabled 0 e1 line 0 timeslot 2 sub-slot 1 timeslot 2 phys_chan_config TCH/F hopping enabled 0 e1 line 0 timeslot 2 sub-slot 2 timeslot 3 phys_chan_config TCH/F hopping enabled 0 e1 line 0 timeslot 2 sub-slot 3 timeslot 4 phys_chan_config TCH/F hopping enabled 0 e1 line 0 timeslot 3 sub-slot 0 timeslot 5 phys_chan_config TCH/F hopping enabled 0 e1 line 0 timeslot 3 sub-slot 1 timeslot 6 phys_chan_config TCH/F hopping enabled 0 e1 line 0 timeslot 3 sub-slot 2 timeslot 7 phys_chan_config TCH/F hopping enabled 0 e1 line 0 timeslot 3 sub-slot 3 trx 1 rf_locked 0 arfcn 119 nominal power 24 max_power_red 12 rsl e1 line 0 timeslot 1 sub-slot full rsl e1 tei 2 timeslot 0 phys_chan_config SDCCH8 hopping enabled 1 hopping sequence-number 0 hopping maio 0 hopping arfcn add 117 hopping arfcn add 119 timeslot 1 phys_chan_config TCH/F hopping enabled 1 hopping sequence-number 0 hopping maio 0 hopping arfcn add 117 hopping arfcn add 119 e1 line 0 timeslot 4 sub-slot 1 timeslot 2 phys_chan_config TCH/F hopping enabled 1 hopping sequence-number 0 hopping maio 0 hopping arfcn add 117 hopping arfcn add 119 e1 line 0 timeslot 4 sub-slot 2 timeslot 3 phys_chan_config TCH/F hopping enabled 1 hopping sequence-number 0 hopping maio 0 hopping arfcn add 117 hopping arfcn add 119 e1 line 0 timeslot 4 sub-slot 3 timeslot 4 phys_chan_config TCH/F hopping enabled 1 hopping sequence-number 0 hopping maio 0 hopping arfcn add 117 hopping arfcn add 119 e1 line 0 timeslot 5 sub-slot 0 timeslot 5 phys_chan_config TCH/F hopping enabled 1 hopping sequence-number 0 hopping maio 0 hopping arfcn add 117 hopping arfcn add 119 e1 line 0 timeslot 5 sub-slot 1 timeslot 6 phys_chan_config TCH/F hopping enabled 1 hopping sequence-number 0 hopping maio 0 hopping arfcn add 117 hopping arfcn add 119 e1 line 0 timeslot 5 sub-slot 2 timeslot 7 phys_chan_config TCH/F hopping enabled 1 hopping sequence-number 0 hopping maio 0 hopping arfcn add 117 hopping arfcn add 119 e1 line 0 timeslot 5 sub-slot 3 From laforge at gnumonks.org Mon Jun 21 10:24:53 2010 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 21 Jun 2010 12:24:53 +0200 Subject: RESOLVED: State of Frequency Hopping in OpenBSC In-Reply-To: <20100620140825.GE3485@prithivi.gnumonks.org> References: <20100620140825.GE3485@prithivi.gnumonks.org> Message-ID: <20100621102453.GA14304@prithivi.gnumonks.org> Hi all! As it turns out, the BTS side of the hopping was working all the time. However, the phones discarded our IMMediate ASSignment message due to an erroneous L2 Pseudo Length. This has been fixed in git commit cfa4a01c8fe2b5f2ab1bfa6fcf23c35ff5e957f4 and the hopping is working fine using the patch and config that I've sent in the last message. Please note the BS-11 does synthesizer hopping, so it can hop over any number of channels. I haven't tested more than 8, but you can definitely hop over 8 ARFCN. Only TRX1 will hop, as TRX0 needs to remain on a constant ARFCN for the CCCH/BCCH. I suggest to use 'channel allocator descending' for testing, as the BSC will then always prefer allocating channels from TRX1, even if suitable channels on TRX0 is still unused. Thanks to Dieter for verifying the BS-11 actually does hopping using his Racal 6113 analyzer, and thanks to Sylvain for his suggestion to check the L2 pseudo length. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From bertoncello at netzing.de Mon Jun 21 12:31:31 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Mon, 21 Jun 2010 14:31:31 +0200 Subject: Bug in "subscriber ... name", if name contains spaces Message-ID: <20100621143131.6f85b93b@Luca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, List! I found a bug in OpenBSC. If I try to change the name of a subscriber using Telnet (command "subscriber ... name") I got an error, if the name contains spaces (for example: first and lastname). I found the problem and I wrote a patches. I send it as attachment. Greetings - -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at netzing.de NETZING Solutions AG Tel.: 0351/41381 - 0 Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12 HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag at netzing.de _______________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFMH1ulAXzltVKV/2wRAlV9AJ9NoQUnUs9HL0d/UnExoBzfjbgZzwCeMJPy NFRpXWHlpRKMTYftSrbqehI= =b5i3 -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: nameWithSpaces.patch Type: text/x-patch Size: 965 bytes Desc: not available URL: From laforge at gnumonks.org Thu Jun 24 06:07:52 2010 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 24 Jun 2010 08:07:52 +0200 Subject: Bug in "subscriber ... name", if name contains spaces In-Reply-To: <20100621143131.6f85b93b@Luca> References: <20100621143131.6f85b93b@Luca> Message-ID: <20100624060752.GB3890@prithivi.gnumonks.org> Dear Luca, thanks for your patch. > I found a bug in OpenBSC. If I try to change the name of a subscriber > using Telnet (command "subscriber ... name") I got an error, if the > name contains spaces (for example: first and lastname). > > I found the problem and I wrote a patches. I have appllied your patch but found some problem (whcih I already fixed): > struct gsm_network *gsmnet = gsmnet_from_vty(vty); > struct gsm_subscriber *subscr = > get_subscr_by_argv(gsmnet, argv[0], argv[1]); > - const char *name = argv[2]; > + char *name; > + > + name = argv_concat(argv, argc, 2); we never check if name is NULL here > if (!subscr) { > vty_out(vty, "%% No subscriber found for %s %s%s", > @@ -410,6 +412,7 @@ DEFUN(ena_subscr_name, > } > > strncpy(subscr->name, name, sizeof(subscr->name)); > + talloc_free(name); we only free it in case subscr != NULL. If subscr == NULL, the function has already returned before we get to this free, causing a memory leak. I have now re-ordered the function slightly to fix this problem (9d4cca7) -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From bertoncello at netzing.de Mon Jun 21 13:53:37 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Mon, 21 Jun 2010 15:53:37 +0200 Subject: Location of the DB of OpenBSC Message-ID: <20100621155337.1c7c86d9@Luca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, List! OpenBSC saves his DB normally in the current directory, but I can overwrite this property with -l. Now I'd like to know WHERE OpenBSC created the DB, and what is his name. Is it possible? I searched in the telnet's commands but I found anything useful... Thanks a lot - -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at netzing.de NETZING Solutions AG Tel.: 0351/41381 - 0 Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12 HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag at netzing.de _______________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFMH27kAXzltVKV/2wRAhf5AKCTWzNChFAa+p8NfWppobxLCOU91wCcCaAd Ez8o4AvIPuC0lvrSU89sBDo= =++RV -----END PGP SIGNATURE----- From 246tnt at gmail.com Mon Jun 21 14:00:41 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Mon, 21 Jun 2010 16:00:41 +0200 Subject: Location of the DB of OpenBSC In-Reply-To: <20100621155337.1c7c86d9@Luca> References: <20100621155337.1c7c86d9@Luca> Message-ID: Hi, > OpenBSC saves his DB normally in the current directory, but I can > overwrite this property with -l. > Now I'd like to know WHERE OpenBSC created the DB, and what is his name. > Is it possible? If the process is still running, you can inspect the open file descriptors in /proc/xxx/fd or with the lsof utility. Cheers, Sylvain From bertoncello at netzing.de Mon Jun 21 14:17:31 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Mon, 21 Jun 2010 16:17:31 +0200 Subject: Location of the DB of OpenBSC In-Reply-To: References: <20100621155337.1c7c86d9@Luca> Message-ID: <20100621161731.4de6ae4e@Luca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Mon, 21 Jun 2010 16:00:41 +0200 schrieb Sylvain Munaut <246tnt at gmail.com>: > If the process is still running, you can inspect the open file > descriptors in /proc/xxx/fd or with the lsof utility. Of course, I can do it, but I hoped there is a "native method" in OpenBSC, to get this value... In bsc_hack.c I see the variable "database_name" is global. It should not be difficult to create a telnet command to inspect this value, or to give it in the output other commands (show?). Bye - -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at netzing.de NETZING Solutions AG Tel.: 0351/41381 - 0 Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12 HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag at netzing.de _______________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFMH3R+AXzltVKV/2wRAkNLAKDnUhgHxG5k03d8HD2U17Y/FvTwVgCg11MP UJt5GZX59SxHJXkUkuUiy1U= =MPOT -----END PGP SIGNATURE----- From holger at freyther.de Mon Jun 21 14:02:15 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 21 Jun 2010 22:02:15 +0800 Subject: Location of the DB of OpenBSC In-Reply-To: <20100621155337.1c7c86d9@Luca> References: <20100621155337.1c7c86d9@Luca> Message-ID: <4C1F70E7.7030107@freyther.de> On 06/21/2010 09:53 PM, Luca Bertoncello wrote: > Hi, List! > > OpenBSC saves his DB normally in the current directory, but I can > overwrite this property with -l. > Now I'd like to know WHERE OpenBSC created the DB, and what is his name. > Is it possible? > > I searched in the telnet's commands but I found anything useful... you will have to do: ls -la /proc/`pidof bsc_hack`/fd/ and find the fd for sqlite, adding a vty command for printing the databasename should not be that hard either. From jmercury313 at gmail.com Mon Jun 21 15:01:46 2010 From: jmercury313 at gmail.com (jason mercury) Date: Mon, 21 Jun 2010 18:01:46 +0300 Subject: show subscriber cache and sms send pending Message-ID: Hi to all, I couldn't use sms send pending and show subscriber cache commands of Telnet interface. Could anybody explain the functions and usage of these commands? Thanks. Jason. -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Mon Jun 21 16:11:24 2010 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 21 Jun 2010 18:11:24 +0200 Subject: show subscriber cache and sms send pending In-Reply-To: References: Message-ID: <20100621161124.GO14304@prithivi.gnumonks.org> On Mon, Jun 21, 2010 at 06:01:46PM +0300, jason mercury wrote: > Hi to all, > > I couldn't use sms send pending and show subscriber cache commands of Telnet > interface. Could anybody explain the functions and usage of these commands? 'show subscriber cache' will show you the 'gsm_subscriber' structures/records which the BSC currently holds in memory. The strategy here is: All the subscribers are stored permanently in the sqlite3 database. When we need a subscriber record, we copy it into RAM until we no longer need it (and drop it from RAM). So if you have an idle system, 'show subscriber cache' should be empty. 'sms send pending' will simply check for all pending sms in the database and deliver all pending messages to those subscribers who are currently online -- - 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 Jun 21 15:54:38 2010 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 21 Jun 2010 17:54:38 +0200 Subject: BTS initialization / OML / sequencing Message-ID: <20100621155438.GM14304@prithivi.gnumonks.org> Hi! There is a more or less common pattern going through a lot of the problems that we've been debugging recently, e.g.: * ip.access BTS OML initialization sometimes doesn't complete * BS-11 initialization problems (no BCCH content) When I started to write OpenBSC (at that time still called bs11-abis), I didn't know much about GSM 12.21 and was simply starting. As there is no explicit information in 12.21 or 08.59 on whether or not there can be multiple outstanding OML requests on one OML link, I simply assumed that I could send a number of commands without having to wait for their ACK. This made it easy to make quick progress early on in the project. However, now we are facing some problems, e.g. we send RSL messages before OML has completed its initialization. I suspect the BTSs don't like that in a number of cases. Possible solutiosn to this: 1) Always store the last OML command that we have issued and wait for an explicit ACK/NACK before sending the next one. This means all msgb's sent down by abis_nm_sendmsg() will end up in a queue which is dequeued by ACK/NACK responses before sending the next command. It's simple to implement and probably solves some of the ordering issues. However, the caller has no idea when the queued operation will actually complete (or if it will complete) 2) Implement some kind of blocking OML layer that will block the caller of abis_nm_sendmsg() until the ACK/NACK has been received. This means that writing the OML code will be much more natural, i.e. if the BTS returns an error, the OML code can deal with it at exactly the message that has caused the error. However, this would imply that OML bringup would have to spawn one thread for each BTS that is about to be brought up, as we cannot block the full BSC just because one of the BTS's is reinitialized. This would be a big difference from the existing non-blocking asynchronous single-process + single-thread model that we have, and there is probably a bit of thinking required how this would affect concurrent accesses to our data structures. As OML is fairly independent from everything else, I don't think it will be much of an issue, though. At the moment I'm slightly more inclined to actually go for '2', since it is a cleaner solution from my point of view. What do you think? 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 Tue Jun 22 01:35:32 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Tue, 22 Jun 2010 09:35:32 +0800 Subject: BTS initialization / OML / sequencing In-Reply-To: <20100621155438.GM14304@prithivi.gnumonks.org> References: <20100621155438.GM14304@prithivi.gnumonks.org> Message-ID: <4C201364.1050509@freyther.de> On 06/21/2010 11:54 PM, Harald Welte wrote: > At the moment I'm slightly more inclined to actually go for '2', since it is > a cleaner solution from my point of view. > > What do you think? The consequences for threading are big. As we can do OML and the BTS might pass away (bsc_unregister_fd) we need locking at quite some places and these include - msgb_enqueue/msgb_dequeue (or shortly before) - bsc_unregister_fd (combined with thread cancellation for the OML threads) And we would always have a OML thread per BTS? And an OML msg with 0xff, 0xff, 0xff would go to the BTS holding the BCCH? I see how the blocking semantic of an opstart and such is very appealing, we do not need to worry about the queue but the kernel will queue messages for us. From zecke at selfish.org Tue Jun 22 09:46:39 2010 From: zecke at selfish.org (Holger Freyther) Date: Tue, 22 Jun 2010 17:46:39 +0800 Subject: BTS initialization / OML / sequencing In-Reply-To: <4C201364.1050509@freyther.de> References: <20100621155438.GM14304@prithivi.gnumonks.org> <4C201364.1050509@freyther.de> Message-ID: <4C20867F.8070706@selfish.org> On 06/22/2010 09:35 AM, Holger Hans Peter Freyther wrote: > On 06/21/2010 11:54 PM, Harald Welte wrote: > > >> At the moment I'm slightly more inclined to actually go for '2', since it is >> a cleaner solution from my point of view. >> >> What do you think? > I see how the blocking semantic of an opstart and such is very > appealing, we do not need to worry about the queue but the kernel will > queue messages for us. Today I was searching for Coroutines and Tasklets for C again and wonder if we could use that, we should not rely on createcontext and such as it is not available on ARM. Another option would be to use fork and have a socketpair between OpenBSC OML and OpenBSC proper and forward OML messages in both ways. We could kill the process whenever the BTS is gone, and create it once it is up. This would also mean config changes would be handled on every BTS reconnect.. And I felt lazy and created zecke/nm-long-queue which appears to work for BTS bringup and ipaccess-config -r -o IP BTS... From 246tnt at gmail.com Tue Jun 22 05:39:01 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Tue, 22 Jun 2010 07:39:01 +0200 Subject: BTS initialization / OML / sequencing In-Reply-To: <20100621155438.GM14304@prithivi.gnumonks.org> References: <20100621155438.GM14304@prithivi.gnumonks.org> Message-ID: > At the moment I'm slightly more inclined to actually go for '2', since it is > a cleaner solution from my point of view. > > What do you think? What about things such as protothreads ? (just a thought, I never actually used them or any similar libs). Sylvain From laforge at gnumonks.org Tue Jun 22 21:31:44 2010 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 22 Jun 2010 23:31:44 +0200 Subject: BTS initialization / OML / sequencing In-Reply-To: References: <20100621155438.GM14304@prithivi.gnumonks.org> Message-ID: <20100622213144.GC10501@prithivi.gnumonks.org> Hi Sylvain, On Tue, Jun 22, 2010 at 07:39:01AM +0200, Sylvain Munaut wrote: > > At the moment I'm slightly more inclined to actually go for '2', since it is > > a cleaner solution from my point of view. > > > > What do you think? > > What about things such as protothreads ? > (just a thought, I never actually used them or any similar libs). I once did some investigation on them, but at that time decided that they wouldn't really be useful for the kind of problems we're facing in both OpenBSC and OsmocomBB. However, I don't recall the exact reason, so let me review this again... -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From 246tnt at gmail.com Tue Jun 22 22:24:53 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 23 Jun 2010 00:24:53 +0200 Subject: BTS initialization / OML / sequencing In-Reply-To: <20100622213144.GC10501@prithivi.gnumonks.org> References: <20100621155438.GM14304@prithivi.gnumonks.org> <20100622213144.GC10501@prithivi.gnumonks.org> Message-ID: > I once did some investigation on them, but at that time decided that > they wouldn't really be useful for the kind of problems we're facing > in both OpenBSC and OsmocomBB. ?However, I don't recall the exact > reason, so let me review this again... Protothreads is just an example because I didn't recall the other names, but as Holger pointed out, it's the whole tasklet / coroutines stuff that might be worth considering. One area where I could see them useful if we can make them 'transparent' enough would be the HLR were all the hlr calls could still appear as blocking in the gsm48 state machine even tough they wouldn't really be. Sylvain From laforge at gnumonks.org Mon Jun 21 16:08:51 2010 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 21 Jun 2010 18:08:51 +0200 Subject: Correctness / Sequencing / Asynchronous-ness Message-ID: <20100621160851.GN14304@prithivi.gnumonks.org> Hi! Some other 'bug' that I discovered while looking at traces recently is in RSL, where we * Send RSL ACTIVATE CHANNEL to open a channel on the BTS side * Send RR IMMEDIATE ASSIGN through the AGCH to the MS and only later receive RSL ACT CHAN ACK. This seems to work fine, since we queue the messages in-order and dequeue them in-order and simply assume the BTS will ACK. but what if it cannot activate the channel due to a hardware problem? Or what if we have a bug and try to assign the same channel twice? However, on the E1 protocol analyzer the ordering of events was reversed, i.e. the IMMEDIATE ASSIGN happened before the RSL CHAN ACT. I couldn't understand why, since we always enqueue at the end of the queue and dequeue from the front. But what I was missing: In a multi-TRX setup, the IMMEDIATE ASSIGN gets sent over the TRX0 (AGCH, part of BCCH) while the RSL CHAN ACTIVATE gets sent over TRX1. Each TRX has its own RSL link, and the TRX0 link might be ready to receive our message a bit sooner than the TRX1 link... So in this case, we send the messages in wrong order, and risk a channel assignment error. What needs to be done is to actually send the RSL CHAN ACT, save the state, wait for the CHAN ACT ACK, then transmit the IMMEDIATE ASSIGN. Similar issues might exist in other cases of channel activation, such as handover. -- - 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 Jun 22 01:27:53 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Tue, 22 Jun 2010 09:27:53 +0800 Subject: Correctness / Sequencing / Asynchronous-ness In-Reply-To: <20100621160851.GN14304@prithivi.gnumonks.org> References: <20100621160851.GN14304@prithivi.gnumonks.org> Message-ID: <4C201199.5070101@freyther.de> On 06/22/2010 12:08 AM, Harald Welte wrote: > What needs to be done is to actually send the RSL CHAN ACT, save the state, > wait for the CHAN ACT ACK, then transmit the IMMEDIATE ASSIGN. I am going to do this for the assignment and immediate assignment commands.. today/now. From zecke at selfish.org Tue Jun 22 09:43:05 2010 From: zecke at selfish.org (Holger Freyther) Date: Tue, 22 Jun 2010 17:43:05 +0800 Subject: Correctness / Sequencing / Asynchronous-ness In-Reply-To: <4C201199.5070101@freyther.de> References: <20100621160851.GN14304@prithivi.gnumonks.org> <4C201199.5070101@freyther.de> Message-ID: <4C2085A9.30501@selfish.org> On 06/22/2010 09:27 AM, Holger Hans Peter Freyther wrote: > On 06/22/2010 12:08 AM, Harald Welte wrote: > >> What needs to be done is to actually send the RSL CHAN ACT, save the state, >> wait for the CHAN ACT ACK, then transmit the IMMEDIATE ASSIGN. > > I am going to do this for the assignment and immediate assignment > commands.. today/now. I have implemented that, for the handover case and in the On-Waves branch for early assignment, we already waited for the signal ack. My understanding of GSM 08.58 so far is that it is taken for granted that the BTS will always have a ACK/NACK for requests. With this in mind I have not added an extra timer waiting for the CHANnel ACTivate ACK/NACK. I am also storing the RACH req information inside the lchan (as a pointer) and use the pointerz inside the CHAN ACT ACK handling to decide if an immediate assignment should be send. This appears to work for the two handsets I have tested it with, I took the liberty to push the change. From laforge at gnumonks.org Tue Jun 22 21:07:05 2010 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 22 Jun 2010 23:07:05 +0200 Subject: Correctness / Sequencing / Asynchronous-ness In-Reply-To: <4C2085A9.30501@selfish.org> References: <20100621160851.GN14304@prithivi.gnumonks.org> <4C201199.5070101@freyther.de> <4C2085A9.30501@selfish.org> Message-ID: <20100622210705.GB10501@prithivi.gnumonks.org> Hi Zecke, On Tue, Jun 22, 2010 at 05:43:05PM +0800, Holger Freyther wrote: > On 06/22/2010 09:27 AM, Holger Hans Peter Freyther wrote: > > On 06/22/2010 12:08 AM, Harald Welte wrote: > > > >> What needs to be done is to actually send the RSL CHAN ACT, save the state, > >> wait for the CHAN ACT ACK, then transmit the IMMEDIATE ASSIGN. > > > > I am going to do this for the assignment and immediate assignment > > commands.. today/now. > > I have implemented that, for the handover case and in the On-Waves > branch for early assignment, we already waited for the signal ack. ok, great news. > My understanding of GSM 08.58 so far is that it is taken for granted > that the BTS will always have a ACK/NACK for requests. With this in mind > I have not added an extra timer waiting for the CHANnel ACTivate > ACK/NACK. makes sense to me. > I am also storing the RACH req information inside the lchan > (as a pointer) and use the pointerz inside the CHAN ACT ACK handling to > decide if an immediate assignment should be send. sounds fine, too. Thanks! -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From mailman-bounces at lists.gnumonks.org Tue Jun 22 07:00:02 2010 From: mailman-bounces at lists.gnumonks.org (mailman-bounces at lists.gnumonks.org) Date: Tue, 22 Jun 2010 09:00:02 +0200 Subject: OpenBSC unsubscribe notification Message-ID: openbsc at walsleben.info has been removed from OpenBSC. From bertoncello at netzing.de Tue Jun 22 09:10:44 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Tue, 22 Jun 2010 11:10:44 +0200 Subject: Solving the problem "ambiguous column name" in SQL-Queries Message-ID: <20100622111044.3c19c9b7@Luca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, list! I wrote an E-Mail on 18.06.2010, asking why many errors: <0012> db.c:157 DBI: 1: ambiguous column name: id <0012> db.c:157 DBI: 1: ambiguous column name: updated appear (by sending, over Telnet, "sms send pending" and "subscriber ... name ..."). Now I decided to search in the code for a reason. There are two functions in db.c (db_sms_get_unsent_by_subscr [line 1055] and get_equipment_by_subscr [line 301]) having queries with ambiguous column name. I suggest to correct the queries, adding the table name. Unfortunately, I'm not sure, which names are correct... I think, for db_sms_get_unsent_by_subscr it should be correct so: result = dbi_conn_queryf(conn, "SELECT * FROM SMS,Subscriber " "WHERE sms.receiver_id >= %llu AND sms.sent is NULL " "AND sms.receiver_id = subscriber.id " "AND subscriber.lac > 0 " "ORDER BY sms.receiver_id, sms.id LIMIT 1", min_subscr_id); or better, using JOIN: result = dbi_conn_queryf(conn, "SELECT * FROM SMS JOIN Subscriber " "ON (SMS.received_id = Subscriber.id) " "WHERE sms.receiver_id >= %llu AND sms.sent is NULL " "AND subscriber.lac > 0 " "ORDER BY sms.receiver_id, sms.id LIMIT 1", min_subscr_id); and for get_equipment_by_subscr so: result = dbi_conn_queryf(conn, "SELECT equipment.* FROM Equipment,EquipmentWatch " "WHERE EquipmentWatch.equipment_id=Equipment.id " "AND EquipmentWatch.subscriber_id = %llu " "ORDER BY Equipment.updated DESC", subscr->id); or, with the JOIN: result = dbi_conn_queryf(conn, "SELECT equipment.* FROM Equipment JOIN EquipmentWatch " "ON (EquipmentWatch.equipment_id = Equipment.id) " "WHERE EquipmentWatch.subscriber_id = %llu " "ORDER BY Equipment.updated DESC", subscr->id); but, as I said, I'm not sure... Can someone confirm me, that I understood the queries correctly and my correction proposals are right? If they are right, I'll write a patch and submit it to the list. I think, correcting this bug is important, since the queries with this ambiguous column name will NOT be executed. Thanks a lot - -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at netzing.de NETZING Solutions AG Tel.: 0351/41381 - 0 Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12 HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag at netzing.de _______________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFMIH4WAXzltVKV/2wRAr/mAJ9cQGOgl+ZTiutmehhS1aaeFegAmgCfWDxu gUh/bQqXuK6PKdzWQ7gq6oo= =GgRb -----END PGP SIGNATURE----- From bertoncello at netzing.de Wed Jun 23 07:09:03 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Wed, 23 Jun 2010 09:09:03 +0200 Subject: [BUG REPORT]: Unable to send SMS Message-ID: <20100623090903.76b39c67@Luca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, List! It seems not possible to send SMS anymore with the yesterday's version of OpenBSC (0.9.0.889-f7a1c). I tryed with another old version (0.9.0.531-b938) and it works (same NanoBTS, same configuration). If I activate the log on Telnet I get: <0002> gsm_04_08.c:621 <- CM SERVICE REQUEST serv_type=0x04 mi_type=0x04 M(1552623826) <0012> db.c:159 DBI: 1: ambiguous column name: updated <0002> gsm_04_08.c:572 -> CM SERVICE ACK <0012> db.c:159 DBI: 1: ambiguous column name: updated <0004> abis_rsl.c:1313 RF release on (bts=0,trx=0,ts=2,ss=0) but state ACTIVE <0004> abis_rsl.c:1024 (bts=0,trx=0,ts=2,ss=0) CHAN REL ACK but state ACTIVE <0004> abis_rsl.c:1313 RF release on (bts=0,trx=0,ts=2,ss=0) but state NONE <0004> abis_rsl.c:1024 (bts=0,trx=0,ts=2,ss=0) CHAN REL ACK but state NONE on the old version, and: <0002> gsm_04_08.c:770 <- CM SERVICE REQUEST serv_type=0x04 mi_type=0x04 M(1910630704) <0002> gsm_04_08.c:695 -> CM SERVICE ACK <0004> abis_rsl.c:1350 RF release on (bts=0,trx=0,ts=2,ss=0) but state ACTIVE <0004> abis_rsl.c:1039 (bts=0,trx=0,ts=2,ss=0) CHAN REL ACK but state ACTIVE <0004> abis_rsl.c:1350 RF release on (bts=0,trx=0,ts=2,ss=0) but state NONE <0004> abis_rsl.c:1039 (bts=0,trx=0,ts=2,ss=0) CHAN REL ACK but state NONE on the new one. I see, the line 572 (or 695) in gsm_04_08.c, and it is the same function (gsm48_tx_mm_serv_ack), but with other parameters. Has someone else the same problem? How can I solve it? Thanks a lot - -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at netzing.de NETZING Solutions AG Tel.: 0351/41381 - 0 Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12 HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag at netzing.de _______________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFMIbMRAXzltVKV/2wRAufHAJ9YkFNYhEXzdNSCuNwDEJcdoICWaACg5SD8 vITTtkdXrlqbxQOHFnoBpeE= =69Za -----END PGP SIGNATURE----- From zecke at selfish.org Wed Jun 23 07:18:41 2010 From: zecke at selfish.org (Holger Freyther) Date: Wed, 23 Jun 2010 15:18:41 +0800 Subject: [BUG REPORT]: Unable to send SMS In-Reply-To: <20100623090903.76b39c67@Luca> References: <20100623090903.76b39c67@Luca> Message-ID: <4C21B551.9030106@selfish.org> On 06/23/2010 03:09 PM, Luca Bertoncello wrote: > <0002> gsm_04_08.c:621 <- CM SERVICE REQUEST serv_type=0x04 > mi_type=0x04 M(1552623826) <0012> db.c:159 DBI: 1: ambiguous column > name: updated is this noise? at least this looks like a difference to the old version... > Has someone else the same problem? How can I solve it? You could try git bisect and see which commit broke that, but I think one should understand the "new" DBI error first? Could you also give us the "old" and "new" git hashes so we can take a look at what changed? From bertoncello at netzing.de Wed Jun 23 07:35:45 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Wed, 23 Jun 2010 09:35:45 +0200 Subject: [BUG REPORT]: Unable to send SMS In-Reply-To: <4C21B551.9030106@selfish.org> References: <20100623090903.76b39c67@Luca> <4C21B551.9030106@selfish.org> Message-ID: <20100623093545.69248a19@Luca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Wed, 23 Jun 2010 15:18:41 +0800 schrieb Holger Freyther : > On 06/23/2010 03:09 PM, Luca Bertoncello wrote: > > > <0002> gsm_04_08.c:621 <- CM SERVICE REQUEST serv_type=0x04 > > mi_type=0x04 M(1552623826) <0012> db.c:159 DBI: 1: ambiguous column > > name: updated > > is this noise? at least this looks like a difference to the old > version... Do you mean "ambiguous column name: updated"? This is not noise, this is another bug. See my E-Mail on 18.06.2010 and then my solving proposal on 22.06.2010. The "new" version uses my patch (I'll send it to the list, if I'm sure it works). I tried without my patch, too (last version from git, 0.9.0.890-2788), and it does not work, too. > > Has someone else the same problem? How can I solve it? > > You could try git bisect and see which commit broke that, but I think > one should understand the "new" DBI error first? I think it, too! See my E-Mails about this problem... :D > Could you also give us the "old" and "new" git hashes so we can take a > look at what changed? Of course, but you have to say me how can I do it... I don't know git so good... :( Thanks - -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at netzing.de NETZING Solutions AG Tel.: 0351/41381 - 0 Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12 HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag at netzing.de _______________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFMIblUAXzltVKV/2wRAogCAJ9jofBq0qhmmG9ENqd/QT0CdCuRugCg0qxL hzn8q9k9Tcmp3R9Y9e6EJWQ= =CDti -----END PGP SIGNATURE----- From holger at freyther.de Wed Jun 23 08:40:35 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Wed, 23 Jun 2010 16:40:35 +0800 Subject: [BUG REPORT]: Unable to send SMS In-Reply-To: <20100623093545.69248a19@Luca> References: <20100623090903.76b39c67@Luca> <4C21B551.9030106@selfish.org> <20100623093545.69248a19@Luca> Message-ID: <4C21C883.2020205@freyther.de> On 06/23/2010 03:35 PM, Luca Bertoncello wrote: Hi Luca, I do not have a lot of spare time today. So let us please start over and collect the information you have right now. What are you doing? Please provide instructions that can be easily repeated. This should include if your phone did a successful Location Update (LU) and then what you actually tried to do. What do you expect? Well, we kind of know that. You try to send a SMS from the phone and then... well nothing... What result did you get? Well, SMS sending from the phone does not work. And then please make sure to provide the full log (e.g. start bsc_hack with -e1 and attach that in both cases) and also record a trace with tcpdump of successful and unsuccessful sending... PS:I just submitted a SMS from my N900 to an imaginary subscriber, I have the log attached... -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: openbsc.log URL: From bertoncello at netzing.de Wed Jun 23 09:08:46 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Wed, 23 Jun 2010 11:08:46 +0200 Subject: [BUG REPORT]: Unable to send SMS In-Reply-To: <4C21C883.2020205@freyther.de> References: <20100623090903.76b39c67@Luca> <4C21B551.9030106@selfish.org> <20100623093545.69248a19@Luca> <4C21C883.2020205@freyther.de> Message-ID: <20100623110846.0fa6c8fa@Luca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Wed, 23 Jun 2010 16:40:35 +0800 schrieb Holger Hans Peter Freyther : > I do not have a lot of spare time today. So let us please start over > and collect the information you have right now. > > What are you doing? > Please provide instructions that can be easily repeated. This should > include if your phone did a successful Location Update (LU) and then > what you actually tried to do. I just start the last version of OpenBSC. Two mobiles phone are logged on my network. I can call them and speak, without any problem. > What do you expect? > Well, we kind of know that. You try to send a SMS from the phone and > then... well nothing... Exactly! I send an SMS from a mobile to the other. It takes a very long time, then said me, that it was impossible to send the SMS. In the DB (table SMS) I find at least 3 SMS, with the content I tried to send. > What result did you get? > Well, SMS sending from the phone does not work. Exact! :D > And then please make sure to provide the full log (e.g. start bsc_hack > with -e1 and attach that in both cases) and also record a trace with > tcpdump of successful and unsuccessful sending... Here as Attachment the Logs of OpenBSC and TCPDump (zipped because of the size). Thanks a lot! - -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at netzing.de NETZING Solutions AG Tel.: 0351/41381 - 0 Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12 HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag at netzing.de _______________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFMIc8gAXzltVKV/2wRAoNkAJ9W8g7HNrjm6yjTzM/i79uDJXJ6mwCcDlop iCBALNMrVV0XuW/5iFpqALA= =RoF5 -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: bscSMSProblem.zip Type: application/zip Size: 21090 bytes Desc: not available URL: From holger at freyther.de Wed Jun 23 09:59:47 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Wed, 23 Jun 2010 17:59:47 +0800 Subject: [BUG REPORT]: Unable to send SMS In-Reply-To: <20100623110846.0fa6c8fa@Luca> References: <20100623090903.76b39c67@Luca> <4C21B551.9030106@selfish.org> <20100623093545.69248a19@Luca> <4C21C883.2020205@freyther.de> <20100623110846.0fa6c8fa@Luca> Message-ID: <4C21DB13.6000800@freyther.de> On 06/23/2010 05:08 PM, Luca Bertoncello wrote: > Exact! :D The easiest is to use git bisect. git bisect start -- openbsc (to limit it to that subdir) git bisect good GOOD_REVISION (the sha1 not the stuff before the hyphen) git bisect bad BAD_REVISION.. then repeat... $ make $ test_it... and then either $ git bisect good or git bisect bad... at the end git will show you the commit that introduced the problem... From bertoncello at netzing.de Wed Jun 23 12:10:40 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Wed, 23 Jun 2010 14:10:40 +0200 Subject: [BUG REPORT]: Unable to send SMS In-Reply-To: <4C21DB13.6000800@freyther.de> References: <20100623090903.76b39c67@Luca> <4C21B551.9030106@selfish.org> <20100623093545.69248a19@Luca> <4C21C883.2020205@freyther.de> <20100623110846.0fa6c8fa@Luca> <4C21DB13.6000800@freyther.de> Message-ID: <20100623141040.5fc66952@Luca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Wed, 23 Jun 2010 17:59:47 +0800 schrieb Holger Hans Peter Freyther : > On 06/23/2010 05:08 PM, Luca Bertoncello wrote: > > > Exact! :D > > The easiest is to use git bisect. > > git bisect start -- openbsc (to limit it to that subdir) > > git bisect good GOOD_REVISION (the sha1 not the stuff before the > hyphen) git bisect bad BAD_REVISION.. > > then repeat... > > $ make > $ test_it... > > and then either > $ git bisect good or git bisect bad... > > at the end git will show you the commit that introduced the problem... Hi, I don't know git. Could you please help me and say how can I get the two revision hashes? I just know the BSC version numbers. Thanks - -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at netzing.de NETZING Solutions AG Tel.: 0351/41381 - 0 Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12 HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag at netzing.de _______________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFMIfnDAXzltVKV/2wRAvXXAJ9QU3QCHkQyzlX1++n6/uA5Z1QEOACgwyZ0 sHU52E6cIua/69dIU+JsCxY= =hgNM -----END PGP SIGNATURE----- From bouchtaoui at gmail.com Wed Jun 23 12:20:56 2010 From: bouchtaoui at gmail.com (Nordin) Date: Wed, 23 Jun 2010 14:20:56 +0200 Subject: [BUG REPORT]: Unable to send SMS In-Reply-To: <20100623141040.5fc66952@Luca> References: <20100623090903.76b39c67@Luca> <4C21B551.9030106@selfish.org> <20100623093545.69248a19@Luca> <4C21C883.2020205@freyther.de> <20100623110846.0fa6c8fa@Luca> <4C21DB13.6000800@freyther.de> <20100623141040.5fc66952@Luca> Message-ID: <4C21FC28.3000400@gmail.com> > Hi, > > I don't know git. Could you please help me and say how can I get the two > revision hashes? I just know the BSC version numbers. > I recommend you to learn and experiment a bit with Git, cause it is used extensively by OpenBSC. By the way, it's a good investment to learn Git :) From bertoncello at netzing.de Wed Jun 23 12:45:39 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Wed, 23 Jun 2010 14:45:39 +0200 Subject: [BUG REPORT]: Unable to send SMS In-Reply-To: <4C21FBB0.9050600@selfish.org> References: <20100623090903.76b39c67@Luca> <4C21B551.9030106@selfish.org> <20100623093545.69248a19@Luca> <4C21C883.2020205@freyther.de> <20100623110846.0fa6c8fa@Luca> <4C21DB13.6000800@freyther.de> <20100623141040.5fc66952@Luca> <4C21FBB0.9050600@selfish.org> Message-ID: <20100623144539.2025ee38@Luca> Am Wed, 23 Jun 2010 20:18:56 +0800 schrieb Holger Freyther : > the first pointer is to the sha1/commit id[1]. So every commit has an > id, it happens to be the sha1 hash over some parts of the content. Now > git log will show all these as "commit". Now the openbsc version is > generated by the little "./git-version-gen" utility. In fact the > utility is calling "git describe" (man git-describe). > > E.g. it looks like this: > 0.9.0-891-gaf7edd9 > > 0.9.0 is the last tag we had.. > 891 is the number of commits since that tag > gaf7edd9 is the commit/sha1. This is what you want. > > I hope this helps Unfortunately not... I tried to give git-describe in the tree of the "sms-sending"-BSC (0.9.0-531-gb938d6b) and in the tree of the last version (0.9.0-890-g2788b96), then I tried to use git bisect: lucabert at Luca:/tmp/bsc/openbsc$ git bisect good gb938d6b Bad rev input: gb938d6b lucabert at Luca:/tmp/bsc/openbsc$ git bisect bad g2788b96 fatal: Needed a single revision Bad rev input: g2788b96 It seems not to work... Maybe I need vacancy? I can't understand what you suppose I can do... Thanks for your suggestion! -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at netzing.de NETZING Solutions AG Tel.: 0351/41381 - 0 Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12 HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag at netzing.de _______________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From holger at freyther.de Wed Jun 23 12:49:03 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Wed, 23 Jun 2010 20:49:03 +0800 Subject: [BUG REPORT]: Unable to send SMS In-Reply-To: <20100623144539.2025ee38@Luca> References: <20100623090903.76b39c67@Luca> <4C21B551.9030106@selfish.org> <20100623093545.69248a19@Luca> <4C21C883.2020205@freyther.de> <20100623110846.0fa6c8fa@Luca> <4C21DB13.6000800@freyther.de> <20100623141040.5fc66952@Luca> <4C21FBB0.9050600@selfish.org> <20100623144539.2025ee38@Luca> Message-ID: <4C2202BF.1010103@freyther.de> On 06/23/2010 08:45 PM, Luca Bertoncello wrote: > lucabert at Luca:/tmp/bsc/openbsc$ git bisect good gb938d6b > Bad rev input: gb938d6b > lucabert at Luca:/tmp/bsc/openbsc$ git bisect bad g2788b96 > fatal: Needed a single revision > Bad rev input: g2788b96 well, ever considered that the 'g' is not part of the hash? I didn't know that when splitting up the result of git describe. From bertoncello at netzing.de Wed Jun 23 12:59:04 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Wed, 23 Jun 2010 14:59:04 +0200 Subject: [BUG REPORT]: Unable to send SMS In-Reply-To: <4C2202BF.1010103@freyther.de> References: <20100623090903.76b39c67@Luca> <4C21B551.9030106@selfish.org> <20100623093545.69248a19@Luca> <4C21C883.2020205@freyther.de> <20100623110846.0fa6c8fa@Luca> <4C21DB13.6000800@freyther.de> <20100623141040.5fc66952@Luca> <4C21FBB0.9050600@selfish.org> <20100623144539.2025ee38@Luca> <4C2202BF.1010103@freyther.de> Message-ID: <20100623145904.0a33d1a9@Luca> Am Wed, 23 Jun 2010 20:49:03 +0800 schrieb Holger Hans Peter Freyther : > On 06/23/2010 08:45 PM, Luca Bertoncello wrote: > > > lucabert at Luca:/tmp/bsc/openbsc$ git bisect good gb938d6b > > Bad rev input: gb938d6b > > lucabert at Luca:/tmp/bsc/openbsc$ git bisect bad g2788b96 > > fatal: Needed a single revision > > Bad rev input: g2788b96 > > well, ever considered that the 'g' is not part of the hash? I didn't > know that when splitting up the result of git describe. How can I know, which letter are part of the hash? :) Anyway lucabert at Luca:/tmp/bsc/openbsc$ git bisect good b938d6b Bad rev input: b938d6b Are these "b" not part of the hash, too? Thanks -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at netzing.de NETZING Solutions AG Tel.: 0351/41381 - 0 Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12 HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag at netzing.de _______________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From 246tnt at gmail.com Wed Jun 23 13:07:02 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 23 Jun 2010 15:07:02 +0200 Subject: [BUG REPORT]: Unable to send SMS In-Reply-To: <20100623145904.0a33d1a9@Luca> References: <20100623090903.76b39c67@Luca> <4C21B551.9030106@selfish.org> <20100623093545.69248a19@Luca> <4C21C883.2020205@freyther.de> <20100623110846.0fa6c8fa@Luca> <4C21DB13.6000800@freyther.de> <20100623141040.5fc66952@Luca> <4C21FBB0.9050600@selfish.org> <20100623144539.2025ee38@Luca> <4C2202BF.1010103@freyther.de> <20100623145904.0a33d1a9@Luca> Message-ID: > How can I know, which letter are part of the hash? :) Huh ... hexadecimal ? 0-9 a-f ? > Bad rev input: b938d6b Weird, that's a valid revision in my tree. Sylvain From holger at freyther.de Wed Jun 23 13:10:17 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Wed, 23 Jun 2010 21:10:17 +0800 Subject: [BUG REPORT]: Unable to send SMS In-Reply-To: References: <20100623090903.76b39c67@Luca> <4C21B551.9030106@selfish.org> <20100623093545.69248a19@Luca> <4C21C883.2020205@freyther.de> <20100623110846.0fa6c8fa@Luca> <4C21DB13.6000800@freyther.de> <20100623141040.5fc66952@Luca> <4C21FBB0.9050600@selfish.org> <20100623144539.2025ee38@Luca> <4C2202BF.1010103@freyther.de> <20100623145904.0a33d1a9@Luca> Message-ID: <4C2207B9.9030300@freyther.de> On 06/23/2010 09:07 PM, Sylvain Munaut wrote: >> How can I know, which letter are part of the hash? :) > > Huh ... hexadecimal ? 0-9 a-f ? Well, it is always tough to deal with something new. The git-describe manpage would have been helpful here. It is separating the three parts correctly here. > >> Bad rev input: b938d6b > > Weird, that's a valid revision in my tree. here too, where do you execute the git command? From bertoncello at netzing.de Wed Jun 23 13:16:04 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Wed, 23 Jun 2010 15:16:04 +0200 Subject: [BUG REPORT]: Unable to send SMS In-Reply-To: <4C2207B9.9030300@freyther.de> References: <20100623090903.76b39c67@Luca> <4C21B551.9030106@selfish.org> <20100623093545.69248a19@Luca> <4C21C883.2020205@freyther.de> <20100623110846.0fa6c8fa@Luca> <4C21DB13.6000800@freyther.de> <20100623141040.5fc66952@Luca> <4C21FBB0.9050600@selfish.org> <20100623144539.2025ee38@Luca> <4C2202BF.1010103@freyther.de> <20100623145904.0a33d1a9@Luca> <4C2207B9.9030300@freyther.de> Message-ID: <20100623151604.009bc143@Luca> Am Wed, 23 Jun 2010 21:10:17 +0800 schrieb Holger Hans Peter Freyther : > Well, it is always tough to deal with something new. The git-describe > manpage would have been helpful here. It is separating the three parts > correctly here. > > > > >> Bad rev input: b938d6b > > > > Weird, that's a valid revision in my tree. > > here too, > > where do you execute the git command? OK, I don't understand anything more... I have two directories: ~/Desktop/bscDebian (the good one) /tmp/bsc (the bad one) Now I change to /tmp/bsc/openbsc and I give: lucabert at Luca:/tmp/bsc/openbsc$ git-describe 0.9.0-890-g2788b96 lucabert at Luca:/tmp/bsc/openbsc$ git bisect start -- openbsc lucabert at Luca:/tmp/bsc/openbsc$ git bisect good b938d6b Bad rev input: b938d6b Could you please explain me what I didn't understand? I'm feeling as a little boy at the first time he used a PC... :( Thanks -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at netzing.de NETZING Solutions AG Tel.: 0351/41381 - 0 Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12 HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag at netzing.de _______________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From holger at freyther.de Wed Jun 23 13:37:51 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Wed, 23 Jun 2010 21:37:51 +0800 Subject: [BUG REPORT]: Unable to send SMS In-Reply-To: <20100623151604.009bc143@Luca> References: <20100623090903.76b39c67@Luca> <4C21B551.9030106@selfish.org> <20100623093545.69248a19@Luca> <4C21C883.2020205@freyther.de> <20100623110846.0fa6c8fa@Luca> <4C21DB13.6000800@freyther.de> <20100623141040.5fc66952@Luca> <4C21FBB0.9050600@selfish.org> <20100623144539.2025ee38@Luca> <4C2202BF.1010103@freyther.de> <20100623145904.0a33d1a9@Luca> <4C2207B9.9030300@freyther.de> <20100623151604.009bc143@Luca> Message-ID: <4C220E2F.2070008@freyther.de> On 06/23/2010 09:16 PM, Luca Bertoncello wrote: > > Could you please explain me what I didn't understand? I'm feeling as a > little boy at the first time he used a PC... :( I am deeply sorry. I had an accidental commit and within an hour after noticing I have used git push --force to make it disappear. You must have pulled in between... This means that next time we will not use git push --force... You want to use 57da4471d1511e5456d67088e2c34b1799f08b9a as commit id which contains the same tree as the rev you tried to use before... happy bisecting PS: With git there is something called git rebase, it allows to rewrite parts of the history, and this means the checksums are changing... From bertoncello at netzing.de Mon Jun 28 08:15:58 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Mon, 28 Jun 2010 10:15:58 +0200 Subject: [BUG REPORT]: Unable to send SMS In-Reply-To: <4C220E2F.2070008@freyther.de> References: <20100623090903.76b39c67@Luca> <4C21B551.9030106@selfish.org> <20100623093545.69248a19@Luca> <4C21C883.2020205@freyther.de> <20100623110846.0fa6c8fa@Luca> <4C21DB13.6000800@freyther.de> <20100623141040.5fc66952@Luca> <4C21FBB0.9050600@selfish.org> <20100623144539.2025ee38@Luca> <4C2202BF.1010103@freyther.de> <20100623145904.0a33d1a9@Luca> <4C2207B9.9030300@freyther.de> <20100623151604.009bc143@Luca> <4C220E2F.2070008@freyther.de> Message-ID: <20100628101558.63137742@Luca> Am Wed, 23 Jun 2010 21:37:51 +0800 schrieb Holger Hans Peter Freyther : > I am deeply sorry. I had an accidental commit and within an hour after > noticing I have used git push --force to make it disappear. You must > have pulled in between... This means that next time we will not use > git push --force... > > You want to use 57da4471d1511e5456d67088e2c34b1799f08b9a as commit id > which contains the same tree as the rev you tried to use before... > > happy bisecting Hi, Holger and List! last week I didn't had time enough to search for the "bad" version. Now I did it... I "bisected" the version between the known good and the last. After 3 tries I found the version with the problem (or better: I hope!). The last known working version is: [4f8340939e631d0254c523e86e7b8be44d1dcf2c] bsc_api: Remove some more occurences of the lchan. Now these two versions have problems: [f3d8e92731dbdc05ed4214ab9ff2bbb9189f42ad] [BSC] introduce the concept of 'BTS features' With this version OpenBSC crashes when the nanoBTS boots in OpenBSC. ========================= DB: Database initialized. DB: Database prepared. <000d> input/ipaccess.c:632 accept()ed new OML link from 192.168.1.107 <0005> bsc_init.c:738 bootstrapping OML for BTS 0 <000d> input/ipaccess.c:694 accept()ed new RSL link from 192.168.1.107 <0004> bsc_init.c:924 bootstrapping RSL for BTS/TRX (0/0) on ARFCN 123 using MCC=1 MNC=1 LAC=1 CID=0 BSIC=63 TSC=7 Segmentation fault ========================= [694a5cfe062b49ac6b3a76714b3f972d3cedd620] [BSC] RSL: Fix Channel Identification IE in RSL CHAN ACT With this version it is NOT possible to send SMS anymore. Of course, I can not be sure which ob both version introduce the problem. I couldn't try the f3d8e92731dbdc05ed4214ab9ff2bbb9189f42ad. Now I need your help again. How can I restrict the problem to the file which introduce the SMS-bug? Thanks -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at netzing.de NETZING Solutions AG Tel.: 0351/41381 - 0 Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12 HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag at netzing.de _______________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bertoncello at netzing.de Mon Jun 28 12:52:56 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Mon, 28 Jun 2010 14:52:56 +0200 Subject: [BUG REPORT]: Unable to send SMS In-Reply-To: <20100628101558.63137742@Luca> References: <20100623090903.76b39c67@Luca> <4C21B551.9030106@selfish.org> <20100623093545.69248a19@Luca> <4C21C883.2020205@freyther.de> <20100623110846.0fa6c8fa@Luca> <4C21DB13.6000800@freyther.de> <20100623141040.5fc66952@Luca> <4C21FBB0.9050600@selfish.org> <20100623144539.2025ee38@Luca> <4C2202BF.1010103@freyther.de> <20100623145904.0a33d1a9@Luca> <4C2207B9.9030300@freyther.de> <20100623151604.009bc143@Luca> <4C220E2F.2070008@freyther.de> <20100628101558.63137742@Luca> Message-ID: <20100628145256.799f9d2e@Luca> Am Mon, 28 Jun 2010 10:15:58 +0200 schrieb Luca Bertoncello : > [694a5cfe062b49ac6b3a76714b3f972d3cedd620] [BSC] RSL: Fix Channel > Identification IE in RSL CHAN ACT With this version it is NOT > possible to send SMS anymore. Hi, again! I tried to search which files are modified. I can confirm, that the release 694a5cfe062b49ac6b3a76714b3f972d3cedd620 introduced the problem. I just revert the changes of this release (file abis_rsl.c, function rsl_chan_activate_lchan) and I can send SMS again. Unfortunately, I don't know yet the GSM protocol so good, and I can't find the error. I send this E-Mail to indicate the problem, and I hope the person, who introduce this change will correct the problem. Regards -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at netzing.de NETZING Solutions AG Tel.: 0351/41381 - 0 Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12 HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag at netzing.de _______________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From laforge at gnumonks.org Mon Jun 28 19:25:06 2010 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 28 Jun 2010 21:25:06 +0200 Subject: [BUG REPORT]: Unable to send SMS In-Reply-To: <20100628145256.799f9d2e@Luca> References: <4C21FBB0.9050600@selfish.org> <20100623144539.2025ee38@Luca> <4C2202BF.1010103@freyther.de> <20100623145904.0a33d1a9@Luca> <4C2207B9.9030300@freyther.de> <20100623151604.009bc143@Luca> <4C220E2F.2070008@freyther.de> <20100628101558.63137742@Luca> <20100628145256.799f9d2e@Luca> Message-ID: <20100628192506.GC2940@prithivi.gnumonks.org> Dear Luca, On Mon, Jun 28, 2010 at 02:52:56PM +0200, Luca Bertoncello wrote: > > [694a5cfe062b49ac6b3a76714b3f972d3cedd620] [BSC] RSL: Fix Channel > > Identification IE in RSL CHAN ACT With this version it is NOT > > possible to send SMS anymore. > > Hi, again! > > I tried to search which files are modified. I can confirm, that the > release 694a5cfe062b49ac6b3a76714b3f972d3cedd620 introduced the problem. > > I just revert the changes of this release (file abis_rsl.c, function > rsl_chan_activate_lchan) and I can send SMS again. > > Unfortunately, I don't know yet the GSM protocol so good, and I can't > find the error. Thanks a lot for your debugging so far. It is very helpful to get qualified bug reports. > I send this E-Mail to indicate the problem, and I hope the person, who > introduce this change will correct the problem. That would be me. What would be most helpful is two pcap files of the communication. One for the working and one for the non-working case. Specifically the RSL CHANNEL ACTIVATE meessage is most important in that pcap. I think with the pcap it will be very easy to solve the problem. And yes, I have your other mails, but the day only has 24 hours, sorry... -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From bertoncello at netzing.de Tue Jun 29 06:51:42 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Tue, 29 Jun 2010 08:51:42 +0200 Subject: [BUG REPORT]: Unable to send SMS In-Reply-To: <20100628192506.GC2940@prithivi.gnumonks.org> References: <4C21FBB0.9050600@selfish.org> <20100623144539.2025ee38@Luca> <4C2202BF.1010103@freyther.de> <20100623145904.0a33d1a9@Luca> <4C2207B9.9030300@freyther.de> <20100623151604.009bc143@Luca> <4C220E2F.2070008@freyther.de> <20100628101558.63137742@Luca> <20100628145256.799f9d2e@Luca> <20100628192506.GC2940@prithivi.gnumonks.org> Message-ID: <20100629085142.7e8c0d2c@Luca> Am Mon, 28 Jun 2010 21:25:06 +0200 schrieb Harald Welte : > What would be most helpful is two pcap files of the communication. > One for the working and one for the non-working case. > > Specifically the RSL CHANNEL ACTIVATE meessage is most important in > that pcap. > > I think with the pcap it will be very easy to solve the problem. OK! I send you two TCPDump files. The first (lastWorkingVersion.log) refers to the last know working version (4f8340939e631d0254c523e86e7b8be44d1dcf2c), the second (firstNotWorkingVersion.log) refers to the first know NOT working version (694a5cfe062b49ac6b3a76714b3f972d3cedd620). As I said, between these version there is another (f3d8e92731dbdc05ed4214ab9ff2bbb9189f42ad) that crashes by starting the communication with the nanoBTS. > And yes, I have your other mails, but the day only has 24 hours, > sorry... I know... I tried to order a couple of hour for my days, but these are undeliverable... :D Bye -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at netzing.de NETZING Solutions AG Tel.: 0351/41381 - 0 Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12 HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag at netzing.de _______________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: lastWorkingVersion.log Type: text/x-log Size: 40676 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: firstNotWorkingVersion.log Type: text/x-log Size: 34248 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From laforge at gnumonks.org Tue Jun 29 09:08:28 2010 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 29 Jun 2010 11:08:28 +0200 Subject: [BUG REPORT]: Unable to send SMS In-Reply-To: <20100629085142.7e8c0d2c@Luca> References: <4C2202BF.1010103@freyther.de> <20100623145904.0a33d1a9@Luca> <4C2207B9.9030300@freyther.de> <20100623151604.009bc143@Luca> <4C220E2F.2070008@freyther.de> <20100628101558.63137742@Luca> <20100628145256.799f9d2e@Luca> <20100628192506.GC2940@prithivi.gnumonks.org> <20100629085142.7e8c0d2c@Luca> Message-ID: <20100629090828.GK2940@prithivi.gnumonks.org> Hi Luca, On Tue, Jun 29, 2010 at 08:51:42AM +0200, Luca Bertoncello wrote: > > What would be most helpful is two pcap files of the communication. > > One for the working and one for the non-working case. > > > > Specifically the RSL CHANNEL ACTIVATE meessage is most important in > > that pcap. > > > > I think with the pcap it will be very easy to solve the problem. > > OK! I send you two TCPDump files. The first (lastWorkingVersion.log) Sorry, we really need pcap files, not the stdout of tcpdump (which you have sent). You can create them using something like "tcpdump -w file.name -s 0 -i eth0" Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From bertoncello at netzing.de Tue Jun 29 11:35:00 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Tue, 29 Jun 2010 13:35:00 +0200 Subject: [BUG REPORT]: Unable to send SMS In-Reply-To: <20100629090828.GK2940@prithivi.gnumonks.org> References: <4C2202BF.1010103@freyther.de> <20100623145904.0a33d1a9@Luca> <4C2207B9.9030300@freyther.de> <20100623151604.009bc143@Luca> <4C220E2F.2070008@freyther.de> <20100628101558.63137742@Luca> <20100628145256.799f9d2e@Luca> <20100628192506.GC2940@prithivi.gnumonks.org> <20100629085142.7e8c0d2c@Luca> <20100629090828.GK2940@prithivi.gnumonks.org> Message-ID: <20100629133500.09611d72@Luca> Am Tue, 29 Jun 2010 11:08:28 +0200 schrieb Harald Welte : > Sorry, we really need pcap files, not the stdout of tcpdump (which > you have sent). You can create them using something like "tcpdump -w > file.name -s 0 -i eth0" Ops! Here there are! Thanks -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at netzing.de NETZING Solutions AG Tel.: 0351/41381 - 0 Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12 HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag at netzing.de _______________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: firstNotWorking.pcap Type: application/octet-stream Size: 64187 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: lastWorking.pcap Type: application/octet-stream Size: 17129 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From laforge at gnumonks.org Tue Jun 29 15:55:31 2010 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 29 Jun 2010 17:55:31 +0200 Subject: [BUG REPORT]: Unable to send SMS In-Reply-To: <20100628145256.799f9d2e@Luca> References: <4C21FBB0.9050600@selfish.org> <20100623144539.2025ee38@Luca> <4C2202BF.1010103@freyther.de> <20100623145904.0a33d1a9@Luca> <4C2207B9.9030300@freyther.de> <20100623151604.009bc143@Luca> <4C220E2F.2070008@freyther.de> <20100628101558.63137742@Luca> <20100628145256.799f9d2e@Luca> Message-ID: <20100629155531.GA17995@prithivi.gnumonks.org> Luca, thanks for the pcap files. On Mon, Jun 28, 2010 at 02:52:56PM +0200, Luca Bertoncello wrote: > Am Mon, 28 Jun 2010 10:15:58 +0200 > schrieb Luca Bertoncello : > > > [694a5cfe062b49ac6b3a76714b3f972d3cedd620] [BSC] RSL: Fix Channel > > Identification IE in RSL CHAN ACT With this version it is NOT > > possible to send SMS anymore. > > Hi, again! > > I tried to search which files are modified. I can confirm, that the > release 694a5cfe062b49ac6b3a76714b3f972d3cedd620 introduced the problem. It is really strange to understand how this relates to the bug you have seen, but indeed we were doing something wrong with regard to the RSL channel activation. I've fixed that now, feel free to see if 93d50e69d37b3e3bd5cd41967705b8645cfefdec fixes your problem. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From bertoncello at netzing.de Wed Jun 30 06:30:01 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Wed, 30 Jun 2010 08:30:01 +0200 Subject: [BUG REPORT]: Unable to send SMS In-Reply-To: <20100629155531.GA17995@prithivi.gnumonks.org> References: <4C21FBB0.9050600@selfish.org> <20100623144539.2025ee38@Luca> <4C2202BF.1010103@freyther.de> <20100623145904.0a33d1a9@Luca> <4C2207B9.9030300@freyther.de> <20100623151604.009bc143@Luca> <4C220E2F.2070008@freyther.de> <20100628101558.63137742@Luca> <20100628145256.799f9d2e@Luca> <20100629155531.GA17995@prithivi.gnumonks.org> Message-ID: <20100630083001.18b01a57@Luca> Am Tue, 29 Jun 2010 17:55:31 +0200 schrieb Harald Welte : > It is really strange to understand how this relates to the bug you > have seen, but indeed we were doing something wrong with regard to > the RSL channel activation. I've fixed that now, feel free to see if > 93d50e69d37b3e3bd5cd41967705b8645cfefdec fixes your problem. Hi, Harald! I installed the last version of OpenBSC. Unfortunately it does not work... Bye -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at netzing.de NETZING Solutions AG Tel.: 0351/41381 - 0 Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12 HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag at netzing.de _______________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From holger at freyther.de Wed Jun 30 07:21:04 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Wed, 30 Jun 2010 15:21:04 +0800 Subject: [BUG REPORT]: Unable to send SMS In-Reply-To: <20100630083001.18b01a57@Luca> References: <4C21FBB0.9050600@selfish.org> <20100623144539.2025ee38@Luca> <4C2202BF.1010103@freyther.de> <20100623145904.0a33d1a9@Luca> <4C2207B9.9030300@freyther.de> <20100623151604.009bc143@Luca> <4C220E2F.2070008@freyther.de> <20100628101558.63137742@Luca> <20100628145256.799f9d2e@Luca> <20100629155531.GA17995@prithivi.gnumonks.org> <20100630083001.18b01a57@Luca> Message-ID: <4C2AF060.1090602@freyther.de> On 06/30/2010 02:30 PM, Luca Bertoncello wrote: > Hi, Harald! > > I installed the last version of OpenBSC. Unfortunately it does not > work... Hi, could you at least try revision 0379c6d386? And it would be nice to know which version you have tested and how it failed? SMS Sending didn't work? or were you seeing floods of NACK messages and processing failures? From bertoncello at netzing.de Wed Jun 30 07:25:28 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Wed, 30 Jun 2010 09:25:28 +0200 Subject: [BUG REPORT]: Unable to send SMS In-Reply-To: <4C2AF060.1090602@freyther.de> References: <4C21FBB0.9050600@selfish.org> <20100623144539.2025ee38@Luca> <4C2202BF.1010103@freyther.de> <20100623145904.0a33d1a9@Luca> <4C2207B9.9030300@freyther.de> <20100623151604.009bc143@Luca> <4C220E2F.2070008@freyther.de> <20100628101558.63137742@Luca> <20100628145256.799f9d2e@Luca> <20100629155531.GA17995@prithivi.gnumonks.org> <20100630083001.18b01a57@Luca> <4C2AF060.1090602@freyther.de> Message-ID: <20100630092528.1cb58e3d@Luca> Am Wed, 30 Jun 2010 15:21:04 +0800 schrieb Holger Hans Peter Freyther : > could you at least try revision 0379c6d386? And it would be nice to How can I install a revision? I searched in the man pages of git, but I didn't found any command to install a specific revision... :( > know which version you have tested and how it failed? SMS Sending > didn't work? or were you seeing floods of NACK messages and > processing failures? The problem is always the same, I described in my E-Mails. I tried to install the last version of OpenBSC (git clone ...), because Harald said, he applied a patch. Thanks -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at netzing.de NETZING Solutions AG Tel.: 0351/41381 - 0 Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12 HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag at netzing.de _______________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From laforge at gnumonks.org Wed Jun 30 16:00:10 2010 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 30 Jun 2010 18:00:10 +0200 Subject: [BUG REPORT]: Unable to send SMS In-Reply-To: <20100630092528.1cb58e3d@Luca> References: <4C2207B9.9030300@freyther.de> <20100623151604.009bc143@Luca> <4C220E2F.2070008@freyther.de> <20100628101558.63137742@Luca> <20100628145256.799f9d2e@Luca> <20100629155531.GA17995@prithivi.gnumonks.org> <20100630083001.18b01a57@Luca> <4C2AF060.1090602@freyther.de> <20100630092528.1cb58e3d@Luca> Message-ID: <20100630160010.GR4876@prithivi.gnumonks.org> On Wed, Jun 30, 2010 at 09:25:28AM +0200, Luca Bertoncello wrote: > Am Wed, 30 Jun 2010 15:21:04 +0800 > schrieb Holger Hans Peter Freyther : > > > could you at least try revision 0379c6d386? And it would be nice to > > How can I install a revision? I searched in the man pages of git, but I > didn't found any command to install a specific revision... :( Using git you always clone a repository, i.e. you have all versions installed at the same time. you can then switch using commands like "git checkout 0379c6d386" "git checkout master" (goes back to the current version). I strongly suggest reading some git tutorial, there are a number of them available online. > > know which version you have tested and how it failed? SMS Sending > > didn't work? or were you seeing floods of NACK messages and > > processing failures? > > The problem is always the same, I described in my E-Mails. > I tried to install the last version of OpenBSC (git clone ...), because > Harald said, he applied a patch. Neither Holger nor I can reproduce your problem, so we are a bit stuck here. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From 246tnt at gmail.com Wed Jun 23 07:46:32 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 23 Jun 2010 09:46:32 +0200 Subject: [BUG REPORT]: Unable to send SMS In-Reply-To: <4C21B551.9030106@selfish.org> References: <20100623090903.76b39c67@Luca> <4C21B551.9030106@selfish.org> Message-ID: > You could try git bisect and see which commit broke that, but I think > one should understand the "new" DBI error first? From bertoncello at netzing.de Wed Jun 23 07:53:10 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Wed, 23 Jun 2010 09:53:10 +0200 Subject: [BUG REPORT]: Unable to send SMS In-Reply-To: References: <20100623090903.76b39c67@Luca> <4C21B551.9030106@selfish.org> Message-ID: <20100623095310.0d869abd@Luca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Wed, 23 Jun 2010 09:46:32 +0200 schrieb Sylvain Munaut <246tnt at gmail.com>: > > You could try git bisect and see which commit broke that, but I > > think one should understand the "new" DBI error first? > > From the original message I thought those error were in the old one > but not the new. Just because, in the new version, I applied a patch from mine, to correct this error (just added a table name to the column names)... > But in any case, the OP can fix the sql. The OP seem to have a > new/more picky version of sqlite. Before in case of ambiguous column > name, it took the one from the first table in the FROM list. (not sql > standard but that's why it didn't matter before). I know, it is NOT SQL-standard. And this is the reason, because I get this error. But I think, the program should use syntactically correct SQL-queries, to avoid these problems. I'll send my patch in a separated E-Mail (I hope today). > > Could you also give us the "old" and "new" git hashes so we can > > take a look at what changed? > > The hash (short) are in the version string, the log is : > > git log b938..f7a1c Aha! Then I sent it already! The old version, the "sms sending version", is 531-b938, and the new, the "non sms sending version", 889-f7a1c. Thanks - -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at netzing.de NETZING Solutions AG Tel.: 0351/41381 - 0 Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12 HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag at netzing.de _______________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFMIb1oAXzltVKV/2wRAhwhAKCoSFzEi6ZP+QisWP1rce4u5k3VvACg5nnb ajh0ciRccoEJi7HSqzEUa0E= =R+OJ -----END PGP SIGNATURE----- From bertoncello at netzing.de Wed Jun 23 07:57:05 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Wed, 23 Jun 2010 09:57:05 +0200 Subject: Measuring signal Message-ID: <20100623095705.2d1ad2c6@Luca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, again! I have another question, and this is: how can I measure the distance of a mobile from a BTS? I'm reading the book "Die GSM-Dm-Kan?le im Dialog" by Joachim G?ller, and I learned, that a mobile phone sends, about every second, a MEASUREMENT REPORT to the station, where it is logged. In this report the mobile sends the signal power of the cell, where it is logged, and of other neighborhood cells. With these signals, I can measure the distance of the mobile from my cell(s). But I don't understand how can I get this values using OpenBSC. Can someone explain me how can I do this? Thanks a lot! - -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at netzing.de NETZING Solutions AG Tel.: 0351/41381 - 0 Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12 HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag at netzing.de _______________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFMIb5RAXzltVKV/2wRAv4zAKDpdHjed/uWweDtoknOaaHIOZlB1QCgtkhs 2jxsdaR/Y2ZmHdT1Nh/mVVY= =9tWf -----END PGP SIGNATURE----- From 246tnt at gmail.com Wed Jun 23 08:06:26 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 23 Jun 2010 10:06:26 +0200 Subject: Measuring signal In-Reply-To: References: <20100623095705.2d1ad2c6@Luca> Message-ID: Hi, > I'm reading the book "Die GSM-Dm-Kan?le im Dialog" by Joachim G?ller, > and I learned, that a mobile phone sends, about every second, a > MEASUREMENT REPORT to the station, where it is logged. > In this report the mobile sends the signal power of the cell, where > it is logged, and of other neighborhood cells. > With these signals, I can measure the distance of the mobile from my > cell(s). > > But I don't understand how can I get this values using OpenBSC. It only does that when in an active dedicated channel (either a call or a sms or some other transaction). If you enable the debug for the DMEAS (either in the console or with the -d option), you should see those reports. Also, it sends reports only for neighbor cell of your network (as specified in the BCCH SI messages). Cheers, ? ?Sylvain From bertoncello at netzing.de Wed Jun 23 08:24:35 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Wed, 23 Jun 2010 10:24:35 +0200 Subject: Measuring signal In-Reply-To: References: <20100623095705.2d1ad2c6@Luca> Message-ID: <20100623102435.41d4a2bf@Luca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Wed, 23 Jun 2010 10:06:26 +0200 schrieb Sylvain Munaut <246tnt at gmail.com>: > It only does that when in an active dedicated channel (either a call > or a sms or some other transaction). > If you enable the debug for the DMEAS (either in the console or with > the -d option), you should see those reports. > > Also, it sends reports only for neighbor cell of your network (as > specified in the BCCH SI messages). Hi, Sylvain! Thanks a lot for your answer! Now I see the measurement. I'll make some experiments... :D Greetings - -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at netzing.de NETZING Solutions AG Tel.: 0351/41381 - 0 Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12 HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag at netzing.de _______________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFMIcTFAXzltVKV/2wRAsQ2AJ9xAwU6bSk81OOTzzuGrzdCQXzKSACePv67 uo/er4c3R6Jt/Gfx2HjcsRs= =EPfY -----END PGP SIGNATURE----- From bertoncello at netzing.de Wed Jun 23 08:43:32 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Wed, 23 Jun 2010 10:43:32 +0200 Subject: Measuring signal In-Reply-To: References: <20100623095705.2d1ad2c6@Luca> Message-ID: <20100623104332.23851a0e@Luca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Wed, 23 Jun 2010 10:06:26 +0200 schrieb Sylvain Munaut <246tnt at gmail.com>: > It only does that when in an active dedicated channel (either a call > or a sms or some other transaction). > If you enable the debug for the DMEAS (either in the console or with > the -d option), you should see those reports. > > Also, it sends reports only for neighbor cell of your network (as > specified in the BCCH SI messages). Hi, again! I tried to activate the DMEAS ("logging level meas everything" on Telnet), and to call a mobile phone. Now I have the problem, that I get TWO measurement reports... How can I filter the reports of just ONE mobile? Thanks a lot - -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at netzing.de NETZING Solutions AG Tel.: 0351/41381 - 0 Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12 HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag at netzing.de _______________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFMIck2AXzltVKV/2wRAr/VAJ9uf8P7BkErrom8NJeiq+oTHeAh3ACeLOKz nrXlW9jmyN+uQS84aK+hTW8= =Axht -----END PGP SIGNATURE----- From holger at freyther.de Wed Jun 23 09:02:53 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Wed, 23 Jun 2010 17:02:53 +0800 Subject: Measuring signal In-Reply-To: <20100623104332.23851a0e@Luca> References: <20100623095705.2d1ad2c6@Luca> <20100623104332.23851a0e@Luca> Message-ID: <4C21CDBD.7040607@freyther.de> On 06/23/2010 04:43 PM, Luca Bertoncello wrote: > I tried to activate the DMEAS ("logging level meas everything" on > Telnet), and to call a mobile phone. > Now I have the problem, that I get TWO measurement reports... > How can I filter the reports of just ONE mobile? You can try to set an imsi filter on the log: "logging filter imsi IMSI" From bertoncello at netzing.de Wed Jun 23 09:31:19 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Wed, 23 Jun 2010 11:31:19 +0200 Subject: Measuring signal In-Reply-To: <4C21CDBD.7040607@freyther.de> References: <20100623095705.2d1ad2c6@Luca> <20100623104332.23851a0e@Luca> <4C21CDBD.7040607@freyther.de> Message-ID: <20100623113119.24716708@Luca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Wed, 23 Jun 2010 17:02:53 +0800 schrieb Holger Hans Peter Freyther : > You can try to set an imsi filter on the log: > > "logging filter imsi IMSI" Unfortunately it does not work... If I just give "logging filter imsi XXX" OpenBSC logs nothing. I have to give "logging filter all 1", too, and then both measurements will be sent. These looks like this: ========================== <0009> abis_rsl.c:881 MEASUREMENT RESULT NR=0 RXL-FULL-ul=-110dBm RXL-SUB-ul=-110dBm RXQ-FULL-ul=5 RXQ-SUB-ul=0 BS_POWER=0 NOT VALID NUM_NEIGH=0 <0009> abis_rsl.c:881 MEASUREMENT RESULT NR=1 RXL-FULL-ul=-62dBm RXL-SUB-ul=-63dBm RXQ-FULL-ul=6 RXQ-SUB-ul=7 BS_POWER=0 NOT VALID NUM_NEIGH=0 <0009> abis_rsl.c:881 MEASUREMENT RESULT NR=2 RXL-FULL-ul=-47dBm RXL-SUB-ul=-47dBm RXQ-FULL-ul=3 RXQ-SUB-ul=2 BS_POWER=0 L1_MS_PWR= 5dBm L1_FPC=0 L1_TA=0 NOT VALID NUM_NEIGH=7 <0009> abis_rsl.c:881 MEASUREMENT RESULT NR=3 RXL-FULL-ul=-47dBm RXL-SUB-ul=-47dBm RXQ-FULL-ul=0 RXQ-SUB-ul=0 BS_POWER=0 L1_MS_PWR= 5dBm L1_FPC=0 L1_TA=0 RXL-FULL-dl=-47dBm RXL-SUB-dl=-47dBm RXQ-FULL-dl=4 RXQ-SUB-dl=0 NUM_NEIGH=7 <0009> abis_rsl.c:881 MEASUREMENT RESULT NR=4 RXL-FULL-ul=-47dBm RXL-SUB-ul=-47dBm RXQ-FULL-ul=0 RXQ-SUB-ul=0 BS_POWER=0 L1_MS_PWR= 5dBm L1_FPC=0 L1_TA=0 RXL-FULL-dl=-47dBm RXL-SUB-dl=-47dBm RXQ-FULL-dl=4 RXQ-SUB-dl=0 NUM_NEIGH=7 <0009> abis_rsl.c:881 MEASUREMENT RESULT NR=5 RXL-FULL-ul=-47dBm RXL-SUB-ul=-47dBm RXQ-FULL-ul=0 RXQ-SUB-ul=0 BS_POWER=0 L1_MS_PWR= 5dBm L1_FPC=0 L1_TA=0 RXL-FULL-dl=-47dBm RXL-SUB-dl=-47dBm RXQ-FULL-dl=4 RXQ-SUB-dl=0 NUM_NEIGH=7 <0009> abis_rsl.c:881 MEASUREMENT RESULT NR=6 RXL-FULL-ul=-47dBm RXL-SUB-ul=-47dBm RXQ-FULL-ul=0 RXQ-SUB-ul=0 BS_POWER=0 L1_MS_PWR= 5dBm L1_FPC=0 L1_TA=0 RXL-FULL-dl=-47dBm RXL-SUB-dl=-47dBm RXQ-FULL-dl=4 RXQ-SUB-dl=0 NUM_NEIGH=7 <0009> abis_rsl.c:881 MEASUREMENT RESULT NR=7 RXL-FULL-ul=-47dBm RXL-SUB-ul=-47dBm RXQ-FULL-ul=0 RXQ-SUB-ul=0 BS_POWER=0 L1_MS_PWR= 5dBm L1_FPC=0 L1_TA=0 RXL-FULL-dl=-47dBm RXL-SUB-dl=-47dBm RXQ-FULL-dl=4 RXQ-SUB-dl=0 NUM_NEIGH=7 <0009> abis_rsl.c:881 MEASUREMENT RESULT NR=8 RXL-FULL-ul=-47dBm RXL-SUB-ul=-47dBm RXQ-FULL-ul=0 RXQ-SUB-ul=0 BS_POWER=0 L1_MS_PWR= 5dBm L1_FPC=0 L1_TA=0 RXL-FULL-dl=-47dBm RXL-SUB-dl=-47dBm RXQ-FULL-dl=4 RXQ-SUB-dl=0 NUM_NEIGH=7 <0009> abis_rsl.c:881 MEASUREMENT RESULT NR=0 RXL-FULL-ul=-88dBm RXL-SUB-ul=-102dBm RXQ-FULL-ul=6 RXQ-SUB-ul=0 BS_POWER=0 NOT VALID NUM_NEIGH=0 <0009> abis_rsl.c:881 MEASUREMENT RESULT NR=9 RXL-FULL-ul=-47dBm RXL-SUB-ul=-47dBm RXQ-FULL-ul=0 RXQ-SUB-ul=0 BS_POWER=0 L1_MS_PWR= 5dBm L1_FPC=0 L1_TA=0 RXL-FULL-dl=-47dBm RXL-SUB-dl=-47dBm RXQ-FULL-dl=4 RXQ-SUB-dl=0 NUM_NEIGH=7 <0009> abis_rsl.c:881 MEASUREMENT RESULT NR=1 RXL-FULL-ul=-47dBm RXL-SUB-ul=-47dBm RXQ-FULL-ul=2 RXQ-SUB-ul=2 BS_POWER=0 L1_MS_PWR= 5dBm L1_FPC=0 L1_TA=0 DTXu NOT VALID NUM_NEIGH=7 <0009> abis_rsl.c:881 MEASUREMENT RESULT NR=10 RXL-FULL-ul=-47dBm RXL-SUB-ul=-47dBm RXQ-FULL-ul=0 RXQ-SUB-ul=0 BS_POWER=0 L1_MS_PWR= 5dBm L1_FPC=0 L1_TA=0 RXL-FULL-dl=-47dBm RXL-SUB-dl=-47dBm RXQ-FULL-dl=4 RXQ-SUB-dl=0 NUM_NEIGH=7 ========================== If it is possible to filter (using an external program) which measurements come from a mobile, it is not a problem for me, but here I can't see any useful pattern... Any idea? - -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at netzing.de NETZING Solutions AG Tel.: 0351/41381 - 0 Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12 HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag at netzing.de _______________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFMIdRpAXzltVKV/2wRAk87AKC1wHoTPxmslzHZdgpboNcpNN/nbACg47T5 fGcquYsVu8TS15g2yFNV1Rw= =sNt+ -----END PGP SIGNATURE----- From holger at freyther.de Wed Jun 23 09:50:19 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Wed, 23 Jun 2010 17:50:19 +0800 Subject: Measuring signal In-Reply-To: <20100623113119.24716708@Luca> References: <20100623095705.2d1ad2c6@Luca> <20100623104332.23851a0e@Luca> <4C21CDBD.7040607@freyther.de> <20100623113119.24716708@Luca> Message-ID: <4C21D8DB.4010201@freyther.de> On 06/23/2010 05:31 PM, Luca Bertoncello wrote: > Am Wed, 23 Jun 2010 17:02:53 +0800 > schrieb Holger Hans Peter Freyther : > >> You can try to set an imsi filter on the log: > >> "logging filter imsi IMSI" > > Unfortunately it does not work... > If I just give "logging filter imsi XXX" OpenBSC logs nothing. > I have to give "logging filter all 1", too, and then both > measurements will be sent. Well, look at src/debug.c and figure out why the imsi comparison is failing? From bertoncello at netzing.de Wed Jun 23 10:01:08 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Wed, 23 Jun 2010 12:01:08 +0200 Subject: Measuring signal In-Reply-To: <4C21D8DB.4010201@freyther.de> References: <20100623095705.2d1ad2c6@Luca> <20100623104332.23851a0e@Luca> <4C21CDBD.7040607@freyther.de> <20100623113119.24716708@Luca> <4C21D8DB.4010201@freyther.de> Message-ID: <20100623120108.0c61995a@Luca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Wed, 23 Jun 2010 17:50:19 +0800 schrieb Holger Hans Peter Freyther : > > Unfortunately it does not work... > > If I just give "logging filter imsi XXX" OpenBSC logs nothing. > > I have to give "logging filter all 1", too, and then both > > measurements will be sent. > > Well, > look at src/debug.c and figure out why the imsi comparison is failing? I'm looking now this code. But I can't understand the reason... I can only suppose, that in this Measurement Report the IMSI will not be sent. Thanks - -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at netzing.de NETZING Solutions AG Tel.: 0351/41381 - 0 Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12 HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag at netzing.de _______________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFMIdtmAXzltVKV/2wRAvXkAKC8Jo6mrma/JypwF58CsMWNg+slmgCeJrua ba+TNhg5vcTAogWS38nKdGU= =DT2R -----END PGP SIGNATURE----- From holger at freyther.de Wed Jun 23 10:13:44 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Wed, 23 Jun 2010 18:13:44 +0800 Subject: Measuring signal In-Reply-To: <20100623120108.0c61995a@Luca> References: <20100623095705.2d1ad2c6@Luca> <20100623104332.23851a0e@Luca> <4C21CDBD.7040607@freyther.de> <20100623113119.24716708@Luca> <4C21D8DB.4010201@freyther.de> <20100623120108.0c61995a@Luca> Message-ID: <4C21DE58.1070808@freyther.de> On 06/23/2010 06:01 PM, Luca Bertoncello wrote: > Am Wed, 23 Jun 2010 17:50:19 +0800 > schrieb Holger Hans Peter Freyther : > >>> Unfortunately it does not work... >>> If I just give "logging filter imsi XXX" OpenBSC logs nothing. >>> I have to give "logging filter all 1", too, and then both >>> measurements will be sent. > >> Well, >> look at src/debug.c and figure out why the imsi comparison is failing? > > I'm looking now this code. But I can't understand the reason... > I can only suppose, that in this Measurement Report the IMSI will not > be sent. if ((tar->filter_map & (1 << FLT_IMSI)) != 0 && subscr && strcmp(subscr->imsi, tar->filter_data[FLT_IMSI]) == 0) return 1; the above does not evaluate to true... this can be: a) because the filter function is not called at all.. b) tar->filter_map & .. is == 0 c) subscr is NULL d) the imsi's do not match.. Okay, after wanting to explain how the filtering is working, I remembered that I did this: 69e8f8285bf080ad2050fbc20f861bc8621e5c75 (git show that-number). You could git revert that-number and then try again. So in the case of the measurement report the subscr is not set as context as the measurement debug is still in the abis_rsl context before it is hitting the BSC side... From bertoncello at netzing.de Wed Jun 23 11:35:12 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Wed, 23 Jun 2010 13:35:12 +0200 Subject: Measuring signal In-Reply-To: <4C21DE58.1070808@freyther.de> References: <20100623095705.2d1ad2c6@Luca> <20100623104332.23851a0e@Luca> <4C21CDBD.7040607@freyther.de> <20100623113119.24716708@Luca> <4C21D8DB.4010201@freyther.de> <20100623120108.0c61995a@Luca> <4C21DE58.1070808@freyther.de> Message-ID: <20100623133512.6730e544@Luca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Wed, 23 Jun 2010 18:13:44 +0800 schrieb Holger Hans Peter Freyther : > if ((tar->filter_map & (1 << FLT_IMSI)) != 0 && subscr && > strcmp(subscr->imsi, tar->filter_data[FLT_IMSI]) == 0) > return 1; > > the above does not evaluate to true... this can be: > > a) because the filter function is not called at all.. > b) tar->filter_map & .. is == 0 > c) subscr is NULL > d) the imsi's do not match.. > > Okay, after wanting to explain how the filtering is working, I > remembered that I did this: 69e8f8285bf080ad2050fbc20f861bc8621e5c75 > (git show that-number). You could git revert that-number and then try > again. > > So in the case of the measurement report the subscr is not set as > context as the measurement debug is still in the abis_rsl context > before it is hitting the BSC side... Hi, Holger! After I revert your changes, I can filter the measurements using IMSI. I suggest, your changes will committed back in the source tree... Thanks a lot! - -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at netzing.de NETZING Solutions AG Tel.: 0351/41381 - 0 Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12 HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag at netzing.de _______________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFMIfFyAXzltVKV/2wRAqnWAKC35jyN59SbGdwPxrE6+ZGqxjvkvQCfQzwN BB4pQozB+3qiwX0NwEGTZlk= =fsCY -----END PGP SIGNATURE----- From holger at freyther.de Wed Jun 23 11:42:29 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Wed, 23 Jun 2010 19:42:29 +0800 Subject: Measuring signal In-Reply-To: <20100623133512.6730e544@Luca> References: <20100623095705.2d1ad2c6@Luca> <20100623104332.23851a0e@Luca> <4C21CDBD.7040607@freyther.de> <20100623113119.24716708@Luca> <4C21D8DB.4010201@freyther.de> <20100623120108.0c61995a@Luca> <4C21DE58.1070808@freyther.de> <20100623133512.6730e544@Luca> Message-ID: <4C21F325.6000706@freyther.de> On 06/23/2010 07:35 PM, Luca Bertoncello wrote: > Hi, Holger! > > After I revert your changes, I can filter the measurements using IMSI. > I suggest, your changes will committed back in the source tree... Well, the printing should move up to the MSC side of OpenBSC.. specially as the conn will become a pointer that may be null. Nevertheless I will revert the change for now. From bertoncello at netzing.de Wed Jun 23 09:48:12 2010 From: bertoncello at netzing.de (Luca Bertoncello) Date: Wed, 23 Jun 2010 11:48:12 +0200 Subject: [PATCH] Solving problem of "ambiguous column name" Message-ID: <20100623114812.3dc66121@Luca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, List! As I promise, here my patch, to solve the problem I explained on 18.06.2010. I'm now sure, my patch is NOT responsible of the problem sending SMS, then I'd like to submit it to the list. Greetings - -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at netzing.de NETZING Solutions AG Tel.: 0351/41381 - 0 Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12 HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag at netzing.de _______________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFMIdheAXzltVKV/2wRAnhaAJ96NdDGLzdAxvn6e1XV8uF8Xf62mACgqbPp AD8uCeWjX/poI/fycmE0R1Y= =+3SS -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: sqlProblems.patch Type: text/x-patch Size: 1298 bytes Desc: not available URL: From mortzy at gmail.com Fri Jun 25 16:46:09 2010 From: mortzy at gmail.com (Stephen Mortimer) Date: Fri, 25 Jun 2010 17:46:09 +0100 Subject: Working GSM1800 config for latest OpenBSC Message-ID: I have a ip.access nanoBTS (version 165AU9012)v(37) and have been using it with a very early version of OpenBSC (OpenBSC 0.01) and am now trying to upgrade to the latest version downloaded from GIT (OpenBSC version 0.9.0.565-993d). When I use the configuration that works on the old version, with this latest version, I get the following error: user at ubuntu:~/openbsc/src$ ./bsc_hack <0005> bsc_init.c:1024 WARNING: You are running an 'accept-all' network on a BTS that is not barred. This configuration is likely to interfere with production GSM networks and should only be used in a RF shielded environment such as a faraday cage! <0005> bsc_init.c:1024 WARNING: You are running an 'accept-all' network on a BTS that is not barred. This configuration is likely to interfere with production GSM networks and should only be used in a RF shielded environment such as a faraday cage! DB: Database initialized. DB: Database prepared. <000d> input/ipaccess.c:632 accept()ed new OML link from 192.168.2.3 <000d> input/ipaccess.c:477 no matching signalling link for hh->proto=0xff <000d> input/ipaccess.c:477 no matching signalling link for hh->proto=0xff <000d> input/ipaccess.c:477 no matching signalling link for hh->proto=0xff Can anyone explain why I get this error and maybe send me a config that would work? -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Fri Jun 25 21:39:20 2010 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 25 Jun 2010 23:39:20 +0200 Subject: Working GSM1800 config for latest OpenBSC In-Reply-To: References: Message-ID: <20100625213920.GV3890@prithivi.gnumonks.org> Hi Stephen, On Fri, Jun 25, 2010 at 05:46:09PM +0100, Stephen Mortimer wrote: > DB: Database initialized. > DB: Database prepared. > <000d> input/ipaccess.c:632 accept()ed new OML link from 192.168.2.3 > <000d> input/ipaccess.c:477 no matching signalling link for hh->proto=0xff > <000d> input/ipaccess.c:477 no matching signalling link for hh->proto=0xff > <000d> input/ipaccess.c:477 no matching signalling link for hh->proto=0xff it sounds like you are missing an ' oml ip.access stream_id 255' at the 'bts 0' level of your config. -- - 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 Sat Jun 26 01:28:46 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sat, 26 Jun 2010 09:28:46 +0800 Subject: Working GSM1800 config for latest OpenBSC In-Reply-To: References: Message-ID: <4C2557CE.9050501@freyther.de> On 06/26/2010 12:46 AM, Stephen Mortimer wrote: > <000d> input/ipaccess.c:632 accept()ed new OML link from 192.168.2.3 > <000d> input/ipaccess.c:477 no matching signalling link for hh->proto=0xff > <000d> input/ipaccess.c:477 no matching signalling link for hh->proto=0xff > <000d> input/ipaccess.c:477 no matching signalling link for hh->proto=0xff oml ip.access stream_id 255 do you have such a line or not? > Can anyone explain why I get this error and maybe send me a config that > would work? Well, send your config and we say what is wrong with it. There are two working nanoBTS configs inside the repository... From mortzy at gmail.com Mon Jun 28 13:32:16 2010 From: mortzy at gmail.com (Stephen Mortimer) Date: Mon, 28 Jun 2010 14:32:16 +0100 Subject: Fwd: Working GSM1800 config for latest OpenBSC In-Reply-To: <4C2557CE.9050501@freyther.de> References: <4C2557CE.9050501@freyther.de> Message-ID: Thanks Peter, Harald, I have checked my config and I have the line you both mention. Please find attached a copy of the config I am trying to get working. I would much appreciate your help in checking what needs adding/removing. Many thanks, Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: openbsc.cfg Type: application/octet-stream Size: 1216 bytes Desc: not available URL: From 246tnt at gmail.com Mon Jun 28 15:39:59 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Mon, 28 Jun 2010 17:39:59 +0200 Subject: Working GSM1800 config for latest OpenBSC In-Reply-To: References: <4C2557CE.9050501@freyther.de> Message-ID: Try removing --- oml ip.access stream_id 255 oml e1 line 0 timeslot 1 sub-slot full oml e1 tei 25 rsl e1 line 0 timeslot 1 sub-slot full rsl e1 tei 1 --- and all the --- e1 line 0 timeslot ? sub-slot ??? --- My latest config doesn't have any 'e1' config left and it works fine. Sylvain From benny at benny.de Fri Jun 25 18:58:20 2010 From: benny at benny.de (Benjamin Hagemann) Date: Fri, 25 Jun 2010 20:58:20 +0200 Subject: GSM video lectures (en) Message-ID: <20100625185820.GL21419@quelle.benny.de> Hello, I found some english lectures about communication by university Freiburg (germany) as video: http://itunes.uni-freiburg.de/uebersicht/podcast_content?id_content=48 e.g. Protocols and technologies of telephone networks ISDN network functions, introduction to GSM digital mobile Extension of GSM overview GSM data services UTMS as the world wide 3G mobile standard You can watch it online as flash or download a .mp4 file :) -- regards, Benny gpg 0xFC505AB0 jabber benny at benny.de sip benny at benny.de -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From r.zahoransky at gmx.de Sun Jun 27 14:33:47 2010 From: r.zahoransky at gmx.de (Richard M. Zahoransky) Date: Sun, 27 Jun 2010 16:33:47 +0200 Subject: Segmentation fault while sending sms via bsc_hack_VTY Message-ID: <4C27614B.1000703@gmx.de> Hello, We have a working OpenBSC-LCR-Asterisk setup by now. Sending SMS from one cell phone to another works perfectly after typing "sms send pending" in the vty-console. Is it always needed to trigger the sms-sending manually or is there a fixed intervall in which sms will be transfered? Still a problem exists. If we try to send a sms directly from the bsc_hack_vty with "subscriber extension xxx sms send "TEXT"", the bsc_hack crashes: <0008> paging.c:225 Start paging of subscriber 36 on bts 0. <0008> paging.c:225 Start paging of subscriber 36 on bts 1. <0008> paging.c:87 Going to send paging commands: imsi: '262012840035907' tmsi: '0x79d38c8e' <0008> paging.c:87 Going to send paging commands: imsi: '262012840035907' tmsi: '0x79d38c8e' <0008> paging.c:87 Going to send paging commands: imsi: '262012840035907' tmsi: '0x79d38c8e' <0008> paging.c:87 Going to send paging commands: imsi: '262012840035907' tmsi: '0x79d38c8e' <0004> abis_rsl.c:1165 (bts=0,trx=0,ts=0,ss=0) Activating ARFCN(871) SS(0) lctype SDCCH r=LOCATION_UPDATE ra=0x15 <0004> abis_rsl.c:969 (bts=0,trx=0,ts=0,ss=0) CHANNEL ACTIVATE ACK <0009> abis_rsl.c:831 MEASUREMENT RESULT NR=0 RXL-FULL-ul=-108dBm RXL-SUB-ul=-108dBm RXQ-FULL-ul=6 RXQ-SUB-ul=6 BS_POWER=0 NOT VALID NUM_NEIGH=0 <0005> abis_nm.c:519 OC=BASEBAND TRANSCEIVER(04) INST=(00,00,ff) Failure Event Report Type=processing failure Severity=warning level failure <0000> abis_rsl.c:1276 (bts=0,trx=0,ts=0,ss=0) SAPI=0 ESTABLISH INDICATION <0003> gsm_04_08.c:799 PAGING RESPONSE: mi_type=0x04 MI(2043907214) <0003> gsm_04_08.c:817 <- Channel was requested by 262012840035907 <0008> paging.c:289 Stop paging on bts 0, calling cbfn. <0007> gsm_04_11.c:1151 paging_cb_send_sms(hooknum=1, event=0, msg=(nil),lchan=0x85365d8, sms=0x859cd58) <0008> paging.c:293 Stop paging on bts 1 silently. <0009> abis_rsl.c:831 MEASUREMENT RESULT NR=1 RXL-FULL-ul=-47dBm RXL-SUB-ul=-47dBm RXQ-FULL-ul=6 RXQ-SUB-ul=6 BS_POWER=0 L1_MS_PWR= 2dBm L1_FPC=0 L1_TA=0 NOT VALID NUM_NEIGH=0 <0000> abis_rsl.c:1276 (bts=0,trx=0,ts=0,ss=0) SAPI=0 DATA INDICATION <0003> gsm_04_08.c:835 CLASSMARK CHANGE CM2(len=3) CM3(len=2) <0009> abis_rsl.c:831 MEASUREMENT RESULT NR=2 RXL-FULL-ul=-47dBm RXL-SUB-ul=-47dBm RXQ-FULL-ul=0 RXQ-SUB-ul=0 BS_POWER=0 L1_MS_PWR= 2dBm L1_FPC=0 L1_TA=0 RXL-FULL-dl=-47dBm RXL-SUB-dl=-47dBm RXQ-FULL-dl=7 RXQ-SUB-dl=3 NUM_NEIGH=1 <0009> abis_rsl.c:863 IDX=0 ARFCN=877 BSIC=63 => -56 dBm <0000> abis_rsl.c:1276 (bts=0,trx=0,ts=0,ss=0) SAPI=3 ESTABLISH CONFIRM <0007> gsm_04_11.c:1125 rll_ind_cb(lchan=0x85365d8, link_id=3, sms=0x859cd58, type=0 <0007> gsm_04_11.c:1057 send_sms_lchan() <0001> transaction.c:69 subscr=0x859cb98, subscr->net=0x8533960 Program received signal SIGSEGV, Segmentation fault. 0x003a4785 in ?? () from /lib/tls/i686/cmov/libc.so.6 gdb bt prints out: Program received signal SIGSEGV, Segmentation fault. 0x003a4785 in ?? () from /lib/tls/i686/cmov/libc.so.6 (gdb) bt #0 0x003a4785 in ?? () from /lib/tls/i686/cmov/libc.so.6 #1 0x001729e9 in gsm48_encode_bcd_number (bcd_lv=0xbffff130 "", max_len=12 '\f', h_len=1, input=0xa6
) at gsm48_ie.c:83 #2 0x080d137d in gsm340_gen_oa (conn=0x8536990, sms=0x8592f90) at gsm_04_11.c:423 #3 gsm340_gen_tpdu (conn=0x8536990, sms=0x8592f90) at gsm_04_11.c:461 #4 gsm411_send_sms_lchan (conn=0x8536990, sms=0x8592f90) at gsm_04_11.c:1096 #5 0x080bfe2f in complete_rllr (rllr=0x8592f18, type=BSC_RLLR_IND_EST_CONF) at bsc_rll.c:59 #6 0x080b7238 in abis_rsl_rx_rll (msg=0x8591db8) at abis_rsl.c:1303 #7 abis_rsl_rcvmsg (msg=0x8591db8) at abis_rsl.c:1728 #8 0x080c3c8a in handle_ts1_read (bfd=0x858550c, what=) at input/ipaccess.c:489 #9 ipaccess_fd_cb (bfd=0x858550c, what=) at input/ipaccess.c:597 #10 0x0016f925 in bsc_select_main (polling=1) at select.c:119 #11 0x08050289 in handle_gsm_bs () at gsm_bs.cpp:864 #12 0x08084343 in main (argc=2, argv=0xbffff884) at main.c:472 Maybe someone expirienced the same problems or can provide some help? Best Regards and Thank you, Richard Zahoransky From holger at freyther.de Mon Jun 28 01:15:11 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 28 Jun 2010 09:15:11 +0800 Subject: Segmentation fault while sending sms via bsc_hack_VTY In-Reply-To: <4C27614B.1000703@gmx.de> References: <4C27614B.1000703@gmx.de> Message-ID: <4C27F79F.1030500@freyther.de> On 06/27/2010 10:33 PM, Richard M. Zahoransky wrote: > Hello, > Still a problem exists. If we try to send a sms directly from the > bsc_hack_vty with "subscriber extension xxx sms send "TEXT"", the > bsc_hack crashes: Could you try two things? One is to build with OpenBSC with -O0 (either by passing CFLAGS on configure or changing the Makefile) and then run OpenBSC with valgrind and report the line number. Looking at the backtrace you have provided I wonder if input=0xa6 is the indicator of the problem or just an issue with gdb and optimized code.. From holger at freyther.de Mon Jun 28 03:10:48 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 28 Jun 2010 11:10:48 +0800 Subject: Segmentation fault while sending sms via bsc_hack_VTY In-Reply-To: <4C27614B.1000703@gmx.de> References: <4C27614B.1000703@gmx.de> Message-ID: <4C2812B8.4010008@freyther.de> On 06/27/2010 10:33 PM, Richard M. Zahoransky wrote: > #3 gsm340_gen_tpdu (conn=0x8536990, sms=0x8592f90) at gsm_04_11.c:461 > #4 gsm411_send_sms_lchan (conn=0x8536990, sms=0x8592f90) at > gsm_04_11.c:1096 > #5 0x080bfe2f in complete_rllr (rllr=0x8592f18, > type=BSC_RLLR_IND_EST_CONF) at bsc_rll.c:59 On second look, this seems to be a week or two old OpenBSC? is that true? Would it be a lot of work to test the latest version of OpenBSC? If you are lucky you are hitting a bug here that applies to the pre BSC/MSC split as well: 280c768f910c29d19a605b9f8e2961fe92832dd1 From r.zahoransky at gmx.de Tue Jun 29 19:59:11 2010 From: r.zahoransky at gmx.de (Richard Zahoransky) Date: Tue, 29 Jun 2010 21:59:11 +0200 Subject: Segmentation fault while sending sms via bsc_hack_VTY Message-ID: <20100629195911.203310@gmx.net> > Date: Mon, 28 Jun 2010 09:15:11 +0800 > From: Holger Hans Peter Freyther > To: openbsc at lists.gnumonks.org > Re: Segmentation fault while sending sms via bsc_hack_VTY > Could you try two things? One is to build with OpenBSC with -O0 (either > by passing CFLAGS on configure or changing the Makefile) and then run > OpenBSC with valgrind and report the line number. > On second look, this seems to be a week or two old OpenBSC? is that > true? Would it be a lot of work to test the latest version of OpenBSC? the new version does not seem to build correct. Make prints out: sgsn_libgtp.c: In function ?sgsn_create_pdp_ctx?: sgsn_libgtp.c:117: error: ?struct pdp_t? has no member named ?priv? sgsn_libgtp.c: In function ?cb_data_ind?: sgsn_libgtp.c:373: error: ?struct pdp_t? has no member named ?priv? sgsn_libgtp.c:396: warning: assignment makes pointer from integer without a cast maybe this could be because I have installed openggsn? anyway, when using make -k (and ./coonfigure CFLAGS="-O0"), bsc_hack builds and starts. Still it "crashes" when I try to send SMS from the bsc_hack_vty. There is no segmantation fault, but this: <0008> paging.c:130 No slots available on bts nr 1 <0008> paging.c:130 No slots available on bts nr 0 and <0004> abis_rsl.c:831 (bts=1,trx=0,ts=0,ss=0) CHANNEL ACTIVATE NACKCAUSE=0x6f(Protocol error, unspecified) <0011> handover_logic.c:197 unable to find HO record it repeats (endlessly?) Valgrind reports: ==26461== Invalid read of size 4 ==26461== at 0x806DA60: subscr_paging_cb (linuxlist.h:163) ==26461== by 0x806EE46: paging_T3113_expired (paging.c:209) ==26461== by 0x403D3EF: bsc_update_timers (timer.c:160) ==26461== by 0x403D8F6: bsc_select_main (select.c:94) ==26461== by 0x804BC75: main (bsc_hack.c:271) ==26461== Address 0x4731120 is 432 bytes inside a block of size 440 free'd ==26461== at 0x4024B3A: free (vg_replace_malloc.c:366) ==26461== by 0x40471AF: talloc_free (talloc.c:610) ==26461== by 0x806DD34: subscr_put (gsm_subscriber_base.c:133) ==26461== by 0x806E9F5: paging_remove_request (paging.c:77) ==26461== by 0x806EE02: paging_T3113_expired (paging.c:204) ==26461== by 0x403D3EF: bsc_update_timers (timer.c:160) ==26461== by 0x403D8F6: bsc_select_main (select.c:94) ==26461== by 0x804BC75: main (bsc_hack.c:271) ==26461== and ==26524== Syscall param ioctl(TCSET{S,SW,SF}) points to uninitialised byte(s) ==26524== at 0x4431A5F: tcsetattr (tcsetattr.c:88) ==26524== by 0x4069865: vty_create (vty.c:1399) ==26524== by 0x406A289: telnet_new_connection (telnet_interface.c:167) ==26524== by 0x403D924: bsc_select_main (select.c:119) ==26524== by 0x804BC75: main (bsc_hack.c:271) ==26524== Address 0xbefa82c8 is on thread 1's stack ==26524== ==26524== Use of uninitialised value of size 4 ==26524== at 0x43A9288: _itoa_word (_itoa.c:196) ==26524== by 0x43ACAE1: vfprintf (vfprintf.c:1613) ==26524== by 0x444DBF3: __vsnprintf_chk (vsnprintf_chk.c:65) ==26524== by 0x444DB13: __snprintf_chk (snprintf_chk.c:36) ==26524== by 0x40417E4: hexdump (stdio2.h:65) ==26524== by 0x8072538: ipaccess_fd_cb (ipaccess.c:566) ==26524== by 0x403D924: bsc_select_main (select.c:119) ==26524== by 0x804BC75: main (bsc_hack.c:271) ==26524== ==26524== Syscall param socketcall.send(msg) points to uninitialised byte(s) ==26524== at 0x443BE78: send (socket.S:100) ==26524== by 0x403D924: bsc_select_main (select.c:119) ==26524== by 0x804BC75: main (bsc_hack.c:271) ==26524== Address 0x4736d9d is 261 bytes inside a block of size 1,140 alloc'd ==26524== at 0x4024F20: malloc (vg_replace_malloc.c:236) ==26524== by 0x4045291: _talloc_zero (talloc.c:355) ==26524== by 0x403DD66: msgb_alloc (msgb.c:37) ==26524== by 0x8061FF9: rsl_msgb_alloc (msgb.h:159) ==26524== by 0x806436E: rsl_chan_activate_lchan (abis_rsl.c:443) ==26524== by 0x80653D0: abis_rsl_rcvmsg (abis_rsl.c:1228) ==26524== by 0x80725F9: ipaccess_fd_cb (ipaccess.c:489) ==26524== by 0x403D924: bsc_select_main (select.c:119) ==26524== by 0x804BC75: main (bsc_hack.c:271) ==26524== Best Regards, Richard From holger at freyther.de Wed Jun 30 01:16:25 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Wed, 30 Jun 2010 09:16:25 +0800 Subject: Segmentation fault while sending sms via bsc_hack_VTY In-Reply-To: <20100629195911.203310@gmx.net> References: <20100629195911.203310@gmx.net> Message-ID: <4C2A9AE9.8070405@freyther.de> On 06/30/2010 03:59 AM, Richard Zahoransky wrote:\ Hi, thanks a lot for starting to debug this. Could you help me a bit with your test setup? Which type of BTS do you use? Could you get us a pcap file for the Channel Activate NACK? > maybe this could be because I have installed openggsn? Sound likely, I would guess you need to update libgtp.. > ==26461== Invalid read of size 4 > ==26461== at 0x806DA60: subscr_paging_cb (linuxlist.h:163) > ==26461== by 0x806EE46: paging_T3113_expired (paging.c:209) > ==26461== by 0x403D3EF: bsc_update_timers (timer.c:160) > ==26461== by 0x403D8F6: bsc_select_main (select.c:94) > ==26461== by 0x804BC75: main (bsc_hack.c:271) > ==26461== Address 0x4731120 is 432 bytes inside a block of size 440 free'd > ==26461== at 0x4024B3A: free (vg_replace_malloc.c:366) > ==26461== by 0x40471AF: talloc_free (talloc.c:610) > ==26461== by 0x806DD34: subscr_put (gsm_subscriber_base.c:133) > ==26461== by 0x806E9F5: paging_remove_request (paging.c:77) > ==26461== by 0x806EE02: paging_T3113_expired (paging.c:204) > ==26461== by 0x403D3EF: bsc_update_timers (timer.c:160) > ==26461== by 0x403D8F6: bsc_select_main (select.c:94) > ==26461== by 0x804BC75: main (bsc_hack.c:271) Thank's a lot. So the ingredient I was missing for my test was the failing paging request. I am using code from subscr_get_channel which is not adding a subscr_get/subscr_put... so the callback param points to a deleted subscriber. > ==26524== Use of uninitialised value of size 4 > ==26524== at 0x43A9288: _itoa_word (_itoa.c:196) > ==26524== by 0x43ACAE1: vfprintf (vfprintf.c:1613) > ==26524== by 0x444DBF3: __vsnprintf_chk (vsnprintf_chk.c:65) > ==26524== by 0x444DB13: __snprintf_chk (snprintf_chk.c:36) > ==26524== by 0x40417E4: hexdump (stdio2.h:65) > ==26524== by 0x8072538: ipaccess_fd_cb (ipaccess.c:566) > ==26524== by 0x403D924: bsc_select_main (select.c:119) > ==26524== by 0x804BC75: main (bsc_hack.c:271) > ==26524== > ==26524== Syscall param socketcall.send(msg) points to uninitialised byte(s) > ==26524== at 0x443BE78: send (socket.S:100) > ==26524== by 0x403D924: bsc_select_main (select.c:119) > ==26524== by 0x804BC75: main (bsc_hack.c:271) > ==26524== Address 0x4736d9d is 261 bytes inside a block of size 1,140 alloc'd > ==26524== at 0x4024F20: malloc (vg_replace_malloc.c:236) > ==26524== by 0x4045291: _talloc_zero (talloc.c:355) > ==26524== by 0x403DD66: msgb_alloc (msgb.c:37) > ==26524== by 0x8061FF9: rsl_msgb_alloc (msgb.h:159) > ==26524== by 0x806436E: rsl_chan_activate_lchan (abis_rsl.c:443) > ==26524== by 0x80653D0: abis_rsl_rcvmsg (abis_rsl.c:1228) > ==26524== by 0x80725F9: ipaccess_fd_cb (ipaccess.c:489) > ==26524== by 0x403D924: bsc_select_main (select.c:119) > ==26524== by 0x804BC75: main (bsc_hack.c:271) > ==26524== These two are new as well.... for the last it is either me or harald... doing it wrong. I will poke it a bit. From holger at freyther.de Wed Jun 30 01:50:11 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Wed, 30 Jun 2010 09:50:11 +0800 Subject: Segmentation fault while sending sms via bsc_hack_VTY In-Reply-To: <4C2A9AE9.8070405@freyther.de> References: <20100629195911.203310@gmx.net> <4C2A9AE9.8070405@freyther.de> Message-ID: <4C2AA2D3.8030706@freyther.de> On 06/30/2010 09:16 AM, Holger Hans Peter Freyther wrote: by 0x804BC75: main (bsc_hack.c:271) > > Thank's a lot. So the ingredient I was missing for my test was the > failing paging request. I am using code from subscr_get_channel which is > not adding a subscr_get/subscr_put... so the callback param points to a > deleted subscriber. I should have fixed the SMS crash and will push it in a second.... >> ==26524== by 0x403D924: bsc_select_main (select.c:119) >> ==26524== by 0x804BC75: main (bsc_hack.c:271) >> ==26524== > > These two are new as well.... for the last it is either me or harald... > doing it wrong. I will poke it a bit. The flood of Channel Activate NACKs and the Processing Failures (you didn't mention them) are due Harald's latest change in the channel activate, weird enough we still have the same valgrind error in them... I will debug this issue a bit more.. From holger at freyther.de Wed Jun 30 04:10:20 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Wed, 30 Jun 2010 12:10:20 +0800 Subject: Segmentation fault while sending sms via bsc_hack_VTY In-Reply-To: <4C2AA2D3.8030706@freyther.de> References: <20100629195911.203310@gmx.net> <4C2A9AE9.8070405@freyther.de> <4C2AA2D3.8030706@freyther.de> Message-ID: <4C2AC3AC.4070909@freyther.de> On 06/30/2010 09:50 AM, Holger Hans Peter Freyther wrote: > > The flood of Channel Activate NACKs and the Processing Failures (you > didn't mention them) are due Harald's latest change in the channel > activate, weird enough we still have the same valgrind error in them... Hi, I think I have fixed this for good now. I calculate the length based on how much we have stored in the msgb, so it will be always correct (as long as we store thingsn correctly), I have also added a memset to make valgrind happy, and checked if we would need more of that for the gsm48_chand_desc (but we don't). The only open issue is... I think we do not need to add the MA at all... at least that is my impression after reading the GSM 08.58 doc about the Channel Identification. please confirm that both the SMS crash and the NACKs are resolved. thanks From laforge at gnumonks.org Wed Jun 30 06:49:55 2010 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 30 Jun 2010 08:49:55 +0200 Subject: Segmentation fault while sending sms via bsc_hack_VTY In-Reply-To: <4C2AC3AC.4070909@freyther.de> References: <20100629195911.203310@gmx.net> <4C2A9AE9.8070405@freyther.de> <4C2AA2D3.8030706@freyther.de> <4C2AC3AC.4070909@freyther.de> Message-ID: <20100630064955.GB18916@prithivi.gnumonks.org> Hi Zecke, thanks for fixing the remaining issue, On Wed, Jun 30, 2010 at 12:10:20PM +0800, Holger Hans Peter Freyther wrote: > The only open issue is... I think we do not need to add the MA at all... > at least that is my impression after reading the GSM 08.58 doc about the > Channel Identification. The protocol traces I have for the Siemens BS-11 include the MA in hopping configurations, so this is why I decided to add them, too. I am not really sure which Phase the BS-11 implements - and if it is Phase 1, then the MA would still be required. -- - 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 Jun 30 07:07:12 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Wed, 30 Jun 2010 15:07:12 +0800 Subject: Segmentation fault while sending sms via bsc_hack_VTY In-Reply-To: <20100630064955.GB18916@prithivi.gnumonks.org> References: <20100629195911.203310@gmx.net> <4C2A9AE9.8070405@freyther.de> <4C2AA2D3.8030706@freyther.de> <4C2AC3AC.4070909@freyther.de> <20100630064955.GB18916@prithivi.gnumonks.org> Message-ID: <4C2AED20.5050609@freyther.de> On 06/30/2010 02:49 PM, Harald Welte wrote: > The protocol traces I have for the Siemens BS-11 include the MA in hopping > configurations, so this is why I decided to add them, too. I am not really > sure which Phase the BS-11 implements - and if it is Phase 1, then the MA > would still be required. Hi LaF0rge, this is the weird part. The whole Channel Identification is only needed for Phase1, and my copy of GSM 08.58 claims that MA should be present but have a size of zero. It looks like we will need Nibbler's Phase1 phone and check if we need that or not. :) From r.zahoransky at gmx.de Wed Jun 30 14:55:54 2010 From: r.zahoransky at gmx.de (Richard Zahoransky) Date: Wed, 30 Jun 2010 16:55:54 +0200 Subject: Segmentation fault while sending sms via bsc_hack_VTY Message-ID: <20100630145554.32420@gmx.net> -------- Original-Nachricht -------- > Datum: Wed, 30 Jun 2010 12:10:20 +0800 > Von: Holger Hans Peter Freyther > An: openbsc at lists.gnumonks.org > Betreff: Re: Segmentation fault while sending sms via bsc_hack_VTY > > > > thanks a lot for starting to debug this. Could you help me a bit with > > your test setup? Which type of BTS do you use? Could you get us a pcap > > file for the Channel Activate NACK? Attached I have a pcap file from bsc_hack. It logged until the segmentation fault happened. Additionally, I have captured the bsc_hack output and valgrind output in the other file. There you also find the openbsc config file. Only bsc_hack was started, without lcr or openggsn for this testing. We use two nanoBTS - ipaccess-find prints out: MAC Address='00:02:95:00:2f:b7' IP Address='10.1.1.10' Unit ID='1802/0/0' Location 1='' Location 2='BTS_NBT131G' Equipment Version='165a029_48' Software Version='168c002_v100b16d0' Unit Name='nbts-00-02-95-00-2F-B7' Serial Number='00071355' MAC Address='00:02:95:00:57:3e' IP Address='10.1.1.11' Unit ID='1800/0/0' Location 1='' Location 2='BTS_NBT131G' Equipment Version='165a029_55' Software Version='168a302_v142b13d0' Unit Name='nbts-00-02-95-00-57-3E' Serial Number='00107709' Each BTS has its own part in the openbsc.cfg > > please confirm that both the SMS crash and the NACKs are resolved. I loaded and built the current version from OpenBSC (Jun., 30. ~ 3:00 p.m.). SMS still crashes when sending from vty console. As far as I can tell, the NACKs are resolved. > > thanks thank you too! -------------- next part -------------- A non-text attachment was scrubbed... Name: smstest.pcap Type: application/cap Size: 9480 bytes Desc: not available URL: -------------- next part -------------- bsc_hack output after sending sms from the console: <0000> abis_rsl.c:1388 (bts=0,trx=0,ts=0,ss=0) SAPI=0 ESTABLISH INDICATION <0002> gsm_04_08.c:936 LOCATION UPDATING REQUEST: mi_type=0x04 MI(2936373035) type=NORMAL <0001> gsm_04_08.c:100 (bts 0 trx 0 ts 0 pd 05) Sending 0x18 to MS. <0001> gsm_04_08.c:100 (bts 0 trx 0 ts 0 pd 05) Sending 0x18 to MS. <- Can't find any subscriber for this ID <0000> abis_rsl.c:1388 (bts=0,trx=0,ts=0,ss=0) SAPI=0 DATA INDICATION <0003> gsm_04_08.c:1024 CLASSMARK CHANGE CM2(len=3) CM3(len=10) <0000> abis_rsl.c:1388 (bts=0,trx=0,ts=0,ss=0) SAPI=0 DATA INDICATION <0002> gsm_04_08.c:390 IDENTITY RESPONSE: mi_type=0x01 MI(262014900288624) <0000> abis_rsl.c:1388 (bts=0,trx=0,ts=0,ss=0) SAPI=0 DATA INDICATION <0002> gsm_04_08.c:390 IDENTITY RESPONSE: mi_type=0x02 MI(358998013670220) <0002> gsm_04_08.c:327 Subscriber 262014900288624: LOCATION UPDATING REJECT LAC=2323 BTS=0 <0001> gsm_04_08.c:100 (bts 0 trx 0 ts 0 pd 05) Sending 0x04 to MS. <0003> gsm_04_08_utils.c:197 Sending Channel Release: Chan: Number: 0 Type: 1 <0004> abis_rsl.c:586 (bts=0,trx=0,ts=0,ss=0) DEACTivate SACCH CMD <0000> chan_alloc.c:363 (bts=0,trx=0,ts=0,ss=0) Recycling Channel <0004> abis_rsl.c:942 (bts=0,trx=0,ts=0,ss=0): MEAS RES for inactive channel <0004> abis_rsl.c:942 (bts=0,trx=0,ts=0,ss=0): MEAS RES for inactive channel <0000> abis_rsl.c:1388 (bts=0,trx=0,ts=0,ss=0) SAPI=0 RELEASE CONFIRMATION <0004> abis_rsl.c:625 (bts=0,trx=0,ts=0,ss=0) RF Channel Release CMD due error 0 <0004> abis_rsl.c:1047 (bts=0,trx=0,ts=0,ss=0) RF CHANNEL RELEASE ACK <0004> abis_rsl.c:1235 (bts=0,trx=0,ts=0,ss=0) Activating ARFCN(871) SS(0) lctype SDCCH r=LOCATION_UPDATE ra=0x00 <0004> abis_rsl.c:1031 (bts=0,trx=0,ts=0,ss=0) CHANNEL ACTIVATE ACK <0000> abis_rsl.c:1388 (bts=0,trx=0,ts=0,ss=0) SAPI=0 ESTABLISH INDICATION <0002> gsm_04_08.c:936 LOCATION UPDATING REQUEST: mi_type=0x01 MI(262032560591295) type=NORMAL <0001> gsm_04_08.c:100 (bts 0 trx 0 ts 0 pd 05) Sending 0x18 to MS. <0000> abis_rsl.c:1388 (bts=0,trx=0,ts=0,ss=0) SAPI=0 DATA INDICATION <0003> gsm_04_08.c:1024 CLASSMARK CHANGE CM2(len=3) CM3(len=5) <0004> abis_rsl.c:1235 (bts=0,trx=0,ts=0,ss=1) Activating ARFCN(871) SS(1) lctype SDCCH r=LOCATION_UPDATE ra=0x12 <0004> abis_rsl.c:1031 (bts=0,trx=0,ts=0,ss=1) CHANNEL ACTIVATE ACK <0000> abis_rsl.c:1388 (bts=0,trx=0,ts=0,ss=0) SAPI=0 DATA INDICATION <0002> gsm_04_08.c:390 IDENTITY RESPONSE: mi_type=0x02 MI(352080036021620) <0000> abis_rsl.c:1388 (bts=0,trx=0,ts=0,ss=1) SAPI=0 ESTABLISH INDICATION <0003> gsm_04_08.c:988 PAGING RESPONSE: mi_type=0x04 MI(782026853) <0003> gsm_04_08.c:1006 <- Channel was requested by stylish-blau <0001> transaction.c:70 subscr=0x86beef0, subscr->net=0x8679ae0 Segmentation fault Valgrind output: when connecting to bts_hack_vty: ==17982== Syscall param ioctl(TCSET{S,SW,SF}) points to uninitialised byte(s) ==17982== at 0x4166A5F: tcsetattr (tcsetattr.c:88) ==17982== by 0x4069865: vty_create (vty.c:1399) ==17982== by 0x406A289: telnet_new_connection (telnet_interface.c:167) ==17982== by 0x403D924: bsc_select_main (select.c:119) ==17982== by 0x804BEA5: main (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== Address 0xbecc1298 is on thread 1's stack ==17982== After typing subscriber extension 42792 sms send "Test via console" in bts_hack_vty: ==17982== Invalid write of size 1 ==17982== at 0x4025D27: strcat (mc_replace_strmem.c:176) ==17982== by 0x402D4B9: dbd_quote_binary (in /usr/lib/dbd/libdbdsqlite3.so) ==17982== by 0x4056894: dbi_conn_quote_binary_copy (in /usr/lib/libdbi.so.0.0.5) ==17982== by 0x8056F24: db_sync_equipment (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x805B683: gsm48_rx_rr_pag_resp (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x805BCB1: gsm0408_rcv_rr (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x8060B80: gsm0408_dispatch (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x8064CC7: msc_compl_l3 (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x807E46B: gsm0408_rcvmsg (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x8068FDF: abis_rsl_rx_rll (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x806A103: abis_rsl_rcvmsg (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x80798F3: handle_ts1_read (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== Address 0x4474eae is 0 bytes after a block of size 6 alloc'd ==17982== at 0x4024F20: malloc (vg_replace_malloc.c:236) ==17982== by 0x402D48C: dbd_quote_binary (in /usr/lib/dbd/libdbdsqlite3.so) ==17982== by 0x4056894: dbi_conn_quote_binary_copy (in /usr/lib/libdbi.so.0.0.5) ==17982== by 0x8056F24: db_sync_equipment (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x805B683: gsm48_rx_rr_pag_resp (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x805BCB1: gsm0408_rcv_rr (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x8060B80: gsm0408_dispatch (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x8064CC7: msc_compl_l3 (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x807E46B: gsm0408_rcvmsg (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x8068FDF: abis_rsl_rx_rll (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x806A103: abis_rsl_rcvmsg (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x80798F3: handle_ts1_read (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== ==17982== Invalid write of size 1 ==17982== at 0x405C973: _dbd_encode_binary (in /usr/lib/libdbi.so.0.0.5) ==17982== by 0x402D4E5: dbd_quote_binary (in /usr/lib/dbd/libdbdsqlite3.so) ==17982== by 0x4056894: dbi_conn_quote_binary_copy (in /usr/lib/libdbi.so.0.0.5) ==17982== by 0x8056F56: db_sync_equipment (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x805B683: gsm48_rx_rr_pag_resp (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x805BCB1: gsm0408_rcv_rr (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x8060B80: gsm0408_dispatch (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x8064CC7: msc_compl_l3 (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x807E46B: gsm0408_rcvmsg (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x8068FDF: abis_rsl_rx_rll (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x806A103: abis_rsl_rcvmsg (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x80798F3: handle_ts1_read (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== Address 0x4474ee4 is 0 bytes after a block of size 4 alloc'd ==17982== at 0x4024F20: malloc (vg_replace_malloc.c:236) ==17982== by 0x402D48C: dbd_quote_binary (in /usr/lib/dbd/libdbdsqlite3.so) ==17982== by 0x4056894: dbi_conn_quote_binary_copy (in /usr/lib/libdbi.so.0.0.5) ==17982== by 0x8056F56: db_sync_equipment (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x805B683: gsm48_rx_rr_pag_resp (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x805BCB1: gsm0408_rcv_rr (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x8060B80: gsm0408_dispatch (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x8064CC7: msc_compl_l3 (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x807E46B: gsm0408_rcvmsg (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x8068FDF: abis_rsl_rx_rll (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x806A103: abis_rsl_rcvmsg (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x80798F3: handle_ts1_read (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== ==17982== Invalid read of size 1 ==17982== at 0x4025CEB: strcat (mc_replace_strmem.c:176) ==17982== by 0x402D4B9: dbd_quote_binary (in /usr/lib/dbd/libdbdsqlite3.so) ==17982== by 0x4056894: dbi_conn_quote_binary_copy (in /usr/lib/libdbi.so.0.0.5) ==17982== by 0x8056F56: db_sync_equipment (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x805B683: gsm48_rx_rr_pag_resp (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x805BCB1: gsm0408_rcv_rr (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x8060B80: gsm0408_dispatch (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x8064CC7: msc_compl_l3 (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x807E46B: gsm0408_rcvmsg (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x8068FDF: abis_rsl_rx_rll (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x806A103: abis_rsl_rcvmsg (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x80798F3: handle_ts1_read (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== Address 0x4474ee4 is 0 bytes after a block of size 4 alloc'd ==17982== at 0x4024F20: malloc (vg_replace_malloc.c:236) ==17982== by 0x402D48C: dbd_quote_binary (in /usr/lib/dbd/libdbdsqlite3.so) ==17982== by 0x4056894: dbi_conn_quote_binary_copy (in /usr/lib/libdbi.so.0.0.5) ==17982== by 0x8056F56: db_sync_equipment (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x805B683: gsm48_rx_rr_pag_resp (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x805BCB1: gsm0408_rcv_rr (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x8060B80: gsm0408_dispatch (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x8064CC7: msc_compl_l3 (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x807E46B: gsm0408_rcvmsg (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x8068FDF: abis_rsl_rx_rll (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x806A103: abis_rsl_rcvmsg (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x80798F3: handle_ts1_read (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== ==17982== Invalid write of size 1 ==17982== at 0x4025D0B: strcat (mc_replace_strmem.c:176) ==17982== by 0x402D4B9: dbd_quote_binary (in /usr/lib/dbd/libdbdsqlite3.so) ==17982== by 0x4056894: dbi_conn_quote_binary_copy (in /usr/lib/libdbi.so.0.0.5) ==17982== by 0x8056F56: db_sync_equipment (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x805B683: gsm48_rx_rr_pag_resp (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x805BCB1: gsm0408_rcv_rr (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x8060B80: gsm0408_dispatch (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x8064CC7: msc_compl_l3 (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x807E46B: gsm0408_rcvmsg (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x8068FDF: abis_rsl_rx_rll (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x806A103: abis_rsl_rcvmsg (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x80798F3: handle_ts1_read (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== Address 0x4474ee4 is 0 bytes after a block of size 4 alloc'd ==17982== at 0x4024F20: malloc (vg_replace_malloc.c:236) ==17982== by 0x402D48C: dbd_quote_binary (in /usr/lib/dbd/libdbdsqlite3.so) ==17982== by 0x4056894: dbi_conn_quote_binary_copy (in /usr/lib/libdbi.so.0.0.5) ==17982== by 0x8056F56: db_sync_equipment (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x805B683: gsm48_rx_rr_pag_resp (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x805BCB1: gsm0408_rcv_rr (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x8060B80: gsm0408_dispatch (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x8064CC7: msc_compl_l3 (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x807E46B: gsm0408_rcvmsg (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x8068FDF: abis_rsl_rx_rll (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x806A103: abis_rsl_rcvmsg (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x80798F3: handle_ts1_read (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== ==17982== Invalid write of size 1 ==17982== at 0x4025D27: strcat (mc_replace_strmem.c:176) ==17982== by 0x402D4B9: dbd_quote_binary (in /usr/lib/dbd/libdbdsqlite3.so) ==17982== by 0x4056894: dbi_conn_quote_binary_copy (in /usr/lib/libdbi.so.0.0.5) ==17982== by 0x8056F56: db_sync_equipment (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x805B683: gsm48_rx_rr_pag_resp (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x805BCB1: gsm0408_rcv_rr (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x8060B80: gsm0408_dispatch (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x8064CC7: msc_compl_l3 (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x807E46B: gsm0408_rcvmsg (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x8068FDF: abis_rsl_rx_rll (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x806A103: abis_rsl_rcvmsg (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x80798F3: handle_ts1_read (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== Address 0x4474ee5 is 1 bytes after a block of size 4 alloc'd ==17982== at 0x4024F20: malloc (vg_replace_malloc.c:236) ==17982== by 0x402D48C: dbd_quote_binary (in /usr/lib/dbd/libdbdsqlite3.so) ==17982== by 0x4056894: dbi_conn_quote_binary_copy (in /usr/lib/libdbi.so.0.0.5) ==17982== by 0x8056F56: db_sync_equipment (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x805B683: gsm48_rx_rr_pag_resp (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x805BCB1: gsm0408_rcv_rr (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x8060B80: gsm0408_dispatch (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x8064CC7: msc_compl_l3 (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x807E46B: gsm0408_rcvmsg (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x8068FDF: abis_rsl_rx_rll (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x806A103: abis_rsl_rcvmsg (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x80798F3: handle_ts1_read (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== ==17982== Invalid read of size 1 ==17982== at 0x40E250B: vfprintf (vfprintf.c:1614) ==17982== by 0x4102146: vasprintf (vasprintf.c:64) ==17982== by 0x405742E: dbi_conn_queryf (in /usr/lib/libdbi.so.0.0.5) ==17982== by 0x8056F8E: db_sync_equipment (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x805B683: gsm48_rx_rr_pag_resp (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x805BCB1: gsm0408_rcv_rr (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x8060B80: gsm0408_dispatch (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x8064CC7: msc_compl_l3 (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x807E46B: gsm0408_rcvmsg (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x8068FDF: abis_rsl_rx_rll (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x806A103: abis_rsl_rcvmsg (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x80798F3: handle_ts1_read (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== Address 0x4474eae is 0 bytes after a block of size 6 alloc'd ==17982== at 0x4024F20: malloc (vg_replace_malloc.c:236) ==17982== by 0x402D48C: dbd_quote_binary (in /usr/lib/dbd/libdbdsqlite3.so) ==17982== by 0x4056894: dbi_conn_quote_binary_copy (in /usr/lib/libdbi.so.0.0.5) ==17982== by 0x8056F24: db_sync_equipment (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x805B683: gsm48_rx_rr_pag_resp (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x805BCB1: gsm0408_rcv_rr (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x8060B80: gsm0408_dispatch (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x8064CC7: msc_compl_l3 (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x807E46B: gsm0408_rcvmsg (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x8068FDF: abis_rsl_rx_rll (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x806A103: abis_rsl_rcvmsg (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x80798F3: handle_ts1_read (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== ==17982== Invalid read of size 1 ==17982== at 0x410BACD: _IO_default_xsputn (genops.c:479) ==17982== by 0x40E2299: vfprintf (vfprintf.c:1614) ==17982== by 0x4102146: vasprintf (vasprintf.c:64) ==17982== by 0x405742E: dbi_conn_queryf (in /usr/lib/libdbi.so.0.0.5) ==17982== by 0x8056F8E: db_sync_equipment (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x805B683: gsm48_rx_rr_pag_resp (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x805BCB1: gsm0408_rcv_rr (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x8060B80: gsm0408_dispatch (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x8064CC7: msc_compl_l3 (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x807E46B: gsm0408_rcvmsg (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x8068FDF: abis_rsl_rx_rll (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x806A103: abis_rsl_rcvmsg (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== Address 0x4474ee4 is 0 bytes after a block of size 4 alloc'd ==17982== at 0x4024F20: malloc (vg_replace_malloc.c:236) ==17982== by 0x402D48C: dbd_quote_binary (in /usr/lib/dbd/libdbdsqlite3.so) ==17982== by 0x4056894: dbi_conn_quote_binary_copy (in /usr/lib/libdbi.so.0.0.5) ==17982== by 0x8056F56: db_sync_equipment (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x805B683: gsm48_rx_rr_pag_resp (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x805BCB1: gsm0408_rcv_rr (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x8060B80: gsm0408_dispatch (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x8064CC7: msc_compl_l3 (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x807E46B: gsm0408_rcvmsg (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x8068FDF: abis_rsl_rx_rll (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x806A103: abis_rsl_rcvmsg (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x80798F3: handle_ts1_read (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== <0001> transaction.c:70 subscr=0x445cc48, subscr->net=0x42af8d0 ==17982== Invalid read of size 1 ==17982== at 0x4026038: strlen (mc_replace_strmem.c:282) ==17982== by 0x40409E8: gsm48_encode_bcd_number (gsm48_ie.c:83) ==17982== by 0x806184F: gsm340_gen_oa (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x806190B: gsm340_gen_tpdu (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x8063069: gsm411_send_sms (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x806319E: paging_cb_send_sms (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x807452F: subscr_paging_cb (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x80760DA: _paging_request_stop (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x8076186: paging_request_stop (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x80722E3: gsm48_handle_paging_resp (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x805B69C: gsm48_rx_rr_pag_resp (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x805BCB1: gsm0408_rcv_rr (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== Address 0xa6 is not stack'd, malloc'd or (recently) free'd ==17982== ==17982== ==17982== Process terminating with default action of signal 11 (SIGSEGV) ==17982== Access not within mapped region at address 0xA6 ==17982== at 0x4026038: strlen (mc_replace_strmem.c:282) ==17982== by 0x40409E8: gsm48_encode_bcd_number (gsm48_ie.c:83) ==17982== by 0x806184F: gsm340_gen_oa (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x806190B: gsm340_gen_tpdu (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x8063069: gsm411_send_sms (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x806319E: paging_cb_send_sms (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x807452F: subscr_paging_cb (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x80760DA: _paging_request_stop (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x8076186: paging_request_stop (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x80722E3: gsm48_handle_paging_resp (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x805B69C: gsm48_rx_rr_pag_resp (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== by 0x805BCB1: gsm0408_rcv_rr (in /home/gsm/openbsc-gprs/openbsc/openbsc/src/bsc_hack) ==17982== If you believe this happened as a result of a stack ==17982== overflow in your program's main thread (unlikely but ==17982== possible), you can try to increase the size of the ==17982== main thread stack using the --main-stacksize= flag. ==17982== The main thread stack size used in this run was 8388608. ==17982== ==17982== HEAP SUMMARY: ==17982== in use at exit: 743,573 bytes in 5,081 blocks ==17982== total heap usage: 8,630 allocs, 3,549 frees, 2,006,406 bytes allocated ==17982== ==17982== LEAK SUMMARY: ==17982== definitely lost: 0 bytes in 0 blocks ==17982== indirectly lost: 0 bytes in 0 blocks ==17982== possibly lost: 740,173 bytes in 5,050 blocks ==17982== still reachable: 3,400 bytes in 31 blocks ==17982== suppressed: 0 bytes in 0 blocks ==17982== Rerun with --leak-check=full to see details of leaked memory ==17982== ==17982== For counts of detected and suppressed errors, rerun with: -v ==17982== Use --track-origins=yes to see where uninitialised values come from ==17982== ERROR SUMMARY: 11 errors from 9 contexts (suppressed: 40 from 13) Segmentation fault OpenBSC config is: ! ! OpenBSC configuration saved from vty ! ! password foo ! line vty no login ! network network country code 262 mobile network code 23 short name RZ-GSM long name RZ-GSM auth policy closed location updating reject cause 13 encryption a5 0 neci 0 rrlp mode none mm info 1 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 0 timer t3105 0 timer t3107 0 timer t3109 0 timer t3111 0 timer t3113 60 timer t3115 0 timer t3117 0 timer t3119 0 timer t3141 0 bts 0 type nanobts band DCS1800 cell_identity 4711 location_area_code 2323 training_sequence_code 7 base_station_id_code 63 ms max power 15 cell reselection hysteresis 4 rxlev access min 0 channel allocator ascending rach tx integer 9 rach max transmission 7 ip.access unit_id 1800 0 oml ip.access stream_id 255 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 timeslot 1 phys_chan_config SDCCH8 timeslot 2 phys_chan_config TCH/F timeslot 3 phys_chan_config TCH/F timeslot 4 phys_chan_config TCH/F timeslot 5 phys_chan_config TCH/F timeslot 6 phys_chan_config TCH/F timeslot 7 phys_chan_config TCH/F bts 1 type nanobts band DCS1800 cell_identity 4712 location_area_code 2323 training_sequence_code 7 base_station_id_code 63 ms max power 15 cell reselection hysteresis 4 rxlev access min 0 channel allocator ascending rach tx integer 9 rach max transmission 7 ip.access unit_id 1802 0 oml ip.access stream_id 255 gprs mode none trx 0 rf_locked 0 arfcn 877 nominal power 23 max_power_red 20 rsl e1 tei 0 timeslot 0 phys_chan_config CCCH+SDCCH4 timeslot 1 phys_chan_config SDCCH8 timeslot 2 phys_chan_config TCH/F timeslot 3 phys_chan_config TCH/F timeslot 4 phys_chan_config TCH/F timeslot 5 phys_chan_config TCH/F timeslot 6 phys_chan_config TCH/F timeslot 7 phys_chan_config TCH/F From laforge at gnumonks.org Wed Jun 30 16:02:38 2010 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 30 Jun 2010 18:02:38 +0200 Subject: Segmentation fault while sending sms via bsc_hack_VTY In-Reply-To: <20100630145554.32420@gmx.net> References: <20100630145554.32420@gmx.net> Message-ID: <20100630160238.GS4876@prithivi.gnumonks.org> Hi Richard, your backtrace seems to indicate that you do not have an extension assigned to the subscriber with ID 1. Sending SMS from VTY will be performed as if it was sent from that 'magic' subscriber. As indicated before, current SMS-from-VTY code is a big hack and needs reimplementation. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From philipp.maier at runningserver.com Sun Jun 27 15:35:56 2010 From: philipp.maier at runningserver.com (Philipp Fabian Benedikt Maier) Date: Sun, 27 Jun 2010 17:35:56 +0200 Subject: Arfcn calculation tool Message-ID: <4C276FDC.2050308@runningserver.com> Hi Folks. I always found it annoying to calculate the correspondending frequency of an arfcn by hand or with the webbased arfcn calculator. So i wrote a little program to do the work for me: http://www.root.runningserver.com/web/runningserver/software/arfcncalc.tar Maybe the one or other here on the list will find it useful. regards. Philipp -- ______________________________________ Philipp Fabian Benedikt Maier philipp.maier at runningserver.com Funk: DO5DXT http://www.runningserver.com http://www.diskettenschlitz.de ______________________________________ From openbsc at mail.tsaitgaist.info Wed Jun 30 11:42:32 2010 From: openbsc at mail.tsaitgaist.info (Kevin) Date: Wed, 30 Jun 2010 13:42:32 +0200 Subject: Arfcn calculation tool In-Reply-To: <4C276FDC.2050308@runningserver.com> References: <4C276FDC.2050308@runningserver.com> Message-ID: <4C2B2DA8.1010408@mail.tsaitgaist.info> You could also add the UARFCN defined in TS 25.104 Greetings, Kevin On 06/27/2010 05:35 PM, Philipp Fabian Benedikt Maier wrote: > Hi Folks. > > I always found it annoying to calculate the correspondending frequency > of an arfcn by hand or with the webbased arfcn calculator. > > So i wrote a little program to do the work for me: > http://www.root.runningserver.com/web/runningserver/software/arfcncalc.tar > > Maybe the one or other here on the list will find it useful. > > regards. > Philipp > From zero-kelvin at gmx.de Sun Jun 27 15:39:11 2010 From: zero-kelvin at gmx.de (dexter) Date: Sun, 27 Jun 2010 17:39:11 +0200 Subject: Arfcn calculation tool Message-ID: <4C27709F.5020908@gmx.de> Hi Folks. I always found it annoying to calculate the correspondending frequency of an arfcn by hand or with the webbased arfcn calculator. So i wrote a little program to do the work for me: http://www.root.runningserver.com/web/runningserver/software/arfcncalc.tar Maybe the one or other here on the list will find it useful. regards. Philipp From laforge at gnumonks.org Mon Jun 28 11:44:25 2010 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 28 Jun 2010 13:44:25 +0200 Subject: Arfcn calculation tool In-Reply-To: <4C27709F.5020908@gmx.de> References: <4C27709F.5020908@gmx.de> Message-ID: <20100628114425.GS3777@prithivi.gnumonks.org> Hi Dexter, thanks for your program. However, this problem had to be solved for OsmocomBB layer1 (and airprobe) already, thus libosmocore already has (at least part of) the functionality, e.g. the "uint16_t gsm_arfcn2freq10(uint16_t arfcn, int uplink)" function, which will give you the frequency in units of 100kHz (to avoid floating point math). The input parameter "arfcn" is the arfcn, optionally with the ARFCN_PCS bit set, if you want PCS1900 instead of DCS1800. Threre is also a function "enum gsm_band gsm_arfcn2band(uint16_t arfcn)" which will tell you the band from the arfcn. What is missing is the function to generate the ARFCN from the frequency. Maybe you could submit a function with the protoctype like "uint16_t gsm_freq10_to_arfcn(uint16_t freq10, int uplink)" and submit it as a patch to libosmocore/src/gsm_utils.c Next step would be to port your tool to use the functions of libosmocore and then merge your tool into the openbsc source tree. If that's too much effort I don't blame you... but I always try to avoid code duplication when possible. 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 Jun 28 11:46:19 2010 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 28 Jun 2010 13:46:19 +0200 Subject: Arfcn calculation tool In-Reply-To: <4C27709F.5020908@gmx.de> References: <4C27709F.5020908@gmx.de> Message-ID: <20100628114619.GT3777@prithivi.gnumonks.org> Oh, one more note: The information that yuo have in provider.h exists as part of osmocom-bb/src/host/layer23/src/networks.c We should move this into libosmocore, at that point you can also use it from your tool or from other software. 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 mosbah.abdelkader at gmail.com Sun Jun 27 16:50:06 2010 From: mosbah.abdelkader at gmail.com (mosbah abdelkader) Date: Sun, 27 Jun 2010 17:50:06 +0100 Subject: SS7 protocols support in openbsc project Message-ID: Hello, Is there a support of SS7 protocol stack over MTP (TDM) or SCTP (SIGTRAN) in the openbsc project. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Mon Jun 28 11:37:43 2010 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 28 Jun 2010 13:37:43 +0200 Subject: SS7 protocols support in openbsc project In-Reply-To: References: Message-ID: <20100628113743.GR3777@prithivi.gnumonks.org> On Sun, Jun 27, 2010 at 05:50:06PM +0100, mosbah abdelkader wrote: > Is there a support of SS7 protocol stack over MTP (TDM) or SCTP (SIGTRAN) in > the openbsc project. no. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From mosbah.abdelkader at gmail.com Mon Jun 28 12:51:23 2010 From: mosbah.abdelkader at gmail.com (mosbah abdelkader) Date: Mon, 28 Jun 2010 13:51:23 +0100 Subject: SS7 protocols support in openbsc project In-Reply-To: <20100628113743.GR3777@prithivi.gnumonks.org> References: <20100628113743.GR3777@prithivi.gnumonks.org> Message-ID: Ok. Thanks for the information. On Mon, Jun 28, 2010 at 12:37 PM, Harald Welte wrote: > On Sun, Jun 27, 2010 at 05:50:06PM +0100, mosbah abdelkader wrote: > > > Is there a support of SS7 protocol stack over MTP (TDM) or SCTP (SIGTRAN) > in > > the openbsc project. > > no. > > -- > - Harald Welte > http://laforge.gnumonks.org/ > > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ashwin.lists at gmail.com Tue Jun 29 07:28:57 2010 From: ashwin.lists at gmail.com (Ashwin) Date: Tue, 29 Jun 2010 12:58:57 +0530 Subject: SS7 protocols support in openbsc project In-Reply-To: <20100628113743.GR3777@prithivi.gnumonks.org> References: <20100628113743.GR3777@prithivi.gnumonks.org> Message-ID: <4C29A0B9.2000309@gmail.com> On Monday 28 June 2010 05:07 PM, Harald Welte wrote: > On Sun, Jun 27, 2010 at 05:50:06PM +0100, mosbah abdelkader wrote: > >> Is there a support of SS7 protocol stack over MTP (TDM) or SCTP (SIGTRAN) in >> the openbsc project. > > no. > If some one needs either one of them, which should be pursued now with an expectation of support in OpenBSC in near future. What are the plans (if any) for building / providing the SS7 support in either of the forms in OpenBSC ? Is there any roadmap for the same ? with Regards, ASHWIN From laforge at gnumonks.org Tue Jun 29 10:23:55 2010 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 29 Jun 2010 12:23:55 +0200 Subject: SS7 protocols support in openbsc project In-Reply-To: <4C29A0B9.2000309@gmail.com> References: <20100628113743.GR3777@prithivi.gnumonks.org> <4C29A0B9.2000309@gmail.com> Message-ID: <20100629102355.GT2940@prithivi.gnumonks.org> Dear Ashwin, On Tue, Jun 29, 2010 at 12:58:57PM +0530, Ashwin wrote: > On Monday 28 June 2010 05:07 PM, Harald Welte wrote: > >On Sun, Jun 27, 2010 at 05:50:06PM +0100, mosbah abdelkader wrote: > > > >>Is there a support of SS7 protocol stack over MTP (TDM) or SCTP (SIGTRAN) in > >>the openbsc project. > > > >no. > > If some one needs either one of them, which should be pursued now > with an expectation of support in OpenBSC in near future. I don't think there is big interest in MTP/TDM these days. SCTP/SIGRAN makes more sense. > What are the plans (if any) for building / providing the SS7 support > in either of the forms in OpenBSC ? Is there any roadmap for the > same ? There is no roadmap for it. We have evaluated it, studied the protocols and roughly know how much effort it would take. Most of the OpenBSC features - but particularly the ones interesting for enterprise use - are driven by customer demand. So as soon as there is a customer that wants to fund the development of such an interface (like adding MAP over TCAP over SCCP over SCTP to our MSC code), I'm sure one of the core OpenBSC developers will be more than happy to work on it. A SS7 interface is nothing that is required for the IT security crowd that wants to play with the GSM air interface. So it is only interested to large / commercial entities who can afford to pay for that development or do it by themselves. As far as our spare time work on OpenBSC is concerned, we will likely focus on issuse that are more interesting to us (and other smaller users of the software, like adding an external interface for fuzzing) Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From zecke at selfish.org Mon Jun 28 10:32:19 2010 From: zecke at selfish.org (Holger Freyther) Date: Mon, 28 Jun 2010 18:32:19 +0800 Subject: BSC API updates Message-ID: <4C287A33.8070103@selfish.org> Hi all, I just pushed zecke/remove-use-count with two commits to almost complete the split. This code allocates the "struct gsm_subscriber_connection" dynamically and the follow on commit is removing the use_count and releases a channel as soon as it is unused (no operation/transaction is left on it). I would like to land this code now and continue with: -) Land some channel release changes from the On-Waves branch -) Update the channel release documentation... -) Start recreating the osmo-bsc... -) Implement the assignment command and use it from gsm_04_08.c and suddenly we can easily switch from very early to early assignment... From laforge at gnumonks.org Mon Jun 28 13:55:57 2010 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 28 Jun 2010 15:55:57 +0200 Subject: ipaccess-config now able to set static IP address / mask / gateway Message-ID: <20100628135557.GY3777@prithivi.gnumonks.org> Hi! I've committed some changes to enable ipaccess-config to set static IP address, netmask and gateway. A full command looks like this: ./ipaccess/ipaccess-config -U dhcp-enabled -S static-ip -S static-gw -i 192.168.100.222/255.255.255.0 -g 192.168.100.1 -r 192.168.100.120 This will * unset DHCP client functionality * set static IP address nvram flag * set static gateway nvram flag * set the BTS IP to 192.168.100.222 netmask 255.255.255.0 * set the default gateway to 192.168.100.1 * restart the BTS Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From openbsc at ngolde.de Tue Jun 29 18:13:06 2010 From: openbsc at ngolde.de (Nico Golde) Date: Tue, 29 Jun 2010 20:13:06 +0200 Subject: [PATCH] * Fix null ptr dereference and sms memleak in case the recipient of an sms sent via vty is not attached. Store the sms in the database in this case for later delivery. Message-ID: <20100629181306.GA13940@pool.math.tu-berlin.de> The problem is that sms_from_text returns NULL in case the subscriber is not attached which a) leaks memory of the previously allocated sms and b) runs into a null ptr dereference in _send_sms_str(). There may be a better solution than this but this is the easiest way of noticing and taking action I could find without changing return values of sms_from_text. --- openbsc/src/vty_interface_layer3.c | 16 ++++++++++------ 1 files changed, 10 insertions(+), 6 deletions(-) diff --git a/openbsc/src/vty_interface_layer3.c b/openbsc/src/vty_interface_layer3.c index d80f7c9..0a65eec 100644 --- a/openbsc/src/vty_interface_layer3.c +++ b/openbsc/src/vty_interface_layer3.c @@ -166,11 +166,6 @@ struct gsm_sms *sms_from_text(struct gsm_subscriber *receiver, const char *text) if (!sms) return NULL; - if (!receiver->lac) { - /* subscriber currently not attached, store in database? */ - return NULL; - } - sms->receiver = subscr_get(receiver); strncpy(sms->text, text, sizeof(sms->text)-1); @@ -195,7 +190,16 @@ static int _send_sms_str(struct gsm_subscriber *receiver, char *str, sms = sms_from_text(receiver, str); sms->protocol_id = tp_pid; - gsm411_send_sms_subscr(receiver, sms); + + if(!receiver->lac){ + /* subscriber currently not attached, store in database */ + if (db_sms_store(sms) != 0) { + LOGP(DSMS, LOGL_ERROR, "Failed to store SMS in Database\n"); + return CMD_WARNING; + } + } else { + gsm411_send_sms_subscr(receiver, sms); + } return CMD_SUCCESS; } -- 1.7.1 From laforge at gnumonks.org Wed Jun 30 07:09:40 2010 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 30 Jun 2010 09:09:40 +0200 Subject: [PATCH] * Fix null ptr dereference and sms memleak in case the recipient of an sms sent via vty is not attached. Store the sms in the database in this case for later delivery. In-Reply-To: <20100629181306.GA13940@pool.math.tu-berlin.de> References: <20100629181306.GA13940@pool.math.tu-berlin.de> Message-ID: <20100630070940.GD18916@prithivi.gnumonks.org> On Tue, Jun 29, 2010 at 08:13:06PM +0200, Nico Golde wrote: > The problem is that sms_from_text returns NULL in case the > subscriber is not attached which a) leaks memory of the > previously allocated sms and b) runs into a null ptr > dereference in _send_sms_str(). nice catch! I'll apply your patch right now. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From philipp.maier at runningserver.com Tue Jun 29 23:01:29 2010 From: philipp.maier at runningserver.com (Philipp Fabian Benedikt Maier) Date: Wed, 30 Jun 2010 01:01:29 +0200 Subject: Cryptography VTY Bugreport Message-ID: <4C2A7B49.7010206@runningserver.com> Hi folks. I am currently playing with the crypto features of openBSC. When i want to enter the key for a specific subscriber in the VTY console openBSC crashes. When i create the entry manually with sqlite3 and try again the entry in the database will be overwritten and it seems to work. The string i entered in VTY was: subscriber imsi 001010000000000 a3a8 comp128v1 DEADBEEF0C0FFEE0F00D013370D00F23 The gdb backtrace is: openbsc at openBSC:~/openbsc/openbsc/src$ gdb -- pid 1612 GNU gdb (GDB) 7.1-ubuntu Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i486-linux-gnu". For bug reporting instructions, please see: ... pid: No such file or directory. Attaching to process 1612 Reading symbols from /home/openbsc/openbsc/openbsc/src/bsc_hack...done. Reading symbols from /usr/local/lib/libosmocore.so.0...done. Loaded symbols for /usr/local/lib/libosmocore.so.0 Reading symbols from /lib/tls/i686/cmov/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/tls/i686/cmov/libdl.so.2 Reading symbols from /usr/lib/libdbi.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libdbi.so.0 Reading symbols from /usr/local/lib/libosmovty.so.0...done. Loaded symbols for /usr/local/lib/libosmovty.so.0 Reading symbols from /lib/tls/i686/cmov/libcrypt.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/tls/i686/cmov/libcrypt.so.1 Reading symbols from /lib/tls/i686/cmov/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/tls/i686/cmov/libc.so.6 Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /lib/tls/i686/cmov/libm.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/tls/i686/cmov/libm.so.6 Reading symbols from /usr/lib/dbd/libdbdsqlite3.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/dbd/libdbdsqlite3.so Reading symbols from /usr/lib/libsqlite3.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libsqlite3.so.0 Reading symbols from /lib/tls/i686/cmov/libpthread.so.0...(no debugging symbols found)...done. [Thread debugging using libthread_db enabled] Loaded symbols for /lib/tls/i686/cmov/libpthread.so.0 0x00c9d422 in __kernel_vsyscall () (gdb) continue Continuing. Program received signal SIGSEGV, Segmentation fault. 0x0046450b in vfprintf () from /lib/tls/i686/cmov/libc.so.6 (gdb) bt #0 0x0046450b in vfprintf () from /lib/tls/i686/cmov/libc.so.6 #1 0x00484147 in vasprintf () from /lib/tls/i686/cmov/libc.so.6 #2 0x006b042f in dbi_conn_queryf () from /usr/lib/libdbi.so.0 #3 0x08054c05 in db_sync_authinfo_for_subscr (ainfo=0x579ff4, subscr=0x994ec18) at db.c:413 #4 0x0805408e in ena_subscr_a3a8 (self=0x8089ee0, vty=0x99501f8, argc=4, argv=0xbfc33f6c) at vty_interface_layer3.c:502 #5 0x00a74cfb in cmd_execute_command_real (vline=, vty=, cmd=0x0) at command.c:1874 #6 0x00a74e27 in cmd_execute_command (vline=0x994a5c0, vty=0x99501f8, cmd=0x0, vtysh=0) at command.c:1909 #7 0x00a7766f in vty_command (vty=0x99501f8) at vty.c:321 #8 vty_execute (vty=0x99501f8) at vty.c:585 #9 vty_read (vty=0x99501f8) at vty.c:1319 #10 0x00a793aa in client_data (fd=0x99504d4, what=1) at telnet_interface.c:128 #11 0x003b7925 in bsc_select_main (polling=0) at select.c:119 #12 0x0804bc66 in main (argc=3, argv=0xbfc34604) at bsc_hack.c:271 (gdb) Maybe this helps to find the bug. regards. Philipp -- ______________________________________ Philipp Fabian Benedikt Maier philipp.maier at runningserver.com Funk: DO5DXT http://www.runningserver.com http://www.diskettenschlitz.de ______________________________________ From laforge at gnumonks.org Wed Jun 30 07:06:23 2010 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 30 Jun 2010 09:06:23 +0200 Subject: Cryptography VTY Bugreport In-Reply-To: <4C2A7B49.7010206@runningserver.com> References: <4C2A7B49.7010206@runningserver.com> Message-ID: <20100630070623.GC18916@prithivi.gnumonks.org> Hi dexter, On Wed, Jun 30, 2010 at 01:01:29AM +0200, Philipp Fabian Benedikt Maier wrote: > I am currently playing with the crypto features of openBSC. When i > want to enter the key for a specific subscriber in the VTY console > openBSC crashes. > > When i create the entry manually with sqlite3 and try again the > entry in the database will be overwritten and it seems to work. Strange. I have just tested this here, but it works for me (whether or not the AuthKeys entry already exists or not...) Please note that Sylvain and me just fixed a probably unrelated bug in parsing upper-case hex letters on the VTY. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From 246tnt at gmail.com Wed Jun 30 07:41:51 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 30 Jun 2010 09:41:51 +0200 Subject: Cryptography VTY Bugreport In-Reply-To: <4C2A7B49.7010206@runningserver.com> References: <4C2A7B49.7010206@runningserver.com> Message-ID: Hi dexter, Here it works as well, I can't reproduce the issue. Can you inspect the ainfo structure given to db_sync_authinfo_for_subscr ? (like ki_len) Also all the arguments to dbi_conn_queryf . Is ki_str NULL by anychance. Sylvain From philipp.maier at runningserver.com Wed Jun 30 10:23:12 2010 From: philipp.maier at runningserver.com (Philipp Fabian Benedikt Maier) Date: Wed, 30 Jun 2010 12:23:12 +0200 Subject: Cryptography VTY Bugreport In-Reply-To: References: <4C2A7B49.7010206@runningserver.com> Message-ID: <4C2B1B10.3050203@runningserver.com> Hi Sylvain. > Here it works as well, I can't reproduce the issue. > I had exactly only one subscriber in the hlr - maybe that helps to reproduce it. > Can you inspect the ainfo structure given to > db_sync_authinfo_for_subscr ? (like ki_len) > > Also all the arguments to dbi_conn_queryf . Is ki_str NULL by anychance. > > I can try that on monday. Regards. Philipp -- ______________________________________ Philipp Fabian Benedikt Maier philipp.maier at runningserver.com Funk: DO5DXT http://www.runningserver.com http://www.diskettenschlitz.de ______________________________________