From zero-kelvin at gmx.de Thu Nov 1 11:42:32 2012 From: zero-kelvin at gmx.de (dexter) Date: Thu, 01 Nov 2012 12:42:32 +0100 Subject: Future of our Osmocom Berlin User Group meeting In-Reply-To: <20120818115942.GV29525@prithivi.gnumonks.org> References: <502d01a9.mirider@mirider.augusta.de> <20120818115942.GV29525@prithivi.gnumonks.org> Message-ID: <50926028.4040500@gmx.de> Hi folks. We have not met each other for a couple of weeks. I think we should keep the meeting going. I am willing to send out the invitation-mails and take card about open doors at the CCCB. So far so good lets move on! This is the announcement for the next Osmocom Berlin meeting. Nov 07, 8pm @ CCC Berlin, Marienstr. 11, 10113 Berlin There is no formal presentation scheduled for this meeting. If you are interested to show up, feel free to do so. There is no registration required. The meeting is free as in "free beer", despite no actual free beer being around. Regards, Philipp Maier From laforge at gnumonks.org Mon Nov 5 11:47:12 2012 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 5 Nov 2012 12:47:12 +0100 Subject: Future of our Osmocom Berlin User Group meeting In-Reply-To: <50926028.4040500@gmx.de> References: <502d01a9.mirider@mirider.augusta.de> <20120818115942.GV29525@prithivi.gnumonks.org> <50926028.4040500@gmx.de> Message-ID: <20121105114712.GD29904@prithivi.gnumonks.org> Hi Dexter, On Thu, Nov 01, 2012 at 12:42:32PM +0100, dexter wrote: > We have not met each other for a couple of weeks. I think we should keep > the meeting going. > > I am willing to send out the invitation-mails and take card about open > doors at the CCCB. thanks for taking care of this. 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 zero-kelvin at gmx.de Sun Nov 18 19:12:11 2012 From: zero-kelvin at gmx.de (dexter) Date: Sun, 18 Nov 2012 20:12:11 +0100 Subject: Future of our Osmocom Berlin User Group meeting In-Reply-To: <20120818115942.GV29525@prithivi.gnumonks.org> References: <502d01a9.mirider@mirider.augusta.de> <20120818115942.GV29525@prithivi.gnumonks.org> Message-ID: <50A9330B.3030905@gmx.de> Hi folks. This is the announcement for the next Osmocom Berlin meeting. Nov 21, 8pm @ CCC Berlin, Marienstr. 11, 10113 Berlin There is no formal presentation scheduled for this meeting. If you are interested to show up, feel free to do so. There is no registration required. The meeting is free as in "free beer", despite no actual free beer being around. Regards, Philipp Maier From zero-kelvin at gmx.de Sun Nov 18 20:19:59 2012 From: zero-kelvin at gmx.de (dexter) Date: Sun, 18 Nov 2012 21:19:59 +0100 Subject: Osmocom Berlin User Group meeting In-Reply-To: <50A9330B.3030905@gmx.de> References: <502d01a9.mirider@mirider.augusta.de> <20120818115942.GV29525@prithivi.gnumonks.org> <50A9330B.3030905@gmx.de> Message-ID: <50A942EF.1030403@gmx.de> Sorry, i messed up the subject... > Hi folks. > > This is the announcement for the next Osmocom Berlin meeting. > > Nov 21, 8pm @ CCC Berlin, Marienstr. 11, 10113 Berlin > > There is no formal presentation scheduled for this meeting. > > If you are interested to show up, feel free to do so. There is no > registration required. The meeting is free as in "free beer", despite > no actual free beer being around. > > Regards, > Philipp Maier > > From laforge at gnumonks.org Mon Nov 19 10:22:15 2012 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 19 Nov 2012 11:22:15 +0100 Subject: Osmocom Berlin User Group meeting on Nov 21 In-Reply-To: <50A942EF.1030403@gmx.de> References: <502d01a9.mirider@mirider.augusta.de> <20120818115942.GV29525@prithivi.gnumonks.org> <50A9330B.3030905@gmx.de> <50A942EF.1030403@gmx.de> Message-ID: <20121119102215.GU8595@prithivi.gnumonks.org> Hi Dexter, JFYI: After a long break, I'll be able to participate again this week. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From niceguy108 at gmail.com Tue Nov 6 04:38:53 2012 From: niceguy108 at gmail.com (Bhaskar11) Date: Tue, 6 Nov 2012 10:08:53 +0530 Subject: Presentations at upcoming CCC? Message-ID: <01a501cdbbd8$a2b826c0$0b00a8c0@notebook> Are any presentations planned on Osmocom-BB and A51 at the upcoming CCC? B. -------------- next part -------------- An HTML attachment was scrubbed... URL: From khorben at defora.org Tue Nov 6 09:13:56 2012 From: khorben at defora.org (Pierre Pronchery) Date: Tue, 06 Nov 2012 10:13:56 +0100 Subject: Presentations at upcoming CCC? In-Reply-To: <01a501cdbbd8$a2b826c0$0b00a8c0@notebook> References: <01a501cdbbd8$a2b826c0$0b00a8c0@notebook> Message-ID: <5098D4D4.7080508@defora.org> On 06/11/2012 05:38, Bhaskar11 wrote: > Are any presentations planned on Osmocom-BB and A51 at the upcoming CCC? Harald will present Osmocom at EHSM, which happens in Berlin at the same time as the CCC: http://ehsm.eu/ HTH, -- khorben From andrew at carrierdetect.com Mon Nov 12 10:25:19 2012 From: andrew at carrierdetect.com (Andrew Back) Date: Mon, 12 Nov 2012 10:25:19 +0000 Subject: Programming SIM card RAND? Message-ID: Hello, I'm trying to get some MS test equipment working and have programmed a SIM with pysim-prog.py, but the tester has a configuration field for RAND and I cannot see how to set this on the SIM. In fact this has confused me as I thought the network always supplied this... I have the IMSI, Ki, MCC and MNC set the same on the tester and SIM, but tests don't get very far and fail with "incorrect SRES". Any ideas? Regards, Andrew -- Andrew Back http://carrierdetect.com From 246tnt at gmail.com Mon Nov 12 10:38:18 2012 From: 246tnt at gmail.com (Sylvain Munaut) Date: Mon, 12 Nov 2012 11:38:18 +0100 Subject: Programming SIM card RAND? In-Reply-To: References: Message-ID: Hi, > I'm trying to get some MS test equipment working and have programmed a > SIM with pysim-prog.py, but the tester has a configuration field for > RAND and I cannot see how to set this on the SIM. In fact this has > confused me as I thought the network always supplied this... You can't set the RAND on the simcard ... that doesn't make sense. As you said the network provides this. Now in some tester, they will always submit a fixed RAND and then ask you to provide the matching SRES and Kc that will be computed by the SIM when fed this RAND. This way the tester doesn't have to know which algorithm (XOR, COMP128v1 v2 v3 MILENAGE ...) is used on your SIM. Cheers, Sylvain From spaar at mirider.augusta.de Mon Nov 12 12:39:13 2012 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Mon, 12 Nov 2012 12:39:13 Subject: Programming SIM card RAND? Message-ID: <50a0edf1.mirider@mirider.augusta.de> Hello Andrew, On Mon, 12 Nov 2012 10:25:19 +0000, "Andrew Back" wrote: > > I'm trying to get some MS test equipment working and have programmed a > SIM with pysim-prog.py, but the tester has a configuration field for > RAND and I cannot see how to set this on the SIM. In fact this has > confused me as I thought the network always supplied this... Most certainly the RAND value of your MS tester is the value which is sent during authentication. All MS testers I have seen so far allow to configure this value, either use random data or set it to a fixed value. > I have the IMSI, Ki, MCC and MNC set the same on the tester and SIM, > but tests don't get very far and fail with "incorrect SRES". I would expect that you need a SIM card which supports XOR for A3/A8. This algorithm is the only one I have seen on nearly all MS tests sets I have access to. Those test sets usually don't support COMP128 and its variants (I guess your SIM card only supports this algorithm), so you need a SIM card which uses the same algorithm as the MS test set. However if you can set a fixed RAND value on the MS test set you can check what your SIM card will return with this RAND and set Kc and SRES on the test set to those values. Best regards, Dieter -- Dieter Spaar, Germany spaar at mirider.augusta.de From andrew at carrierdetect.com Mon Nov 12 13:19:02 2012 From: andrew at carrierdetect.com (Andrew Back) Date: Mon, 12 Nov 2012 13:19:02 +0000 Subject: Programming SIM card RAND? In-Reply-To: <50a0edf1.mirider@mirider.augusta.de> References: <50a0edf1.mirider@mirider.augusta.de> Message-ID: Hi Dieter, On 12 November 2012 12:39, Dieter Spaar wrote: > Hello Andrew, > > On Mon, 12 Nov 2012 10:25:19 +0000, "Andrew Back" wrote: >> >> I'm trying to get some MS test equipment working and have programmed a >> SIM with pysim-prog.py, but the tester has a configuration field for >> RAND and I cannot see how to set this on the SIM. In fact this has >> confused me as I thought the network always supplied this... > > Most certainly the RAND value of your MS tester is the value which > is sent during authentication. All MS testers I have seen so far > allow to configure this value, either use random data or set it > to a fixed value. Right, so I'm now thinking that the tester UI and documentation is probably just unclear/misleading. >> I have the IMSI, Ki, MCC and MNC set the same on the tester and SIM, >> but tests don't get very far and fail with "incorrect SRES". > > I would expect that you need a SIM card which supports XOR for > A3/A8. This algorithm is the only one I have seen on nearly all > MS tests sets I have access to. Those test sets usually don't > support COMP128 and its variants (I guess your SIM card only supports > this algorithm), so you need a SIM card which uses the same algorithm > as the MS test set. I've ordered one of those generic test SIMs from eBay and now I just need to wait for it to arrive from China... The description mentioned a number of common testers and so I'm guessing it must support XOR. > However if you can set a fixed RAND value on the MS test set you can > check what your SIM card will return with this RAND and set Kc and > SRES on the test set to those values. I don't see any way to set SRES and Kc in the tester, sadly, so I think I will just have to wait and try with the test SIM when it arrives. Thanks for your help! Best, Andrew -- Andrew Back http://carrierdetect.com From andrew at carrierdetect.com Sat Nov 24 10:42:00 2012 From: andrew at carrierdetect.com (Andrew Back) Date: Sat, 24 Nov 2012 10:42:00 +0000 Subject: Programming SIM card RAND? In-Reply-To: <50a0edf1.mirider@mirider.augusta.de> References: <50a0edf1.mirider@mirider.augusta.de> Message-ID: On 12 November 2012 12:39, Dieter Spaar wrote: > I would expect that you need a SIM card which supports XOR for > A3/A8. This algorithm is the only one I have seen on nearly all > MS tests sets I have access to. Those test sets usually don't > support COMP128 and its variants (I guess your SIM card only supports > this algorithm), so you need a SIM card which uses the same algorithm > as the MS test set. I bought one of those generic test SIMs from eBay that claim to work with HP8922 etc. testers. Now this is probably another stupid question, but how do I determine the IMSI and Ki? Or maybe set them (pySim-prog.py doesn't seem to work with it). Best, Andrew -- Andrew Back http://carrierdetect.com From ml at mail.tsaitgaist.info Mon Nov 26 10:07:18 2012 From: ml at mail.tsaitgaist.info (Kevin Redon) Date: Mon, 26 Nov 2012 11:07:18 +0100 Subject: Programming SIM card RAND? In-Reply-To: References: <50a0edf1.mirider@mirider.augusta.de> Message-ID: <1353924198-sup-1293@dennou> Hi, you can read the IMSI in the EF_IMSI file on the SIM card. tools (like softSIM and others) are available to read that out for you. Ki is not readable on normal SIM cards. If it's a developer SIM, then you have to look in your SIMs manufacturer manual/specification. If it's a MagicCard, GreenCard, or SysmoSIM, you should be able to overwrite them using pySim-prog.py. kevin Excerpts from Andrew Back's message of Sat Nov 24 11:42:00 +0100 2012: > On 12 November 2012 12:39, Dieter Spaar wrote: > > > I would expect that you need a SIM card which supports XOR for > > A3/A8. This algorithm is the only one I have seen on nearly all > > MS tests sets I have access to. Those test sets usually don't > > support COMP128 and its variants (I guess your SIM card only supports > > this algorithm), so you need a SIM card which uses the same algorithm > > as the MS test set. > > I bought one of those generic test SIMs from eBay that claim to work > with HP8922 etc. testers. Now this is probably another stupid > question, but how do I determine the IMSI and Ki? Or maybe set them > (pySim-prog.py doesn't seem to work with it). > > Best, > > Andrew > From spaar at mirider.augusta.de Sat Nov 24 13:14:36 2012 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Sat, 24 Nov 2012 13:14:36 Subject: Programming SIM card RAND? Message-ID: <50b0c83c.mirider@mirider.augusta.de> Hello Andrew, On Sat, 24 Nov 2012 10:42:00 +0000, "Andrew Back" wrote: > > I bought one of those generic test SIMs from eBay that claim to work > with HP8922 etc. testers. Now this is probably another stupid > question, but how do I determine the IMSI and Ki? Or maybe set them > (pySim-prog.py doesn't seem to work with it). For the IMSI you can read the appropriate EF of the SIM (the phone does the same to get the IMSI). Ki usually cannot be read back but because A3/A8 for a Test SIM is GSM XOR you can calculate Ki from the SIM response to the RUN GSM ALGORITHM command. OpenBSC contains code for the GSM XOR algorithm, this should give enough hints for how the calculation is done. For setting IMSI and Ki you most certainly have to contact the seller of the SIM card and hope that he can/will tell you the details. Best regards, Dieter -- Dieter Spaar, Germany spaar at mirider.augusta.de From andrew at carrierdetect.com Wed Nov 28 22:44:02 2012 From: andrew at carrierdetect.com (Andrew Back) Date: Wed, 28 Nov 2012 22:44:02 +0000 Subject: Programming SIM card RAND? In-Reply-To: <50b0c83c.mirider@mirider.augusta.de> References: <50b0c83c.mirider@mirider.augusta.de> Message-ID: Hi Dieter, On 24 November 2012 13:14, Dieter Spaar wrote: > For the IMSI you can read the appropriate EF of the SIM (the phone > does the same to get the IMSI). Ki usually cannot be read back but > because A3/A8 for a Test SIM is GSM XOR you can calculate Ki from > the SIM response to the RUN GSM ALGORITHM command. OpenBSC contains > code for the GSM XOR algorithm, this should give enough hints for > how the calculation is done. > > For setting IMSI and Ki you most certainly have to contact the seller > of the SIM card and hope that he can/will tell you the details. I asked the seller if they could tell me the Ki and explained why I needed this, and the response I got was: "the test card is mainly test 2GB network singinal" :o) The baseband VTY show subscriber command gave me the IMSI (001010123456789) and by reading the OpenBSC code I found that for XOR I just needed the first 4 bytes of Ki, which worked out to be 1 154 2 173 (to make things easy I set the tester to use 255 255 255 255 ... for RAND). I'm not sure how I would ascertain Ki in its entirety, but maybe I don't need this anyway. Thank you for your help! Best, Andrew -- Andrew Back http://carrierdetect.com From jl at thre.at Tue Nov 13 18:47:11 2012 From: jl at thre.at (Joshua Lackey) Date: Tue, 13 Nov 2012 10:47:11 -0800 Subject: gsm322.c:arfcn2index patch Message-ID: (This is a patch against the latest, as of last night, git master.) If you enable PCS, you'll never make it out of power-measurement without this patch: (This should be applied by everyone.) ---8<--- diff --git a/src/host/layer23/src/mobile/gsm322.c b/src/host/layer23/src/mobile/gsm322.c index ce5e1e1..ffecfc3 100644 --- a/src/host/layer23/src/mobile/gsm322.c +++ b/src/host/layer23/src/mobile/gsm322.c @@ -300,11 +300,14 @@ uint16_t index2arfcn(int index) int arfcn2index(uint16_t arfcn) { - if ((arfcn & ARFCN_PCS) && arfcn >= 512 && arfcn <= 810) + int is_pcs = arfcn & ARFCN_PCS; + arfcn &= ~ARFCN_FLAG_MASK; + if ((is_pcs) && (arfcn >= 512) && (arfcn <= 810)) return (arfcn & 1023)-512+1024; return arfcn & 1023; } + static char *bargraph(int value, int min, int max) { static char bar[128]; ---8<--- If you enable PCS, you'll never receive packets without this patch: (which I only include for e88 and e86 but it should work for others) (This should be applied if you don't use DCS in your area.) ---8<--- diff --git a/src/target/firmware/board/compal/rffe_dualband.c b/src/target/firmware/board/compal/rffe_dualband.c index f4b7361..5df1dfc 100644 --- a/src/target/firmware/board/compal/rffe_dualband.c +++ b/src/target/firmware/board/compal/rffe_dualband.c @@ -47,7 +47,8 @@ void rffe_mode(enum gsm_band band, int tx) /* Returns RF wiring */ uint32_t rffe_get_rx_ports(void) { - return (1 << PORT_LO) | (1 << PORT_DCS1800); + // return (1 << PORT_LO) | (1 << PORT_DCS1800); + return (1 << PORT_LO) | (1 << PORT_PCS1900); } uint32_t rffe_get_tx_ports(void) diff --git a/src/target/firmware/board/compal_e86/rffe_dualband_e86.c b/src/target/firmware/board/compal_e86/rffe_dualband_e86.c index 25bb099..10459d9 100644 --- a/src/target/firmware/board/compal_e86/rffe_dualband_e86.c +++ b/src/target/firmware/board/compal_e86/rffe_dualband_e86.c @@ -51,7 +51,8 @@ void rffe_mode(enum gsm_band band, int tx) /* Returns RF wiring */ uint32_t rffe_get_rx_ports(void) { - return (1 << PORT_LO) | (1 << PORT_DCS1800); + // return (1 << PORT_LO) | (1 << PORT_DCS1800); + return (1 << PORT_LO) | (1 << PORT_PCS1900); } uint32_t rffe_get_tx_ports(void) ---8<--- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gsm322.patch Type: application/octet-stream Size: 615 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pcs.patch Type: application/octet-stream Size: 1150 bytes Desc: not available URL: From andreas at eversberg.eu Thu Nov 15 10:17:49 2012 From: andreas at eversberg.eu (jolly) Date: Thu, 15 Nov 2012 11:17:49 +0100 Subject: gsm322.c:arfcn2index patch In-Reply-To: References: Message-ID: <50A4C14D.2020704@eversberg.eu> hi joshua, i applied the patch for gsm322.c. i cannot apply the patch for rffe_dualband.c, because i am not into it. maybe anyone else can review it. best regards, andreas From 246tnt at gmail.com Thu Nov 15 10:59:27 2012 From: 246tnt at gmail.com (Sylvain Munaut) Date: Thu, 15 Nov 2012 11:59:27 +0100 Subject: gsm322.c:arfcn2index patch In-Reply-To: <50A4C14D.2020704@eversberg.eu> References: <50A4C14D.2020704@eversberg.eu> Message-ID: > i applied the patch for gsm322.c. i cannot apply the patch for > rffe_dualband.c, because i am not into it. maybe anyone else can review it. Nothing to review really ... if you apply it it'll break all DCS users. There is no way to detect which phone submodel we run on. Cheers, Sylvain From nkozina at ryerson.ca Thu Nov 15 23:02:57 2012 From: nkozina at ryerson.ca (Nikola Kozina) Date: Thu, 15 Nov 2012 18:02:57 -0500 Subject: gsm322.c:arfcn2index patch In-Reply-To: References: <50A4C14D.2020704@eversberg.eu> Message-ID: Hi Joshua, What problems are you having with osmocom-bb? It works fine for me on 850/1900 using the sylvain/testing branch (i think that's what it was) with similar patches to yours (the only difference is a patch related to simreader). Nik From jl at thre.at Tue Nov 20 03:21:14 2012 From: jl at thre.at (Joshua Lackey) Date: Mon, 19 Nov 2012 19:21:14 -0800 Subject: gsm322.c:arfcn2index patch In-Reply-To: References: <50A4C14D.2020704@eversberg.eu> Message-ID: I was going to say that I got sylvain/testing to work after a bit of playing around with. But I figured it was a useless thing to say unless I typed up the details. (Which I haven't done yet.) On Thu, Nov 15, 2012 at 3:02 PM, Nikola Kozina wrote: > Hi Joshua, > > What problems are you having with osmocom-bb? It works fine for me on > 850/1900 using the sylvain/testing branch (i think that's what it was) with > similar patches to yours (the only difference is a patch related to > simreader). > > Nik > -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Sun Nov 18 11:01:41 2012 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 18 Nov 2012 12:01:41 +0100 Subject: gsm322.c:arfcn2index patch In-Reply-To: References: <50A4C14D.2020704@eversberg.eu> Message-ID: <20121118110140.GO8595@prithivi.gnumonks.org> Hi Sylvain and others, On Thu, Nov 15, 2012 at 11:59:27AM +0100, Sylvain Munaut wrote: > > i applied the patch for gsm322.c. i cannot apply the patch for > > rffe_dualband.c, because i am not into it. maybe anyone else can review it. > > Nothing to review really ... if you apply it it'll break all DCS users. > There is no way to detect which phone submodel we run on. We should probably have a better solution than to manually patch the source. I could imagine: 1) build a DCS and a PCS version of the firmware images 2) have the user set a #define that is evaluated in the RFFE 3) simply include DCS and PCS support in the firmware builds and rely on a configuration file / 'mobile' to define what bands to use What do you think? -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From 246tnt at gmail.com Tue Nov 20 09:20:23 2012 From: 246tnt at gmail.com (Sylvain Munaut) Date: Tue, 20 Nov 2012 10:20:23 +0100 Subject: gsm322.c:arfcn2index patch In-Reply-To: <20121118110140.GO8595@prithivi.gnumonks.org> References: <50A4C14D.2020704@eversberg.eu> <20121118110140.GO8595@prithivi.gnumonks.org> Message-ID: Hi, > We should probably have a better solution than to manually patch the > source. I could imagine: > > 1) build a DCS and a PCS version of the firmware images That would require de-duplicating all the code for each target ... it's already a pain as it is. Or we just give up the idea of building all the fw image all the time and have like a menuconfig system, but that's a massive build system change. > 2) have the user set a #define that is evaluated in the RFFE Changing define or changing a DCS into PCS in a file doesn't change much. People won't read the doc anyway. > 3) simply include DCS and PCS support in the firmware builds and rely > on a configuration file / 'mobile' to define what bands to use mobile has a config file ... But it specifies which band to use, not the RF port on the RITA to use. There are (I have one) PCS phone that have the DCS input of the RITA connected and not the PCS one. (They're pretty much symmetrical, not internal differences) So that RFFE config specifies which internal RF port is connected, not the band to use. Then the internal sw logic will try to find how to configure the switch (like if mobile asks for a PCS ARFCN but the RFFE config says only the DCS RF port is connected, it will try using that port and not the PCS port of the RITA where there is nothing connected). Cheers, Sylvain From 246tnt at gmail.com Tue Nov 20 16:07:05 2012 From: 246tnt at gmail.com (Sylvain Munaut) Date: Tue, 20 Nov 2012 17:07:05 +0100 Subject: gsm322.c:arfcn2index patch In-Reply-To: References: <50A4C14D.2020704@eversberg.eu> <20121118110140.GO8595@prithivi.gnumonks.org> Message-ID: Hi, > There are (I have one) PCS phone that have the DCS input of the RITA > connected and not the PCS one. > (They're pretty much symmetrical, not internal differences) OTOH, It seems there isn't all that many of those phones (only the J100i and nobody really uses it AFAIK), the properly wired ones are more common. So the RFFE config could reflect that both DCS and PCS are wired and then it would just work for most users in normal situations. The down side is you then can't longer use a PCS phone in DCS band or a DCS phone in the PCS band ... Cheers, Sylvain From pabftk at gmail.com Fri Nov 16 12:38:48 2012 From: pabftk at gmail.com (Pavel Baturko) Date: Fri, 16 Nov 2012 12:38:48 +0000 Subject: [PATCH] Fix wrong printing of end freq in powerscan Message-ID: Hi All, This is small patch that fixes wrong printing of scanning frequencies due powerscan: <0003> gsm322.c:2794 Scanning power for all frequencies. <0003> gsm322.c:2855 Scanning frequencies. (0..0) .. <0003> gsm322.c:2855 Scanning frequencies. (512(DCS)..512(DCS)) .. <0003> gsm322.c:2855 Scanning frequencies. (955..955) with this fix: <0003> gsm322.c:2797 Scanning power for all frequencies. <0003> gsm322.c:2860 Scanning frequencies. (0..124) .. <0003> gsm322.c:2860 Scanning frequencies. (512(DCS)..885(DCS)) .. <0003> gsm322.c:2860 Scanning frequencies. (955..1023) Thanks, Pavel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: scan_freq_dup_text_fix.patch Type: application/octet-stream Size: 2353 bytes Desc: not available URL: From andreas at eversberg.eu Fri Nov 16 13:57:40 2012 From: andreas at eversberg.eu (Andreas Eversberg) Date: Fri, 16 Nov 2012 14:57:40 +0100 Subject: [PATCH] Fix wrong printing of end freq in powerscan In-Reply-To: References: Message-ID: <50A64654.2010405@eversberg.eu> Pavel Baturko wrote: > Hi All, > > This is small patch that fixes wrong printing of > scanning frequencies due powerscan: > applied, thanx! From akibsayyed at gmail.com Mon Nov 19 04:24:45 2012 From: akibsayyed at gmail.com (Akib Sayyed) Date: Mon, 19 Nov 2012 07:24:45 +0300 Subject: Using 900/1800 C118 on 1900 Message-ID: Guys is wanted to know if there is any tweak that can allow me to use 900/1800 C118 phone on 1900 band. please let me know. -- Akib Sayyed Matrix-Shell akibsayyed at gmail.com akibsayyed at matrixshell.com Mob:- +91-966-514-2243 -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Tue Nov 20 07:33:20 2012 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 20 Nov 2012 08:33:20 +0100 Subject: Using 900/1800 C118 on 1900 In-Reply-To: References: Message-ID: <20121120073320.GN8595@prithivi.gnumonks.org> On Mon, Nov 19, 2012 at 07:24:45AM +0300, Akib Sayyed wrote: > Guys is wanted to know if there is any tweak that can allow me to use > 900/1800 C118 phone on 1900 band. you have to remove the shielding cover and replace the 1800 band filters with footprint-compatible 1900 MHz filters. It's possible, but requires good SMD soldering skills and access to the right parts. You can also remove the filters completely. This will hovever significantly degrade receiver performance in the presence of out-of-band interferers. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From akibsayyed at gmail.com Tue Nov 20 07:37:41 2012 From: akibsayyed at gmail.com (Akib Sayyed) Date: Tue, 20 Nov 2012 10:37:41 +0300 Subject: Using 900/1800 C118 on 1900 In-Reply-To: <20121120073320.GN8595@prithivi.gnumonks.org> References: <20121120073320.GN8595@prithivi.gnumonks.org> Message-ID: phone with filter rework will work right and i also will be able to sniff traffic on 1900mhz witnh burst_ind.but my issue is how to tell code of app_ccch to sniff 1900 mhz instead of 1800 as they share same arfcn no?? On Tue, Nov 20, 2012 at 10:33 AM, Harald Welte wrote: > On Mon, Nov 19, 2012 at 07:24:45AM +0300, Akib Sayyed wrote: > > Guys is wanted to know if there is any tweak that can allow me to use > > 900/1800 C118 phone on 1900 band. > > you have to remove the shielding cover and replace the 1800 band filters > with footprint-compatible 1900 MHz filters. It's possible, but requires > good SMD soldering skills and access to the right parts. > > You can also remove the filters completely. This will hovever > significantly degrade receiver performance in the presence of > out-of-band interferers. > > -- > - Harald Welte > http://laforge.gnumonks.org/ > > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. > A6) > -- Akib Sayyed Matrix-Shell akibsayyed at gmail.com akibsayyed at matrixshell.com Mob:- +91-966-514-2243 -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Tue Nov 20 08:55:56 2012 From: 246tnt at gmail.com (Sylvain Munaut) Date: Tue, 20 Nov 2012 09:55:56 +0100 Subject: Using 900/1800 C118 on 1900 In-Reply-To: References: <20121120073320.GN8595@prithivi.gnumonks.org> Message-ID: On Tue, Nov 20, 2012 at 8:37 AM, Akib Sayyed wrote: > phone with filter rework will work right and i also will be able to sniff > traffic on 1900mhz witnh burst_ind.but my issue is how to tell code of > app_ccch to sniff 1900 mhz instead of 1800 as they share same arfcn no?? we have a flag called ARFCN_PCS that's defined to 0x8000. So if you want to go to ARFCN PCS 512 you set the arfcn to 0x8000 + 512 = 33280 From akibsayyed at gmail.com Sat Nov 24 13:54:49 2012 From: akibsayyed at gmail.com (Akib Sayyed) Date: Sat, 24 Nov 2012 16:54:49 +0300 Subject: Using 900/1800 C118 on 1900 In-Reply-To: References: <20121120073320.GN8595@prithivi.gnumonks.org> Message-ID: i ordered stuff to modify phones. just waiting for them to be delivered On Sat, Nov 24, 2012 at 3:48 PM, Marten Christophe wrote: > Hello Akib, > > > Have you able to sniff TCH channel or intercept other phone calls by > OsmocomBB > > Regards, > dev > > On Tue, Nov 20, 2012 at 7:37 AM, Akib Sayyed wrote: > > phone with filter rework will work right and i also will be able to sniff > > traffic on 1900mhz witnh burst_ind.but my issue is how to tell code of > > app_ccch to sniff 1900 mhz instead of 1800 as they share same arfcn no?? > > > > > > > > On Tue, Nov 20, 2012 at 10:33 AM, Harald Welte > wrote: > >> > >> On Mon, Nov 19, 2012 at 07:24:45AM +0300, Akib Sayyed wrote: > >> > Guys is wanted to know if there is any tweak that can allow me to use > >> > 900/1800 C118 phone on 1900 band. > >> > >> you have to remove the shielding cover and replace the 1800 band filters > >> with footprint-compatible 1900 MHz filters. It's possible, but requires > >> good SMD soldering skills and access to the right parts. > >> > >> You can also remove the filters completely. This will hovever > >> significantly degrade receiver performance in the presence of > >> out-of-band interferers. > >> > >> -- > >> - Harald Welte > >> http://laforge.gnumonks.org/ > >> > >> > ============================================================================ > >> "Privacy in residential applications is a desirable marketing option." > >> (ETSI EN 300 175-7 Ch. > >> A6) > > > > > > > > > > -- > > Akib Sayyed > > Matrix-Shell > > akibsayyed at gmail.com > > akibsayyed at matrixshell.com > > Mob:- +91-966-514-2243 > > > > > -- Akib Sayyed Matrix-Shell akibsayyed at gmail.com akibsayyed at matrixshell.com Mob:- +91-966-514-2243 -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas at eversberg.eu Wed Nov 21 12:34:27 2012 From: andreas at eversberg.eu (Andreas Eversberg) Date: Wed, 21 Nov 2012 13:34:27 +0100 Subject: osmocom-commitlog Digest, Vol 551, Issue 1 In-Reply-To: References: Message-ID: <50ACCA53.8010302@eversberg.eu> osmocom-commitlog-request at lists.osmocom.org wrote: > commit 73a809e57b8a531b9b8a33b6841ed3df2ea22620 > Author: Harald Welte > Date: Tue Nov 20 10:13:44 2012 +0100 > > Tell L1CTL_FBSB_REQ the expected received signal level > hi harald, please note that cell_log.c and mobile (gsm322.c) use signed uint8_t for real rx-level (dbm). i think you should use dbm2rxlev() before handing it to l1ctl_tx_fbsb_req(). regards, andreas From laforge at gnumonks.org Thu Nov 22 09:17:31 2012 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 22 Nov 2012 10:17:31 +0100 Subject: osmocom-commitlog Digest, Vol 551, Issue 1 In-Reply-To: <50ACCA53.8010302@eversberg.eu> References: <50ACCA53.8010302@eversberg.eu> Message-ID: <20121122091731.GU8595@prithivi.gnumonks.org> On Wed, Nov 21, 2012 at 01:34:27PM +0100, Andreas Eversberg wrote: > please note that cell_log.c and mobile (gsm322.c) use signed uint8_t > for real rx-level (dbm). i think you should use dbm2rxlev() before > handing it to l1ctl_tx_fbsb_req(). thanks, fix pushed. It would be a good idea to not call those fields 'rxlev' if they actually contain a 'receive level in dbm' but not a 'rxlev' value like in the specs. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From andreas at eversberg.eu Thu Nov 22 15:07:40 2012 From: andreas at eversberg.eu (jolly) Date: Thu, 22 Nov 2012 16:07:40 +0100 Subject: osmocom-commitlog Digest, Vol 551, Issue 1 In-Reply-To: <20121122091731.GU8595@prithivi.gnumonks.org> References: <50ACCA53.8010302@eversberg.eu> <20121122091731.GU8595@prithivi.gnumonks.org> Message-ID: <50AE3FBC.5050203@eversberg.eu> Harald Welte wrote: > On Wed, Nov 21, 2012 at 01:34:27PM +0100, Andreas Eversberg wrote: > >> please note that cell_log.c and mobile (gsm322.c) use signed uint8_t >> for real rx-level (dbm). i think you should use dbm2rxlev() before >> handing it to l1ctl_tx_fbsb_req(). >> > thanks, fix pushed. It would be a good idea to not call those fields > 'rxlev' if they actually contain a 'receive level in dbm' but not a > 'rxlev' value like in the specs. > > hi harald, yes, i just did (pushed) . also i was wrong that l1ctl_tx_fbdb_req of "mobile" requires conversion. it is already in correct range format. i fixed names and signess of rxlev / rxlev_dbm now. regards, andreas From avwiseav at gmail.com Thu Nov 22 08:51:38 2012 From: avwiseav at gmail.com (bob) Date: Thu, 22 Nov 2012 00:51:38 -0800 (PST) Subject: is my decode for efr decode right? Message-ID: <1353574298445-4025448.post@n3.nabble.com> Hi, list I write a decode for efr decode for TCH,but there some bug, and I have not a debug device, Can someone help me find the problem, Thanks! static void process_tch_efr(struct osmocom_ms *ms,struct l1ctl_burst_ind *bi) { int16_t rx_dbm; uint16_t arfcn; uint32_t fn,B; uint8_t cbits, tn, lch_idx; int ul, bid, i, k, length; sbit_t *bursts, mC[456]; ubit_t steal_bit[2], bt[114],convu[189],convd[189],tch_raw[260],TCHW[260],EFRBits[244],EFRAMR[8 + 244]; pbit_t voice[33]; /* Get params (Only for SDCCH and SACCH/{4,8,F,H}) */ arfcn = ntohs(bi->band_arfcn); rx_dbm = rxlev2dbm(bi->rx_level); fn = ntohl(bi->frame_nr); ul = !!(arfcn & ARFCN_UPLINK); cbits = bi->chan_nr >> 3; tn = bi->chan_nr & 7; B = -1; if((fn%13)%4 == 0) flag= 1; if(!flag) return; //B = count_tch % 8; B = (fn % 13) % 8; printf("fn % 26 = %d, fn % 13 = %d,B = %d\n",fn%26 ,fn%13 ,B); if (B == -1) return; /* Unpack (ignore hu/hl) */ osmo_pbit2ubit_ext(bt, 0, bi->bits, 0, 57, 0); osmo_pbit2ubit_ext(bt, 57, bi->bits, 57, 57, 0); //osmo_pbit2ubit_ext(steal_bit, 0 , bi->bits, 114 , 2 , 0); //printf("steal_bit %x , %x\n",steal_bit[0],steal_bit[1]); /* save stealing flags */ hl[B] = !!(bi->bits[14] & 0x10); // hl 57 hu[B] = !!(bi->bits[14] & 0x20); // hu 58 printf("steal_bit %x , %x\n", hl[B],hu[B]); /* Convert to softbits */ for (i=0; i<114; i++) app_state.mI[B][i] = bt[i] ? - (bi->snr >> 1) : (bi->snr >> 1); count_tch++; // Deinterleave according to the diagonal "phase" of B. // See GSM 05.03 3.1.3. // Deinterleaves i[] to c[] if((B % 4 ==3)&&(count_tch >= 7)){ if(B == 3) { if(!hl[0] && !hl[1] && !hl[2] && !hl[3] && !hu[4] && !hu[5] && !hu[6] && !hu[7]) { tch_deinterleave(mC, 4); } else if(hl[0] && hl[1] && hl[2] && hl[3] && hu[4] && hu[5] && hu[6] && hu[7]) { printf(" may be FACCH.\n"); return; }else{ printf("not a speech frame.\n"); return; } }else{ if(!hl[4] && !hl[5] && !hl[6] && !hl[7] && !hu[0] && !hu[1] && !hu[2] && !hu[3]) { tch_deinterleave(mC,0); } else if(hl[4] && hl[5] && hl[6] && hl[7] && hu[0] && hu[1] && hu[2] && hu[3]) { printf(" may be FACCH.\n"); return; }else{ printf("not a speech frame.\n"); return; } } //mC is soft bit, and must convert to ubit type for (k = 0; k < 78; k++) { if(mC[378 + k] < 0){ tch_raw[182 + k] = 1; }else{ tch_raw[182 + k] = 0; } } osmo_conv_decode(&conv_tch_afs_12_2, mC, convu); // 3.1.2.1 // copy class 1 bits u[] to d[] for (k = 0; k <= 90; k++) { convd[2*k] = convu[k]; convd[2*k+1] = convu[184-k]; } memcpy(tch_raw,convd,182); // the last 78 bit has been stored! //now only process EFR or AMR 12_2, fix me! tch_unmap(gsm660_bitorder, 260, TCHW, tch_raw); // Remove repeating bits and CRC to get raw EFR frame (244 bits) for (k=0; k<71; k++) EFRBits[k] = TCHW[k]; for (k=73; k<123; k++) EFRBits[k-2] = TCHW[k]; for (k=125; k<178; k++) EFRBits[k-4] = TCHW[k]; for (k=180; k<230; k++) EFRBits[k-6] = TCHW[k]; for (k=232; k<252; k++) EFRBits[k-8] = TCHW[k]; // Map bits as AMR 12.2k tch_map(gsm690_12_2_bitorder, 244, EFRAMR + 8,EFRBits); fillField(EFRAMR, 0, 0x3c, 8); length = osmo_ubit2pbit_ext(voice, 0, EFRAMR, 0, 8 + gsm690_12_2_len, 0); fwrite(voice, 1, length, d_speech_file); } } -- View this message in context: http://baseband-devel.722152.n3.nabble.com/is-my-decode-for-efr-decode-right-tp4025448.html Sent from the baseband-devel mailing list archive at Nabble.com. From lonelysurfer at web.de Fri Nov 23 16:45:48 2012 From: lonelysurfer at web.de (lonelysurfer) Date: Fri, 23 Nov 2012 08:45:48 -0800 (PST) Subject: is my decode for efr decode right? In-Reply-To: <1353574298445-4025448.post@n3.nabble.com> References: <1353574298445-4025448.post@n3.nabble.com> Message-ID: <1353689148961-4025451.post@n3.nabble.com> if u are using osmo_conv_decode with conv_tch_afs_12_2 u are getting 244bits and not 260. So "Remove repeating bits and CRC to get raw EFR frame (244 bits)" goes wrong. Airprobe is using this, because it uses the same viterbi-option for FR and EFR. -- View this message in context: http://baseband-devel.722152.n3.nabble.com/is-my-decode-for-efr-decode-right-tp4025448p4025451.html Sent from the baseband-devel mailing list archive at Nabble.com. From akibsayyed at gmail.com Tue Nov 27 09:30:30 2012 From: akibsayyed at gmail.com (Akib Sayyed) Date: Tue, 27 Nov 2012 12:30:30 +0300 Subject: Unable to flash firmware Message-ID: Dear all i am unable to flash firmware of C118 with RSSI.bin i am using 64bit Ubuntu.and 64bit gnu toolchain -- Akib Sayyed Matrix-Shell akibsayyed at gmail.com akibsayyed at matrixshell.com Mob:- +91-966-514-2243 -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.huemer at xx.vu Tue Nov 27 09:57:01 2012 From: alexander.huemer at xx.vu (Alexander Huemer) Date: Tue, 27 Nov 2012 10:57:01 +0100 Subject: Unable to flash firmware In-Reply-To: References: Message-ID: <20121127095701.GA27872@de.xx.vu> On Tue, Nov 27, 2012 at 12:30:30PM +0300, Akib Sayyed wrote: > Dear all i am unable to flash firmware of C118 with RSSI.bin > > i am using 64bit Ubuntu.and 64bit gnu toolchain Thanks for letting everybody know. Maybe you can help me with a different problem. I am unable to open the door of my microwave oven. I am using 220V mains power. What's wrong with it? Kind regards, -Alex From akibsayyed at gmail.com Tue Nov 27 10:12:06 2012 From: akibsayyed at gmail.com (Akib Sayyed) Date: Tue, 27 Nov 2012 13:12:06 +0300 Subject: Unable to flash firmware In-Reply-To: <20121127095701.GA27872@de.xx.vu> References: <20121127095701.GA27872@de.xx.vu> Message-ID: damn for got to put error codes. :P Loading 8192 bytes of memory at 0x10000 in chip 0 from file compal_loader.bin bad crc 93fc (not 4190) at offset 0x00000000 status 8491490, aborting root at akib-ThinkPad-T410:/opt/osmocom/gsm-debug/src# On Tue, Nov 27, 2012 at 12:57 PM, Alexander Huemer wrote: > On Tue, Nov 27, 2012 at 12:30:30PM +0300, Akib Sayyed wrote: > > Dear all i am unable to flash firmware of C118 with RSSI.bin > > > > i am using 64bit Ubuntu.and 64bit gnu toolchain > > Thanks for letting everybody know. > > Maybe you can help me with a different problem. > I am unable to open the door of my microwave oven. > I am using 220V mains power. > What's wrong with it? > > Kind regards, > -Alex > > -- Akib Sayyed Matrix-Shell akibsayyed at gmail.com akibsayyed at matrixshell.com Mob:- +91-966-514-2243 -------------- next part -------------- An HTML attachment was scrubbed... URL: From akibsayyed at gmail.com Tue Nov 27 10:15:12 2012 From: akibsayyed at gmail.com (Akib Sayyed) Date: Tue, 27 Nov 2012 13:15:12 +0300 Subject: Unable to flash firmware In-Reply-To: References: <20121127095701.GA27872@de.xx.vu> Message-ID: let me add more to it . dumping works fine root at akib-ThinkPad-T410:/opt/osmocom/gsm-debug/src# host/osmocon/osmoload memdump 0x000000 0x2000 compal_loader.bin Dumping 8192 bytes of memory at 0x0 to file compal_loader.bin ...................................done. root at akib-ThinkPad-T410:/opt/osmocom/gsm-debug/src# unlocking ad erasing work fine only while programming there is an issue root at akib-ThinkPad-T410:/opt/osmocom/gsm-debug/src# host/osmocon/osmoload fprogram 0 0x010000 compal_loader.bin Loading 8192 bytes of memory at 0x10000 in chip 0 from file compal_loader.bin bad crc f6ce (not 4190) at offset 0x00000000 status 8492002, aborting root at akib-ThinkPad-T410:/opt/osmocom/gsm-debug/src# On Tue, Nov 27, 2012 at 1:12 PM, Akib Sayyed wrote: > damn for got to put error codes. :P > Loading 8192 bytes of memory at 0x10000 in chip 0 from file > compal_loader.bin > > bad crc 93fc (not 4190) at offset 0x00000000 > status 8491490, aborting > root at akib-ThinkPad-T410:/opt/osmocom/gsm-debug/src# > > > > On Tue, Nov 27, 2012 at 12:57 PM, Alexander Huemer > wrote: > >> On Tue, Nov 27, 2012 at 12:30:30PM +0300, Akib Sayyed wrote: >> > Dear all i am unable to flash firmware of C118 with RSSI.bin >> > >> > i am using 64bit Ubuntu.and 64bit gnu toolchain >> >> Thanks for letting everybody know. >> >> Maybe you can help me with a different problem. >> I am unable to open the door of my microwave oven. >> I am using 220V mains power. >> What's wrong with it? >> >> Kind regards, >> -Alex >> >> > > > -- > Akib Sayyed > Matrix-Shell > akibsayyed at gmail.com > akibsayyed at matrixshell.com > Mob:- +91-966-514-2243 > > > -- Akib Sayyed Matrix-Shell akibsayyed at gmail.com akibsayyed at matrixshell.com Mob:- +91-966-514-2243 -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.pcguy.inci at gmail.com Tue Nov 27 12:07:30 2012 From: chris.pcguy.inci at gmail.com (Christian Inci) Date: Tue, 27 Nov 2012 13:07:30 +0100 Subject: baseband-devel Digest, Vol 34, Issue 17 In-Reply-To: References: Message-ID: <50B4AD02.9040009@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'd the same problem. Now, my C118 is bricked. :-( I'm now waiting for my Bus Pirate in order to unbrick it. Does anybody knows a fast way to do it? Should I use the test points (maybe those who are accessible from the battery compartment) or even directly to the nor flash? Many thanks in advance! - -Chris On 11/27/2012 12:00 PM, baseband-devel-request at lists.osmocom.org wrote: > Send baseband-devel mailing list submissions to > baseband-devel at lists.osmocom.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.osmocom.org/mailman/listinfo/baseband-devel or, via > email, send a message with subject or body 'help' to > baseband-devel-request at lists.osmocom.org > > You can reach the person managing the list at > baseband-devel-owner at lists.osmocom.org > > When replying, please edit your Subject line so it is more > specific than "Re: Contents of baseband-devel digest..." > > > Today's Topics: > > 1. Unable to flash firmware (Akib Sayyed) 2. Re: Unable to flash > firmware (Alexander Huemer) 3. Re: Unable to flash firmware (Akib > Sayyed) 4. Re: Unable to flash firmware (Akib Sayyed) > > > ---------------------------------------------------------------------- > > Message: 1 Date: Tue, 27 Nov 2012 12:30:30 +0300 From: Akib Sayyed > To: baseband-devel at lists.osmocom.org > Subject: Unable to flash firmware Message-ID: > > > Content-Type: text/plain; charset="utf-8" > > Dear all i am unable to flash firmware of C118 with RSSI.bin > > i am using 64bit Ubuntu.and 64bit gnu toolchain > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBAgAGBQJQtK0BAAoJEDfL/pqB6n6N3dAQAJLpkD+4MVJbzfBHDt6mepN6 OcXyX/EbgZkN7zZY4ulRadlqyMvq7MH7pN9zv1sRk+2oMWRTEOwHeT1xG8Lfoukp J4GMTY21bv6Ov0QLQOisxydRH4TQ7riJGfSbATPA6VBUMQWuxrws140BFDslXaPk 8Vk9o5a2G9kQTbLdJp/tqxjKnlLZ3m22qSgph0O1uV7w4e82tc45rOX8FiAps7f2 cCjGfbphjpb+GVx/OT5mSTaKseYAPyLsm2n1CvTbFYm0OVlJ9d8Pp/iVluQdrPdQ pBLpF/MFPdqw7swUTXTSjL5PFjhBnwz1b0hImdoFBG/uHRGrU8l8sG4ll553DWtw OnPEo1lEDkPdoRY0vpqYWVhrf6t1b54k5cc+ISKVvLweRoscMjkU7DBdzwuSyIQv FVLk9cLatp33ogCqpzinebEBNl6eQpa869c+MC2ii/Y+A82QRiyhSs6JMmYOCYRg jMiw/0lZIZcUEzHfGm75X7LnyfEyPDaG39MWl8m/xU/1aQhZHN4p23sKrqEAaZQp z439nICJoCybsPsPDZiz1XEqcD4lNVVWvba6Ofd+cNKNzSJb3Y8IjUFFPwPyCCw6 dlkgqo52xBnQvb3PzAv+JTUkFesdGqyvcSOMsnFxB8zZGl3pkRn0XPnX+0TsLZdC B701/yHCM9CXYeckOYft =Rsu7 -----END PGP SIGNATURE----- From akibsayyed at gmail.com Tue Nov 27 13:06:21 2012 From: akibsayyed at gmail.com (Akib Sayyed) Date: Tue, 27 Nov 2012 16:06:21 +0300 Subject: baseband-devel Digest, Vol 34, Issue 17 In-Reply-To: <50B4AD02.9040009@gmail.com> References: <50B4AD02.9040009@gmail.com> Message-ID: what os you are using?? i tried on ubuntu10.04 i386 with older version of osmocom and it worked?? I think there is an issue with os support. still no idea. and my firmware did worked well. there are some bugs but will take care of them soon. On Tue, Nov 27, 2012 at 3:07 PM, Christian Inci wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I'd the same problem. Now, my C118 is bricked. :-( > > I'm now waiting for my Bus Pirate in order to unbrick it. > > Does anybody knows a fast way to do it? > > Should I use the test points (maybe those who are accessible from the > battery compartment) or even directly to the nor flash? > > Many thanks in advance! > > - -Chris > > On 11/27/2012 12:00 PM, baseband-devel-request at lists.osmocom.org wrote: > > Send baseband-devel mailing list submissions to > > baseband-devel at lists.osmocom.org > > > > To subscribe or unsubscribe via the World Wide Web, visit > > https://lists.osmocom.org/mailman/listinfo/baseband-devel or, via > > email, send a message with subject or body 'help' to > > baseband-devel-request at lists.osmocom.org > > > > You can reach the person managing the list at > > baseband-devel-owner at lists.osmocom.org > > > > When replying, please edit your Subject line so it is more > > specific than "Re: Contents of baseband-devel digest..." > > > > > > Today's Topics: > > > > 1. Unable to flash firmware (Akib Sayyed) 2. Re: Unable to flash > > firmware (Alexander Huemer) 3. Re: Unable to flash firmware (Akib > > Sayyed) 4. Re: Unable to flash firmware (Akib Sayyed) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 Date: Tue, 27 Nov 2012 12:30:30 +0300 From: Akib Sayyed > > To: baseband-devel at lists.osmocom.org > > Subject: Unable to flash firmware Message-ID: > > > > > > > Content-Type: text/plain; charset="utf-8" > > > > Dear all i am unable to flash firmware of C118 with RSSI.bin > > > > i am using 64bit Ubuntu.and 64bit gnu toolchain > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.19 (GNU/Linux) > Comment: Using GnuPG with undefined - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJQtK0BAAoJEDfL/pqB6n6N3dAQAJLpkD+4MVJbzfBHDt6mepN6 > OcXyX/EbgZkN7zZY4ulRadlqyMvq7MH7pN9zv1sRk+2oMWRTEOwHeT1xG8Lfoukp > J4GMTY21bv6Ov0QLQOisxydRH4TQ7riJGfSbATPA6VBUMQWuxrws140BFDslXaPk > 8Vk9o5a2G9kQTbLdJp/tqxjKnlLZ3m22qSgph0O1uV7w4e82tc45rOX8FiAps7f2 > cCjGfbphjpb+GVx/OT5mSTaKseYAPyLsm2n1CvTbFYm0OVlJ9d8Pp/iVluQdrPdQ > pBLpF/MFPdqw7swUTXTSjL5PFjhBnwz1b0hImdoFBG/uHRGrU8l8sG4ll553DWtw > OnPEo1lEDkPdoRY0vpqYWVhrf6t1b54k5cc+ISKVvLweRoscMjkU7DBdzwuSyIQv > FVLk9cLatp33ogCqpzinebEBNl6eQpa869c+MC2ii/Y+A82QRiyhSs6JMmYOCYRg > jMiw/0lZIZcUEzHfGm75X7LnyfEyPDaG39MWl8m/xU/1aQhZHN4p23sKrqEAaZQp > z439nICJoCybsPsPDZiz1XEqcD4lNVVWvba6Ofd+cNKNzSJb3Y8IjUFFPwPyCCw6 > dlkgqo52xBnQvb3PzAv+JTUkFesdGqyvcSOMsnFxB8zZGl3pkRn0XPnX+0TsLZdC > B701/yHCM9CXYeckOYft > =Rsu7 > -----END PGP SIGNATURE----- > > -- Akib Sayyed Matrix-Shell akibsayyed at gmail.com akibsayyed at matrixshell.com Mob:- +91-966-514-2243 -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.pcguy.inci at gmail.com Tue Nov 27 13:22:32 2012 From: chris.pcguy.inci at gmail.com (Christian Inci) Date: Tue, 27 Nov 2012 14:22:32 +0100 Subject: baseband-devel Digest, Vol 34, Issue 17 In-Reply-To: References: <50B4AD02.9040009@gmail.com> Message-ID: <50B4BE98.6090100@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've tried it using gentoo amd64 unstable and osmocoms git trunk. On 11/27/2012 02:06 PM, Akib Sayyed wrote: > what os you are using?? i tried on ubuntu10.04 i386 with older > version of osmocom and it worked?? I think there is an issue with > os support. still no idea. > > and my firmware did worked well. there are some bugs but will take > care of them soon. > > > On Tue, Nov 27, 2012 at 3:07 PM, Christian Inci > wrote: > > I'd the same problem. Now, my C118 is bricked. :-( > > I'm now waiting for my Bus Pirate in order to unbrick it. > > Does anybody knows a fast way to do it? > > Should I use the test points (maybe those who are accessible from > the battery compartment) or even directly to the nor flash? > > Many thanks in advance! > > -Chris > > On 11/27/2012 12:00 PM, baseband-devel-request at lists.osmocom.org > wrote: >>>> Send baseband-devel mailing list submissions to >>>> baseband-devel at lists.osmocom.org >>>> >>>> To subscribe or unsubscribe via the World Wide Web, visit >>>> https://lists.osmocom.org/mailman/listinfo/baseband-devel or, >>>> via email, send a message with subject or body 'help' to >>>> baseband-devel-request at lists.osmocom.org >>>> >>>> You can reach the person managing the list at >>>> baseband-devel-owner at lists.osmocom.org >>>> >>>> When replying, please edit your Subject line so it is more >>>> specific than "Re: Contents of baseband-devel digest..." >>>> >>>> >>>> Today's Topics: >>>> >>>> 1. Unable to flash firmware (Akib Sayyed) 2. Re: Unable to >>>> flash firmware (Alexander Huemer) 3. Re: Unable to flash >>>> firmware (Akib Sayyed) 4. Re: Unable to flash firmware (Akib >>>> Sayyed) >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> >>>> >>>> Message: 1 Date: Tue, 27 Nov 2012 12:30:30 +0300 From: Akib Sayyed >>>> To: baseband-devel at lists.osmocom.org >>>> Subject: Unable to flash firmware Message-ID: >>>> >>>> >>>> > >>>> Content-Type: text/plain; charset="utf-8" >>>> >>>> Dear all i am unable to flash firmware of C118 with RSSI.bin >>>> >>>> i am using 64bit Ubuntu.and 64bit gnu toolchain >>>> > >> >> > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBAgAGBQJQtL6WAAoJEDfL/pqB6n6NvREQAKgcVvio+Tu1wqQplosmrnuu eT0P8H8GtO8FJSZdbOGiMuGNR0ohcCl2JaRUJD0hC70lqsFpzC7/S2ikU8fNH9Rd PFy11ee46jw8YNiZzD0RCNLsyLDV9FVcfMe3HGONqxEibaD3ErfgGHwpXUaibvb9 pYt7DaV9wW6ZGTOTJtQG2NwTe4aiN4mK+YSGc2SEmRdfDUmNENJCUBXEl/nd0hmn CTOhTN24O1on0weCYxV3/43TM7VtJQWyW/H2UPF17/tix9vrQlCbDxCEbnZCYdWY vn3LXnG+jjQOJiK/ScJfqBrdTdOw7RwCCE03jPw5zfrOIgvuxpwC9YbbUKKeNqd9 UKy5XADzt/OjAtM0eLZkA16+H5Irs+kBVAULrVFEjIeWtbAaaY3TP4wT9TZewuEU /4TqnsnG4evcKf3/w7PJWlG5xhsEYnHV7ACFOOyFF4sxu38LatVAS22Ike3CSbnk AhFC1E2dgljXuwJSuW+yzTlQHzO7L7ZV6LznxYrp0kBiibYMgLfqa7Yj6DNWwroc /cgMf9C06Xu8mXfBDMoevHUUwPfokYjm306cge0LiMVD1eZmda/hRRNOqKBIWUue ipdHNVrUtikJcJYAcs/0zqMfm02ma4Z0p3oxOCwPCeWictCnFQulVy7hcrQI3lkR stTEpJ4X/s3bBWWqrRub =OSns -----END PGP SIGNATURE----- From akibsayyed at gmail.com Tue Nov 27 13:26:53 2012 From: akibsayyed at gmail.com (Akib Sayyed) Date: Tue, 27 Nov 2012 16:26:53 +0300 Subject: baseband-devel Digest, Vol 34, Issue 17 In-Reply-To: <50B4BE98.6090100@gmail.com> References: <50B4AD02.9040009@gmail.com> <50B4BE98.6090100@gmail.com> Message-ID: I suggest dont use 64bit OS use 32bit os that much better. On Tue, Nov 27, 2012 at 4:22 PM, Christian Inci wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I've tried it using gentoo amd64 unstable and osmocoms git trunk. > > On 11/27/2012 02:06 PM, Akib Sayyed wrote: > > what os you are using?? i tried on ubuntu10.04 i386 with older > > version of osmocom and it worked?? I think there is an issue with > > os support. still no idea. > > > > and my firmware did worked well. there are some bugs but will take > > care of them soon. > > > > > > On Tue, Nov 27, 2012 at 3:07 PM, Christian Inci > > wrote: > > > > I'd the same problem. Now, my C118 is bricked. :-( > > > > I'm now waiting for my Bus Pirate in order to unbrick it. > > > > Does anybody knows a fast way to do it? > > > > Should I use the test points (maybe those who are accessible from > > the battery compartment) or even directly to the nor flash? > > > > Many thanks in advance! > > > > -Chris > > > > On 11/27/2012 12:00 PM, baseband-devel-request at lists.osmocom.org > > wrote: > >>>> Send baseband-devel mailing list submissions to > >>>> baseband-devel at lists.osmocom.org > >>>> > >>>> To subscribe or unsubscribe via the World Wide Web, visit > >>>> https://lists.osmocom.org/mailman/listinfo/baseband-devel or, > >>>> via email, send a message with subject or body 'help' to > >>>> baseband-devel-request at lists.osmocom.org > >>>> > >>>> You can reach the person managing the list at > >>>> baseband-devel-owner at lists.osmocom.org > >>>> > >>>> When replying, please edit your Subject line so it is more > >>>> specific than "Re: Contents of baseband-devel digest..." > >>>> > >>>> > >>>> Today's Topics: > >>>> > >>>> 1. Unable to flash firmware (Akib Sayyed) 2. Re: Unable to > >>>> flash firmware (Alexander Huemer) 3. Re: Unable to flash > >>>> firmware (Akib Sayyed) 4. Re: Unable to flash firmware (Akib > >>>> Sayyed) > >>>> > >>>> > >>>> ---------------------------------------------------------------------- > >>>> > >>>> > >>>> > Message: 1 Date: Tue, 27 Nov 2012 12:30:30 +0300 From: Akib Sayyed > >>>> To: baseband-devel at lists.osmocom.org > >>>> Subject: Unable to flash firmware Message-ID: > >>>> > >>>> > >>>> > > > >>>> > Content-Type: text/plain; charset="utf-8" > >>>> > >>>> Dear all i am unable to flash firmware of C118 with RSSI.bin > >>>> > >>>> i am using 64bit Ubuntu.and 64bit gnu toolchain > >>>> > > > >> > >> > > > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.19 (GNU/Linux) > Comment: Using GnuPG with undefined - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJQtL6WAAoJEDfL/pqB6n6NvREQAKgcVvio+Tu1wqQplosmrnuu > eT0P8H8GtO8FJSZdbOGiMuGNR0ohcCl2JaRUJD0hC70lqsFpzC7/S2ikU8fNH9Rd > PFy11ee46jw8YNiZzD0RCNLsyLDV9FVcfMe3HGONqxEibaD3ErfgGHwpXUaibvb9 > pYt7DaV9wW6ZGTOTJtQG2NwTe4aiN4mK+YSGc2SEmRdfDUmNENJCUBXEl/nd0hmn > CTOhTN24O1on0weCYxV3/43TM7VtJQWyW/H2UPF17/tix9vrQlCbDxCEbnZCYdWY > vn3LXnG+jjQOJiK/ScJfqBrdTdOw7RwCCE03jPw5zfrOIgvuxpwC9YbbUKKeNqd9 > UKy5XADzt/OjAtM0eLZkA16+H5Irs+kBVAULrVFEjIeWtbAaaY3TP4wT9TZewuEU > /4TqnsnG4evcKf3/w7PJWlG5xhsEYnHV7ACFOOyFF4sxu38LatVAS22Ike3CSbnk > AhFC1E2dgljXuwJSuW+yzTlQHzO7L7ZV6LznxYrp0kBiibYMgLfqa7Yj6DNWwroc > /cgMf9C06Xu8mXfBDMoevHUUwPfokYjm306cge0LiMVD1eZmda/hRRNOqKBIWUue > ipdHNVrUtikJcJYAcs/0zqMfm02ma4Z0p3oxOCwPCeWictCnFQulVy7hcrQI3lkR > stTEpJ4X/s3bBWWqrRub > =OSns > -----END PGP SIGNATURE----- > -- Akib Sayyed Matrix-Shell akibsayyed at gmail.com akibsayyed at matrixshell.com Mob:- +91-966-514-2243 -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas at eversberg.eu Tue Nov 27 16:25:45 2012 From: andreas at eversberg.eu (Andreas Eversberg) Date: Tue, 27 Nov 2012 17:25:45 +0100 Subject: osmocom-commitlog Digest, Vol 557, Issue 1 In-Reply-To: References: Message-ID: <50B4E989.8070101@eversberg.eu> osmocom-commitlog-request at lists.osmocom.org wrote: > The branch, zecke/work-with-nitb has been created > at 2076448d458ce1271dcd4d584fe276a8b8857e35 (commit) > > - Log ----------------------------------------------------------------- > http://cgit.osmocom.org/cgit/osmocom-bb/commit/?id=2076448d458ce1271dcd4d584fe276a8b8857e35 > > commit 2076448d458ce1271dcd4d584fe276a8b8857e35 > Author: Holger Hans Peter Freyther > Date: Mon Nov 26 17:15:07 2012 +0100 > > mobile: Do the LU with a IMSI... to deal with changing NITBs.. > > NITB will not ask for the IMSI if the TMSI is not known... work around > and do the LU with the IMSI.. hi holger, i saw your patch, but i did not like it. i just breaks the way location updating is done by standard. it is a workaround and not committed to master, but i think this should be an option for a baseband stack that is designed to test an play with. therefore i made a patch to configure this option via vty. it is not tested, but it obviously should work. regards, andreas From jolly at eversberg.eu Tue Nov 27 16:18:57 2012 From: jolly at eversberg.eu (Andreas Eversberg) Date: Tue, 27 Nov 2012 17:18:57 +0100 Subject: [PATCH] Add option to force location updating with IMSI, event if TMSI is valid Message-ID: To set this option, enter VTY: enable conf t ms 1 location-updating imsi-only write --- .../layer23/include/osmocom/bb/mobile/settings.h | 1 + src/host/layer23/src/mobile/gsm48_mm.c | 2 +- src/host/layer23/src/mobile/vty_interface.c | 33 ++++++++++++++++++- 3 files changed, 33 insertions(+), 3 deletions(-) diff --git a/src/host/layer23/include/osmocom/bb/mobile/settings.h b/src/host/layer23/include/osmocom/bb/mobile/settings.h index fae1220..6ff8b12 100644 --- a/src/host/layer23/include/osmocom/bb/mobile/settings.h +++ b/src/host/layer23/include/osmocom/bb/mobile/settings.h @@ -51,6 +51,7 @@ struct gsm_settings { uint16_t stick_arfcn; uint8_t skip_max_per_band; uint8_t no_lupd; + uint8_t lupd_imsi; uint8_t no_neighbour; /* supported by configuration */ diff --git a/src/host/layer23/src/mobile/gsm48_mm.c b/src/host/layer23/src/mobile/gsm48_mm.c index 0598768..06f6629 100644 --- a/src/host/layer23/src/mobile/gsm48_mm.c +++ b/src/host/layer23/src/mobile/gsm48_mm.c @@ -2358,7 +2358,7 @@ static int gsm48_mm_tx_loc_upd_req(struct osmocom_ms *ms) gsm48_encode_classmark1(&nlu->classmark1, sup->rev_lev, sup->es_ind, set->a5_1, pwr_lev); /* MI */ - if (0 && subscr->tmsi != 0xffffffff) { /* have TMSI ? */ + if (!set->lupd_imsi && subscr->tmsi != 0xffffffff) { /* have TMSI ? */ gsm48_encode_mi(buf, NULL, ms, GSM_MI_TYPE_TMSI); LOGP(DMM, LOGL_INFO, " using TMSI 0x%08x\n", subscr->tmsi); } else { diff --git a/src/host/layer23/src/mobile/vty_interface.c b/src/host/layer23/src/mobile/vty_interface.c index 4d7f6a2..e6add60 100644 --- a/src/host/layer23/src/mobile/vty_interface.c +++ b/src/host/layer23/src/mobile/vty_interface.c @@ -1334,6 +1334,9 @@ static void config_write_ms(struct vty *vty, struct osmocom_ms *ms) if (!hide_default || set->no_lupd) vty_out(vty, " %slocation-updating%s", (set->no_lupd) ? "no " : "", VTY_NEWLINE); + if (!hide_default || set->lupd_imsi) + vty_out(vty, " %slocation-updating imsi-only%s", + (set->lupd_imsi) ? "" : "no ", VTY_NEWLINE); if (!hide_default || set->no_neighbour) vty_out(vty, " %sneighbour-measurement%s", (set->no_neighbour) ? "no " : "", VTY_NEWLINE); @@ -1893,7 +1896,7 @@ DEFUN(cfg_ms_no_stick, cfg_ms_no_stick_cmd, "no stick", } DEFUN(cfg_ms_lupd, cfg_ms_lupd_cmd, "location-updating", - "Allow location updating") + "Do location updating") { struct osmocom_ms *ms = vty->index; struct gsm_settings *set = &ms->settings; @@ -1904,7 +1907,7 @@ DEFUN(cfg_ms_lupd, cfg_ms_lupd_cmd, "location-updating", } DEFUN(cfg_ms_no_lupd, cfg_ms_no_lupd_cmd, "no location-updating", - NO_STR "Do not allow location updating") + NO_STR "Do not perform location updating") { struct osmocom_ms *ms = vty->index; struct gsm_settings *set = &ms->settings; @@ -1914,6 +1917,30 @@ DEFUN(cfg_ms_no_lupd, cfg_ms_no_lupd_cmd, "no location-updating", return CMD_SUCCESS; } +DEFUN(cfg_ms_lupd_imsi, cfg_ms_lupd_imsi_cmd, "location-updating imsi-only", + "Do location updating\nAlways use IMSI to perform location updating") +{ + struct osmocom_ms *ms = vty->index; + struct gsm_settings *set = &ms->settings; + + set->lupd_imsi = 1; + + return CMD_SUCCESS; +} + +DEFUN(cfg_ms_no__imsilupd, cfg_ms_no_lupd_imsi_cmd, + "no location-updating imsi-only", + NO_STR "Do not perform location updating\n" + "Do not force location updating with IMSI, if TMSI is valid") +{ + struct osmocom_ms *ms = vty->index; + struct gsm_settings *set = &ms->settings; + + set->lupd_imsi = 0; + + return CMD_SUCCESS; +} + DEFUN(cfg_codec_full, cfg_ms_codec_full_cmd, "codec full-speed", "Enable codec\nFull speed speech codec") { @@ -2821,6 +2848,8 @@ int ms_vty_init(void) install_element(MS_NODE, &cfg_ms_no_stick_cmd); install_element(MS_NODE, &cfg_ms_lupd_cmd); install_element(MS_NODE, &cfg_ms_no_lupd_cmd); + install_element(MS_NODE, &cfg_ms_lupd_imsi_cmd); + install_element(MS_NODE, &cfg_ms_no_lupd_imsi_cmd); install_element(MS_NODE, &cfg_ms_codec_full_cmd); install_element(MS_NODE, &cfg_ms_codec_full_pref_cmd); install_element(MS_NODE, &cfg_ms_codec_half_cmd); -- 1.7.3.4 --------------030505010406090507000203-- From holger at freyther.de Tue Nov 27 17:38:47 2012 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Tue, 27 Nov 2012 18:38:47 +0100 Subject: osmocom-commitlog Digest, Vol 557, Issue 1 In-Reply-To: <50B4E989.8070101@eversberg.eu> References: <50B4E989.8070101@eversberg.eu> Message-ID: <20121127173847.GH30675@xiaoyu.lan> On Tue, Nov 27, 2012 at 05:25:45PM +0100, Andreas Eversberg wrote: > hi holger, hi Andreas, yes it is a hack and has only been pushed to my zecke/work-with-nitb branch. > > i saw your patch, but i did not like it. i just breaks the way > location updating is done by standard. it is a workaround and not > committed to master, but i think this should be an option for a > baseband stack that is designed to test an play with. therefore i > made a patch to configure this option via vty. it is not tested, but > it obviously should work. Thanks for the patch. I wonder if something like removing the TMSI from the SIM Card as a VTY command might be better? I triggered this by deleting my hlr.sqlite3 and 'mobile' came back with an invalid TMSI and the NITB does not ask for the IMSI. From andreas at eversberg.eu Tue Nov 27 18:40:29 2012 From: andreas at eversberg.eu (Andreas Eversberg) Date: Tue, 27 Nov 2012 19:40:29 +0100 Subject: osmocom-commitlog Digest, Vol 557, Issue 1 In-Reply-To: <20121127173847.GH30675@xiaoyu.lan> References: <50B4E989.8070101@eversberg.eu> <20121127173847.GH30675@xiaoyu.lan> Message-ID: <50B5091D.4070004@eversberg.eu> Holger Hans Peter Freyther wrote: > On Tue, Nov 27, 2012 at 05:25:45PM +0100, Andreas Eversberg wrote: >> hi holger, > hi Andreas, > > yes it is a hack and has only been pushed to my zecke/work-with-nitb > branch. > >> i saw your patch, but i did not like it. i just breaks the way >> location updating is done by standard. it is a workaround and not >> committed to master, but i think this should be an option for a >> baseband stack that is designed to test an play with. therefore i >> made a patch to configure this option via vty. it is not tested, but >> it obviously should work. > Thanks for the patch. I wonder if something like removing the TMSI > from the SIM Card as a VTY command might be better? I triggered this > by deleting my hlr.sqlite3 and 'mobile' came back with an invalid > TMSI and the NITB does not ask for the IMSI. hi holger, you can use "sim lai " to set lai. in this case, the tmsi is removed and also stored in the sim card, if sim reader is selected. regards, andreas From Max.Suraev at fairwaves.ru Wed Nov 28 10:36:09 2012 From: Max.Suraev at fairwaves.ru (=?UTF-8?B?4piO?=) Date: Wed, 28 Nov 2012 11:36:09 +0100 Subject: asn.1 compilation Message-ID: <50B5E919.8080107@fairwaves.ru> Hello. I'm having troubles compiling asn.1 files from http://www.3gpp.org/ftp/Specs/archive/24_series/24.080/ASN.1/ I'm getting syntax error (syntax error at line 264 in module SS-Operations.asn: got 'SEQUENCE' expected ':') while running erlc SS-Operations.asn using Erlang version 15.b.1 As far as I recall Harald has done this for MAP asn.1 Are there any hints on what might be wrong? Tried online compiler but it gives different errors in different places. Should I use different version? Compile smth else before attempting to compile this file? Fix syntax using some clever trick? Do some rtfm? Any advices would be greatly appreciated. -- best regards, Max, http://fairwaves.ru From 246tnt at gmail.com Wed Nov 28 10:55:36 2012 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 28 Nov 2012 11:55:36 +0100 Subject: asn.1 compilation In-Reply-To: <50B5E919.8080107@fairwaves.ru> References: <50B5E919.8080107@fairwaves.ru> Message-ID: Hi > I'm having troubles compiling asn.1 files from > http://www.3gpp.org/ftp/Specs/archive/24_series/24.080/ASN.1/ > > I'm getting syntax error (syntax error at line 264 in module SS-Operations.asn: got > 'SEQUENCE' expected ':') while running > Are there any hints on what might be wrong? Yeah ... there is a syntax error at line 264 :) > Any advices would be greatly appreciated. The ASN1 files in the specs are buggy, you need to fix them yourself. Look at the various ASN1 tree in http://cgit.osmocom.org/cgit/ some will contain fixed up version of some of the ASN1 files from the spec. Wireshark also sometimes have fixed up version of the ASN1 files if they have the corresponding dissector. Cheers, Sylvain From Max.Suraev at fairwaves.ru Wed Nov 28 11:34:11 2012 From: Max.Suraev at fairwaves.ru (=?UTF-8?B?4piO?=) Date: Wed, 28 Nov 2012 12:34:11 +0100 Subject: asn.1 compilation In-Reply-To: References: <50B5E919.8080107@fairwaves.ru> Message-ID: <50B5F6B3.5020505@fairwaves.ru> 28.11.2012 11:55, Sylvain Munaut ?????: > Hi > >> I'm having troubles compiling asn.1 files from >> http://www.3gpp.org/ftp/Specs/archive/24_series/24.080/ASN.1/ >> >> I'm getting syntax error (syntax error at line 264 in module SS-Operations.asn: got >> 'SEQUENCE' expected ':') while running >> Are there any hints on what might be wrong? > Yeah ... there is a syntax error at line 264 :) Doh! That's what's wrong with GSM industry :) > > >> Any advices would be greatly appreciated. > The ASN1 files in the specs are buggy, you need to fix them yourself. > > Look at the various ASN1 tree in http://cgit.osmocom.org/cgit/ some > will contain fixed up version of some of the ASN1 files from the spec. > Wireshark also sometimes have fixed up version of the ASN1 files if > they have the corresponding dissector. Sweet - found the right spot: git clone git://git.osmocom.org/erlang/osmo_map.git cd osmo_map/asn1 erlc *.asn asn1error:130:'MAP-Protocol':'Supported-MAP-Operations' {asn1,{undefined_type,'forwardCUG-Info'}} but the rest compiles just fine. Thank you! -- best regards, Max, http://fairwaves.ru From holger at freyther.de Wed Nov 28 13:54:54 2012 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Wed, 28 Nov 2012 14:54:54 +0100 Subject: asn.1 compilation In-Reply-To: <50B5F6B3.5020505@fairwaves.ru> References: <50B5E919.8080107@fairwaves.ru> <50B5F6B3.5020505@fairwaves.ru> Message-ID: <20121128135454.GQ17561@xiaoyu.lan> On Wed, Nov 28, 2012 at 12:34:11PM +0100, ? wrote: > git clone git://git.osmocom.org/erlang/osmo_map.git > cd osmo_map/asn1 > erlc *.asn you probably want the map.set.asn1 From Max.Suraev at fairwaves.ru Wed Nov 28 15:10:32 2012 From: Max.Suraev at fairwaves.ru (=?UTF-8?B?4piO?=) Date: Wed, 28 Nov 2012 16:10:32 +0100 Subject: asn.1 compilation In-Reply-To: <20121128135454.GQ17561@xiaoyu.lan> References: <50B5E919.8080107@fairwaves.ru> <50B5F6B3.5020505@fairwaves.ru> <20121128135454.GQ17561@xiaoyu.lan> Message-ID: <50B62968.9010408@fairwaves.ru> 28.11.2012 14:54, Holger Hans Peter Freyther ?????: > On Wed, Nov 28, 2012 at 12:34:11PM +0100, ? wrote: >> git clone git://git.osmocom.org/erlang/osmo_map.git >> cd osmo_map/asn1 >> erlc *.asn > > you probably want the map.set.asn1 > > Maybe but no luck so far: erlc map.set.asn1 syntax error at line 58 in module TCAPMessages.asn: got: '{' and '{' expected typereference '::=' Compiler function asn1ct:compile_asn1/3 returned: {error,{'parse error in file:',"/home/dude/osmo_map/asn1/TCAPMessages.asn", [got,['{','{'],expected,typereference,'::=']}} any ideas? -- best regards, Max, http://fairwaves.ru From Max.Suraev at fairwaves.ru Thu Nov 29 14:12:08 2012 From: Max.Suraev at fairwaves.ru (=?UTF-8?B?4piO?=) Date: Thu, 29 Nov 2012 15:12:08 +0100 Subject: [PATCH] Add return value to indicate unsopported cipher Message-ID: <50B76D38.2040708@fairwaves.ru> Hello. Right now there's no way for user of osmo_a5(..) to understand if particular cipher (a5/3 for example) is supported or not. Attached patch adds simple return value to osmo_a5 to fix that. Of course I would rather see a5/3 included into mainline but in a meantime this patch might be useful too :) -- best regards, Max, http://fairwaves.ru From Max.Suraev at fairwaves.ru Thu Nov 29 14:07:27 2012 From: Max.Suraev at fairwaves.ru (Max) Date: Thu, 29 Nov 2012 15:07:27 +0100 Subject: [PATCH] Add return value to indicate unsopported cipher. Message-ID: --- include/osmocom/gsm/a5.h | 2 +- src/gsm/a5.c | 8 ++++++-- 2 files changed, 7 insertions(+), 3 deletions(-) diff --git a/include/osmocom/gsm/a5.h b/include/osmocom/gsm/a5.h index 649dbab..f237c42 100644 --- a/include/osmocom/gsm/a5.h +++ b/include/osmocom/gsm/a5.h @@ -54,7 +54,7 @@ osmo_a5_fn_count(uint32_t fn) * - fn is the _real_ GSM frame number. * (converted internally to fn_count) */ -void osmo_a5(int n, const uint8_t *key, uint32_t fn, ubit_t *dl, ubit_t *ul); +unsigned osmo_a5(int n, const uint8_t *key, uint32_t fn, ubit_t *dl, ubit_t *ul); void osmo_a5_1(const uint8_t *key, uint32_t fn, ubit_t *dl, ubit_t *ul); void osmo_a5_2(const uint8_t *key, uint32_t fn, ubit_t *dl, ubit_t *ul); diff --git a/src/gsm/a5.c b/src/gsm/a5.c index 356060a..68d703a 100644 --- a/src/gsm/a5.c +++ b/src/gsm/a5.c @@ -45,10 +45,10 @@ * \param[out] dl Pointer to array of ubits to return Downlink cipher stream * \param[out] ul Pointer to array of ubits to return Uplink cipher stream * - * Currently A5/[0-2] are supported. + * Currently A5/[0-2] are supported: 0 returned in this case, 1 s returned otherwise. * Either (or both) of dl/ul can be NULL if not needed. */ -void +unsigned osmo_a5(int n, const uint8_t *key, uint32_t fn, ubit_t *dl, ubit_t *ul) { switch (n) @@ -58,18 +58,22 @@ osmo_a5(int n, const uint8_t *key, uint32_t fn, ubit_t *dl, ubit_t *ul) memset(dl, 0x00, 114); if (ul) memset(ul, 0x00, 114); + return 1; break; case 1: osmo_a5_1(key, fn, dl, ul); + return 1; break; case 2: osmo_a5_2(key, fn, dl, ul); + return 1; break; default: /* a5/[3..7] not supported here/yet */ + return 0; break; } } -- 1.7.10.4 --------------090904030806030201060909-- From 246tnt at gmail.com Thu Nov 29 15:07:39 2012 From: 246tnt at gmail.com (Sylvain Munaut) Date: Thu, 29 Nov 2012 16:07:39 +0100 Subject: [PATCH] Add return value to indicate unsopported cipher In-Reply-To: <50B76D38.2040708@fairwaves.ru> References: <50B76D38.2040708@fairwaves.ru> Message-ID: Hi, > Right now there's no way for user of osmo_a5(..) to understand if particular cipher > (a5/3 for example) is supported or not. Indeed .. > Attached patch adds simple return value to osmo_a5 to fix that. > Of course I would rather see a5/3 included into mainline but in a meantime this patch > might be useful too :) mmm, the "osmocom" usual way is to return 0 for success and a negative error, in this case -ENOTSUP would be perfect. true/false is more a C++ thing :p Cheers, Sylvain From Max.Suraev at fairwaves.ru Fri Nov 30 16:38:50 2012 From: Max.Suraev at fairwaves.ru (=?UTF-8?B?4piO?=) Date: Fri, 30 Nov 2012 17:38:50 +0100 Subject: [PATCH] Add return value to indicate unsopported cipher In-Reply-To: References: <50B76D38.2040708@fairwaves.ru> Message-ID: <50B8E11A.1030509@fairwaves.ru> 29.11.2012 16:07, Sylvain Munaut ?????: > mmm, the "osmocom" usual way is to return 0 for success and a negative > error, in this case -ENOTSUP would be perfect. > Is there common place to define such error codes in osmocom? git grep -ni ENOTSUP reveals nothing of a kind. -- best regards, Max, http://fairwaves.ru From 246tnt at gmail.com Fri Nov 30 17:18:18 2012 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 30 Nov 2012 18:18:18 +0100 Subject: [PATCH] Add return value to indicate unsopported cipher In-Reply-To: <50B8E11A.1030509@fairwaves.ru> References: <50B76D38.2040708@fairwaves.ru> <50B8E11A.1030509@fairwaves.ru> Message-ID: Hi, >> mmm, the "osmocom" usual way is to return 0 for success and a negative >> error, in this case -ENOTSUP would be perfect. >> > Is there common place to define such error codes in osmocom? > > git grep -ni ENOTSUP > reveals nothing of a kind. Well we never used that one yet I guess, but those are defined in errno.h part of POSIX AFAIK. Cheers, Sylvain From Max.Suraev at fairwaves.ru Thu Nov 29 14:07:27 2012 From: Max.Suraev at fairwaves.ru (Max) Date: Thu, 29 Nov 2012 15:07:27 +0100 Subject: [PATCH] Add A5/3 support. Message-ID: --- include/osmocom/gsm/a5.h | 4 +- src/gsm/a5.c | 246 ++++++++++++++++++++++++++++++++++++++++++++-- 2 files changed, 239 insertions(+), 11 deletions(-) diff --git a/include/osmocom/gsm/a5.h b/include/osmocom/gsm/a5.h index 649dbab..46cf4fb 100644 --- a/include/osmocom/gsm/a5.h +++ b/include/osmocom/gsm/a5.h @@ -54,10 +54,10 @@ osmo_a5_fn_count(uint32_t fn) * - fn is the _real_ GSM frame number. * (converted internally to fn_count) */ -void osmo_a5(int n, const uint8_t *key, uint32_t fn, ubit_t *dl, ubit_t *ul); +int osmo_a5(int n, const uint8_t *key, uint32_t fn, ubit_t *dl, ubit_t *ul); void osmo_a5_1(const uint8_t *key, uint32_t fn, ubit_t *dl, ubit_t *ul); void osmo_a5_2(const uint8_t *key, uint32_t fn, ubit_t *dl, ubit_t *ul); - +void osmo_a5_3(const uint8_t *key, uint32_t fn, ubit_t *dl, ubit_t *ul); /*! @} */ #endif /* __OSMO_A5_H__ */ diff --git a/src/gsm/a5.c b/src/gsm/a5.c index 356060a..d95283e 100644 --- a/src/gsm/a5.c +++ b/src/gsm/a5.c @@ -33,9 +33,10 @@ /*! \file gsm/a5.c * \brief Osmocom GSM A5 ciphering algorithm implementation */ - +#include #include - +#include +#include #include /*! \brief Main method to generate a A5/x cipher stream @@ -45,10 +46,10 @@ * \param[out] dl Pointer to array of ubits to return Downlink cipher stream * \param[out] ul Pointer to array of ubits to return Uplink cipher stream * - * Currently A5/[0-2] are supported. + * Currently A5/[0-2] are supported: -ENOTSUP returned in this case, 0 returned for supported ciphers. * Either (or both) of dl/ul can be NULL if not needed. */ -void +int osmo_a5(int n, const uint8_t *key, uint32_t fn, ubit_t *dl, ubit_t *ul) { switch (n) @@ -58,20 +59,25 @@ osmo_a5(int n, const uint8_t *key, uint32_t fn, ubit_t *dl, ubit_t *ul) memset(dl, 0x00, 114); if (ul) memset(ul, 0x00, 114); - break; + return 0; case 1: osmo_a5_1(key, fn, dl, ul); - break; + return 0; case 2: osmo_a5_2(key, fn, dl, ul); - break; + return 0; + + case 3: + osmo_a5_3(key, fn, dl, ul); + return 0; default: - /* a5/[3..7] not supported here/yet */ - break; + /* a5/[4..7] not supported here/yet */ + return -ENOTSUP; } + return -ENOTSUP; /* make compiler happy */ } @@ -364,4 +370,226 @@ osmo_a5_2(const uint8_t *key, uint32_t fn, ubit_t *dl, ubit_t *ul) } } +/* ------------------------------------------------------------------------ */ +/* A5/3 */ +/* ------------------------------------------------------------------------ */ + +uint16_t _rol16(uint16_t in, unsigned shift) +{ + return (in << shift) | (in >> (16 - shift)); +} + +uint16_t osmo_get2bytes(uint8_t *a) +{ /* UNSAFE! Do NOT use unless you know what you are doing! */ + return (uint16_t)((((uint16_t)a[0]) << 8) + (uint16_t)a[1]); +} + +void osmo_64pack2pbit(uint64_t in, pbit_t *out) +{ + int i; + for (i = 7; i >=0; i--) { + out[i] = in & 0xFF; + in >>= 8; + } +} + +uint16_t +_a5_3_kasumi_FI(uint16_t I, uint16_t skey) +{ + static uint16_t S7[] = { + 54, 50, 62, 56, 22, 34, 94, 96, 38, 6, 63, 93, 2, 18, 123, 33, + 55, 113, 39, 114, 21, 67, 65, 12, 47, 73, 46, 27, 25, 111, 124, 81, + 53, 9, 121, 79, 52, 60, 58, 48, 101, 127, 40, 120, 104, 70, 71, 43, + 20, 122, 72, 61, 23, 109, 13, 100, 77, 1, 16, 7, 82, 10, 105, 98, + 117, 116, 76, 11, 89, 106, 0,125,118, 99, 86, 69, 30, 57, 126, 87, + 112, 51, 17, 5, 95, 14, 90, 84, 91, 8, 35,103, 32, 97, 28, 66, + 102, 31, 26, 45, 75, 4, 85, 92, 37, 74, 80, 49, 68, 29, 115, 44, + 64, 107, 108, 24, 110, 83, 36, 78, 42, 19, 15, 41, 88, 119, 59, 3 + }; + static uint16_t S9[] = { + 167, 239, 161, 379, 391, 334, 9, 338, 38, 226, 48, 358, 452, 385, 90, 397, + 183, 253, 147, 331, 415, 340, 51, 362, 306, 500, 262, 82, 216, 159, 356, 177, + 175, 241, 489, 37, 206, 17, 0, 333, 44, 254, 378, 58, 143, 220, 81, 400, + 95, 3, 315, 245, 54, 235, 218, 405, 472, 264, 172, 494, 371, 290, 399, 76, + 165, 197, 395, 121, 257, 480, 423, 212, 240, 28, 462, 176, 406, 507, 288, 223, + 501, 407, 249, 265, 89, 186, 221, 428,164, 74, 440, 196, 458, 421, 350, 163, + 232, 158, 134, 354, 13, 250, 491, 142,191, 69, 193, 425, 152, 227, 366, 135, + 344, 300, 276, 242, 437, 320, 113, 278, 11, 243, 87, 317, 36, 93, 496, 27, + 487, 446, 482, 41, 68, 156, 457, 131, 326, 403, 339, 20, 39, 115, 442, 124, + 475, 384, 508, 53, 112, 170, 479, 151, 126, 169, 73, 268, 279, 321, 168, 364, + 363, 292, 46, 499, 393, 327, 324, 24, 456, 267, 157, 460, 488, 426, 309, 229, + 439, 506, 208, 271, 349, 401, 434, 236, 16, 209, 359, 52, 56, 120, 199, 277, + 465, 416, 252, 287, 246, 6, 83, 305, 420, 345, 153,502, 65, 61, 244, 282, + 173, 222, 418, 67, 386, 368, 261, 101, 476, 291, 195,430, 49, 79, 166, 330, + 280, 383, 373, 128, 382, 408, 155, 495, 367, 388, 274, 107, 459, 417, 62, 454, + 132, 225, 203, 316, 234, 14, 301, 91, 503, 286, 424, 211, 347, 307, 140, 374, + 35, 103, 125, 427, 19, 214, 453, 146, 498, 314, 444, 230, 256, 329, 198, 285, + 50, 116, 78, 410, 10, 205, 510, 171, 231, 45, 139, 467, 29, 86, 505, 32, + 72, 26, 342, 150, 313, 490, 431, 238, 411, 325, 149, 473, 40, 119, 174, 355, + 185, 233, 389, 71, 448, 273, 372, 55, 110, 178, 322, 12, 469, 392, 369, 190, + 1, 109, 375, 137, 181, 88, 75, 308, 260, 484, 98, 272, 370, 275, 412, 111, + 336, 318, 4, 504, 492, 259, 304, 77, 337, 435, 21, 357, 303, 332, 483, 18, + 47, 85, 25, 497, 474, 289, 100, 269, 296, 478, 270, 106, 31, 104, 433, 84, + 414, 486, 394, 96, 99, 154, 511, 148, 413, 361, 409, 255, 162, 215, 302, 201, + 266, 351, 343, 144, 441, 365, 108, 298, 251, 34, 182, 509, 138, 210, 335, 133, + 311, 352, 328, 141, 396, 346, 123, 319, 450, 281, 429, 228, 443, 481, 92, 404, + 485, 422, 248, 297, 23, 213, 130, 466, 22, 217, 283, 70, 294, 360, 419, 127, + 312, 377, 7, 468, 194, 2, 117, 295, 463, 258, 224, 447, 247, 187, 80, 398, + 284, 353, 105, 390, 299, 471, 470, 184, 57, 200, 348, 63, 204, 188, 33, 451, + 97, 30, 310, 219, 94, 160, 129, 493, 64, 179, 263, 102, 189, 207, 114, 402, + 438, 477, 387, 122, 192, 42, 381, 5, 145, 118, 180, 449, 293, 323, 136, 380, + 43, 66, 60, 455, 341, 445, 202, 432, 8, 237, 15, 376, 436, 464, 59, 461 + }; + uint16_t L, R; + + /* Split 16 bit input into two unequal halves: 9 and 7 bits, same for subkey */ + L = I >> 7; /* take 9 bits */ + R = I & 0x7F; /* take 7 bits */ + + L = S9[L] ^ R; + R = S7[R] ^ (L & 0x7F); + + L ^= (skey & 0x1FF); + R ^= (skey >> 9); + + L = S9[L] ^ R; + R = S7[R] ^ (L & 0x7F); + + return (R << 9) + L; +} + +uint32_t +_a5_3_kasumi_FO(uint32_t I, uint16_t *KOi1, uint16_t *KOi2, uint16_t *KOi3, uint16_t *KIi1, uint16_t *KIi2, uint16_t *KIi3, unsigned i) +{ + uint16_t L = I >> 16, R = I; /* Split 32 bit input into Left and Right parts */ + + L ^= KOi1[i]; + L = _a5_3_kasumi_FI(L, KIi1[i]); + L ^= R; + + R ^= KOi2[i]; + R =_a5_3_kasumi_FI(R, KIi2[i]); + R ^= L; + + L ^= KOi3[i]; + L = _a5_3_kasumi_FI(L, KIi3[i]); + L ^= R; + + return (((uint32_t)R) << 16) + L; +} + +uint32_t +_a5_3_kasumi_FL(uint32_t I, uint16_t *KLi1, uint16_t *KLi2, unsigned i) +{ + uint16_t L = I >> 16, R = I, tmp; /* Split 32 bit input into Left and Right parts */ + + tmp = L & KLi1[i]; + R ^= _rol16(tmp, 1); + + tmp = R | KLi2[i]; + L ^= _rol16(tmp, 1); + + return (((uint32_t)L) << 16) + R; +} + +uint64_t +_a5_3_kasumi(uint64_t P, uint16_t *KLi1, uint16_t *KLi2, uint16_t *KOi1, uint16_t *KOi2, uint16_t *KOi3, uint16_t *KIi1, uint16_t *KIi2, uint16_t *KIi3) +{ + uint32_t i, L = P >> 32, R = P; /* Split 64 bit input into Left and Right parts */ + + for (i = 0; i < 8; i++) + { + R ^= _a5_3_kasumi_FO(_a5_3_kasumi_FL(L, KLi1, KLi2, i), KOi1, KOi2, KOi3, KIi1, KIi2, KIi3, i); /* odd round */ + i++; + L ^= _a5_3_kasumi_FL(_a5_3_kasumi_FO(R, KOi1, KOi2, KOi3, KIi1, KIi2, KIi3, i), KLi1, KLi2, i); /* even round */ + } + return (((uint64_t)L) << 32) + R; /* Concatenate Left and Right 32 bits into 64 bit ciphertext */ +} + +/*! \brief Expand key into set of subkeys + * \param[in] key (128 bits) as array of bytes + * \param[out] arrays of round-specific subkeys - see TS 135 202 for details + */ +void +_a5_3_key_expand(uint8_t *key, uint16_t *KLi1, uint16_t *KLi2, uint16_t *KOi1, uint16_t *KOi2, uint16_t *KOi3, uint16_t *KIi1, uint16_t *KIi2, uint16_t *KIi3) +{ + uint16_t i, C[] = { 0x0123, 0x4567, 0x89AB, 0xCDEF, 0xFEDC, 0xBA98, 0x7654, 0x3210 }; + + for (i = 0; i < 8; i++) /* Work with 16 bit subkeys and create prime subkeys */ + { + C[i] ^= osmo_get2bytes(key + i * 2); + } + /* C[] now stores K-prime[] */ + for (i = 0; i < 8; i++) /* Create round-specific subkeys */ + { + KLi1[i] = _rol16(osmo_get2bytes(key + i * 2), 1); + KLi2[i] = C[(i + 2) & 0x7]; + + KOi1[i] = _rol16(osmo_get2bytes(key + ((2 * (i + 1)) & 0xE)), 5); + KOi2[i] = _rol16(osmo_get2bytes(key + ((2 * (i + 5)) & 0xE)), 8); + KOi3[i] = _rol16(osmo_get2bytes(key + ((2 * (i + 6)) & 0xE)), 13); + + KIi1[i] = C[(i + 4) & 0x7]; + KIi2[i] = C[(i + 3) & 0x7]; + KIi3[i] = C[(i + 7) & 0x7]; + } +} + +void +_a5_3_kgcore_gsm(uint8_t CA, uint8_t cb, uint32_t cc, uint8_t cd, uint8_t *ck, uint8_t *co, uint16_t cl) +{ + uint16_t KLi1[8], KLi2[8], KOi1[8], KOi2[8], KOi3[8], KIi1[8], KIi2[8], KIi3[8], i; + uint64_t A = ((uint64_t)cc) << 32, BLK = 0, _ca = ((uint64_t)CA << 16) ; + A |= _ca; + _ca = (uint64_t)((cb << 3) | (cd << 2)) << 24; + A |= _ca; + /* Register loading complete: see TR 55.919 8.2 and TS 55.216 3.2 */ + + uint8_t ck_km[16]; + for (i = 0; i < 16; i++) ck_km[i] = ck[i] ^ 0x55; /* Modified key established */ + + /* preliminary round with modified key */ + _a5_3_key_expand(ck_km, KLi1, KLi2, KOi1, KOi2, KOi3, KIi1, KIi2, KIi3); + A = _a5_3_kasumi(A, KLi1, KLi2, KOi1, KOi2, KOi3, KIi1, KIi2, KIi3); + + /* Run Kasumi in OFB to obtain enough data for gamma. */ + _a5_3_key_expand(ck, KLi1, KLi2, KOi1, KOi2, KOi3, KIi1, KIi2, KIi3); + for (i = 0; i < cl / 64 + 1; i++) /* i is a block counter */ + { + BLK = _a5_3_kasumi(A ^ i ^ BLK, KLi1, KLi2, KOi1, KOi2, KOi3, KIi1, KIi2, KIi3); + osmo_64pack2pbit(BLK, co + (i * 8)); + } +} + +/*! \brief Generate a GSM A5/3 cipher stream + * \param[in] key 8 byte array for the key (as received from the SIM) + * \param[in] fn Frame number + * \param[out] dl Pointer to array of ubits to return Downlink cipher stream + * \param[out] ul Pointer to array of ubits to return Uplink cipher stream + * + * Either (or both) of dl/ul should be NULL if not needed. + * + * Implementation based on specifications from 3GPP TS 55.216, 3GPP TR 55.919 and ETSI TS 135 202 + * with slight simplifications (CE hardcoded to 0). + */ +void +osmo_a5_3(const uint8_t *key, uint32_t fn, ubit_t *dl, ubit_t *ul) +{ + /* internal function require 128 bit key so we expand by concatenating supplied 64 bit key */ + uint8_t i, ck[16], gamma[32]; + memcpy(ck, key, 8); + memcpy(ck + 8, key, 8); + uint32_t fn_count = osmo_a5_fn_count(fn); /* Frame count load */ + if (dl) { + _a5_3_kgcore_gsm(0xF, 0, fn_count, 0, ck, gamma, 114); + osmo_pbit2ubit(dl, gamma, 114); + } + if (ul) { + _a5_3_kgcore_gsm(0xF, 0, fn_count, 0, ck, gamma, 228); + uint8_t uplink[15]; + for(i = 0; i < 15; i++) uplink[i] = (gamma[i + 14] << 2) + (gamma[i + 15] >> 6); + osmo_pbit2ubit(ul, uplink, 114); + } +} + /*! @} */ -- 1.7.10.4 --------------080507080909000101000702--