From zero-kelvin at gmx.de Mon Jan 7 13:14:16 2013 From: zero-kelvin at gmx.de (dexter) Date: Mon, 07 Jan 2013 14:14:16 +0100 Subject: Osmocom Berlin User Group meeting In-Reply-To: <20120818115942.GV29525@prithivi.gnumonks.org> References: <502d01a9.mirider@mirider.augusta.de> <20120818115942.GV29525@prithivi.gnumonks.org> Message-ID: <50EACA28.9040200@gmx.de> Hi folks. This is the announcement for the next Osmocom Berlin meeting. Jan 09, 8pm @ CCC Berlin, Marienstr. 11, 10113 Berlin There is no formal presentation scheduled for this meeting. If you are interested to show up, feel free to do so. There is no registration required. The meeting is free as in "free beer", despite no actual free beer being around. Regards, Philipp Maier From prakash.ntk at gmail.com Thu Jan 31 10:42:40 2013 From: prakash.ntk at gmail.com (prakash) Date: Thu, 31 Jan 2013 10:42:40 +0000 (UTC) Subject: Location update problems on Motorola C118 on real network (network location::india) References: Message-ID: hi, i am using osmocombb in motorola c118. when i load firmware (layer1) on phone and start the application MOBILE, it gets all parameters from phone, gets plmn finds cell but location update is rejected with cause ILLEGAL ME. i am trying in a network in india. i dont know the real problem behind this. plz help me From 246tnt at gmail.com Thu Jan 31 11:40:33 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Thu, 31 Jan 2013 12:40:33 +0100 Subject: Location update problems on Motorola C118 on real network (network location::india) In-Reply-To: References: Message-ID: On Thu, Jan 31, 2013 at 11:42 AM, prakash wrote: > hi, > i am using osmocombb in motorola c118. > when i load firmware (layer1) on phone and start the > application MOBILE, > it gets all parameters from phone, > gets plmn > finds cell > but location update is rejected with cause ILLEGAL ME. Try setting the IMEI to something valid. Cheers, Sylvain From kheimerl at cs.berkeley.edu Thu Jan 31 15:44:42 2013 From: kheimerl at cs.berkeley.edu (Kurtis Heimerl) Date: Fri, 1 Feb 2013 00:44:42 +0900 Subject: Location update problems on Motorola C118 on real network (network location::india) In-Reply-To: References: Message-ID: Should people be attaching Osmocom to real networks? On Thu, Jan 31, 2013 at 8:40 PM, Sylvain Munaut <246tnt at gmail.com> wrote: > On Thu, Jan 31, 2013 at 11:42 AM, prakash wrote: > > hi, > > i am using osmocombb in motorola c118. > > when i load firmware (layer1) on phone and start the > > application MOBILE, > > it gets all parameters from phone, > > gets plmn > > finds cell > > but location update is rejected with cause ILLEGAL > ME. > > Try setting the IMEI to something valid. > > Cheers, > > Sylvain > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Thu Jan 31 16:00:16 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Thu, 31 Jan 2013 17:00:16 +0100 Subject: Location update problems on Motorola C118 on real network (network location::india) In-Reply-To: References: Message-ID: > Should people be attaching Osmocom to real networks? Well, it's of course their responsibility, but both the stack and RF control are designed to be compliant to specs. Doesn't mean there is no bugs of course, but I mean, there is bug in commercial stacks as well. Cheers, Sylvain From laforge at gnumonks.org Thu Jan 31 16:34:26 2013 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 31 Jan 2013 17:34:26 +0100 Subject: Location update problems on Motorola C118 on real network (network location::india) In-Reply-To: References: Message-ID: <20130131163426.GM16835@prithivi.gnumonks.org> Hi Kurtis, On Fri, Feb 01, 2013 at 12:44:42AM +0900, Kurtis Heimerl wrote: > Should people be attaching Osmocom to real networks? If they feel that their local jurisdiction permits the use of modified software on certified/approved phone hardware: It is their choice. 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 pabftk at gmail.com Sun Jan 20 20:16:14 2013 From: pabftk at gmail.com (Pavel Baturko) Date: Sun, 20 Jan 2013 20:16:14 +0000 Subject: [PATCH] Decoding UCS2 USSD In-Reply-To: References: <20120919010248.GC25668@localhost> <20120919021257.14324.qmail@stuge.se> <20120922095747.GD29787@localhost> Message-ID: Hi list, Some time ago I proposed patch for supporting UCS2 USSD decoding, there was a discussion, but then unfortunately I have not received a response. Now I'm back to this subject and made small changes to decode UCS2 SMS by reusing code from USSD. But before sending new patch for SMS (and resend updated patch for USSD) I'd like to re-ask my last question in this thread: what to do with UTF-8 text after converting from UCS2? I sent patches with 3 variants: 1) Use setlocale to get available locales and set utf if possible and then print message. 2) Call external *nix command "locale" to check if utf is available and then print message. 3) Just print hex (with osmo_hexdump e.g.) I prefer #2, #1 may be also ok, #3 is bad because local (non-English) GSM providers often send service SMS/USSD messages in UCS2 and in that case reading hex instead of text is awful, also reading usual SMS from other MSs in hex uncomfortable too. Another problem is that using all of these methods makes impossible to read received SMS/USSD in VTY because AFAIU there is no way to check if console with VTY will be ok with UTF. Maybe it's possible to add flag to indicate that VTY can receive text in UTF? This flag may also cancel auto-detection of terminal's locale and shift responsibility to the user of this flag. But I'm not sure where this flag should be.. In my tests I just send decoded UTF text to VTY and all works fine. Another variant is inform user in VTY that message is printed in mobile log. So, what variant to choose when checking if terminal supports UTF? And how to interact with VTY in case of UTF strings? Thanks, Pavel From laforge at gnumonks.org Tue Jan 1 18:39:31 2013 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 1 Jan 2013 19:39:31 +0100 Subject: 29c3 youtube video In-Reply-To: References: <20121229101810.GA13977@nybble.binarybase.org> <20121229110747.GA23849@nybble.binarybase.org> Message-ID: <20130101183931.GA7118@prithivi.gnumonks.org> Hi Akib, On Sat, Dec 29, 2012 at 03:11:46PM +0300, Akib Sayyed wrote: > nice one. I would like to stdy your code. cause I am implementing l23 > mobile app on phone. currently CCCH_app is ported completely but there is > some memory management issue going on.:( are you sharing your current progress in a public git repository? If not, I'd like to strongly encourage you to do so. I can also give you commit access so you can push to a private branch on git.osmocom.org, if you prefer that. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From luca.bongiorni1 at studenti.unimi.it Tue Jan 1 20:09:24 2013 From: luca.bongiorni1 at studenti.unimi.it (Luca Bongiorni) Date: Tue, 01 Jan 2013 22:09:24 +0200 Subject: 29c3 youtube video In-Reply-To: <20130101183931.GA7118@prithivi.gnumonks.org> References: <20121229101810.GA13977@nybble.binarybase.org> <20121229110747.GA23849@nybble.binarybase.org> <20130101183931.GA7118@prithivi.gnumonks.org> Message-ID: Hey all, actually is "interesting" his web site. Since it seems a commercial website*: * " Matrix Shell developed own GSM penetration testing tool.This tool is comprised of hardware unit and a laptop.it can perform various test on network using custom firmware. Using this too tester can identify state in which end user is getting service in terms of security." * "We provide following services. GSM Network Penetration Testing Matrixshell have developed a tool that can be used for testing attack vectors from users point of view. That is attacks that can be carried out by using modified handsets which may cause misusing identity of GSM subscriber , mass cellphone cell phone switch off ,denial of service of subscriber etc. Such vulnerability may cause loss in reputation of provider. We can find out such issues using our own tools. Our tools comprised of UM interface hardware and a laptop communicating with UM interface. This tool can run different tests on network like: Checking encryption type, Authentication bypass, Wrong way of TMSI assignment by network, Identity impersonating." I am wondering how his software tools are dealing with Osmocom's licenses. Cheers, Luca > are you sharing your current progress in a public git repository? If > not, I'd like to strongly encourage you to do so. I can also give you > commit access so you can push to a private branch on git.osmocom.org, if you > prefer that. > > -- > - Harald Welte http://laforge.gnumonks.org/ > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) > From akibsayyed at gmail.com Wed Jan 2 05:35:39 2013 From: akibsayyed at gmail.com (Akib Sayyed) Date: Wed, 2 Jan 2013 08:35:39 +0300 Subject: 29c3 youtube video In-Reply-To: References: <20121229101810.GA13977@nybble.binarybase.org> <20121229110747.GA23849@nybble.binarybase.org> <20130101183931.GA7118@prithivi.gnumonks.org> Message-ID: Currently we are in production stage. We are more focused on buying own stack or buying chipset with compatible stack as there is no gprs/edge/3g suppprt in osmocom. Our first tool was based on osmocom but we are not in production. On Jan 2, 2013 12:12 AM, "Luca Bongiorni" wrote: > Hey all, > actually is "interesting" his web site. > > Since it seems a commercial website*: > > * " Matrix Shell developed own GSM penetration testing tool.This tool is > comprised of hardware unit and a laptop.it can perform various test on > network using custom firmware. > Using this too tester can identify state in which end user is getting > service in terms of security." > > * "We provide following services. > GSM Network Penetration Testing > Matrixshell have developed a tool that can be used for testing attack > vectors from users point of view. That is attacks that can be carried out > by using modified handsets which may cause misusing identity of GSM > subscriber , mass cellphone cell phone switch off ,denial of service of > subscriber etc. Such vulnerability may cause loss in reputation of provider. > We can find out such issues using our own tools. Our tools comprised of UM > interface hardware and a laptop communicating with UM interface. This tool > can run different tests on network like: Checking encryption type, > Authentication bypass, Wrong way of TMSI assignment by network, Identity > impersonating." > > I am wondering how his software tools are dealing with Osmocom's licenses. > > Cheers, > Luca > > > are you sharing your current progress in a public git repository? If > > not, I'd like to strongly encourage you to do so. I can also give you > > commit access so you can push to a private branch on git.osmocom.org, > if you > > prefer that. > > > > -- > > - 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 akibsayyed at gmail.com Wed Jan 2 05:36:46 2013 From: akibsayyed at gmail.com (Akib Sayyed) Date: Wed, 2 Jan 2013 08:36:46 +0300 Subject: 29c3 youtube video In-Reply-To: References: <20121229101810.GA13977@nybble.binarybase.org> <20121229110747.GA23849@nybble.binarybase.org> <20130101183931.GA7118@prithivi.gnumonks.org> Message-ID: Damn typo mistake On Jan 2, 2013 8:35 AM, "Akib Sayyed" wrote: > > Currently we are not in production stage. > We are more focused on buying own stack or buying chipset with compatible stack as there is no gprs/edge/3g suppprt in osmocom. > Our first tool was based on osmocom but we are not in production. > > On Jan 2, 2013 12:12 AM, "Luca Bongiorni" < luca.bongiorni1 at studenti.unimi.it> wrote: >> >> Hey all, >> actually is "interesting" his web site. >> >> Since it seems a commercial website*: >> >> * " Matrix Shell developed own GSM penetration testing tool.This tool is comprised of hardware unit and a laptop.it can perform various test on network using custom firmware. >> Using this too tester can identify state in which end user is getting service in terms of security." >> >> * "We provide following services. >> GSM Network Penetration Testing >> Matrixshell have developed a tool that can be used for testing attack vectors from users point of view. That is attacks that can be carried out by using modified handsets which may cause misusing identity of GSM subscriber , mass cellphone cell phone switch off ,denial of service of subscriber etc. Such vulnerability may cause loss in reputation of provider. >> We can find out such issues using our own tools. Our tools comprised of UM interface hardware and a laptop communicating with UM interface. This tool can run different tests on network like: Checking encryption type, Authentication bypass, Wrong way of TMSI assignment by network, Identity impersonating." >> >> I am wondering how his software tools are dealing with Osmocom's licenses. >> >> Cheers, >> Luca >> >> > are you sharing your current progress in a public git repository? If >> > not, I'd like to strongly encourage you to do so. I can also give you >> > commit access so you can push to a private branch on git.osmocom.org, if you >> > prefer that. >> > >> > -- >> > - 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 luca.bongiorni1 at studenti.unimi.it Wed Jan 2 07:34:08 2013 From: luca.bongiorni1 at studenti.unimi.it (Luca Bongiorni) Date: Wed, 02 Jan 2013 09:34:08 +0200 Subject: 29c3 youtube video In-Reply-To: References: <20121229101810.GA13977@nybble.binarybase.org> <20121229110747.GA23849@nybble.binarybase.org> <20130101183931.GA7118@prithivi.gnumonks.org> <1388428503-1357110472-cardhu_decombobulator_blackberry.rim.net-1887887579-@b16.c10.bise7.blackberry> Message-ID: I perfectly understand and agree about being reluctant to publish code that could be used for malicious purposes. I was talking more about what Harald suggested: a public/private git repo related with Layers implementation into the MS. Cheers, Luca > Currently there is no commercial activity going on. and tool mostly contain testing tools like Multiple IMSI Detach .Identity impersonation , channel hijacking like one presented in this 29C3. Channel DOS. more issue is if we publish such tools we might get in trouble from Government and also from telecom Operator for creating such tools. for same purpose we didnt published those tools. its more like publishing complete sniffing app for GSM with all codec support. > > currently we shall publish l1 l2 l3 app on target code soon when code cleaning will be completed. but dont get time as code is having multiple changes and uses library from different osmocom git hosted locally. > > > about publishing tools and research papers we shall do it after total research is complete. > > and reason that its taking too much time is am single person who can do technical work and coding rest team is more on core telecom network security. > > thats major issue in completing research . > > > On Wed, Jan 2, 2013 at 10:07 AM, wrote: > So, if I may ask, since you are NOT having anykind of commercial activity related with osmocom's tools and is more than one year that you are asking for technical explanations over this ml/irc... Why u didn't publish yet the sources/results of your researches into a public repo as Harald suggested? > > Cheers, > Luca > Sent from my Fuffaphone? > From: Akib Sayyed > Sender: baseband-devel-bounces at lists.osmocom.org > Date: Wed, 02 Jan 2013 08:36:46 +0300 > To: Luca Bongiorni > Cc: ; Harald Welte > Subject: Re: 29c3 youtube video > > Damn typo mistake > On Jan 2, 2013 8:35 AM, "Akib Sayyed" wrote: > > > > Currently we are not in production stage. > > We are more focused on buying own stack or buying chipset with compatible stack as there is no gprs/edge/3g suppprt in osmocom. > > Our first tool was based on osmocom but we are not in production. > > > > On Jan 2, 2013 12:12 AM, "Luca Bongiorni" wrote: > >> > >> Hey all, > >> actually is "interesting" his web site. > >> > >> Since it seems a commercial website*: > >> > >> * " Matrix Shell developed own GSM penetration testing tool.This tool is comprised of hardware unit and a laptop.it can perform various test on network using custom firmware. > >> Using this too tester can identify state in which end user is getting service in terms of security." > >> > >> * "We provide following services. > >> GSM Network Penetration Testing > >> Matrixshell have developed a tool that can be used for testing attack vectors from users point of view. That is attacks that can be carried out by using modified handsets which may cause misusing identity of GSM subscriber , mass cellphone cell phone switch off ,denial of service of subscriber etc. Such vulnerability may cause loss in reputation of provider. > >> We can find out such issues using our own tools. Our tools comprised of UM interface hardware and a laptop communicating with UM interface. This tool can run different tests on network like: Checking encryption type, Authentication bypass, Wrong way of TMSI assignment by network, Identity impersonating." > >> > >> I am wondering how his software tools are dealing with Osmocom's licenses. > >> > >> Cheers, > >> Luca > >> > >> > are you sharing your current progress in a public git repository? If > >> > not, I'd like to strongly encourage you to do so. I can also give you > >> > commit access so you can push to a private branch on git.osmocom.org, if you > >> > prefer that. > >> > > >> > -- > >> > - Harald Welte http://laforge.gnumonks.org/ > >> > ============================================================================ > >> > "Privacy in residential applications is a desirable marketing option." > >> > (ETSI EN 300 175-7 Ch. A6) > >> > > >> > >> > > > > -- > Akib Sayyed > Matrix-Shell > akibsayyed at gmail.com > akibsayyed at matrixshell.com > Mob:- +91-966-514-2243 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dario.lombardo.ml at gmail.com Tue Jan 8 08:25:45 2013 From: dario.lombardo.ml at gmail.com (Dario Lombardo) Date: Tue, 8 Jan 2013 09:25:45 +0100 Subject: sylvains talk from 29c3 In-Reply-To: References: Message-ID: Sylvain, are you planning to release your code? It is a fantastic work to play with. On Sun, Dec 30, 2012 at 5:26 PM, Vic Delorge wrote: > Speaker: Sylvain Munaut > or how to turn a phone into a BTS > > > The calypso baseband and its companion chips are used on the Motorola C123 > among other and are now well known for being supported by the Osmocom-BB > open source GSM baseband implementation. A couple years ago, it was hacked > a little further by using it as a raw bits capture device allowing the > interception of GSM traffic very cheaply. > > This talk will present some further work on that platform, showing that > just because a device wasn't design for a given task doesn't mean it can't > do it. More specifically how you can hack this phone to act as a GSM > basestation and broadcast your own network. > http://youtu.be/xFjVcxMpA6c > -------------- next part -------------- An HTML attachment was scrubbed... URL: From choukoumoun at gmail.com Fri Jan 11 22:18:17 2013 From: choukoumoun at gmail.com (choukoumoun) Date: Fri, 11 Jan 2013 23:18:17 +0100 Subject: [Osmocom] First step Osmocombb+Openbts In-Reply-To: References: Message-ID: <50F08FA9.6050904@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi people. I have seen the remarkable work of Sylvain on the use made of osmophone with OpenBTS. but I find no small tutorial to guide me through my first step. someone or I would just find my happiness? Bye -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJQ8I+oAAoJEABO1Y0yGxgxpj0IAKplUxlVkjoZGUZMFyBjbvdv f74JddJIMjkHiP5zCMdMEuSo5VH1vrbxpDzoBtGvBPUuyURJJ49bWfvVlmsI1Zih 4Fo77Rz1V9cgiBOfBdpZSlredqBiHJgzI6giUD9V4wN1f53cGsSFvddjeSQe9/PN ILBHNe8kCgiBEH0iFbO80JcsctYELfRo0oX7SS7ipQTr31npaq6zf31nmLuxFqma LJT+Knv1+P251BpIYPr707pQ96f+CEEdkCEao7I8TIkNWEtPQKu9kiHtRiFvT6zp koaUmgciTUF4glbHUmo2uv6tEKnDcoC+01TKPDZPLn7I0vFWD3ByuXysZMZrOWI= =lUg2 -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From choukoumoun at gmail.com Sat Jan 12 11:58:54 2013 From: choukoumoun at gmail.com (choukoumoun) Date: Sat, 12 Jan 2013 12:58:54 +0100 Subject: Fwd: [Osmocom] First step Osmocombb+Openbts In-Reply-To: <50F08FA9.6050904@gmail.com> References: <50F08FA9.6050904@gmail.com> Message-ID: <50F14FFE.9040300@gmail.com> -------- Original Message -------- Subject: [Osmocom] First step Osmocombb+Openbts Date: Fri, 11 Jan 2013 23:18:17 +0100 From: choukoumoun To: baseband-devel at lists.osmocom.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi people. I have seen the remarkable work of Sylvain on the use made of osmophone with OpenBTS. but I find no small tutorial to guide me through my first step. someone or I would just find my happiness? Bye * * *OK the code is not relesead Sorry. * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJQ8I+oAAoJEABO1Y0yGxgxpj0IAKplUxlVkjoZGUZMFyBjbvdv f74JddJIMjkHiP5zCMdMEuSo5VH1vrbxpDzoBtGvBPUuyURJJ49bWfvVlmsI1Zih 4Fo77Rz1V9cgiBOfBdpZSlredqBiHJgzI6giUD9V4wN1f53cGsSFvddjeSQe9/PN ILBHNe8kCgiBEH0iFbO80JcsctYELfRo0oX7SS7ipQTr31npaq6zf31nmLuxFqma LJT+Knv1+P251BpIYPr707pQ96f+CEEdkCEao7I8TIkNWEtPQKu9kiHtRiFvT6zp koaUmgciTUF4glbHUmo2uv6tEKnDcoC+01TKPDZPLn7I0vFWD3ByuXysZMZrOWI= =lUg2 -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Tue Jan 1 19:17:40 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Tue, 1 Jan 2013 20:17:40 +0100 Subject: Filter replacement In-Reply-To: <4C8FBFA6-50D6-4BB8-A9B3-5923C9631DC8@gmail.com> References: <4C8FBFA6-50D6-4BB8-A9B3-5923C9631DC8@gmail.com> Message-ID: > Is somebody on this list able and willing to sell me one C123 with the filter kit already built in (and tested)? I'd really appreciate if someone, who is more experienced in SMD soldering than me, could help me out. Ebay ... there is at least 3 listing for motorola C123 with filter replaced. Cheers, Sylvain From 246tnt at gmail.com Tue Jan 1 21:16:52 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Tue, 1 Jan 2013 22:16:52 +0100 Subject: OsmoDevCon 2013 brainstorming In-Reply-To: <20121231173736.GD21955@prithivi.gnumonks.org> References: <20121231173736.GD21955@prithivi.gnumonks.org> Message-ID: Hi, > I personally percevied OsmoDevCon 2012 as a big success, and it was fun > to bring everyone together. Same here and definitely looking forward to the 2013 edition ! > Generally, I prefer to keep the spirit of an invitation-only > developer+contributor-only event of those involved in Osmocom. +1 > At the same time, I would consider it a good idea to add a one day > user-conference to the schedule, where we try to get interested users up > to speed with the various projects, possibly including some workshops > and the like. Sure, could be nice. This might have some impact on logistics though since that means we may require significantly more space for the 'public' side that for the contributors only part, (and even possibly several rooms for workshops ?) > The concept of "hacking days" has proven to be quite useful for the > netfilter project in the past (Pablo and I can acknowledge to that > fact). I'm not sure how many people would be able to spend even more > days of their schedule, but even if it's a much smaller group it would > still be useful, IMHO. Yes, that's something we actually brought up during 29C3 that doing some hacking would definitely be a great idea. Last year we kinda planned of doing that in the evening but with day packed full of talk and then just general social interaction, we pretty much never got around to it. Now what I'm not yet sure is if it's best to have dedicated presentation / hacking days or to have hacking sessions on specific topic during the general schedule. > 2) consider whether late march (like 2012) would be a good schedule > again For me late march is fine. > 3) what we can improve from the last event The only thing that comes to mind was the "hacking" part and that's covered above. A south-east non-shielded window with visibility down to 20deg elevation maybe ... > Venue-wise, I would again suggest to hold it in Berlin, as it's > reasonbly well connected, has lots of low-cost flights to it, > accomodation is not too expensive and holger/me/sysmocom can take care > of local organization related activities. Hoewver, if somebody has a > strong opinion against berlin _and_ is willing to organize it, I'm not > completely against another venue. Damn, I was so looking forward to holding it in Dubai :p Cheers, Sylvain From laforge at gnumonks.org Wed Jan 2 15:46:55 2013 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 2 Jan 2013 16:46:55 +0100 Subject: OsmoDevCon 2013 brainstorming In-Reply-To: References: <20121231173736.GD21955@prithivi.gnumonks.org> Message-ID: <20130102154655.GC21354@prithivi.gnumonks.org> On Tue, Jan 01, 2013 at 10:16:52PM +0100, Sylvain Munaut wrote: > This might have some impact on logistics though since that means we > may require significantly more space for the 'public' side that for > the contributors only part, (and even possibly several rooms for > workshops ?) I don't think that's much of a problem. Sure, it will have to be different rooms, maybe even at a different location in Berlin. In case of lack of better ideas, we could consider using the large c-base main hall for the user day, I'm quite sure it would be sufficient, size-wise. Also, one might be able to get some room at a university. In fact, given that some folks at TU Berlin are using OsmocomBB and even OpenBSC + sysmoBTS, it might be an option to consider. > Now what I'm not yet sure is if it's best to have dedicated > presentation / hacking days or to have hacking sessions on specific > topic during the general schedule. i think splitting them from the main part of the OsmoDevCon has the advantage that not everyone has to be there during all the days. > > 2) consider whether late march (like 2012) would be a good schedule > > again > > For me late march is fine. ok, then I'll start to look for a venue that's available during that timeframe. > A south-east non-shielded window with visibility down to 20deg > elevation maybe ... heh. well, I think considering that would make the search quite more difficult... 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 dburgess at jcis.net Wed Jan 2 03:23:35 2013 From: dburgess at jcis.net (David A. Burgess) Date: Tue, 1 Jan 2013 19:23:35 -0800 Subject: OsmoDevCon 2013 brainstorming In-Reply-To: <20121231173736.GD21955@prithivi.gnumonks.org> References: <20121231173736.GD21955@prithivi.gnumonks.org> Message-ID: <85A5FA0C-E870-4A62-B66C-AE32C52112C7@jcis.net> Harald - Am 31.12.2012 um 09:37 schrieb Harald Welte : > Hi all, > > as the year 2012 has already ended or will soon end depending on your > timezone, it might be a good occasion to start thinking of an OsmoDevCon > 2013. > > I personally percevied OsmoDevCon 2012 as a big success, and it was fun > to bring everyone together. I agree. And while I am not a direct participant in Osmocom, I would like participate in this event again and contribute in some way that others find useful. > > Generally, I prefer to keep the spirit of an invitation-only > developer+contributor-only event of those involved in Osmocom. At the > same time, I would consider it a good idea to add a one day > user-conference to the schedule, where we try to get interested users up > to speed with the various projects, possibly including some workshops > and the like. I would be interested in attending an user-oriented OsmocomBB event. > > So schedule-wise, I would suggest something like: > > * one day user conference > * two day developer/contributor event > * optionally: 1-2 "hacking days". > > The concept of "hacking days" has proven to be quite useful for the > netfilter project in the past (Pablo and I can acknowledge to that > fact). I'm not sure how many people would be able to spend even more > days of their schedule, but even if it's a much smaller group it would > still be useful, IMHO. To go to Berlin from San Francisco, I spend about 16 hours in transit each way. So once I am there, I might as well stay a few days. :) I would hope to find others interested in working on project that overlaps with OpenBTS, like Sylvain's recent handset-cum-femtocell project, or an SMSCB that both projects can use. > > I'd like you to > > 1) provide feedback on the ideas about the one-day user event and the > hacking days These sound like good additions. > 2) consider whether late march (like 2012) would be a good schedule > against My own preference would be either early March, immediately after the GSM World Congress (so anyone attending both from outside Europe can combine travel) or as late in March as possible or even in April to give some turn-around time between trips. > 3) what we can improve from the last event This may sound odd coming from me, but unless this is explicitly intended to be a broad "FOSS cellular" event, broader than Osmocom, I would prefer to discuss OpenBTS only to the degree that the projects overlap or might interoperate. I think more discussion of topics like SIM acquisition, SIM applications, SS7-MAP and core network integration would be great. I think the public-vs-commercial discussion of OpenBTS was weird and inappropriate for the audience. More discussion of analog radio topics, like antenna selection and propagation, including specific case studies, might be a good addition if there is interest. > > In terms of improvements, I so far have noted down: > * larger venue needs to be found > * complaints about the venue not having sufficient heating C-Base has its charms, but I agree with these. > > Venue-wise, I would again suggest to hold it in Berlin, as it's > reasonbly well connected, has lots of low-cost flights to it, > accomodation is not too expensive and holger/me/sysmocom can take care > of local organization related activities. Hoewver, if somebody has a > strong opinion against berlin _and_ is willing to organize it, I'm not > completely against another venue. I welcome any excuse to visit Berlin. I would personally prefer a venue in or near Mitte, and certainly near an U-Banhhof. > > Regards and happy new year, > 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 Wed Jan 2 16:15:06 2013 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 2 Jan 2013 17:15:06 +0100 Subject: OsmoDevCon 2013 brainstorming In-Reply-To: <85A5FA0C-E870-4A62-B66C-AE32C52112C7@jcis.net> References: <20121231173736.GD21955@prithivi.gnumonks.org> <85A5FA0C-E870-4A62-B66C-AE32C52112C7@jcis.net> Message-ID: <20130102161506.GD21354@prithivi.gnumonks.org> Hi David, On Tue, Jan 01, 2013 at 07:23:35PM -0800, David A. Burgess wrote: > I agree. And while I am not a direct participant in Osmocom, I would > like participate in this event again and contribute in some way that > others find useful. great, your presence is appreciated. > > 2) consider whether late march (like 2012) would be a good schedule > > against > > My own preference would be either early March, immediately after the > GSM World Congress (so anyone attending both from outside Europe can > combine travel) or as late in March as possible or even in April to > give some turn-around time between trips. I think very early march after MWC might be a bit challenging to organize given the limited lead-time. Late in march might be overlapping with Easter holidays, where people might have holiday plans, or attend other events like EasterHegg. So personally, I think early April might be a better choice then. Question to the list at large: Would you prefer or avoid overlap with Easter? > This may sound odd coming from me, but unless this is explicitly > intended to be a broad "FOSS cellular" event, broader than Osmocom, I > would prefer to discuss OpenBTS only to the degree that the projects > overlap or might interoperate. I understand that position and don't mind it at all. 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 Jan 3 23:13:16 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 4 Jan 2013 00:13:16 +0100 Subject: OsmoDevCon 2013 brainstorming In-Reply-To: <20130102161506.GD21354@prithivi.gnumonks.org> References: <20121231173736.GD21955@prithivi.gnumonks.org> <85A5FA0C-E870-4A62-B66C-AE32C52112C7@jcis.net> <20130102161506.GD21354@prithivi.gnumonks.org> Message-ID: > Question to the list at large: Would you prefer or avoid overlap with > Easter? Maybe a slight preference since it means taking less days off work ... but really it doesn't change much to me. Cheers, Sylvain From dburgess at jcis.net Thu Jan 3 23:21:19 2013 From: dburgess at jcis.net (David A. Burgess) Date: Thu, 3 Jan 2013 15:21:19 -0800 Subject: OsmoDevCon 2013 brainstorming In-Reply-To: References: <20121231173736.GD21955@prithivi.gnumonks.org> <85A5FA0C-E870-4A62-B66C-AE32C52112C7@jcis.net> <20130102161506.GD21354@prithivi.gnumonks.org> Message-ID: <39AB0CE8-535D-4052-B37C-AAB27E7CA85F@jcis.net> I would prefer not to overlap, since for me this actually counts as "work". I guess I'm lucky that way. And I will probably try to schedule other business in Europe around this event, so keeping it away from Easter gives me more flexibility. On Jan 3, 2013, at 3:13 PM, Sylvain Munaut wrote: >> Question to the list at large: Would you prefer or avoid overlap with >> Easter? > > Maybe a slight preference since it means taking less days off work ... > but really it doesn't change much to me. > > > Cheers, > > Sylvain From alexander.chemeris at gmail.com Fri Jan 4 11:04:55 2013 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Fri, 4 Jan 2013 15:04:55 +0400 Subject: OsmoDevCon 2013 brainstorming In-Reply-To: <20121231173736.GD21955@prithivi.gnumonks.org> References: <20121231173736.GD21955@prithivi.gnumonks.org> Message-ID: Hi Harald, On Mon, Dec 31, 2012 at 9:37 PM, Harald Welte wrote: > as the year 2012 has already ended or will soon end depending on your > timezone, it might be a good occasion to start thinking of an OsmoDevCon > 2013. > > I personally percevied OsmoDevCon 2012 as a big success, and it was fun > to bring everyone together. +1 > Generally, I prefer to keep the spirit of an invitation-only > developer+contributor-only event of those involved in Osmocom. At the > same time, I would consider it a good idea to add a one day > user-conference to the schedule, where we try to get interested users up > to speed with the various projects, possibly including some workshops > and the like. I second this. > So schedule-wise, I would suggest something like: > > * one day user conference > * two day developer/contributor event > * optionally: 1-2 "hacking days". > > The concept of "hacking days" has proven to be quite useful for the > netfilter project in the past (Pablo and I can acknowledge to that > fact). I'm not sure how many people would be able to spend even more > days of their schedule, but even if it's a much smaller group it would > still be useful, IMHO. > > I'd like you to > > 1) provide feedback on the ideas about the one-day user event Tutorials and status updates? > and the hacking days Bug hunting&fixing (e.g. in osmosgsn), writing unit tests, architecture changes discussions? > 2) consider whether late march (like 2012) would be a good schedule > again I'm very much willing to attend and the lest week of March is very inconvenient for me due to other activities I participate in. April is much better (and warmer). > 3) what we can improve from the last event > > In terms of improvements, I so far have noted down: > * larger venue needs to be found > * complaints about the venue not having sufficient heating Yes, being at a warm place helps a lot. From niceguy108 at gmail.com Tue Jan 1 12:17:30 2013 From: niceguy108 at gmail.com (Bhaskar11) Date: Tue, 1 Jan 2013 17:47:30 +0530 Subject: Possible fix for problem -- "l1ctl.c:114 FBSB RESP: result=255" Message-ID: When I run ccch_scan on a regular network, every once in a while, at random I find the app stops sniffing with the error: > <000c> l1ctl.c:291 BURST IND: @(1428545 = 1077/01/35) (-105 dBm, SNR 3, > SACCH) > <000c> l1ctl.c:114 FBSB RESP: result=255 At the same time Osmocon gives a message like the following: > => DSP reports FB in bit that is 1031487569 bits in the future?!? > Synchronize_TDMA > LOST 2313! The problems seems therefore to emerge from some corruption of data in reception which causes l1ctl.c to dispatch the S_L1CTL_FBSB_ERR signal. From 246tnt at gmail.com Tue Jan 1 17:34:43 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Tue, 1 Jan 2013 18:34:43 +0100 Subject: Possible fix for problem -- "l1ctl.c:114 FBSB RESP: result=255" In-Reply-To: References: Message-ID: > Can Holger or Harald who have written ccch_scan please confirm if this is > the correct way to fix the problem or if there is better solution? Can you > please also insert the update in the ccch_scan code in the burst_ind branch > so that others can benefit? It's not a correct fix, that's just a work around that basically says "Try to sync endlessly until it works" ... Finding out _why_ the sync failed in the first place is the correct fix, which also would most likely fix the border case where you get bits errors (that case is triggered when the firmware thinks it has successfully synced but in fact didn't). Cheers, Sylvain From niceguy108 at gmail.com Wed Jan 2 07:13:59 2013 From: niceguy108 at gmail.com (Bhaskar11) Date: Wed, 2 Jan 2013 12:43:59 +0530 Subject: Potential bug / problematic code in gsm411_rx_rl_data() Message-ID: In gsm411_sms.c the function gsm411_rx_rl_data receives "struct gsm48_hdr *gh" as input then in very first line typecasts the pointer to "struct gsm411_rp_hdr *rp_data" to access its "data" field. struct gsm411_rp_hdr *rp_data = (struct gsm411_rp_hdr*)&gh->data; But the two header structures have their "data" fields offset by one byte as in: struct gsm411_rp_hdr { > uint8_t len; > uint8_t msg_type; > uint8_t msg_ref; > uint8_t data[0]; > } __attribute__ ((packed)); > > struct gsm48_hdr { > uint8_t proto_discr; > uint8_t msg_type; > uint8_t data[0]; > } __attribute__((packed)); Obviously this displacement has been compensated for elsewhere in the code as the application works. But this seems to be inadvertent. And if it is deliberate, it is risky programming practice and could create problems later on. Request you to correct and update suitably. Thanks. B. -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Wed Jan 2 09:35:35 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 2 Jan 2013 10:35:35 +0100 Subject: Potential bug / problematic code in gsm411_rx_rl_data() In-Reply-To: References: Message-ID: > In gsm411_sms.c the function gsm411_rx_rl_data receives "struct gsm48_hdr > *gh" as input then in very first line typecasts the pointer to "struct > gsm411_rp_hdr *rp_data" to access its "data" field. > >> struct gsm411_rp_hdr *rp_data = (struct gsm411_rp_hdr*)&gh->data; That's not what it does .... you need to either re-read that line or re-read a book on C programming. What is type casted is the pointer to gsm48_hdr data field. And that's because the data field of the gsm48_hdr contains a gsm411_rp_hdr in this case. > Request you to correct and update suitably. Well, I request you check your claims before making them ... Cheers, Sylvain From krummeich at mac.com Wed Jan 2 09:41:31 2013 From: krummeich at mac.com (Karsten Krummeich) Date: Wed, 02 Jan 2013 09:41:31 +0000 (GMT) Subject: Sylvain/testing branch compile error in gsm411 Message-ID: Hi list, I want to play with the mobile_app with TX and SIM-card support, so I checkout the sylvain/testing branch described in the wiki but the following error message occurs. The master branch work's very fine on my HW (C123). Can someone give me a hint, what should I do to get a working testset with SIM support? Here the shell-output by makeing sylvain/testing branch ......? CC gsm411_sms.o gsm411_sms.c: In Funktion ?gsm340_rx_tpdu?: gsm411_sms.c:228:19: Warnung: Variable ?sms_mms? gesetzt, aber nicht verwendet [-Wunused-but-set-variable] gsm411_sms.c: In Funktion ?gsm411_rx_rp_ud?: gsm411_sms.c:375:2: Warnung: Format ?%li? erwartet Argumenttyp ?long int?, aber Argument 7 hat Typ ?int? [-Wformat] gsm411_sms.c: In Funktion ?gsm411_tx_sms_submit?: gsm411_sms.c:657:3: Warnung: ?bergabe des Arguments 4 von ?gsm411_smc_init? von inkompatiblem Zeigertyp [standardm??ig aktiviert] /home/kasio/osmocom-bb/src/shared/libosmocore/include/osmocom/gsm/gsm0411_smc.h:46:6: Anmerkung: ?int (*)(struct gsm411_smc_inst *, int, struct msgb *, int)? erwartet, aber Argument hat Typ ?int (*)(struct gsm411_smc_inst *, int, struct msgb *)? gsm411_sms.c:657:3: Fehler: zu viele Argumente f?r Funktion ?gsm411_smc_init? /home/kasio/osmocom-bb/src/shared/libosmocore/include/osmocom/gsm/gsm0411_smc.h:46:6: Anmerkung: hier deklariert gsm411_sms.c:659:3: Fehler: zu viele Argumente f?r Funktion ?gsm411_smr_init? /home/kasio/osmocom-bb/src/shared/libosmocore/include/osmocom/gsm/gsm0411_smr.h:27:6: Anmerkung: hier deklariert gsm411_sms.c: In Funktion ?gsm411_rcv_sms?: gsm411_sms.c:911:4: Warnung: ?bergabe des Arguments 4 von ?gsm411_smc_init? von inkompatiblem Zeigertyp [standardm??ig aktiviert] /home/kasio/osmocom-bb/src/shared/libosmocore/include/osmocom/gsm/gsm0411_smc.h:46:6: Anmerkung: ?int (*)(struct gsm411_smc_inst *, int, struct msgb *, int)? erwartet, aber Argument hat Typ ?int (*)(struct gsm411_smc_inst *, int, struct msgb *)? gsm411_sms.c:911:4: Fehler: zu viele Argumente f?r Funktion ?gsm411_smc_init? /home/kasio/osmocom-bb/src/shared/libosmocore/include/osmocom/gsm/gsm0411_smc.h:46:6: Anmerkung: hier deklariert gsm411_sms.c:913:4: Fehler: zu viele Argumente f?r Funktion ?gsm411_smr_init? /home/kasio/osmocom-bb/src/shared/libosmocore/include/osmocom/gsm/gsm0411_smr.h:27:6: Anmerkung: hier deklariert make[3]: *** [gsm411_sms.o] Fehler 1 make[3]: Verlasse Verzeichnis '/home/kasio/osmocom-bb/src/host/layer23/src/mobile' make[2]: *** [all-recursive] Fehler 1 make[2]: Verlasse Verzeichnis '/home/kasio/osmocom-bb/src/host/layer23/src' make[1]: *** [all-recursive] Fehler 1 make[1]: Verlasse Verzeichnis '/home/kasio/osmocom-bb/src/host/layer23' make: *** [host/layer23/layer23] Fehler 2 kasio at T60:~/osmocom-bb/src$ Thanks a lot for your help. kasio -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Wed Jan 2 10:58:05 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 2 Jan 2013 11:58:05 +0100 Subject: Sylvain/testing branch compile error in gsm411 In-Reply-To: References: Message-ID: Hi, > I want to play with the mobile_app with TX and SIM-card support, so I > checkout the sylvain/testing branch described in the wiki but the following > error message occurs. > The master branch work's very fine on my HW (C123). In sylvain/testing, I know rely on the system wide installed libosmocore instead of a bundled version, which means you need to downliad/compile/install libosmocore (and a recent one) on your system for this to work. Obviously the configure should have failed, so there is a bug there. It shouldn't even have tried to compile, need to check why that happened. In the mean time you can find instructions to install libosmocore in https://bs11-abis.gnumonks.org/trac/wiki/Building_OpenBSC > Here the shell-output by makeing sylvain/testing branch When pasting errors, you might want to switch the locale to english ... I can't read german. Also, this would help people looking in the archive for the same bug. Cheers, Sylvain From krummeich at mac.com Wed Jan 2 17:53:37 2013 From: krummeich at mac.com (Karsten Krummeich) Date: Wed, 02 Jan 2013 18:53:37 +0100 Subject: Sylvain/testing branch compile error in gsm411 In-Reply-To: References: Message-ID: <1867768D-B51F-4D92-8BFB-C15AB1232D3D@mac.com> Hi Sylvain, thanks for your first aid. My answers below. On 02.01.2013, at 11:58, Sylvain Munaut <246tnt at gmail.com> wrote: > Hi, > >> I want to play with the mobile_app with TX and SIM-card support, so I >> checkout the sylvain/testing branch described in the wiki but the following >> error message occurs. >> The master branch work's very fine on my HW (C123). > > In sylvain/testing, I know rely on the system wide installed > libosmocore instead of a bundled version, which means you need to > downliad/compile/install libosmocore (and a recent one) on your system > for this to work. I have installed a recent libosmocore before I tried to compile your testing branch. > Obviously the configure should have failed, so there is a bug there. > It shouldn't even have tried to compile, need to check why that > happened. > > In the mean time you can find instructions to install libosmocore in > https://bs11-abis.gnumonks.org/trac/wiki/Building_OpenBSC I try to read the instructions above, but I haven't access to the server because no user and password. What should I do to get it? > >> Here the shell-output by makeing sylvain/testing branch > > When pasting errors, you might want to switch the locale to english > ... I can't read german. Also, this would help people looking in the > archive for the same bug. Sorry, my mistake. I've changed the location yet. > > Cheers, > > Sylvain Thanks and regards. kasio From 246tnt at gmail.com Wed Jan 2 19:18:03 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 2 Jan 2013 20:18:03 +0100 Subject: Sylvain/testing branch compile error in gsm411 In-Reply-To: <1867768D-B51F-4D92-8BFB-C15AB1232D3D@mac.com> References: <1867768D-B51F-4D92-8BFB-C15AB1232D3D@mac.com> Message-ID: Hi, > I have installed a recent libosmocore before I tried to compile your testing branch. Did you also do a fresh checkout or a "git clean -f -x -d" when switching branch ? Due to changes in the build system, residual from an old compilation may prevent it from building. >> In the mean time you can find instructions to install libosmocore in >> https://bs11-abis.gnumonks.org/trac/wiki/Building_OpenBSC > > I try to read the instructions above, but I haven't access to the server because no user and password. Remove the 'https' ... it's only for authenticated wiki users. Cheers, Sylvain From krummeich at mac.com Wed Jan 2 20:13:44 2013 From: krummeich at mac.com (Karsten Krummeich) Date: Wed, 02 Jan 2013 21:13:44 +0100 Subject: Sylvain/testing branch compile error in gsm411 In-Reply-To: References: <1867768D-B51F-4D92-8BFB-C15AB1232D3D@mac.com> Message-ID: <40218100-8620-4EEF-B22A-7D67E2D51EB7@mac.com> Hi Sylvain, that's it. Thank you so much. I did a "git clan -f -x -d" and it works fine. Best regards. kasio On 02.01.2013, at 20:18, Sylvain Munaut <246tnt at gmail.com> wrote: > Hi, > >> I have installed a recent libosmocore before I tried to compile your testing branch. > > Did you also do a fresh checkout or a "git clean -f -x -d" when > switching branch ? > > Due to changes in the build system, residual from an old compilation > may prevent it from building. > >>> In the mean time you can find instructions to install libosmocore in >>> https://bs11-abis.gnumonks.org/trac/wiki/Building_OpenBSC >> >> I try to read the instructions above, but I haven't access to the server because no user and password. > > Remove the 'https' ... it's only for authenticated wiki users. > > Cheers, > > Sylvain From osmocom at ehlers.info Mon Jan 7 14:24:23 2013 From: osmocom at ehlers.info (Tim Ehlers) Date: Mon, 7 Jan 2013 15:24:23 +0100 (CET) Subject: Sylvain/testing branch compile error in gsm411 In-Reply-To: References: Message-ID: On Wed, 2 Jan 2013, Karsten Krummeich wrote: Hi, > I want to play with the mobile_app with TX and SIM-card support, so I > checkout the sylvain/testing branch described in the wiki but the following > error message occurs. > The master branch work's very fine on my HW (C123). the changes for the systemwide libosmocore are now somehow got into the main branch. I had the same error today, using the main branch and had to revert these two patches: http://bb.osmocom.org/trac/changeset/9c1d7b10b83eaaaa328540f177c5af0ec90e4473/ http://bb.osmocom.org/trac/changeset/439738df434507405e1a4722ef5fd61e087ed6db/ Is that intended to have to have libosmocore systemwide, or is it a mistake? Or did I miss something else? Cheers Tim From 246tnt at gmail.com Mon Jan 7 16:20:40 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Mon, 7 Jan 2013 17:20:40 +0100 Subject: Sylvain/testing branch compile error in gsm411 In-Reply-To: References: Message-ID: Hi, > the changes for the systemwide libosmocore are now somehow got into the main > branch. I had the same error today, using the main branch and had to revert > these two patches: > > http://bb.osmocom.org/trac/changeset/9c1d7b10b83eaaaa328540f177c5af0ec90e4473/ > http://bb.osmocom.org/trac/changeset/439738df434507405e1a4722ef5fd61e087ed6db/ > > Is that intended to have to have libosmocore systemwide, or is it a mistake? > Or did I miss something else? It's intended. You will now need to download and install libosmocore separately. Cheers, Sylvain From andreas at eversberg.eu Mon Jan 7 17:56:41 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Mon, 07 Jan 2013 18:56:41 +0100 Subject: Sylvain/testing branch compile error in gsm411 In-Reply-To: References: Message-ID: <50EB0C59.3030101@eversberg.eu> Tim Ehlers wrote: > the changes for the systemwide libosmocore are now somehow got into > the main branch. hi tim, i just installed the latest libosmocore and the in osmocombb: "make distclean" only then it worked for me. andreas From dario.lombardo.ml at gmail.com Wed Jan 2 13:19:59 2013 From: dario.lombardo.ml at gmail.com (Dario Lombardo) Date: Wed, 2 Jan 2013 14:19:59 +0100 Subject: [PATCH] Custom range in cell_log Message-ID: Hi guys Please find attached a patch to cell_log that allows a user to specify a custom frequency range instead of the standard one. In the past I've done the same job changing the code by hand and recompiling, but a command line switch is more feasible. This is useful when one wants to monitor a subset of arfcns (like in GSM900) or even a single one. Any comment appreciated. Dario. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Adde-custom-frequecy-range-to-cell_log.patch Type: application/octet-stream Size: 4301 bytes Desc: not available URL: From 246tnt at gmail.com Wed Jan 2 15:14:40 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 2 Jan 2013 16:14:40 +0100 Subject: [PATCH] Custom range in cell_log In-Reply-To: References: Message-ID: Hi, > Please find attached a patch to cell_log that allows a user to specify a > custom frequency range instead of the standard one. Thanks. > In the past I've done the same job changing the code by hand and > recompiling, but a command line switch is more feasible. > This is useful when one wants to monitor a subset of arfcns (like in GSM900) > or even a single one. Indeed, looks like a very useful functionality. > Any comment appreciated. - print_band_range & parse_band_range should be static - Check coding style rules, (tab vs space). We use the kernel coding style (which you can view in the kernel tree under Documentation/CodingStyle ) I'm not a fan of the method used to pass the new range, but I can't think of anything better so good enough. I'm not exactly sure why the app is split into two files to begin with. Cheers, Sylvain From dario.lombardo.ml at gmail.com Wed Jan 2 16:12:41 2013 From: dario.lombardo.ml at gmail.com (Dario Lombardo) Date: Wed, 2 Jan 2013 17:12:41 +0100 Subject: [PATCH] Custom range in cell_log In-Reply-To: References: Message-ID: Hi Sylvain, and thanks for your comments. I've addressed your points. Let me know if I can improve the patch furter. On Wed, Jan 2, 2013 at 4:14 PM, Sylvain Munaut <246tnt at gmail.com> wrote: > Hi, > > > Please find attached a patch to cell_log that allows a user to specify a > > custom frequency range instead of the standard one. > > Thanks. > > > In the past I've done the same job changing the code by hand and > > recompiling, but a command line switch is more feasible. > > This is useful when one wants to monitor a subset of arfcns (like in > GSM900) > > or even a single one. > > Indeed, looks like a very useful functionality. > > > Any comment appreciated. > > - print_band_range & parse_band_range should be static > - Check coding style rules, (tab vs space). We use the kernel coding > style (which you can view in the kernel tree under > Documentation/CodingStyle ) > > I'm not a fan of the method used to pass the new range, but I can't > think of anything better so good enough. I'm not exactly sure why the > app is split into two files to begin with. > > Cheers, > > Sylvain > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Added-custom-frequecy-range-to-cell_log.patch Type: application/octet-stream Size: 4144 bytes Desc: not available URL: From 246tnt at gmail.com Wed Jan 2 19:34:36 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 2 Jan 2013 20:34:36 +0100 Subject: [PATCH] Custom range in cell_log In-Reply-To: References: Message-ID: > Hi Sylvain, and thanks for your comments. > I've addressed your points. Let me know if I can improve the patch furter. Thanks, merged. Cheers, Sylvain From akibsayyed at gmail.com Wed Jan 2 13:49:08 2013 From: akibsayyed at gmail.com (Akib Sayyed) Date: Wed, 2 Jan 2013 16:49:08 +0300 Subject: Implementing AMR Codec for Mobile App Message-ID: Dear All Currently i am trying to implement AMR codec for Mobile App. Please guide me for same. I am not that good in channel decoding. if anyone have given a try or have partial code implementation please help me in that. -- Akib Sayyed Matrix-Shell akibsayyed at gmail.com akibsayyed at matrixshell.com Mob:- +91-966-514-2243 -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Wed Jan 2 15:41:45 2013 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 2 Jan 2013 16:41:45 +0100 Subject: Implementing AMR Codec for Mobile App In-Reply-To: References: Message-ID: <20130102154145.GB21354@prithivi.gnumonks.org> Dear Akib, On Wed, Jan 02, 2013 at 04:49:08PM +0300, Akib Sayyed wrote: > Currently i am trying to implement AMR codec for Mobile App. > Please guide me for same. just a general remark: Only if you intend to respect the GPL and release your modified version of the code, you can expect anyone here to help you in your pursuit of adding new features to OsmocomBB. The collaborative work is _the_ motivation behind Open Source. People who just take and not give back are not generally welcome. AMR support would most likely be very much appreciated. It does not require you to implement anything related to channel coding, it merely requires you to understand and implement the DSP patch code loading, and how to configure the AMR related bits in the DSP-ARM API. 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 akibsayyed at gmail.com Fri Jan 4 06:54:21 2013 From: akibsayyed at gmail.com (Akib Sayyed) Date: Fri, 4 Jan 2013 09:54:21 +0300 Subject: Implementing AMR Codec for Mobile App In-Reply-To: <20130102154145.GB21354@prithivi.gnumonks.org> References: <20130102154145.GB21354@prithivi.gnumonks.org> Message-ID: Dear Herald I am trying my best for purpose of contributing. but there are some point i would like to tell code is completely in raw format.and i am really a bad in keeping things in proper format. I have uploaded them on https://github.com/akibsayyed/osmocom_ccch_firmware.git code is total garbage lol. needs lots of cleaning. On Wed, Jan 2, 2013 at 6:41 PM, Harald Welte wrote: > Dear Akib, > > On Wed, Jan 02, 2013 at 04:49:08PM +0300, Akib Sayyed wrote: > > Currently i am trying to implement AMR codec for Mobile App. > > Please guide me for same. > > just a general remark: Only if you intend to respect the GPL and > release your modified version of the code, you can expect anyone here to > help you in your pursuit of adding new features to OsmocomBB. > > The collaborative work is _the_ motivation behind Open Source. People > who just take and not give back are not generally welcome. > > AMR support would most likely be very much appreciated. It does not > require you to implement anything related to channel coding, it merely > requires you to understand and implement the DSP patch code loading, and > how to configure the AMR related bits in the DSP-ARM API. > > Regards, > Harald > > -- > - Harald Welte > http://laforge.gnumonks.org/ > > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. > A6) > -- Akib Sayyed Matrix-Shell akibsayyed at gmail.com akibsayyed at matrixshell.com Mob:- +91-966-514-2243 -------------- next part -------------- An HTML attachment was scrubbed... URL: From akibsayyed at gmail.com Fri Jan 4 08:10:06 2013 From: akibsayyed at gmail.com (Akib Sayyed) Date: Fri, 4 Jan 2013 11:10:06 +0300 Subject: Implementing AMR Codec for Mobile App In-Reply-To: References: <20130102154145.GB21354@prithivi.gnumonks.org> Message-ID: here is dietlibc used for same purpose https://github.com/akibsayyed/dietlibc_for_osmocom On Fri, Jan 4, 2013 at 9:54 AM, Akib Sayyed wrote: > Dear Herald > > > I am trying my best for purpose of contributing. but there are some point > i would like to tell > code is completely in raw format.and i am really a bad in keeping things > in proper format. > > I have uploaded them on > https://github.com/akibsayyed/osmocom_ccch_firmware.git > > code is total garbage lol. needs lots of cleaning. > > > On Wed, Jan 2, 2013 at 6:41 PM, Harald Welte wrote: > >> Dear Akib, >> >> On Wed, Jan 02, 2013 at 04:49:08PM +0300, Akib Sayyed wrote: >> > Currently i am trying to implement AMR codec for Mobile App. >> > Please guide me for same. >> >> just a general remark: Only if you intend to respect the GPL and >> release your modified version of the code, you can expect anyone here to >> help you in your pursuit of adding new features to OsmocomBB. >> >> The collaborative work is _the_ motivation behind Open Source. People >> who just take and not give back are not generally welcome. >> >> AMR support would most likely be very much appreciated. It does not >> require you to implement anything related to channel coding, it merely >> requires you to understand and implement the DSP patch code loading, and >> how to configure the AMR related bits in the DSP-ARM API. >> >> Regards, >> Harald >> >> -- >> - Harald Welte >> http://laforge.gnumonks.org/ >> >> ============================================================================ >> "Privacy in residential applications is a desirable marketing option." >> (ETSI EN 300 175-7 Ch. >> A6) >> > > > > -- > Akib Sayyed > Matrix-Shell > akibsayyed at gmail.com > akibsayyed at matrixshell.com > Mob:- +91-966-514-2243 > > -- Akib Sayyed Matrix-Shell akibsayyed at gmail.com akibsayyed at matrixshell.com Mob:- +91-966-514-2243 -------------- next part -------------- An HTML attachment was scrubbed... URL: From akibsayyed at gmail.com Fri Jan 25 07:27:19 2013 From: akibsayyed at gmail.com (Akib Sayyed) Date: Fri, 25 Jan 2013 12:57:19 +0530 Subject: Implementing AMR Codec for Mobile App In-Reply-To: <20130102154145.GB21354@prithivi.gnumonks.org> References: <20130102154145.GB21354@prithivi.gnumonks.org> Message-ID: On Wed, Jan 2, 2013 at 9:11 PM, Harald Welte wrote: > Dear Akib, > > On Wed, Jan 02, 2013 at 04:49:08PM +0300, Akib Sayyed wrote: > > Currently i am trying to implement AMR codec for Mobile App. > > Please guide me for same. > > just a general remark: Only if you intend to respect the GPL and > release your modified version of the code, you can expect anyone here to > help you in your pursuit of adding new features to OsmocomBB. > > The collaborative work is _the_ motivation behind Open Source. People > who just take and not give back are not generally welcome. > > AMR support would most likely be very much appreciated. It does not > require you to implement anything related to channel coding, it merely > requires you to understand and implement the DSP patch code loading, and > how to configure the AMR related bits in the DSP-ARM API. > > I would like to study documentation for same. if possible what work is left for AMR Codec support. > Regards, > Harald > > -- > - Harald Welte > http://laforge.gnumonks.org/ > > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. > A6) > -- Akib Sayyed Matrix-Shell akibsayyed at gmail.com akibsayyed at matrixshell.com Mob:- +91-966-514-2243 -------------- next part -------------- An HTML attachment was scrubbed... URL: From vamposdecampos at gmail.com Wed Jan 2 15:34:25 2013 From: vamposdecampos at gmail.com (Alex Badea) Date: Wed, 2 Jan 2013 17:34:25 +0200 Subject: [PATCH] l23 sysinfo: defer SI4 CBCH mobile allocation until SI1 is received Message-ID: <2c7c6f7e0690218badd2d37d7f5c95cd56651819.1357139765.git.vamposdecampos@gmail.com> When parsing SI4, there's a check and a log message saying that CBCH MA is ignored until SI1 is received. Then the MA is decoded anyway -- incorrectly -- such that it remains incorrect even after receiving the next SI1. Fix that with an "else". Signed-off-by: Alex Badea --- src/host/layer23/src/common/sysinfo.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/host/layer23/src/common/sysinfo.c b/src/host/layer23/src/common/sysinfo.c index 2816c26..b42bd65 100644 --- a/src/host/layer23/src/common/sysinfo.c +++ b/src/host/layer23/src/common/sysinfo.c @@ -753,6 +753,7 @@ short_read: LOGP(DRR, LOGL_NOTICE, "Ignoring CBCH allocation of " "SYSTEM INFORMATION 4 until SI 1 is " "received.\n"); + } else { gsm48_decode_mobile_alloc(s->freq, data + 2, data[1], s->hopping, &s->hopp_len, 1); } -- 1.7.0.4 From andreas at eversberg.eu Wed Jan 2 17:34:50 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Wed, 02 Jan 2013 18:34:50 +0100 Subject: [PATCH] l23 sysinfo: defer SI4 CBCH mobile allocation until SI1 is received In-Reply-To: <2c7c6f7e0690218badd2d37d7f5c95cd56651819.1357139765.git.vamposdecampos@gmail.com> References: <2c7c6f7e0690218badd2d37d7f5c95cd56651819.1357139765.git.vamposdecampos@gmail.com> Message-ID: <50E46FBA.4030400@eversberg.eu> Alex Badea wrote: > When parsing SI4, there's a check and a log message saying that CBCH > MA is ignored until SI1 is received. Then the MA is decoded anyway -- > incorrectly -- such that it remains incorrect even after receiving > the next SI1. > > Fix that with an "else". > hi alex, nice catch! is now committed. best regards, andreas From vamposdecampos at gmail.com Wed Jan 2 19:17:13 2013 From: vamposdecampos at gmail.com (Alex Badea) Date: Wed, 2 Jan 2013 21:17:13 +0200 Subject: [PATCH] l1: add CBCH flag to dedicated mode Message-ID: <4473982493dd1138f3867c59c16903288fcf64ef.1357153336.git.vamposdecampos@gmail.com> Add a .cbch_mode member to struct l1ctl_dm_est_req. If set, this instructs L1 to use the CBCH variant of SDCCH for dedicated mode (no uplink, no SACCH). Add the new cbch_mode flag to l1ctl_tx_dm_est_req* API calls. Clear it everywhere, except for app_cbch_sniff. Signed-off-by: Alex Badea --- The extra struct member might be a bit excessive; an alternative would be to abuse audio_mode, which is not used for signalling channels. include/l1ctl_proto.h | 1 + src/host/layer23/include/osmocom/bb/common/l1ctl.h | 5 +++-- src/host/layer23/src/common/l1ctl.c | 6 ++++-- src/host/layer23/src/misc/app_cbch_sniff.c | 4 ++-- src/host/layer23/src/mobile/gsm48_rr.c | 4 ++-- src/target/firmware/include/layer1/mframe_sched.h | 3 +++ src/target/firmware/layer1/l23_api.c | 12 +++++++----- src/target/firmware/layer1/mframe_sched.c | 14 ++++++++++++++ 8 files changed, 36 insertions(+), 13 deletions(-) diff --git a/include/l1ctl_proto.h b/include/l1ctl_proto.h index 771bf1c..55f0ffc 100644 --- a/include/l1ctl_proto.h +++ b/include/l1ctl_proto.h @@ -233,6 +233,7 @@ struct l1ctl_dm_est_req { }; uint8_t tch_mode; uint8_t audio_mode; + uint8_t cbch_mode; } __attribute__((packed)); struct l1ctl_dm_freq_req { diff --git a/src/host/layer23/include/osmocom/bb/common/l1ctl.h b/src/host/layer23/include/osmocom/bb/common/l1ctl.h index 46a333e..f25a516 100644 --- a/src/host/layer23/include/osmocom/bb/common/l1ctl.h +++ b/src/host/layer23/include/osmocom/bb/common/l1ctl.h @@ -25,10 +25,11 @@ int l1ctl_tx_rach_req(struct osmocom_ms *ms, uint8_t ra, uint16_t offset, /* Transmit L1CTL_DM_EST_REQ */ int l1ctl_tx_dm_est_req_h0(struct osmocom_ms *ms, uint16_t band_arfcn, - uint8_t chan_nr, uint8_t tsc, uint8_t tch_mode, uint8_t audio_mode); + uint8_t chan_nr, uint8_t tsc, uint8_t tch_mode, uint8_t audio_mode, + uint8_t cbch_mode); int l1ctl_tx_dm_est_req_h1(struct osmocom_ms *ms, uint8_t maio, uint8_t hsn, uint16_t *ma, uint8_t ma_len, uint8_t chan_nr, uint8_t tsc, - uint8_t tch_mode, uint8_t audio_mode); + uint8_t tch_mode, uint8_t audio_mode, uint8_t cbch_mode); /* Transmit L1CTL_DM_FREQ_REQ */ int l1ctl_tx_dm_freq_req_h0(struct osmocom_ms *ms, uint16_t band_arfcn, diff --git a/src/host/layer23/src/common/l1ctl.c b/src/host/layer23/src/common/l1ctl.c index 5898b22..57003af 100644 --- a/src/host/layer23/src/common/l1ctl.c +++ b/src/host/layer23/src/common/l1ctl.c @@ -461,7 +461,7 @@ int l1ctl_tx_rach_req(struct osmocom_ms *ms, uint8_t ra, uint16_t offset, /* Transmit L1CTL_DM_EST_REQ */ int l1ctl_tx_dm_est_req_h0(struct osmocom_ms *ms, uint16_t band_arfcn, uint8_t chan_nr, uint8_t tsc, uint8_t tch_mode, - uint8_t audio_mode) + uint8_t audio_mode, uint8_t cbch_mode) { struct msgb *msg; struct l1ctl_info_ul *ul; @@ -484,6 +484,7 @@ int l1ctl_tx_dm_est_req_h0(struct osmocom_ms *ms, uint16_t band_arfcn, req->h0.band_arfcn = htons(band_arfcn); req->tch_mode = tch_mode; req->audio_mode = audio_mode; + req->cbch_mode = cbch_mode; return osmo_send_l1(ms, msg); } @@ -491,7 +492,7 @@ int l1ctl_tx_dm_est_req_h0(struct osmocom_ms *ms, uint16_t band_arfcn, int l1ctl_tx_dm_est_req_h1(struct osmocom_ms *ms, uint8_t maio, uint8_t hsn, uint16_t *ma, uint8_t ma_len, uint8_t chan_nr, uint8_t tsc, uint8_t tch_mode, - uint8_t audio_mode) + uint8_t audio_mode, uint8_t cbch_mode) { struct msgb *msg; struct l1ctl_info_ul *ul; @@ -519,6 +520,7 @@ int l1ctl_tx_dm_est_req_h1(struct osmocom_ms *ms, uint8_t maio, uint8_t hsn, req->h1.ma[i] = htons(ma[i]); req->tch_mode = tch_mode; req->audio_mode = audio_mode; + req->cbch_mode = cbch_mode; return osmo_send_l1(ms, msg); } diff --git a/src/host/layer23/src/misc/app_cbch_sniff.c b/src/host/layer23/src/misc/app_cbch_sniff.c index 8256eaf..6df2f11 100644 --- a/src/host/layer23/src/misc/app_cbch_sniff.c +++ b/src/host/layer23/src/misc/app_cbch_sniff.c @@ -57,12 +57,12 @@ static int try_cbch(struct osmocom_ms *ms, struct gsm48_sysinfo *s) return l1ctl_tx_dm_est_req_h1(ms, s->maio, s->hsn, s->hopping, s->hopp_len, s->chan_nr, s->tsc, - GSM48_CMODE_SIGN, 0); + GSM48_CMODE_SIGN, 0, 1); } else { LOGP(DRR, LOGL_INFO, "chan_nr = 0x%02x TSC = %d ARFCN = %d\n", s->chan_nr, s->tsc, s->arfcn); return l1ctl_tx_dm_est_req_h0(ms, s->arfcn, - s->chan_nr, s->tsc, GSM48_CMODE_SIGN, 0); + s->chan_nr, s->tsc, GSM48_CMODE_SIGN, 0, 1); } } diff --git a/src/host/layer23/src/mobile/gsm48_rr.c b/src/host/layer23/src/mobile/gsm48_rr.c index 3d15494..a21758c 100644 --- a/src/host/layer23/src/mobile/gsm48_rr.c +++ b/src/host/layer23/src/mobile/gsm48_rr.c @@ -3002,10 +3002,10 @@ static int gsm48_rr_activate_channel(struct osmocom_ms *ms, if (cd->h) l1ctl_tx_dm_est_req_h1(ms, cd->maio, cd->hsn, ma, ma_len, cd->chan_nr, cd->tsc, cd->mode, - rr->audio_mode); + rr->audio_mode, 0); else l1ctl_tx_dm_est_req_h0(ms, cd->arfcn, cd->chan_nr, cd->tsc, - cd->mode, rr->audio_mode); + cd->mode, rr->audio_mode, 0); rr->dm_est = 1; /* old SI 5/6 are not valid on a new dedicated channel */ diff --git a/src/target/firmware/include/layer1/mframe_sched.h b/src/target/firmware/include/layer1/mframe_sched.h index ecdb1ec..74e2d27 100644 --- a/src/target/firmware/include/layer1/mframe_sched.h +++ b/src/target/firmware/include/layer1/mframe_sched.h @@ -23,6 +23,9 @@ enum mframe_task { MF_TASK_SDCCH8_6, MF_TASK_SDCCH8_7, + MF_TASK_SDCCH4_CBCH, + MF_TASK_SDCCH8_CBCH, + MF_TASK_TCH_F_EVEN, MF_TASK_TCH_F_ODD, MF_TASK_TCH_H_0, diff --git a/src/target/firmware/layer1/l23_api.c b/src/target/firmware/layer1/l23_api.c index ae39e63..215fc00 100644 --- a/src/target/firmware/layer1/l23_api.c +++ b/src/target/firmware/layer1/l23_api.c @@ -72,7 +72,7 @@ enum mf_type { MF26ODD, MF26EVEN }; -static uint32_t chan_nr2mf_task_mask(uint8_t chan_nr, uint8_t neigh_mode) +static uint32_t chan_nr2mf_task_mask(uint8_t chan_nr, uint8_t neigh_mode, uint8_t cbch) { uint8_t cbits = chan_nr >> 3; uint8_t tn = chan_nr & 0x7; @@ -90,11 +90,11 @@ static uint32_t chan_nr2mf_task_mask(uint8_t chan_nr, uint8_t neigh_mode) master_task = MF_TASK_TCH_H_0 + lch_idx; } else if ((cbits & 0x1c) == 0x04) { lch_idx = cbits & 0x3; - master_task = MF_TASK_SDCCH4_0 + lch_idx; + master_task = cbch ? MF_TASK_SDCCH4_CBCH : (MF_TASK_SDCCH4_0 + lch_idx); multiframe = MF51; } else if ((cbits & 0x18) == 0x08) { lch_idx = cbits & 0x7; - master_task = MF_TASK_SDCCH8_0 + lch_idx; + master_task = cbch ? MF_TASK_SDCCH8_CBCH : (MF_TASK_SDCCH8_0 + lch_idx); multiframe = MF51; #if 0 } else if (cbits == 0x10) { @@ -225,7 +225,8 @@ static void l1ctl_rx_dm_est_req(struct msgb *msg) struct l1ctl_info_ul *ul = (struct l1ctl_info_ul *) l1h->data; struct l1ctl_dm_est_req *est_req = (struct l1ctl_dm_est_req *) ul->payload; - printd("L1CTL_DM_EST_REQ (arfcn=%u, chan_nr=0x%02x, tsc=%u)\n", + printd("L1CTL_DM_EST_REQ %s(arfcn=%u, chan_nr=0x%02x, tsc=%u)\n", + est_req->cbch_mode ? "CBCH " : "", ntohs(est_req->h0.band_arfcn), ul->chan_nr, est_req->tsc); /* disable neighbour cell measurement of C0 TS 0 */ @@ -262,7 +263,8 @@ static void l1ctl_rx_dm_est_req(struct msgb *msg) } /* figure out which MF tasks to enable */ - l1a_mftask_set(chan_nr2mf_task_mask(ul->chan_nr, NEIGH_MODE_PM)); + l1a_mftask_set(chan_nr2mf_task_mask(ul->chan_nr, NEIGH_MODE_PM, + est_req->cbch_mode)); } /* receive a L1CTL_DM_FREQ_REQ from L23 */ diff --git a/src/target/firmware/layer1/mframe_sched.c b/src/target/firmware/layer1/mframe_sched.c index f3a6b43..0a9ff1e 100644 --- a/src/target/firmware/layer1/mframe_sched.c +++ b/src/target/firmware/layer1/mframe_sched.c @@ -198,6 +198,15 @@ static const struct mframe_sched_item mf_sdcch8_7[] = { { .sched_set = NULL } }; +static const struct mframe_sched_item mf_sdcch8_cbch[] = { + { .sched_set = NB_QUAD_FH_DL, .modulo = 51, .frame_nr = 8 }, + { .sched_set = NULL } +}; +static const struct mframe_sched_item mf_sdcch4_cbch[] = { + { .sched_set = NB_QUAD_DL, .modulo = 51, .frame_nr = 32 }, + { .sched_set = NULL } +}; + /* Measurement for MF 51 C0 */ static const struct mframe_sched_item mf_neigh_pm51_c0t0[] = { { .sched_set = NEIGH_PM , .modulo = 51, .frame_nr = 0 }, @@ -327,6 +336,9 @@ static const struct mframe_sched_item *sched_set_for_task[32] = { [MF_TASK_SDCCH8_6] = mf_sdcch8_6, [MF_TASK_SDCCH8_7] = mf_sdcch8_7, + [MF_TASK_SDCCH4_CBCH] = mf_sdcch4_cbch, + [MF_TASK_SDCCH8_CBCH] = mf_sdcch8_cbch, + [MF_TASK_TCH_F_EVEN] = mf_tch_f_even, [MF_TASK_TCH_F_ODD] = mf_tch_f_odd, [MF_TASK_TCH_H_0] = mf_tch_h_0, @@ -361,6 +373,7 @@ uint8_t mframe_task2chan_nr(enum mframe_task mft, uint8_t ts) cbits = 0x04 + 1; break; case MF_TASK_SDCCH4_2: + case MF_TASK_SDCCH4_CBCH: cbits = 0x04 + 2; break; case MF_TASK_SDCCH4_3: @@ -373,6 +386,7 @@ uint8_t mframe_task2chan_nr(enum mframe_task mft, uint8_t ts) cbits = 0x08 + 1; break; case MF_TASK_SDCCH8_2: + case MF_TASK_SDCCH8_CBCH: cbits = 0x08 + 2; break; case MF_TASK_SDCCH8_3: -- 1.7.0.4 From holger at freyther.de Wed Jan 2 22:51:42 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Wed, 2 Jan 2013 23:51:42 +0100 Subject: [PATCH] l1: add CBCH flag to dedicated mode In-Reply-To: <4473982493dd1138f3867c59c16903288fcf64ef.1357153336.git.vamposdecampos@gmail.com> References: <4473982493dd1138f3867c59c16903288fcf64ef.1357153336.git.vamposdecampos@gmail.com> Message-ID: <20130102225142.GG26077@xiaoyu.lan> On Wed, Jan 02, 2013 at 09:17:13PM +0200, Alex Badea wrote: Hi, could you please use an enum instead of 0 and 1. Looks like nice work otherwise. thanks holger From 246tnt at gmail.com Thu Jan 3 00:16:18 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Thu, 3 Jan 2013 01:16:18 +0100 Subject: [PATCH] l1: add CBCH flag to dedicated mode In-Reply-To: <4473982493dd1138f3867c59c16903288fcf64ef.1357153336.git.vamposdecampos@gmail.com> References: <4473982493dd1138f3867c59c16903288fcf64ef.1357153336.git.vamposdecampos@gmail.com> Message-ID: Hi, > Add a .cbch_mode member to struct l1ctl_dm_est_req. If set, this > instructs L1 to use the CBCH variant of SDCCH for dedicated mode (no > uplink, no SACCH). I would make it a generic 'flags' bit fields with a DM_FLAG_CBCH or something like that. This way we can re-use this for other special modes (I'm thinking like a sniff more or no tx or role swap modes). > The extra struct member might be a bit excessive; an alternative would > be to abuse audio_mode, which is not used for signalling channels. I don't like the idea of abusing audio_mode, but I'll look into the code tomorrow see if it worth combining more stuff into a parameters. Cheers, Sylvain From vamposdecampos at gmail.com Thu Jan 3 11:25:05 2013 From: vamposdecampos at gmail.com (Alex Badea) Date: Thu, 3 Jan 2013 13:25:05 +0200 Subject: [PATCH v2] l1: add CBCH flag to dedicated mode In-Reply-To: References: <4473982493dd1138f3867c59c16903288fcf64ef.1357153336.git.vamposdecampos@gmail.com> Message-ID: Add a .dm_flags member to struct l1ctl_dm_est_req. Define a flag bit to indicate CBCH mode. If set, this instructs L1 to use the CBCH variant of SDCCH for dedicated mode (no uplink, no SACCH). Add the new dm_flags field to l1ctl_tx_dm_est_req* API calls. Clear it everywhere, except for app_cbch_sniff which requests CBCH. Signed-off-by: Alex Badea --- Thanks for reviewing. include/l1ctl_proto.h | 3 +++ src/host/layer23/include/osmocom/bb/common/l1ctl.h | 5 +++-- src/host/layer23/src/common/l1ctl.c | 6 ++++-- src/host/layer23/src/misc/app_cbch_sniff.c | 4 ++-- src/host/layer23/src/mobile/gsm48_rr.c | 4 ++-- src/target/firmware/include/layer1/mframe_sched.h | 3 +++ src/target/firmware/layer1/l23_api.c | 14 ++++++++------ src/target/firmware/layer1/mframe_sched.c | 14 ++++++++++++++ 8 files changed, 39 insertions(+), 14 deletions(-) diff --git a/include/l1ctl_proto.h b/include/l1ctl_proto.h index 771bf1c..c958518 100644 --- a/include/l1ctl_proto.h +++ b/include/l1ctl_proto.h @@ -233,8 +233,11 @@ struct l1ctl_dm_est_req { }; uint8_t tch_mode; uint8_t audio_mode; + uint8_t dm_flags; } __attribute__((packed)); +#define L1CTL_DM_F_CBCH (1 << 0) + struct l1ctl_dm_freq_req { uint16_t fn; uint8_t tsc; diff --git a/src/host/layer23/include/osmocom/bb/common/l1ctl.h b/src/host/layer23/include/osmocom/bb/common/l1ctl.h index 46a333e..2b7155a 100644 --- a/src/host/layer23/include/osmocom/bb/common/l1ctl.h +++ b/src/host/layer23/include/osmocom/bb/common/l1ctl.h @@ -25,10 +25,11 @@ int l1ctl_tx_rach_req(struct osmocom_ms *ms, uint8_t ra, uint16_t offset, /* Transmit L1CTL_DM_EST_REQ */ int l1ctl_tx_dm_est_req_h0(struct osmocom_ms *ms, uint16_t band_arfcn, - uint8_t chan_nr, uint8_t tsc, uint8_t tch_mode, uint8_t audio_mode); + uint8_t chan_nr, uint8_t tsc, uint8_t tch_mode, uint8_t audio_mode, + uint8_t dm_flags); int l1ctl_tx_dm_est_req_h1(struct osmocom_ms *ms, uint8_t maio, uint8_t hsn, uint16_t *ma, uint8_t ma_len, uint8_t chan_nr, uint8_t tsc, - uint8_t tch_mode, uint8_t audio_mode); + uint8_t tch_mode, uint8_t audio_mode, uint8_t dm_flags); /* Transmit L1CTL_DM_FREQ_REQ */ int l1ctl_tx_dm_freq_req_h0(struct osmocom_ms *ms, uint16_t band_arfcn, diff --git a/src/host/layer23/src/common/l1ctl.c b/src/host/layer23/src/common/l1ctl.c index 5898b22..7432085 100644 --- a/src/host/layer23/src/common/l1ctl.c +++ b/src/host/layer23/src/common/l1ctl.c @@ -461,7 +461,7 @@ int l1ctl_tx_rach_req(struct osmocom_ms *ms, uint8_t ra, uint16_t offset, /* Transmit L1CTL_DM_EST_REQ */ int l1ctl_tx_dm_est_req_h0(struct osmocom_ms *ms, uint16_t band_arfcn, uint8_t chan_nr, uint8_t tsc, uint8_t tch_mode, - uint8_t audio_mode) + uint8_t audio_mode, uint8_t dm_flags) { struct msgb *msg; struct l1ctl_info_ul *ul; @@ -484,6 +484,7 @@ int l1ctl_tx_dm_est_req_h0(struct osmocom_ms *ms, uint16_t band_arfcn, req->h0.band_arfcn = htons(band_arfcn); req->tch_mode = tch_mode; req->audio_mode = audio_mode; + req->dm_flags = dm_flags; return osmo_send_l1(ms, msg); } @@ -491,7 +492,7 @@ int l1ctl_tx_dm_est_req_h0(struct osmocom_ms *ms, uint16_t band_arfcn, int l1ctl_tx_dm_est_req_h1(struct osmocom_ms *ms, uint8_t maio, uint8_t hsn, uint16_t *ma, uint8_t ma_len, uint8_t chan_nr, uint8_t tsc, uint8_t tch_mode, - uint8_t audio_mode) + uint8_t audio_mode, uint8_t dm_flags) { struct msgb *msg; struct l1ctl_info_ul *ul; @@ -519,6 +520,7 @@ int l1ctl_tx_dm_est_req_h1(struct osmocom_ms *ms, uint8_t maio, uint8_t hsn, req->h1.ma[i] = htons(ma[i]); req->tch_mode = tch_mode; req->audio_mode = audio_mode; + req->dm_flags = dm_flags; return osmo_send_l1(ms, msg); } diff --git a/src/host/layer23/src/misc/app_cbch_sniff.c b/src/host/layer23/src/misc/app_cbch_sniff.c index 8256eaf..a62dd7c 100644 --- a/src/host/layer23/src/misc/app_cbch_sniff.c +++ b/src/host/layer23/src/misc/app_cbch_sniff.c @@ -57,12 +57,12 @@ static int try_cbch(struct osmocom_ms *ms, struct gsm48_sysinfo *s) return l1ctl_tx_dm_est_req_h1(ms, s->maio, s->hsn, s->hopping, s->hopp_len, s->chan_nr, s->tsc, - GSM48_CMODE_SIGN, 0); + GSM48_CMODE_SIGN, 0, L1CTL_DM_F_CBCH); } else { LOGP(DRR, LOGL_INFO, "chan_nr = 0x%02x TSC = %d ARFCN = %d\n", s->chan_nr, s->tsc, s->arfcn); return l1ctl_tx_dm_est_req_h0(ms, s->arfcn, - s->chan_nr, s->tsc, GSM48_CMODE_SIGN, 0); + s->chan_nr, s->tsc, GSM48_CMODE_SIGN, 0, L1CTL_DM_F_CBCH); } } diff --git a/src/host/layer23/src/mobile/gsm48_rr.c b/src/host/layer23/src/mobile/gsm48_rr.c index 3d15494..a21758c 100644 --- a/src/host/layer23/src/mobile/gsm48_rr.c +++ b/src/host/layer23/src/mobile/gsm48_rr.c @@ -3002,10 +3002,10 @@ static int gsm48_rr_activate_channel(struct osmocom_ms *ms, if (cd->h) l1ctl_tx_dm_est_req_h1(ms, cd->maio, cd->hsn, ma, ma_len, cd->chan_nr, cd->tsc, cd->mode, - rr->audio_mode); + rr->audio_mode, 0); else l1ctl_tx_dm_est_req_h0(ms, cd->arfcn, cd->chan_nr, cd->tsc, - cd->mode, rr->audio_mode); + cd->mode, rr->audio_mode, 0); rr->dm_est = 1; /* old SI 5/6 are not valid on a new dedicated channel */ diff --git a/src/target/firmware/include/layer1/mframe_sched.h b/src/target/firmware/include/layer1/mframe_sched.h index ecdb1ec..74e2d27 100644 --- a/src/target/firmware/include/layer1/mframe_sched.h +++ b/src/target/firmware/include/layer1/mframe_sched.h @@ -23,6 +23,9 @@ enum mframe_task { MF_TASK_SDCCH8_6, MF_TASK_SDCCH8_7, + MF_TASK_SDCCH4_CBCH, + MF_TASK_SDCCH8_CBCH, + MF_TASK_TCH_F_EVEN, MF_TASK_TCH_F_ODD, MF_TASK_TCH_H_0, diff --git a/src/target/firmware/layer1/l23_api.c b/src/target/firmware/layer1/l23_api.c index ae39e63..49aeb45 100644 --- a/src/target/firmware/layer1/l23_api.c +++ b/src/target/firmware/layer1/l23_api.c @@ -72,7 +72,7 @@ enum mf_type { MF26ODD, MF26EVEN }; -static uint32_t chan_nr2mf_task_mask(uint8_t chan_nr, uint8_t neigh_mode) +static uint32_t chan_nr2mf_task_mask(uint8_t chan_nr, uint8_t neigh_mode, uint8_t cbch) { uint8_t cbits = chan_nr >> 3; uint8_t tn = chan_nr & 0x7; @@ -90,11 +90,11 @@ static uint32_t chan_nr2mf_task_mask(uint8_t chan_nr, uint8_t neigh_mode) master_task = MF_TASK_TCH_H_0 + lch_idx; } else if ((cbits & 0x1c) == 0x04) { lch_idx = cbits & 0x3; - master_task = MF_TASK_SDCCH4_0 + lch_idx; + master_task = cbch ? MF_TASK_SDCCH4_CBCH : (MF_TASK_SDCCH4_0 + lch_idx); multiframe = MF51; } else if ((cbits & 0x18) == 0x08) { lch_idx = cbits & 0x7; - master_task = MF_TASK_SDCCH8_0 + lch_idx; + master_task = cbch ? MF_TASK_SDCCH8_CBCH : (MF_TASK_SDCCH8_0 + lch_idx); multiframe = MF51; #if 0 } else if (cbits == 0x10) { @@ -225,8 +225,9 @@ static void l1ctl_rx_dm_est_req(struct msgb *msg) struct l1ctl_info_ul *ul = (struct l1ctl_info_ul *) l1h->data; struct l1ctl_dm_est_req *est_req = (struct l1ctl_dm_est_req *) ul->payload; - printd("L1CTL_DM_EST_REQ (arfcn=%u, chan_nr=0x%02x, tsc=%u)\n", - ntohs(est_req->h0.band_arfcn), ul->chan_nr, est_req->tsc); + printd("L1CTL_DM_EST_REQ (arfcn=%u, chan_nr=0x%02x, tsc=%u, flags=0x%x)\n", + ntohs(est_req->h0.band_arfcn), ul->chan_nr, est_req->tsc, + est_req->dm_flags); /* disable neighbour cell measurement of C0 TS 0 */ mframe_disable(MF_TASK_NEIGH_PM51_C0T0); @@ -262,7 +263,8 @@ static void l1ctl_rx_dm_est_req(struct msgb *msg) } /* figure out which MF tasks to enable */ - l1a_mftask_set(chan_nr2mf_task_mask(ul->chan_nr, NEIGH_MODE_PM)); + l1a_mftask_set(chan_nr2mf_task_mask(ul->chan_nr, NEIGH_MODE_PM, + est_req->dm_flags & L1CTL_DM_F_CBCH)); } /* receive a L1CTL_DM_FREQ_REQ from L23 */ diff --git a/src/target/firmware/layer1/mframe_sched.c b/src/target/firmware/layer1/mframe_sched.c index f3a6b43..0a9ff1e 100644 --- a/src/target/firmware/layer1/mframe_sched.c +++ b/src/target/firmware/layer1/mframe_sched.c @@ -198,6 +198,15 @@ static const struct mframe_sched_item mf_sdcch8_7[] = { { .sched_set = NULL } }; +static const struct mframe_sched_item mf_sdcch8_cbch[] = { + { .sched_set = NB_QUAD_FH_DL, .modulo = 51, .frame_nr = 8 }, + { .sched_set = NULL } +}; +static const struct mframe_sched_item mf_sdcch4_cbch[] = { + { .sched_set = NB_QUAD_DL, .modulo = 51, .frame_nr = 32 }, + { .sched_set = NULL } +}; + /* Measurement for MF 51 C0 */ static const struct mframe_sched_item mf_neigh_pm51_c0t0[] = { { .sched_set = NEIGH_PM , .modulo = 51, .frame_nr = 0 }, @@ -327,6 +336,9 @@ static const struct mframe_sched_item *sched_set_for_task[32] = { [MF_TASK_SDCCH8_6] = mf_sdcch8_6, [MF_TASK_SDCCH8_7] = mf_sdcch8_7, + [MF_TASK_SDCCH4_CBCH] = mf_sdcch4_cbch, + [MF_TASK_SDCCH8_CBCH] = mf_sdcch8_cbch, + [MF_TASK_TCH_F_EVEN] = mf_tch_f_even, [MF_TASK_TCH_F_ODD] = mf_tch_f_odd, [MF_TASK_TCH_H_0] = mf_tch_h_0, @@ -361,6 +373,7 @@ uint8_t mframe_task2chan_nr(enum mframe_task mft, uint8_t ts) cbits = 0x04 + 1; break; case MF_TASK_SDCCH4_2: + case MF_TASK_SDCCH4_CBCH: cbits = 0x04 + 2; break; case MF_TASK_SDCCH4_3: @@ -373,6 +386,7 @@ uint8_t mframe_task2chan_nr(enum mframe_task mft, uint8_t ts) cbits = 0x08 + 1; break; case MF_TASK_SDCCH8_2: + case MF_TASK_SDCCH8_CBCH: cbits = 0x08 + 2; break; case MF_TASK_SDCCH8_3: -- 1.7.0.4 From 246tnt at gmail.com Sat Jan 5 23:58:00 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 6 Jan 2013 00:58:00 +0100 Subject: [PATCH v2] l1: add CBCH flag to dedicated mode In-Reply-To: References: <4473982493dd1138f3867c59c16903288fcf64ef.1357153336.git.vamposdecampos@gmail.com> Message-ID: > Add a .dm_flags member to struct l1ctl_dm_est_req. Define a flag bit > to indicate CBCH mode. If set, this instructs L1 to use the CBCH > variant of SDCCH for dedicated mode (no uplink, no SACCH). > > Add the new dm_flags field to l1ctl_tx_dm_est_req* API calls. Clear it > everywhere, except for app_cbch_sniff which requests CBCH. > > Signed-off-by: Alex Badea I've put it in my testing branch to make sure I don't loose it. I want to think about it a bit more (mostly to see how I could merge other stuff in mainline by adding other 'flags'). Cheers, Sylvain From holger at freyther.de Sun Jan 6 08:02:39 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sun, 6 Jan 2013 09:02:39 +0100 Subject: [PATCH v2] l1: add CBCH flag to dedicated mode In-Reply-To: References: <4473982493dd1138f3867c59c16903288fcf64ef.1357153336.git.vamposdecampos@gmail.com> Message-ID: <20130106080239.GN28715@xiaoyu.lan> On Sun, Jan 06, 2013 at 12:58:00AM +0100, Sylvain Munaut wrote: > I've put it in my testing branch to make sure I don't loose it. I want > to think about it a bit more (mostly to see how I could merge other > stuff in mainline by adding other 'flags'). will you keep your testing branch? I removed build testing yesterday but I can re-add the Jenkins job if you want to. holger From 246tnt at gmail.com Sun Jan 6 09:40:08 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 6 Jan 2013 10:40:08 +0100 Subject: [PATCH v2] l1: add CBCH flag to dedicated mode In-Reply-To: <20130106080239.GN28715@xiaoyu.lan> References: <4473982493dd1138f3867c59c16903288fcf64ef.1357153336.git.vamposdecampos@gmail.com> <20130106080239.GN28715@xiaoyu.lan> Message-ID: Hi, > will you keep your testing branch? I removed build testing yesterday but > I can re-add the Jenkins job if you want to. Yes, I always keep it with more exotic stuff or hacks in there, but I don't think the build testing is necessary now that the build system changes are merged. Cheers, Sylvain From andreas at eversberg.eu Thu Jan 3 13:10:10 2013 From: andreas at eversberg.eu (jolly) Date: Thu, 03 Jan 2013 14:10:10 +0100 Subject: linking sdr trx with osmo-bts/openbsc Message-ID: <50E58332.2040308@eversberg.eu> hi thomas, i saw your work for your master of science. i must say: congratulations! it really brings both openbts and openbsc projects together. it allows to use both sdr and real bts together in one network. as shown at the chaos communication congress (29c3), sylvain presented a compal phone with firmware to turn it into a trx for openbts. with your code, it is possible to use it with openbsc. this is something i aimed at too. i like to know if your work is (only) a proof of concept or something that could be used in a productive environment. i would help to review the changes to osmo-bts and help to get them merged to the current master branch. iirc, there are just some fixes and minor issues to solve. i already had planed a similar approach: but instead of using source from openbts, i wanted to do scheduling and coding/fec inside osmo-bts. code from libosmocore could be used for that. instead of using the device to the femto-dsp as an interface, i wanted to add the trx manager's udp interface to osmo-bts code. this way it would not require an additional process to run a trx with osmo-bts. special things regarding to the trx could be configured with the osmo-bts' config. as some guys at the 29c3 might have noticed, i was a little shocked when i read about your work. i was highly motivated to do a work that i found it was already done, so my motivation dropped to zero. i would like to apologize for my bad mood at the congress. best regards, andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: From tacooper at vt.edu Thu Jan 3 14:20:42 2013 From: tacooper at vt.edu (Tom Cooper) Date: Thu, 3 Jan 2013 09:20:42 -0500 Subject: linking sdr trx with osmo-bts/openbsc In-Reply-To: <50E58332.2040308@eversberg.eu> References: <50E58332.2040308@eversberg.eu> Message-ID: On Thu, Jan 3, 2013 at 8:10 AM, jolly wrote: > hi thomas, > > i saw your work for your master of science. i must say: congratulations! it > really brings both openbts and openbsc projects together. it allows to use > both sdr and real bts together in one network. as shown at the chaos > communication congress (29c3), sylvain presented a compal phone with > firmware to turn it into a trx for openbts. with your code, it is possible > to use it with openbsc. this is something i aimed at too. > > i like to know if your work is (only) a proof of concept or something that > could be used in a productive environment. i would help to review the > changes to osmo-bts and help to get them merged to the current master > branch. iirc, there are just some fixes and minor issues to solve. Thanks, I'm glad my contribution is useful in some way to the community. I think it's safe to say it's mostly proof of concept; although I was able to get it running and working pretty well on my setup, others have told me they have problems. As I graduated and no longer have a USRP, I can't really do much troubleshooting unfortunately. Also since I was pressed for time to graduate, the code may not have all the bugs worked out or be fully tested for all different GSM scenarios and machines. You are correct about the osmo-bts changes being minor fixes. I remember Harald wanted me to get everything straightened up, but I just have never had the time. I'm sure any help from you on this work would be appreciated. His plan was: * remove your re-implemented headers and use our real header files (git clone git at git.sysmocom.de:sysmo-bts/femtobts-firmware.git) * get it working with most current public version of OpenBTS and osmo-bts * we can merge the osmo-bts part almost immediately * see if and how the OpenBTS part can be merged into the official range networks tree, or keep a custom git tree on git.osmocom.org > > i already had planed a similar approach: but instead of using source from > openbts, i wanted to do scheduling and coding/fec inside osmo-bts. code from > libosmocore could be used for that. instead of using the device to the > femto-dsp as an interface, i wanted to add the trx manager's udp interface > to osmo-bts code. this way it would not require an additional process to run > a trx with osmo-bts. special things regarding to the trx could be configured > with the osmo-bts' config. > > as some guys at the 29c3 might have noticed, i was a little shocked when i > read about your work. i was highly motivated to do a work that i found it > was already done, so my motivation dropped to zero. i would like to > apologize for my bad mood at the congress. Your plan to discard the extra OpenBTS process by moving its L1 to osmo-bts sounds great. I would have preferred to do it that way if I had more time. I'm sorry to have ruined your motivation, hopefully you can be inspired to improve/merge with my work! Let me know if I can help with anything (with my limited capabilities). -Tom C. > > best regards, > > andreas > > From krummeich at mac.com Fri Jan 4 22:34:07 2013 From: krummeich at mac.com (Karsten Krummeich) Date: Fri, 04 Jan 2013 22:34:07 +0000 (GMT) Subject: No r-gsm cell shown in mobile app Message-ID: Hi, I'm thinking about why the mobile app don't show me the German GSM-R (MCC: 262, MNC: 10) cells they are around me. The rssi app shows me the cells (e. g. ARFCN: 957 and 961). I'm using the sylvain/testing branch and I am searching for more details in the source code and found in settings.c that the r gsm band are enabled and in the freq_list. Can someone tell me another point for searching in source? Thanks in advance. Best regards. ? kasio -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Sat Jan 5 09:34:03 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sat, 5 Jan 2013 10:34:03 +0100 Subject: No r-gsm cell shown in mobile app In-Reply-To: References: Message-ID: > I'm thinking about why the mobile app don't show me the German GSM-R (MCC: > 262, MNC: 10) cells they are around me. > The rssi app shows me the cells (e. g. ARFCN: 957 and 961). > I'm using the sylvain/testing branch and I am searching for more details in > the source code and found in settings.c that the r gsm band are enabled and > in the freq_list. > Can someone tell me another point for searching in source? Are you sure the band is enabled in the configuration ? if you do 'show run' in the vty you should see the 'support' section that has 'r-gsm' Cheers, Sylvain From krummeich at mac.com Sat Jan 5 11:09:24 2013 From: krummeich at mac.com (Karsten Krummeich) Date: Sat, 05 Jan 2013 12:09:24 +0100 Subject: No r-gsm cell shown in mobile app In-Reply-To: References: Message-ID: Hi Sylvain, yes I'm sure the r-gsm band is enabled in the mobile.cfg and I've checked it with 'show run' again. But now I have trouble with the mobile app, it's not registered to my home PLMN (O2). I think it is a SIM reader problem or my SIM card. Have you another idea why the r gsm band not shown with 'show cell 1'? Thanks in advance. Best regards. kasio On 05.01.2013, at 10:34, Sylvain Munaut <246tnt at gmail.com> wrote: >> I'm thinking about why the mobile app don't show me the German GSM-R (MCC: >> 262, MNC: 10) cells they are around me. >> The rssi app shows me the cells (e. g. ARFCN: 957 and 961). >> I'm using the sylvain/testing branch and I am searching for more details in >> the source code and found in settings.c that the r gsm band are enabled and >> in the freq_list. >> Can someone tell me another point for searching in source? > > Are you sure the band is enabled in the configuration ? > > if you do 'show run' in the vty you should see the 'support' section > that has 'r-gsm' > > Cheers, > > Sylvain From 246tnt at gmail.com Sat Jan 5 11:49:30 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sat, 5 Jan 2013 12:49:30 +0100 Subject: No r-gsm cell shown in mobile app In-Reply-To: References: Message-ID: Hi, > Have you another idea why the r gsm band not shown with 'show cell 1'? I'm not that familiar with the cell selection process, but I would guess it's possible that 'mobile' obeys the normal rules for cell selection and so maybe the gsm-r cell you see are 'barred' or required 'access class' that your sim doesn't have and so are rejected as potential cell. The sim also contains a list of forbidden PLMN that should not be considered at all so maybe the gsm-r network is listed there ... You can probably see what's happening if you start a power scan and see if the network is scanned at all. (might want to redirect logs to a file for easier analysis) Cheers, Sylvain From andreas at eversberg.eu Sat Jan 5 14:14:02 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Sat, 05 Jan 2013 15:14:02 +0100 Subject: No r-gsm cell shown in mobile app In-Reply-To: References: Message-ID: <50E8352A.20500@eversberg.eu> Karsten Krummeich wrote: > Have you another idea why the r gsm band not shown with 'show cell 1'? hi karsten, if the sim stores the last network, the selection process will only scan cells until the last network is found. you can switch network selection to manual. this should trigger a complete search. if not there is a vty-command "network search" (iirc) to trigger complete search again. regards, andreas From kheimerl at cs.berkeley.edu Sat Jan 5 04:45:56 2013 From: kheimerl at cs.berkeley.edu (Kurtis Heimerl) Date: Fri, 4 Jan 2013 20:45:56 -0800 Subject: PySIM write SMSC Message-ID: Hey Baseband, I've got a stock of SIMs I bought and programmed already, but I unfortunately (and stupidly) forgot to set the SMSC. This is causing me heaps of issues, as each phone now has to have the SMSC set manually. I was hoping to hack up a quick script which just inserts the SMSC onto the SIM without needing to regenerate the ki or IMSI. Lining those up with my database is rife with hazard. Looking at the pySim-prog, it looks like this probably isn't possible; all of the data seems to get bundled together and so changing the SMSC length will cause other data to be corrupted. Is that right? I just wanted to see what ya'll think would be the best way for me to remedy my particular stupidity. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Sat Jan 5 09:45:36 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sat, 5 Jan 2013 10:45:36 +0100 Subject: PySIM write SMSC In-Reply-To: References: Message-ID: Hi, > I've got a stock of SIMs I bought and programmed already, but I > unfortunately (and stupidly) forgot to set the SMSC. What type of SIMs exactly and how did you program them ? pySIM sets a default SMSC if you don't set one ... > Looking at the pySim-prog, it looks like this probably isn't possible; all > of the data seems to get bundled together and so changing the SMSC length > will cause other data to be corrupted. Is that right? I just wanted to see > what ya'll think would be the best way for me to remedy my particular > stupidity. If you look in the ccc branch of pySIM, there is a ccc-fix.py script that was written during 27C3 for fixing SMSC on cards we wrote (at the time pysim was creating a corrupt smsc entry). It won't work "as-is", but you can look at the internal logic and adapt ... essentially it read the personalization file, fix it and rewrites it entirely. Cheers, Sylvain From kheimerl at cs.berkeley.edu Sat Jan 5 10:21:59 2013 From: kheimerl at cs.berkeley.edu (Kurtis Heimerl) Date: Sat, 5 Jan 2013 02:21:59 -0800 Subject: PySIM write SMSC In-Reply-To: References: Message-ID: They're programmable as 'sysmosim-gr1' with pysim, that's all I really know. I bought them programmed from a vendor in China, who promptly screwed up the SMSC on 1000 sim cards. I'll take a look at the branch, seems very similar to what I need. Thanks! On Saturday, January 5, 2013, Sylvain Munaut <246tnt at gmail.com> wrote: > Hi, > > > I've got a stock of SIMs I bought and programmed already, but I > > unfortunately (and stupidly) forgot to set the SMSC. > > What type of SIMs exactly and how did you program them ? > > pySIM sets a default SMSC if you don't set one ... > > > > Looking at the pySim-prog, it looks like this probably isn't possible; > all > > of the data seems to get bundled together and so changing the SMSC length > > will cause other data to be corrupted. Is that right? I just wanted to > see > > what ya'll think would be the best way for me to remedy my particular > > stupidity. > > If you look in the ccc branch of pySIM, there is a ccc-fix.py script > that was written during 27C3 for fixing SMSC on cards we wrote (at the > time pysim was creating a corrupt smsc entry). > > It won't work "as-is", but you can look at the internal logic and > adapt ... essentially it read the personalization file, fix it and > rewrites it entirely. > > > Cheers, > > Sylvain > -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at freyther.de Sun Jan 6 08:08:41 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sun, 6 Jan 2013 09:08:41 +0100 Subject: PySIM write SMSC In-Reply-To: References: Message-ID: <20130106080841.GQ28715@xiaoyu.lan> On Sat, Jan 05, 2013 at 02:21:59AM -0800, Kurtis Heimerl wrote: > They're programmable as 'sysmosim-gr1' with pysim, that's all I really > know. I bought them programmed from a vendor in China, who promptly screwed > up the SMSC on 1000 sim cards. You are already lucky that you got the right CardOS, nothing like punching out thousands of SIM cards by hand and sending them back. holger From kheimerl at cs.berkeley.edu Mon Jan 7 02:50:31 2013 From: kheimerl at cs.berkeley.edu (Kurtis Heimerl) Date: Mon, 7 Jan 2013 11:50:31 +0900 Subject: PySIM write SMSC In-Reply-To: <20130106080841.GQ28715@xiaoyu.lan> References: <20130106080841.GQ28715@xiaoyu.lan> Message-ID: Definitely. Moreso because "sending them back" isn't all that possible where I am (Papua) anyhow, on account of the lack of a postal service. On Sunday, January 6, 2013, Holger Hans Peter Freyther wrote: > On Sat, Jan 05, 2013 at 02:21:59AM -0800, Kurtis Heimerl wrote: > > They're programmable as 'sysmosim-gr1' with pysim, that's all I really > > know. I bought them programmed from a vendor in China, who promptly > screwed > > up the SMSC on 1000 sim cards. > > You are already lucky that you got the right CardOS, nothing like punching > out > thousands of SIM cards by hand and sending them back. > > holger > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailman-bounces at lists.osmocom.org Sat Jan 5 08:00:05 2013 From: mailman-bounces at lists.osmocom.org (mailman-bounces at lists.osmocom.org) Date: Sat, 05 Jan 2013 09:00:05 +0100 Subject: baseband-devel unsubscribe notification Message-ID: osmocom at slewe.com has been removed from baseband-devel. From andreas at eversberg.eu Sat Jan 5 11:22:40 2013 From: andreas at eversberg.eu (jolly) Date: Sat, 05 Jan 2013 12:22:40 +0100 Subject: fix of osmoload, flashing c155 works Message-ID: <50E80D00.1050802@eversberg.eu> hi, just fixed the issue from 29c3, where flashing of phones did not work anymore. if no one complains, i will apply it. it is also possible to flash c155 phones. the original compal boot loader will start firmware at 0x20000 instead of 0x2000 (c123), so i modified the linker scripts for compal_e99. i am not sure, if all c155 phones behave the same. to check this, i dumped some pages of the flash memory: run the loader: $ host/osmocon/osmocon -p /dev/ttyUSB0 -m c155 target/firmware/board/compal_e99/loader.compalram.bin start the phone and dump some flash: $ host/osmocon/osmoload memdump 0x000000 0x30000 dump a hexdump of that dump showed me where the actual firmware starts: ... 0000800 4f42 544f 392e 2e30 3530 0000 0000 0000 0000810 3031 3330 0101 0000 ffff ffff ffff ffff 0000820 ffff ffff ffff ffff ffff ffff ffff ffff * 0020000 4f43 4544 392e 2e30 3130 0000 0000 0000 0020010 4c46 5845 392e 2e30 3130 302e 0031 0000 0020020 5352 4b50 392e 2e30 3130 302e 0031 0000 ... i would like to know, if this is true for other c155 phones. regards, andreas -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Fix-Correctly-handle-return-value-of-msgb_pull.patch URL: From jolly at eversberg.eu Sat Jan 5 10:13:44 2013 From: jolly at eversberg.eu (Andreas Eversberg) Date: Sat, 5 Jan 2013 11:13:44 +0100 Subject: [PATCH] Fix: Correctly handle return value of msgb_pull() Message-ID: Now it is possible to use osmoload again to flash. Flashing was successfully tested with c123 and c155. --- src/host/osmocon/osmoload.c | 2 +- src/target/firmware/apps/loader/main.c | 7 +++++-- src/target/firmware/apps/loader_mtk/main.c | 4 ++-- 3 files changed, 8 insertions(+), 5 deletions(-) diff --git a/src/host/osmocon/osmoload.c b/src/host/osmocon/osmoload.c index 9b64935..e83f98a 100644 --- a/src/host/osmocon/osmoload.c +++ b/src/host/osmocon/osmoload.c @@ -307,7 +307,7 @@ loader_handle_reply(struct msgb *msg) { length = msgb_pull_u8(msg); crc = msgb_pull_u16(msg); address = msgb_pull_u32(msg); - data = msgb_pull(msg, length); + data = msgb_pull(msg, length) - length; break; case LOADER_MEM_WRITE: length = msgb_pull_u8(msg); diff --git a/src/target/firmware/apps/loader/main.c b/src/target/firmware/apps/loader/main.c index 50a39dd..fd07d0f 100644 --- a/src/target/firmware/apps/loader/main.c +++ b/src/target/firmware/apps/loader/main.c @@ -273,7 +273,7 @@ static void cmd_handler(uint8_t dlci, struct msgb *msg) crc = msgb_pull_u16(msg); address = msgb_pull_u32(msg); - data = msgb_pull(msg, nbytes); + data = msgb_pull(msg, nbytes) - nbytes; mycrc = osmo_crc16(0, data, nbytes); @@ -391,7 +391,7 @@ static void cmd_handler(uint8_t dlci, struct msgb *msg) chip = msgb_pull_u8(msg); address = msgb_pull_u32(msg); - data = msgb_pull(msg, nbytes); + data = msgb_pull(msg, nbytes) - nbytes; mycrc = osmo_crc16(0, data, nbytes); @@ -439,6 +439,9 @@ static void key_handler(enum key_codes code, enum key_states state) puts("Resetting due to keypress.\n"); device_reset(); break; + case KEY_MENU: + device_jump((void *)0x10000); + break; default: break; } diff --git a/src/target/firmware/apps/loader_mtk/main.c b/src/target/firmware/apps/loader_mtk/main.c index 7748dc4..3a12d27 100644 --- a/src/target/firmware/apps/loader_mtk/main.c +++ b/src/target/firmware/apps/loader_mtk/main.c @@ -213,7 +213,7 @@ static void cmd_handler(uint8_t dlci, struct msgb *msg) crc = msgb_pull_u16(msg); address = msgb_pull_u32(msg); - data = msgb_pull(msg, nbytes); + data = msgb_pull(msg, nbytes) - nbytes; mycrc = osmo_crc16(0, data, nbytes); @@ -331,7 +331,7 @@ static void cmd_handler(uint8_t dlci, struct msgb *msg) chip = msgb_pull_u8(msg); address = msgb_pull_u32(msg); - data = msgb_pull(msg, nbytes); + data = msgb_pull(msg, nbytes) - nbytes; mycrc = osmo_crc16(0, data, nbytes); -- 1.7.3.4 --------------060605070405050509030107 Content-Type: text/plain; name="0001-Generate-Compal-E99-binaries-for-loader-and-flash-lo.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="0001-Generate-Compal-E99-binaries-for-loader-and-flash-lo.pa"; filename*1="tch" From jolly at eversberg.eu Sat Jan 5 11:05:44 2013 From: jolly at eversberg.eu (Andreas Eversberg) Date: Sat, 5 Jan 2013 12:05:44 +0100 Subject: [PATCH] Generate Compal E99 binaries for loader and flash locations Message-ID: Loader binaries start at 0x20000 at flash memory. This is where the Compal loader jumps to. Flash binaries start at 0x30000 at flash memory. --- src/target/firmware/Makefile | 12 +- src/target/firmware/board/compal_e99/flash.lds | 134 +++++++++++++++++++++ src/target/firmware/board/compal_e99/loader.lds | 147 +++++++++++++++++++++++ 3 files changed, 288 insertions(+), 5 deletions(-) create mode 100644 src/target/firmware/board/compal_e99/flash.lds create mode 100644 src/target/firmware/board/compal_e99/loader.lds diff --git a/src/target/firmware/Makefile b/src/target/firmware/Makefile index a71eef6..c76bcd0 100644 --- a/src/target/firmware/Makefile +++ b/src/target/firmware/Makefile @@ -66,11 +66,13 @@ compal_e86_ENVIRONMENTS=$(compal_COMMON_ENVIRONMENTS) # Compal E99 compal_e99_OBJS=$(compal_COMMON_OBJS) board/compal_e99/init.o battery/dummy.o $(FB_e99_OBJS) -compal_e99_ENVIRONMENTS=$(compal_COMMON_ENVIRONMENTS) +compal_e99_ENVIRONMENTS=$(compal_COMMON_ENVIRONMENTS) e99loader e99flash e99loader_LDS=board/compal_e99/loader.lds -e99loader_OBJS=board/compal/header.o +e99loader_OBJS=board/compal/start.rom.o board/compal/header.o board/compal/exceptions_redirect.o + e99flash_LDS=board/compal_e99/flash.lds +e99flash_OBJS=board/compal/start.rom.o board/compal/header.o board/compal/exceptions_redirected.o board/compal/handlers.o # Sony Ericsson J100 (made by Compal) @@ -99,10 +101,10 @@ ANY_APP_LIBS+=calypso/libcalypso.a layer1/liblayer1.a lib/libmini.a comm/libcomm -include Makefile.inc # Uncomment this line if you want to enable Tx (Transmit) Support. -#CFLAGS += -DCONFIG_TX_ENABLE +CFLAGS += -DCONFIG_TX_ENABLE # Uncomment this line if you want to write to flash. -#CFLAGS += -DCONFIG_FLASH_WRITE +CFLAGS += -DCONFIG_FLASH_WRITE # Uncomment this line if you want to write to flash, including the bootloader. -#CFLAGS += -DCONFIG_FLASH_WRITE_LOADER +CFLAGS += -DCONFIG_FLASH_WRITE_LOADER diff --git a/src/target/firmware/board/compal_e99/flash.lds b/src/target/firmware/board/compal_e99/flash.lds new file mode 100644 index 0000000..1cf189f --- /dev/null +++ b/src/target/firmware/board/compal_e99/flash.lds @@ -0,0 +1,134 @@ +/* + * Linker script for flashed applications on the Compal E99 + * + * This script creates a binary that can be linked at 0xFFFF, starting + * with the second flash page. This is what a phone application or + * pure layer1 device uses. + * + * XXX: interrupts? + * + */ +OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm") +OUTPUT_ARCH(arm) +ENTRY(_start) +MEMORY +{ + LOADR (rx) : ORIGIN = 0x00000000, LENGTH = 0x30000 + /* 2 MBytes of external flash memory (minus loader) */ + FLASH (rx) : ORIGIN = 0x00030000, LENGTH = 0x1F0000 + /* 256 kBytes of internal zero-waitstate sram */ + IRAM (rw) : ORIGIN = 0x00800000, LENGTH = 0x040000 + /* 256 kBytes of external slow sram */ + ERAM (rw) : ORIGIN = 0x01000000, LENGTH = 0x040000 +} +SECTIONS +{ + /* entrypoint */ + .text.start : { + PROVIDE(_start = .); + KEEP(*(.text.start)) + *(.text.start) + } > FLASH + + /* exception vectors from 0x80001c to 0x800034 */ + .text.exceptions 0x80001c : { + KEEP(*(.text.exceptions)) + * (.text.exceptions) + . = ALIGN(4); + } > IRAM AT> FLASH + PROVIDE(_exceptions = LOADADDR(.text.exceptions)); + + /* code */ + .text : { + /* regular code */ + *(.text*) + /* gcc voodoo */ + *(.glue_7t) *(.glue_7) *(.vfp11_veneer) *(.v4_bx) + } > FLASH + PROVIDE(_text_start = ADDR(.text)); + PROVIDE(_text_end = ADDR(.text) + SIZEOF(.text)); + + /* constructor pointers */ + .ctors : { + /* ctor count */ + LONG(SIZEOF(.ctors) / 4 - 2) + /* ctor pointers */ + KEEP(*(SORT(.ctors))) + /* end of list */ + LONG(0) + } > FLASH + PROVIDE(_ctor_start = LOADADDR(.ctors)); + PROVIDE(_ctor_end = LOADADDR(.ctors) + SIZEOF(.ctors)); + + /* destructor pointers */ + .dtors : { + /* dtor count */ + LONG(SIZEOF(.dtors) / 4 - 2) + /* dtor pointers */ + KEEP(*(SORT(.dtors))) + /* end of list */ + LONG(0) + } > FLASH + PROVIDE(_dtor_start = LOADADDR(.dtors)); + PROVIDE(_dtor_end = LOADADDR(.dtors) + SIZEOF(.dtors)); + + /* read-only data */ + .rodata : { + *(.rodata*) + } > FLASH + PROVIDE(_rodata_start = ADDR(.rodata)); + PROVIDE(_rodata_end = ADDR(.rodata) + SIZEOF(.rodata)); + + /* pic offset tables */ + .got : { + . = ALIGN(4); + *(.got) + *(.got.plt) *(.igot.plt) *(.got) *(.igot) + . = ALIGN(4); + } > FLASH + PROVIDE(_got_start = ADDR(.got)); + PROVIDE(_got_end = ADDR(.got) + SIZEOF(.got)); + + /* reserved ram */ + .compal.reservedram 0x800000 (NOLOAD) : { + . = 0xff; + } > IRAM + + /* initialized data */ + .data : AT (LOADADDR(.got) + SIZEOF(.got)) { + . = ALIGN(4); + *(.data) + . = ALIGN(4); + } > IRAM + PROVIDE(__data_start = LOADADDR(.data)); + PROVIDE(__data_end = LOADADDR(.data) + SIZEOF(.data)); + PROVIDE(_data_start = ADDR(.data)); + PROVIDE(_data_end = ADDR(.data) + SIZEOF(.data)); + + /* ram code */ + .ramtext : AT (LOADADDR(.data) + SIZEOF(.data)) { + . = ALIGN(4); + *(.ramtext) + . = ALIGN(4); + } > IRAM + PROVIDE(__ramtext_start = LOADADDR(.ramtext)); + PROVIDE(__ramtext_end = LOADADDR(.ramtext) + SIZEOF(.ramtext)); + PROVIDE(_ramtext_start = ADDR(.ramtext)); + PROVIDE(_ramtext_end = ADDR(.ramtext) + SIZEOF(.ramtext)); + + /* uninitialized data */ + .bss (NOLOAD) : { + . = ALIGN(4); + *(.bss) + . = ALIGN(4); + } > IRAM + PROVIDE(__bss_start = ADDR(.bss)); + PROVIDE(__bss_end = ADDR(.bss) + SIZEOF(.bss)); + PROVIDE(_bss_start = __bss_start); + PROVIDE(_bss_end = __bss_end); + + /* end of image */ + . = ALIGN(4); + _end = .; + PROVIDE(end = .); +} diff --git a/src/target/firmware/board/compal_e99/loader.lds b/src/target/firmware/board/compal_e99/loader.lds new file mode 100644 index 0000000..bb117a8 --- /dev/null +++ b/src/target/firmware/board/compal_e99/loader.lds @@ -0,0 +1,147 @@ +/* + * Linker script for flashed loader on the Compal E99 + * + * This script creates a binary that can replace a standard firmware + * located at 0x20000. It works in conjunction with the compal ramloader. + * + * The interrupt vectors and start address are at known, fixed offsets. + * + */ +OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm") +OUTPUT_ARCH(arm) +ENTRY(_start) +MEMORY +{ + /* 2 MBytes of external flash memory */ + FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 0x200000 + /* 256 kBytes of internal zero-waitstate sram */ + IRAM (rw) : ORIGIN = 0x00800000, LENGTH = 0x040000 + /* 256 kBytes of external slow sram */ + ERAM (rw) : ORIGIN = 0x01000000, LENGTH = 0x040000 +} +SECTIONS +{ + /* Provide symbols for the compal loader */ + .compal.loader 0x00000000 (NOLOAD) : { + _compal_loader_start = .; + . = 0x2000; + _compal_loader_end = .; + } > FLASH + + /* Compal-style image header */ + .compal.header 0x00020000 : { + _compal_header_start = .; + KEEP(*(.compal.header)) + *(.compal.header) + . = 0xA0; + _compal_header_end = .; + } > FLASH + + /* Compal-style vector table */ + .compal.vectors 0x000200A0 : { + PROVIDE(_exceptions = .); + KEEP(*(.text.exceptions)) + *(.text.exceptions) + } > FLASH + + /* Compal-style entry point */ + .text.start 0x000200F8 : { + PROVIDE(_start = .); + KEEP(*(.text.start)) + *(.text.start) + } > FLASH + + /* code */ + .text : { + /* regular code */ + *(.text*) + /* gcc voodoo */ + *(.glue_7t) *(.glue_7) *(.vfp11_veneer) *(.v4_bx) + } > FLASH + PROVIDE(_text_start = ADDR(.text)); + PROVIDE(_text_end = ADDR(.text) + SIZEOF(.text)); + + /* constructor pointers */ + .ctors : { + /* ctor count */ + LONG(SIZEOF(.ctors) / 4 - 2) + /* ctor pointers */ + KEEP(*(SORT(.ctors))) + /* end of list */ + LONG(0) + } > FLASH + PROVIDE(_ctor_start = LOADADDR(.ctors)); + PROVIDE(_ctor_end = LOADADDR(.ctors) + SIZEOF(.ctors)); + + /* destructor pointers */ + .dtors : { + /* dtor count */ + LONG(SIZEOF(.dtors) / 4 - 2) + /* dtor pointers */ + KEEP(*(SORT(.dtors))) + /* end of list */ + LONG(0) + } > FLASH + PROVIDE(_dtor_start = LOADADDR(.dtors)); + PROVIDE(_dtor_end = LOADADDR(.dtors) + SIZEOF(.dtors)); + + /* read-only data */ + .rodata : { + *(.rodata*) + } > FLASH + PROVIDE(_rodata_start = ADDR(.rodata)); + PROVIDE(_rodata_end = ADDR(.rodata) + SIZEOF(.rodata)); + + /* pic offset tables */ + .got : { + . = ALIGN(4); + *(.got) + *(.got.plt) *(.igot.plt) *(.got) *(.igot) + . = ALIGN(4); + } > FLASH + PROVIDE(_got_start = ADDR(.got)); + PROVIDE(_got_end = ADDR(.got) + SIZEOF(.got)); + + /* reserved ram */ + .compal.reservedram 0x800000 (NOLOAD) : { + . = 0xff; + } > IRAM + + /* initialized data */ + .data : AT (LOADADDR(.got) + SIZEOF(.got)) { + . = ALIGN(4); + *(.data) + . = ALIGN(4); + } > IRAM + PROVIDE(__data_start = LOADADDR(.data)); + PROVIDE(__data_end = LOADADDR(.data) + SIZEOF(.data)); + PROVIDE(_data_start = ADDR(.data)); + PROVIDE(_data_end = ADDR(.data) + SIZEOF(.data)); + + /* ram code */ + .ramtext : AT (LOADADDR(.data) + SIZEOF(.data)) { + . = ALIGN(4); + *(.ramtext) + . = ALIGN(4); + } > IRAM + PROVIDE(__ramtext_start = LOADADDR(.ramtext)); + PROVIDE(__ramtext_end = LOADADDR(.ramtext) + SIZEOF(.ramtext)); + PROVIDE(_ramtext_start = ADDR(.ramtext)); + PROVIDE(_ramtext_end = ADDR(.ramtext) + SIZEOF(.ramtext)); + + /* uninitialized data */ + .bss (NOLOAD) : { + . = ALIGN(4); + *(.bss) + . = ALIGN(4); + } > IRAM + PROVIDE(__bss_start = ADDR(.bss)); + PROVIDE(__bss_end = ADDR(.bss) + SIZEOF(.bss)); + PROVIDE(_bss_start = __bss_start); + PROVIDE(_bss_end = __bss_end); + + /* end of image */ + . = ALIGN(4); + _end = .; + PROVIDE(end = .); +} -- 1.7.3.4 --------------060605070405050509030107-- From 246tnt at gmail.com Sat Jan 5 14:14:39 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sat, 5 Jan 2013 15:14:39 +0100 Subject: fix of osmoload, flashing c155 works In-Reply-To: <50E80D00.1050802@eversberg.eu> References: <50E80D00.1050802@eversberg.eu> Message-ID: > just fixed the issue from 29c3, where flashing of phones did not work > anymore. if no one complains, i will apply it. 1) Can you make those patch over my testing branch instead ? The build system was completely reworked and the merge is going to suck if you change the makefile in master 2) Your patch enables TX and flash write by default, that's bad. Cheers, Sylvain From 246tnt at gmail.com Sat Jan 5 14:17:42 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sat, 5 Jan 2013 15:17:42 +0100 Subject: fix of osmoload, flashing c155 works In-Reply-To: References: <50E80D00.1050802@eversberg.eu> Message-ID: And wrt to the msgb_pull patch : - I'm not sure it's the correct way to fix it. Having mgb_pull return a pointer to the end of the bytes we just removed seems a very weird API ... maybe the bug is msgb_pull itself. - The addition of the handler for KEY_MENU should be a separate patch, not in that one. From andreas at eversberg.eu Sat Jan 5 14:27:23 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Sat, 05 Jan 2013 15:27:23 +0100 Subject: fix of osmoload, flashing c155 works In-Reply-To: References: <50E80D00.1050802@eversberg.eu> Message-ID: <50E8384B.9000802@eversberg.eu> Sylvain Munaut wrote: > - I'm not sure it's the correct way to fix it. Having mgb_pull return > a pointer to the end of the bytes we just removed seems a very weird > API ... maybe the bug is msgb_pull itself. for all msgb_pull_u* harald took this into account, so i think there is a reason for that. but i don't like this way either. > - The addition of the handler for KEY_MENU should be a separate > patch, not in that one. again i missed to remove that when creating diffs... From 246tnt at gmail.com Sat Jan 5 14:28:31 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sat, 5 Jan 2013 15:28:31 +0100 Subject: fix of osmoload, flashing c155 works In-Reply-To: References: <50E80D00.1050802@eversberg.eu> Message-ID: > - I'm not sure it's the correct way to fix it. Having mgb_pull return > a pointer to the end of the bytes we just removed seems a very weird > API ... maybe the bug is msgb_pull itself. Ok, I guess changing the api of pull wouldn't be a great idea because of other users and symmetry to _put ... But then, I would introduce a msgb_pull_buffer() or _data that returns a pointer to the buffer/data zone that's just been pulled. Cheers, Sylvain From andreas at eversberg.eu Sun Jan 6 05:12:26 2013 From: andreas at eversberg.eu (jolly) Date: Sun, 06 Jan 2013 06:12:26 +0100 Subject: fix of osmoload, flashing c155 works In-Reply-To: References: <50E80D00.1050802@eversberg.eu> Message-ID: <50E907BA.5020202@eversberg.eu> here is the patch for the current master. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Generate-Compal-E99-binaries-for-loader-and-flash-lo.patch URL: From andreas at eversberg.eu Sat Jan 5 14:18:34 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Sat, 05 Jan 2013 15:18:34 +0100 Subject: fix of osmoload, flashing c155 works In-Reply-To: References: <50E80D00.1050802@eversberg.eu> Message-ID: <50E8363A.3020407@eversberg.eu> Sylvain Munaut wrote: > 1) Can you make those patch over my testing branch instead ? The build > system was completely reworked and the merge is going to suck if you > change the makefile in master can do that. > 2) Your patch enables TX and flash write by default, that's bad. forgot to remove it. i will send you both patches after finishing. From 246tnt at gmail.com Sat Jan 5 14:52:03 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sat, 5 Jan 2013 15:52:03 +0100 Subject: [PATCH] core/msgb: Change return value of msgb_pull to the start of pulled header Message-ID: <1357397523-29643-1-git-send-email-246tnt@gmail.com> From: Sylvain Munaut Currently msgb_pull returns a pointer to the new start of msgb, which is pretty counter intuitive and when using msgb_pull is often annoying. For eg, the msgb_pull_u{8,16,32} were previously "fixed" for this quirk in a previous commit. The msgb_pull_l2h in lapdm is also wrong because of this, same for code in osmocom-bb loader. AFAICT, the current users of msgb_pull either don't care about the return value, or expect it to be a pointer to the pulled header and not the new start of msgb (and so are currently buggy). Without this patch, you have things like: struct foo *bar = msgb_pull(msg, sizeof(struct foo)) - sizeof(struct foo) With the patch, you have: struct foo *bar = msgb_pull(msg, sizeof(struct foo)); which is IMHO a much better style. Signed-off-by: Sylvain Munaut --- include/osmocom/core/msgb.h | 14 ++++++++------ 1 files changed, 8 insertions(+), 6 deletions(-) diff --git a/include/osmocom/core/msgb.h b/include/osmocom/core/msgb.h index a1939ab..4a72f2d 100644 --- a/include/osmocom/core/msgb.h +++ b/include/osmocom/core/msgb.h @@ -287,16 +287,18 @@ static inline unsigned char *msgb_push(struct msgb *msgb, unsigned int len) /*! \brief remove (pull) a header from the front of the message buffer * \param[in] msgb message buffer * \param[in] len number of octets to be pulled - * \returns pointer to new start of msgb + * \returns pointer to header that's been pulled (i.e. previous start of msgb) * * This function moves the \a data pointer of the \ref msgb further back * in the message, thereby shrinking the size of the message by \a len * bytes. */ static inline unsigned char *msgb_pull(struct msgb *msgb, unsigned int len) -{ +{ + unsigned char *tmp = msgb->data; msgb->len -= len; - return msgb->data += len; + msgb->data += len; + return tmp; } /*! \brief remove uint8 from front of message @@ -305,7 +307,7 @@ static inline unsigned char *msgb_pull(struct msgb *msgb, unsigned int len) */ static inline uint8_t msgb_pull_u8(struct msgb *msgb) { - uint8_t *space = msgb_pull(msgb, 1) - 1; + uint8_t *space = msgb_pull(msgb, 1); return space[0]; } /*! \brief remove uint16 from front of message @@ -314,7 +316,7 @@ static inline uint8_t msgb_pull_u8(struct msgb *msgb) */ static inline uint16_t msgb_pull_u16(struct msgb *msgb) { - uint8_t *space = msgb_pull(msgb, 2) - 2; + uint8_t *space = msgb_pull(msgb, 2); return space[0] << 8 | space[1]; } /*! \brief remove uint32 from front of message @@ -323,7 +325,7 @@ static inline uint16_t msgb_pull_u16(struct msgb *msgb) */ static inline uint32_t msgb_pull_u32(struct msgb *msgb) { - uint8_t *space = msgb_pull(msgb, 4) - 4; + uint8_t *space = msgb_pull(msgb, 4); return space[0] << 24 | space[1] << 16 | space[2] << 8 | space[3]; } -- 1.7.8.6 From vogelchr at vogel.cx Sat Jan 5 18:42:03 2013 From: vogelchr at vogel.cx (Christian Vogel) Date: Sat, 5 Jan 2013 19:42:03 +0100 Subject: libosmocore: [PATCH] Replace obsolete automake AM_CONFIG_HEADER. Message-ID: <20130105184203.GA10070@vogel.cx> Hi, I just setup a machine running ArchLinux which has a pretty recent automake/autoconf. libosmocore fails to build. Attached (trivial) patch fixes that. Someone with a really old toolchain/automake should check if it breaks setups we consider supported. Chris From vogelchr at vogel.cx Sat Jan 5 19:30:41 2013 From: vogelchr at vogel.cx (Christian Vogel) Date: Sat, 5 Jan 2013 20:30:41 +0100 Subject: [PATCH] Replace obsolete automake AM_CONFIG_HEADER. Message-ID: This fixes the following complaint by autoconf 2.69-1, automake 1.13.1-1. : configure.ac:80: error: 'AM_CONFIG_HEADER': this macro is obsolete. : You should use the 'AC_CONFIG_HEADERS' macro instead. : /usr/share/aclocal-1.13/obsolete-err.m4:12: AM_CONFIG_HEADER is expan : configure.ac:80: the top level Automake 1:1.11.3-1ubuntu2, autoconf 2.68-1ubuntu2 don't even emit a warning without, and work just fine with this patch. Signed-off-by: Christian Vogel --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 24ddd0c..fbc83f3 100644 --- a/configure.ac +++ b/configure.ac @@ -77,7 +77,7 @@ AC_DEFUN([CHECK_TM_INCLUDES_TM_GMTOFF], [ CHECK_TM_INCLUDES_TM_GMTOFF dnl Generate the output -AM_CONFIG_HEADER(config.h) +AC_CONFIG_HEADER(config.h) AC_ARG_ENABLE(talloc, [AS_HELP_STRING( -- 1.8.1 --VS++wcV0S1rZb1Fb-- From 246tnt at gmail.com Sat Jan 5 23:56:36 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 6 Jan 2013 00:56:36 +0100 Subject: libosmocore: [PATCH] Replace obsolete automake AM_CONFIG_HEADER. In-Reply-To: <20130105184203.GA10070@vogel.cx> References: <20130105184203.GA10070@vogel.cx> Message-ID: Hi, > I just setup a machine running ArchLinux which has a pretty recent > automake/autoconf. libosmocore fails to build. Attached (trivial) patch > fixes that. Someone with a really old toolchain/automake should check > if it breaks setups we consider supported. Merged. Cheers, Sylvain From vamposdecampos at gmail.com Sat Jan 5 18:59:00 2013 From: vamposdecampos at gmail.com (Alex Badea) Date: Sat, 5 Jan 2013 20:59:00 +0200 Subject: [PATCH libosmocore] timer_test: tweak path to config.h Message-ID: <33bbeea71794fbca796a103d74194b8eedcbb968.1357412292.git.vamposdecampos@gmail.com> When building out-of-srcdir, "../../config.h" fails to reach config.h because the compiler is invoked in $builddir/tests/, not $builddir/tests/timer/. Use "../config.h" instead; this also works for in-srcdir builds. Signed-off-by: Alex Badea --- tests/timer/timer_test.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/tests/timer/timer_test.c b/tests/timer/timer_test.c index ba3127d..bb9a177 100644 --- a/tests/timer/timer_test.c +++ b/tests/timer/timer_test.c @@ -33,7 +33,7 @@ #include #include -#include "../../config.h" +#include "../config.h" static void main_timer_fired(void *data); static void secondary_timer_fired(void *data); -- 1.7.0.4 From 246tnt at gmail.com Sat Jan 5 23:58:29 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 6 Jan 2013 00:58:29 +0100 Subject: [PATCH libosmocore] timer_test: tweak path to config.h In-Reply-To: <33bbeea71794fbca796a103d74194b8eedcbb968.1357412292.git.vamposdecampos@gmail.com> References: <33bbeea71794fbca796a103d74194b8eedcbb968.1357412292.git.vamposdecampos@gmail.com> Message-ID: > When building out-of-srcdir, "../../config.h" fails to reach config.h > because the compiler is invoked in $builddir/tests/, not > $builddir/tests/timer/. Use "../config.h" instead; this also works > for in-srcdir builds. > > Signed-off-by: Alex Badea Merged From vamposdecampos at gmail.com Sat Jan 5 18:59:12 2013 From: vamposdecampos at gmail.com (Alex Badea) Date: Sat, 5 Jan 2013 20:59:12 +0200 Subject: [PATCH libosmocore] doxyfiles: refer paths to @srcdir@ Message-ID: When building out-of-srcdir, paths such as "src/gsm" will not find any source files. Since the Doxyfiles are preprocessed, we can prepend @srcdir@ to fix that. Signed-off-by: Alex Badea --- Doxyfile.codec.in | 2 +- Doxyfile.core.in | 2 +- Doxyfile.gsm.in | 2 +- Doxyfile.vty.in | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/Doxyfile.codec.in b/Doxyfile.codec.in index fcd5122..1b0df5e 100644 --- a/Doxyfile.codec.in +++ b/Doxyfile.codec.in @@ -610,7 +610,7 @@ WARN_LOGFILE = # directories like "/usr/src/myproject". Separate the files or directories # with spaces. -INPUT = include/osmocom/codec src/codec +INPUT = @srcdir@/include/osmocom/codec @srcdir@/src/codec # This tag can be used to specify the character encoding of the source files # that doxygen parses. Internally doxygen uses the UTF-8 encoding, which is diff --git a/Doxyfile.core.in b/Doxyfile.core.in index 18eb226..ee58f80 100644 --- a/Doxyfile.core.in +++ b/Doxyfile.core.in @@ -610,7 +610,7 @@ WARN_LOGFILE = # directories like "/usr/src/myproject". Separate the files or directories # with spaces. -INPUT = include/osmocom/core src +INPUT = @srcdir@/include/osmocom/core @srcdir/@src # This tag can be used to specify the character encoding of the source files # that doxygen parses. Internally doxygen uses the UTF-8 encoding, which is diff --git a/Doxyfile.gsm.in b/Doxyfile.gsm.in index ab25b22..36a6ae2 100644 --- a/Doxyfile.gsm.in +++ b/Doxyfile.gsm.in @@ -610,7 +610,7 @@ WARN_LOGFILE = # directories like "/usr/src/myproject". Separate the files or directories # with spaces. -INPUT = include/osmocom/gsm include/osmocom/gsm/protocol src/gsm +INPUT = @srcdir@/include/osmocom/gsm @srcdir@/include/osmocom/gsm/protocol @srcdir@/src/gsm # This tag can be used to specify the character encoding of the source files # that doxygen parses. Internally doxygen uses the UTF-8 encoding, which is diff --git a/Doxyfile.vty.in b/Doxyfile.vty.in index 57f19ad..527cdb2 100644 --- a/Doxyfile.vty.in +++ b/Doxyfile.vty.in @@ -610,7 +610,7 @@ WARN_LOGFILE = # directories like "/usr/src/myproject". Separate the files or directories # with spaces. -INPUT = include/osmocom/vty src/vty +INPUT = @srcdir@/include/osmocom/vty @srcdir@/src/vty # This tag can be used to specify the character encoding of the source files # that doxygen parses. Internally doxygen uses the UTF-8 encoding, which is -- 1.7.0.4 From 246tnt at gmail.com Sat Jan 5 23:59:54 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 6 Jan 2013 00:59:54 +0100 Subject: [PATCH libosmocore] doxyfiles: refer paths to @srcdir@ In-Reply-To: References: Message-ID: > When building out-of-srcdir, paths such as "src/gsm" will not find any > source files. Since the Doxyfiles are preprocessed, we can prepend > @srcdir@ to fix that. > > Signed-off-by: Alex Badea Merged. Also applied an equivalent patch to libosmo-dsp. If anyone has created a Doxy template following the examples in libosmocore, you might want to check if that fix is required as well. Cheers, Sylvain From holger at freyther.de Sun Jan 6 08:04:31 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sun, 6 Jan 2013 09:04:31 +0100 Subject: [PATCH libosmocore] doxyfiles: refer paths to @srcdir@ In-Reply-To: References: Message-ID: <20130106080431.GO28715@xiaoyu.lan> On Sun, Jan 06, 2013 at 12:59:54AM +0100, Sylvain Munaut wrote: > Also applied an equivalent patch to libosmo-dsp. > > If anyone has created a Doxy template following the examples in > libosmocore, you might want to check if that fix is required as well. Hi, depending on what we do @abs_srcdir@ might better/worse. holger From vamposdecampos at gmail.com Sat Jan 5 19:26:24 2013 From: vamposdecampos at gmail.com (Alex Badea) Date: Sat, 5 Jan 2013 21:26:24 +0200 Subject: [PATCH libosmocore 0/8] Cell Broadcast (SMSCB) MS support Message-ID: <1357413992-25231-1-git-send-email-vamposdecampos@gmail.com> Hi, This a respin of my old series of patches[1], to add decoding of SMSCB messages on the MS side. The series defines a new smscb_entity, which can be fed L1 messages from a CBCH, performs reassembly, and constructs equivalent SMS Broadcast Command (RSL_MT_SMS_BC_CMD) messages for L3. I also have a follow-up patch for bb/cell_log which makes use of this functionality. Please review and consider for merging, thanks. [1] http://lists.osmocom.org/pipermail/baseband-devel/2010-November/000834.html Alex Badea (8): gsm: add skeleton smscb module smscb: add unit test for smscb_entity smscb: process Null messages smscb test: support a list of L1 messages to test smscb: add test-case for reassembling a normal message smscb: add test-case for reassembling a Schedule message smscb: implement reassembly smscb: hook into LAPDm include/Makefile.am | 1 + include/osmocom/gsm/lapdm.h | 3 + include/osmocom/gsm/smscb.h | 37 ++++++++ src/gsm/Makefile.am | 1 + src/gsm/lapdm.c | 13 +++ src/gsm/libosmogsm.map | 5 + src/gsm/smscb.c | 209 +++++++++++++++++++++++++++++++++++++++++++ tests/smscb/smscb_test.c | 118 ++++++++++++++++++++++++ tests/smscb/smscb_test.ok | 9 ++ tests/testsuite.at | 2 +- 10 files changed, 397 insertions(+), 1 deletions(-) create mode 100644 include/osmocom/gsm/smscb.h create mode 100644 src/gsm/smscb.c From vamposdecampos at gmail.com Sat Jan 5 19:26:25 2013 From: vamposdecampos at gmail.com (Alex Badea) Date: Sat, 5 Jan 2013 21:26:25 +0200 Subject: [PATCH libosmocore 1/8] gsm: add skeleton smscb module In-Reply-To: <1357413992-25231-1-git-send-email-vamposdecampos@gmail.com> References: <1357413992-25231-1-git-send-email-vamposdecampos@gmail.com> Message-ID: <1357413992-25231-2-git-send-email-vamposdecampos@gmail.com> Header files and skeleton functions for a SMSCB entity. Signed-off-by: Alex Badea --- include/Makefile.am | 1 + include/osmocom/gsm/smscb.h | 28 ++++++++++++++++++ src/gsm/Makefile.am | 1 + src/gsm/libosmogsm.map | 5 +++ src/gsm/smscb.c | 65 +++++++++++++++++++++++++++++++++++++++++++ 5 files changed, 100 insertions(+), 0 deletions(-) create mode 100644 include/osmocom/gsm/smscb.h create mode 100644 src/gsm/smscb.c diff --git a/include/Makefile.am b/include/Makefile.am index 60b9ea9..560fc54 100644 --- a/include/Makefile.am +++ b/include/Makefile.am @@ -66,6 +66,7 @@ nobase_include_HEADERS = \ osmocom/gsm/protocol/ipaccess.h \ osmocom/gsm/rsl.h \ osmocom/gsm/rxlev_stat.h \ + osmocom/gsm/smscb.h \ osmocom/gsm/sysinfo.h \ osmocom/gsm/tlv.h diff --git a/include/osmocom/gsm/smscb.h b/include/osmocom/gsm/smscb.h new file mode 100644 index 0000000..88ba6e2 --- /dev/null +++ b/include/osmocom/gsm/smscb.h @@ -0,0 +1,28 @@ +#ifndef _OSMOCOM_SMSCB_H +#define _OSMOCOM_SMSCB_H + +/*! \defgroup smscb SMSCB implementation according to GSM TS 03.41 + * @{ + */ + +/*! \file smscb.h */ + +struct msgb; +struct smscb_entity; + +typedef int (*smscb_cb_t)(struct msgb *msg, struct smscb_entity *se, void *ctx); + +/*! \brief a SMSCB Entity */ +struct smscb_entity { + smscb_cb_t l3_cb; /*!< \brief callback for sending stuff to L3 */ + void *l3_ctx; /*!< \brief context for layer3 instance */ +}; + +void smscb_init(struct smscb_entity *se); +void smscb_exit(struct smscb_entity *se); +void smscb_set_l3(struct smscb_entity *se, smscb_cb_t cb, void *ctx); +int smscb_ph_data_ind(struct smscb_entity *se, struct msgb *msg); + +/*! @} */ + +#endif /* _OSMOCOM_SMSCB_H */ diff --git a/src/gsm/Makefile.am b/src/gsm/Makefile.am index 6e2a785..3d79f7e 100644 --- a/src/gsm/Makefile.am +++ b/src/gsm/Makefile.am @@ -16,6 +16,7 @@ libosmogsm_la_SOURCES = a5.c rxlev_stat.c tlv_parser.c comp128.c gsm_utils.c \ gprs_cipher_core.c gsm0480.c abis_nm.c gsm0502.c \ gsm0411_utils.c gsm0411_smc.c gsm0411_smr.c \ lapd_core.c lapdm.c \ + smscb.c \ auth_core.c auth_comp128v1.c auth_milenage.c \ milenage/aes-encblock.c milenage/aes-internal.c \ milenage/aes-internal-enc.c milenage/milenage.c gan.c diff --git a/src/gsm/libosmogsm.map b/src/gsm/libosmogsm.map index b2278f1..674a85f 100644 --- a/src/gsm/libosmogsm.map +++ b/src/gsm/libosmogsm.map @@ -223,6 +223,11 @@ rxlev_stat_get_next; rxlev_stat_input; rxlev_stat_reset; +smscb_init; +smscb_exit; +smscb_set_l3; +smscb_ph_data_ind; + tlv_def_patch; tlv_dump; tlv_parse; diff --git a/src/gsm/smscb.c b/src/gsm/smscb.c new file mode 100644 index 0000000..a9f38eb --- /dev/null +++ b/src/gsm/smscb.c @@ -0,0 +1,65 @@ +/* GSM SMSCB (TS 04.12) implementation */ + +/* (C) 2010,2013 by Alex Badea + * + * All Rights Reserved + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License along + * with this program; if not, write to the Free Software Foundation, Inc., + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. + * + */ + + +/*! \addtogroup smscb + * @{ + */ + +/*! \file smscb.c */ + +#include +#include +#include + +/*! \brief Initialize a SMSCB entity */ +void smscb_init(struct smscb_entity *se) +{ +} + +/*! \brief Deinitialize a smscb entity */ +void smscb_exit(struct smscb_entity *se) +{ +} + +/*! \brief Set the L3 callback and context of a SMSCB entity */ +void smscb_set_l3(struct smscb_entity *se, smscb_cb_t cb, void *ctx) +{ + se->l3_cb = cb; + se->l3_ctx = ctx; +} + +/*! \brief Input data from layer 1 */ +int smscb_ph_data_ind(struct smscb_entity *se, struct msgb *msg) +{ + uint8_t addr = msg->l2h[0]; + uint8_t seq = addr & 0x0f; + + LOGP(DLLAPD, LOGL_NOTICE, "SMSCB: received message: seq=%d len=%d\n", + seq, msg->len); + + msgb_free(msg); + return 0; +} + +/*! @} */ + -- 1.7.0.4 From vamposdecampos at gmail.com Sat Jan 5 19:26:26 2013 From: vamposdecampos at gmail.com (Alex Badea) Date: Sat, 5 Jan 2013 21:26:26 +0200 Subject: [PATCH libosmocore 2/8] smscb: add unit test for smscb_entity In-Reply-To: <1357413992-25231-1-git-send-email-vamposdecampos@gmail.com> References: <1357413992-25231-1-git-send-email-vamposdecampos@gmail.com> Message-ID: <1357413992-25231-3-git-send-email-vamposdecampos@gmail.com> Since we've enabled logging, we now ignore stderr. Signed-off-by: Alex Badea --- tests/smscb/smscb_test.c | 71 +++++++++++++++++++++++++++++++++++++++++++++ tests/smscb/smscb_test.ok | 3 ++ tests/testsuite.at | 2 +- 3 files changed, 75 insertions(+), 1 deletions(-) diff --git a/tests/smscb/smscb_test.c b/tests/smscb/smscb_test.c index e10e12d..de88b0a 100644 --- a/tests/smscb/smscb_test.c +++ b/tests/smscb/smscb_test.c @@ -19,8 +19,76 @@ */ #include +#include +#include +#include +#include +#include #include +#include +#include + +#define ASSERT(exp) \ + if (!(exp)) { \ + printf("Assert failed %s %s:%d\n", #exp, __FILE__, __LINE__); \ + abort(); \ + } + + +static struct log_info info = {}; + +static uint8_t smscb_null_l1_msg[] = { + 0x2f, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, + 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, + 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, +}; + +static int l3_cb(struct msgb *msg, struct smscb_entity *se, void *ctx) +{ + struct abis_rsl_cchan_hdr *ch; + struct tlv_parsed tv; + struct rsl_ie_cb_cmd_type *cmd_type; + struct gsm341_ms_message *cbmsg; + unsigned int cbmsglen; + + printf("smscb l3 cb\n"); + + ch = msgb_l2(msg); + ASSERT(ch != NULL); + ASSERT(ch->c.msg_discr == ABIS_RSL_MDISC_COM_CHAN | ABIS_RSL_MDISC_TRANSP); + ASSERT(ch->c.msg_type == RSL_MT_SMS_BC_CMD); + + rsl_tlv_parse(&tv, ch->data, msgb_l2len(msg) - sizeof(*ch)); + ASSERT(TLVP_PRESENT(&tv, RSL_IE_CB_CMD_TYPE)); + ASSERT(TLVP_PRESENT(&tv, RSL_IE_SMSCB_MSG)); + + cmd_type = (struct rsl_ie_cb_cmd_type *) TLVP_VAL(&tv, RSL_IE_CB_CMD_TYPE); + cbmsg = (struct gsm341_ms_message *) TLVP_VAL(&tv, RSL_IE_SMSCB_MSG); + cbmsglen = TLVP_LEN(&tv, RSL_IE_SMSCB_MSG); + + printf("cmd_type: %u\n", cmd_type->command); + printf("cbmsg:\t%s\n", osmo_hexdump((uint8_t *) cbmsg, cbmsglen)); +} + +static int smscb_send(struct smscb_entity *se, const void *data, size_t len) +{ + struct msgb *msg = msgb_alloc_headroom(4096, 128, "data"); + msg->l2h = msgb_put(msg, len); + memcpy(msg->l2h, data, len); + return smscb_ph_data_ind(se, msg); +} + +static void test_reassembly(void) +{ + struct smscb_entity se; + + smscb_init(&se); + smscb_set_l3(&se, l3_cb, NULL); + smscb_send(&se, smscb_null_l1_msg, sizeof(smscb_null_l1_msg)); + smscb_exit(&se); +} + static uint8_t smscb_msg[] = { 0x40, 0x10, 0x05, 0x0d, 0x01, 0x11 }; @@ -37,5 +105,8 @@ int main(int argc, char **argv) printf("(pge) page total: %d current: %d\n", msg->page.total, msg->page.current); + osmo_init_logging(&info); + test_reassembly(); + return 0; } diff --git a/tests/smscb/smscb_test.ok b/tests/smscb/smscb_test.ok index 347037f..5954fc6 100644 --- a/tests/smscb/smscb_test.ok +++ b/tests/smscb/smscb_test.ok @@ -2,3 +2,6 @@ (msg) msg_id: 1293 (dcs) group: 1 language: 0 (pge) page total: 1 current: 1 +smscb l3 cb +cmd_type: 15 +cbmsg: diff --git a/tests/testsuite.at b/tests/testsuite.at index 1cfae03..0f5b721 100644 --- a/tests/testsuite.at +++ b/tests/testsuite.at @@ -46,7 +46,7 @@ AT_CLEANUP AT_SETUP([smscb]) AT_KEYWORDS([smscb]) cat $abs_srcdir/smscb/smscb_test.ok > expout -AT_CHECK([$abs_top_builddir/tests/smscb/smscb_test], [], [expout]) +AT_CHECK([$abs_top_builddir/tests/smscb/smscb_test], [], [expout], [ignore]) AT_CLEANUP AT_SETUP([timer]) -- 1.7.0.4 From vamposdecampos at gmail.com Sat Jan 5 19:26:27 2013 From: vamposdecampos at gmail.com (Alex Badea) Date: Sat, 5 Jan 2013 21:26:27 +0200 Subject: [PATCH libosmocore 3/8] smscb: process Null messages In-Reply-To: <1357413992-25231-1-git-send-email-vamposdecampos@gmail.com> References: <1357413992-25231-1-git-send-email-vamposdecampos@gmail.com> Message-ID: <1357413992-25231-4-git-send-email-vamposdecampos@gmail.com> Pick smscb messages with a sequence-number of "null". For these, construct a RSL_MT_SMS_BC_CMD message and send it upstream. Signed-off-by: Alex Badea --- src/gsm/smscb.c | 71 +++++++++++++++++++++++++++++++++++++++++++++++++++--- 1 files changed, 67 insertions(+), 4 deletions(-) diff --git a/src/gsm/smscb.c b/src/gsm/smscb.c index a9f38eb..db7f1cc 100644 --- a/src/gsm/smscb.c +++ b/src/gsm/smscb.c @@ -28,9 +28,21 @@ /*! \file smscb.c */ #include +#include +#include +#include +#include #include #include +#include + +#define SMSCB_ALLOC_SIZE 256 +#define SMSCB_ALLOC_HEADROOM 64 + +/* Link Protocol Discriminator for SMSCB */ +#define SMSCB_LPD 1 + /*! \brief Initialize a SMSCB entity */ void smscb_init(struct smscb_entity *se) { @@ -48,14 +60,65 @@ void smscb_set_l3(struct smscb_entity *se, smscb_cb_t cb, void *ctx) se->l3_ctx = ctx; } +static int rslms_sendmsg(struct msgb *msg, struct smscb_entity *se) +{ + if (!se->l3_cb) { + msgb_free(msg); + return -EIO; + } + return se->l3_cb(msg, se, se->l3_ctx); +} + +static int smscb_rx_null_msg(struct smscb_entity *se) +{ + struct msgb *msg; + struct abis_rsl_cchan_hdr *ch; + struct rsl_ie_cb_cmd_type cmd_type = {}; + + msg = msgb_alloc_headroom( + SMSCB_ALLOC_HEADROOM + SMSCB_ALLOC_SIZE, + SMSCB_ALLOC_HEADROOM, "smscb_data"); + if (!msg) + return -ENOMEM; + + msg->l2h = msgb_put(msg, sizeof(*ch)); + ch = (struct abis_rsl_cchan_hdr *) msg->l2h; + rsl_init_cchan_hdr(ch, RSL_MT_SMS_BC_CMD); + ch->c.msg_discr |= ABIS_RSL_MDISC_TRANSP; + /* TODO: we need ->chan_nr from L1: */ + ch->chan_nr = rsl_enc_chan_nr(RSL_CHAN_SDCCH8_ACCH, 2, 2); + + cmd_type.command = RSL_CB_CMD_TYPE_NULL; + msgb_tv_put(msg, RSL_IE_CB_CMD_TYPE, *((uint8_t *) &cmd_type)); + msgb_tlv_put(msg, RSL_IE_SMSCB_MSG, 0, NULL); + + /* + * TODO: we need ->frame_nr from L1: + * gsm_fn2gsmtime(&tm, ntohl(l1i->frame_nr)); + * msgb_tv_put(msg, RSL_IE_SMSCB_CHAN_INDICATOR, !(tm.tc < 4)); + */ + + return rslms_sendmsg(msg, se); +} + + + /*! \brief Input data from layer 1 */ int smscb_ph_data_ind(struct smscb_entity *se, struct msgb *msg) { - uint8_t addr = msg->l2h[0]; - uint8_t seq = addr & 0x0f; + struct gsm412_block_type *bt = (struct gsm412_block_type *) msg->l2h; + + LOGP(DLLAPD, LOGL_NOTICE, "SMSCB: received message: len=%d" + " seq=%d lb=%d lpd=%d spare=%d\n", + msg->len, bt->seq_nr, bt->lb, bt->lpd, bt->spare); + + if (bt->lpd != SMSCB_LPD) { + msgb_free(msg); + return -EINVAL; + } - LOGP(DLLAPD, LOGL_NOTICE, "SMSCB: received message: seq=%d len=%d\n", - seq, msg->len); + if (bt->seq_nr == GSM412_SEQ_NULL_MSG) + smscb_rx_null_msg(se); msgb_free(msg); return 0; -- 1.7.0.4 From vamposdecampos at gmail.com Sat Jan 5 19:26:28 2013 From: vamposdecampos at gmail.com (Alex Badea) Date: Sat, 5 Jan 2013 21:26:28 +0200 Subject: [PATCH libosmocore 4/8] smscb test: support a list of L1 messages to test In-Reply-To: <1357413992-25231-1-git-send-email-vamposdecampos@gmail.com> References: <1357413992-25231-1-git-send-email-vamposdecampos@gmail.com> Message-ID: <1357413992-25231-5-git-send-email-vamposdecampos@gmail.com> Signed-off-by: Alex Badea --- tests/smscb/smscb_test.c | 15 ++++++++++----- 1 files changed, 10 insertions(+), 5 deletions(-) diff --git a/tests/smscb/smscb_test.c b/tests/smscb/smscb_test.c index de88b0a..80cf69c 100644 --- a/tests/smscb/smscb_test.c +++ b/tests/smscb/smscb_test.c @@ -38,10 +38,13 @@ static struct log_info info = {}; -static uint8_t smscb_null_l1_msg[] = { - 0x2f, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, - 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, - 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, +static uint8_t smscb_test_messages[][23] = { + /* NULL message */ + { + 0x2f, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, + 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, + 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, + }, }; static int l3_cb(struct msgb *msg, struct smscb_entity *se, void *ctx) @@ -82,10 +85,12 @@ static int smscb_send(struct smscb_entity *se, const void *data, size_t len) static void test_reassembly(void) { struct smscb_entity se; + int k; smscb_init(&se); smscb_set_l3(&se, l3_cb, NULL); - smscb_send(&se, smscb_null_l1_msg, sizeof(smscb_null_l1_msg)); + for (k = 0; k < ARRAY_SIZE(smscb_test_messages); k++) + smscb_send(&se, smscb_test_messages[k], sizeof(smscb_test_messages[k])); smscb_exit(&se); } -- 1.7.0.4 From vamposdecampos at gmail.com Sat Jan 5 19:26:29 2013 From: vamposdecampos at gmail.com (Alex Badea) Date: Sat, 5 Jan 2013 21:26:29 +0200 Subject: [PATCH libosmocore 5/8] smscb: add test-case for reassembling a normal message In-Reply-To: <1357413992-25231-1-git-send-email-vamposdecampos@gmail.com> References: <1357413992-25231-1-git-send-email-vamposdecampos@gmail.com> Message-ID: <1357413992-25231-6-git-send-email-vamposdecampos@gmail.com> Signed-off-by: Alex Badea --- tests/smscb/smscb_test.c | 21 +++++++++++++++++++++ tests/smscb/smscb_test.ok | 3 +++ 2 files changed, 24 insertions(+), 0 deletions(-) diff --git a/tests/smscb/smscb_test.c b/tests/smscb/smscb_test.c index 80cf69c..9948f5f 100644 --- a/tests/smscb/smscb_test.c +++ b/tests/smscb/smscb_test.c @@ -45,6 +45,27 @@ static uint8_t smscb_test_messages[][23] = { 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, }, + /* 4 blocks with a normal message */ + { + 0x20, 0x00, 0x70, 0x00, 0x32, 0x01, 0x11, 0x3c, + 0xaa, 0xaf, 0xd1, 0x68, 0x34, 0x1a, 0x8d, 0x46, + 0xa3, 0xd1, 0x68, 0x34, 0x1a, 0x8d, 0x46, + }, + { + 0x21, 0xa3, 0xd1, 0x68, 0x34, 0x1a, 0x8d, 0x46, + 0xa3, 0xd1, 0x68, 0x34, 0x1a, 0x8d, 0x46, 0xa3, + 0xd1, 0x68, 0x34, 0x1a, 0x8d, 0x46, 0xa3, + }, + { + 0x22, 0xd1, 0x68, 0x34, 0x1a, 0x8d, 0x46, 0xa3, + 0xd1, 0x68, 0x34, 0x1a, 0x8d, 0x46, 0xa3, 0xd1, + 0x68, 0x34, 0x1a, 0x8d, 0x46, 0xa3, 0xd1, + }, + { + 0x23, 0x68, 0x34, 0x1a, 0x8d, 0x46, 0xa3, 0xd1, + 0x68, 0x34, 0x1a, 0x8d, 0x46, 0xa3, 0xd1, 0x68, + 0x34, 0x1a, 0x8d, 0x46, 0xa3, 0xd1, 0x00, + }, }; static int l3_cb(struct msgb *msg, struct smscb_entity *se, void *ctx) diff --git a/tests/smscb/smscb_test.ok b/tests/smscb/smscb_test.ok index 5954fc6..c4dd4b8 100644 --- a/tests/smscb/smscb_test.ok +++ b/tests/smscb/smscb_test.ok @@ -5,3 +5,6 @@ smscb l3 cb cmd_type: 15 cbmsg: +smscb l3 cb +cmd_type: 0 +cbmsg: 00 70 00 32 01 11 3c aa af d1 68 34 1a 8d 46 a3 d1 68 34 1a 8d 46 a3 d1 68 34 1a 8d 46 a3 d1 68 34 1a 8d 46 a3 d1 68 34 1a 8d 46 a3 d1 68 34 1a 8d 46 a3 d1 68 34 1a 8d 46 a3 d1 68 34 1a 8d 46 a3 d1 68 34 1a 8d 46 a3 d1 68 34 1a 8d 46 a3 d1 68 34 1a 8d 46 a3 d1 00 -- 1.7.0.4 From vamposdecampos at gmail.com Sat Jan 5 19:26:30 2013 From: vamposdecampos at gmail.com (Alex Badea) Date: Sat, 5 Jan 2013 21:26:30 +0200 Subject: [PATCH libosmocore 6/8] smscb: add test-case for reassembling a Schedule message In-Reply-To: <1357413992-25231-1-git-send-email-vamposdecampos@gmail.com> References: <1357413992-25231-1-git-send-email-vamposdecampos@gmail.com> Message-ID: <1357413992-25231-7-git-send-email-vamposdecampos@gmail.com> Signed-off-by: Alex Badea --- tests/smscb/smscb_test.c | 21 +++++++++++++++++++++ tests/smscb/smscb_test.ok | 3 +++ 2 files changed, 24 insertions(+), 0 deletions(-) diff --git a/tests/smscb/smscb_test.c b/tests/smscb/smscb_test.c index 9948f5f..779c2af 100644 --- a/tests/smscb/smscb_test.c +++ b/tests/smscb/smscb_test.c @@ -66,6 +66,27 @@ static uint8_t smscb_test_messages[][23] = { 0x68, 0x34, 0x1a, 0x8d, 0x46, 0xa3, 0xd1, 0x68, 0x34, 0x1a, 0x8d, 0x46, 0xa3, 0xd1, 0x00, }, + /* 4 blocks with a Schedule message */ + { + 0x28, 0x01, 0x1f, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x80, 0x32, 0x40, 0x40, 0x40, 0x01, 0x40, + 0x40, 0x40, 0x01, 0x40, 0x40, 0x40, 0x01, + }, + { + 0x21, 0x40, 0x40, 0x40, 0x01, 0x40, 0x40, 0x40, + 0x01, 0x40, 0x40, 0x40, 0x01, 0x40, 0x40, 0x40, + 0x01, 0x40, 0x40, 0x2b, 0x2b, 0x2b, 0x2b, + }, + { + 0x22, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, + 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, + 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, + }, + { + 0x23, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, + 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, + 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, + }, }; static int l3_cb(struct msgb *msg, struct smscb_entity *se, void *ctx) diff --git a/tests/smscb/smscb_test.ok b/tests/smscb/smscb_test.ok index c4dd4b8..f28ab5b 100644 --- a/tests/smscb/smscb_test.ok +++ b/tests/smscb/smscb_test.ok @@ -8,3 +8,6 @@ cbmsg: smscb l3 cb cmd_type: 0 cbmsg: 00 70 00 32 01 11 3c aa af d1 68 34 1a 8d 46 a3 d1 68 34 1a 8d 46 a3 d1 68 34 1a 8d 46 a3 d1 68 34 1a 8d 46 a3 d1 68 34 1a 8d 46 a3 d1 68 34 1a 8d 46 a3 d1 68 34 1a 8d 46 a3 d1 68 34 1a 8d 46 a3 d1 68 34 1a 8d 46 a3 d1 68 34 1a 8d 46 a3 d1 68 34 1a 8d 46 a3 d1 00 +smscb l3 cb +cmd_type: 8 +cbmsg: 01 1f 00 00 00 00 00 00 80 32 40 40 40 01 40 40 40 01 40 40 40 01 40 40 40 01 40 40 40 01 40 40 40 01 40 40 40 01 40 40 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b -- 1.7.0.4 From vamposdecampos at gmail.com Sat Jan 5 19:26:31 2013 From: vamposdecampos at gmail.com (Alex Badea) Date: Sat, 5 Jan 2013 21:26:31 +0200 Subject: [PATCH libosmocore 7/8] smscb: implement reassembly In-Reply-To: <1357413992-25231-1-git-send-email-vamposdecampos@gmail.com> References: <1357413992-25231-1-git-send-email-vamposdecampos@gmail.com> Message-ID: <1357413992-25231-8-git-send-email-vamposdecampos@gmail.com> Signed-off-by: Alex Badea --- include/osmocom/gsm/smscb.h | 9 ++++ src/gsm/smscb.c | 95 +++++++++++++++++++++++++++++++++++++++--- 2 files changed, 97 insertions(+), 7 deletions(-) diff --git a/include/osmocom/gsm/smscb.h b/include/osmocom/gsm/smscb.h index 88ba6e2..05f33ef 100644 --- a/include/osmocom/gsm/smscb.h +++ b/include/osmocom/gsm/smscb.h @@ -1,12 +1,16 @@ #ifndef _OSMOCOM_SMSCB_H #define _OSMOCOM_SMSCB_H +#include + /*! \defgroup smscb SMSCB implementation according to GSM TS 03.41 * @{ */ /*! \file smscb.h */ +#define SMSCB_MAX_BLOCKS 4 + struct msgb; struct smscb_entity; @@ -16,8 +20,13 @@ typedef int (*smscb_cb_t)(struct msgb *msg, struct smscb_entity *se, void *ctx); struct smscb_entity { smscb_cb_t l3_cb; /*!< \brief callback for sending stuff to L3 */ void *l3_ctx; /*!< \brief context for layer3 instance */ + + uint8_t seq_next; /*!< \brief next expected sequence number */ + uint8_t sched:1; /*!< \brief 1 if we're processing a Schedule message */ + struct msgb *blocks[SMSCB_MAX_BLOCKS]; /*!< \brief stored blocks for reassembly */ }; + void smscb_init(struct smscb_entity *se); void smscb_exit(struct smscb_entity *se); void smscb_set_l3(struct smscb_entity *se, smscb_cb_t cb, void *ctx); diff --git a/src/gsm/smscb.c b/src/gsm/smscb.c index db7f1cc..d9a0ccf 100644 --- a/src/gsm/smscb.c +++ b/src/gsm/smscb.c @@ -43,14 +43,28 @@ /* Link Protocol Discriminator for SMSCB */ #define SMSCB_LPD 1 +static void smscb_reset(struct smscb_entity *se) +{ + int k; + + for (k = 0; k < SMSCB_MAX_BLOCKS; k++) { + msgb_free(se->blocks[k]); + se->blocks[k] = NULL; + } + se->sched = 0; + se->seq_next = 0; +} + /*! \brief Initialize a SMSCB entity */ void smscb_init(struct smscb_entity *se) { + memset(se, 0, sizeof(*se)); } /*! \brief Deinitialize a smscb entity */ void smscb_exit(struct smscb_entity *se) { + smscb_reset(se); } /*! \brief Set the L3 callback and context of a SMSCB entity */ @@ -69,11 +83,13 @@ static int rslms_sendmsg(struct msgb *msg, struct smscb_entity *se) return se->l3_cb(msg, se, se->l3_ctx); } -static int smscb_rx_null_msg(struct smscb_entity *se) +static int smscb_rx_msg(struct smscb_entity *se) { struct msgb *msg; struct abis_rsl_cchan_hdr *ch; struct rsl_ie_cb_cmd_type cmd_type = {}; + int k; + uint8_t msglen, *tlv; msg = msgb_alloc_headroom( SMSCB_ALLOC_HEADROOM + SMSCB_ALLOC_SIZE, @@ -81,6 +97,9 @@ static int smscb_rx_null_msg(struct smscb_entity *se) if (!msg) return -ENOMEM; + for (k = 0, msglen = 0; se->blocks[k] && k < SMSCB_MAX_BLOCKS; k++) + msglen += se->blocks[k]->len; + msg->l2h = msgb_put(msg, sizeof(*ch)); ch = (struct abis_rsl_cchan_hdr *) msg->l2h; rsl_init_cchan_hdr(ch, RSL_MT_SMS_BC_CMD); @@ -88,9 +107,24 @@ static int smscb_rx_null_msg(struct smscb_entity *se) /* TODO: we need ->chan_nr from L1: */ ch->chan_nr = rsl_enc_chan_nr(RSL_CHAN_SDCCH8_ACCH, 2, 2); - cmd_type.command = RSL_CB_CMD_TYPE_NULL; + cmd_type.command = + se->sched ? RSL_CB_CMD_TYPE_SCHEDULE : + msglen ? RSL_CB_CMD_TYPE_NORMAL : + RSL_CB_CMD_TYPE_NULL; + cmd_type.last_block = + se->blocks[3] ? RSL_CB_CMD_LASTBLOCK_4 : + se->blocks[2] ? RSL_CB_CMD_LASTBLOCK_3 : + se->blocks[1] ? RSL_CB_CMD_LASTBLOCK_2 : + RSL_CB_CMD_LASTBLOCK_1; msgb_tv_put(msg, RSL_IE_CB_CMD_TYPE, *((uint8_t *) &cmd_type)); - msgb_tlv_put(msg, RSL_IE_SMSCB_MSG, 0, NULL); + + tlv = msgb_put(msg, TLV_GROSS_LEN(msglen)); + *tlv++ = RSL_IE_SMSCB_MSG; + *tlv++ = msglen; + for (k = 0; se->blocks[k] && k < SMSCB_MAX_BLOCKS; k++) { + memcpy(tlv, se->blocks[k]->data, se->blocks[k]->len); + tlv += se->blocks[k]->len; + } /* * TODO: we need ->frame_nr from L1: @@ -107,6 +141,8 @@ static int smscb_rx_null_msg(struct smscb_entity *se) int smscb_ph_data_ind(struct smscb_entity *se, struct msgb *msg) { struct gsm412_block_type *bt = (struct gsm412_block_type *) msg->l2h; + uint8_t seq; + uint8_t last; LOGP(DLLAPD, LOGL_NOTICE, "SMSCB: received message: len=%d" " seq=%d lb=%d lpd=%d spare=%d\n", @@ -117,11 +153,56 @@ int smscb_ph_data_ind(struct smscb_entity *se, struct msgb *msg) return -EINVAL; } - if (bt->seq_nr == GSM412_SEQ_NULL_MSG) - smscb_rx_null_msg(se); + msgb_pull(msg, sizeof(*bt)); + seq = bt->seq_nr & 3; + last = bt->lb; + + if (bt->seq_nr == GSM412_SEQ_NULL_MSG) { + smscb_reset(se); + smscb_rx_msg(se); + msgb_free(msg); + return 0; + } + + if (seq != se->seq_next) { + LOGP(DLLAPD, LOGL_ERROR, "SMSCB: got sequence %d (expected %d)\n", + bt->seq_nr, se->seq_next); + smscb_reset(se); + if (seq) { + msgb_free(msg); + return -EINVAL; + } + } - msgb_free(msg); - return 0; + switch (bt->seq_nr) { + case GSM412_SEQ_FST_SCHED_BLOCK: + se->sched = 1; + break; + case GSM412_SEQ_FTH_BLOCK: + last = 1; + break; + } + + switch (bt->seq_nr) { + case GSM412_SEQ_FST_SCHED_BLOCK: + case GSM412_SEQ_FST_BLOCK: + case GSM412_SEQ_SND_BLOCK: + case GSM412_SEQ_TRD_BLOCK: + case GSM412_SEQ_FTH_BLOCK: + msgb_free(se->blocks[seq]); + se->blocks[seq] = msg; + se->seq_next = seq + 1; + if (!last) + return 0; + smscb_rx_msg(se); + smscb_reset(se); + return 0; + default: + LOGP(DLLAPD, LOGL_ERROR, "SMSCB: unhandled sequence number %d\n", + bt->seq_nr); + msgb_free(msg); + return -EINVAL; + } } /*! @} */ -- 1.7.0.4 From vamposdecampos at gmail.com Sat Jan 5 19:26:32 2013 From: vamposdecampos at gmail.com (Alex Badea) Date: Sat, 5 Jan 2013 21:26:32 +0200 Subject: [PATCH libosmocore 8/8] smscb: hook into LAPDm In-Reply-To: <1357413992-25231-1-git-send-email-vamposdecampos@gmail.com> References: <1357413992-25231-1-git-send-email-vamposdecampos@gmail.com> Message-ID: <1357413992-25231-9-git-send-email-vamposdecampos@gmail.com> Add a smscb_entity to each lapdm_entity. Pass LAPDm messages having LPD=01 up to SMSCB. Pass L3 messages output by SMSCB to the L3 entity registered with LAPDm. Signed-off-by: Alex Badea --- This makes L3 get SMSCB decoding for free. It worksforme, but I'm not sure how it might interact with e.g. the BTS side. An alternative is to hook smscb_entity into the bb layer3 apps themselves; suggestions are welcome. include/osmocom/gsm/lapdm.h | 3 +++ src/gsm/lapdm.c | 13 +++++++++++++ 2 files changed, 16 insertions(+), 0 deletions(-) diff --git a/include/osmocom/gsm/lapdm.h b/include/osmocom/gsm/lapdm.h index 571fd46..e1fd4f0 100644 --- a/include/osmocom/gsm/lapdm.h +++ b/include/osmocom/gsm/lapdm.h @@ -2,6 +2,7 @@ #define _OSMOCOM_LAPDM_H #include +#include /*! \defgroup lapdm LAPDm implementation according to GSM TS 04.06 * @{ @@ -113,6 +114,8 @@ struct lapdm_entity { /*! \brief pointer to \ref lapdm_channel of which we're part */ struct lapdm_channel *lapdm_ch; + /*! \brief SMSCB entity associated with this LAPDm entity */ + struct smscb_entity smscb; uint8_t ta; /* TA used and indicated to network */ uint8_t tx_power; /* MS power used and indicated to network */ diff --git a/src/gsm/lapdm.c b/src/gsm/lapdm.c index 2bda48a..fcce526 100644 --- a/src/gsm/lapdm.c +++ b/src/gsm/lapdm.c @@ -114,6 +114,7 @@ enum lapdm_format { static int lapdm_send_ph_data_req(struct lapd_msg_ctx *lctx, struct msgb *msg); static int send_rslms_dlsap(struct osmo_dlsap_prim *dp, struct lapd_msg_ctx *lctx); +static int lapdm_smscb_cb(struct msgb *msg, struct smscb_entity *se, void *ctx); static void lapdm_dl_init(struct lapdm_datalink *dl, struct lapdm_entity *entity, int t200) @@ -142,6 +143,8 @@ void lapdm_entity_init(struct lapdm_entity *le, enum lapdm_mode mode, int t200) lapdm_dl_init(&le->datalink[i], le, t200); lapdm_entity_set_mode(le, mode); + smscb_init(&le->smscb); + smscb_set_l3(&le->smscb, lapdm_smscb_cb, le); } /*! \brief initialize a LAPDm channel and all its channels @@ -168,6 +171,7 @@ void lapdm_entity_exit(struct lapdm_entity *le) dl = &le->datalink[i]; lapd_dl_exit(&dl->dl); } + smscb_exit(&le->smscb); } /* \brief lfush and release all resources in LAPDm channel @@ -229,6 +233,12 @@ static int rslms_sendmsg(struct msgb *msg, struct lapdm_entity *le) return le->l3_cb(msg, le, le->l3_ctx); } +/* input function from smscb up to L3 */ +static int lapdm_smscb_cb(struct msgb *msg, struct smscb_entity *se, void *ctx) +{ + return rslms_sendmsg(msg, ctx); +} + /* write a frame into the tx queue */ static int tx_ph_data_enqueue(struct lapdm_datalink *dl, struct msgb *msg, uint8_t chan_nr, uint8_t link_id, uint8_t pad) @@ -543,6 +553,9 @@ static int l2_ph_data_ind(struct msgb *msg, struct lapdm_entity *le, LOGP(DLLAPD, LOGL_INFO, "fmt=B\n"); n201 = N201_AB_SDCCH; sapi = (msg->l2h[0] >> 2) & 7; + + if (LAPDm_ADDR_LPD(msg->l2h[0]) == LAPDm_LPD_SMSCB) + return smscb_ph_data_ind(&le->smscb, msg); } } -- 1.7.0.4 From 246tnt at gmail.com Sat Jan 5 22:34:11 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sat, 5 Jan 2013 23:34:11 +0100 Subject: [PATCH libosmocore 0/8] Cell Broadcast (SMSCB) MS support In-Reply-To: <1357413992-25231-1-git-send-email-vamposdecampos@gmail.com> References: <1357413992-25231-1-git-send-email-vamposdecampos@gmail.com> Message-ID: Hi, > This a respin of my old series of patches[1], to add decoding of SMSCB > messages on the MS side. Before I dig deeper, a quick question: Why in libosmocore ? This implementation is MS side only right ? so can't be re-used to implement smscb in OpenBSC or OsmoBTS. Cheers, Sylvain From vamposdecampos at gmail.com Sun Jan 6 09:41:14 2013 From: vamposdecampos at gmail.com (Alex Badea) Date: Sun, 6 Jan 2013 11:41:14 +0200 Subject: [PATCH libosmocore 0/8] Cell Broadcast (SMSCB) MS support In-Reply-To: References: <1357413992-25231-1-git-send-email-vamposdecampos@gmail.com> Message-ID: Hi, On Sun, Jan 6, 2013 at 12:34 AM, Sylvain Munaut <246tnt at gmail.com> wrote: > > Hi, > > > This a respin of my old series of patches[1], to add decoding of SMSCB > > messages on the MS side. > > Before I dig deeper, a quick question: > > Why in libosmocore ? This implementation is MS side only right ? so > can't be re-used to implement smscb in OpenBSC or OsmoBTS. Inertia would be one reason -- since my first patchset, LAPDm has moved from BB into libosmocore, so I just tagged along. On the practical side, I see two reasons now: i) if we want to hook it into LAPDm, it needs to be where lapdm.c is ii) libosmocore has a testsuite, so I could just stuff some testcases in there In the future, we can also add the BTS-side implementation. I don't think they can share much code, but it might make sense to have both in the same place. I can spin a patch series directly on top of osmocom-bb, but the testcases will probably not make it. Thanks, Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Sun Jan 6 15:10:27 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 6 Jan 2013 16:10:27 +0100 Subject: [PATCH libosmocore 0/8] Cell Broadcast (SMSCB) MS support In-Reply-To: References: <1357413992-25231-1-git-send-email-vamposdecampos@gmail.com> Message-ID: Hi, > Inertia would be one reason -- since my first patchset, LAPDm has moved > from BB into libosmocore, so I just tagged along. > > On the practical side, I see two reasons now: > > i) if we want to hook it into LAPDm, it needs to be where lapdm.c is After starting to read the spec (not done yet, so further comments my come afterwards), I don't think "hooking" LAPDm is the right way. From vamposdecampos at gmail.com Mon Jan 7 13:22:22 2013 From: vamposdecampos at gmail.com (Alex Badea) Date: Mon, 7 Jan 2013 15:22:22 +0200 Subject: [PATCH libosmocore 0/8] Cell Broadcast (SMSCB) MS support In-Reply-To: References: <1357413992-25231-1-git-send-email-vamposdecampos@gmail.com> Message-ID: On Sun, Jan 6, 2013 at 5:10 PM, Sylvain Munaut <246tnt at gmail.com> wrote: >> i) if we want to hook it into LAPDm, it needs to be where lapdm.c is > > After starting to read the spec (not done yet, so further comments my > come afterwards), I don't think "hooking" LAPDm is the right way. > > From the specs, LAPDm and the SMSCB link layer are not one above the > other but rather completely separate. > And again from the spec, should you expect one or the other on a > channel, you must ignore any packets with the wrong LPD. So AFAIK on a > CBCH channel if you ever get a LPD=00 it should be ignored and not fed > to a LAPDm processor. Same thing for a BTS side LAPDm instance if it > receives a LPD=01 it should be ignored. I did get confused by that. I parsed that the LPD field is specified by LAPDm (TS 04.06), and it indicates a possible sublayer. Now that I re-read 04.06, it does say that only LPD=00 is valid for LAPDm, so other values must be other protocols. [...] That all makes sense, I'll give it a try. Thanks for the feedback. From holger at freyther.de Sun Jan 6 08:07:03 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sun, 6 Jan 2013 09:07:03 +0100 Subject: [PATCH libosmocore 0/8] Cell Broadcast (SMSCB) MS support In-Reply-To: <1357413992-25231-1-git-send-email-vamposdecampos@gmail.com> References: <1357413992-25231-1-git-send-email-vamposdecampos@gmail.com> Message-ID: <20130106080703.GP28715@xiaoyu.lan> On Sat, Jan 05, 2013 at 09:26:24PM +0200, Alex Badea wrote: > Hi, Hi, nice! and with test cases! holger From vamposdecampos at gmail.com Sat Jan 5 19:29:58 2013 From: vamposdecampos at gmail.com (Alex Badea) Date: Sat, 5 Jan 2013 21:29:58 +0200 Subject: [PATCH] layer23 cell_log: log CBCH cell info Message-ID: <1357414198-25328-1-git-send-email-vamposdecampos@gmail.com> If System Information contained CBCH channel description, tune to it and log SMSCB messages with a Geographical Scope of Cell Wide (Immediate) -- these are typically used for "Cell Info Display". The CBCH timeout is set to a generous 8 seconds; this is because we need 4 frames for reassembly, we usually miss the first, and we might hit a burst of Null SMSCB messages. By default this feature is disabled; it can be enabled via a new '-B' or '--cbch' commandline argument. Signed-off-by: Alex Badea --- This patch requires the CBCH DM flag patch[1], and the libosmocore patch series[2] for SMSCB reassembly. [1] http://lists.osmocom.org/pipermail/baseband-devel/2013-January/003612.html [2] http://lists.osmocom.org/pipermail/baseband-devel/2013-January/003642.html src/host/layer23/src/misc/app_cell_log.c | 11 +++- src/host/layer23/src/misc/cell_log.c | 114 +++++++++++++++++++++++++++++- 2 files changed, 121 insertions(+), 4 deletions(-) diff --git a/src/host/layer23/src/misc/app_cell_log.c b/src/host/layer23/src/misc/app_cell_log.c index a7f42c3..5ed1d6b 100644 --- a/src/host/layer23/src/misc/app_cell_log.c +++ b/src/host/layer23/src/misc/app_cell_log.c @@ -45,6 +45,7 @@ extern uint16_t (*band_range)[][2]; char *logname = "/var/log/osmocom.log"; int RACH_MAX = 2; +int do_cbch = 0; int _scan_work(struct osmocom_ms *ms) { @@ -103,7 +104,8 @@ static int l23_getopt_options(struct option **options) #endif {"gps", 1, 0, 'g'}, {"baud", 1, 0, 'b'}, - {"arfcns", 1, 0, 'A'} + {"arfcns", 1, 0, 'A'}, + {"cbch", 1, 0, 'B'}, }; *options = opts; @@ -162,6 +164,8 @@ static int l23_cfg_print_help() printf(" -f --gps DEVICE /dev/ttyACM0. GPS serial device.\n"); printf(" -b --baud BAUDRAT The baud rate of the GPS device\n"); printf(" -A --arfcns ARFCNS The list of arfcns to be monitored\n"); + printf(" -B --cbch Scan and log info from the CBCH\n"); + return 0; } @@ -224,6 +228,9 @@ static int l23_cfg_handle(int c, const char *optarg) parse_band_range((char*)optarg); printf("New frequencies range: %s\n", print_band_range(*band_range, buf, sizeof(buf))); break; + case 'B': + do_cbch = 1; + break; } return 0; @@ -234,7 +241,7 @@ cmd_line_error: static struct l23_app_info info = { .copyright = "Copyright (C) 2010 Andreas Eversberg\n", - .getopt_string = "g:p:l:r:nf:b:A:", + .getopt_string = "g:p:l:r:nf:b:A:B", .cfg_supported = l23_cfg_supported, .cfg_getopt_opt = l23_getopt_options, .cfg_handle_opt = l23_cfg_handle, diff --git a/src/host/layer23/src/misc/cell_log.c b/src/host/layer23/src/misc/cell_log.c index 7340dcb..41a34fd 100644 --- a/src/host/layer23/src/misc/cell_log.c +++ b/src/host/layer23/src/misc/cell_log.c @@ -26,6 +26,8 @@ #include #include #include +#include +#include #include @@ -35,6 +37,7 @@ #include #include #include +#include #include #include @@ -47,6 +50,7 @@ #define READ_WAIT 2, 0 #define RACH_WAIT 0, 900000 +#define CBCH_WAIT 8, 0 #define MIN_RXLEV_DBM -106 #define MAX_DIST 2000 @@ -55,6 +59,7 @@ enum { SCAN_STATE_SYNC, SCAN_STATE_READ, SCAN_STATE_RACH, + SCAN_STATE_CBCH, }; /* ranges of bands */ @@ -89,6 +94,7 @@ static int rach_count; static FILE *logfp = NULL; extern char *logname; extern int RACH_MAX; +extern int do_cbch; static struct gsm48_sysinfo sysinfo; @@ -115,6 +121,7 @@ struct rach_ref { static void start_sync(void); static void start_rach(void); +static void start_cbch(void); static void start_pm(void); static void log_gps(void) @@ -228,6 +235,11 @@ static void timeout_cb(void *arg) rach_count++; start_rach(); break; + case SCAN_STATE_CBCH: + LOGP(DRR, LOGL_INFO, "Timeout on CBCH\n"); + l1ctl_tx_dm_rel_req(ms); + start_sync(); + break; } } @@ -245,6 +257,35 @@ static void start_timer(int sec, int micro) osmo_timer_schedule(&timer, sec, micro); } +static void start_cbch(void) +{ + struct gsm48_sysinfo *s = &sysinfo; + int res; + + if (!do_cbch) { + res = -1; + } else if (!s->chan_nr) { + LOGP(DRR, LOGL_DEBUG, "No CBCH description in sysinfo\n"); + res = -1; + } else if (s->h) { + res = l1ctl_tx_dm_est_req_h1(ms, + s->maio, s->hsn, s->hopping, s->hopp_len, + s->chan_nr, s->tsc, + GSM48_CMODE_SIGN, 0, L1CTL_DM_F_CBCH); + } else { + res = l1ctl_tx_dm_est_req_h0(ms, s->arfcn, s->chan_nr, s->tsc, + GSM48_CMODE_SIGN, 0, L1CTL_DM_F_CBCH); + } + + if (res < 0) { + start_sync(); + return; + } + + state = SCAN_STATE_CBCH; + start_timer(CBCH_WAIT); +} + static void start_rach(void) { struct gsm48_sysinfo *s = &sysinfo; @@ -254,7 +295,7 @@ static void start_rach(void) if (rach_count == RACH_MAX) { log_sysinfo(); - start_sync(); + start_cbch(); return; } @@ -433,7 +474,7 @@ static int ta_result(uint8_t ta) } log_sysinfo(); - start_sync(); + start_cbch(); return 0; } @@ -737,6 +778,70 @@ int chan_conf(struct osmocom_ms *ms, struct msgb *msg) return 0; } +static int sms_bc_cmd(struct osmocom_ms *ms, struct msgb *msg) +{ + struct abis_rsl_cchan_hdr *ch = msgb_l2(msg); + struct tlv_parsed tv; + struct rsl_ie_cb_cmd_type *cmd_type; + struct gsm341_ms_message *cbmsg; + unsigned int cbmsglen; + char buf[256], *p; + + DEBUGP(DRSL, "RSLms SMS BC CMD chan_nr=0x%02x\n", + ch->chan_nr); + + rsl_tlv_parse(&tv, ch->data, msgb_l2len(msg) - sizeof(*ch)); + if (!TLVP_PRESENT(&tv, RSL_IE_SMSCB_MSG) || + !TLVP_PRESENT(&tv, RSL_IE_CB_CMD_TYPE)) { + LOGP(DRR, LOGL_ERROR, "SMS_BC_CMD missing mandatory IEs\n"); + return -EINVAL; + } + + cmd_type = (struct rsl_ie_cb_cmd_type *) TLVP_VAL(&tv, RSL_IE_CB_CMD_TYPE); + cbmsg = (struct gsm341_ms_message *) TLVP_VAL(&tv, RSL_IE_SMSCB_MSG); + cbmsglen = TLVP_LEN(&tv, RSL_IE_SMSCB_MSG); + if (cbmsglen < sizeof(*cbmsg)) { + LOGP(DRR, LOGL_ERROR, "RSL_IE_SMSCB_MSG too short\n"); + return -EINVAL; + } + + if (cmd_type->command != RSL_CB_CMD_TYPE_NORMAL) + return 0; + + gsm_7bit_decode(buf, cbmsg->data, cbmsglen - sizeof(*cbmsg)); + for (p = buf; *p; p++) + if (!isprint(*p)) + *p = '_'; + + LOGP(DSUM, LOGL_INFO, "Cell info: gs=%d code=%d update=%d id=%d text=\"%s\"\n", + cbmsg->serial.gs, + GSM341_MSG_CODE(cbmsg), + cbmsg->serial.update, + ntohs(cbmsg->msg_id), + buf); + + if (cbmsg->serial.gs != GSM341_GS_CELL_WIDE_IMMED) + return 0; + + LOGFILE("[cbch]\n"); + LOGFILE("arfcn %d\n", sysinfo.arfcn); + LOGFILE("gs %d code %d update %d msg_id %d page %d numpages %d\n", + cbmsg->serial.gs, + GSM341_MSG_CODE(cbmsg), + cbmsg->serial.update, + ntohs(cbmsg->msg_id), + cbmsg->page.current, cbmsg->page.total); + LOGFILE("text \"%s\"\n", buf); + LOGFILE("\n"); + LOGFLUSH(); + + l1ctl_tx_dm_rel_req(ms); + stop_timer(); + + start_sync(); + return 0; +} + static int rcv_cch(struct osmocom_ms *ms, struct msgb *msg) { struct abis_rsl_cchan_hdr *ch = msgb_l2(msg); @@ -751,6 +856,11 @@ static int rcv_cch(struct osmocom_ms *ms, struct msgb *msg) msgb_free(msg); return rc; } + if (state == SCAN_STATE_CBCH && msg_type == RSL_MT_SMS_BC_CMD) { + rc = sms_bc_cmd(ms, msg); + msgb_free(msg); + return rc; + } LOGP(DRSL, LOGL_NOTICE, "RSLms message unhandled\n"); msgb_free(msg); -- 1.7.0.4 From vamposdecampos at gmail.com Sun Jan 6 10:34:06 2013 From: vamposdecampos at gmail.com (Alex Badea) Date: Sun, 6 Jan 2013 12:34:06 +0200 Subject: layer23 on GTA02 AP and ARM unaligned memory access Message-ID: Hi list, I'm running layer23 apps on the Application Processor of the OpenMoko GTA02, which is also an ARM. I noticed that some parts of code try to access words in memory which are not naturally aligned. [ The first symptom was "Err from socket: Bad address" given by osmocon. This is because a bogus length header read from the L2 unix socket was overflowing a static 4K buffer. The bogus length was due to an unaligned uint16_t write in osmo_send_l1() -- for an L1CTL_DATA_REQ I think. ] The easy and inefficient workaround for this is to ask the kernel[1] to fix up these accesses: echo 3 > /proc/cpu/alignment Cheers, Alex [1] http://lxr.linux.no/#linux+v3.7.1/Documentation/arm/mem_alignment From holger at freyther.de Sun Jan 6 21:03:32 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sun, 6 Jan 2013 22:03:32 +0100 Subject: layer23 on GTA02 AP and ARM unaligned memory access In-Reply-To: References: Message-ID: <20130106210332.GC20728@xiaoyu.lan> On Sun, Jan 06, 2013 at 12:34:06PM +0200, Alex Badea wrote: > Hi list, Hi, > The easy and inefficient workaround for this is to ask the kernel[1] > to fix up these accesses: > > echo 3 > /proc/cpu/alignment we have a pragmatic approach for this. There are several new tlv methods to access data unaligned (using memcpy). We use them once we get alignment warnings from the kernel. holger From dario.lombardo.ml at gmail.com Mon Jan 7 12:59:23 2013 From: dario.lombardo.ml at gmail.com (Dario Lombardo) Date: Mon, 7 Jan 2013 13:59:23 +0100 Subject: [PATCH] Typos Message-ID: Attached a small patch that fixes a couple of typos. Have a nice day. Dario. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Typos-fixes.patch Type: application/octet-stream Size: 1698 bytes Desc: not available URL: From holger at freyther.de Tue Jan 8 21:12:54 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Tue, 8 Jan 2013 22:12:54 +0100 Subject: [PATCH] Typos In-Reply-To: References: Message-ID: <20130108211254.GG20797@xiaoyu.lan> On Mon, Jan 07, 2013 at 01:59:23PM +0100, Dario Lombardo wrote: > Attached a small patch that fixes a couple of typos. Applied. From dario.lombardo.ml at gmail.com Mon Jan 7 15:12:41 2013 From: dario.lombardo.ml at gmail.com (Dario Lombardo) Date: Mon, 7 Jan 2013 16:12:41 +0100 Subject: Cleaning up stuff Message-ID: Hi guys This is a question related to the compilation system of osmocom-bb. For an unknown reason, something has gone wrong with my compiled binaries, so now I would like to clean up everything as it was freshly checked out, before restarting the compilation. How can I do it? Make clean and make distclean seem not to be enough, since my compilation now fails with: cd ./doc && tar cf html.tar */html make[3]: Leaving directory `/home/dario/Projects/mobile/osmocom-bb/src/shared/libosmocore/build-target' make[2]: Leaving directory `/home/dario/Projects/mobile/osmocom-bb/src/shared/libosmocore/build-target' make[1]: Leaving directory `/home/dario/Projects/mobile/osmocom-bb/src/shared/libosmocore/build-target' cd host/layer23 && ./configure checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... no checking for mawk... mawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking whether make sets $(MAKE)... (cached) yes checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking for ranlib... ranlib checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for LIBOSMOCORE... no configure: error: Package requirements (libosmocore) were not met: No package 'libosmocore' found Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. Alternatively, you may set the environment variables LIBOSMOCORE_CFLAGS and LIBOSMOCORE_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details. make: *** [host/layer23/Makefile] Error 1 How can I clean up everything? Any help appreciated. Thanks Dario. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dario.lombardo.ml at gmail.com Tue Jan 8 08:23:30 2013 From: dario.lombardo.ml at gmail.com (Dario Lombardo) Date: Tue, 8 Jan 2013 09:23:30 +0100 Subject: Cleaning up stuff In-Reply-To: <1357581600.73007.YahooMailNeo@web171205.mail.ir2.yahoo.com> References: <1357581600.73007.YahooMailNeo@web171205.mail.ir2.yahoo.com> Message-ID: I've done it and now everything works, thanks. But I've noticed that this requirement is not documented anywhere. Wiki should be updated or new users will stuck at this point. On Mon, Jan 7, 2013 at 7:00 PM, Erich Dachleger wrote: > Did you install libosmocore first?One must do that now > regards > erich > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordan.bouyat at etu.unilim.fr Tue Jan 8 16:33:39 2013 From: jordan.bouyat at etu.unilim.fr (laFouine) Date: Tue, 8 Jan 2013 16:33:39 +0000 (UTC) Subject: Cleaning up stuff References: Message-ID: Dario Lombardo gmail.com> writes: > > > Hi guys > This is a question related to the compilation system of osmocom-bb. For an unknown reason, something has gone wrong with my compiled binaries, so now I would like to clean up everything as it was freshly checked out, before restarting the compilation. How can I do it? Make clean and make distclean seem not to be enough, since my compilation now fails with: > > > cd ./doc && tar cf html.tar */html > make[3]: Leaving directory `/home/dario/Projects/mobile/osmocom-bb/src/shared/libosmocore/build-target' > make[2]: Leaving directory `/home/dario/Projects/mobile/osmocom-bb/src/shared/libosmocore/build-target' > make[1]: Leaving directory `/home/dario/Projects/mobile/osmocom-bb/src/shared/libosmocore/build-target' > cd host/layer23 && ./configure? > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for a thread-safe mkdir -p... /bin/mkdir -p > checking for gawk... no > checking for mawk... mawk > checking whether make sets $(MAKE)... yes > checking whether make supports nested variables... yes > checking whether make sets $(MAKE)... (cached) yes > checking for gcc... gcc > checking whether the C compiler works... yes > checking for C compiler default output file name... a.out > checking for suffix of executables...? > checking whether we are cross compiling... no > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ISO C89... none needed > checking for style of include used by make... GNU > checking dependency style of gcc... gcc3 > checking for ranlib... ranlib > checking for pkg-config... /usr/bin/pkg-config > checking pkg-config is at least version 0.9.0... yes > checking for LIBOSMOCORE... no > configure: error: Package requirements (libosmocore) were not met: > > No package 'libosmocore' found > > Consider adjusting the PKG_CONFIG_PATH environment variable if you > installed software in a non-standard prefix. > > Alternatively, you may set the environment variables LIBOSMOCORE_CFLAGS > and LIBOSMOCORE_LIBS to avoid the need to call pkg-config. > See the pkg-config man page for more details. > make: *** [host/layer23/Makefile] Error 1 > > > How can I clean up everything? > Any help appreciated. > Thanks > Dario. > I had exactly the same problem. I don't know why but the libosmocore provided by osmcombb couldn't be found... I fixed the problem this way : - Delete totally the osmocom-bb folder (which you clone from the repo) - Download and install libosmocore and follow the instructions : http://bb.osmocom.org/trac/wiki/libosmocore - Then, configure you PKG_CONFIG_PATH to aim at /usr/local/lib/pkgconfig - Then, clone obtain the sources of osmocombb and install : http://bb.osmocom.org/trac/wiki/GettingStarted From dario.lombardo.ml at gmail.com Wed Jan 9 08:31:00 2013 From: dario.lombardo.ml at gmail.com (Dario Lombardo) Date: Wed, 9 Jan 2013 09:31:00 +0100 Subject: Cleaning up stuff In-Reply-To: References: Message-ID: On Tue, Jan 8, 2013 at 5:33 PM, laFouine wrote: > > I had exactly the same problem. > I don't know why but the libosmocore provided by osmcombb couldn't be > found... > > I fixed the problem this way : > > - Delete totally the osmocom-bb folder (which you clone from the repo) > - Download and install libosmocore and follow the instructions : > http://bb.osmocom.org/trac/wiki/libosmocore > - Then, configure you PKG_CONFIG_PATH to aim at /usr/local/lib/pkgconfig > - Then, clone obtain the sources of osmocombb and install : > http://bb.osmocom.org/trac/wiki/GettingStarted > > I didn't need to go through all of your steps. In particular, step 1 was absolutely impossible, since I have many local branches. Everything went right by simply installing libosmocore in my system, which is now a requirement (I have discovered it going through this issue). Everything now is ok, except for the GettingStarted wiki page, that doesn't describe the libosmocore requirement. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ml at mail.tsaitgaist.info Wed Jan 9 21:23:33 2013 From: ml at mail.tsaitgaist.info (Kevin Redon) Date: Wed, 09 Jan 2013 22:23:33 +0100 Subject: Cleaning up stuff In-Reply-To: References: Message-ID: <1357766407-sup-5936@dennou> Hi, Yes, you are right. Now osmocomBB does not use the included libosmocore, but now requires the one for the system. Thus to compile osmocomBB you first need to install libosmocore on the machine. This detail is now mentioned in the wiki ( http://bb.osmocom.org/trac/wiki/Software/GettingStarted ) thanks, kevin Excerpts from Dario Lombardo's message of Wed Jan 09 09:31:00 +0100 2013: > absolutely impossible, since I have many local branches. Everything went > right by simply installing libosmocore in my system, which is now a > requirement (I have discovered it going through this issue). Everything now > is ok, except for the GettingStarted wiki page, that doesn't describe the > libosmocore requirement. From pabftk at gmail.com Mon Jan 7 20:04:50 2013 From: pabftk at gmail.com (Pavel Baturko) Date: Mon, 7 Jan 2013 20:04:50 +0000 Subject: MDL-Error in case of OsmocomBB+OpenBTS Message-ID: Hi list, I'm trying to connect my OsmocomBB phone to OpenBTS and I always got MDL-Error in mobile app log when MS trying to perform LU. Part of log (full mobile log in attach): <0001> gsm48_rr.c:355 new state connection pending -> dedicated <0005> gsm48_mm.c:3911 (ms 1) Received 'RR_EST_CNF' from RR in state wait for RR connection (location updating) (sapi 0) <0005> gsm48_mm.c:404 starting T3210 (loc. upd. timeout) with 20.0 seconds <0005> gsm48_mm.c:924 new state wait for RR connection (location updating) -> location updating initiated <0001> gsm48_rr.c:4984 MDL-Error (cause 3) ignoring <0001> gsm48_rr.c:4987 MDL-Error (cause 3) aborting <0001> gsm48_rr.c:355 new state dedicated -> idle In wireshark trace (from OpenBTS, attached) I see that MS sends LURequest (packet 359) and BTS responds with LUAccept (packet 440) but MS never receive this message because of error. As I understand this is "unsolicited UA response" from 08.58 (9.3.22) but I do not know how to fix that or properly debug. I'm using latest sylvain/testing and official OpenBTS 2.8. "Usual" (not with OsmocomBB) phones works with OpenBTS fine and OsmocomBB phones works fine with "usual" (not OpenBTS) networks. Thanks, Pavel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bb_mobile.log Type: application/octet-stream Size: 8316 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: reg_trace.pcapng Type: application/octet-stream Size: 152112 bytes Desc: not available URL: From 246tnt at gmail.com Tue Jan 8 00:01:44 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Tue, 8 Jan 2013 01:01:44 +0100 Subject: MDL-Error in case of OsmocomBB+OpenBTS In-Reply-To: References: Message-ID: Hi, > In wireshark trace (from OpenBTS, attached) I see that MS sends LURequest > (packet 359) and BTS responds with LUAccept (packet 440) but MS never > receive this message because of error. Can you send a gsmtap trace from the mobile side as well ? (using the -i 127.0.0.1 option). Cheers, Sylvain From pabftk at gmail.com Tue Jan 8 10:13:19 2013 From: pabftk at gmail.com (Pavel Baturko) Date: Tue, 8 Jan 2013 10:13:19 +0000 Subject: MDL-Error in case of OsmocomBB+OpenBTS In-Reply-To: References: Message-ID: Hi, Attached new mobile log + trace from both OpenBTS and OsmocomBB (since I'm using 1 lo interface for them, packets from/to 127.0.0.1 - OpenBTS, from/to 127.0.0.2 - OsmocomBB). LURequests in packets 278, 380 and following. Thanks, Pavel On Tue, Jan 8, 2013 at 12:01 AM, Sylvain Munaut <246tnt at gmail.com> wrote: > Hi, > > > In wireshark trace (from OpenBTS, attached) I see that MS sends LURequest > > (packet 359) and BTS responds with LUAccept (packet 440) but MS never > > receive this message because of error. > > Can you send a gsmtap trace from the mobile side as well ? (using the > -i 127.0.0.1 option). > > Cheers, > > Sylvain > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bb_mobile_2.log Type: application/octet-stream Size: 10931 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: reg_trace_2.pcapng Type: application/octet-stream Size: 131932 bytes Desc: not available URL: From andreas at eversberg.eu Tue Jan 8 12:47:28 2013 From: andreas at eversberg.eu (jolly) Date: Tue, 08 Jan 2013 13:47:28 +0100 Subject: MDL-Error in case of OsmocomBB+OpenBTS In-Reply-To: References: Message-ID: <50EC1560.8090206@eversberg.eu> Pavel Baturko wrote: > Hi, > > Attached new mobile log + trace from both OpenBTS and OsmocomBB (since > I'm using 1 lo interface for them, packets from/to 127.0.0.1 - > OpenBTS, from/to 127.0.0.2 - OsmocomBB). LURequests in packets 278, > 380 and following. > > hi pavel, i can see that openbts did not manage to reply to SABM within the required time (we use 1 second timeout). this causes a second SABM to be transmitted by the mobile. the openbts replies with UA twice, because it assumes that the first UA was not received by mobile. this delay between mobile and openbts is not nice, but should not cause any link failure. i just committed a fix to master branch of osmocombb. the "unsoliciated UA response" is something that must not cause link failure. there are other causes that may not cause link failures, so they are ignored too. @holger: please revert your patch in your branch and use my fix. regards, andreas From 246tnt at gmail.com Tue Jan 8 12:58:31 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Tue, 8 Jan 2013 13:58:31 +0100 Subject: MDL-Error in case of OsmocomBB+OpenBTS In-Reply-To: <50EC1560.8090206@eversberg.eu> References: <50EC1560.8090206@eversberg.eu> Message-ID: The fix Andreas just pushed is what I suspected: A missing 'return' that made the "ignore" casei, not really ignored. What seems to happen is: - We respond to the assignement a bit fast it seems and OpenBTS doesn't see the first SABM at all (not in the OpenBTS trace at all) - When OpenBTS sees the SABM, it responds with the UA frame - OpenBTS doesn't send a new frame until quite a bit later, which means the UA frame is resent several times by OpenBTS transceiver application using it's filling table (which is why we see only 1 UA frame in OpenBTS trace but multiple of them in the OsmocomBB trace) - OsmocomBB had a bug where it was supposed to ignore the extraneous UA frame but instead was dropping the connection because of a missing "return" inside the switch statement. Cheers, Sylvain From pabftk at gmail.com Tue Jan 8 13:02:18 2013 From: pabftk at gmail.com (Pavel Baturko) Date: Tue, 8 Jan 2013 13:02:18 +0000 Subject: MDL-Error in case of OsmocomBB+OpenBTS In-Reply-To: References: <50EC1560.8090206@eversberg.eu> Message-ID: Thanks for explanations and fast fix! It seems that now all works as should be. Pavel On Tue, Jan 8, 2013 at 12:58 PM, Sylvain Munaut <246tnt at gmail.com> wrote: > The fix Andreas just pushed is what I suspected: A missing 'return' > that made the "ignore" casei, not really ignored. > > What seems to happen is: > - We respond to the assignement a bit fast it seems and OpenBTS > doesn't see the first SABM at all (not in the OpenBTS trace at all) > - When OpenBTS sees the SABM, it responds with the UA frame > - OpenBTS doesn't send a new frame until quite a bit later, which > means the UA frame is resent several times by OpenBTS transceiver > application using it's filling table (which is why we see only 1 UA > frame in OpenBTS trace but multiple of them in the OsmocomBB trace) > - OsmocomBB had a bug where it was supposed to ignore the extraneous > UA frame but instead was dropping the connection because of a missing > "return" inside the switch statement. > > Cheers, > > Sylvain > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kheimerl at cs.berkeley.edu Tue Jan 8 14:51:56 2013 From: kheimerl at cs.berkeley.edu (Kurtis Heimerl) Date: Tue, 8 Jan 2013 23:51:56 +0900 Subject: MDL-Error in case of OsmocomBB+OpenBTS In-Reply-To: References: <50EC1560.8090206@eversberg.eu> Message-ID: Anything OpenBTS is doing wrong? On Tuesday, January 8, 2013, Pavel Baturko wrote: > Thanks for explanations and fast fix! It seems that now all works as > should be. > > Pavel > > On Tue, Jan 8, 2013 at 12:58 PM, Sylvain Munaut <246tnt at gmail.com > > wrote: > >> The fix Andreas just pushed is what I suspected: A missing 'return' >> that made the "ignore" casei, not really ignored. >> >> What seems to happen is: >> - We respond to the assignement a bit fast it seems and OpenBTS >> doesn't see the first SABM at all (not in the OpenBTS trace at all) >> - When OpenBTS sees the SABM, it responds with the UA frame >> - OpenBTS doesn't send a new frame until quite a bit later, which >> means the UA frame is resent several times by OpenBTS transceiver >> application using it's filling table (which is why we see only 1 UA >> frame in OpenBTS trace but multiple of them in the OsmocomBB trace) >> - OsmocomBB had a bug where it was supposed to ignore the extraneous >> UA frame but instead was dropping the connection because of a missing >> "return" inside the switch statement. >> >> Cheers, >> >> Sylvain >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Tue Jan 8 15:40:56 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Tue, 8 Jan 2013 16:40:56 +0100 Subject: MDL-Error in case of OsmocomBB+OpenBTS In-Reply-To: References: <50EC1560.8090206@eversberg.eu> Message-ID: Hi, > Anything OpenBTS is doing wrong? Well, kind of. Seems that when the L2 doesn't have anything "new" to send, it doesn't send anything, which causes the filler table to repeat the last message. Now AFAIU, it is the intended behavior, but all in all I'm not convinced it's a good idea. It can help if the process generating the burst doesn't send them to transceiver in time (and so they'll be 'replayed' a multiframe later), but that only works IF: - The message are time independent (eg some messages on CCCH need to at the right time (longer than 1 multiframe) to be in the good paging group, each SI message is supposed to be in some specific order, ...) - No new L1 bursts are generated in the mean time that would overwrite the non transmitted bursts from the filler table - The L1FEC was really too late to TX message to the transceiver to send them in time I'm kind of wondering how often all those 3 conditions are met and this filler table actually helps. If instead of retransmitting the last L2 packet, it would just transmit a filler, then if the L1FEC was late, the packet would be lost and the LAPDm recovery would kick-in. As it is now, it _should_ work since the LAPDm receiver is essentially supposed to ignore all those redudant packet. But that doesn't mean it won't trigger weird bugs in the stack. Cheers, Sylvain From dburgess at jcis.net Tue Jan 8 22:19:14 2013 From: dburgess at jcis.net (David A. Burgess) Date: Tue, 8 Jan 2013 14:19:14 -0800 Subject: MDL-Error in case of OsmocomBB+OpenBTS In-Reply-To: References: <50EC1560.8090206@eversberg.eu> Message-ID: <0316AB2B-BF84-4F1F-8BCA-79C0BF1EFEF2@jcis.net> Sylvain - There was an unintentional change in filler table behavior between 2.6 and 2.8, probably as a result of modifications to support multi-ARFCN operation. A known symptom of this change in normal OpenBTS operation is the occasional failure of an assignment to a TCH for some MS basebands, most notably Nokia DTC4 series handsets, like the 1600. We are looking for the bug ourselves now. -- David On Jan 8, 2013, at 7:40 AM, Sylvain Munaut wrote: > Hi, > >> Anything OpenBTS is doing wrong? > > Well, kind of. > > Seems that when the L2 doesn't have anything "new" to send, it doesn't > send anything, which causes the filler table to repeat the last > message. Now AFAIU, it is the intended behavior, but all in all I'm > not convinced it's a good idea. It can help if the process generating > the burst doesn't send them to transceiver in time (and so they'll be > 'replayed' a multiframe later), but that only works IF: > - The message are time independent (eg some messages on CCCH need to > at the right time (longer than 1 multiframe) to be in the good paging > group, each SI message is supposed to be in some specific order, ...) > - No new L1 bursts are generated in the mean time that would > overwrite the non transmitted bursts from the filler table > - The L1FEC was really too late to TX message to the transceiver to > send them in time > > I'm kind of wondering how often all those 3 conditions are met and > this filler table actually helps. > > If instead of retransmitting the last L2 packet, it would just > transmit a filler, then if the L1FEC was late, the packet would be > lost and the LAPDm recovery would kick-in. > > As it is now, it _should_ work since the LAPDm receiver is essentially > supposed to ignore all those redudant packet. But that doesn't mean it > won't trigger weird bugs in the stack. > > Cheers, > > Sylvain From alexander.chemeris at gmail.com Tue Jan 8 17:29:34 2013 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Tue, 8 Jan 2013 21:29:34 +0400 Subject: MDL-Error in case of OsmocomBB+OpenBTS In-Reply-To: References: <50EC1560.8090206@eversberg.eu> Message-ID: I suspect there is an issue with excessive queuing in OpenBTS 2.8. IIRC more queuing was one of changes between OpenBTS 2.6 and 2.8. My guess is that this queuing might lead to missing frames on receive side, but this should be checked. On Tue, Jan 8, 2013 at 6:51 PM, Kurtis Heimerl wrote: > Anything OpenBTS is doing wrong? > > > On Tuesday, January 8, 2013, Pavel Baturko wrote: >> >> Thanks for explanations and fast fix! It seems that now all works as >> should be. >> >> Pavel >> >> On Tue, Jan 8, 2013 at 12:58 PM, Sylvain Munaut <246tnt at gmail.com> wrote: >>> >>> The fix Andreas just pushed is what I suspected: A missing 'return' >>> that made the "ignore" casei, not really ignored. >>> >>> What seems to happen is: >>> - We respond to the assignement a bit fast it seems and OpenBTS >>> doesn't see the first SABM at all (not in the OpenBTS trace at all) >>> - When OpenBTS sees the SABM, it responds with the UA frame >>> - OpenBTS doesn't send a new frame until quite a bit later, which >>> means the UA frame is resent several times by OpenBTS transceiver >>> application using it's filling table (which is why we see only 1 UA >>> frame in OpenBTS trace but multiple of them in the OsmocomBB trace) >>> - OsmocomBB had a bug where it was supposed to ignore the extraneous >>> UA frame but instead was dropping the connection because of a missing >>> "return" inside the switch statement. >>> >>> Cheers, >>> >>> Sylvain >> >> > -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From holger at freyther.de Tue Jan 8 09:53:40 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Tue, 8 Jan 2013 10:53:40 +0100 Subject: MDL-Error in case of OsmocomBB+OpenBTS In-Reply-To: References: Message-ID: <20130108095340.GA9909@xiaoyu.lan> On Mon, Jan 07, 2013 at 08:04:50PM +0000, Pavel Baturko wrote: Hi, > <0001> gsm48_rr.c:4984 MDL-Error (cause 3) ignoring > <0001> gsm48_rr.c:4987 MDL-Error (cause 3) aborting > <0001> gsm48_rr.c:355 new state dedicated -> idle It is something I experienced recently as well and created this[1] to improve the warning. In case of the osmo-bts this error was triggered by a wrong filling frame[2]. Make sure that OpenBTS is sending it as a command and not as a response. holger [1] http://cgit.osmocom.org/cgit/osmocom-bb/commit/?h=zecke/work-with-nitb [2] http://cgit.osmocom.org/cgit/osmo-bts/commit/?id=6ae49691afc4dc067f9dfb6c4aa386ec05f3cc1c From pabftk at gmail.com Tue Jan 8 12:31:21 2013 From: pabftk at gmail.com (Pavel Baturko) Date: Tue, 8 Jan 2013 12:31:21 +0000 Subject: MDL-Error in case of OsmocomBB+OpenBTS In-Reply-To: <20130108095340.GA9909@xiaoyu.lan> References: <20130108095340.GA9909@xiaoyu.lan> Message-ID: Hi, I tried to use OpenBTS 2.6 and OsmocomBB phone works fine with it! Seems that something wrong with OpenBTS 2.8.. But "usual" phones works with it. Holger, thanks for your answer, I'll try find problem source. All, does anyone use OpenBTS 2.8 with OsmocomBB? Thanks, Pavel On Tue, Jan 8, 2013 at 9:53 AM, Holger Hans Peter Freyther < holger at freyther.de> wrote: > On Mon, Jan 07, 2013 at 08:04:50PM +0000, Pavel Baturko wrote: > > Hi, > > > > <0001> gsm48_rr.c:4984 MDL-Error (cause 3) ignoring > > <0001> gsm48_rr.c:4987 MDL-Error (cause 3) aborting > > <0001> gsm48_rr.c:355 new state dedicated -> idle > > It is something I experienced recently as well and created this[1] to > improve the warning. In case of the osmo-bts this error was triggered > by a wrong filling frame[2]. Make sure that OpenBTS is sending it as > a command and not as a response. > > holger > > > [1] http://cgit.osmocom.org/cgit/osmocom-bb/commit/?h=zecke/work-with-nitb > [2] > http://cgit.osmocom.org/cgit/osmo-bts/commit/?id=6ae49691afc4dc067f9dfb6c4aa386ec05f3cc1c > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pabftk at gmail.com Fri Jan 11 07:33:36 2013 From: pabftk at gmail.com (Pavel Baturko) Date: Fri, 11 Jan 2013 07:33:36 +0000 Subject: MDL-Error in case of OsmocomBB+OpenBTS In-Reply-To: <1357840922.97003.YahooMailNeo@web171202.mail.ir2.yahoo.com> References: <1357840922.97003.YahooMailNeo@web171202.mail.ir2.yahoo.com> Message-ID: Hi, Erich, I'm using OpenBTS with USRP B100 & SBX. I encountered new problem, maybe it's similar to initial problem. Calls and MO SMS works fine (not in 100%, but it's ok). But MT SMS does not work (actually I received only 1 SMS from many attempts). Mobile log (error part, from line 454): <0001> gsm48_rr.c:429 new SAPI 3 link state idle -> established <000e> gsm48_rr.c:5042 Radio link SAPI3 is established <0005> gsm48_mm.c:3911 (ms 1) Received 'RR_EST_IND' from RR in state wait for network command (sapi 3) <0001> gsm48_rr.c:662 MON: f=50 lev=>=-47 snr= 0 ber= 0 LAI=001 01 0001 ID=0001 TA=3 pwr=19 TS=0/0 <0001> gsm48_rr.c:2864 MEAS REP: pwr=19 TA=3 meas-invalid=0 rxlev-full=-47 rxlev-sub=-47 rxqual-full=0 rxqual-sub=0 dtx 0 ba 0 no-ncell-n 0 <0001> gsm48_rr.c:4767 Indicated ta 3 (actual ta 3) <0001> gsm48_rr.c:4769 Indicated tx_power 19 <0001> gsm48_rr.c:4767 Indicated ta 3 (actual ta 3) <0001> gsm48_rr.c:4769 Indicated tx_power 19 <0001> gsm48_rr.c:4984 MDL-Error (cause 4) ignoring Dropping frame with 71 bit errors <0001> gsm48_rr.c:4767 Indicated ta 3 (actual ta 3) <0001> gsm48_rr.c:4769 Indicated tx_power 19 <0001> gsm48_rr.c:662 MON: f=50 lev=>=-47 snr=10 ber= 42 LAI=001 01 0001 ID=0001 TA=3 pwr=19 TS=0/0 <0001> gsm48_rr.c:2864 MEAS REP: pwr=19 TA=3 meas-invalid=0 rxlev-full=-47 rxlev-sub=-47 rxqual-full=0 rxqual-sub=0 dtx 0 ba 0 no-ncell-n 0 <0001> gsm48_rr.c:3389 channel release request with cause 0x62 <0001> gsm48_rr.c:355 new state dedicated -> release pending In trace (from packet 5509): BTS send SABM MS receive SABM MS respond with UA BTS receive UA BTS send I frame MS receive SABM (extra message?) MS respond with UA BTS receive UA BTS send DM (disconnect request? because of extra UA respond from MS?) BTS send Channel Release after that MS receive I frame and send RR with ack but as I understand this does not matter because of Chan Release.. Thanks, Pavel On Thu, Jan 10, 2013 at 6:02 PM, Erich Dachleger wrote: > What do you use to generate the network? > The osmocombb-phone or other bts? > cheers > Erich > > ________________________________ > Fra: Pavel Baturko > Til: baseband-devel at lists.osmocom.org > Sendt: Mandag, 7. januar 2013 21.04 > Emne: MDL-Error in case of OsmocomBB+OpenBTS > > Hi list, > > I'm trying to connect my OsmocomBB phone to OpenBTS and I always got > MDL-Error in mobile app log when MS trying to perform LU. > Part of log (full mobile log in attach): > <0001> gsm48_rr.c:355 new state connection pending -> dedicated > <0005> gsm48_mm.c:3911 (ms 1) Received 'RR_EST_CNF' from RR in state wait > for RR connection (location updating) (sapi 0) > <0005> gsm48_mm.c:404 starting T3210 (loc. upd. timeout) with 20.0 seconds > <0005> gsm48_mm.c:924 new state wait for RR connection (location updating) > -> location updating initiated > <0001> gsm48_rr.c:4984 MDL-Error (cause 3) ignoring > <0001> gsm48_rr.c:4987 MDL-Error (cause 3) aborting > <0001> gsm48_rr.c:355 new state dedicated -> idle > > In wireshark trace (from OpenBTS, attached) I see that MS sends LURequest > (packet 359) and BTS responds with LUAccept (packet 440) but MS never > receive this message because of error. > > As I understand this is "unsolicited UA response" from 08.58 (9.3.22) but I > do not know how to fix that or properly debug. > I'm using latest sylvain/testing and official OpenBTS 2.8. "Usual" (not with > OsmocomBB) phones works with OpenBTS fine and OsmocomBB phones works fine > with "usual" (not OpenBTS) networks. > > Thanks, > Pavel > > -------------- next part -------------- A non-text attachment was scrubbed... Name: mt_sms_fail.zip Type: application/zip Size: 122646 bytes Desc: not available URL: From dario.lombardo.ml at gmail.com Wed Jan 9 15:11:50 2013 From: dario.lombardo.ml at gmail.com (Dario Lombardo) Date: Wed, 9 Jan 2013 16:11:50 +0100 Subject: Unencrypted MT Message-ID: Hi list! As described in Nico Golde's talk at 29c3, mobile operators can deactivate encryption on MT SMSes. To check if a MT is encrypted I've started 'mobile' with GSMTAP, and I've sent an sms to the mobile. Encryption seems to be requested by the network. Now the question is: how can I be sure that encryption is always activated? Should I exaustively send messages to the mobile in order to look for unecrypted messages? Or is there some other way? People who give stats about MNO do exaustive tests, or simply generate a bunch of events and campute stats on those results? Thanks for your answers/opinions. Dario. -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Wed Jan 9 16:53:37 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 9 Jan 2013 17:53:37 +0100 Subject: Unencrypted MT In-Reply-To: References: Message-ID: Hi, > As described in Nico Golde's talk at 29c3, mobile operators can deactivate > encryption on MT SMSes. I think Nico was talking about authentication ... not encryption. Cheers, Sylvain From osmocom at ngolde.de Wed Jan 9 20:10:10 2013 From: osmocom at ngolde.de (Nico Golde) Date: Wed, 9 Jan 2013 21:10:10 +0100 Subject: Unencrypted MT In-Reply-To: References: Message-ID: <20130109201010.GA25369@nybble.binarybase.org> Hi, * Dario Lombardo [2013-01-09 20:41]: > As described in Nico Golde's talk at 29c3, mobile operators can deactivate > encryption on MT SMSes. I think this is a misunderstanding, please check the slides/video. > To check if a MT is encrypted I've started 'mobile' > with GSMTAP, and I've sent an sms to the mobile. Encryption seems to be > requested by the network. Now the question is: how can I be sure that > encryption is always activated? If the network is not encrypting, you don't get a CIPHER MODE COMMAND message. For MT you would have to generate events that cause this, like sending an SMS. For MO you can simply to a service request. Cheers Nico From dario.lombardo.ml at gmail.com Thu Jan 10 08:51:20 2013 From: dario.lombardo.ml at gmail.com (Dario Lombardo) Date: Thu, 10 Jan 2013 09:51:20 +0100 Subject: Unencrypted MT In-Reply-To: <20130109201010.GA25369@nybble.binarybase.org> References: <20130109201010.GA25369@nybble.binarybase.org> Message-ID: Hi Nico and thanks for your answer. You and Sylvain are right: there is a misunderstaning... my side :). I intended to talk about authentication, not encryption. So the question would be: do the mno disable authentication for some (or all) the mt SMSs? I think you sent a bunch of SMS to a 'mobile' app to check the presence of auth: how many of them (I'm interested in the magnitudo of your tests). Can you give the ML a ping when your code will be released (if you're planning to do so)? Have a nice day. Dario. On Wed, Jan 9, 2013 at 9:10 PM, Nico Golde wrote: > Hi, > * Dario Lombardo [2013-01-09 20:41]: > > As described in Nico Golde's talk at 29c3, mobile operators can > deactivate > > encryption on MT SMSes. > > I think this is a misunderstanding, please check the > slides/video. > > > To check if a MT is encrypted I've started 'mobile' > > with GSMTAP, and I've sent an sms to the mobile. Encryption seems to be > > requested by the network. Now the question is: how can I be sure that > > encryption is always activated? > > If the network is not encrypting, you don't get a CIPHER > MODE COMMAND message. For MT you would have to generate > events that cause this, like sending an SMS. For MO you can > simply to a service request. > > Cheers > Nico > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vamposdecampos at gmail.com Fri Jan 11 09:31:28 2013 From: vamposdecampos at gmail.com (Alex Badea) Date: Fri, 11 Jan 2013 11:31:28 +0200 Subject: GTA02 Burst_ind baudrate In-Reply-To: <5daa523c87b7914e2106cbf178e130f8@localhost> References: <5daa523c87b7914e2106cbf178e130f8@localhost> Message-ID: On Thu, Jan 10, 2013 at 11:33 PM, Heiko Besemann wrote: > > Hello Alex, You should send mail to the mailing list, instead of specific individuals. This way, i) you may get a responder quicker, and ii) information can reach other interested people. > > I read on Osmocom-BB mailing-list that you are using a GTA02 with > cross-compiled tools. Well, I did cross-compiling of the sylvain/burst_ind > branch for the OpenMoko, but starting osmocon I get an error that the > higher non-standard baudrate can not be set to /dev/ttySAC0. On the GTA02 the calypso is wired to one internal UART of the application processor SoC. AFAIR the SoC only supports up to 115200 bps so it won't be usable with burst_ind. Cheers, Alex From laforge at gnumonks.org Fri Jan 11 12:01:08 2013 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 11 Jan 2013 13:01:08 +0100 Subject: GTA02 Burst_ind baudrate In-Reply-To: References: <5daa523c87b7914e2106cbf178e130f8@localhost> Message-ID: <20130111120108.GZ21525@prithivi.gnumonks.org> Hi all, On Fri, Jan 11, 2013 at 11:31:28AM +0200, Alex Badea wrote: > On the GTA02 the calypso is wired to one internal UART of the > application processor SoC. AFAIR the SoC only supports up to 115200 > bps so it won't be usable with burst_ind. 1) the IRDA UART is wired to the 2.5mm headset plug, so _if_ the IRDA UART supports higher baudrates, you can simply output the samples there. 2) The s3c2440 user manual provides at full reference on the UART of the application processor. If you're willing to re-configure some of the internal PLLs, then you can achieve baud rates up to 921.6kbps. So I'm quite sure using the s3c2440 manual you can compute a PCLK suitable for the non-standard high baudrate of burst_ind, and then compute PLL parameters for ensuring the s3c2440 PLL generates that PCLK. 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 GNUtoo at no-log.org Fri Jan 11 13:36:20 2013 From: GNUtoo at no-log.org (Denis 'GNUtoo' Carikli) Date: Fri, 11 Jan 2013 14:36:20 +0100 Subject: GTA02 Burst_ind baudrate In-Reply-To: <20130111120108.GZ21525@prithivi.gnumonks.org> References: <5daa523c87b7914e2106cbf178e130f8@localhost> <20130111120108.GZ21525@prithivi.gnumonks.org> Message-ID: <20130111143620.2ea72dd7@no-log.org> Hi, On Fri, 11 Jan 2013 13:01:08 +0100 Harald Welte wrote: > 2) The s3c2440 user manual provides at full reference on the UART of > the application processor. If you're willing to re-configure some of > the internal PLLs, then you can achieve baud rates up to 921.6kbps. > So I'm quite sure using the s3c2440 manual you can compute a PCLK > suitable for the non-standard high baudrate of burst_ind, and then > compute PLL parameters for ensuring the s3c2440 PLL generates that > PCLK. http://lists.infradead.org/pipermail/linux-arm-kernel/2012-February/083151.html Note that it probably didn't go into mainline according to the comments of this patch. Also do higer baudrates require an external clock(I didn't check in the SC32442B datasheet)? (and I guess the GTA02 has an internal clock,but I didn't check myself on the schematics). Denis. From osmocom at ehlers.info Fri Jan 11 09:36:12 2013 From: osmocom at ehlers.info (Tim Ehlers) Date: Fri, 11 Jan 2013 10:36:12 +0100 (CET) Subject: strange crashes in current main branch Message-ID: Hi, I already mentioned a strange behavior, sometimes when running osmocom for a few days. I think this is a different issue, because it happens more frequently and the situation is a bit different. This problem does not occur with a binary from june 2012. So it has to be some change between june and now. But now the problem: When running a phone with the main branch (only tested), it sometime come to the situation that the phone says "connection pending" and is not reacting anymore. osmocon only logs periodically this line: TOA AVG is not 16 qbits, correcting (got 15) And mobile says: <0003> gsm322.c:474 Sync to ARFCN=694(DCS) rxlev=-80 (No sysinfo yet, ccch mode NONE) <000e> gsm48_mm.c:353 Periodic location update <0005> gsm48_mm.c:355 timer T3212 (periodic loc. upd. delay) has fired <0005> gsm48_mm.c:4338 (ms 1) Received 'MM_EVENT_TIMEOUT_T3212' event in state MM IDLE, normal service <000e> gsm48_mm.c:2222 Perform location update (MCC 262, MNC 07 LAC 0x27e9) <0005> gsm48_mm.c:2356 LOCATION UPDATING REQUEST <0005> gsm48_mm.c:2378 using LAI (mcc 262 mnc 07 lac 0x27e9) <0005> gsm48_mm.c:2386 using TMSI 0xXXXXXXXX <0005> gsm48_mm.c:917 new state MM IDLE, normal service -> wait for RR connection (location updating) <0001> gsm48_rr.c:5575 (ms 1) Message 'RR_EST_REQ' received in state idle (sapi 0) <000e> gsm48_rr.c:1352 Establish radio link due to mobility management request <0003> gsm322.c:4049 (ms 1) Event 'EVENT_LEAVE_IDLE' for Cell selection in state 'C3 camped normally' <0003> gsm322.c:829 new state 'C3 camped normally' -> 'connected mode 1' <0003> gsm322.c:3665 Going to camping (normal) ARFCN 664(DCS). <0003> gsm322.c:452 Sync to ARFCN=664(DCS), but there is a sync already pending <0001> gsm48_rr.c:355 new state idle -> connection pending <0001> gsm48_rr.c:1504 CHANNEL REQUEST: 00 (Location Update no NECI) Mobile says nothing when shutting the phone off or on: OsmocomBB(ms)#shutdown OsmocomBB(ms)# OsmocomBB(ms)#no shutdown OsmocomBB(ms)# Only logs: <0005> gsm48_mm.c:4342 (ms 1) Received 'MM_EVENT_IMSI_DETACH' event in state wait for RR connection (location updating) <0005> gsm48_mm.c:1992 IMSI detach delayed. Killing and restarting mobile leads to: eeepc:~ # mobile -i 127.0.0.1 Copyright (C) 2008-2010 ... Contributions by ... License GPLv2+: GNU GPL version 2 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. <000f> sim.c:1223 init SIM client <0006> gsm48_cc.c:63 init Call Control <0007> gsm480_ss.c:231 init SS <0017> gsm411_sms.c:63 init SMS <0001> gsm48_rr.c:5626 init Radio Ressource process <0005> gsm48_mm.c:1327 init Mobility Management process <0005> gsm48_mm.c:1040 Selecting PLMN SEARCH state, because no SIM. <0002> gsm322.c:5037 init PLMN process <0003> gsm322.c:5038 init Cell Selection process <0003> gsm322.c:5095 Read stored BA list (mcc=262 mnc=01 Germany, T-Mobile) <0003> gsm322.c:5095 Read stored BA list (mcc=262 mnc=07 Germany, O2) Mobile '1' initialized, please start phone now! VTY available on port 4247. And layer1 still logs some: TOA AVG is not 16 qbits, correcting (got 15) TOA AVG is not 16 qbits, correcting (got 15) TOA AVG is not 16 qbits, correcting (got 15) Has anybody a clue how this could happen from time to time? Cheers Tim From osmocom at ehlers.info Tue Jan 22 08:49:40 2013 From: osmocom at ehlers.info (Tim Ehlers) Date: Tue, 22 Jan 2013 09:49:40 +0100 (CET) Subject: strange crashes in current main branch In-Reply-To: References: Message-ID: On Fri, 11 Jan 2013, Tim Ehlers wrote: Hi, > TOA AVG is not 16 qbits, correcting (got 15) > TOA AVG is not 16 qbits, correcting (got 15) > TOA AVG is not 16 qbits, correcting (got 15) > > Has anybody a clue how this could happen from time to time? mhh, I reply to myself, since nobody seems to have that problem too? In the meantime I made further inverstigations and came to the conclusion that theses crashes are related to the layer1. When using a new mobile and osmocon application, but the old layer1: no crash. And I should mention that I have a C118 (e88) phone. I newly got a e99 phone and interestingly this phone doesn't crash with current layer1. But before you think the hardware is broken. I have several e88 phones and all of them behave the same. In the past I used the pre-compiled cross-compiler gnuarm-3.4.3. According to the new Wiki-pages I compiled the combi binutils-2.21.1, newlib-1.19.0 and gcc-4.5.2. Tried it with e88 and e99 during the night. Today e88 crashed again. So do I have a special cell here (SIMs are from german O2 prepaid platform) causing crashes to layer1 (e88)? Or what is special here? I made a diff between working and not working compal_e88 directory, but the changes are only some kind of irq-changes, like: - calypso_bootrom(1); + calypso_bootrom(with_irq); and so on. I think this is not the problem, or could it open a race condition? But why am I the only one with this problem? Has anybody a suggestion, what I could test to track the problem down? Cheers Tim From edachleger at yahoo.com Sat Jan 12 09:05:41 2013 From: edachleger at yahoo.com (Erich Dachleger) Date: Sat, 12 Jan 2013 09:05:41 +0000 (GMT) Subject: calypso-talk 29c3 Message-ID: <1357981541.25897.YahooMailNeo@web171202.mail.ir2.yahoo.com> Hi list, I saw the interesting talk about turning the osmocombb-phone into a proof of concept bts using openbts. During the talk:When? OpenBts was configured(before using sipauthserve) was? it the option --with-uhd (as is for umtrx )that was used? Does anybody know when the code will be released? [I built sylvain/testing branch as well as branch jolly/meas branch some days ago, but I couldn't find that code anywhere, so I guess it is not available anywhere yet] regards erich -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas at eversberg.eu Mon Jan 14 10:40:37 2013 From: andreas at eversberg.eu (jolly) Date: Mon, 14 Jan 2013 11:40:37 +0100 Subject: osmocombb: TS 3 -> TS failed Message-ID: <50F3E0A5.9040100@eversberg.eu> hi, i just encountered the following problem: the network assigns me from TS 1 to TS 3 it worked, but not when it did another assigment from TS 3 to TS4. i just got noise instead of valid SACCH frames. TS Chg forth: 1 -> 3 | 1856 ... TS Chg forth: 3 -> 4 | 1875 this is the wireshark trace of both assignments. they only differ in the assigned slot: Frame 3225: 81 bytes on wire (648 bits), 81 bytes captured (648 bits) Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00) Internet Protocol Version 4, Src: 127.0.0.1 (127.0.0.1), Dst: 127.0.0.1 (127.0.0.1) User Datagram Protocol, Src Port: 52261 (52261), Dst Port: gsmtap (4729) GSM TAP Header, ARFCN: 34 (Downlink), TS: 1, Channel: SDCCH/8 (0) Link Access Procedure, Channel Dm (LAPDm) GSM A-I/F DTAP - Assignment Command Protocol Discriminator: Radio Resources Management messages DTAP Radio Resources Management Message Type: Assignment Command (0x2e) Channel Description 2 - Description of the First Channel, after time 0000 1... = TCH/F + FACCH/F and SACCH/F .... .011 = Timeslot: 3 000. .... = Training Sequence: 0 ...1 .... = Hopping channel: Yes Hopping channel: MAIO 0 Hopping channel: HSN 0 Power Command 0... .... = Spare: 0 .0.. .... = EPC_mode: Channel(s) not in EPC mode ..0. .... = FPC_EPC: FPC not in use/C not in use for uplink power control ...0 0101 = POWER LEVEL: 5 Frequency List - Frequency List, after time Element ID: 5 Length: 16 00.. 000. = Format Identifier: bit map 0 (0x00) List of ARFCNs = 99 34 Channel Mode - Mode of the First Channel(Channel Set 1) Element ID: 99 Channel Mode: speech full rate or half rate version 2(GSM EFR) (33) No. Time Source Destination Protocol Info 3243 464.672890 127.0.0.1 127.0.0.1 LAPDm I, N(R)=1, N(S)=2(DTAP) (RR) Assignment Command Frame 3243: 81 bytes on wire (648 bits), 81 bytes captured (648 bits) Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00) Internet Protocol Version 4, Src: 127.0.0.1 (127.0.0.1), Dst: 127.0.0.1 (127.0.0.1) User Datagram Protocol, Src Port: 52261 (52261), Dst Port: gsmtap (4729) GSM TAP Header, ARFCN: 99 (Downlink), TS: 3, Channel: FACCH/F (0) Link Access Procedure, Channel Dm (LAPDm) GSM A-I/F DTAP - Assignment Command Protocol Discriminator: Radio Resources Management messages DTAP Radio Resources Management Message Type: Assignment Command (0x2e) Channel Description 2 - Description of the First Channel, after time 0000 1... = TCH/F + FACCH/F and SACCH/F .... .100 = Timeslot: 4 000. .... = Training Sequence: 0 ...1 .... = Hopping channel: Yes Hopping channel: MAIO 0 Hopping channel: HSN 0 Power Command 0... .... = Spare: 0 .0.. .... = EPC_mode: Channel(s) not in EPC mode ..0. .... = FPC_EPC: FPC not in use/C not in use for uplink power control ...0 0101 = POWER LEVEL: 5 Frequency List - Frequency List, after time Element ID: 5 Length: 16 00.. 000. = Format Identifier: bit map 0 (0x00) List of ARFCNs = 99 34 Channel Mode - Mode of the First Channel(Channel Set 1) Element ID: 99 Channel Mode: speech full rate or half rate version 2(GSM EFR) (33) any idea why this does not work? i used the "[WIP] Ugly hack to compensate lost time on TS change (high TS -> low TS)" path. regards, andreas From 246tnt at gmail.com Mon Jan 14 12:22:37 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Mon, 14 Jan 2013 13:22:37 +0100 Subject: osmocombb: TS 3 -> TS failed In-Reply-To: <50F3E0A5.9040100@eversberg.eu> References: <50F3E0A5.9040100@eversberg.eu> Message-ID: Hi, > i just encountered the following problem: > > the network assigns me from TS 1 to TS 3 it worked, but not when it did > another assigment from TS 3 to TS4. i just got noise instead of valid > SACCH frames. > > TS Chg forth: 1 -> 3 | 1856 > ... > TS Chg forth: 3 -> 4 | 1875 My guess is that somehow the fact they're contiguous makes something fail ... This whole timeslot alignement thing is highly unstable ... I think I need to code a special version of OpenBTS that broadcast on each burst the TS it belongs to and the frame number and then do some stress test of timeslot changing. Cheers, Sylvain From andreas at eversberg.eu Mon Jan 14 17:32:42 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Mon, 14 Jan 2013 18:32:42 +0100 Subject: osmocombb: TS 3 -> TS failed In-Reply-To: References: <50F3E0A5.9040100@eversberg.eu> Message-ID: <50F4413A.9050705@eversberg.eu> > TS Chg forth: 1 -> 3 | 1856 > ... > TS Chg forth: 3 -> 4 | 1875 > i wonder why the network pushs me from one slot to another... i have no idea what this might be good for. From Max.Suraev at fairwaves.ru Mon Jan 14 17:22:21 2013 From: Max.Suraev at fairwaves.ru (=?UTF-8?B?4piO?=) Date: Mon, 14 Jan 2013 18:22:21 +0100 Subject: [PATCH] Improve hex parser Message-ID: <50F43ECD.5070700@fairwaves.ru> Hello. Current implementation of osmo_hexparse have couple of limitations (which are undocumented btw): * it refuses to parse odd-length numbers (e. g. 7abdf) * it fails while parsing 0x prefix (e. g. 0xdead) Both could be worked around by upper-layer code of course but since both cases above are perfectly valid hexadecimal numbers I think they should be handled by osmo_hexparse internally without complicating life of library users. Attached patch does just that. Please review and merge if it feels OK. -- best regards, Max, http://fairwaves.ru From Max.Suraev at fairwaves.ru Mon Jan 14 17:14:30 2013 From: Max.Suraev at fairwaves.ru (Max) Date: Mon, 14 Jan 2013 18:14:30 +0100 Subject: [PATCH] Improve hex parser robustness. Message-ID: --- src/utils.c | 26 ++++++++++++++++++++++---- 1 file changed, 22 insertions(+), 4 deletions(-) diff --git a/src/utils.c b/src/utils.c index c36979c..525bff1 100644 --- a/src/utils.c +++ b/src/utils.c @@ -73,7 +73,7 @@ uint8_t osmo_char2bcd(char c) return c - 0x30; } -/*! \brief Parse a string ocntaining hexadecimal digits +/*! \brief Parse a string ocntaining hexadecimal digits, optionally prefixed with 0x * \param[in] str string containing ASCII encoded hexadecimal digits * \param[out] b output buffer * \param[in] max_len maximum space in output buffer @@ -81,10 +81,28 @@ uint8_t osmo_char2bcd(char c) int osmo_hexparse(const char *str, uint8_t *b, int max_len) { - int i, l, v; + int v; + size_t i, l = strlen(str); + + if (l > 2) { /* remove 0x prefix if any */ + if ('0' == str[0] && 'x' == str[1]) { + l -= 2; + str += 2; + } + } + + if (l & 1) i = l + 1; + else i = l; + char hs[i]; /* enough space to store additional leading 0 if str length is odd */ + + if (l & 1) { + memcpy(hs + 1, str, l); + hs[0] = '0'; + } else { + memcpy(hs, str, l); + } - l = strlen(str); - if ((l&1) || ((l>>1) > max_len)) + if ((l>>1) > max_len) return -1; memset(b, 0x00, max_len); -- 1.7.10.4 --------------040904080202060501050607-- From Max.Suraev at fairwaves.ru Mon Jan 14 18:13:15 2013 From: Max.Suraev at fairwaves.ru (=?UTF-8?B?4piO?=) Date: Mon, 14 Jan 2013 19:13:15 +0100 Subject: [PATCH] Improve hex parser v.2 In-Reply-To: <50F43ECD.5070700@fairwaves.ru> References: <50F43ECD.5070700@fairwaves.ru> Message-ID: <50F44ABB.1050601@fairwaves.ru> Second version: - fix forgotten variable - preserve backward compatibility with regards to odd length behavior -- looking forward for your comments, Max, http://fairwaves.ru From Max.Suraev at fairwaves.ru Mon Jan 14 17:14:30 2013 From: Max.Suraev at fairwaves.ru (Max) Date: Mon, 14 Jan 2013 18:14:30 +0100 Subject: [PATCH] Improve hex parser robustness. Message-ID: --- include/osmocom/core/utils.h | 2 ++ src/utils.c | 48 ++++++++++++++++++++++++++++++++++++------ 2 files changed, 44 insertions(+), 6 deletions(-) diff --git a/include/osmocom/core/utils.h b/include/osmocom/core/utils.h index 03861d7..05cb2a4 100644 --- a/include/osmocom/core/utils.h +++ b/include/osmocom/core/utils.h @@ -15,6 +15,7 @@ #define OSMO_MIN(a, b) ((a) >= (b) ? (b) : (a)) #include +#include /*! \brief A mapping between human-readable string and numeric value */ struct value_string { @@ -30,6 +31,7 @@ char osmo_bcd2char(uint8_t bcd); /* only works for numbers in ascci */ uint8_t osmo_char2bcd(char c); +int osmo_hexparse_adv(const char *str, uint8_t *b, int max_len, bool allow_odd); int osmo_hexparse(const char *str, uint8_t *b, int max_len); char *osmo_ubit_dump(const uint8_t *bits, unsigned int len); diff --git a/src/utils.c b/src/utils.c index c36979c..8c1849e 100644 --- a/src/utils.c +++ b/src/utils.c @@ -3,7 +3,7 @@ #include #include #include - +#include #include /*! \addtogroup utils @@ -73,24 +73,60 @@ uint8_t osmo_char2bcd(char c) return c - 0x30; } -/*! \brief Parse a string ocntaining hexadecimal digits +/*! \brief Parse a string ocntaining hexadecimal digits, optionally prefixed with 0x * \param[in] str string containing ASCII encoded hexadecimal digits * \param[out] b output buffer * \param[in] max_len maximum space in output buffer */ int osmo_hexparse(const char *str, uint8_t *b, int max_len) +{ + return osmo_hexparse_adv(str, b, max_len, false); +} +/*! \brief Parse a string ocntaining hexadecimal digits, optionally prefixed with 0x + * \param[in] str string containing ASCII encoded hexadecimal digits + * \param[out] b output buffer + * \param[in] max_len maximum space in output buffer + * \param[in] allow_odd allow odd length (prefix with 0 on the left side) + */ +int osmo_hexparse_adv(const char *str, uint8_t *b, int max_len, bool allow_odd) { - int i, l, v; + int v; + size_t i, l = strlen(str); + const char * src; + + if (l > 2) { /* remove 0x prefix if any */ + if ('0' == str[0] && 'x' == str[1]) { + l -= 2; + str += 2; + } + } + + if (allow_odd) { + if (l & 1) i = l + 1; + else i = l; + char hs[i]; /* enough space to store additional leading 0 if str length is odd */ + + if (l & 1) { + memcpy(hs + 1, str, l); + hs[0] = '0'; + } else { + memcpy(hs, str, l); + } + src = hs; + } else { + if (l & 1) + return -1; + src = str; + } - l = strlen(str); - if ((l&1) || ((l>>1) > max_len)) + if ((l>>1) > max_len) return -1; memset(b, 0x00, max_len); for (i=0; i= '0' && c <= '9') v = c - '0'; else if (c >= 'a' && c <= 'f') -- 1.7.10.4 --------------070900070504060905060402-- From peter at stuge.se Tue Jan 15 00:59:09 2013 From: peter at stuge.se (Peter Stuge) Date: Tue, 15 Jan 2013 01:59:09 +0100 Subject: [PATCH] Improve hex parser v.2 In-Reply-To: <50F44ABB.1050601@fairwaves.ru> References: <50F43ECD.5070700@fairwaves.ru> <50F44ABB.1050601@fairwaves.ru> Message-ID: <20130115005909.6246.qmail@stuge.se> Thanks for the initiative! I completely agree with adding this functionality, but I have some concern about the implementation.. > +++ b/src/utils.c .. > +int osmo_hexparse_adv(const char *str, uint8_t *b, int max_len, bool allow_odd) What's the use case for not allowing an odd number of hexits? I think if any code relies on osmo_hexparse() being unable to parse an odd number of hexits then that code must be fixed. > { > - int i, l, v; > + int v; > + size_t i, l = strlen(str); > + const char * src; > + > + if (l > 2) { /* remove 0x prefix if any */ > + if ('0' == str[0] && 'x' == str[1]) { I suggest: if (!strncmp(str, "0x", 2)) { > + if (allow_odd) { > + if (l & 1) i = l + 1; > + else i = l; Is the above code style used elsewhere in the file? I haven't looked, but the proposed lines can be made a lot nicer. Please optimize for readability. > + char hs[i]; /* enough space to store additional leading 0 if str length is odd */ Why is this even needed? > + if (l & 1) { > + memcpy(hs + 1, str, l); > + hs[0] = '0'; > + } else { > + memcpy(hs, str, l); > + } Please don't ever add memcpy() to any code anywhere. Always try to eliminate memcpy() everywhere. There is no need for memcpy() here. Just handle the case of odd number of hexits inside the loop instead. It fits fine into the existing code paths. No memory allocation and no memory copying needed. Always strive for zero copy. > - l = strlen(str); > - if ((l&1) || ((l>>1) > max_len)) > + if ((l>>1) > max_len) > return -1; The old code also used bit shifts, but I'd prefer using l / 2 for readability. The compiler will optimize it, and since this is not a bitwise operation but an arithmetic operation it is more clear to use the divide operand in the source code. Bonus: divide operand takes precedence over greater-than condition, so can remove parentheses. > for (i=0; i - char c = str[i]; > + char c = src[i]; Here, I suggest to instead insert something like: if (0 == i && 1 == l % 2) { /* special case for odd number of hexits */ /* convert one input character into lower nibble of output */ continue; } //Peter From 246tnt at gmail.com Tue Jan 15 06:52:49 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Tue, 15 Jan 2013 07:52:49 +0100 Subject: [PATCH] Improve hex parser v.2 In-Reply-To: <20130115005909.6246.qmail@stuge.se> References: <50F43ECD.5070700@fairwaves.ru> <50F44ABB.1050601@fairwaves.ru> <20130115005909.6246.qmail@stuge.se> Message-ID: On Tue, Jan 15, 2013 at 1:59 AM, Peter Stuge wrote: > Thanks for the initiative! I completely agree with adding this > functionality, but I have some concern about the implementation.. fyi, I've actually been discussing the path with him on IRC. Hopefully should get a new patch soon :p Cheers, Sylvain From Max.Suraev at fairwaves.ru Tue Jan 15 09:56:12 2013 From: Max.Suraev at fairwaves.ru (=?UTF-8?B?4piO?=) Date: Tue, 15 Jan 2013 10:56:12 +0100 Subject: [PATCH] Improve hex parser v.2 In-Reply-To: References: <50F43ECD.5070700@fairwaves.ru> <50F44ABB.1050601@fairwaves.ru> <20130115005909.6246.qmail@stuge.se> Message-ID: <50F527BC.3000804@fairwaves.ru> 15.01.2013 07:52, Sylvain Munaut ?????: > On Tue, Jan 15, 2013 at 1:59 AM, Peter Stuge wrote: >> Thanks for the initiative! I completely agree with adding this >> functionality, but I have some concern about the implementation.. > > fyi, I've actually been discussing the path with him on IRC. Hopefully > should get a new patch soon :p Working on regression tests - stay tuned :) -- best regards, Max, http://fairwaves.ru From Max.Suraev at fairwaves.ru Tue Jan 15 14:31:23 2013 From: Max.Suraev at fairwaves.ru (=?UTF-8?B?4piO?=) Date: Tue, 15 Jan 2013 15:31:23 +0100 Subject: [PATCH] Improve hex parser v.3 In-Reply-To: <50F43ECD.5070700@fairwaves.ru> References: <50F43ECD.5070700@fairwaves.ru> Message-ID: <50F5683B.7040300@fairwaves.ru> Attached is improved version of the patch per discussions on irc and ML: * no more memory allocation * more readable code * regression tests Please review and merge if it's ok :) -- best regards, Max, http://fairwaves.ru From Max.Suraev at fairwaves.ru Mon Jan 14 17:14:30 2013 From: Max.Suraev at fairwaves.ru (Max) Date: Mon, 14 Jan 2013 18:14:30 +0100 Subject: [PATCH] Improve hex parser robustness. Message-ID: --- .gitignore | 1 + include/osmocom/core/utils.h | 5 ++++ src/utils.c | 68 ++++++++++++++++++++++++++++++++---------- tests/Makefile.am | 7 +++-- tests/hex/hex_test.c | 52 ++++++++++++++++++++++++++++++++ tests/hex/hex_test.ok | 18 +++++++++++ tests/testsuite.at | 6 ++++ 7 files changed, 140 insertions(+), 17 deletions(-) create mode 100644 tests/hex/hex_test.c create mode 100644 tests/hex/hex_test.ok diff --git a/.gitignore b/.gitignore index ac19b23..67d9196 100644 --- a/.gitignore +++ b/.gitignore @@ -58,6 +58,7 @@ tests/sms/sms_test tests/timer/timer_test tests/msgfile/msgfile_test tests/ussd/ussd_test +tests/hex/hex_test tests/smscb/smscb_test tests/bits/bitrev_test tests/a5/a5_test diff --git a/include/osmocom/core/utils.h b/include/osmocom/core/utils.h index 03861d7..5250094 100644 --- a/include/osmocom/core/utils.h +++ b/include/osmocom/core/utils.h @@ -30,6 +30,11 @@ char osmo_bcd2char(uint8_t bcd); /* only works for numbers in ascci */ uint8_t osmo_char2bcd(char c); +enum hex_len_policy { /* define how to deal with odd length during hex string parsing */ + HEX_ODD_NONE, HEX_ODD_LEFT, HEX_ODD_RIGHT +}; + +int osmo_hexparse_ext(const char *str, uint8_t *b, int max_len, enum hex_len_policy pol); int osmo_hexparse(const char *str, uint8_t *b, int max_len); char *osmo_ubit_dump(const uint8_t *bits, unsigned int len); diff --git a/src/utils.c b/src/utils.c index c36979c..cd11618 100644 --- a/src/utils.c +++ b/src/utils.c @@ -73,36 +73,74 @@ uint8_t osmo_char2bcd(char c) return c - 0x30; } -/*! \brief Parse a string ocntaining hexadecimal digits +/*! \brief Parse a string ocntaining hexadecimal digits, optionally prefixed with 0x * \param[in] str string containing ASCII encoded hexadecimal digits * \param[out] b output buffer * \param[in] max_len maximum space in output buffer */ int osmo_hexparse(const char *str, uint8_t *b, int max_len) +{ + return osmo_hexparse_ext(str, b, max_len, HEX_ODD_NONE); +} +inline int _osmo_hexval(char c) { - int i, l, v; + if (c >= '0' && c <= '9') + return c - '0'; + if (c >= 'a' && c <= 'f') + return 10 + (c - 'a'); + if (c >= 'A' && c <= 'F') + return 10 + (c - 'A'); + return -1; +} - l = strlen(str); - if ((l&1) || ((l>>1) > max_len)) +/*! \brief Parse a string ocntaining hexadecimal digits, optionally prefixed with 0x + * \param[in] str string containing ASCII encoded hexadecimal digits + * \param[out] b output buffer + * \param[in] max_len maximum space in output buffer + * \param[in] pol defines how to treat odd length case + */ +int osmo_hexparse_ext(const char *str, uint8_t *b, int max_len, enum hex_len_policy pol) +{ + int v; + size_t i, left_adj = 0, right_adj = 0, l = strlen(str); + const char * src; + + if (l > 2) { /* remove 0x prefix if any */ + if (!strncmp(str, "0x", 2)) { + l -= 2; + str += 2; + } + } + + if (l & 1) { + switch (pol) { + case HEX_ODD_LEFT: + left_adj = 1; + break; + case HEX_ODD_NONE: + return -1; + case HEX_ODD_RIGHT: + right_adj = 1; + break; + default: + return -1; + } + } + /* left_adj and right_adj are mutually exclusive so left_adj + right_adj is either 1 or 0 */ + if ((l>>1) > max_len + left_adj + right_adj) return -1; - memset(b, 0x00, max_len); + memset(b, 0x00, max_len + left_adj + right_adj); for (i=0; i= '0' && c <= '9') - v = c - '0'; - else if (c >= 'a' && c <= 'f') - v = 10 + (c - 'a'); - else if (c >= 'A' && c <= 'F') - v = 10 + (c - 'A'); - else + v = _osmo_hexval(str[i]); + if (-1 == v) return -1; - b[i>>1] |= v << (i&1 ? 0 : 4); + b[(i + left_adj) >> 1] |= v << ( (i + left_adj) & 1 ? 0 : 4); } - return i>>1; + return (l + left_adj + right_adj)/2; } static char hexd_buff[4096]; diff --git a/tests/Makefile.am b/tests/Makefile.am index b60f675..fbefab1 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -4,7 +4,7 @@ check_PROGRAMS = timer/timer_test sms/sms_test ussd/ussd_test \ smscb/smscb_test bits/bitrev_test a5/a5_test \ conv/conv_test auth/milenage_test lapd/lapd_test \ gsm0808/gsm0808_test gsm0408/gsm0408_test \ - gb/bssgp_fc_test logging/logging_test + gb/bssgp_fc_test hex/hex_test logging/logging_test if ENABLE_MSGFILE check_PROGRAMS += msgfile/msgfile_test endif @@ -21,6 +21,9 @@ bits_bitrev_test_LDADD = $(top_builddir)/src/libosmocore.la conv_conv_test_SOURCES = conv/conv_test.c conv_conv_test_LDADD = $(top_builddir)/src/libosmocore.la +hex_hex_test_SOURCES = hex/hex_test.c +hex_hex_test_LDADD = $(top_builddir)/src/libosmocore.la + gsm0808_gsm0808_test_SOURCES = gsm0808/gsm0808_test.c gsm0808_gsm0808_test_LDADD = $(top_builddir)/src/libosmocore.la $(top_builddir)/src/gsm/libosmogsm.la @@ -77,7 +80,7 @@ EXTRA_DIST = testsuite.at $(srcdir)/package.m4 $(TESTSUITE) \ gsm0808/gsm0808_test.ok gb/bssgp_fc_tests.err \ gb/bssgp_fc_tests.ok gb/bssgp_fc_tests.sh \ msgfile/msgfile_test.ok msgfile/msgconfig.cfg \ - logging/logging_test.ok logging/logging_test.err + logging/logging_test.ok hex/hex_test.ok logging/logging_test.err DISTCLEANFILES = atconfig diff --git a/tests/hex/hex_test.c b/tests/hex/hex_test.c new file mode 100644 index 0000000..fa85065 --- /dev/null +++ b/tests/hex/hex_test.c @@ -0,0 +1,52 @@ +#include +#include +#include + +#include + +/* ------------------------------------------------------------------------ */ +/* Test vectors */ +/* ------------------------------------------------------------------------ */ + +char * long_rand_x = "0xa63c3b465eb79b3e06ae66eb816eace"; +char * long_rand = "39ea2e536e6a2c0d3e59110df20e4bf"; +char * small_even_x = "0xDEAD"; +char * small_even = "FACE"; +char * small_odd_x = "0xFFACE"; +char * small_odd = "bee"; + +/* ------------------------------------------------------------------------ */ +/* Main */ +/* ------------------------------------------------------------------------ */ + +inline void _run_tests(char * vec, size_t len) +{ + uint8_t test[len]; + + int parsed = osmo_hexparse_ext(vec, test, len, HEX_ODD_NONE); + printf("NONE parsed %s: %d", vec, parsed); + if (-1 != parsed) printf(", dumped: %s\n", osmo_hexdump_nospc(test, len)); + else printf("\n"); + + parsed = osmo_hexparse_ext(vec, test, len, HEX_ODD_LEFT); + printf("LEFT parsed %s: %d", vec, parsed); + if (-1 != parsed) printf(", dumped: %s\n", osmo_hexdump_nospc(test, len)); + else printf("\n"); + + parsed = osmo_hexparse_ext(vec, test, len, HEX_ODD_RIGHT); + printf("RIGHT parsed %s: %d", vec, parsed); + if (-1 != parsed) printf(", dumped: %s\n", osmo_hexdump_nospc(test, len)); + else printf("\n"); +} + +int main(int argc, char argv[]) +{ + _run_tests(long_rand_x, 16); + _run_tests(long_rand, 16); + _run_tests(small_even_x, 2); + _run_tests(small_even, 2); + _run_tests(small_odd_x, 3); + _run_tests(small_odd, 2); + + return 0; +} diff --git a/tests/hex/hex_test.ok b/tests/hex/hex_test.ok new file mode 100644 index 0000000..1419b8c --- /dev/null +++ b/tests/hex/hex_test.ok @@ -0,0 +1,18 @@ +NONE parsed 0xa63c3b465eb79b3e06ae66eb816eace: -1 +LEFT parsed 0xa63c3b465eb79b3e06ae66eb816eace: 16, dumped: 0a63c3b465eb79b3e06ae66eb816eace +RIGHT parsed 0xa63c3b465eb79b3e06ae66eb816eace: 16, dumped: a63c3b465eb79b3e06ae66eb816eace0 +NONE parsed 39ea2e536e6a2c0d3e59110df20e4bf: -1 +LEFT parsed 39ea2e536e6a2c0d3e59110df20e4bf: 16, dumped: 039ea2e536e6a2c0d3e59110df20e4bf +RIGHT parsed 39ea2e536e6a2c0d3e59110df20e4bf: 16, dumped: 39ea2e536e6a2c0d3e59110df20e4bf0 +NONE parsed 0xDEAD: 2, dumped: dead +LEFT parsed 0xDEAD: 2, dumped: dead +RIGHT parsed 0xDEAD: 2, dumped: dead +NONE parsed FACE: 2, dumped: face +LEFT parsed FACE: 2, dumped: face +RIGHT parsed FACE: 2, dumped: face +NONE parsed 0xFFACE: -1 +LEFT parsed 0xFFACE: 3, dumped: 0fface +RIGHT parsed 0xFFACE: 3, dumped: fface0 +NONE parsed bee: -1 +LEFT parsed bee: 2, dumped: 0bee +RIGHT parsed bee: 2, dumped: bee0 diff --git a/tests/testsuite.at b/tests/testsuite.at index 1cfae03..cfbcf78 100644 --- a/tests/testsuite.at +++ b/tests/testsuite.at @@ -28,6 +28,12 @@ cat $abs_srcdir/conv/conv_test.ok > expout AT_CHECK([$abs_top_builddir/tests/conv/conv_test], [], [expout]) AT_CLEANUP +AT_SETUP([hex]) +AT_KEYWORDS([hex]) +cat $abs_srcdir/hex/hex_test.ok > expout +AT_CHECK([$abs_top_builddir/tests/hex/hex_test], [], [expout]) +AT_CLEANUP + if ENABLE_MSGFILE AT_SETUP([msgfile]) AT_KEYWORDS([msgfile]) -- 1.7.10.4 --------------040406000709000102010704-- From Max.Suraev at fairwaves.ru Tue Jan 15 16:35:27 2013 From: Max.Suraev at fairwaves.ru (=?UTF-8?B?4piO?=) Date: Tue, 15 Jan 2013 17:35:27 +0100 Subject: [PATCH] Improve hex parser v.4 In-Reply-To: <50F43ECD.5070700@fairwaves.ru> References: <50F43ECD.5070700@fairwaves.ru> Message-ID: <50F5854F.8070905@fairwaves.ru> * Fixed last byte corruption * Updated test suit * Improved style -- best regards, Max, http://fairwaves.ru From Max.Suraev at fairwaves.ru Mon Jan 14 17:14:30 2013 From: Max.Suraev at fairwaves.ru (Max) Date: Mon, 14 Jan 2013 18:14:30 +0100 Subject: [PATCH] Improve hex parser robustness. Message-ID: --- .gitignore | 1 + include/osmocom/core/utils.h | 5 ++++ src/utils.c | 68 ++++++++++++++++++++++++++++++++---------- tests/Makefile.am | 7 +++-- tests/hex/hex_test.c | 57 +++++++++++++++++++++++++++++++++++ tests/hex/hex_test.ok | 18 +++++++++++ tests/testsuite.at | 6 ++++ 7 files changed, 145 insertions(+), 17 deletions(-) create mode 100644 tests/hex/hex_test.c create mode 100644 tests/hex/hex_test.ok diff --git a/.gitignore b/.gitignore index ac19b23..67d9196 100644 --- a/.gitignore +++ b/.gitignore @@ -58,6 +58,7 @@ tests/sms/sms_test tests/timer/timer_test tests/msgfile/msgfile_test tests/ussd/ussd_test +tests/hex/hex_test tests/smscb/smscb_test tests/bits/bitrev_test tests/a5/a5_test diff --git a/include/osmocom/core/utils.h b/include/osmocom/core/utils.h index 03861d7..5250094 100644 --- a/include/osmocom/core/utils.h +++ b/include/osmocom/core/utils.h @@ -30,6 +30,11 @@ char osmo_bcd2char(uint8_t bcd); /* only works for numbers in ascci */ uint8_t osmo_char2bcd(char c); +enum hex_len_policy { /* define how to deal with odd length during hex string parsing */ + HEX_ODD_NONE, HEX_ODD_LEFT, HEX_ODD_RIGHT +}; + +int osmo_hexparse_ext(const char *str, uint8_t *b, int max_len, enum hex_len_policy pol); int osmo_hexparse(const char *str, uint8_t *b, int max_len); char *osmo_ubit_dump(const uint8_t *bits, unsigned int len); diff --git a/src/utils.c b/src/utils.c index c36979c..a93d72c 100644 --- a/src/utils.c +++ b/src/utils.c @@ -73,36 +73,74 @@ uint8_t osmo_char2bcd(char c) return c - 0x30; } -/*! \brief Parse a string ocntaining hexadecimal digits +/*! \brief Parse a string ocntaining hexadecimal digits, optionally prefixed with 0x * \param[in] str string containing ASCII encoded hexadecimal digits * \param[out] b output buffer * \param[in] max_len maximum space in output buffer */ int osmo_hexparse(const char *str, uint8_t *b, int max_len) +{ + return osmo_hexparse_ext(str, b, max_len, HEX_ODD_NONE); +} +static inline int _osmo_hexval(char c) { - int i, l, v; + if (c >= '0' && c <= '9') + return c - '0'; + if (c >= 'a' && c <= 'f') + return 10 + (c - 'a'); + if (c >= 'A' && c <= 'F') + return 10 + (c - 'A'); + return -1; +} - l = strlen(str); - if ((l&1) || ((l>>1) > max_len)) +/*! \brief Parse a string ocntaining hexadecimal digits, optionally prefixed with 0x + * \param[in] str string containing ASCII encoded hexadecimal digits + * \param[out] b output buffer + * \param[in] max_len maximum space in output buffer + * \param[in] pol defines how to treat odd length case + */ +int osmo_hexparse_ext(const char *str, uint8_t *b, int max_len, enum hex_len_policy pol) +{ + int v; + size_t i, left_adj = 0, right_adj = 0, l = strlen(str); + const char *src; + + if (l > 2) { /* remove 0x prefix if any */ + if (!strncmp(str, "0x", 2)) { + l -= 2; + str += 2; + } + } + + if (l & 1) { + switch (pol) { + case HEX_ODD_LEFT: + left_adj = 1; + break; + case HEX_ODD_NONE: + return -1; + case HEX_ODD_RIGHT: + right_adj = 1; + break; + default: + return -1; + } + } +/* left_adj and right_adj are mutually exclusive so left_adj + right_adj is either 1 or 0 */ + if ((l>>1) + left_adj + right_adj > max_len) return -1; memset(b, 0x00, max_len); - for (i=0; i= '0' && c <= '9') - v = c - '0'; - else if (c >= 'a' && c <= 'f') - v = 10 + (c - 'a'); - else if (c >= 'A' && c <= 'F') - v = 10 + (c - 'A'); - else + for (i = 0; i < l; i++) { + v = _osmo_hexval(str[i]); + if (-1 == v) return -1; - b[i>>1] |= v << (i&1 ? 0 : 4); + b[(i + left_adj) >> 1] |= v << ((i + left_adj) & 1 ? 0 : 4); } - return i>>1; + return (l + left_adj + right_adj)/2; } static char hexd_buff[4096]; diff --git a/tests/Makefile.am b/tests/Makefile.am index b60f675..fbefab1 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -4,7 +4,7 @@ check_PROGRAMS = timer/timer_test sms/sms_test ussd/ussd_test \ smscb/smscb_test bits/bitrev_test a5/a5_test \ conv/conv_test auth/milenage_test lapd/lapd_test \ gsm0808/gsm0808_test gsm0408/gsm0408_test \ - gb/bssgp_fc_test logging/logging_test + gb/bssgp_fc_test hex/hex_test logging/logging_test if ENABLE_MSGFILE check_PROGRAMS += msgfile/msgfile_test endif @@ -21,6 +21,9 @@ bits_bitrev_test_LDADD = $(top_builddir)/src/libosmocore.la conv_conv_test_SOURCES = conv/conv_test.c conv_conv_test_LDADD = $(top_builddir)/src/libosmocore.la +hex_hex_test_SOURCES = hex/hex_test.c +hex_hex_test_LDADD = $(top_builddir)/src/libosmocore.la + gsm0808_gsm0808_test_SOURCES = gsm0808/gsm0808_test.c gsm0808_gsm0808_test_LDADD = $(top_builddir)/src/libosmocore.la $(top_builddir)/src/gsm/libosmogsm.la @@ -77,7 +80,7 @@ EXTRA_DIST = testsuite.at $(srcdir)/package.m4 $(TESTSUITE) \ gsm0808/gsm0808_test.ok gb/bssgp_fc_tests.err \ gb/bssgp_fc_tests.ok gb/bssgp_fc_tests.sh \ msgfile/msgfile_test.ok msgfile/msgconfig.cfg \ - logging/logging_test.ok logging/logging_test.err + logging/logging_test.ok hex/hex_test.ok logging/logging_test.err DISTCLEANFILES = atconfig diff --git a/tests/hex/hex_test.c b/tests/hex/hex_test.c new file mode 100644 index 0000000..5c060c4 --- /dev/null +++ b/tests/hex/hex_test.c @@ -0,0 +1,57 @@ +#include +#include +#include + +#include + +/* ------------------------------------------------------------------------ */ +/* Test vectors */ +/* ------------------------------------------------------------------------ */ + +char * long_rand_x = "0xa63c3b465eb79b3e06ae66eb816eace"; +char * long_rand = "39ea2e536e6a2c0d3e59110df20e4bf"; +char * small_even_x = "0xDEAD"; +char * small_even = "FACE"; +char * small_odd_x = "0xFFACE"; +char * small_odd = "bee"; + +/* ------------------------------------------------------------------------ */ +/* Main */ +/* ------------------------------------------------------------------------ */ + +inline void _single_test(char * vec, size_t len, uint8_t * test, enum hex_len_policy pol) +{ + int r = osmo_hexparse_ext(vec, test, len, pol); + printf(" parsed %s (%u): %d", vec, len, r); + if (-1 != r) printf(", dumped: %s, check %x,%d,%d\n", osmo_hexdump_nospc(test, len), test[len - 1], test[len], test[len + 1]); + else printf("\n"); +} + +inline void _run_tests(char * vec, size_t len) +{ + uint8_t test[len + 4]; + int r; + + for (r = 0; r < len + 4; r++) test[r] = r; + + printf("NONE"); + _single_test(vec, len, test, HEX_ODD_NONE); + + printf("LEFT"); + _single_test(vec, len, test, HEX_ODD_LEFT); + + printf("RIGHT"); + _single_test(vec, len, test, HEX_ODD_RIGHT); +} + +int main(int argc, char **argv) +{ + _run_tests(long_rand_x, 16); + _run_tests(long_rand, 16); + _run_tests(small_even_x, 2); + _run_tests(small_even, 2); + _run_tests(small_odd_x, 3); + _run_tests(small_odd, 2); + + return 0; +} diff --git a/tests/hex/hex_test.ok b/tests/hex/hex_test.ok new file mode 100644 index 0000000..44e89d2 --- /dev/null +++ b/tests/hex/hex_test.ok @@ -0,0 +1,18 @@ +NONE parsed 0xa63c3b465eb79b3e06ae66eb816eace (16): -1 +LEFT parsed 0xa63c3b465eb79b3e06ae66eb816eace (16): 16, dumped: 0a63c3b465eb79b3e06ae66eb816eace, check ce,16,17 +RIGHT parsed 0xa63c3b465eb79b3e06ae66eb816eace (16): 16, dumped: a63c3b465eb79b3e06ae66eb816eace0, check e0,16,17 +NONE parsed 39ea2e536e6a2c0d3e59110df20e4bf (16): -1 +LEFT parsed 39ea2e536e6a2c0d3e59110df20e4bf (16): 16, dumped: 039ea2e536e6a2c0d3e59110df20e4bf, check bf,16,17 +RIGHT parsed 39ea2e536e6a2c0d3e59110df20e4bf (16): 16, dumped: 39ea2e536e6a2c0d3e59110df20e4bf0, check f0,16,17 +NONE parsed 0xDEAD (2): 2, dumped: dead, check ad,2,3 +LEFT parsed 0xDEAD (2): 2, dumped: dead, check ad,2,3 +RIGHT parsed 0xDEAD (2): 2, dumped: dead, check ad,2,3 +NONE parsed FACE (2): 2, dumped: face, check ce,2,3 +LEFT parsed FACE (2): 2, dumped: face, check ce,2,3 +RIGHT parsed FACE (2): 2, dumped: face, check ce,2,3 +NONE parsed 0xFFACE (3): -1 +LEFT parsed 0xFFACE (3): 3, dumped: 0fface, check ce,3,4 +RIGHT parsed 0xFFACE (3): 3, dumped: fface0, check e0,3,4 +NONE parsed bee (2): -1 +LEFT parsed bee (2): 2, dumped: 0bee, check ee,2,3 +RIGHT parsed bee (2): 2, dumped: bee0, check e0,2,3 diff --git a/tests/testsuite.at b/tests/testsuite.at index 1cfae03..cfbcf78 100644 --- a/tests/testsuite.at +++ b/tests/testsuite.at @@ -28,6 +28,12 @@ cat $abs_srcdir/conv/conv_test.ok > expout AT_CHECK([$abs_top_builddir/tests/conv/conv_test], [], [expout]) AT_CLEANUP +AT_SETUP([hex]) +AT_KEYWORDS([hex]) +cat $abs_srcdir/hex/hex_test.ok > expout +AT_CHECK([$abs_top_builddir/tests/hex/hex_test], [], [expout]) +AT_CLEANUP + if ENABLE_MSGFILE AT_SETUP([msgfile]) AT_KEYWORDS([msgfile]) -- 1.7.10.4 --------------080702070805090503080203-- From andreas at eversberg.eu Mon Jan 14 19:16:40 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Mon, 14 Jan 2013 20:16:40 +0100 Subject: drawing of state machines Message-ID: <50F45998.6060704@eversberg.eu> hi, while reading about SMS state machines, i found some drawings that are not in the specs, but quite useful to understand some processes. they are: - MM idle process (MS side) - additions to CC (MS side) - SMC process (MS and network side) see http://home.eversberg.eu/gsm they might be useful and so i think they should be placed in the wiki. i would suggest to put them to OsmocomBB wiki in the "GSM Documentation" section. but i don't know if it is ok to publish the CC process, because it contains a scan of the original spec. any suggestions? regards, andreas From alexander.huemer at xx.vu Mon Jan 14 22:42:12 2013 From: alexander.huemer at xx.vu (Alexander Huemer) Date: Mon, 14 Jan 2013 23:42:12 +0100 Subject: drawing of state machines In-Reply-To: <50F45998.6060704@eversberg.eu> References: <50F45998.6060704@eversberg.eu> Message-ID: <20130114224212.GA30405@de.xx.vu> Hi Andreas, On Mon, Jan 14, 2013 at 08:16:40PM +0100, Andreas Eversberg wrote: > while reading about SMS state machines, i found some drawings that > are not in the specs, but quite useful to understand some processes. > they are: > > - MM idle process (MS side) > - additions to CC (MS side) > - SMC process (MS and network side) > > see http://home.eversberg.eu/gsm > > they might be useful and so i think they should be placed in the > wiki. i would suggest to put them to OsmocomBB wiki in the "GSM > Documentation" section. but i don't know if it is ok to publish the > CC process, because it contains a scan of the original spec. I have just redone cc-ms.pdf in dot[1]. - Your notes are missing, because parts are difficult to read. Please add them yourself. - The original documentation is very inconsistent in the usage of '.' and '-'. I have done it as close to the original as possible. One scheme should be selected and the .dot file adjusted. The other graphs should probably be redone in dot too. Kind regards, -Alexander Huemer [1] http://xx.vu/~ahuemer/volatile/2013-01-14-rUI4rlcpbh4/cc-ms.dot From andreas at eversberg.eu Tue Jan 15 08:18:08 2013 From: andreas at eversberg.eu (jolly) Date: Tue, 15 Jan 2013 09:18:08 +0100 Subject: drawing of state machines In-Reply-To: <20130114224212.GA30405@de.xx.vu> References: <50F45998.6060704@eversberg.eu> <20130114224212.GA30405@de.xx.vu> Message-ID: <50F510C0.1050102@eversberg.eu> Alexander Huemer wrote: > I have just redone cc-ms.pdf in dot[1]. hi alex, i would like to open/edit it, but i don't know of a dot editor. i tried inkscape, but it does not support dot files. any idea what to use? regards, andreas From alexander.huemer at xx.vu Tue Jan 15 09:43:15 2013 From: alexander.huemer at xx.vu (Alexander Huemer) Date: Tue, 15 Jan 2013 10:43:15 +0100 Subject: drawing of state machines In-Reply-To: <50F510C0.1050102@eversberg.eu> References: <50F45998.6060704@eversberg.eu> <20130114224212.GA30405@de.xx.vu> <50F510C0.1050102@eversberg.eu> Message-ID: <20130115094315.GA22001@de.xx.vu> On Tue, Jan 15, 2013 at 09:18:08AM +0100, jolly wrote: > Alexander Huemer wrote: > > I have just redone cc-ms.pdf in dot[1]. > i would like to open/edit it, but i don't know of a dot editor. i > tried > inkscape, but it does not support dot files. any idea what to use? vim/emacs, choose your poison ;) It's just a plain text file that you edit manually, it's nothing fancy. Please see [1,2]. After editing, do $ dot -Tpng cc-ms.dot -o cc-ms.png Dot is part of graphviz, here[3] is a preview of the result. Maybe there is a way to give dot some hints how to arrange the graph so that is looks a bit more like the original. Kind regards, -Alexander Huemer [1] http://www.graphviz.org/pdf/dotguide.pdf [2] http://www.graphviz.org/Documentation.php [3] http://xx.vu/~ahuemer/volatile/2013-01-14-84kvRGlK4yU/cc-ms.png From andreas at eversberg.eu Fri Jan 18 11:47:21 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Fri, 18 Jan 2013 12:47:21 +0100 Subject: drawing of state machines In-Reply-To: <20130115094315.GA22001@de.xx.vu> References: <50F45998.6060704@eversberg.eu> <20130114224212.GA30405@de.xx.vu> <50F510C0.1050102@eversberg.eu> <20130115094315.GA22001@de.xx.vu> Message-ID: <50F93649.4010508@eversberg.eu> hi, just did some work on cc-ms.dot file. it is not fully reviewed. i would like to know how to place some boxes to specific locations, rather than letting 'dot' place that automatically. andreas -------------- next part -------------- A non-text attachment was scrubbed... Name: cc-ms.dot Type: application/msword-template Size: 5013 bytes Desc: not available URL: From alexander.huemer at xx.vu Fri Jan 18 12:49:19 2013 From: alexander.huemer at xx.vu (Alexander Huemer) Date: Fri, 18 Jan 2013 13:49:19 +0100 Subject: drawing of state machines In-Reply-To: <50F93649.4010508@eversberg.eu> References: <50F45998.6060704@eversberg.eu> <20130114224212.GA30405@de.xx.vu> <50F510C0.1050102@eversberg.eu> <20130115094315.GA22001@de.xx.vu> <50F93649.4010508@eversberg.eu> Message-ID: <20130118124919.GA1463@de.xx.vu> On Fri, Jan 18, 2013 at 12:47:21PM +0100, Andreas Eversberg wrote: > just did some work on cc-ms.dot file. it is not fully reviewed. i > would like to know how to place some boxes to specific locations, > rather than letting 'dot' place that automatically. I only have basic dot knowledge, but from what I know this not easily possible, which is simply a result of how dot works. If you really want to affect the layout, try to render the graph in e.g. SVG and modify it in inkscape or so. The rendering engine of graphviz also accepts parameters which modify its behavior. I know of nodesep and ranksep. Maybe there are others too. Kind regards, -Alexander Huemer From laforge at gnumonks.org Fri Jan 18 14:34:06 2013 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 18 Jan 2013 15:34:06 +0100 Subject: drawing of state machines In-Reply-To: <50F93649.4010508@eversberg.eu> References: <50F45998.6060704@eversberg.eu> <20130114224212.GA30405@de.xx.vu> <50F510C0.1050102@eversberg.eu> <20130115094315.GA22001@de.xx.vu> <50F93649.4010508@eversberg.eu> Message-ID: <20130118143406.GA8375@prithivi.gnumonks.org> Hi Andreas and others, please note that the OpenBSC and OsmocomBB trac wiki both have the dot plugin installed, i.e. you can copy+paste dot syntax into the wiki and it will render a nice graph. I've used this to draw the graphs at http://bb.osmocom.org/trac/wiki/Software/Overview Regards, Harald On Fri, Jan 18, 2013 at 12:47:21PM +0100, Andreas Eversberg wrote: > hi, > > just did some work on cc-ms.dot file. it is not fully reviewed. i > would like to know how to place some boxes to specific locations, > rather than letting 'dot' place that automatically. > > andreas > -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From andreas at eversberg.eu Fri Jan 18 15:27:58 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Fri, 18 Jan 2013 16:27:58 +0100 Subject: drawing of state machines In-Reply-To: <20130118143406.GA8375@prithivi.gnumonks.org> References: <50F45998.6060704@eversberg.eu> <20130114224212.GA30405@de.xx.vu> <50F510C0.1050102@eversberg.eu> <20130115094315.GA22001@de.xx.vu> <50F93649.4010508@eversberg.eu> <20130118143406.GA8375@prithivi.gnumonks.org> Message-ID: <50F969FE.9050301@eversberg.eu> Harald Welte wrote: > please note that the OpenBSC and OsmocomBB trac wiki both have the dot > plugin installed, i.e. you can copy+paste dot syntax into the wiki and > it will render a nice graph. hi harald, i would like to do that, but the graph looks horrible, because i cannot place on or another boxes to a fixed place. without the graph would be hard to understand. regards, andreas From dario.lombardo.ml at gmail.com Fri Jan 18 16:21:00 2013 From: dario.lombardo.ml at gmail.com (Dario Lombardo) Date: Fri, 18 Jan 2013 17:21:00 +0100 Subject: drawing of state machines In-Reply-To: <50F969FE.9050301@eversberg.eu> References: <50F45998.6060704@eversberg.eu> <20130114224212.GA30405@de.xx.vu> <50F510C0.1050102@eversberg.eu> <20130115094315.GA22001@de.xx.vu> <50F93649.4010508@eversberg.eu> <20130118143406.GA8375@prithivi.gnumonks.org> <50F969FE.9050301@eversberg.eu> Message-ID: Hi Andreas I've rendered your dot file with my dot program. The attached pdf doesn't look like horrible. A have a bit of knowledge of dot: if you point which part of the graph looks horrible, I can help you to improve it. ...for what dot allows... :) Dario. On Fri, Jan 18, 2013 at 4:27 PM, Andreas Eversberg wrote: > Harald Welte wrote: > >> please note that the OpenBSC and OsmocomBB trac wiki both have the dot >> plugin installed, i.e. you can copy+paste dot syntax into the wiki and >> it will render a nice graph. >> > hi harald, > > i would like to do that, but the graph looks horrible, because i cannot > place on or another boxes to a fixed place. without the graph would be hard > to understand. > > regards, > > andreas > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cc-ms.pdf Type: application/pdf Size: 18402 bytes Desc: not available URL: From andreas at eversberg.eu Fri Jan 18 13:36:20 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Fri, 18 Jan 2013 14:36:20 +0100 Subject: tranceiver support for osmo-bts Message-ID: <50F94FD4.5010702@eversberg.eu> hi, i would like to start implementing the trx manager interface support to osmo-bts. before going to work, i'm writing this mail, because i like to read some pros and cons for my approach. as already stated, thomas a. cooper already implemented an interface between sysmo-bts's dsp device and trx manager interface by using code from openbts, running in an own process [1]. i would like to follow a different approach by writing a scheduler and adding the udp interface for the trx(s). some benefits are in my oppinion: - not having an extra process running with additional latency and overhead - smaller code, because only a small multiframe scheduler + udp interface for the trx is required (coding scheme and forward error correction code can be used from libosmocore.) - no running after dsp's api changes, (caused by newer firmware of sysmobts) - trx specific features and limitations can be considered. (vty options for setting special features, limitations can affect oml ack/nack responses to be considered by bsc) - no use of multithreading, use of talloc. the code is easier to debug and so becomes more stable. - easy to add initial support for BCCH(+SDCCH4), SDCCH8, TCH/F, TCH/H, PDCH (gprs) for a whide range of applications. comments are welcome. regards, andreas [1] http://scholar.lib.vt.edu/theses/available/etd-05082012-141540/unrestricted/Cooper_TA_T_2012.pdf From 246tnt at gmail.com Fri Jan 18 15:47:26 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 18 Jan 2013 16:47:26 +0100 Subject: tranceiver support for osmo-bts In-Reply-To: <50F94FD4.5010702@eversberg.eu> References: <50F94FD4.5010702@eversberg.eu> Message-ID: I would suggest something like http://i.imgur.com/F20Q7.png Where basically you have: - The osmo-bts core and all common BTS logic / A-bis interface and such - It talks to the lower L1 layer via the primitives defined in the spec for creation of channels and stuff. AFAIK it's "pretty" similar to the current DSP interface but some specific stuff might need to be made generic. Then you have two possible L1 implementation speaking thos primitives - the sysmobts one which basically includes all the specific stuff to convert the 'generic' primitves into the specific call to the DSP. - The TRX one which includes scheduler / channel coding internally and would use the UDP protocol used by OpenBTS This impl can itself offer a generic interface internally so that the OpenBTS UDP protocol is only one of the possible user of the scheduler / channel coding ... Cheers, Sylvain From andreas at eversberg.eu Fri Jan 18 17:52:21 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Fri, 18 Jan 2013 18:52:21 +0100 Subject: tranceiver support for osmo-bts In-Reply-To: References: <50F94FD4.5010702@eversberg.eu> Message-ID: <50F98BD5.3000706@eversberg.eu> Sylvain Munaut wrote: > - the sysmobts one which basically includes all the specific stuff > to convert the 'generic' primitves into the specific call to the DSP. hi sylvain, your mail inspired me, so i looked deeper at the l1_if.c of sysmobts code. there is one major function (that calls several other functions): l1if_handle_ind(). it handles data (ph-data-ind, ph-rach-ind) received from dsp and triggers (ph-readytosend-ind) generation and transmission of data (ph-data-request) sent to dsp. the primitives have a layer-1 header that is specific for the dsp of sysmobts. since the coding of data between l1 and the bts code is not defined in the gsm specs, i think this header is something that sould be used for a split between common and l1 specific part. i would suggest to move the handling and generation of primitives from l1_if.c of sysmobts code to the common part of osmo-bts and only keep the handling of dsp itself. it would be nice to put femtobts/gsml1prim.h (currently a seperate git) to be part of the common include files. i don't know if the license of that header file allows that. another thing i need to deeper look at is the oml.c of sysmobts specific code. many stuff could be moved to common part of osmo-bts also, if the layer 1 primitives are used to split between common part and l1 specific part. the current osmo-bts-bb code would become (already became) obsolete and should be removed. regards, andreas From laforge at gnumonks.org Fri Jan 18 16:34:19 2013 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 18 Jan 2013 17:34:19 +0100 Subject: tranceiver support for osmo-bts In-Reply-To: <50F94FD4.5010702@eversberg.eu> References: <50F94FD4.5010702@eversberg.eu> Message-ID: <20130118163419.GE8375@prithivi.gnumonks.org> Hi Andreas, On Fri, Jan 18, 2013 at 02:36:20PM +0100, Andreas Eversberg wrote: > as already stated, thomas a. cooper already implemented an interface > between sysmo-bts's dsp device and trx manager interface by using > code from openbts, running in an own process [1]. i would like to > follow a different approach by writing a scheduler and adding the > udp interface for the trx(s). some benefits are in my oppinion: generally I'm not particular in favor or against any specific implementation. The different approaches all have their advantages and disadvantages. Just one comment: > - not having an extra process running with additional latency and overhead agreed, though on any reasonable x86 machine this is not a problem. It is only a problem on something as small as the ARM926 of the symsoBTS, but then there is no point of running this on the sysmoBTS ;) > - no running after dsp's api changes, (caused by newer firmware of sysmobts) While there have been a number of changes over the last year, the interface is not expected to change anymore at this point. Also, most of the changes in the past were related to the board-specific "femtobts" primitives and not to the actual layer1 API. So at least this should not be an argument. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From 246tnt at gmail.com Fri Jan 18 17:55:30 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 18 Jan 2013 18:55:30 +0100 Subject: tranceiver support for osmo-bts In-Reply-To: <20130118163419.GE8375@prithivi.gnumonks.org> References: <50F94FD4.5010702@eversberg.eu> <20130118163419.GE8375@prithivi.gnumonks.org> Message-ID: Hi, > but then there is no point of running this on the sysmoBTS ;) Challenge accepted ! :) You could use phones as secondary hopping TRXs :p Cheers, Sylvain From akibsayyed at gmail.com Fri Jan 18 16:50:49 2013 From: akibsayyed at gmail.com (Akib Sayyed) Date: Fri, 18 Jan 2013 22:20:49 +0530 Subject: Filter Modification Message-ID: Dear List I tried to modify filter of osmocom c118 but i found that its not getting signals. loosing all signalls and showing all on 115dbm to 120dbm. what could have gone wrong ?? -- Akib Sayyed Matrix-Shell akibsayyed at gmail.com akibsayyed at matrixshell.com Mob:- +91-966-514-2243 -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Fri Jan 18 17:59:18 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 18 Jan 2013 18:59:18 +0100 Subject: Filter Modification In-Reply-To: References: Message-ID: > loosing all signalls and showing all on 115dbm to 120dbm. > what could have gone wrong ?? ... Everything ... A short, a mis-connection, an ESD discharge, bad component, ... pretty much everything could potentially fail and will cause to loose reception all together ... From edachleger at yahoo.com Sat Jan 19 11:39:06 2013 From: edachleger at yahoo.com (Erich Dachleger) Date: Sat, 19 Jan 2013 11:39:06 +0000 (GMT) Subject: sylvain/testing: apps/trx/trx.c: inttypes.h:No such file or directory Message-ID: <1358595546.22112.YahooMailNeo@web171202.mail.ir2.yahoo.com> Hi list, Yesterday when I tried to to make a new build of sylvain/testing? I encountered following errors when running make(and also when running make HOST_layer23_CONFARGS=--enable-transceiver): -------------------------------------- make -C target/firmware CROSS_COMPILE=arm-elf- make[1]: Entering directory `/root/osmocom-bb/src/target/firmware' apps/trx/trx.c:22:22: inttypes.h: No such file or directory make[1]: Leaving directory `/root/osmocom-bb/src/target/firmware' make[1]: Entering directory `/root/osmocom-bb/src/target/firmware' apps/trx/trx.c:22:22: inttypes.h: No such file or directory make[1]: *** No rule to make target `apps/trx/trx.p', needed by `all'.? Stop. make[1]: Leaving directory `/root/osmocom-bb/src/target/firmware' make: *** [firmware] Error 2 ------------------------------------------- Master branch builds fine on backtrack 5 r2? and so did also Sylvain/testing earlier. Searching mailing-list gives? some info that removing inttypes.h can be done as that "is taken care of by upstrean libosmocore".However I have read that inntypes.h should exist. I tested and removed inttypes.h in trx/trx.c. Recompiling gives an error message about parse error before debug-message PRIu32 on line 69 in trx/trx.c. Commenting out that line makes it build, but as info obtained earlier I now guess I have also removed some key-functionality and my approach is wrong? Further searching gave some unclear/vague(mostly for other situations) hints that the line? #include could be replaced by: #ifdef HAVE_STDINT_H #include #else #include #endif I tested replacing #include ? by the abovein trx.c also but it didn't work. Any ideas or hints what migh be wrong? Enclosed is the full build-error-log from running without making any changes to inttypes.h. Regards erich -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: build-log-sylv-testing.txt URL: From 246tnt at gmail.com Sat Jan 19 12:28:46 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sat, 19 Jan 2013 13:28:46 +0100 Subject: sylvain/testing: apps/trx/trx.c: inttypes.h:No such file or directory In-Reply-To: <1358595546.22112.YahooMailNeo@web171202.mail.ir2.yahoo.com> References: <1358595546.22112.YahooMailNeo@web171202.mail.ir2.yahoo.com> Message-ID: Hi, > Master branch builds fine on backtrack 5 r2 and so did also Sylvain/testing > earlier. Yes, the file with that include is newly added. > I tested and removed inttypes.h in trx/trx.c. Recompiling gives an error > message about parse error before debug-message PRIu32 on line 69 in > trx/trx.c. PRIu32 is AFAIK the proper way of printing a uint32_t without generating a warning and without making assumptions about the platform. inttypes.h is a standard C99 header file, if you distribution doesn't have it, I would suggest reporting the bug to them. > I tested replacing #include by the abovein trx.c also but it > didn't work. It wont's stdint.h is a subset of inttype.h so you could replace stdint.h by inttype.h but not the other way around. Cheers, Sylvain From 246tnt at gmail.com Sat Jan 19 13:18:15 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sat, 19 Jan 2013 14:18:15 +0100 Subject: sylvain/testing: apps/trx/trx.c: inttypes.h:No such file or directory In-Reply-To: References: <1358595546.22112.YahooMailNeo@web171202.mail.ir2.yahoo.com> Message-ID: >> I tested and removed inttypes.h in trx/trx.c. Recompiling gives an error >> message about parse error before debug-message PRIu32 on line 69 in >> trx/trx.c. > > PRIu32 is AFAIK the proper way of printing a uint32_t without > generating a warning and without making assumptions about the > platform. > > inttypes.h is a standard C99 header file, if you distribution doesn't > have it, I would suggest reporting the bug to them. As was pointed out to me, it's the trx.c file from the firmware and not the one from the host app, so the bug should go to the cross toolchain provider I guess. That printf is definitely not a "key-functionality" so you can just remote it, however, I would expect that while fixing other GCC warnings, the use of inttypes.h will rise in the future, so I'd suggest you get a good toolchain. See http://bb.osmocom.org/trac/wiki/GnuArmToolchain for how to build one. Cheers, Sylvain From edachleger at yahoo.com Mon Jan 21 12:32:27 2013 From: edachleger at yahoo.com (Erich Dachleger) Date: Mon, 21 Jan 2013 12:32:27 +0000 (GMT) Subject: Vedr: sylvain/testing: apps/trx/trx.c: inttypes.h:No such file or directory In-Reply-To: References: <1358595546.22112.YahooMailNeo@web171202.mail.ir2.yahoo.com> Message-ID: <1358771547.71119.YahooMailNeo@web171201.mail.ir2.yahoo.com> Hi sylvain and thanks for your replies. As you pointed out the resolution to the problem was to build new toolchain according to instructions in wiki, which does build( in backtrack r2 )both master and testing branch without complaining about inttypes.h regards erich ________________________________ Fra: Sylvain Munaut <246tnt at gmail.com> Til: Erich Dachleger Kopi: "baseband-devel at lists.osmocom.org" Sendt: L?rdag, 19. januar 2013 14.18 Emne: Re: sylvain/testing: apps/trx/trx.c: inttypes.h:No such file or directory >> I tested and removed inttypes.h in trx/trx.c. Recompiling gives an error >> message about parse error before debug-message PRIu32 on line 69 in >> trx/trx.c. > > PRIu32 is AFAIK the proper way of printing a uint32_t without > generating a warning and without making assumptions about the > platform. > > inttypes.h is a standard C99 header file, if you distribution doesn't > have it, I would suggest reporting the bug to them. As was pointed out to me, it's the trx.c file from the firmware and not the one from the host app, so the bug should go to the cross toolchain provider I guess. That printf is definitely not a "key-functionality" so you can just remote it, however, I would expect that while fixing other GCC warnings, the use of inttypes.h will rise in the future, so I'd suggest you get a good toolchain. See http://bb.osmocom.org/trac/wiki/GnuArmToolchain for how to build one. Cheers, ? ? Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Mon Jan 21 12:50:38 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Mon, 21 Jan 2013 13:50:38 +0100 Subject: sylvain/testing: apps/trx/trx.c: inttypes.h:No such file or directory In-Reply-To: <1358771547.71119.YahooMailNeo@web171201.mail.ir2.yahoo.com> References: <1358595546.22112.YahooMailNeo@web171202.mail.ir2.yahoo.com> <1358771547.71119.YahooMailNeo@web171201.mail.ir2.yahoo.com> Message-ID: Hi, > As you pointed out the resolution to the problem was to build new toolchain > according to instructions in wiki, > which does build( in backtrack r2 )both master and testing branch without > complaining about inttypes.h Ok, good to know. In the mean time, I also removed links from the wiki to outdated toolchains. Cheers, Sylvain From klaus.mailinglists at pernau.at Sun Jan 20 10:04:40 2013 From: klaus.mailinglists at pernau.at (Klaus Darilion) Date: Sun, 20 Jan 2013 11:04:40 +0100 Subject: slow osmocom website Message-ID: <50FBC138.5040605@pernau.at> Hi! The last days I experienced the website is sometimes very slow. Requests takes up to 30 seconds to be answered by the server. http://bb.osmocom.org/ is fast, but http://bb.osmocom.org/trac/ is slow. Thus I suspect a Trac or database problem. regards Klaus From holger at freyther.de Sun Jan 20 10:48:55 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sun, 20 Jan 2013 11:48:55 +0100 Subject: slow osmocom website In-Reply-To: <50FBC138.5040605@pernau.at> References: <50FBC138.5040605@pernau.at> Message-ID: <20130120104855.GE8764@xiaoyu.lan> On Sun, Jan 20, 2013 at 11:04:40AM +0100, Klaus Darilion wrote: Hi, > The last days I experienced the website is sometimes very slow. > Requests takes up to 30 seconds to be answered by the server. > > http://bb.osmocom.org/ is fast, but http://bb.osmocom.org/trac/ is > slow. Thus I suspect a Trac or database problem. this is due multiple web spiders (Bing, Baidu, ...) hitting the trac and cgit. Patches for the robots.txt are welcome. holger From 246tnt at gmail.com Sun Jan 20 11:15:38 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 20 Jan 2013 12:15:38 +0100 Subject: slow osmocom website In-Reply-To: <20130120104855.GE8764@xiaoyu.lan> References: <50FBC138.5040605@pernau.at> <20130120104855.GE8764@xiaoyu.lan> Message-ID: Hi, > this is due multiple web spiders (Bing, Baidu, ...) hitting the trac > and cgit. Patches for the robots.txt are welcome. Put this in git.osmocom.org/robots.txt (currently it returns 403) --- User-agent: * Disallow: / --- The git should just not be crawled at all IMHO. Cheers, Sylvain From steve at steve-m.de Sun Jan 20 12:13:57 2013 From: steve at steve-m.de (Steve Markgraf) Date: Sun, 20 Jan 2013 13:13:57 +0100 Subject: slow osmocom website In-Reply-To: <20130120104855.GE8764@xiaoyu.lan> References: <50FBC138.5040605@pernau.at> <20130120104855.GE8764@xiaoyu.lan> Message-ID: <50FBDF85.9050700@steve-m.de> Hi, On 20.01.2013 11:48, Holger Hans Peter Freyther wrote: > this is due multiple web spiders (Bing, Baidu, ...) hitting the trac > and cgit. Patches for the robots.txt are welcome. I guess setting up Varnish would make more sense than blocking spiders, after all we want the pages to be found by search engines... Regards, Steve From 246tnt at gmail.com Sun Jan 20 13:34:15 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 20 Jan 2013 14:34:15 +0100 Subject: slow osmocom website In-Reply-To: <50FBDF85.9050700@steve-m.de> References: <50FBC138.5040605@pernau.at> <20130120104855.GE8764@xiaoyu.lan> <50FBDF85.9050700@steve-m.de> Message-ID: > I guess setting up Varnish would make more sense than blocking spiders, > after all we want the pages to be found by search engines... Well I think the problem is mostly when they try to index pages that are very heavy to generate (like search or diff between revisions ...), not when they browse standard wiki pages. Cheers, Sylvain From peter at stuge.se Mon Jan 21 04:01:27 2013 From: peter at stuge.se (Peter Stuge) Date: Mon, 21 Jan 2013 05:01:27 +0100 Subject: slow osmocom website In-Reply-To: <20130120104855.GE8764@xiaoyu.lan> References: <50FBC138.5040605@pernau.at> <20130120104855.GE8764@xiaoyu.lan> Message-ID: <20130121040127.5623.qmail@stuge.se> Holger Hans Peter Freyther wrote: > Patches for the robots.txt are welcome. If not already done then I recommend moving all Trac databases off the toy SQLite database to MariaDB, Postgres or such. Getting rid of SQLite has significant impact on popular Trac instances, and makes running the database on a separate machine really easy, which further distributes the load. //Peter From laforge at gnumonks.org Mon Jan 21 10:06:19 2013 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 21 Jan 2013 11:06:19 +0100 Subject: slow osmocom website In-Reply-To: <20130121040127.5623.qmail@stuge.se> References: <50FBC138.5040605@pernau.at> <20130120104855.GE8764@xiaoyu.lan> <20130121040127.5623.qmail@stuge.se> Message-ID: <20130121100619.GR13197@prithivi.gnumonks.org> Hi Peter, On Mon, Jan 21, 2013 at 05:01:27AM +0100, Peter Stuge wrote: > Holger Hans Peter Freyther wrote: > > Patches for the robots.txt are welcome. > > If not already done then I recommend moving all Trac databases off > the toy SQLite database to MariaDB, Postgres or such. > > Getting rid of SQLite has significant impact on popular Trac > instances, and makes running the database on a separate machine > really easy, which further distributes the load. We can do that, but I think the main issue is that the machine is just overloaded with too many VMs, so high load on one of the VMs will have a significant impact on others. Doing an upgrade / re-organization is on my todo list, but it is a very low priority item, as the slow web site is mostly a problem of convenience, and not an urgent issue at this point. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From peter at stuge.se Tue Jan 22 12:56:50 2013 From: peter at stuge.se (Peter Stuge) Date: Tue, 22 Jan 2013 13:56:50 +0100 Subject: slow osmocom website In-Reply-To: <20130121100619.GR13197@prithivi.gnumonks.org> References: <50FBC138.5040605@pernau.at> <20130120104855.GE8764@xiaoyu.lan> <20130121040127.5623.qmail@stuge.se> <20130121100619.GR13197@prithivi.gnumonks.org> Message-ID: <20130122125650.31658.qmail@stuge.se> Harald Welte wrote: > the slow web site is mostly a problem of convenience, > and not an urgent issue at this point. It *is* the public view of the osmocom projects. If the web site looks down, the projects look down. (Even though it's not the case.) //Peter From alexander.chemeris at gmail.com Tue Jan 22 16:02:10 2013 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Tue, 22 Jan 2013 20:02:10 +0400 Subject: slow osmocom website In-Reply-To: <20130122125650.31658.qmail@stuge.se> References: <50FBC138.5040605@pernau.at> <20130120104855.GE8764@xiaoyu.lan> <20130121040127.5623.qmail@stuge.se> <20130121100619.GR13197@prithivi.gnumonks.org> <20130122125650.31658.qmail@stuge.se> Message-ID: On Tue, Jan 22, 2013 at 4:56 PM, Peter Stuge wrote: > Harald Welte wrote: >> the slow web site is mostly a problem of convenience, >> and not an urgent issue at this point. > > It *is* the public view of the osmocom projects. If the web site > looks down, the projects look down. (Even though it's not the case.) I also agree that web-site is an important part of the project. Yeah, it's not critical, and one or two outages are fine, but it quickly becomes annoying if a web-site is slow/unavailable on a regular basis. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From steve at steve-m.de Tue Jan 22 16:33:06 2013 From: steve at steve-m.de (Steve Markgraf) Date: Tue, 22 Jan 2013 17:33:06 +0100 Subject: slow osmocom website In-Reply-To: <20130122125650.31658.qmail@stuge.se> References: <50FBC138.5040605@pernau.at> <20130120104855.GE8764@xiaoyu.lan> <20130121040127.5623.qmail@stuge.se> <20130121100619.GR13197@prithivi.gnumonks.org> <20130122125650.31658.qmail@stuge.se> Message-ID: <50FEBF42.4040308@steve-m.de> Hi, On 22.01.2013 13:56, Peter Stuge wrote: > It *is* the public view of the osmocom projects. If the web site > looks down, the projects look down. (Even though it's not the case.) I agree, especially since sometimes the site doesn't load at all. Browsing any of the osmocom-tracs at the moment feels like browsing via GPRS. Regards, Steve From osmocom at ngolde.de Tue Jan 22 14:39:04 2013 From: osmocom at ngolde.de (Nico Golde) Date: Tue, 22 Jan 2013 15:39:04 +0100 Subject: slow osmocom website In-Reply-To: <20130121100619.GR13197@prithivi.gnumonks.org> References: <50FBC138.5040605@pernau.at> <20130120104855.GE8764@xiaoyu.lan> <20130121040127.5623.qmail@stuge.se> <20130121100619.GR13197@prithivi.gnumonks.org> Message-ID: <20130122143904.GA5722@nybble.binarybase.org> Hi, * Harald Welte [2013-01-21 21:45]: > On Mon, Jan 21, 2013 at 05:01:27AM +0100, Peter Stuge wrote: > > Holger Hans Peter Freyther wrote: > > > Patches for the robots.txt are welcome. > > > > If not already done then I recommend moving all Trac databases off > > the toy SQLite database to MariaDB, Postgres or such. > > > > Getting rid of SQLite has significant impact on popular Trac > > instances, and makes running the database on a separate machine > > really easy, which further distributes the load. > > We can do that, but I think the main issue is that the machine is just > overloaded with too many VMs, so high load on one of the VMs will have a > significant impact on others. Doing an upgrade / re-organization is on > my todo list, but it is a very low priority item, as the slow web site > is mostly a problem of convenience, and not an urgent issue at this point. I agree with Peter here and think this is not only about convenience. As most of the active developers rarely use the website I would assume, this is mostly about our public face to the community and people who are interested in the project and I think this is important. I would argue that this isn't a super high priority item, but given the time these problems exist, I think we should start working on that. I'm also willing to give a helping hand here if needed. Cheers Nico From 246tnt at gmail.com Tue Jan 22 14:34:17 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Tue, 22 Jan 2013 15:34:17 +0100 Subject: slow osmocom website In-Reply-To: <20130120104855.GE8764@xiaoyu.lan> References: <50FBC138.5040605@pernau.at> <20130120104855.GE8764@xiaoyu.lan> Message-ID: Hi, > this is due multiple web spiders (Bing, Baidu, ...) hitting the trac > and cgit. Patches for the robots.txt are welcome. btw, could you send me the log file for such case ? I would guess they hit some high-resource pages that could be easily excluded by the robots.txt but that was just missed in the 'deny' ... Cheers, Sylvain From klaus.mailinglists at pernau.at Sun Jan 20 11:14:43 2013 From: klaus.mailinglists at pernau.at (Klaus Darilion) Date: Sun, 20 Jan 2013 12:14:43 +0100 Subject: Some beginner questions and comments Message-ID: <50FBD1A3.2080503@pernau.at> Hi! First I do not know if this is the proper mailing lists, as I am not a developer but a user. But I couldn't find a user list. So please advice if there is a better list. I started playing with Osmocom and my "brand new" C118 :-) and meanwhile I made my first open source GSM phone call. Following is my list of questions and suggestions I experienced so far: - Build System: since the "Use the system wide libosmocore for host applications" commit it is required that libosmocore is built separately. But the documentation is still confusing. Thus I think it would be good to: - remove the libosmocore subtree git from osmocom-bb git - remove this line of text from http://bb.osmocom.org/trac/wiki/libosmocore: "When you download and build OsmocomBB, then libosmocore is automatically part of the package, no special action is required." - osmocom: some wiki pages refer to an "osmocom" application. Is there an osmocom binary? (I think most times it is a typo for osmocon) - I use Wireshark to capture the GSMTAP packets of "monitor". How do I find out in the Wireshark trace if a message is sent from the MS or is received by the MS? - I want to study the high layer messages (e.g. not cell selection but call setup, registering to the network) but I am lost in the debug flags: DCS:DNB:DPLMN:DRR:DMM:DSIM:DCC:DMNCC:DSS:DLSMS:DPAG:DSUM. Which ones are needed in my case? Is there somewhere a description of the flags? - Some tools (e.g. cell_log) give 'SAP' log messages, e.g: Failed to connect to '/tmp/osmocom_sap'. Failed during sap_open(), no SIM reader I suspect this is for communcation with SIM cards. How it is supposed to work? - Is this 'SAP' stuff only needed/useful for softSIMs? - Which application should create the /tmp/osmocom_sap socket? (osmocon only creates /tmp/osmocom_l2 and /tmp/osmocom_loader) - Would it be possible to remove the SIM card from my C118 and put it in an external SIM reader, and then let "mobile" use the SIM card in the external reader instead? Thanks Klaus PS: I'm willing to improve the documentation in the wiki with your answers ;-) From 246tnt at gmail.com Sun Jan 20 12:24:56 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 20 Jan 2013 13:24:56 +0100 Subject: Some beginner questions and comments In-Reply-To: <50FBD1A3.2080503@pernau.at> References: <50FBD1A3.2080503@pernau.at> Message-ID: Hi, > - remove the libosmocore subtree git from osmocom-bb git We can't do that. libosmocore subtree is still used to compile the embedded ARM version of libosmocore. > - remove this line of text from > http://bb.osmocom.org/trac/wiki/libosmocore: "When you download and build > OsmocomBB, then libosmocore is automatically part of the package, no special > action is required." Indeed. Feel free to edit it. > - osmocom: some wiki pages refer to an "osmocom" application. Is there an > osmocom binary? (I think most times it is a typo for osmocon) It's most likely a typo. > - I use Wireshark to capture the GSMTAP packets of "monitor". How do I find > out in the Wireshark trace if a message is sent from the MS or is received > by the MS? Look at the ARFCN field of GSMTAP Header. It should indicate uplink or downlink direction. > - I want to study the high layer messages (e.g. not cell selection but call > setup, registering to the network) but I am lost in the debug flags: > DCS:DNB:DPLMN:DRR:DMM:DSIM:DCC:DMNCC:DSS:DLSMS:DPAG:DSUM. Which ones are > needed in my case? Is there somewhere a description of the flags? You're probably better off with wireshark to view the messages. The debug category are explained in src/host/layer23/src/common/logging.c > - Some tools (e.g. cell_log) give 'SAP' log messages, e.g: > Failed to connect to '/tmp/osmocom_sap'. > Failed during sap_open(), no SIM reader > I suspect this is for communcation with SIM cards. How it is supposed to > work? > - Is this 'SAP' stuff only needed/useful for softSIMs? > - Which application should create the /tmp/osmocom_sap socket? (osmocon only > creates /tmp/osmocom_l2 and /tmp/osmocom_loader) SAP support in mainline is incomplete and unsupported currently. > - Would it be possible to remove the SIM card from my C118 and put it in an > external SIM reader, and then let "mobile" use the SIM card in the external > reader instead? No Cheers, Sylvain From peter at stuge.se Mon Jan 21 03:56:51 2013 From: peter at stuge.se (Peter Stuge) Date: Mon, 21 Jan 2013 04:56:51 +0100 Subject: Some beginner questions and comments In-Reply-To: References: <50FBD1A3.2080503@pernau.at> Message-ID: <20130121035651.4933.qmail@stuge.se> Sylvain Munaut wrote: > > - remove the libosmocore subtree git from osmocom-bb git > > We can't do that. libosmocore subtree is still used to compile the > embedded ARM version of libosmocore. I think we should change that, and instead require the ARM library to be installed into a prefix which is set when building osmocom-bb targets. A sane default could be to have the prefix next to the osmocom-bb source tree. //Peter From 246tnt at gmail.com Mon Jan 21 06:15:49 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Mon, 21 Jan 2013 07:15:49 +0100 Subject: Some beginner questions and comments In-Reply-To: <20130121035651.4933.qmail@stuge.se> References: <50FBD1A3.2080503@pernau.at> <20130121035651.4933.qmail@stuge.se> Message-ID: Hi, >> We can't do that. libosmocore subtree is still used to compile the >> embedded ARM version of libosmocore. > > I think we should change that, and instead require the ARM library > to be installed into a prefix which is set when building osmocom-bb > targets. A sane default could be to have the prefix next to the > osmocom-bb source tree. We don't have an OS on the ARM, no libraries, no BSP ... it's all a big static block, so we can't have an installed "ARM library" for it. So we could ask the user to have the sources somewhere, but the issue is that the ARM build is much more sensitive to libosmocore version than the host one. I don't really see the problem with having the libosmocore as subtree for ARM build. For the host, it would sometime mix the intree and installed versions during build and we also had to update it often, but the subset used in the ARM is pretty small and doesn't require much updates. Cheers, Sylvain From peter at stuge.se Mon Jan 21 08:00:32 2013 From: peter at stuge.se (Peter Stuge) Date: Mon, 21 Jan 2013 09:00:32 +0100 Subject: Some beginner questions and comments In-Reply-To: References: <50FBD1A3.2080503@pernau.at> <20130121035651.4933.qmail@stuge.se> Message-ID: <20130121080032.3150.qmail@stuge.se> Sylvain Munaut wrote: > >> We can't do that. libosmocore subtree is still used to compile the > >> embedded ARM version of libosmocore. > > > > I think we should change that, and instead require the ARM library > > to be installed into a prefix which is set when building osmocom-bb > > targets. A sane default could be to have the prefix next to the > > osmocom-bb source tree. > > We don't have an OS on the ARM, no libraries, no BSP ... it's all a > big static block, so we can't have an installed "ARM library" for it. Sure we can - even if it's just a single .a file. Linker search path has nothing to do with an OS, libraries can be used without an OS, and no BSP is needed. > So we could ask the user to have the sources somewhere, but the issue > is that the ARM build is much more sensitive to libosmocore version > than the host one. All the more reason to make the target library explicitly visible. > I don't really see the problem with having the libosmocore as subtree > for ARM build. For the host, it would sometime mix the intree and > installed versions during build Another good reason to clearly separate the two. //Peter From 246tnt at gmail.com Mon Jan 21 09:51:53 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Mon, 21 Jan 2013 10:51:53 +0100 Subject: Some beginner questions and comments In-Reply-To: <20130121080032.3150.qmail@stuge.se> References: <50FBD1A3.2080503@pernau.at> <20130121035651.4933.qmail@stuge.se> <20130121080032.3150.qmail@stuge.se> Message-ID: > Sure we can - even if it's just a single .a file. Linker search path > has nothing to do with an OS, libraries can be used without an OS, > and no BSP is needed. Yes ok, but it's really more of an hassle than an advantage, and then if you want to use the same toolchain to build different arm projects that need different libosmocore version, that's going to be fun ... All in all, I really fail to see how this is going to _HELP_ ... it's going to be a bunch of additional step that can be messed up and IMHO with _NO_ upsides at all. The host build was becoming a problem and that's why it was moved out. The target build has not caused issue so I don't see why we would change it and give it the opportunity to fail. Cheers, Sylvain From laforge at gnumonks.org Mon Jan 21 12:09:22 2013 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 21 Jan 2013 13:09:22 +0100 Subject: Some beginner questions and comments In-Reply-To: References: <50FBD1A3.2080503@pernau.at> <20130121035651.4933.qmail@stuge.se> <20130121080032.3150.qmail@stuge.se> Message-ID: <20130121120922.GW13197@prithivi.gnumonks.org> On Mon, Jan 21, 2013 at 10:51:53AM +0100, Sylvain Munaut wrote: > The host build was becoming a problem and that's why it was moved out. > The target build has not caused issue so I don't see why we would > change it and give it the opportunity to fail. btw, just for the record: the idea of the host build from inside osmocom-bb.git was to make sure that the header files and APIs on both sides would be identical, which was considered a helpful idea if more and more code is eventually moved from host into the target (which never happened so far). -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From niceguy108 at gmail.com Thu Jan 24 15:44:50 2013 From: niceguy108 at gmail.com (Bhaskar11) Date: Thu, 24 Jan 2013 21:14:50 +0530 Subject: Some beginner questions and comments In-Reply-To: <20130121120922.GW13197@prithivi.gnumonks.org> References: <50FBD1A3.2080503@pernau.at> <20130121035651.4933.qmail@stuge.se> <20130121080032.3150.qmail@stuge.se> <20130121120922.GW13197@prithivi.gnumonks.org> Message-ID: Should we consider separating *only* the shared header definitions and APIs into a separate "shared" folder which would be accessed by the ARM compiler and host compilers from *all* Osmocom related projects? I've been porting the code to Windows and can see the benefits of clear separation of code. B. On Mon, Jan 21, 2013 at 5:39 PM, Harald Welte wrote: > On Mon, Jan 21, 2013 at 10:51:53AM +0100, Sylvain Munaut wrote: > > The host build was becoming a problem and that's why it was moved out. > > The target build has not caused issue so I don't see why we would > > change it and give it the opportunity to fail. > > btw, just for the record: the idea of the host build from inside > osmocom-bb.git was to make sure that the header files and APIs on both > sides would be identical, which was considered a helpful idea if more > and more code is eventually moved from host into the target (which never > happened so far). > > -- > - 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 peter at stuge.se Fri Jan 25 03:41:44 2013 From: peter at stuge.se (Peter Stuge) Date: Fri, 25 Jan 2013 04:41:44 +0100 Subject: Some beginner questions and comments In-Reply-To: References: <50FBD1A3.2080503@pernau.at> <20130121035651.4933.qmail@stuge.se> <20130121080032.3150.qmail@stuge.se> Message-ID: <20130125034144.15638.qmail@stuge.se> Sylvain Munaut wrote: > > Sure we can - even if it's just a single .a file. Linker search path > > has nothing to do with an OS, libraries can be used without an OS, > > and no BSP is needed. > > Yes ok, but it's really more of an hassle than an advantage, and then > if you want to use the same toolchain to build different arm projects > that need different libosmocore version, that's going to be fun ... That's what pkg-config is for, and libosmocore already installs a .pc file. Set PKG_CONFIG_LIBDIR in order to pick up the correct libosmocore. A sane default could maybe be set by the Makefile, meaning that no special consideration is needed when following the default recommended build approach as we document on the wiki. I don't think it makes sense to install libosmocore into the toolchain's own lib directory. > it's going to be a bunch of additional step that can be messed up > and IMHO with _NO_ upsides at all. I don't think it would be additional user-visible steps, and internally the steps are still the same. > I don't see why we would change it Because building both for host and target would use the same pattern, and in particular a pattern (pkg-config) which is sadly not well understood but very handy. //Peter From peter at stuge.se Fri Jan 25 05:05:37 2013 From: peter at stuge.se (Peter Stuge) Date: Fri, 25 Jan 2013 06:05:37 +0100 Subject: Some beginner questions and comments In-Reply-To: <20130125034144.15638.qmail@stuge.se> References: <50FBD1A3.2080503@pernau.at> <20130121035651.4933.qmail@stuge.se> <20130121080032.3150.qmail@stuge.se> <20130125034144.15638.qmail@stuge.se> Message-ID: <20130125050537.5078.qmail@stuge.se> Peter Stuge wrote: > Set PKG_CONFIG_LIBDIR in order to pick up the correct libosmocore. That is, when the correct library is not the one installed to system default location, ie. the host-compiled library. //Peter From g.roelant at telenet.be Sun Jan 20 15:52:46 2013 From: g.roelant at telenet.be (g.roelant at telenet.be) Date: Sun, 20 Jan 2013 16:52:46 +0100 (CET) Subject: gsm450 in belgium Message-ID: <8f995809-7070-48f5-9c9e-262533692546@chipo.telenet-ops.be> Hi, Does anyone know if gsm450 is encrypted with A5/1? and who is using gsm450 in belgium I can see signals on my ettus + external ant. there... kind regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From benny at benny.de Mon Jan 21 06:40:41 2013 From: benny at benny.de (Benjamin Hagemann) Date: Mon, 21 Jan 2013 07:40:41 +0100 Subject: gsm450 in belgium In-Reply-To: <8f995809-7070-48f5-9c9e-262533692546@chipo.telenet-ops.be> References: <8f995809-7070-48f5-9c9e-262533692546@chipo.telenet-ops.be> Message-ID: <20130121064041.GS7121@quelle.benny.de> Good morning, * g.roelant at telenet.be [130120 17:29]: > > Does anyone know if gsm450 is encrypted with A5/1? > and who is using gsm450 in belgium > > I can see signals on my ettus + external ant. there... maybe gsmmap.org can help you. http://gsmmap.org/ about it: http://www.digitaltrends.com/mobile/researcher-claims-all-gsm-phones-vulnerable-to-hijacking/ http://www.nextlevelofnews.com/2011/12/karsten-nohl-most-gsm-cellular-networks-worldwide-vulnerable-to-attack.html http://events.ccc.de/congress/2011/Fahrplan/events/4736.en.html => http://events.ccc.de/congress/2011/Fahrplan/attachments/1994_111217.SRLabs-28C3-Defending_mobile_phones.pdf (page 13) -- 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: 190 bytes Desc: Digital signature URL: From 246tnt at gmail.com Mon Jan 21 07:40:16 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Mon, 21 Jan 2013 08:40:16 +0100 Subject: gsm450 in belgium In-Reply-To: <8f995809-7070-48f5-9c9e-262533692546@chipo.telenet-ops.be> References: <8f995809-7070-48f5-9c9e-262533692546@chipo.telenet-ops.be> Message-ID: Hi, > and who is using gsm450 in belgium No one ... I seriously doubt it's GSM. There is no band allocated to it by the IBPT. There should only be TETRA, PMR, and some local paging & medical stuff around 450. Cheers, Sylvain From qiuhan1989 at gmail.com Mon Jan 21 00:52:16 2013 From: qiuhan1989 at gmail.com (qiuhan1989) Date: Sun, 20 Jan 2013 16:52:16 -0800 (PST) Subject: What's the difference between the hello_world.e88flash.bin and hello_world.compalram.bin Message-ID: <1358729536108-4025734.post@n3.nabble.com> As said in the topic, I don't know what is the difference between the two .bin file. And when I try the osmocon app, only the hello_world.compalram.bin works, why? Thanks in advance. -- View this message in context: http://baseband-devel.722152.n3.nabble.com/What-s-the-difference-between-the-hello-world-e88flash-bin-and-hello-world-compalram-bin-tp4025734.html Sent from the baseband-devel mailing list archive at Nabble.com. From andreas at eversberg.eu Mon Jan 21 15:54:29 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Mon, 21 Jan 2013 16:54:29 +0100 Subject: What's the difference between the hello_world.e88flash.bin and hello_world.compalram.bin In-Reply-To: <1358729536108-4025734.post@n3.nabble.com> References: <1358729536108-4025734.post@n3.nabble.com> Message-ID: <50FD64B5.5030004@eversberg.eu> qiuhan1989 wrote: > As said in the topic, I don't know what is the difference between the two > .bin file. And when I try the osmocon app, only the > hello_world.compalram.bin works, why? > Thanks in advance. > hi, the e88flash.bin is compiled for running from flash memory rather than ram. andreas From qiuhan1989 at gmail.com Mon Jan 21 18:32:27 2013 From: qiuhan1989 at gmail.com (qiuhan1989) Date: Mon, 21 Jan 2013 10:32:27 -0800 (PST) Subject: What's the difference between the hello_world.e88flash.bin and hello_world.compalram.bin In-Reply-To: <50FD64B5.5030004@eversberg.eu> References: <1358729536108-4025734.post@n3.nabble.com> <50FD64B5.5030004@eversberg.eu> Message-ID: <1358793147568-4025748.post@n3.nabble.com> Thank you for your replying! I see that difference. When I try to run the following command, it works, but if I change FIRMWARE.compalram.bin to FIRMWARE.e88flash.bin, there is no result. $ ./osmocon -p /dev/ttyUSB0 -m c123xor ../../target/firmware/board/PHONE_TYPE/FIRMWARE.compalram.bin And one more further question, if I want to write a firmware file by myself, how can I manage to compile it running in ram or flash? -- View this message in context: http://baseband-devel.722152.n3.nabble.com/What-s-the-difference-between-the-hello-world-e88flash-bin-and-hello-world-compalram-bin-tp4025734p4025748.html Sent from the baseband-devel mailing list archive at Nabble.com. From osmocom at ngolde.de Mon Jan 21 21:01:44 2013 From: osmocom at ngolde.de (Nico Golde) Date: Mon, 21 Jan 2013 22:01:44 +0100 Subject: What's the difference between the hello_world.e88flash.bin and hello_world.compalram.bin In-Reply-To: <1358793147568-4025748.post@n3.nabble.com> References: <1358729536108-4025734.post@n3.nabble.com> <50FD64B5.5030004@eversberg.eu> <1358793147568-4025748.post@n3.nabble.com> Message-ID: <20130121210144.GA662@nybble.binarybase.org> Hi, * qiuhan1989 [2013-01-21 21:45]: > Thank you for your replying! > I see that difference. When I try to run the following command, it works, > but if I change FIRMWARE.compalram.bin to FIRMWARE.e88flash.bin, there is no > result. It's just not intended to be used like that. These firmwares are used by the osmocom loader in case you want to flash an application. For more information regarding flashing firmwares see http://bb.osmocom.org/trac/wiki/flashing > $ ./osmocon -p /dev/ttyUSB0 -m c123xor > ../../target/firmware/board/PHONE_TYPE/FIRMWARE.compalram.bin > > And one more further question, if I want to write a firmware file by myself, > how can I manage to compile it running in ram or flash? Have a look at src/target/firmware/Makefile, you can basically generate both versions by adding your application there. Cheers Nico From laforge at gnumonks.org Mon Jan 21 12:33:00 2013 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 21 Jan 2013 13:33:00 +0100 Subject: Jan 23, 8pm / Osmocom Berlin User Group meeting Message-ID: <20130121123300.GY13197@prithivi.gnumonks.org> Hi all! This is the announcement for the latest incarnation of our bi-weekly Osmocom Berlin meeting. January 23, 8pm @ CCC Berlin, Marienstr. 11, 10113 Berlin There is no formal presentation scheduled for this meeting. However, we'll have a progress report + demonstration of current osmo-pcu. If you are interested to show up, feel free to do so. The meeting is free as in "free beer", despite no actual free beer being around ;) 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 akibsayyed at gmail.com Wed Jan 23 04:13:37 2013 From: akibsayyed at gmail.com (Akib Sayyed) Date: Wed, 23 Jan 2013 09:43:37 +0530 Subject: Need instructions Message-ID: Dear All I need instructions for flashing c155 with custom firmware. also i need to build linker script too.what all changes need to be done in flash.lds for e88 hw. will changes in only address and size part will work ?? can any one help me ?? -- Akib Sayyed Matrix-Shell akibsayyed at gmail.com akibsayyed at matrixshell.com Mob:- +91-966-514-2243 -------------- next part -------------- An HTML attachment was scrubbed... URL: From akibsayyed at gmail.com Wed Jan 23 14:51:39 2013 From: akibsayyed at gmail.com (Akib Sayyed) Date: Wed, 23 Jan 2013 20:21:39 +0530 Subject: another method for filter rework Message-ID: Dear sylvain I checked on your website you gave some other way of doing filter rework. I checked tried to check problem n checked possible shorts. but multi meter shows all part are shorted. also checked each components but it shows that there is direct connection in between all points of baluns. i would like to try other way for same -- Akib Sayyed Matrix-Shell akibsayyed at gmail.com akibsayyed at matrixshell.com Mob:- +91-966-514-2243 -------------- next part -------------- An HTML attachment was scrubbed... URL: From zero-kelvin at gmx.de Wed Jan 23 16:45:56 2013 From: zero-kelvin at gmx.de (dexter) Date: Wed, 23 Jan 2013 17:45:56 +0100 Subject: another method for filter rework In-Reply-To: References: Message-ID: <510013C4.2070300@gmx.de> Hi. > > i would like to try other way for same > I did it several times with a soldering iron. I have twisted a wire around the iron to get a second, much sharper tip. I also sharpend the end of the wire. With a soldering iron tuned like that i soldered the components under a stereo lens basically like normal components. I know this method is a bit extreme but i am not familiar with hot air ;-) You also should use flux. I have liquid one that sucks itself under the components. Its called FL 88 FLUXI. I am very happy with that. A multimeter is not the right tool for testing for shorts. It sends a current through the parts. As the parts are soldered into a circuit you can not really distinguish between low impedance components and real shorts and depending on the multimeter quality you might ruin parts. You have no AVR here, its a very sensitive HF circuit, don't forget that. I think you better inspect it visually using a stereo lens. Don't worry if you ruin some phones, thats normal. I think i ruined two phones before i could do it properly. You also should be familiar with SMD hand-soldering otherwise you won't have a chance. After the mod do not use the phone for transmitting anymore as you might ruin the receiver then. regards. Philipp From zero-kelvin at gmx.de Wed Jan 23 18:13:08 2013 From: zero-kelvin at gmx.de (dexter) Date: Wed, 23 Jan 2013 19:13:08 +0100 Subject: another method for filter rework In-Reply-To: References: Message-ID: <51002834.6060709@gmx.de> Hi. > > i would like to try other way for same > I did it several times with a soldering iron. I have twisted a wire around the iron to get a second, much sharper tip. I also sharpend the end of the wire. With a soldering iron tuned like that i soldered the components under a stereo lens basically like normal components. I know this method is a bit extreme but i am not familiar with hot air ;-) You also should use flux. I have liquid one that sucks itself under the components. Its called FL 88 FLUXI. I am very happy with that. A multimeter is not the right tool for testing for shorts. It sends a current through the parts. As the parts are soldered into a circuit you can not really distinguish between low impedance components and real shorts and depending on the multimeter quality you might ruin parts. You have no AVR here, its a very sensitive HF circuit, don't forget that. I think you better inspect it visually using a stereo lens. Don't worry if you ruin some phones, thats normal. I think i ruined two phones before i could do it properly. You also should be familiar with SMD hand-soldering otherwise you won't have a chance. After the mod do not use the phone for transmitting anymore as you might ruin the receiver then. regards. Philipp From akibsayyed at gmail.com Fri Jan 25 19:44:40 2013 From: akibsayyed at gmail.com (Akib Sayyed) Date: Sat, 26 Jan 2013 01:14:40 +0530 Subject: another method for filter rework In-Reply-To: <51002834.6060709@gmx.de> References: <51002834.6060709@gmx.de> Message-ID: hello guys does anyone know about this The 'hacked up' way with just capswhat value of caps are used in this one ?? On Wed, Jan 23, 2013 at 11:43 PM, dexter wrote: > Hi. > > >> i would like to try other way for same >> >> I did it several times with a soldering iron. I have twisted a wire > around the iron to get a second, much sharper tip. I also sharpend the end > of the wire. With a soldering iron tuned like that i soldered the > components under a stereo lens basically like normal components. I know > this method is a bit extreme but i am not familiar with hot air ;-) > > You also should use flux. I have liquid one that sucks itself under the > components. Its called FL 88 FLUXI. I am very happy with that. > > A multimeter is not the right tool for testing for shorts. It sends a > current through the parts. As the parts are soldered into a circuit you can > not really distinguish between low impedance components and real shorts and > depending on the multimeter quality you might ruin parts. You have no AVR > here, its a very sensitive HF circuit, don't forget that. I think you > better inspect it visually using a stereo lens. > > Don't worry if you ruin some phones, thats normal. I think i ruined two > phones before i could do it properly. You also should be familiar with SMD > hand-soldering otherwise you won't have a chance. > > After the mod do not use the phone for transmitting anymore as you might > ruin the receiver then. > > regards. > Philipp > > -- Akib Sayyed Matrix-Shell akibsayyed at gmail.com akibsayyed at matrixshell.com Mob:- +91-966-514-2243 -------------- next part -------------- An HTML attachment was scrubbed... URL: From niceguy108 at gmail.com Thu Jan 24 16:21:10 2013 From: niceguy108 at gmail.com (Bhaskar11) Date: Thu, 24 Jan 2013 21:51:10 +0530 Subject: Structure of traffic data in burst_ind messages Message-ID: I'm experimenting with burst-ind branch and am able to track control messages in ccch_scan. I then send an Assignment Command to change to a traffic channel. I can see the bursts come in, but cannot make out the format of the data. If I understand right, the burst_ind structure holds 15 bytes of data, but the traffic data should be 33 bytes. I assume the traffic data is spread across several burst-ind messages. Can you please clarify how to re-assemble the full 33-byte traffic data structure from the burst_ind messages? Thanks. B. -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Thu Jan 24 17:48:19 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Thu, 24 Jan 2013 18:48:19 +0100 Subject: Structure of traffic data in burst_ind messages In-Reply-To: References: Message-ID: > Can you please clarify how to re-assemble the full 33-byte traffic data > structure from the burst_ind messages? GSM 05.03 From niceguy108 at gmail.com Thu Jan 24 19:08:16 2013 From: niceguy108 at gmail.com (Bhaskar11) Date: Fri, 25 Jan 2013 00:38:16 +0530 Subject: Structure of traffic data in burst_ind messages In-Reply-To: References: Message-ID: > > Can you please clarify how to re-assemble the full 33-byte traffic data > > structure from the burst_ind messages? > > GSM 05.03 > Thanks! I'd like to believe that we already have code that does the work somewhere in the Osmocom project, even if it does it partially. I see some interesting code in rx_l1_traffic_ind() in l1ctl.c. But that already assumes 33 bytes received. If possible I'd rather build on existing code that build from scratch! Can you please point me in the right direction? Thanks for your prompt replies. B. -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Thu Jan 24 19:43:36 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Thu, 24 Jan 2013 20:43:36 +0100 Subject: Structure of traffic data in burst_ind messages In-Reply-To: References: Message-ID: Hi, > I see some interesting > code in rx_l1_traffic_ind() in l1ctl.c. But that already assumes 33 bytes > received. If possible I'd rather build on existing code that build from > scratch! There is no code that does what's needed for traffic channels in osmocom-bb. During normal operation, this is entirely dealt with inside the DSP, and traffic_ind deals with some TI specific stuff that has no relevance whatsoever in this case. > Can you please point me in the right direction? again ... GSM 05.03 I will not repeat myself, a third time ... Cheers, Sylvain From niceguy108 at gmail.com Sat Jan 26 19:17:49 2013 From: niceguy108 at gmail.com (Bhaskar11) Date: Sun, 27 Jan 2013 00:47:49 +0530 Subject: Structure of traffic data in burst_ind messages In-Reply-To: References: Message-ID: I'm able to track the channel and extract the data. But to detect end of traffic I follow the similar code as in ccch_scan by checking the signal to noise ratio of the bursts on the downlink but during SACCH bursts only. In most cases app_state.dch_badcnt quickly climbs beyond 6, and the channel is dropped within barely a second. Much of the traffic data bursts also have a very low snr. Very occasionally, the channel stays on for 3 to 5 seconds, then drops. During these rare occasions the traffic data remains with high snr for longer time also. What am I doing wrong? Is this the right way to detect end of traffic data? Is it normal for this channel to have low snr? B On Fri, Jan 25, 2013 at 1:13 AM, Sylvain Munaut <246tnt at gmail.com> wrote: > Hi, > > > > I see some interesting > > code in rx_l1_traffic_ind() in l1ctl.c. But that already assumes 33 bytes > > received. If possible I'd rather build on existing code that build from > > scratch! > > There is no code that does what's needed for traffic channels in > osmocom-bb. During normal operation, this is entirely dealt with > inside the DSP, and traffic_ind deals with some TI specific stuff that > has no relevance whatsoever in this case. > > > > Can you please point me in the right direction? > > again ... GSM 05.03 > > I will not repeat myself, a third time ... > > > Cheers, > > Sylvain > -------------- next part -------------- An HTML attachment was scrubbed... URL: From niceguy108 at gmail.com Mon Jan 28 14:49:05 2013 From: niceguy108 at gmail.com (Bhaskar11) Date: Mon, 28 Jan 2013 20:19:05 +0530 Subject: Structure of traffic data in burst_ind messages In-Reply-To: References: Message-ID: I'm trying to decode TCH data using burst_ind. Below is info from the frames as they come. The SACCHs are correctly separated by 26 frames in the frame number so I know the data is valid. I detect upload/download of frame by checking (bi->flags & BI_FLG_SACCH). But I see two problems: 1. Almost every alternate frame is missing. 2. I should not be seeing any upload frames, as I am not using filter-rework. Can you please guide me on what could be wrong? Data received: TCH/H (hl=1, hu=1) in FN=379183 DL SACCH TCH/H (hl=0, hu=1) in FN=379183 UL SACCH TCH/H (hl=1, hu=1) in FN=379185 DL TCH/H (hl=1, hu=1) in FN=379185 UL TCH/H (hl=1, hu=1) in FN=379187 DL TCH/H (hl=0, hu=0) in FN=379187 UL TCH/H (hl=1, hu=0) in FN=379189 DL TCH/H (hl=0, hu=1) in FN=379189 UL TCH/H (hl=1, hu=1) in FN=379191 DL TCH/H (hl=0, hu=1) in FN=379191 UL TCH/H (hl=1, hu=1) in FN=379193 DL TCH/H (hl=0, hu=0) in FN=379193 UL TCH/H (hl=1, hu=1) in FN=379195 DL TCH/H (hl=0, hu=1) in FN=379195 UL TCH/H (hl=1, hu=1) in FN=379198 DL TCH/H (hl=1, hu=0) in FN=379198 UL TCH/H (hl=1, hu=1) in FN=379200 DL TCH/H (hl=0, hu=1) in FN=379200 UL TCH/H (hl=1, hu=1) in FN=379202 DL TCH/H (hl=1, hu=0) in FN=379202 UL TCH/H (hl=0, hu=0) in FN=379204 DL TCH/H (hl=1, hu=0) in FN=379204 UL TCH/H (hl=0, hu=0) in FN=379206 DL TCH/H (hl=1, hu=0) in FN=379206 UL TCH/H (hl=1, hu=1) in FN=379208 DL TCH/H (hl=0, hu=1) in FN=379208 UL TCH/H (hl=0, hu=0) in FN=379209 DL SACCH TCH/H (hl=1, hu=1) in FN=379209 UL SACCH TCH/H (hl=0, hu=0) in FN=379211 DL TCH/H (hl=1, hu=1) in FN=379211 UL TCH/H (hl=1, hu=1) in FN=379213 DL TCH/H (hl=0, hu=0) in FN=379213 UL TCH/H (hl=1, hu=1) in FN=379215 DL TCH/H (hl=0, hu=0) in FN=379215 UL TCH/H (hl=1, hu=1) in FN=379217 DL TCH/H (hl=1, hu=1) in FN=379217 UL TCH/H (hl=1, hu=1) in FN=379219 DL TCH/H (hl=0, hu=0) in FN=379219 UL TCH/H (hl=1, hu=1) in FN=379221 DL TCH/H (hl=0, hu=1) in FN=379221 UL TCH/H (hl=1, hu=1) in FN=379224 DL TCH/H (hl=1, hu=0) in FN=379224 UL TCH/H (hl=1, hu=1) in FN=379226 DL TCH/H (hl=1, hu=1) in FN=379226 UL TCH/H (hl=1, hu=1) in FN=379228 DL TCH/H (hl=1, hu=1) in FN=379228 UL TCH/H (hl=1, hu=1) in FN=379230 DL TCH/H (hl=1, hu=1) in FN=379230 UL TCH/H (hl=1, hu=1) in FN=379232 DL TCH/H (hl=1, hu=1) in FN=379232 UL TCH/H (hl=1, hu=1) in FN=379234 DL TCH/H (hl=0, hu=0) in FN=379234 UL TCH/H (hl=1, hu=1) in FN=379235 DL SACCH TCH/H (hl=0, hu=1) in FN=379235 UL SACCH TCH/H (hl=1, hu=1) in FN=379237 DL TCH/H (hl=1, hu=1) in FN=379237 UL TCH/H (hl=0, hu=0) in FN=379239 DL TCH/H (hl=1, hu=0) in FN=379239 UL TCH/H (hl=0, hu=0) in FN=379241 DL TCH/H (hl=1, hu=0) in FN=379241 UL TCH/H (hl=0, hu=0) in FN=379243 DL TCH/H (hl=0, hu=1) in FN=379243 UL TCH/H (hl=0, hu=0) in FN=379245 DL TCH/H (hl=0, hu=0) in FN=379245 UL TCH/H (hl=1, hu=1) in FN=379247 DL TCH/H (hl=0, hu=1) in FN=379247 UL TCH/H (hl=1, hu=1) in FN=379250 DL TCH/H (hl=0, hu=0) in FN=379250 UL TCH/H (hl=1, hu=1) in FN=379252 DL TCH/H (hl=1, hu=1) in FN=379252 UL TCH/H (hl=1, hu=1) in FN=379254 DL TCH/H (hl=1, hu=0) in FN=379254 UL TCH/H (hl=1, hu=1) in FN=379256 DL TCH/H (hl=1, hu=1) in FN=379256 UL TCH/H (hl=1, hu=1) in FN=379258 DL TCH/H (hl=1, hu=0) in FN=379258 UL TCH/H (hl=1, hu=1) in FN=379260 DL TCH/H (hl=0, hu=0) in FN=379260 UL TCH/H (hl=1, hu=1) in FN=379261 DL SACCH TCH/H (hl=1, hu=0) in FN=379261 UL SACCH TCH/H (hl=1, hu=1) in FN=379263 DL TCH/H (hl=0, hu=0) in FN=379263 UL TCH/H (hl=1, hu=1) in FN=379265 DL -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Mon Jan 28 15:19:04 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Mon, 28 Jan 2013 16:19:04 +0100 Subject: Structure of traffic data in burst_ind messages In-Reply-To: References: Message-ID: > But I see two problems: > 1. Almost every alternate frame is missing. ... TCH/H ... > 2. I should not be seeing any upload frames, as I am not using > filter-rework. The filters only attenuate the signal ... if the victim phone is close enough, they will go through anyway. Also, AFAIR the phone will transmit a burst_ind packet in anycase ... which might be complete gibberish, that up to you to try to interpret it. Cheers, Sylvain From niceguy108 at gmail.com Mon Jan 28 19:54:13 2013 From: niceguy108 at gmail.com (Bhaskar11) Date: Tue, 29 Jan 2013 01:24:13 +0530 Subject: Structure of traffic data in burst_ind messages In-Reply-To: References: Message-ID: Sylvain, thanks for the prompt replies. But... > But I see two problems: > > 1. Almost every alternate frame is missing. > > ... TCH/H ... I re-read the specs: 05.03 / 3.2.4. If the data is spread across 4 blocks, should that not mean some of the data will be on each successive burst? The specs don't mention skipping alternate bursts. So, I still don't understand why the entire burst would be missing alternately. I seem to have missed something important here. > > 2. I should not be seeing any upload frames, as I am not using > > filter-rework. > > The filters only attenuate the signal ... if the victim phone is close > enough, they will go through anyway. > Also, AFAIR the phone will transmit a burst_ind packet in anycase ... > which might be complete gibberish, that up to you to try to interpret > it. > In your experience, up to what distance does this kind of interference come in a typical scenario? Is it in the range of dozens of metres or hundreds? B. -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Mon Jan 28 21:00:40 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Mon, 28 Jan 2013 22:00:40 +0100 Subject: Structure of traffic data in burst_ind messages In-Reply-To: References: Message-ID: Hi, > I re-read the specs: 05.03 / 3.2.4. If the data is spread across 4 blocks, > should that not mean some of the data will be on each successive burst? sucessive burst ... on the logical channel, not the physical channel. You need to read 05.02 now. > The specs don't mention skipping alternate bursts. Sure they do. You just haven't read them all yet. > I seem to have missed something important here. Yes, it would seem so. > In your experience, up to what distance does this kind of interference come > in a typical scenario? Is it in the range of dozens of metres or hundreds? No idea, never did any testing beyond a single room. Cheers, Sylvain From oxccoxcc at yandex.ru Thu Jan 31 15:08:48 2013 From: oxccoxcc at yandex.ru (Pe) Date: Thu, 31 Jan 2013 07:08:48 -0800 (PST) Subject: Structure of traffic data in burst_ind messages In-Reply-To: References: Message-ID: <1359644928095-4025787.post@n3.nabble.com> Hi, Bhaskar11 Did you resolve problem with low snr? Do you make synchronization on SCH before going to TCH, after Assignment Command? -- View this message in context: http://baseband-devel.722152.n3.nabble.com/Structure-of-traffic-data-in-burst-ind-messages-tp4025762p4025787.html Sent from the baseband-devel mailing list archive at Nabble.com. From roderrick345 at gmail.com Thu Jan 24 19:18:22 2013 From: roderrick345 at gmail.com (Roddy Ernest) Date: Thu, 24 Jan 2013 11:18:22 -0800 Subject: Hardware replacement for uplink sniffing Message-ID: <0E07507A-B594-45E3-9B50-EF46446E45EE@gmail.com> Hello, I know that there is a hardware replacement kit that is available for Osmocombb phones that help make the phones be used as uplink sniffers, but unfortunately the kit uses components that operate in the European GSM bands. Are there any hardware replacement kits for Osmocombb phones that operate in the U.S. GSM frequency bands? Sincerely, Roderick Ernest From 246tnt at gmail.com Thu Jan 31 11:39:59 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Thu, 31 Jan 2013 12:39:59 +0100 Subject: Hardware replacement for uplink sniffing In-Reply-To: <0E07507A-B594-45E3-9B50-EF46446E45EE@gmail.com> References: <0E07507A-B594-45E3-9B50-EF46446E45EE@gmail.com> Message-ID: > I know that there is a hardware replacement kit that is available for Osmocombb phones that help make the phones be used as uplink sniffers, but unfortunately the kit uses components that operate in the European GSM bands. Are there any hardware replacement kits for Osmocombb phones that operate in the U.S. GSM frequency bands? The HHM1526 balun is specified for both PCS and DCS and the one for the lower band should be close enough. Cheers, Sylvain From akibsayyed at gmail.com Fri Jan 25 07:48:35 2013 From: akibsayyed at gmail.com (Akib Sayyed) Date: Fri, 25 Jan 2013 13:18:35 +0530 Subject: Dumping DSP Message-ID: Dear list i see there is target_dsp firmware. as per readme found inside it dumps dsp data on console. but i am unable to compile. it needs tic54x-coff but couldnt find it. can any one guide me through this. -- Akib Sayyed Matrix-Shell akibsayyed at gmail.com akibsayyed at matrixshell.com Mob:- +91-966-514-2243 -------------- next part -------------- An HTML attachment was scrubbed... URL: From teslarode at yahoo.com Mon Jan 28 18:34:36 2013 From: teslarode at yahoo.com (teslarode at yahoo.com) Date: Mon, 28 Jan 2013 10:34:36 -0800 (PST) Subject: Help with JTAG In-Reply-To: <1359312248.96598.YahooMailNeo@web160903.mail.bf1.yahoo.com> References: <1359312248.96598.YahooMailNeo@web160903.mail.bf1.yahoo.com> Message-ID: <1359398076.55949.YahooMailNeo@web160904.mail.bf1.yahoo.com> Hello, I've found a very interesting article about SciphoneDream G2 published on your webpage at http://bb.osmocom.org/trac/wiki/SciphoneDreamG2 that covers pretty detailed information about MT6235 SoC, bootstrapping as well as JTAG. This is the only article I have ever found on internet about MTK SoC and JTAG. What I am trying to accomplish is to access NAND flash and write to it over JTAG (in order to recover from corruption after bad flash) on MTK8555 SoC which according to my in-depth research and analysis has very similar architecture to MT6235. If I can't write to NAND over JTAG but would be able to launch u-boot that would be a solution too. I am very good at ARM assembly and debugging, however I am not very experienced with JTAG. Do you think you (or anyone else) could help me out, by giving me guidance what hardware, software, config files should I use to make JTAG work on this SoC ? Any help or advise would be more then appreciated! If you are a wrong person I contacted, I apologize for the inconvenience. Many thanks in advance! Dwayne -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcin.mielczarczyk at gmail.com Thu Jan 31 06:14:20 2013 From: marcin.mielczarczyk at gmail.com (Marcin Mielczarczyk) Date: Thu, 31 Jan 2013 07:14:20 +0100 Subject: Help with JTAG In-Reply-To: <1359398076.55949.YahooMailNeo@web160904.mail.bf1.yahoo.com> References: <1359312248.96598.YahooMailNeo@web160903.mail.bf1.yahoo.com> <1359398076.55949.YahooMailNeo@web160904.mail.bf1.yahoo.com> Message-ID: Hi Dwayne, On Mon, Jan 28, 2013 at 7:34 PM, wrote: > > I've found a very interesting article about SciphoneDream G2 published on > your webpage at http://bb.osmocom.org/trac/wiki/SciphoneDreamG2 that > covers pretty detailed information about MT6235 SoC, bootstrapping as well > as JTAG. This is the only article I have ever found on internet about MTK > SoC and JTAG. > What I am trying to accomplish is to access NAND flash and write to it over > JTAG (in order to recover from corruption after bad flash) on MTK8555 SoC > which according to my in-depth research and analysis has very similar > architecture to MT6235. If I can't write to NAND over JTAG but would be > able to launch u-boot that would be a solution too. I am very good at ARM > assembly and debugging, however I am not very experienced with JTAG. Do you > think you (or anyone else) could help me out, by giving me guidance what > hardware, software, config files should I use to make JTAG work on this SoC > ? Any help or advise would be more then appreciated! > For JTAG debugging of MT6235 I used commercial debugger Trace32 from Lauterbach. I know that it was also working with OpenOCD. In case when your NAND is corrupted completely it can be pretty hard to get your board running. The biggest problem is in initialising SDRAM/DDR RAM controller, to get external RAM working. When I had MT6235 running (booting without issues), I was able to break running processor and load my code into external RAM as RAM was already initialised by bootloader. Later on when I learnt Mediatek boot process and new where bootloader is placed in NAND, I extracted SDRAM initialisation procedure. NAND layout is described in the link you mentioned. MT6235 had static RAM (64KB or 128KB) available from start (without initialisation), and you could place your code for SoC init there (this is where DRAM initialisation was copied from NAND and then executed). I have never flashed NAND using JTAG on MT6235 as I haven't found it useful. I focused on getting U-Boot running and this is the first place which has flash driver for NAND found on Sciphone G2. In case of any further questions you can contact me directly as this group covers different topics. BR, Marcin -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig_comstock at yahoo.com Tue Jan 29 17:09:15 2013 From: craig_comstock at yahoo.com (Craig Comstock) Date: Tue, 29 Jan 2013 09:09:15 -0800 (PST) Subject: thanks for osmocom, my goals, available to test c139 & c115 Message-ID: <1359479355.81873.YahooMailNeo@web121004.mail.ne1.yahoo.com> Hi, ? I have bought two phones... Motorola C139 and Motorola C115. I'm using the raspberry PI UART instead of a dedicated cable and got the hello world example working just fine on the C115. ? My goal is to have a usable open source phone which I see there is a bit of a start at in the source code. ? I've been working on getting debian on my Motorola Defy for a while and am making some progress. ? Since I have two phones... I am certainly willing to help in testing things. I can't promise a lot of time but I can hope to help a little. ? Thanks for your efforts, Craig Comstock Lawrence, KS -------------- next part -------------- An HTML attachment was scrubbed... URL: From GNUtoo at no-log.org Tue Jan 29 18:05:24 2013 From: GNUtoo at no-log.org (Denis 'GNUtoo' Carikli) Date: Tue, 29 Jan 2013 19:05:24 +0100 Subject: thanks for osmocom, my goals, available to test c139 & c115 In-Reply-To: <1359479355.81873.YahooMailNeo@web121004.mail.ne1.yahoo.com> References: <1359479355.81873.YahooMailNeo@web121004.mail.ne1.yahoo.com> Message-ID: <20130129190524.4683ce27@m4a785t-m.lan> On Tue, 29 Jan 2013 09:09:15 -0800 (PST) Craig Comstock wrote: > Hi, Hi, > My goal is to have a usable open source phone which I see there is a > bit of a start at in the source code. Learn about the osmocombb port on top of nuttx(also known as nuttx-bb). We gather on a temporary IRC channel at ##nuttx-bb on Freenode. Denis. From niceguy108 at gmail.com Tue Jan 29 18:51:20 2013 From: niceguy108 at gmail.com (Bhaskar11) Date: Wed, 30 Jan 2013 00:21:20 +0530 Subject: Mistake in gsm_04_08.h channel mode definition Message-ID: In enum gsm48_chan_mode definitions we have: GSM48_CMODE_DATA_3k6 = 0x23, It should be 0x13 as in 3GPP TS 04.08 / 10.5.2.6. Please update in repository. -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at freyther.de Wed Jan 30 07:56:58 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Wed, 30 Jan 2013 08:56:58 +0100 Subject: Mistake in gsm_04_08.h channel mode definition In-Reply-To: References: Message-ID: <20130130075658.GQ20860@xiaoyu.lan> On Wed, Jan 30, 2013 at 12:21:20AM +0530, Bhaskar11 wrote: > In enum gsm48_chan_mode definitions we have: GSM48_CMODE_DATA_3k6 = 0x23, > > It should be 0x13 as in 3GPP TS 04.08 / 10.5.2.6. > > Please update in repository. Hi, could you please take a look at git commit and git format-patch or git send-email. It makes applying patches very easy for us and your author name and email address will be like you want it. and thanks for spotting and reporting this. holger From niceguy108 at gmail.com Thu Jan 31 07:12:10 2013 From: niceguy108 at gmail.com (Bhaskar11) Date: Thu, 31 Jan 2013 12:42:10 +0530 Subject: Decoding AMR Message-ID: I've been experimenting with decoding AMR in burst_ind with the following steps: 1. Ignore SACCH and UL frames 2. check for FACCH 3. check for CMI/CMR (only on specific frame numbers) and change codec if necessary after 12 frames 4. check for RATSCCH, if necessary change codec after 12 frames Can anyone confirm that this is the proper process? I've looked at Bob's code of July 2012. It does not use the above checks which may be the reason for its failure. B. ===================== From: bob gmail.com> Subject: is my patch for capturing TCH frame correctly? Newsgroups: gmane.comp.mobile.osmocom.baseband.devel Date: 2012-07-19 08:58:28 GMT (27 weeks, 6 days, 20 hours and 14 minutes ago) Hi, everyone interesting the topic, this is my latest patch for TCH decode, fix few bug; but it not work well for TCH AMR decode, welcome everyone interesting it to review it and modify it! the most problem now I think is the capture of the Correct TCH frame, at the last ,there is some output for analysis --- app_ccch_scan.c 2012-03-14 16:08:11.305112000 +0800 +++ new_app_ccch_scan.c 2012-07-19 15:32:31.945314000 +0800 -50,20 +50,80 #include #include +#include +#include "conv_tch_afs.h" +//#include "../openbtsstuff/GSML1FEC.h" +//extern bool TCHFACCHL1Decoder::processBurst( const RxBurst& inBurst); +//const struct osmo_conv_code conv_tch_afs_12_2; +extern FILE *log_tmsi; extern struct gsmtap_inst *gsmtap_inst; +FILE *d_speech_file; +const unsigned char amr_nb_magic[6] = { 0x23, 0x21, 0x41, 0x4d, 0x52, 0x0a }; + -------------- next part -------------- An HTML attachment was scrubbed... URL: