From holger at freyther.de Fri Apr 3 17:37:42 2015 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Fri, 3 Apr 2015 19:37:42 +0200 Subject: [PATCH] Fix lintian-reported errors In-Reply-To: <20150325234423.GO540@xiaoyu.lan> References: <1427303161-6552-1-git-send-email-max.suraev@fairwaves.co> <20150325234423.GO540@xiaoyu.lan> Message-ID: <20150403173742.GL1127@xiaoyu.lan> On Thu, Mar 26, 2015 at 12:44:23AM +0100, Holger Hans Peter Freyther wrote: > On Wed, Mar 25, 2015 at 06:06:01PM +0100, Max wrote: max, could you please provide an updated/separated patch to at least improve the parts that are obviously correct and needed? From holger at freyther.de Sun Apr 5 12:42:00 2015 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sun, 5 Apr 2015 14:42:00 +0200 Subject: [PATCH] Add A5/3-4 cipher support In-Reply-To: <5512EC29.3010900@fairwaves.co> References: <1427300431-20371-1-git-send-email-max.suraev@fairwaves.co> <5512EC29.3010900@fairwaves.co> Message-ID: <20150405124200.GA13606@xiaoyu.lan> On Wed, Mar 25, 2015 at 06:11:05PM +0100, ? wrote: Dear Max, > Previous patch http://patchwork.ozlabs.org/patch/360531/ bitrot - ported to latest > master and hope to get some feedback. a5/a5_test.c: In function ?test_a53?: a5/a5_test.c:60:2: warning: implicit declaration of function ?_a5_3? [-Wimplicit-function-declaration] _a5_3(key, count, dlout, NULL, false); ^ a5/a5_test.c: In function ?test_a54?: a5/a5_test.c:72:2: warning: implicit declaration of function ?_a5_4? [-Wimplicit-function-declaration] _a5_4(key, count, dlout, NULL, false); in case the above come from your patch, please fix these warnings. From max.suraev at fairwaves.co Mon Apr 6 14:17:49 2015 From: max.suraev at fairwaves.co (Max) Date: Mon, 6 Apr 2015 16:17:49 +0200 Subject: [PATCH] fix compiler warnings for a5 tests Message-ID: <1428329869-21475-1-git-send-email-max.suraev@fairwaves.co> Signed-off-by: Max --- tests/a5/a5_test.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/tests/a5/a5_test.c b/tests/a5/a5_test.c index 0dbc6fb..6d7cc3c 100644 --- a/tests/a5/a5_test.c +++ b/tests/a5/a5_test.c @@ -8,6 +8,10 @@ #include #include +// make compiler happy +void _a5_3(const uint8_t *key, uint32_t fn, ubit_t *dl, ubit_t *ul, bool fn_correct); +void _a5_4(const uint8_t *key, uint32_t fn, ubit_t *dl, ubit_t *ul, bool fn_correct); + static const uint8_t key[] = { 0x01, 0x23, 0x45, 0x67, 0x89, 0xab, 0xcd, 0xef }; static const uint32_t fn = 123456; static const uint8_t dl[] = { -- 2.1.0 From Max.Suraev at fairwaves.co Wed Apr 8 11:46:11 2015 From: Max.Suraev at fairwaves.co (=?UTF-8?B?4piO?=) Date: Wed, 08 Apr 2015 13:46:11 +0200 Subject: [PATCH] Add A5/3-4 cipher support In-Reply-To: <20150405124200.GA13606@xiaoyu.lan> References: <1427300431-20371-1-git-send-email-max.suraev@fairwaves.co> <5512EC29.3010900@fairwaves.co> <20150405124200.GA13606@xiaoyu.lan> Message-ID: <55251503.2020108@fairwaves.co> Here it is: http://patchwork.ozlabs.org/patch/458387/ 05.04.2015 14:42, Holger Hans Peter Freyther ?????: > On Wed, Mar 25, 2015 at 06:11:05PM +0100, ? wrote: > > Dear Max, > >> Previous patch http://patchwork.ozlabs.org/patch/360531/ bitrot - ported to latest >> master and hope to get some feedback. > > a5/a5_test.c: In function ?test_a53?: > a5/a5_test.c:60:2: warning: implicit declaration of function ?_a5_3? [-Wimplicit-function-declaration] > _a5_3(key, count, dlout, NULL, false); > ^ > a5/a5_test.c: In function ?test_a54?: > a5/a5_test.c:72:2: warning: implicit declaration of function ?_a5_4? [-Wimplicit-function-declaration] > _a5_4(key, count, dlout, NULL, false); > > > in case the above come from your patch, please fix these warnings. > -- best regards, Max, http://fairwaves.co From Max.Suraev at fairwaves.co Wed Apr 8 11:52:22 2015 From: Max.Suraev at fairwaves.co (=?UTF-8?B?4piO?=) Date: Wed, 08 Apr 2015 13:52:22 +0200 Subject: [PATCH] Fix lintian-reported errors In-Reply-To: <20150403173742.GL1127@xiaoyu.lan> References: <1427303161-6552-1-git-send-email-max.suraev@fairwaves.co> <20150325234423.GO540@xiaoyu.lan> <20150403173742.GL1127@xiaoyu.lan> Message-ID: <55251676.4070401@fairwaves.co> 03.04.2015 19:37, Holger Hans Peter Freyther ?????: > On Thu, Mar 26, 2015 at 12:44:23AM +0100, Holger Hans Peter Freyther wrote: >> On Wed, Mar 25, 2015 at 06:06:01PM +0100, Max wrote: > > max, could you please provide an updated/separated patch to > at least improve the parts that are obviously correct and > needed? > Sure that's on my TODO alongside with writing better descriptions based on wiki pages. Can't give any ETA though so if anyone is willing to step in - go ahead. -- best regards, Max, http://fairwaves.co From craig_comstock at yahoo.com Thu Apr 16 11:51:06 2015 From: craig_comstock at yahoo.com (Craig Comstock) Date: Thu, 16 Apr 2015 11:51:06 +0000 (UTC) Subject: nuttx-bb? Message-ID: <947230410.4267258.1429185067070.JavaMail.yahoo@mail.yahoo.com> Hi all, Was starting to work on making a usable phone again and wondered about the status of nuttx-bb git on osmocom.org versus nuttx source. It seems nuttx source is more up-to-date and has configs for my device: compal_e86/c139. Wondering if there is something in nuttx-bb that is unique that I should pay attention to? Should nuttx-bb be rebased from nuttx upstream? I was able to cobble together a nuttx.bin but on loading it always stops at 88% with the chainloader. The nuttx.bin is 148K which would seem plenty of room since the C139 has 4000K flash (32MBit) (am I doing that calculation correctly)? I had to fiddle with the MEMORY section of the ld.script in order to make space for nuttx, I'm not too familiar with this sort of thing so may have done something wrong... /* E86 stacked flash 32mbit flash, 4mbit sram, DBB internal 256kb SRAM */ ??? /* 0x800000-0x87ffff */ /* bump up because we have 32mbit instead of 16mbit */ ??? /* compal-loaded binary: our text, initialized data */ ??? LRAM (rw) : ORIGIN = 0x00800000, LENGTH = 0x00020000 ??? TRAM (rw) : ORIGIN = 0x00820000, LENGTH = 0x00040000 ??? /* compal-loaded binary: our unitialized data, stacks, heap */ ??? IRAM (rw) : ORIGIN = 0x00860000, LENGTH = 0x00020000 Originally TRAM was 20000 long and gave me an error on building. Not sure if I can fiddle with these values or not. Thanks,Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: diff2 Type: application/octet-stream Size: 4233 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: osmocon.log Type: text/x-log Size: 3339 bytes Desc: not available URL: From craig_comstock at yahoo.com Fri Apr 17 00:51:41 2015 From: craig_comstock at yahoo.com (Craig Comstock) Date: Fri, 17 Apr 2015 00:51:41 +0000 (UTC) Subject: nuttx-bb? References: <947230410.4267258.1429185067070.JavaMail.yahoo@mail.yahoo.com> Message-ID: Craig Comstock yahoo.com> writes: > > > Hi all, > > Was starting to work on making a usable phone again and wondered about the status of nuttx-bb git on osmocom.org versus nuttx source. It seems nuttx source is more up-to-date and has configs for my device: compal_e86/c139. Wondering if there is something in nuttx-bb that is unique that I should pay attention to? Should nuttx-bb be rebased from nuttx upstream? > > I was able to cobble together a nuttx.bin but on loading it always stops at 88% with the chainloader. The nuttx.bin is 148K which would seem plenty of room since the C139 has 4000K flash (32MBit) (am I doing that calculation correctly)? > > I had to fiddle with the MEMORY section of the ld.script in order to make space for nuttx, I'm not too familiar with this sort of thing so may have done something wrong... > > /* E86 stacked flash 32mbit flash, 4mbit sram, DBB internal 256kb SRAM */??? /* 0x800000-0x87ffff */ /* bump up because we have 32mbit instead of 16mbit */??? /* compal-loaded binary: our text, initialized data */??? LRAM (rw) : ORIGIN = 0x00800000, LENGTH = 0x00020000??? TRAM (rw) : ORIGIN = 0x00820000, LENGTH = 0x00040000??? /* compal-loaded binary: our unitialized data, stacks, heap */??? IRAM (rw) : ORIGIN = 0x00860000, LENGTH = 0x00020000 > > > Originally TRAM was 20000 long and gave me an error on building. Not sure if I can fiddle with these values or not. > > > Thanks, > Craig > > > > Attachment (diff2): application/octet-stream, 4233 bytes > Attachment (osmocon.log): text/x-log, 3339 bytes I did some debugging on osmocon and it seems it is getting stuck on the serial read not returning anything, maybe blocking forever waiting for data coming back. I wasn't sure how the chainloader program was loaded... there seemed to be 30-40 bytes of code in an array maybe? Maybe the chainloader is being corrupted? Other chainloaded programs such as rssi work just fine so maybe my nuttx.bin is causing a problem somehow. Thanks, Craig From craig_comstock at yahoo.com Fri Apr 17 04:50:04 2015 From: craig_comstock at yahoo.com (Craig Comstock) Date: Fri, 17 Apr 2015 04:50:04 +0000 (UTC) Subject: nuttx-bb? References: <947230410.4267258.1429185067070.JavaMail.yahoo@mail.yahoo.com> Message-ID: Craig Comstock yahoo.com> writes: > > Craig Comstock yahoo.com> writes: > > > > > > > Hi all, > > > > Was starting to work on making a usable phone again and wondered about the > status of nuttx-bb git on osmocom.org versus nuttx source. It seems nuttx > source is more up-to-date and has configs for my device: compal_e86/c139. > Wondering if there is something in nuttx-bb that is unique that I should pay > attention to? Should nuttx-bb be rebased from nuttx upstream? > > > > I was able to cobble together a nuttx.bin but on loading it always stops > at 88% with the chainloader. The nuttx.bin is 148K which would seem plenty > of room since the C139 has 4000K flash (32MBit) (am I doing that calculation > correctly)? > > > > I had to fiddle with the MEMORY section of the ld.script in order to make > space for nuttx, I'm not too familiar with this sort of thing so may have > done something wrong... > > > > /* E86 stacked flash 32mbit flash, 4mbit sram, DBB internal 256kb SRAM > */??? /* 0x800000-0x87ffff */ /* bump up because we have 32mbit instead of > 16mbit */??? /* compal-loaded binary: our text, initialized data */??? LRAM > (rw) : ORIGIN = 0x00800000, LENGTH = 0x00020000??? TRAM (rw) : ORIGIN = > 0x00820000, LENGTH = 0x00040000??? /* compal-loaded binary: our unitialized > data, stacks, heap */??? IRAM (rw) : ORIGIN = 0x00860000, LENGTH = 0x00020000 > > > > > > Originally TRAM was 20000 long and gave me an error on building. Not sure > if I can fiddle with these values or not. > > > > > > Thanks, > > Craig > > > > > > > > Attachment (diff2): application/octet-stream, 4233 bytes > > Attachment (osmocon.log): text/x-log, 3339 bytes > > I did some debugging on osmocon and it seems it is getting stuck on the > serial read not returning anything, maybe blocking forever waiting for data > coming back. I wasn't sure how the chainloader program was loaded... there > seemed to be 30-40 bytes of code in an array maybe? Maybe the chainloader is > being corrupted? Other chainloaded programs such as rssi work just fine so > maybe my nuttx.bin is causing a problem somehow. > > Thanks, > Craig > > I tried chopping the binary down to 130 chunks of 1014 bytes, i.e. 128kb bytes, and that loads fine. So maybe this TI Calypso romloader can only load 128kb? The osmocom c140 page mentions 256kb of internal SRAM. Can anyone give me some clues here? I suppose the c139 might have a different Calypso chip with only 128kb internal sram? Does this have something to do with the extra control register ffff:fb10 it has a note that mentions access ending at some point... 0 = Accessing nCS3 with programmed wait-state. 1 = When accessing nCS3 the number of wait is set to 127, but access is ended when nready_mem goes low. If nready_mem stays at ?1? after 127 wait states an abort is generated. I read a bunch of old messages on this list about nuttx b/w Greg and Harald and learned a lot. Sounds like running NuttX from flash and then loading GSM-specific "apps" into SRAM is sort of the best idea? If anyone else is working on nuttx-bb or maybe porting mobile onto the phone it would be great to collaborate. From domi at tomcsanyi.net Thu Apr 23 16:01:15 2015 From: domi at tomcsanyi.net (=?utf-8?Q?Tomcs=C3=A1nyi=2C?= Domonkos) Date: Thu, 23 Apr 2015 18:01:15 +0200 (CEST) Subject: [PATCH] SAP client - revisited Message-ID: <1015750550.17043.1429804875628.JavaMail.zimbra@tomcsanyi.net> Hi everyone, I'm following up on this conversation: http://comments.gmane.org/gmane.comp.mobile.osmocom.baseband.devel/1796 It seems like there was no movement in this topic in the last couple of years, so I decided to go ahead and integrate Nico's SAP client into the current master branch and created a patch from it. I tested it (with Kevin's softSIM and a pcsc reader), it worked for me, however it is currently quite ugly: it kind of hand crafts the msgb structure (in l1ctl.c, patch line 121), sorry for that, but I kept getting extra bytes stuffed into the msg that was passed to the sap_interface so I decided to manually go around the problem. I'm of course open to any suggestions to get it cleaner, and then if you think and decide so it could be merged into the master (as far as I see. One thing however that I think is strange, and worth mentioning: I'm not sure why Nico decided to implement the switch between phone and SAP-client inside of l1ctl.c, for me it would feel better to do it in sim.c (since sim.c deals with SIM activities, l1ctl should deal only with L1 stuff...also the current SAP client calls back to sim.c, but receives data from l1ctl - little bit confusing), but I left it as is because of not knowing exactly the thoughts behind it. Regards, Domi -------------- next part -------------- A non-text attachment was scrubbed... Name: sap.patch Type: text/x-patch Size: 23863 bytes Desc: not available URL: From osmocom at ngolde.de Fri Apr 24 14:41:53 2015 From: osmocom at ngolde.de (Nico Golde) Date: Fri, 24 Apr 2015 16:41:53 +0200 Subject: [PATCH] SAP client - revisited In-Reply-To: <1015750550.17043.1429804875628.JavaMail.zimbra@tomcsanyi.net> References: <1015750550.17043.1429804875628.JavaMail.zimbra@tomcsanyi.net> Message-ID: <20150424144153.GB9119@ngolde.de> Hi, * Tomcs?nyi, Domonkos [2015-04-23 18:12]: [...] > It seems like there was no movement in this topic in the last couple of years, so I decided to go ahead and integrate Nico's SAP client into the current master branch and created a patch from it. Cool, great work! > One thing however that I think is strange, and worth mentioning: I'm not > sure why Nico decided to implement the switch between phone and SAP-client > inside of l1ctl.c, for me it would feel better to do it in sim.c (since > sim.c deals with SIM activities, l1ctl should deal only with L1 stuff...also > the current SAP client calls back to sim.c, but receives data from l1ctl - > little bit confusing), but I left it as is because of not knowing exactly > the thoughts behind it. I don't remember details to be honest as this is too long ago, but I think there was no real design decision behind this other than that the code that is sending traffic to the SIM was already in l1ctl and I just added the switch... Cheers, Nico -- Nico Golde - XMPP: nion at jabber.ccc.de - GPG: 0xA0A0AAAA -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From domi at tomcsanyi.net Tue Apr 28 13:39:44 2015 From: domi at tomcsanyi.net (=?utf-8?Q?Tomcs=C3=A1nyi=2C?= Domonkos) Date: Tue, 28 Apr 2015 15:39:44 +0200 (CEST) Subject: [PATCH] SAP client - revisited In-Reply-To: <20150424144153.GB9119@ngolde.de> References: <1015750550.17043.1429804875628.JavaMail.zimbra@tomcsanyi.net> <20150424144153.GB9119@ngolde.de> Message-ID: <2083838205.22261.1430228384417.JavaMail.zimbra@tomcsanyi.net> Hi, On Friday, April 24, 2015 4:41:53 PM, Nico Golde wrote: >> One thing however that I think is strange, and worth mentioning: I'm not >> sure why Nico decided to implement the switch between phone and SAP-client >> inside of l1ctl.c, for me it would feel better to do it in sim.c (since >> sim.c deals with SIM activities, l1ctl should deal only with L1 stuff...also >> the current SAP client calls back to sim.c, but receives data from l1ctl - >> little bit confusing), but I left it as is because of not knowing exactly >> the thoughts behind it. > > I don't remember details to be honest as this is too long ago, but I think > there was no real design decision behind this other than that the code that is > sending traffic to the SIM was already in l1ctl and I just added the switch... All right, thanks for clarifying. I went ahead and did the change: now sim.c calls either l1ctl or sap_interface and they both call back to sim.c when they have a result. The function that gets called in sap_interface.c has now the same signature as the one in l1ctl suggesting they provide an interface for the same task (which they do indeed). I attached the revised patch. Some background info/documentation: By default the mobile app will try to use the SAP backend instead of the built in SIM reader. If it fails to connect to the default SAP socket (/tmp/osmocom_sap) it'll fallback to the phone's built-in SIM slot. To use the SAP backend you'll need softSIM which will create the socket and also interact with a PC/SC reader or a previously captured file (sim_os). First you need to start up the demo_server with the right parameters based on your setup (-s unix to create the socket for the mobile app, -t type depends on whether you have a PC/SC reader or not). After that osmocon could be started, then the mobile app, then the phone itself. When starting up the mobile app one can observe the debug information from the SAP interface by default. Regards, Domi -------------- next part -------------- A non-text attachment was scrubbed... Name: sap_v2.patch Type: text/x-patch Size: 23020 bytes Desc: not available URL: From 246tnt at gmail.com Tue Apr 28 13:57:55 2015 From: 246tnt at gmail.com (Sylvain Munaut) Date: Tue, 28 Apr 2015 15:57:55 +0200 Subject: [PATCH] SAP client - revisited In-Reply-To: <2083838205.22261.1430228384417.JavaMail.zimbra@tomcsanyi.net> References: <1015750550.17043.1429804875628.JavaMail.zimbra@tomcsanyi.net> <20150424144153.GB9119@ngolde.de> <2083838205.22261.1430228384417.JavaMail.zimbra@tomcsanyi.net> Message-ID: Patch looked good. Pushed. From clovnrian at gmail.com Tue Apr 28 14:52:21 2015 From: clovnrian at gmail.com (Miroslav Babjak) Date: Tue, 28 Apr 2015 16:52:21 +0200 Subject: Osmocom-bb cell sync problem in my version without HW Message-ID: Hi everyone, I am working on modification the osmocom-bb project. I try modified the osmocom-bb which could communicate with BTS via UDP sockets. Here you can find the project: https://github.com/clovnrian/osmocom-bb-gprs-no-hw I have problem with cell syncing. This is output from mobile: <0003> gsm322.c:2947 Channel synched. (ARFCN=17, snr=0, BSIC=0) <0003> gsm322.c:698 Starting CS timer with 4 seconds. <0001> gsm322.c:2968 using DSC of 90 The CS timer always timeout. On github you can see what messages BTS sends to mobile. Does anybody know what I have to do to or what message I have to send to mobile? I will be grateful for any help With regards Miroslav Babj?k -------------- next part -------------- An HTML attachment was scrubbed... URL: