From mail at thomasbertani.it Mon Sep 3 07:24:28 2012 From: mail at thomasbertani.it (Thomas Bertani) Date: Mon, 3 Sep 2012 09:24:28 +0200 Subject: Sagem OT-290 trace phone / GSMTAP integration In-Reply-To: References: <1342988200.4810.8.camel@gnutoo-laptop> Message-ID: Hi list, just a quick update on what is going on here. I received the Sagem OT-290 and started working on it a couple of weeks ago. At the moment I got it working for every layer message except for gprs rlc/mac header ones, I will work to support them asap. The git repo with the updated source code is available here: http://cgit.osmocom.org/cgit/ot290-gsmtap/ Any feedback is highly appreciated! Thomas Bertani -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at freyther.de Mon Sep 3 18:07:00 2012 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 3 Sep 2012 20:07:00 +0200 Subject: Sagem OT-290 trace phone / GSMTAP integration In-Reply-To: References: <1342988200.4810.8.camel@gnutoo-laptop> Message-ID: <20120903180700.GR17772@localhost> On Mon, Sep 03, 2012 at 09:24:28AM +0200, Thomas Bertani wrote: > Hi list, Hi, > http://cgit.osmocom.org/cgit/ot290-gsmtap/ I have added your project to the jenkins system[1]. > > Any feedback is highly appreciated! Test early, test often. :) thank you for your work holger [1] http://jenkins.osmocom.org/jenkins/job/ot290-gsmtap From khorben at defora.org Tue Sep 4 09:41:53 2012 From: khorben at defora.org (Pierre Pronchery) Date: Tue, 04 Sep 2012 11:41:53 +0200 Subject: LTE support Message-ID: <5045CCE1.1040708@defora.org> Hi guys, Fabrice Bellard strikes again: http://bellard.org/lte/ It looks like he hasn't released the source code though :( Cheers, -- khorben From dario.lombardo.ml at gmail.com Tue Sep 4 10:01:59 2012 From: dario.lombardo.ml at gmail.com (Dario Lombardo) Date: Tue, 4 Sep 2012 12:01:59 +0200 Subject: LTE support In-Reply-To: <5045CCE1.1040708@defora.org> References: <5045CCE1.1040708@defora.org> Message-ID: > > It looks like he hasn't released the source code though :( > I read "Interested companies can contact me" Did anyone try to contact him to have the code/bin? From sebastien at lorquet.fr Tue Sep 4 12:59:48 2012 From: sebastien at lorquet.fr (Sebastien Lorquet) Date: Tue, 04 Sep 2012 14:59:48 +0200 Subject: LTE support In-Reply-To: References: <5045CCE1.1040708@defora.org> Message-ID: <5045FB44.6050004@lorquet.fr> I understand "Wait for next February 30th for source code" ;) Sebastien Le 04/09/2012 12:01, Dario Lombardo a ?crit : >> It looks like he hasn't released the source code though :( >> > I read > > "Interested companies can contact me" > > Did anyone try to contact him to have the code/bin? > From laforge at gnumonks.org Wed Sep 5 06:50:02 2012 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 5 Sep 2012 08:50:02 +0200 Subject: Sept 5, 8pm / Osmocom Berlin User Group meeting Message-ID: <20120905065002.GM12467@prithivi.gnumonks.org> Hi all! This is the announcement for the next Osmocom Berlin meeting. Sept 05, 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, Harald [p.s.: I myself will not be able to attend tonight, but I'm sure you will be able to do just fine (or even better?)] -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From ml at mail.tsaitgaist.info Wed Sep 5 19:45:22 2012 From: ml at mail.tsaitgaist.info (Kevin Redon) Date: Wed, 05 Sep 2012 21:45:22 +0200 Subject: libgps fix for layer23 Message-ID: <1346874125-sup-4678@dennou> [PATCH] Fix linking with GNU ld 2.22 and libgps Error: gcc -Wall -I/home/kevredon/osmocom-bb/src/shared/libosmocore/include -I/home/kevredon/osmocom-bb/src/shared/libosmocore/include -g -O2 -D_HAVE_GPSD -lgps -o cell_log main.o app_cell_log.o cell_log.o geo.o ../common/liblayer23.a /home/kevredon/osmocom-bb/src/shared/libosmocore/build-host/src/.libs/libosmocore.a /home/kevredon/osmocom-bb/src/shared/libosmocore/build-host/src/gsm/.libs/libosmogsm.a /home/kevredon/osmocom-bb/src/shared/libosmocore/build-host/src/codec/.libs/libosmocodec.a -lm ../common/liblayer23.a(gps.o): In function `osmo_gpsd_cb': /home/kevredon/osmocom-bb/src/host/layer23/src/common/gps.c:79: undefined reference to `gps_waiting' Fix: Holger told me to do so (he knows better then me about autoconf) - set CFLAGS and LIBS for LIBGPS in layer23 - add libgps CFLAGS and LIBS in Makefile.am for common, misc, mobile I would have done the following (which also works): -AC_CHECK_LIB(gps, gps_waiting, CFLAGS+=" -D_HAVE_GPSD" LDFLAGS+=" -lgps",,) +AC_CHECK_LIB(gps, gps_waiting, CFLAGS+=" -D_HAVE_GPSD" LDFLAGS+=" -lgps" LIBS+=" -lgps",,) --- src/host/layer23/configure.ac | 5 ++++- src/host/layer23/src/common/Makefile.am | 2 +- src/host/layer23/src/misc/Makefile.am | 4 ++-- src/host/layer23/src/mobile/Makefile.am | 4 ++-- 4 files changed, 9 insertions(+), 6 deletions(-) diff --git a/src/host/layer23/configure.ac b/src/host/layer23/configure.ac index b50868a..9335e66 100644 --- a/src/host/layer23/configure.ac +++ b/src/host/layer23/configure.ac @@ -17,7 +17,10 @@ PKG_CHECK_MODULES(LIBOSMOCORE, libosmocore) PKG_CHECK_MODULES(LIBOSMOVTY, libosmovty) PKG_CHECK_MODULES(LIBOSMOGSM, libosmogsm) PKG_CHECK_MODULES(LIBOSMOCODEC, libosmocodec) -AC_CHECK_LIB(gps, gps_waiting, CFLAGS+=" -D_HAVE_GPSD" LDFLAGS+=" -lgps",,) +AC_CHECK_LIB(gps, gps_waiting, LIBGPS_CFLAGS=" -D_HAVE_GPSD" LIBGPS_LIBS=" -lgps ",,) +AC_SUBST([LIBGPS_CFLAGS]) +AC_SUBST([LIBGPS_LIBS]) + dnl checks for header files AC_HEADER_STDC diff --git a/src/host/layer23/src/common/Makefile.am b/src/host/layer23/src/common/Makefile.am index 73a0fc9..8d96ed2 100644 --- a/src/host/layer23/src/common/Makefile.am +++ b/src/host/layer23/src/common/Makefile.am @@ -1,5 +1,5 @@ INCLUDES = $(all_includes) -I$(top_srcdir)/include -AM_CFLAGS = -Wall $(LIBOSMOCORE_CFLAGS) $(LIBOSMOGSM_CFLAGS) +AM_CFLAGS = -Wall $(LIBOSMOCORE_CFLAGS) $(LIBOSMOGSM_CFLAGS) $(LIBGPS_CFLAGS) noinst_LIBRARIES = liblayer23.a liblayer23_a_SOURCES = l1ctl.c l1l2_interface.c sap_interface.c \ diff --git a/src/host/layer23/src/misc/Makefile.am b/src/host/layer23/src/misc/Makefile.am index 0b59f38..d8fb322 100644 --- a/src/host/layer23/src/misc/Makefile.am +++ b/src/host/layer23/src/misc/Makefile.am @@ -1,6 +1,6 @@ INCLUDES = $(all_includes) -I$(top_srcdir)/include -AM_CFLAGS = -Wall $(LIBOSMOCORE_CFLAGS) $(LIBOSMOGSM_CFLAGS) -LDADD = ../common/liblayer23.a $(LIBOSMOCORE_LIBS) $(LIBOSMOGSM_LIBS) $(LIBOSMOCODEC_LIBS) +AM_CFLAGS = -Wall $(LIBOSMOCORE_CFLAGS) $(LIBOSMOGSM_CFLAGS) $(LIBGPS_CFLAGS) +LDADD = ../common/liblayer23.a $(LIBOSMOCORE_LIBS) $(LIBOSMOGSM_LIBS) $(LIBOSMOCODEC_LIBS) $(LIBGPS_LIBS) bin_PROGRAMS = bcch_scan ccch_scan echo_test cell_log cbch_sniff diff --git a/src/host/layer23/src/mobile/Makefile.am b/src/host/layer23/src/mobile/Makefile.am index f3365af..8920c54 100644 --- a/src/host/layer23/src/mobile/Makefile.am +++ b/src/host/layer23/src/mobile/Makefile.am @@ -1,6 +1,6 @@ INCLUDES = $(all_includes) -I$(top_srcdir)/include -AM_CFLAGS = -Wall $(LIBOSMOCORE_CFLAGS) $(LIBOSMOGSM_CFLAGS) -LDADD = ../common/liblayer23.a $(LIBOSMOCORE_LIBS) $(LIBOSMOVTY_LIBS) $(LIBOSMOGSM_LIBS) $(LIBOSMOCODEC_LIBS) +AM_CFLAGS = -Wall $(LIBOSMOCORE_CFLAGS) $(LIBOSMOGSM_CFLAGS) $(LIBGPS_CFLAGS) +LDADD = ../common/liblayer23.a $(LIBOSMOCORE_LIBS) $(LIBOSMOVTY_LIBS) $(LIBOSMOGSM_LIBS) $(LIBOSMOCODEC_LIBS) $(LIBGPS_LIBS) noinst_LIBRARIES = libmobile.a libmobile_a_SOURCES = gsm322.c gsm480_ss.c gsm411_sms.c gsm48_cc.c gsm48_mm.c \ -- 1.7.9.5 From laforge at gnumonks.org Mon Sep 17 06:41:10 2012 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 17 Sep 2012 08:41:10 +0200 Subject: libgps fix for layer23 In-Reply-To: <1346874125-sup-4678@dennou> References: <1346874125-sup-4678@dennou> Message-ID: <20120917064110.GB3968@prithivi.gnumonks.org> Hi Kevin, On Wed, Sep 05, 2012 at 09:45:22PM +0200, Kevin Redon wrote: > [PATCH] Fix linking with GNU ld 2.22 and libgps thanks, merged. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From dario.lombardo.ml at gmail.com Fri Sep 7 15:15:00 2012 From: dario.lombardo.ml at gmail.com (Dario Lombardo) Date: Fri, 7 Sep 2012 17:15:00 +0200 Subject: PNLM list overwritten Message-ID: Hil list Today I've observed a strange behaviour when modifying the PNLM of some real networks expired sims (to be used with osmocom and openbts). I've put 001 01 on the top of the list. I've ejected and reinsterted the sim in the reader many times, and I'm sure that the value has been wrtitten. When trying to connect to my test operator I get the message "your sim card doesn't allow the connection to this network operator" from my android phone. Reading again the pnlm I see that the original list has been restored. This astonishes me... Is is possible that the SIM overwrites the list by itselt? Or is it the phone that does it? The android has an original, not branded, operating system. Thanks everybody for your help. Dario From cstone at pobox.com Fri Sep 7 16:02:41 2012 From: cstone at pobox.com (Brandon Creighton) Date: Fri, 7 Sep 2012 09:02:41 -0700 Subject: PNLM list overwritten In-Reply-To: References: Message-ID: I've seen similar behavior before -- particularly trying to write EF.PLMNSEL, EF.FPLMN, and EF.{O,H,}PLMNwACT on some US-carrier SIMs. This seems to be worse in the ones from AT&T MVNOs (I've tried ones from Red Pocket and H2O). Generally, the write just fails; but I believe I've observed some EFs get reset after a successful write/read. Are you getting a valid response from the UPDATE BINARY command? Unfortunately, I haven't found a reasonable workaround for this. One ugly hack that seemed to work with some SIMs on an HTC One V (a recent Android phone ), is "priming" the SIM by first registering to the network using a old Nokia 3310 or similar; the connected data is stored on the SIM (EF.LOCI, I imagine? I actually never figured out why this worked.) and is good for a one-time use in the smartphone. Writable or custom SIMs are reasonably inexpensive, so for anything over a handful of devices in a test network (with manual network selection), that's probably the way to go.. Are you operating as MCC=001 MNC=01 (test network)? (Apologies to the list if this is the wrong venue for this.) On Fri, Sep 7, 2012 at 8:15 AM, Dario Lombardo wrote: > Hil list > Today I've observed a strange behaviour when modifying the PNLM of > some real networks expired sims (to be used with osmocom and openbts). > I've put 001 01 on the top of the list. I've ejected and reinsterted > the sim in the reader many times, and I'm sure that the value has been > wrtitten. > When trying to connect to my test operator I get the message "your sim > card doesn't allow the connection to this network operator" from my > android phone. > Reading again the pnlm I see that the original list has been restored. > This astonishes me... Is is possible that the SIM overwrites the list > by itselt? Or is it the phone that does it? The android has an > original, not branded, operating system. > Thanks everybody for your help. > Dario > From dario.lombardo.ml at gmail.com Fri Sep 7 21:12:45 2012 From: dario.lombardo.ml at gmail.com (Dario Lombardo) Date: Fri, 7 Sep 2012 23:12:45 +0200 Subject: PNLM list overwritten In-Reply-To: References: Message-ID: On Fri, Sep 7, 2012 at 6:02 PM, Brandon Creighton wrote: > I've seen similar behavior before -- particularly trying to write > EF.PLMNSEL, EF.FPLMN, and EF.{O,H,}PLMNwACT on some US-carrier SIMs. > > This seems to be worse in the ones from AT&T MVNOs (I've tried ones > from Red Pocket and H2O). Generally, the write just fails; but I > believe I've observed some EFs get reset after a successful > write/read. Are you getting a valid response from the UPDATE BINARY > command? > My software doesn't give me any error. Unplugging and replugging the sim gives me good feedback: the test operator is still on the top of the plnm. > Unfortunately, I haven't found a reasonable workaround for this. One > ugly hack that seemed to work with some SIMs on an HTC One V (a recent > Android phone ), is "priming" the SIM by first registering to the > network using a old Nokia 3310 or similar; the connected data is > stored on the SIM (EF.LOCI, I imagine? I actually never figured out > why this worked.) and is good for a one-time use in the smartphone. > > Writable or custom SIMs are reasonably inexpensive, so for anything > over a handful of devices in a test network (with manual network > selection), that's probably the way to go.. > I tried to used expired sims because I have loads of them... :) > Are you operating as MCC=001 MNC=01 (test network)? > Yes. > (Apologies to the list if this is the wrong venue for this.) > > > On Fri, Sep 7, 2012 at 8:15 AM, Dario Lombardo > wrote: >> Hil list >> Today I've observed a strange behaviour when modifying the PNLM of >> some real networks expired sims (to be used with osmocom and openbts). >> I've put 001 01 on the top of the list. I've ejected and reinsterted >> the sim in the reader many times, and I'm sure that the value has been >> wrtitten. >> When trying to connect to my test operator I get the message "your sim >> card doesn't allow the connection to this network operator" from my >> android phone. >> Reading again the pnlm I see that the original list has been restored. >> This astonishes me... Is is possible that the SIM overwrites the list >> by itselt? Or is it the phone that does it? The android has an >> original, not branded, operating system. >> Thanks everybody for your help. >> Dario >> From ml at mail.tsaitgaist.info Sat Sep 8 16:21:52 2012 From: ml at mail.tsaitgaist.info (Kevin Redon) Date: Sat, 08 Sep 2012 18:21:52 +0200 Subject: PNLM list overwritten In-Reply-To: References: Message-ID: <1347120850-sup-2621@dennou> Hi, Curious, but I tested it and also came to the same conclusion (with a current vodafone card). The changes on PLMNsel are not stored permanently. On the next power up, the SIM will rewrite this file. Here some code to test it: https://www.tsaitgaist.info/private/plmn.tar.xz The source is open (it uses libpcsc), but only use it to verify the results (e.g. not distributing it), as the code is not yet ready to be published (the file will be removed in 2 days). have fun, kevin Excerpts from Dario Lombardo's message of Fri Sep 07 23:12:45 +0200 2012: > On Fri, Sep 7, 2012 at 6:02 PM, Brandon Creighton wrote: > > I've seen similar behavior before -- particularly trying to write > > EF.PLMNSEL, EF.FPLMN, and EF.{O,H,}PLMNwACT on some US-carrier SIMs. > > > > This seems to be worse in the ones from AT&T MVNOs (I've tried ones > > from Red Pocket and H2O). Generally, the write just fails; but I > > believe I've observed some EFs get reset after a successful > > write/read. Are you getting a valid response from the UPDATE BINARY > > command? > > > > My software doesn't give me any error. Unplugging and replugging the > sim gives me good feedback: the test operator is still on the top of > the plnm. > > > Unfortunately, I haven't found a reasonable workaround for this. One > > ugly hack that seemed to work with some SIMs on an HTC One V (a recent > > Android phone ), is "priming" the SIM by first registering to the > > network using a old Nokia 3310 or similar; the connected data is > > stored on the SIM (EF.LOCI, I imagine? I actually never figured out > > why this worked.) and is good for a one-time use in the smartphone. > > > > Writable or custom SIMs are reasonably inexpensive, so for anything > > over a handful of devices in a test network (with manual network > > selection), that's probably the way to go.. > > > > I tried to used expired sims because I have loads of them... :) > > > Are you operating as MCC=001 MNC=01 (test network)? > > > > Yes. > > > (Apologies to the list if this is the wrong venue for this.) > > > > > > On Fri, Sep 7, 2012 at 8:15 AM, Dario Lombardo > > wrote: > >> Hil list > >> Today I've observed a strange behaviour when modifying the PNLM of > >> some real networks expired sims (to be used with osmocom and openbts). > >> I've put 001 01 on the top of the list. I've ejected and reinsterted > >> the sim in the reader many times, and I'm sure that the value has been > >> wrtitten. > >> When trying to connect to my test operator I get the message "your sim > >> card doesn't allow the connection to this network operator" from my > >> android phone. > >> Reading again the pnlm I see that the original list has been restored. > >> This astonishes me... Is is possible that the SIM overwrites the list > >> by itselt? Or is it the phone that does it? The android has an > >> original, not branded, operating system. > >> Thanks everybody for your help. > >> Dario > >> From dario.lombardo.ml at gmail.com Mon Sep 10 07:52:44 2012 From: dario.lombardo.ml at gmail.com (Dario Lombardo) Date: Mon, 10 Sep 2012 09:52:44 +0200 Subject: PNLM list overwritten In-Reply-To: <1347120850-sup-2621@dennou> References: <1347120850-sup-2621@dennou> Message-ID: On Sat, Sep 8, 2012 at 6:21 PM, Kevin Redon wrote: > Hi, > > Curious, but I tested it and also came to the same conclusion (with a current vodafone card). > The changes on PLMNsel are not stored permanently. On the next power up, the SIM will rewrite this file. That's not exactly what I observed. Powering up the card in a card reader, I checked that the list is modified. But putting it into a cell phone, I found it restored. > Here some code to test it: https://www.tsaitgaist.info/private/plmn.tar.xz > The source is open (it uses libpcsc), but only use it to verify the results (e.g. not distributing it), as the code is not yet ready to be published (the file will be removed in 2 days). > Going to test it. Do you know open source suites for sim card management? The most complete one I know is from Dekart, but is for win and commercial/closed. Anything useful for open source/unix world? From ml at mail.tsaitgaist.info Mon Sep 10 10:14:14 2012 From: ml at mail.tsaitgaist.info (Kevin Redon) Date: Mon, 10 Sep 2012 12:14:14 +0200 Subject: PNLM list overwritten In-Reply-To: References: <1347120850-sup-2621@dennou> Message-ID: <1347271449-sup-6987@dennou> Hi, Excerpts from Dario Lombardo's message of Mon Sep 10 09:52:44 +0200 2012: > On Sat, Sep 8, 2012 at 6:21 PM, Kevin Redon wrote: > > Hi, > > > > Curious, but I tested it and also came to the same conclusion (with a current vodafone card). > > The changes on PLMNsel are not stored permanently. On the next power up, the SIM will rewrite this file. > > That's not exactly what I observed. Powering up the card in a card > reader, I checked that the list is modified. But putting it into a > cell phone, I found it restored. Ok. I tested more sim cards and found different behaviours: - Vodafone (germany) + Vodafone CallYA: rewrites EF_PLMNsel at every power up - SFR: rewrites EF_PLMNsel at every power up - universal (bouygues): does not rewrite EF_PLMNsel, even in the phone (card not active/can not connect to network anymore) - virgin mobile (orange franche): does not rewrite EF_PLMNsel, even in the phone (card not active/can not connect to network anymore) - O2 prepaid: does not rewrite EF_PLMNsel at boot, but rewrites in the phone (card not active/can not connect to network anymore) - O2 loop (older): does not rewrite EF_PLMNsel, even in the phone. card did connect to the network. I used a Motorols C121 as phone. I will try SIMtrace on the o2 prepaid card to see what is happening and check if the phone rewrites it, or the SIM card does it itself (due to some sequence of instructions). > > > Here some code to test it: https://www.tsaitgaist.info/private/plmn.tar.xz > > The source is open (it uses libpcsc), but only use it to verify the results (e.g. not distributing it), as the code is not yet ready to be published (the file will be removed in 2 days). > > > > Going to test it. Do you know open source suites for sim card > management? The most complete one I know is from Dekart, but is for > win and commercial/closed. Anything useful for open source/unix world? No, I don't know any tool. That is why I wrote it myself. kevin From ml at mail.tsaitgaist.info Mon Sep 10 14:23:49 2012 From: ml at mail.tsaitgaist.info (Kevin Redon) Date: Mon, 10 Sep 2012 16:23:49 +0200 Subject: PNLM list overwritten In-Reply-To: <1347271449-sup-6987@dennou> References: <1347120850-sup-2621@dennou> <1347271449-sup-6987@dennou> Message-ID: <1347286655-sup-596@dennou> Hi, Excerpts from Kevin Redon's message of Mon Sep 10 12:14:14 +0200 2012: > Hi, > > I will try SIMtrace on the o2 prepaid card to see what is happening and check if the phone rewrites it, or the SIM card does it itself (due to some sequence of instructions). I looked at the traffic using SIMtrace and the O2 prepaid SIM card. PLMNsel is already rewritten when the phone (Motorala C121) reads it for the first time. The phone does not write anything up to that point. I think the rewrite to default is triggered when a particular file is read, but this is just a guess as I did not test it myself. It could also be due to a sequence a commands, or something else. At least we know something curious is happening with PLMNsel. hope it helps, kevin From Max.Suraev at fairwaves.ru Tue Sep 11 15:13:37 2012 From: Max.Suraev at fairwaves.ru (=?UTF-8?B?4piO?=) Date: Tue, 11 Sep 2012 17:13:37 +0200 Subject: [PATCH] fix libosmocore build with dpkg-buildpackage Message-ID: <504F5521.8050607@fairwaves.ru> Hello. Attached is a trivial patch to make dpkg-buildpackage -rfakeroot -uc -us work out of the box. Tested on ubuntu 12.04 x86_64 but should work on any debian-based distro. -- best regards, Max, http://fairwaves.ru From Max.Suraev at fairwaves.ru Tue Sep 11 15:08:13 2012 From: Max.Suraev at fairwaves.ru (Max) Date: Tue, 11 Sep 2012 17:08:13 +0200 Subject: [PATCH] Fix build with dpkg-buildpackage. Message-ID: --- .gitignore | 10 ++++++++++ debian/libosmocore.install | 1 + 2 files changed, 11 insertions(+) diff --git a/.gitignore b/.gitignore index 0bc78eb..3dc916b 100644 --- a/.gitignore +++ b/.gitignore @@ -31,6 +31,16 @@ Doxyfile.gsm Doxyfile.vty Doxyfile.codec +debian/autoreconf.after +debian/autoreconf.before +debian/files +debian/libosmocore-dev/ +debian/libosmocore*.log +debian/tmp/ +debian/libosmocore*.substvars +debian/libosmocore/ +debian/libosmocore.post*.debhelper + .tarball-version .version diff --git a/debian/libosmocore.install b/debian/libosmocore.install index d0dbfd1..9330260 100644 --- a/debian/libosmocore.install +++ b/debian/libosmocore.install @@ -1 +1,2 @@ usr/lib/lib*.so.* +usr/share/doc/libosmocore/* -- 1.7.9.5 --------------010904040907040604020505-- From laforge at gnumonks.org Mon Sep 17 06:37:28 2012 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 17 Sep 2012 08:37:28 +0200 Subject: [PATCH] fix libosmocore build with dpkg-buildpackage In-Reply-To: <504F5521.8050607@fairwaves.ru> References: <504F5521.8050607@fairwaves.ru> Message-ID: <20120917063728.GA3968@prithivi.gnumonks.org> Hi Max, On Tue, Sep 11, 2012 at 05:13:37PM +0200, ? wrote: > Attached is a trivial patch to make > dpkg-buildpackage -rfakeroot -uc -us > work out of the box. thanks, applied. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From maciej.grela at gmail.com Sun Sep 16 18:58:24 2012 From: maciej.grela at gmail.com (Maciej Grela) Date: Sun, 16 Sep 2012 18:58:24 +0000 Subject: [PATCH] build: Fix make rule for building crc%gen.h Message-ID: The current rule for building a directory for crc%gen.h uses $(notdir $@) causing a build error: make[3]: Entering directory `/home/enki/devel/tst/osmocom-bb/src/shared/libosmocore/build-target/include' /usr/bin/mkdir -p crc16gen.h sed -e's/XX/16/g' ../../include/osmocom/core/crcXXgen.h.tpl > osmocom/core/crc16gen.h Changed to use $(dir $@) which makes more sense when calling mkdir. Signed-off-by: Maciej Grela --- src/shared/libosmocore/include/Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/shared/libosmocore/include/Makefile.am b/src/shared/libosmocore/include/Makefile.am index dec8eac..2c5fb3e 100644 --- a/src/shared/libosmocore/include/Makefile.am +++ b/src/shared/libosmocore/include/Makefile.am @@ -99,5 +99,5 @@ endif noinst_HEADERS = osmocom/core/timer_compat.h osmocom/core/crc%gen.h: osmocom/core/crcXXgen.h.tpl - $(AM_V_GEN)$(MKDIR_P) $(notdir $@) + $(AM_V_GEN)$(MKDIR_P) $(dir $@) $(AM_V_GEN)sed -e's/XX/$*/g' $< > $@ -- 1.7.12 From Max.Suraev at fairwaves.ru Mon Sep 17 12:44:32 2012 From: Max.Suraev at fairwaves.ru (=?UTF-8?B?4piO?=) Date: Mon, 17 Sep 2012 14:44:32 +0200 Subject: [PATCH] build: Fix make rule for building crc%gen.h In-Reply-To: References: Message-ID: <50571B30.8060409@fairwaves.ru> 16.09.2012 20:58, Maciej Grela ?????: > The current rule for building a directory for crc%gen.h uses $(notdir > $@) causing a build error: I think I've experienced this error while building osmocom-bb today. Until this patch merged into mainline the following workaround might help: cd src/shared/libosmocore ./configure make distclean cd ../.. make -- best regards, Max, http://fairwaves.ru From dodegkr at gmail.com Mon Sep 17 15:18:44 2012 From: dodegkr at gmail.com (Dave Davies) Date: Mon, 17 Sep 2012 16:18:44 +0100 Subject: [PATCH] build: Fix make rule for building crc%gen.h In-Reply-To: <50571B30.8060409@fairwaves.ru> References: <50571B30.8060409@fairwaves.ru> Message-ID: fresh pull and build fails, is this related at all as I have installed many times before ? http://pastebin.com/GTbJjd8y Dave On 17 September 2012 13:44, ? wrote: > 16.09.2012 20:58, Maciej Grela ?????: >> The current rule for building a directory for crc%gen.h uses $(notdir >> $@) causing a build error: > > I think I've experienced this error while building osmocom-bb today. > Until this patch merged into mainline the following workaround might help: > > cd src/shared/libosmocore > ./configure > make distclean > cd ../.. > make > > -- > best regards, > Max, http://fairwaves.ru > From dario.lombardo.ml at gmail.com Mon Sep 17 15:23:29 2012 From: dario.lombardo.ml at gmail.com (Dario Lombardo) Date: Mon, 17 Sep 2012 17:23:29 +0200 Subject: [PATCH] build: Fix make rule for building crc%gen.h In-Reply-To: References: <50571B30.8060409@fairwaves.ru> Message-ID: Works for me applying this patch diff --git a/src/shared/libosmocore/include/Makefile.am b/src/shared/libosmocore/include/Makefile.am index dec8eac..2c5fb3e 100644 --- a/src/shared/libosmocore/include/Makefile.am +++ b/src/shared/libosmocore/include/Makefile.am @@ -99,5 +99,5 @@ endif noinst_HEADERS = osmocom/core/timer_compat.h osmocom/core/crc%gen.h: osmocom/core/crcXXgen.h.tpl - $(AM_V_GEN)$(MKDIR_P) $(notdir $@) + $(AM_V_GEN)$(MKDIR_P) $(dir $@) $(AM_V_GEN)sed -e's/XX/$*/g' $< > $@ and then >> cd src/shared/libosmocore >> ./configure >> make distclean >> cd ../.. >> make On Mon, Sep 17, 2012 at 5:18 PM, Dave Davies wrote: > fresh pull and build fails, is this related at all as I have installed > many times before ? > > http://pastebin.com/GTbJjd8y > > Dave > > > On 17 September 2012 13:44, ? wrote: >> 16.09.2012 20:58, Maciej Grela ?????: >>> The current rule for building a directory for crc%gen.h uses $(notdir >>> $@) causing a build error: >> >> I think I've experienced this error while building osmocom-bb today. >> Until this patch merged into mainline the following workaround might help: >> >> cd src/shared/libosmocore >> ./configure >> make distclean >> cd ../.. >> make >> >> -- >> best regards, >> Max, http://fairwaves.ru >> > From Max.Suraev at fairwaves.ru Mon Sep 17 15:25:07 2012 From: Max.Suraev at fairwaves.ru (=?UTF-8?B?4piO?=) Date: Mon, 17 Sep 2012 17:25:07 +0200 Subject: [PATCH] build: Fix make rule for building crc%gen.h In-Reply-To: References: <50571B30.8060409@fairwaves.ru> Message-ID: <505740D3.6030306@fairwaves.ru> 17.09.2012 17:18, Dave Davies ?????: > fresh pull and build fails, is this related at all as I have installed > many times before ? > My case exactly. Have you tried the workaround? -- best regards, Max, http://fairwaves.ru From maciej.grela at gmail.com Sun Sep 16 21:39:30 2012 From: maciej.grela at gmail.com (Maciej Grela) Date: Sun, 16 Sep 2012 21:39:30 +0000 Subject: Location update problems on Motorola C118 Message-ID: Hi, I'm trying to run the latest osmocom-bb git on a Motorola C118 phone. After a minor problem with the build (as you may've noticed in the patch I've sent). I got to the point of successfuly running layer1 on the phone and the mobile app on the PC (I have also enabled TX). The process seems to be stuck on trying to perform a location update. The status of the ms is always either: show ms MS '1' is up, MM connection active IMEI: 000000000000000 IMEISV: 0000000000000000 IMEI generation: fixed automatic network selection state: A1 trying RPLMN MCC=104 MNC=002 (104, 002) cell selection state: connected mode 1 ARFCN=19 MCC=104 MNC=002 LAC=0xb00f CELLID=0x4fd9 (104, 002) radio ressource layer state: connection pending mobility management layer state: wait for RR connection (location updating) OsmocomBB> or show ms MS '1' is up, service is limited (pending) IMEI: 000000000000000 IMEISV: 0000000000000000 IMEI generation: fixed automatic network selection state: A1 trying RPLMN MCC=104 MNC=002 (104, 002) cell selection state: C3 camped normally ARFCN=19 MCC=104 MNC=002 LAC=0xb00f CELLID=0x4fd9 (104, 002) radio ressource layer state: idle mobility management layer state: MM idle, attempting to update OsmocomBB> I think, that because of this I can't make any calls or send sms (all the requests are being rejected): OsmocomBB# call 1 call 1 OsmocomBB# % (MS 1) % Call has been rejected The log information from mobile when it's trying to do a location update is show below: <000b> gsm48_rr.c:2174 PAGING REQUEST 1 <000b> gsm48_rr.c:2141 IMSI 260021964220249 (not for us) <000b> gsm48_rr.c:2132 TMSI fd82a501 (not for us) <000e> gsm48_mm.c:344 Location update retry <0005> gsm48_mm.c:345 timer T3211 (loc. upd. retry delay) has fired <0005> gsm48_mm.c:4311 (ms 1) Received 'MM_EVENT_TIMEOUT_T3211' event in state MM IDLE, attempting to update <000e> gsm48_mm.c:2199 Perform location update (MCC 104, MNC 002 LAC 0xb00f) <0005> gsm48_mm.c:2333 LOCATION UPDATING REQUEST <0005> gsm48_mm.c:2355 using LAI (mcc 104 mnc 002 lac 0xb00f) <0005> gsm48_mm.c:2363 using TMSI 0x28a3d62e <0005> gsm48_mm.c:914 new state MM IDLE, attempting to update -> wait for RR connection (location updating) <0001> gsm48_rr.c:5428 (ms 1) Message 'RR_EST_REQ' received in state idle (sapi 0) <000e> gsm48_rr.c:1318 Establish radio link due to mobility management request <0003> gsm322.c:4037 (ms 1) Event 'EVENT_LEAVE_IDLE' for Cell selection in state 'C3 camped normally' <0003> gsm322.c:823 new state 'C3 camped normally' -> 'connected mode 1' <0003> gsm322.c:3653 Going to camping (normal) ARFCN 19. <0003> gsm322.c:463 Sync to ARFCN=19 rxlev=-74 (Sysinfo, ccch mode NON-COMB) <0001> gsm48_rr.c:366 new state idle -> connection pending <0001> gsm48_rr.c:1465 CHANNEL REQUEST: 00 (Location Update with NECI) <0003> gsm322.c:2938 Channel synched. (ARFCN=19, snr=16, BSIC=17) <0001> gsm322.c:2959 using DSC of 90 <0003> gsm48_rr.c:4816 Channel provides data. <0001> gsm48_rr.c:1601 RANDOM ACCESS (requests left 5) <0001> gsm48_rr.c:1658 RANDOM ACCESS (Tx-integer 50 combined no S(lots) 0 ra 0x0e) <0001> gsm48_rr.c:1697 Use MS-TXPWR-MAX-CCH power value 5 (33 dBm) <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:1601 RANDOM ACCESS (requests left 4) <0001> gsm48_rr.c:1658 RANDOM ACCESS (Tx-integer 50 combined no S(lots) 55 ra 0x07) <0001> gsm48_rr.c:1697 Use MS-TXPWR-MAX-CCH power value 5 (33 dBm) <0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT: <0001> gsm48_rr.c:2462 (ta 2/1107m ra 0x75 chan_nr 0x0a MAIO 0 HSN 38 TS 2 SS 0 TSC 0) <0001> gsm48_rr.c:2503 Request, but not for us. <0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT: <0001> gsm48_rr.c:2462 (ta 2/1107m ra 0x75 chan_nr 0x0a MAIO 0 HSN 38 TS 2 SS 0 TSC 0) <0001> gsm48_rr.c:2503 Request, but not for us. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:673 MON: f=19 lev=-78 snr= 0 ber= 0 LAI=104 002 b00f ID=4fd9 <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:1601 RANDOM ACCESS (requests left 3) <0001> gsm48_rr.c:1658 RANDOM ACCESS (Tx-integer 50 combined no S(lots) 55 ra 0x0f) <0001> gsm48_rr.c:1697 Use MS-TXPWR-MAX-CCH power value 5 (33 dBm) <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:1601 RANDOM ACCESS (requests left 2) <0001> gsm48_rr.c:1658 RANDOM ACCESS (Tx-integer 50 combined no S(lots) 55 ra 0x01) <0001> gsm48_rr.c:1697 Use MS-TXPWR-MAX-CCH power value 5 (33 dBm) <0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT: <0001> gsm48_rr.c:2473 (ta 1/553m ra 0x18 chan_nr 0x59 ARFCN 19 TS 1 SS 3 TSC 1) <0001> gsm48_rr.c:2503 Request, but not for us. <0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT: <0001> gsm48_rr.c:2473 (ta 1/553m ra 0x18 chan_nr 0x59 ARFCN 19 TS 1 SS 3 TSC 1) <0001> gsm48_rr.c:2503 Request, but not for us. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:1601 RANDOM ACCESS (requests left 1) <0001> gsm48_rr.c:1658 RANDOM ACCESS (Tx-integer 50 combined no S(lots) 55 ra 0x0a) <0001> gsm48_rr.c:1697 Use MS-TXPWR-MAX-CCH power value 5 (33 dBm) <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:673 MON: f=19 lev=-78 snr= 0 ber= 1 LAI=104 002 b00f ID=4fd9 <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:1601 RANDOM ACCESS (requests left 0) <0001> gsm48_rr.c:1605 Done with sending RANDOM ACCESS bursts <0001> gsm48_rr.c:836 starting T3126 with 5.000 seconds <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2225 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:673 MON: f=19 lev=-78 snr= 0 ber= 0 LAI=104 002 b00f ID=4fd9 <0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT: <0001> gsm48_rr.c:2473 (ta 2/1107m ra 0x0a chan_nr 0x41 ARFCN 19 TS 1 SS 0 TSC 1) <0001> gsm48_rr.c:2393 request 0a matches but not frame number (IMM.ASS fn=22,6,30 != RACH fn=22,5,25) <0001> gsm48_rr.c:2503 Request, but not for us. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT: <0001> gsm48_rr.c:2473 (ta 2/1107m ra 0x05 chan_nr 0x49 ARFCN 19 TS 1 SS 1 TSC 1) <0001> gsm48_rr.c:2503 Request, but not for us. <0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT: <0001> gsm48_rr.c:2473 (ta 2/1107m ra 0x05 chan_nr 0x49 ARFCN 19 TS 1 SS 1 TSC 1) <0001> gsm48_rr.c:2503 Request, but not for us. <0001> gsm48_rr.c:2225 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:673 MON: f=19 lev=-77 snr= 0 ber= 6 LAI=104 002 b00f ID=4fd9 <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT: <0001> gsm48_rr.c:2473 (ta 2/1107m ra 0x00 chan_nr 0x61 ARFCN 19 TS 1 SS 4 TSC 1) <0001> gsm48_rr.c:2503 Request, but not for us. <0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT: <0001> gsm48_rr.c:2473 (ta 2/1107m ra 0x00 chan_nr 0x61 ARFCN 19 TS 1 SS 4 TSC 1) <0001> gsm48_rr.c:2503 Request, but not for us. <0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT: <0001> gsm48_rr.c:2462 (ta 2/1107m ra 0x7d chan_nr 0x0b MAIO 0 HSN 38 TS 3 SS 0 TSC 0) <0001> gsm48_rr.c:2503 Request, but not for us. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT: <0001> gsm48_rr.c:2462 (ta 2/1107m ra 0x7d chan_nr 0x0b MAIO 0 HSN 38 TS 3 SS 0 TSC 0) <0001> gsm48_rr.c:2503 Request, but not for us. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:673 MON: f=19 lev=-78 snr= 0 ber= 0 LAI=104 002 b00f ID=4fd9 <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2225 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2225 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:673 MON: f=19 lev=-78 snr= 0 ber= 3 LAI=104 002 b00f ID=4fd9 <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT: <0001> gsm48_rr.c:2462 (ta 2/1107m ra 0x77 chan_nr 0x09 MAIO 0 HSN 38 TS 1 SS 0 TSC 0) <0001> gsm48_rr.c:2503 Request, but not for us. <0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT: <0001> gsm48_rr.c:2462 (ta 2/1107m ra 0x77 chan_nr 0x09 MAIO 0 HSN 38 TS 1 SS 0 TSC 0) <0001> gsm48_rr.c:2503 Request, but not for us. <0001> gsm48_rr.c:2225 PAGING ignored, we are not camping. <0001> gsm48_rr.c:2170 PAGING ignored, we are not camping. <0001> gsm48_rr.c:673 MON: f=19 lev=-78 snr= 0 ber= 6 LAI=104 002 b00f ID=4fd9 <0001> gsm48_rr.c:765 timer T3126 has fired <000e> gsm48_rr.c:770 Requesting channel failed <0001> gsm48_rr.c:366 new state connection pending -> idle <0003> gsm322.c:4037 (ms 1) Event 'EVENT_RET_IDLE' for Cell selection in state 'connected mode 1' <0003> gsm322.c:3565 Selecting ARFCN 19. after LOC.UPD. <0003> gsm322.c:463 Sync to ARFCN=19 rxlev=-74 (Sysinfo, ccch mode NON-COMB) <0003> gsm322.c:823 new state 'connected mode 1' -> 'C3 camped normally' <0005> gsm48_mm.c:3902 (ms 1) Received 'RR_REL_IND' from RR in state wait for RR connection (location updating) (sapi 0) <0005> gsm48_mm.c:2732 RR link released after loc. upd. <000e> gsm48_mm.c:2676 Location update failed <000e> gsm48_mm.c:2686 Try location update later <0005> gsm48_mm.c:2688 Loc. upd. failed, retry #0 <0005> gsm48_mm.c:413 starting T3211 (loc. upd. retry delay) with 15.0 seconds <0005> gsm48_mm.c:1143 We are camping normally as returning to MM IDLE <0005> gsm48_mm.c:1159 Loc. upd. allowed. <0005> gsm48_mm.c:919 new state wait for RR connection (location updating) -> MM IDLE, location updating needed <0005> gsm48_mm.c:909 new MM IDLE state location updating needed -> attempting to update <0005> gsm48_mm.c:2215 Loc. upd. already pending. <0005> gsm48_mm.c:4311 (ms 1) Received 'MM_EVENT_CELL_SELECTED' event in state MM IDLE, attempting to update <0005> gsm48_mm.c:2215 Loc. upd. already pending. <0003> gsm322.c:2938 Channel synched. (ARFCN=19, snr=16, BSIC=17) <0001> gsm322.c:2959 using DSC of 90 Can you provide me any hints on how to debug this ? Why is the location update failing constantly ? Thanks in advance for your help. Best regards, Maciej Grela From 246tnt at gmail.com Sun Sep 16 21:45:39 2012 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 16 Sep 2012 23:45:39 +0200 Subject: Location update problems on Motorola C118 In-Reply-To: References: Message-ID: Hi, > I'm trying to run the latest osmocom-bb git on a Motorola C118 phone. > After a minor problem with the build (as you may've noticed in the > patch I've sent). I got to the point of successfuly running layer1 on > the phone and the mobile app on the PC (I have also enabled TX). 1) Where are you in the world ? 2) Are you _sure_ you enabled TX ? Did you check the layer 1 log doesn't say TX is disabled ? Cheers, Sylvain From maciej.grela at gmail.com Sun Sep 16 21:52:46 2012 From: maciej.grela at gmail.com (Maciej Grela) Date: Sun, 16 Sep 2012 21:52:46 +0000 Subject: Location update problems on Motorola C118 In-Reply-To: References: Message-ID: 2012/9/16 Sylvain Munaut <246tnt at gmail.com>: > Hi, > >> I'm trying to run the latest osmocom-bb git on a Motorola C118 phone. >> After a minor problem with the build (as you may've noticed in the >> patch I've sent). I got to the point of successfuly running layer1 on >> the phone and the mobile app on the PC (I have also enabled TX). > > 1) Where are you in the world ? Poland. > 2) Are you _sure_ you enabled TX ? Did you check the layer 1 log > doesn't say TX is disabled ? Yes, I'm sure. Here is the beginning of layer1 booting: >Received DOWNLOAD ACK from phone, your code is running now! battery_compal_e88_init: starting up OsmocomBB Layer 1 (revision osmocon_v0.0.0-1658-g6ce46e7-modified) ====================================================================== Device ID code: 0xb4fb Device Version code: 0x0000 ARM ID code: 0xfff3 cDSP ID code: 0x0128 Die ID code: 058d392b9c039bfc ====================================================================== REG_DPLL=0x2413 CNTL_ARM_CLK=0xf0a1 CNTL_CLK=0xff91 CNTL_RST=0xfff3 CNTL_ARM_DIV=0xfff9 ====================================================================== Power up simcard: Assert DSP into Reset Releasing DSP from Reset Setting some dsp_api.ndb values Setting API NDB parameters DSP Download Status: 0x0001 DSP API Version: 0x0000 0x0000 Finishing download phase DSP Download Status: 0x0002 DSP API Version: 0x3606 0x0000 LOST 7130! Best regards, Maciej Grela > Cheers, > > Sylvain > From maciej.grela at gmail.com Mon Sep 17 06:45:38 2012 From: maciej.grela at gmail.com (Maciej Grela) Date: Mon, 17 Sep 2012 06:45:38 +0000 Subject: Location update problems on Motorola C118 In-Reply-To: References: Message-ID: 2012/9/16 Sylvain Munaut <246tnt at gmail.com>: > Hi, > >> I'm trying to run the latest osmocom-bb git on a Motorola C118 phone. >> After a minor problem with the build (as you may've noticed in the >> patch I've sent). I got to the point of successfuly running layer1 on >> the phone and the mobile app on the PC (I have also enabled TX). > > 1) Where are you in the world ? > 2) Are you _sure_ you enabled TX ? Did you check the layer 1 log > doesn't say TX is disabled ? Also, fyi: 1. The phone works OK on the stock firmware. 2. I was able to successfuly make calls and send sms with osmocombb on this particular phone during haxogreen.lu in Luxemburg in August 2012. I don't remember which network I used then. Br, Maciej Grela From osmocom at ngolde.de Mon Sep 17 16:30:38 2012 From: osmocom at ngolde.de (Nico Golde) Date: Mon, 17 Sep 2012 18:30:38 +0200 Subject: [PATCH] gsm_utils.c: cleanup + do not use dynamic memory when decoding 7bit messages Message-ID: <20120917163038.GA1474@nybble.binarybase.org> Hi, attached is a patch that cleans up gsm_7bit_decode_hdr() a little and removes the need for calloc/free. This way, this function can be used on systems that do not have the required allocation routines (e.g. a layer1 firmware). This is a bit selfish, as I personally need it :) Cheers Nico From nico at ngolde.de Mon Sep 17 16:27:07 2012 From: nico at ngolde.de (Nico Golde) Date: Mon, 17 Sep 2012 18:27:07 +0200 Subject: [PATCH] gsm_utils.c: cleanup + do not use dynamic memory when decoding 7bit messages Message-ID: --- src/gsm/gsm_utils.c | 19 +++++++++---------- 1 file changed, 9 insertions(+), 10 deletions(-) diff --git a/src/gsm/gsm_utils.c b/src/gsm/gsm_utils.c index 3f3a73f..cf1cc2b 100644 --- a/src/gsm/gsm_utils.c +++ b/src/gsm/gsm_utils.c @@ -128,8 +128,8 @@ int gsm_7bit_decode_hdr(char *text, const uint8_t *user_data, uint8_t septet_l, int i = 0; int shift = 0; - uint8_t *rtext = calloc(septet_l, sizeof(uint8_t)); - uint8_t tmp; + uint8_t data[160]; + uint8_t ext_septet; /* skip the user data header */ if (ud_hdr_ind) { @@ -140,30 +140,29 @@ int gsm_7bit_decode_hdr(char *text, const uint8_t *user_data, uint8_t septet_l, septet_l = septet_l - shift; } - for (i = 0; i < septet_l; i++) { - rtext[i] = + for (i = 0; i < septet_l && i < sizeof(data); i++) { + data[i] = ((user_data[((i + shift) * 7 + 7) >> 3] << (7 - (((i + shift) * 7 + 7) & 7))) | (user_data[((i + shift) * 7) >> 3] >> (((i + shift) * 7) & 7))) & 0x7f; } - for (i = 0; i < septet_l; i++) { + for (i = 0; i < septet_l && i < sizeof(data); i++) { /* this is an extension character */ - if(rtext[i] == 0x1b && i + 1 < septet_l){ - tmp = rtext[i+1]; - *(text++) = gsm_7bit_alphabet[0x7f + tmp]; + if(data[i] == 0x1b && i + 1 < septet_l){ + ext_septet = data[i+1]; + *(text++) = gsm_7bit_alphabet[0x7f + ext_septet]; i++; continue; } - *(text++) = gsm_septet_lookup(rtext[i]); + *(text++) = gsm_septet_lookup(data[i]); } if (ud_hdr_ind) i += shift; *text = '\0'; - free(rtext); return i; } -- 1.7.10.4 --r5Pyd7+fXNt84Ff3-- From holger at freyther.de Mon Sep 17 21:40:34 2012 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 17 Sep 2012 23:40:34 +0200 Subject: [PATCH] gsm_utils.c: cleanup + do not use dynamic memory when decoding 7bit messages In-Reply-To: <20120917163038.GA1474@nybble.binarybase.org> References: <20120917163038.GA1474@nybble.binarybase.org> Message-ID: <20120917214034.GB1258@localhost> On Mon, Sep 17, 2012 at 06:30:38PM +0200, Nico Golde wrote: > This is a bit selfish, as I personally need it :) the best patches. :) > > Cheers > Nico > > > - uint8_t *rtext = calloc(septet_l, sizeof(uint8_t)); > - uint8_t tmp; > + uint8_t data[160]; > + uint8_t ext_septet; could you please add a check for septet_l >= sizeof(data) and log an error? I don't remember right now if we use this routine for USSD or not. From osmocom at ngolde.de Tue Sep 18 11:40:56 2012 From: osmocom at ngolde.de (Nico Golde) Date: Tue, 18 Sep 2012 13:40:56 +0200 Subject: [PATCH] gsm_utils.c: cleanup + do not use dynamic memory when decoding 7bit messages In-Reply-To: <20120917214034.GB1258@localhost> References: <20120917163038.GA1474@nybble.binarybase.org> <20120917214034.GB1258@localhost> Message-ID: <20120918114056.GA31040@nybble.binarybase.org> Hi, * Holger Hans Peter Freyther [2012-09-18 13:25]: > On Mon, Sep 17, 2012 at 06:30:38PM +0200, Nico Golde wrote: > > - uint8_t *rtext = calloc(septet_l, sizeof(uint8_t)); > > - uint8_t tmp; > > + uint8_t data[160]; > > + uint8_t ext_septet; > > > could you please add a check for septet_l >= sizeof(data) and log > an error? I don't remember right now if we use this routine for USSD > or not. New patch attached. Cheers Nico > From nico at ngolde.de Tue Sep 18 11:39:44 2012 From: nico at ngolde.de (Nico Golde) Date: Tue, 18 Sep 2012 13:39:44 +0200 Subject: [PATCH] gsm_utils.c: cleanup + do not use dynamic memory when decoding 7bit messages Message-ID: --- src/gsm/gsm_utils.c | 23 ++++++++++++++--------- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/src/gsm/gsm_utils.c b/src/gsm/gsm_utils.c index 3f3a73f..08932d1 100644 --- a/src/gsm/gsm_utils.c +++ b/src/gsm/gsm_utils.c @@ -2,7 +2,7 @@ * (C) 2008 by Daniel Willmann * (C) 2009 by Holger Hans Peter Freyther * (C) 2009-2010 by Harald Welte - * (C) 2010 by Nico Golde + * (C) 2010-2012 by Nico Golde * * All Rights Reserved * @@ -65,6 +65,7 @@ //#include #include #include +#include #include #include @@ -128,8 +129,8 @@ int gsm_7bit_decode_hdr(char *text, const uint8_t *user_data, uint8_t septet_l, int i = 0; int shift = 0; - uint8_t *rtext = calloc(septet_l, sizeof(uint8_t)); - uint8_t tmp; + uint8_t data[160]; + uint8_t ext_septet; /* skip the user data header */ if (ud_hdr_ind) { @@ -140,8 +141,13 @@ int gsm_7bit_decode_hdr(char *text, const uint8_t *user_data, uint8_t septet_l, septet_l = septet_l - shift; } + if(septet_l >= sizeof(data)){ + LOGP(DLSMS, LOGL_ERROR, + "Message User-Data too long\n"); + return -EINVAL; + } for (i = 0; i < septet_l; i++) { - rtext[i] = + data[i] = ((user_data[((i + shift) * 7 + 7) >> 3] << (7 - (((i + shift) * 7 + 7) & 7))) | (user_data[((i + shift) * 7) >> 3] >> @@ -150,20 +156,19 @@ int gsm_7bit_decode_hdr(char *text, const uint8_t *user_data, uint8_t septet_l, for (i = 0; i < septet_l; i++) { /* this is an extension character */ - if(rtext[i] == 0x1b && i + 1 < septet_l){ - tmp = rtext[i+1]; - *(text++) = gsm_7bit_alphabet[0x7f + tmp]; + if(data[i] == 0x1b && i + 1 < septet_l){ + ext_septet = data[i+1]; + *(text++) = gsm_7bit_alphabet[0x7f + ext_septet]; i++; continue; } - *(text++) = gsm_septet_lookup(rtext[i]); + *(text++) = gsm_septet_lookup(data[i]); } if (ud_hdr_ind) i += shift; *text = '\0'; - free(rtext); return i; } -- 1.7.10.4 --r5Pyd7+fXNt84Ff3-- From 246tnt at gmail.com Tue Sep 18 11:49:03 2012 From: 246tnt at gmail.com (Sylvain Munaut) Date: Tue, 18 Sep 2012 13:49:03 +0200 Subject: [PATCH] gsm_utils.c: cleanup + do not use dynamic memory when decoding 7bit messages In-Reply-To: <20120918114056.GA31040@nybble.binarybase.org> References: <20120917163038.GA1474@nybble.binarybase.org> <20120917214034.GB1258@localhost> <20120918114056.GA31040@nybble.binarybase.org> Message-ID: Hi, New patch attached. > I'm not a big fan of adding this limitation ... and linking to the log system as well. AFAICT there is nothing that prevents rewriting the algorithm itself to just not need a buffer at all. Cheers, Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From osmocom at ngolde.de Tue Sep 18 12:31:14 2012 From: osmocom at ngolde.de (Nico Golde) Date: Tue, 18 Sep 2012 14:31:14 +0200 Subject: [PATCH] gsm_utils.c: cleanup + do not use dynamic memory when decoding 7bit messages In-Reply-To: References: <20120917163038.GA1474@nybble.binarybase.org> <20120917214034.GB1258@localhost> <20120918114056.GA31040@nybble.binarybase.org> Message-ID: <20120918123114.GA11841@nybble.binarybase.org> Hi, * Sylvain Munaut <246tnt at gmail.com> [2012-09-18 13:52]: > > New patch attached. > > > > I'm not a big fan of adding this limitation ... and linking to the log > system as well. I agree. > AFAICT there is nothing that prevents rewriting the algorithm itself to > just not need a buffer at all. Attached is a rewritten patch that removes the buffer completely based on your input on IRC. Kind regards Nico From nico at ngolde.de Tue Sep 18 12:29:40 2012 From: nico at ngolde.de (Nico Golde) Date: Tue, 18 Sep 2012 14:29:40 +0200 Subject: [PATCH] gsm_utils.c: cleanup + do not use dynamic memory when decoding 7bit messages Message-ID: --- src/gsm/gsm_utils.c | 27 +++++++++++++-------------- 1 file changed, 13 insertions(+), 14 deletions(-) diff --git a/src/gsm/gsm_utils.c b/src/gsm/gsm_utils.c index 3f3a73f..f51cf1b 100644 --- a/src/gsm/gsm_utils.c +++ b/src/gsm/gsm_utils.c @@ -2,7 +2,7 @@ * (C) 2008 by Daniel Willmann * (C) 2009 by Holger Hans Peter Freyther * (C) 2009-2010 by Harald Welte - * (C) 2010 by Nico Golde + * (C) 2010-2012 by Nico Golde * * All Rights Reserved * @@ -127,9 +127,8 @@ int gsm_7bit_decode_hdr(char *text, const uint8_t *user_data, uint8_t septet_l, { int i = 0; int shift = 0; - - uint8_t *rtext = calloc(septet_l, sizeof(uint8_t)); - uint8_t tmp; + uint8_t c; + uint8_t next_is_ext = 0; /* skip the user data header */ if (ud_hdr_ind) { @@ -141,29 +140,29 @@ int gsm_7bit_decode_hdr(char *text, const uint8_t *user_data, uint8_t septet_l, } for (i = 0; i < septet_l; i++) { - rtext[i] = + c = ((user_data[((i + shift) * 7 + 7) >> 3] << (7 - (((i + shift) * 7 + 7) & 7))) | (user_data[((i + shift) * 7) >> 3] >> (((i + shift) * 7) & 7))) & 0x7f; - } - for (i = 0; i < septet_l; i++) { - /* this is an extension character */ - if(rtext[i] == 0x1b && i + 1 < septet_l){ - tmp = rtext[i+1]; - *(text++) = gsm_7bit_alphabet[0x7f + tmp]; - i++; + if(c == 0x1b && i + 1 < septet_l){ + next_is_ext = 1; continue; } - *(text++) = gsm_septet_lookup(rtext[i]); + /* this is an extension character */ + if(next_is_ext){ + next_is_ext = 0; + *(text++) = gsm_7bit_alphabet[0x7f + c]; + } else { + *(text++) = gsm_septet_lookup(c); + } } if (ud_hdr_ind) i += shift; *text = '\0'; - free(rtext); return i; } -- 1.7.10.4 --6TrnltStXW4iwmi0-- From laforge at gnumonks.org Thu Sep 20 07:59:14 2012 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 20 Sep 2012 09:59:14 +0200 Subject: [PATCH] gsm_utils.c: cleanup + do not use dynamic memory when decoding 7bit messages In-Reply-To: <20120918123114.GA11841@nybble.binarybase.org> References: <20120917163038.GA1474@nybble.binarybase.org> <20120917214034.GB1258@localhost> <20120918114056.GA31040@nybble.binarybase.org> <20120918123114.GA11841@nybble.binarybase.org> Message-ID: <20120920075914.GD15271@prithivi.gnumonks.org> Hi Nico, On Tue, Sep 18, 2012 at 02:31:14PM +0200, Nico Golde wrote: > Attached is a rewritten patch that removes the buffer > completely based on your input on IRC. thanks, merged. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From osmocom at ngolde.de Thu Sep 20 15:00:36 2012 From: osmocom at ngolde.de (Nico Golde) Date: Thu, 20 Sep 2012 17:00:36 +0200 Subject: [PATCH] gsm_utils.c: cleanup + do not use dynamic memory when decoding 7bit messages In-Reply-To: <20120920075914.GD15271@prithivi.gnumonks.org> References: <20120917163038.GA1474@nybble.binarybase.org> <20120917214034.GB1258@localhost> <20120918114056.GA31040@nybble.binarybase.org> <20120918123114.GA11841@nybble.binarybase.org> <20120920075914.GD15271@prithivi.gnumonks.org> Message-ID: <20120920150036.GA3804@nybble.binarybase.org> Hi, * Harald Welte [2012-09-20 16:08]: > On Tue, Sep 18, 2012 at 02:31:14PM +0200, Nico Golde wrote: > > Attached is a rewritten patch that removes the buffer > > completely based on your input on IRC. > > thanks, merged. Thanks! Sylvaint just pointed out another issue with the patch, the check for the last char being an extension char has to take precedence over the check for the extension char. Cheers Nico From nico at ngolde.de Thu Sep 20 14:56:23 2012 From: nico at ngolde.de (Nico Golde) Date: Thu, 20 Sep 2012 16:56:23 +0200 Subject: [PATCH] gsm_utils.c: in 7bit decoding, first check if the last character was an extension character before doing anything else Message-ID: --- src/gsm/gsm_utils.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/src/gsm/gsm_utils.c b/src/gsm/gsm_utils.c index 6af0a5f..8b1fae0 100644 --- a/src/gsm/gsm_utils.c +++ b/src/gsm/gsm_utils.c @@ -146,15 +146,15 @@ int gsm_7bit_decode_hdr(char *text, const uint8_t *user_data, uint8_t septet_l, (user_data[((i + shift) * 7) >> 3] >> (((i + shift) * 7) & 7))) & 0x7f; - if (c == 0x1b && i + 1 < septet_l) { - next_is_ext = 1; - continue; - } - /* this is an extension character */ if (next_is_ext) { next_is_ext = 0; *(text++) = gsm_7bit_alphabet[0x7f + c]; + continue; + } + + if (c == 0x1b && i + 1 < septet_l) { + next_is_ext = 1; } else { *(text++) = gsm_septet_lookup(c); } -- 1.7.10.4 --4Ckj6UjgE2iN1+kY-- From laforge at gnumonks.org Fri Sep 21 07:25:39 2012 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 21 Sep 2012 09:25:39 +0200 Subject: [PATCH] gsm_utils.c: cleanup + do not use dynamic memory when decoding 7bit messages In-Reply-To: <20120920150036.GA3804@nybble.binarybase.org> References: <20120917163038.GA1474@nybble.binarybase.org> <20120917214034.GB1258@localhost> <20120918114056.GA31040@nybble.binarybase.org> <20120918123114.GA11841@nybble.binarybase.org> <20120920075914.GD15271@prithivi.gnumonks.org> <20120920150036.GA3804@nybble.binarybase.org> Message-ID: <20120921072539.GH15271@prithivi.gnumonks.org> Hi Nico, On Thu, Sep 20, 2012 at 05:00:36PM +0200, Nico Golde wrote: > Thanks! Sylvaint just pointed out another issue with the > patch, the check for the last char being an extension char > has to take precedence over the check for the extension > char. merged in my local tree, will push when I'm next near some internet connection... -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From osmocom at ngolde.de Tue Sep 18 16:11:46 2012 From: osmocom at ngolde.de (Nico Golde) Date: Tue, 18 Sep 2012 18:11:46 +0200 Subject: [PATCH] build: fix directory creation for core headers, introduced by d471a219 Message-ID: <20120918161146.GA13945@nybble.binarybase.org> Attached is a patch for libosmocore that fixes the error mentioned in CABvrX2XCNRP+qhdW+b8eiWzCDJGVeC5vEaHfO3tOTsjaUg96Lw at mail.gmail.com. I guess this should be fixed in libosmocore and not osmocom-bb and the included shared library should be updated. Cheers Nico From nico at ngolde.de Tue Sep 18 16:07:57 2012 From: nico at ngolde.de (Nico Golde) Date: Tue, 18 Sep 2012 18:07:57 +0200 Subject: [PATCH] build: fix directory creation for core headers, introduced by d471a219. Message-ID: --- include/Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/Makefile.am b/include/Makefile.am index 61ab67d..60b9ea9 100644 --- a/include/Makefile.am +++ b/include/Makefile.am @@ -100,5 +100,5 @@ endif noinst_HEADERS = osmocom/core/timer_compat.h osmocom/core/crc%gen.h: osmocom/core/crcXXgen.h.tpl - $(AM_V_GEN)$(MKDIR_P) $(notdir $@) + $(AM_V_GEN)$(MKDIR_P) $(dir $@) $(AM_V_GEN)sed -e's/XX/$*/g' $< > $@ -- 1.7.10.4 --jRHKVT23PllUwdXP-- From laforge at gnumonks.org Tue Sep 18 17:49:25 2012 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 18 Sep 2012 19:49:25 +0200 Subject: Sept 19, 8pm / Osmocom Berlin User Group meeting Message-ID: <20120918174925.GL3968@prithivi.gnumonks.org> Hi all! This is the announcement for the next Osmocom Berlin meeting. Sept 19, 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, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From holger at freyther.de Wed Sep 19 17:48:15 2012 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Wed, 19 Sep 2012 19:48:15 +0200 Subject: Sept 19, 8pm / Osmocom Berlin User Group meeting In-Reply-To: <20120918174925.GL3968@prithivi.gnumonks.org> References: <20120918174925.GL3968@prithivi.gnumonks.org> Message-ID: <20120919174815.GG1258@localhost> On Tue, Sep 18, 2012 at 07:49:25PM +0200, Harald Welte wrote: > Hi all! Hi, I am not going to make it today, I hope some other Osmocom/CCC members will be present. sorry From pabftk at gmail.com Tue Sep 18 20:44:27 2012 From: pabftk at gmail.com (Pavel Baturko) Date: Tue, 18 Sep 2012 20:44:27 +0000 Subject: [PATCH] Decoding UCS2 USSD Message-ID: Hi, I create patch with added decoding of UCS2 USSD messages. Text in UCS2 is printed on 'mobile' console and status is sent to vty since there is no support of wide characters in vty. Added constants to decode GSM 7bit text when DCS is specified as 0x00, 0x01. I tested it with Russian language with several providers and all works ok. Thanks, Pavel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ussd-ucs2.patch Type: application/octet-stream Size: 11217 bytes Desc: not available URL: From holger at freyther.de Wed Sep 19 01:02:48 2012 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Wed, 19 Sep 2012 03:02:48 +0200 Subject: [PATCH] Decoding UCS2 USSD In-Reply-To: References: Message-ID: <20120919010248.GC25668@localhost> On Tue, Sep 18, 2012 at 08:44:27PM +0000, Pavel Baturko wrote: > Hi, > > I create patch with added decoding of UCS2 USSD messages. > Text in UCS2 is printed on 'mobile' console and status is sent to vty since > there is no support of wide characters in vty. > Added constants to decode GSM 7bit text when DCS is specified as 0x00, 0x01. > I tested it with Russian language with several providers and all works ok. Dear Pavel, thanks a lot for your patch. I think a library should not call setlocale as it will impact the entire application. I think our only other realistic option is to use iconv (and stub it out for osmocomBB). Do you think you could try to create such a patch? thanks holger From peter at stuge.se Wed Sep 19 02:12:57 2012 From: peter at stuge.se (Peter Stuge) Date: Wed, 19 Sep 2012 04:12:57 +0200 Subject: [PATCH] Decoding UCS2 USSD In-Reply-To: <20120919010248.GC25668@localhost> References: <20120919010248.GC25668@localhost> Message-ID: <20120919021257.14324.qmail@stuge.se> Holger Hans Peter Freyther wrote: > I think a library should not call setlocale as it will impact the > entire application. I think our only other realistic option is to > use iconv (and stub it out for osmocomBB). Do you think you could > try to create such a patch? I'd suggest http://www.lemoda.net/c/ucs2-to-utf8/ and simply output UTF-8. Maybe output an error if setlocal(LC_CTYPE,NULL) does not report that a UTF-8 locale is being used. //Peter From pabftk at gmail.com Wed Sep 19 21:49:29 2012 From: pabftk at gmail.com (Pavel Baturko) Date: Wed, 19 Sep 2012 21:49:29 +0000 Subject: [PATCH] Decoding UCS2 USSD In-Reply-To: <20120919021257.14324.qmail@stuge.se> References: <20120919010248.GC25668@localhost> <20120919021257.14324.qmail@stuge.se> Message-ID: Thanks for advises! New version: if received text in UCS2, convert it to UTF-8, then check if console supports UTF-8, if yes - print message in vty as usual, if not - print message in hex. ~Pavel On Wed, Sep 19, 2012 at 2:12 AM, Peter Stuge wrote: > Holger Hans Peter Freyther wrote: > > I think a library should not call setlocale as it will impact the > > entire application. I think our only other realistic option is to > > use iconv (and stub it out for osmocomBB). Do you think you could > > try to create such a patch? > > I'd suggest http://www.lemoda.net/c/ucs2-to-utf8/ and simply output > UTF-8. > > Maybe output an error if setlocal(LC_CTYPE,NULL) does not report that > a UTF-8 locale is being used. > > > //Peter > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ussd-ucs2.patch Type: application/octet-stream Size: 11256 bytes Desc: not available URL: From peter at stuge.se Thu Sep 20 10:00:19 2012 From: peter at stuge.se (Peter Stuge) Date: Thu, 20 Sep 2012 12:00:19 +0200 Subject: [PATCH] Decoding UCS2 USSD In-Reply-To: References: <20120919010248.GC25668@localhost> <20120919021257.14324.qmail@stuge.se> Message-ID: <20120920100019.21517.qmail@stuge.se> Thanks Harald for checking the license thing out, although I think the code is so trivial that it's difficult to claim copyright. Let's see. Thanks Pavel for the patch! I have some comments: Pavel Baturko wrote: > From 4fcf1f7afc29053833e524cc35c15dd57ebbbf64 Mon Sep 17 00:00:00 2001 > From: pab Please set the git config user.name and user.email options correctly: git config --global user.name 'Pavel Baturko' git config --global user.email your at email.here > Date: Thu, 20 Sep 2012 01:36:28 +0000 > Subject: [PATCH] Add USSD UCS2 support > > --- There is no commit message. I don't know why this would be OK. Please write a few relevant sentences about the change *in* the commit message, rather than in the email you send where you attach the commit message. The commit message is the correct place for the information, since that is the canonical storage facility for the code. The mailing list is not. > +++ b/src/host/layer23/src/mobile/gsm480_ss.c > @@ -24,6 +24,9 @@ > #include > #include > #include > +#include > +#include > +#include Are these files always guaranteed to be available, or are some configure.ac checks required in this change? > @@ -439,7 +442,7 @@ static int gsm480_tx_invoke(struct gsm_trans *trans, struct msgb *msg, > /* Pre-pend the invoke ID */ > msgb_push_TLV1(msg, GSM0480_COMPIDTAG_INVOKE_ID, trans->ss.invoke_id); > > - /* Wrap this up as invoke vomponent */ > + /* Wrap this up as invoke component */ > if (msg_type == GSM0480_MTYPE_FACILITY) > msgb_wrap_with_TL_asn(msg, GSM0480_CTYPE_RETURN_RESULT); > else > @@ -592,7 +595,7 @@ int ss_send(struct osmocom_ms *ms, const char *code, int new_trans) > LOGP(DSS, LOGL_INFO, "Existing transaction.\n"); > return gsm480_tx_ussd(trans, GSM0480_MTYPE_FACILITY, code); > } > - > + Please remove all unrelated changes from the commit. I am strongly in favor of cleaning up code, but it needs to be done in separate commits, not mixed in with other changes. Mixing changes makes life very difficult for anyone who might need to bisect the code. It is completely unneccessary. It's also really ugly. > @@ -751,14 +755,27 @@ static int gsm480_rx_ussd(struct gsm_trans *trans, const uint8_t *data, > LOGP(DSS, LOGL_NOTICE, "DSC tag too short\n"); > return -EINVAL; > } > + > if (data[0] != ASN1_OCTET_STRING_TAG || tag_len != 1) { > LOGP(DSS, LOGL_NOTICE, "Expecting DSC tag\n"); > return -EINVAL; > } > - if (tag_data[0] != 0x0f) { > - LOGP(DSS, LOGL_NOTICE, "DSC not 0x0f\n"); > - return -EINVAL; > + > + switch (tag_data[0]) > + { > + case DCS_GSM7DEAFULT: > + case DCS_GSM7DEAFULT2: > + case DCS_0f: > + dcs_charset = CGB_GEN_CHARSET7; > + break; I really like the kernel style for switch: switch (foo) { case BAR: case BAZ: quux(); break; } Ie. moving the opening brace, and using one less tab inside. > + default: > + LOGP(DSS, LOGL_NOTICE, "DSC <%d> unknown\n", tag_data[0]); > + return -EINVAL; > } > + > len -= tag_data - data + tag_len; > data = tag_data + tag_len; The added newline seems an unrelated change. > @@ -767,25 +784,81 @@ static int gsm480_rx_ussd(struct gsm_trans *trans, const uint8_t *data, > LOGP(DSS, LOGL_NOTICE, "Text tag too short\n"); > return -EINVAL; > } > + > if (data[0] != ASN1_OCTET_STRING_TAG) { > LOGP(DSS, LOGL_NOTICE, "Expecting text tag\n"); > return -EINVAL; > } The one above too. > - num_chars = tag_len * 8 / 7; > - /* Prevent a mobile-originated buffer-overrun! */ > - if (num_chars > sizeof(text) - 1) > - num_chars = sizeof(text) - 1; > - text[sizeof(text) - 1] = '\0'; > - gsm_7bit_decode(text, tag_data, num_chars); > - > - for (i = 0; text[i]; i++) { > - if (text[i] == '\r') > - text[i] = '\n'; > + > + if (dcs_charset == CGB_GEN_CHARSET7) > + { Please pay attention to the existing style in code that you work on, and make sure that you follow it exactly. You put the opening brace on the following line, while the rest of the code does not do this. In any case, please change this if (x == foo) else if (x == bar) code to use switch (). > + else if (dcs_charset == CGB_GEN_CHARSET16) > + { > + // USC2 charset, see ISO/IEC 10646 > + const char *curr_locale; > + uint8_t hex_or_str; // 1 - print string in utf-8, 0 -print raw hex The hex_or_str variable name is absolutely horrible. Please change it to something that also conveys the meaning of the value; something self-descriptive. One suggestion would be have_utf8_locale. > + int j = 0; > + > + num_chars = tag_len / 2; // since 1 char = 2 bytes This discards the last surplus byte if there is one. Good! > + // determine if console locale is UTF-8 and we can print message > + // if not - print raw hex UTF-8 data > + curr_locale = setlocale(LC_ALL, ""); Passing an empty string as locale is an invasive operation, which is why I suggested to pass NULL. Why do you use the empty string instead of NULL? > + hex_or_str = (strstr(curr_locale, "UTF-8")) ? 1 : 0; I'd suggest variable = strstr() != NULL; > + if (!hex_or_str) printf("Received USSD (UFT-8, hex):\n"); Three comments for a single line of code: First the style, I don't think that conditions and their code is on the same line anywhere else in the code. Following existing style. Second, I don't believe other parts of the code write directly to any file descriptors, but rather they all use logging macros. Follow existing style. Third, in the patch there are several occurences of the "UFT-8" typo. > + for (i = 0; i < num_chars; i++) { > + unsigned char utf8[4]; > + int ucs2, res; > + > + ucs2 = ((tag_data[2*i]<<8)|tag_data[2*i+1]); Look at how other code uses whitespace and follow existing style. > + res = ucs2_to_utf8(ucs2, utf8); I would either just include the code here, or write a new function which suits our purposes which converts the full string. > + if (res > 0) { > + if (hex_or_str) { > + memcpy(text+j, utf8, res); > + j += res; > + } > + else { > + int j; > + for (j=0; j + printf(" "); > + } > + } I still think printf() is not used anywhere else in the code. And the code makes absolutely no sense. In one case there is a memcpy(), in the other case there is printf(). Also, why is there a memcpy at all - please just write the data to the correct location in the first place. Always strive for zero copy. Thank you. > + if (hex_or_str) { > + text[j] = '\0'; > + } > + else { > + printf("\n"); > + sprintf(text, "USSD not printed(locale not UFT-8)"); > + } > + > + gsm480_ss_result(trans->ms, text, 0); Did you investigate if this function will handle UTF-8 data correctly? I sure don't know that. > @@ -935,6 +1008,7 @@ static int gsm480_rx_result(struct gsm_trans *trans, const uint8_t *data, > LOGP(DSS, LOGL_NOTICE, "Invoke ID too short\n"); > return -EINVAL; > } > + > if (data[0] != GSM0480_COMPIDTAG_INVOKE_ID || tag_len != 1) { > LOGP(DSS, LOGL_NOTICE, "Expecting invoke ID\n"); > return -EINVAL; This seems to be an unrelated change. > @@ -960,6 +1034,7 @@ static int gsm480_rx_result(struct gsm_trans *trans, const uint8_t *data, > LOGP(DSS, LOGL_NOTICE, "Sequence tag too short\n"); > return -EINVAL; > } > + > if (data[0] != GSM_0480_SEQUENCE_TAG) { > LOGP(DSS, LOGL_NOTICE, "Expecting Sequence Tag, trying " > "Operation Tag\n"); And this. > @@ -974,6 +1049,7 @@ operation: > LOGP(DSS, LOGL_NOTICE, "Operation too short\n"); > return -EINVAL; > } > + > if (data[0] != GSM0480_OPERATION_CODE || tag_len != 1) { > LOGP(DSS, LOGL_NOTICE, "Expecting Operation Code\n"); > return -EINVAL; And this. > @@ -1223,8 +1299,8 @@ static int gsm480_mmss_ind(int mmss_msg, struct gsm_trans *trans, > /* pull the MMSS header */ > msgb_pull(msg, sizeof(struct gsm48_mmxx_hdr)); > > - LOGP(DSS, LOGL_INFO, "(ms %s) Received est/data '%u'\n", ms->name, > - msg_type); > + LOGP(DSS, LOGL_INFO, "(ms %s) Received est/data '%u'='%X'\n", ms->name, > + msg_type, msg_type); > > switch (msg_type) { > case GSM0480_MTYPE_RELEASE_COMPLETE: And this. > +++ b/src/shared/libosmocore/include/osmocom/gsm/gsm_utils.h .. > @@ -143,9 +145,51 @@ enum gsm_chan_t { > GSM_LCHAN_TCH_H, > GSM_LCHAN_UNKNOWN, > GSM_LCHAN_CCCH, > - GSM_LCHAN_PDTCH, > _GSM_LCHAN_MAX > }; Seems unrelated. > +/* Data Coding Schemes (DCS), 23.038, 4 */ > +#define CGB_GEN 0x00 /* 00xxxxxxb, General Data Coding indication */ > +#define CGB_GEN_COM 0x20 /* xx1xxxxxb, text is uncompressed */ > +#define CGB_GEN_UNCOM 0x00 /* xx0xxxxxb, text is compressed (23.042) */ > +#define CGB_GEN_CLASS 0x10 /* xxx1xxxxb, bits 1 to 0 have a message class meaning */ > +#define CGB_GEN_NOCLASS 0x00 /* xxx0xxxxb, bits 1 to 0 are reserved and have no message class */ > +#define CGB_GEN_CLASS0 0x00 /* xxxxxx00b, Class 0 */ > +#define CGB_GEN_CLASS1 0x01 /* xxxxxx01b, Class 1, Default meaning: ME-specific */ > +#define CGB_GEN_CLASS2 0x02 /* xxxxxx10b, Class 2, (U)SIM specific message */ > +#define CGB_GEN_CLASS3 0x03 /* xxxxxx11b, Class 3, Default meaning: TE specific (27.005) */ > +#define CGB_GEN_CHARSET7 0x00 /* xxxx00xxb, GSM 7 bit default alphabet */ > +#define CGB_GEN_CHARSET8 0x04 /* xxxx01xxb, 8 bit data */ > +#define CGB_GEN_CHARSET16 0x08 /* xxxx10xxb, UCS2 (16bit) */ > +#define CGB_GEN_CHARSETR 0x0C /* xxxx11xxb, Reserved */ > + > +#define CGB_AUTODEL 0x40 /* 01xxxxxxb, Message Marked for Automatic Deletion Group */ > +#define CGB_RESERVED 0x8B /* 10001011b, Reserved */ > + > +#define CGB_MWI_DISC 0xC0 /* 1100xxxxb, Message Waiting Indication Group: Discard Message */ > +#define CGB_MWI_STOR 0xD0 /* 1101xxxxb, Message Waiting Indication Group: Store Message */ > +#define CGB_MWI_INACT 0x00 /* xxxx0xxxb, Set Indication Inactive */ > +#define CGB_MWI_ACT 0x08 /* xxxx1xxxb, Set Indication Active */ > +#define CGB_MWI_RESERVED 0x00 /* xxxxx0xxb, Reserved */ > +#define CGB_MWI_VMAIL 0x00 /* xxxxxx00b, Voicemail Message Waiting */ > +#define CGB_MWI_FAX 0x01 /* xxxxxx01b, Fax Message Waiting */ > +#define CGB_MWI_EMAIL 0x02 /* xxxxxx10b, Electronic Mail Message Waiting */ > +#define CGB_MWI_OTHER 0x03 /* xxxxxx11b, Other Message Waiting */ > +#define CGB_MWI_STOR2 0xE0 /* 1110xxxxb, as CGB_MWI_STOR, but text in UCS2 */ > + > +#define CGB_DCMC 0xF0 /* 1111xxxxb, Data coding/message class */ > +#define CGB_DCMC_RESERVED 0x08 /* xxxx0xxxb, Reserved */ > +#define CGB_DCMC_ALPH7 0x00 /* xxxxx0xxb, GSM 7 bit default alphabet */ > +#define CGB_DCMC_ALPH8 0x04 /* xxxxx0xxb, 8 bit alphabet */ > + > +/* Default 7 bit GSM */ > +#define DCS_GSM7DEAFULT (CGB_GEN | CGB_GEN_UNCOM | CGB_GEN_NOCLASS | CGB_GEN_CHARSET7) > +/* As default, but last bit is 1. > + * It makes no sense but some providers sends this type of DCS */ > +#define DCS_GSM7DEAFULT2 (CGB_GEN | CGB_GEN_UNCOM | CGB_GEN_NOCLASS | CGB_GEN_CHARSET7 | CGB_GEN_CLASS1) > +/* This constant was initialy in code */ > +#define DCS_0f (CGB_GEN | CGB_GEN_UNCOM | CGB_GEN_NOCLASS | CGB_GEN_CHARSETR | CGB_GEN_CLASS3) I hope a better name than DSC_0f can be found for it! Please talk to the developer who added the constant, to understand what it is about. Use git blame to find out who it is. > +/* Autodel 16 bit UCS2 */ > +#define DCS_ADEL_USC2 (CGB_AUTODEL| CGB_GEN_UNCOM | CGB_GEN_NOCLASS | CGB_GEN_CHARSET16) > > #endif Lots of new defines. They're not all required, but I do like that they are all there now. > +++ b/src/shared/libosmocore/src/gsm/gsm_utils.c > @@ -102,6 +102,30 @@ static unsigned char gsm_7bit_alphabet[] = { > 0xff, 0x7d, 0x08, 0xff, 0xff, 0xff, 0x7c, 0xff, 0x0c, 0x06, 0xff, 0xff, 0x7e, 0xff, 0xff > }; > > +/* Convert UCS2 char to UTF8 char */ > +int ucs2_to_utf8 (int ucs2, unsigned char * utf8) > +{ If you do end up keeping this function then even if it is too trivial to be copyrightable and/or the author doesn't care I think it is polite to at the very least reference it's origin. Thanks for your effort - I hope you'll spin a new improved patch! //Peter From holger at freyther.de Sat Sep 22 09:57:47 2012 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sat, 22 Sep 2012 11:57:47 +0200 Subject: [PATCH] Decoding UCS2 USSD In-Reply-To: References: <20120919010248.GC25668@localhost> <20120919021257.14324.qmail@stuge.se> Message-ID: <20120922095747.GD29787@localhost> On Wed, Sep 19, 2012 at 09:49:29PM +0000, Pavel Baturko wrote: > Thanks for advises! New version: if received text in UCS2, convert it to > UTF-8, then check if console supports UTF-8, if yes - print message in vty > as usual, if not - print message in hex. Hi Pavel, thanks for updating the patch. Could you remove the calls to setlocale and move the actual ucs->utf8 folding into a new subroutine. thanks holger From pabftk at gmail.com Sat Sep 29 11:06:45 2012 From: pabftk at gmail.com (Pavel Baturko) Date: Sat, 29 Sep 2012 15:06:45 +0400 Subject: [PATCH] Decoding UCS2 USSD In-Reply-To: <20120922095747.GD29787@localhost> References: <20120919010248.GC25668@localhost> <20120919021257.14324.qmail@stuge.se> <20120922095747.GD29787@localhost> Message-ID: Hi All, I fixed issues. Some comments: > Are these files always guaranteed to be available, or are some configure.ac checks required in this change? I'm not sure that checking is required because 'locale.h' is in standard C library. Please correct me if I mistaken. > Did you investigate if this function will handle UTF-8 data correctly? I sure don't know that. UTF-8 text is now not going from gsm480_rx_ussd function since terminal with telnet which is connected to mobile app can not support UTF-8 and there is no way to check it. > I hope a better name than DSC_0f can be found Author of gsm480_ss.c unfortunately does not remember why 0x0f constant is used but if it's works and text is decoded as GSM 7bit - I changed name to default3, hope it's ok. And now I have 3 variants of patch: ussd-ucs2.setlocale.patch - with setlocale function. locale is set to "Environment's default locale" with setlocale(LC_ALL, "") and then restored to previous. Calling of setlocale(LC_ALL, NULL) returns "C" (Minimal "C" locale) and this is not what I want, so I have to manually set locale to Env default and check if it's UTF-8. As I understand this variant is not desirable. ussd-ucs2.pipe.patch - locale is obtained from system shell with 'locale' command. I can't think another method to check locale except calling 'locale' or function 'setlocale'. If someone knows - please let me know. ussd-ucs2.hex.patch - compromise variant (no external programs calls, no functions that affects whole app). Just convert text from UCS2 to UTF-8 and print hex representation of the string. Thanks, Pavel On Sat, Sep 22, 2012 at 1:57 PM, Holger Hans Peter Freyther < holger at freyther.de> wrote: > On Wed, Sep 19, 2012 at 09:49:29PM +0000, Pavel Baturko wrote: > > Thanks for advises! New version: if received text in UCS2, convert it to > > UTF-8, then check if console supports UTF-8, if yes - print message in > vty > > as usual, if not - print message in hex. > > Hi Pavel, > > thanks for updating the patch. Could you remove the calls to setlocale and > move the actual ucs->utf8 folding into a new subroutine. > > thanks > > holger > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ussd-ucs2.setlocale.patch Type: application/octet-stream Size: 9780 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ussd-ucs2.pipe.patch Type: application/octet-stream Size: 9704 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ussd-ucs2.hex.patch Type: application/octet-stream Size: 8996 bytes Desc: not available URL: From laforge at gnumonks.org Thu Sep 20 08:23:51 2012 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 20 Sep 2012 10:23:51 +0200 Subject: [PATCH] Decoding UCS2 USSD In-Reply-To: <20120919021257.14324.qmail@stuge.se> References: <20120919010248.GC25668@localhost> <20120919021257.14324.qmail@stuge.se> Message-ID: <20120920082351.GE15271@prithivi.gnumonks.org> On Wed, Sep 19, 2012 at 04:12:57AM +0200, Peter Stuge wrote: > Holger Hans Peter Freyther wrote: > > I think a library should not call setlocale as it will impact the > > entire application. I think our only other realistic option is to > > use iconv (and stub it out for osmocomBB). Do you think you could > > try to create such a patch? > > I'd suggest http://www.lemoda.net/c/ucs2-to-utf8/ and simply output > UTF-8. interesting, but unfortunately comes without any indication of license. I will contact the author. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Thu Sep 20 10:55:42 2012 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 20 Sep 2012 12:55:42 +0200 Subject: [PATCH] Decoding UCS2 USSD In-Reply-To: <20120920082351.GE15271@prithivi.gnumonks.org> References: <20120919010248.GC25668@localhost> <20120919021257.14324.qmail@stuge.se> <20120920082351.GE15271@prithivi.gnumonks.org> Message-ID: <20120920105542.GO15271@prithivi.gnumonks.org> Hi all, On Thu, Sep 20, 2012 at 10:23:51AM +0200, Harald Welte wrote: > > I'd suggest http://www.lemoda.net/c/ucs2-to-utf8/ and simply output > > UTF-8. > > interesting, but unfortunately comes without any indication of license. > I will contact the author. He just responded to me that we can use the function under the terms of GNU GPL v2 or later. 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 pabs3 at bonedaddy.net Sat Sep 29 11:20:15 2012 From: pabs3 at bonedaddy.net (Paul Wise) Date: Sat, 29 Sep 2012 19:20:15 +0800 Subject: cppcheck/pyflakes results for osmocom-bb Message-ID: <1348917615.15047.116.camel@chianamo> Hi all, I noticed that cppcheck and pyflakes are detecting some possible issues in the osmocom-bb codebase on the master branch: ./src/target_dsp/calypso/dump2coff.py:3: 'namedtuple' imported but unused ./src/host/fb_tools/bdf_to_c.py:30: 'string' imported but unused [src/host/layer23/src/common/main.c:146]: (error) Possible null pointer dereference: app_opp [src/host/gsmmap/gsmmap.c:379] -> [src/host/gsmmap/gsmmap.c:384]: (error) Possible null pointer dereference: meas - otherwise it is redundant to check it against null. [src/shared/libosmocore/src/gb/gprs_bssgp.c:1076] -> [src/shared/libosmocore/src/gb/gprs_bssgp.c:1041]: (error) Possible null pointer dereference: dup - otherwise it is redundant to check it against null. [src/shared/libosmocore/src/gb/gprs_bssgp.c:1087] -> [src/shared/libosmocore/src/gb/gprs_bssgp.c:1041]: (error) Possible null pointer dereference: dup - otherwise it is redundant to check it against null. [src/shared/libosmocore/src/gb/gprs_bssgp.c:1088] -> [src/shared/libosmocore/src/gb/gprs_bssgp.c:1041]: (error) Possible null pointer dereference: dup - otherwise it is redundant to check it against null. [src/shared/libosmocore/src/gsm/lapd_core.c:1936] -> [src/shared/libosmocore/src/gsm/lapd_core.c:1948]: (error) Possible null pointer dereference: msg - otherwise it is redundant to check it against null. [src/target/firmware/apps/chainload/main.c:39]: (error) Possible null pointer dereference: entry [src/target/firmware/apps/loader/main.c:92]: (error) Possible null pointer dereference: entry [src/target/firmware/apps/loader_mtk/main.c:87]: (error) Possible null pointer dereference: entry [src/target/ui-experiment/png2tiny.c:20]: (error) printf format string has 1 parameters but only 0 are given. [src/target/firmware/rf/mt6139.c:138]: (error) Uninitialized variable: pga_gain -- bye, pabs http://bonedaddy.net/pabs3/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From holger at freyther.de Sun Sep 30 12:12:14 2012 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sun, 30 Sep 2012 14:12:14 +0200 Subject: cppcheck/pyflakes results for osmocom-bb In-Reply-To: <1348917615.15047.116.camel@chianamo> References: <1348917615.15047.116.camel@chianamo> Message-ID: <20120930121214.GA1358@localhost> On Sat, Sep 29, 2012 at 07:20:15PM +0800, Paul Wise wrote: > Hi all, > > ./src/target_dsp/calypso/dump2coff.py:3: 'namedtuple' imported but unused > ./src/host/fb_tools/bdf_to_c.py:30: 'string' imported but unused please create a patch for that/these. > [src/target/firmware/apps/chainload/main.c:39]: (error) Possible null pointer dereference: entry that is actually the point of the method. :) > > [src/host/layer23/src/common/main.c:146]: (error) Possible null pointer dereference: app_opp the tool is wrong here. app_opp == NULL iff app_len == 0 (or it should be). > [src/host/gsmmap/gsmmap.c:379] -> [src/host/gsmmap/gsmmap.c:384]: (error) Possible null pointer dereference: meas - otherwise it is redundant to check it against null. the code could use do {} while(); instead of while to make the warning go away. > [src/shared/libosmocore/src/gb/gprs_bssgp.c:1076] -> [src/shared/libosmocore/src/gb/gprs_bssgp.c:1041]: (error) Possible null pointer dereference: dup - otherwise it is redundant to check it against null. > [src/shared/libosmocore/src/gb/gprs_bssgp.c:1087] -> [src/shared/libosmocore/src/gb/gprs_bssgp.c:1041]: (error) Possible null pointer dereference: dup - otherwise it is redundant to check it against null. > [src/shared/libosmocore/src/gb/gprs_bssgp.c:1088] -> [src/shared/libosmocore/src/gb/gprs_bssgp.c:1041]: (error) Possible null pointer dereference: dup - otherwise it is redundant to check it against null. > [src/shared/libosmocore/src/gsm/lapd_core.c:1936] -> [src/shared/libosmocore/src/gsm/lapd_core.c:1948]: (error) Possible null pointer dereference: msg - otherwise it is redundant to check it against null. propably right, didn't check these. > [src/target/ui-experiment/png2tiny.c:20]: (error) printf format string has 1 parameters but only 0 are given. gcc by itself should warn about it. mtk: probably right but the code is not used on many devices. > [src/target/firmware/apps/loader/main.c:92]: (error) Possible null pointer dereference: entry > [src/target/firmware/apps/loader_mtk/main.c:87]: (error) Possible null pointer dereference: entry > [src/target/firmware/rf/mt6139.c:138]: (error) Uninitialized variable: pga_gain > > -- > bye, > pabs > > http://bonedaddy.net/pabs3/ From pabs3 at bonedaddy.net Sun Sep 30 23:44:37 2012 From: pabs3 at bonedaddy.net (Paul Wise) Date: Mon, 1 Oct 2012 07:44:37 +0800 Subject: [PATCH] Drop unused imports In-Reply-To: <20120930121214.GA1358@localhost> References: <20120930121214.GA1358@localhost> Message-ID: <1349048677-21292-1-git-send-email-pabs3@bonedaddy.net> --- src/host/fb_tools/bdf_to_c.py | 1 - src/target_dsp/calypso/dump2coff.py | 1 - 2 files changed, 2 deletions(-) diff --git a/src/host/fb_tools/bdf_to_c.py b/src/host/fb_tools/bdf_to_c.py index 2a3a644..86be6a6 100755 --- a/src/host/fb_tools/bdf_to_c.py +++ b/src/host/fb_tools/bdf_to_c.py @@ -27,7 +27,6 @@ selected glyphs in the format defined by the header. from optparse import OptionParser import sys import os -import string def unique_name(thisname,existingnames) : # return first of thisname, thisname_1, thisname_2, ... diff --git a/src/target_dsp/calypso/dump2coff.py b/src/target_dsp/calypso/dump2coff.py index 67a49e8..c05a0ff 100755 --- a/src/target_dsp/calypso/dump2coff.py +++ b/src/target_dsp/calypso/dump2coff.py @@ -1,6 +1,5 @@ #!/usr/bin/env python -from collections import namedtuple import re import sys import struct -- 1.7.10.4 From pabs at debian.org Sun Sep 30 23:56:39 2012 From: pabs at debian.org (Paul Wise) Date: Mon, 1 Oct 2012 07:56:39 +0800 Subject: cppcheck/pyflakes results for osmocom-bb In-Reply-To: <20120930121214.GA1358@localhost> References: <1348917615.15047.116.camel@chianamo> <20120930121214.GA1358@localhost> Message-ID: On Sun, Sep 30, 2012 at 8:12 PM, Holger Hans Peter Freyther wrote: > On Sat, Sep 29, 2012 at 07:20:15PM +0800, Paul Wise wrote: >> [src/target/firmware/apps/chainload/main.c:39]: (error) Possible null pointer dereference: entry > > that is actually the point of the method. :) Hmmm, should I file a bug on cppcheck about this? I guess jumping to address zero is something rarely done though so probably not. >> [src/host/layer23/src/common/main.c:146]: (error) Possible null pointer dereference: app_opp > > the tool is wrong here. app_opp == NULL iff app_len == 0 (or it should be). Hmm, probably not possible for cppcheck to deduce that since app_opp is set in another file. -- bye, pabs http://wiki.debian.org/PaulWise