From ml at mail.tsaitgaist.info Sat Nov 2 19:02:12 2013 From: ml at mail.tsaitgaist.info (Kevin Redon) Date: Sat, 02 Nov 2013 19:02:12 +0100 Subject: COMP128v23 Message-ID: <1383414202-sup-5743@dennou> I tested the reserved COMP128v23 code from www.hackingprojects.net the values in the python file match the ones outputed by the sysmoSIM-GR1 (which also supports COMP128 v2 and v3) so I implemented it in C, and added it to libosmocore I then checked the output from osmo-auc-gen again the values provided also the python code and all values matched Here are te patched WARNING: I also renamed COMP128 to COMP128v1, but don't know if this breaks any compatibility with other projects kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-add-COMP128v23-to-library-headers.patch Type: application/octet-stream Size: 811 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0006-renamed-COMP128-version-1-functions-to-COMP128v1-to-.patch Type: application/octet-stream Size: 24003 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-add-COMP128v23-files-to-be-compiled.patch Type: application/octet-stream Size: 1512 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-implemented-COMP128-version-2-and-3-A3-A8-algorithm.patch Type: application/octet-stream Size: 6345 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0007-fixed-typo.patch Type: application/octet-stream Size: 868 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-added-header-to-access-COMP128v23-functions.patch Type: application/octet-stream Size: 1123 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-register-COMP128v23-algorithms.patch Type: application/octet-stream Size: 2643 bytes Desc: not available URL: From laforge at gnumonks.org Sun Nov 3 15:00:09 2013 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 3 Nov 2013 15:00:09 +0100 Subject: COMP128v23 In-Reply-To: <1383414202-sup-5743@dennou> References: <1383414202-sup-5743@dennou> Message-ID: <20131103140009.GA7342@nataraja.gnumonks.org> Hi Kevin, On Sat, Nov 02, 2013 at 07:02:12PM +0100, Kevin Redon wrote: > I tested the reserved COMP128v23 code from www.hackingprojects.net Thanks, I didn't even know that there was now a publicly-documented, publicly-leaked vresion of COMP128v2/v3 available. This of course means that nobody can claim the algorithm is a trade secret anymore, and thus I don't see problems with us implementing it in libosmocore for subsequent use in other osmocom projects like osmo-nitb, etc. > I then checked the output from osmo-auc-gen again the values provided > also the python code and all values matched thanks! > WARNING: I also renamed COMP128 to COMP128v1, but don't know if this > breaks any compatibility with other projects Exactly to avoid that, I would simply skip it. I know it's sort-of strange that comp128 refers to v1 without explicitly stating it, but I think for the sake of simplicitly we should keep it. Finally, I hope somebody will have enough reason of porting osmo-nitb over to the generic osmo_auth API in libosmocore, rather than calling the comp128[v1] algorithm directly. At that point, COMP128v2/v3 as well as milenage support will come more or less automagically. Afer that, we could probably resort to not exporting the comp128() functions directly anymore, but require all users to go through the osmo_auth_* API. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Sun Nov 3 15:09:42 2013 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 3 Nov 2013 15:09:42 +0100 Subject: COMP128v23 In-Reply-To: <1383414202-sup-5743@dennou> References: <1383414202-sup-5743@dennou> Message-ID: <20131103140941.GB7342@nataraja.gnumonks.org> I've now merged your patches, except the re-name. I squashed all in one, there's no point in having 7 commits for one single feature addition. Regards, -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From holger at freyther.de Sun Nov 3 18:49:45 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sun, 3 Nov 2013 18:49:45 +0100 Subject: COMP128v23 In-Reply-To: <20131103140941.GB7342@nataraja.gnumonks.org> References: <1383414202-sup-5743@dennou> <20131103140941.GB7342@nataraja.gnumonks.org> Message-ID: <20131103174945.GJ14634@xiaoyu.lan> On Sun, Nov 03, 2013 at 03:09:42PM +0100, Harald Welte wrote: > I've now merged your patches, except the re-name. I squashed all in > one, there's no point in having 7 commits for one single feature > addition. I started to use "#pragma once" in my own header files and the PCU. This feature was introduced in gcc 3.4 (released in 2004). I would like to use it in future header files everywhere. comments? holger From steveh7070 at gmail.com Sun Nov 3 17:34:42 2013 From: steveh7070 at gmail.com (Steve Harrison) Date: Sun, 3 Nov 2013 16:34:42 +0000 Subject: Multislot transmit power - possible to reduce it? (plain text) Message-ID: Sorry, forgot to tick the "plain text mode" box on my previous mail... Hi all, In the "EMI" application's main.c is an interesting comment: /* hack: because we cannot control power of multiple burst, * we just force power to 1w, as it is fixed in dsp_extcode If I understand this correctly, the 'C54 code in src/target/firmware/calypso/dsp_extcode.c sets the transmit power to maximum (1W) for all multi-slot transmissions. Would it be possible to fix the multislot transmit power (for the TRX app as well as EMI) at some lower value instead (e.g. 100mW) by modifying dsp_extcode.c? Three reasons: 1. Play nicely with "other users" of the GSM band, by transmitting the same as a "proper" picocell, 2. not draw such a high current from the phone's tiny battery, and 3. avoid overheating the phone's RF power amp and other circuitry - I left my S-E J100 transmitting for about 5 minutes, then noticed that the LCD display was starting to "white out" with the heat! I've achieved a similar result by a hardware modification (added a resistor to reduce the power-control voltage going into the PA), but it's a brutal process - requires prying open a screening can and soldering an 0402 resistor, then trying to get the screening can lid to go back without too much deformation. A software mod would be much more elegant, but I don't know C54 DSP code. Sylvain? thanks, Steve From laforge at gnumonks.org Sun Nov 3 19:13:24 2013 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 3 Nov 2013 19:13:24 +0100 Subject: #pragma once (Re: COMP128v23) In-Reply-To: <20131103174945.GJ14634@xiaoyu.lan> References: <1383414202-sup-5743@dennou> <20131103140941.GB7342@nataraja.gnumonks.org> <20131103174945.GJ14634@xiaoyu.lan> Message-ID: <20131103181324.GW6401@nataraja.gnumonks.org> Hi Holger, On Sun, Nov 03, 2013 at 06:49:45PM +0100, Holger Hans Peter Freyther wrote: > I started to use "#pragma once" in my own header files and the PCU. > This feature was introduced in gcc 3.4 (released in 2004). I would > like to use it in future header files everywhere. I don't see any problems, but then the gain from three fairly simple lines to one line is not really all that big. -- - 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 Mon Nov 4 10:18:04 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Mon, 4 Nov 2013 10:18:04 +0100 Subject: #pragma once (Re: COMP128v23) In-Reply-To: <20131103181324.GW6401@nataraja.gnumonks.org> References: <1383414202-sup-5743@dennou> <20131103140941.GB7342@nataraja.gnumonks.org> <20131103174945.GJ14634@xiaoyu.lan> <20131103181324.GW6401@nataraja.gnumonks.org> Message-ID: Hi, > On Sun, Nov 03, 2013 at 06:49:45PM +0100, Holger Hans Peter Freyther wrote: >> I started to use "#pragma once" in my own header files and the PCU. >> This feature was introduced in gcc 3.4 (released in 2004). I would >> like to use it in future header files everywhere. > > I don't see any problems, but then the gain from three fairly simple > lines to one line is not really all that big. What about other compilers ? I'm thinking on particular of people building part of it on Windows ? (VCC is pretty much out already but what about ICC ?) Cheers, Sylvain From 246tnt at gmail.com Mon Nov 4 10:19:27 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Mon, 4 Nov 2013 10:19:27 +0100 Subject: COMP128v23 In-Reply-To: <20131103140009.GA7342@nataraja.gnumonks.org> References: <1383414202-sup-5743@dennou> <20131103140009.GA7342@nataraja.gnumonks.org> Message-ID: Hi, >> WARNING: I also renamed COMP128 to COMP128v1, but don't know if this >> breaks any compatibility with other projects > > Exactly to avoid that, I would simply skip it. I know it's sort-of > strange that comp128 refers to v1 without explicitly stating it, but I > think for the sake of simplicitly we should keep it. We could also use a weak alias and mark it as deprecated like we did for some of the hexdump function. Cheers, Sylvain From 246tnt at gmail.com Mon Nov 4 10:35:33 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Mon, 4 Nov 2013 10:35:33 +0100 Subject: Multislot transmit power - possible to reduce it? (plain text) In-Reply-To: References: Message-ID: > If I understand this correctly, the 'C54 code in > src/target/firmware/calypso/dsp_extcode.c sets the transmit power to > maximum (1W) for all multi-slot transmissions. Take the dsp_extcode.c that's in sylvain/testing rather than the one from jollys. The power there is fixed to low levels. Cheers, Sylvain From laforge at gnumonks.org Tue Nov 5 16:58:25 2013 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 5 Nov 2013 16:58:25 +0100 Subject: OsmoDevCon 2014 / Date / Venue Message-ID: <20131105155825.GK12353@nataraja.gnumonks.org> Hi all, time is moving fast, and I want to start some initial discussion and planning for OsmoDevCon 2014. There are basically four questions which I'm raising below. Please provide your feedback to the osmocom-event-orga mailing list only, to avoid cross-posting over all the project lists. = Who? = My intention is to keep it an 'active developer/contributer only' event, like we had it before. I would also want to keep the group relatively small, to keep the 'Osmocom family' atmosphere. If desired, we could have one half or full day of public prsentations in a larger auditorium, but the developer meeting should be a close group, as known so far. = Where? = If we keep the number of attendees within the same range as this year, then I'm sure we could again hold it at the same venue. I know it is not perfect, but it is a place that we have access to, 24 hours per day, and free of cost for community projects like osmocom.org. If the community wants a larger event, then this is something that would require more funds and much more time organizing. And that is something that I personally could not offer to take care of, sorry. I'm happy to attend and support any larger events, but I'm unable to take care of fundraising and venue research. = When? = Q1/2014. In January, I'm not aware of any 'blocker' events. February, there is Fosdem (Feb 1 + Feb 2), and MWC from Feb 24 through Feb 27. In March there is CeBIT (March 10-14) and Easter holidays (with EasterHegg March 17-21). Did I miss any other FOSS / mobile event that might clash in Q1? So my preference woudl be to do it either late January (23-26) or in February (6-9 or 13-16). Any preferences regarding preferred schedule? Once we have some concencus here on the list [and we want to do it in the same size / venue], I'll talk to IN-Berlin. = What? = I think that question is easy to answer, if we have the above three figured out... There's no shortage of topics, I suppose. You can start adding your suggestions to http://openbsc.osmocom.org/trac/wiki/OsmoDevCon2014 Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: Digital signature URL: From logosisigle at gmail.com Thu Nov 7 11:35:01 2013 From: logosisigle at gmail.com (Cristine) Date: Thu, 7 Nov 2013 02:35:01 -0800 (PST) Subject: Error... any can help me, please? Message-ID: <1383820501057-4026209.post@n3.nabble.com> root at debian:~/osmocom-bb/src# make cd shared/libosmocore/build-target && ../configure \ --host=arm-none-eabi --enable-embedded --disable-shared \ --disable-tests ac_cv_header_sys_select_h=no \ --disable-tests ac_cv_header_sys_socket_h=no \ CFLAGS="-Os -ffunction-sections -I/root/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs" configure: WARNING: unrecognized options: --disable-shared, --disable-tests, --disable-tests checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for arm-none-eabi-strip... no checking for strip... strip checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... no checking for mawk... mawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking whether make sets $(MAKE)... (cached) yes checking for arm-none-eabi-gcc... no checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... yes checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 ../configure: line 3803: syntax error near unexpected token `pic-only' ../configure: line 3803: `LT_INIT(pic-only)' make: *** [shared/libosmocore/build-target/Makefile] Error 2 -- View this message in context: http://baseband-devel.722152.n3.nabble.com/Error-any-can-help-me-please-tp4026209.html Sent from the baseband-devel mailing list archive at Nabble.com. From logosisigle at gmail.com Thu Nov 7 19:35:13 2013 From: logosisigle at gmail.com (Cristine) Date: Thu, 7 Nov 2013 10:35:13 -0800 (PST) Subject: Error... any can help me, please? In-Reply-To: <1383841880415-4026210.post@n3.nabble.com> References: <1383820501057-4026209.post@n3.nabble.com> <1383841880415-4026210.post@n3.nabble.com> Message-ID: <1383849313588-4026211.post@n3.nabble.com> ok, i am i***t... thread can be closed, solution for fix is: git clean -dfx -- View this message in context: http://baseband-devel.722152.n3.nabble.com/Error-any-can-help-me-please-tp4026209p4026211.html Sent from the baseband-devel mailing list archive at Nabble.com. From muellermsg at gmail.com Fri Nov 8 11:37:04 2013 From: muellermsg at gmail.com (Michael) Date: Fri, 8 Nov 2013 10:37:04 +0000 (UTC) Subject: Query on flashing the loader References: Message-ID: Bhaskar11 gmail.com> writes: > > This is my first attempt to flash the loader. > 1) The instructions on?http://bb.osmocom.org/trac/wiki/flashing?require loading the file named "target/firmware/board/compal_e88/loader.e88loader.bin". > > Strangely I do not have this file after compilation. I have loader.compalram.bin and loader.highram.bin. I also have?layer1.e88loader.bin and rssi.e88loader.bin. > > > Can you please guide me? > > > 2) The guide for flashing an application says to use?rssi.e88flash.bin. Does that mean if I want to flash "layer1" as my application, then I must use layer1.e88flash.bin at that point? > > > Thank you for your help. > > B. > > > > Hello Bhaskar11, hello all, I haave the same problem... I haven't the "loader.e88loader.bin" file and simply tried to use the "layer1.e88flash.bin" instead.. It was a bad idea !!!!!!!!!!!!!!!!!!!!!!! My phone is a paperweight now :( I read that you posted some patches but also read (if I understand correct) that it didn't solve this problem ??!! Do you found a solution to this problem ? I would be very thankful for some help..!!!!!!!!!!!!!!! Thanks Michael From giovanni.nervi at yahoo.com Sun Nov 10 09:35:42 2013 From: giovanni.nervi at yahoo.com (Giovanni) Date: Sun, 10 Nov 2013 00:35:42 -0800 (PST) Subject: C115 boot loader Message-ID: <1384072542.28111.YahooMailBasic@web124502.mail.ne1.yahoo.com> Hi, I trying OsmocomBB on C115, I have a self build cable, already tested and working as explained in this message http://lists.osmocom.org/pipermail/baseband-devel/2011-August/002230.html I tried last version on git today, but with command osmocon I can't load firmware, it can't find the phone, I never receive "Received PROMPT1 from phone" I tried with -m c123xor and -m c123 without success same result. Short push on C115 not start the loader, so I press the power-on button normaly. Suggestions? Thank you Giovanni From galersekali at gmail.com Sun Nov 17 20:18:33 2013 From: galersekali at gmail.com (anak galer) Date: Mon, 18 Nov 2013 02:18:33 +0700 Subject: schematic motorola c123 Message-ID: Hello folks anyone have schematic motorola c123 , i see here http://bb.osmocom.org/trac/wiki/MotorolaC123 link not found, please mirror if anyone have it. Regards From msokolov at ivan.Harhan.ORG Sun Nov 17 22:09:37 2013 From: msokolov at ivan.Harhan.ORG (Michael Spacefalcon) Date: Sun, 17 Nov 2013 21:09:37 GMT Subject: schematic motorola c123 Message-ID: <1311172109.AA00929@ivan.Harhan.ORG> anak galer wrote: > anyone have schematic motorola c123 , i see here > http://bb.osmocom.org/trac/wiki/MotorolaC123 link not found, please > mirror if anyone have it. I'm not sure if it is the same schematic or not, but take a look at this one: ftp://ftp.ifctf.org/pub/GSM/basic_phones/mot_c118_schem.pdf HTH, SF From Max.Suraev at fairwaves.ru Mon Nov 18 18:47:22 2013 From: Max.Suraev at fairwaves.ru (=?UTF-8?B?4piO?=) Date: Mon, 18 Nov 2013 18:47:22 +0100 Subject: [PATCH] COMP128v23 improvements Message-ID: <528A52AA.1060109@fairwaves.ru> Hello. I've got rid of unnecessary cycle and to made difference between v2 and v3 more visible: v2 is basically just v3 with last bits of Kc zeroed. Also - small readability improvements. Also I've added test suite with test vectors from original python implementation. -- best regards, Max, http://fairwaves.ru -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Refactor-COMP128v23-implementation-and-add-test-suit.patch Type: text/x-patch Size: 188075 bytes Desc: not available URL: From 246tnt at gmail.com Tue Nov 19 09:17:26 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Tue, 19 Nov 2013 09:17:26 +0100 Subject: [PATCH] COMP128v23 improvements In-Reply-To: <528A52AA.1060109@fairwaves.ru> References: <528A52AA.1060109@fairwaves.ru> Message-ID: Hi Max, There are definitely things weird in that patch : - You double declare the same function - Why replace #defined constant by hardcoded numbers ? - Speaking about readability : kc[6] = 4 * (kc[6] >> 2); isn't the most obvious way to do kc[6] &= 0xfc; Cheers, Sylvain On Mon, Nov 18, 2013 at 6:47 PM, ? wrote: > Hello. > > I've got rid of unnecessary cycle and to made difference between v2 and v3 more > visible: v2 is basically just v3 with last bits of Kc zeroed. Also - small > readability improvements. > > Also I've added test suite with test vectors from original python implementation. > > -- > best regards, > Max, http://fairwaves.ru From Max.Suraev at fairwaves.ru Tue Nov 19 10:33:01 2013 From: Max.Suraev at fairwaves.ru (=?UTF-8?B?4piO?=) Date: Tue, 19 Nov 2013 10:33:01 +0100 Subject: [PATCH] COMP128v23 improvements In-Reply-To: References: <528A52AA.1060109@fairwaves.ru> Message-ID: <528B304D.2050304@fairwaves.ru> 19.11.2013 09:17, Sylvain Munaut ?????: > Hi Max, > > There are definitely things weird in that patch : > > - You double declare the same function Which one? > - Why replace #defined constant by hardcoded numbers ? To make code look more similar to comp128v1 and other code which uses Kc and rand: we use hardcoded values everywhere. > - Speaking about readability : > > kc[6] = 4 * (kc[6] >> 2); > > isn't the most obvious way to do kc[6] &= 0xfc; Added, thank you. -- best regards, Max, http://fairwaves.ru -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Refactor-COMP128v23-implementation-and-add-test-suit-v2.patch Type: text/x-patch Size: 188101 bytes Desc: not available URL: From peter at stuge.se Tue Nov 19 12:16:18 2013 From: peter at stuge.se (Peter Stuge) Date: Tue, 19 Nov 2013 12:16:18 +0100 Subject: [PATCH] COMP128v23 improvements In-Reply-To: <528A52AA.1060109@fairwaves.ru> References: <528A52AA.1060109@fairwaves.ru> Message-ID: <20131119111618.1475.qmail@stuge.se> Hi, ? wrote: > I've got rid of unnecessary cycle and to made difference between v2 and > v3 more visible: v2 is basically just v3 with last bits of Kc zeroed. > Also - small readability improvements. More on this below. > Also I've added test suite with test vectors from original python implementation. Cool! > +++ b/include/osmocom/gsm/comp128v23.h > @@ -13,11 +13,11 @@ > * Performs the COMP128 version 2 and 3 algorithm (used as A3/A8) > * ki : uint8_t [16] > * srand : uint8_t [16] > - * version : uint8_t (2 or 3) > * sres : uint8_t [4] > * kc : uint8_t [8] > * returns 1 if not version 2 or 3 specified > */ > -int comp128v23(const uint8_t *ki, const uint8_t *rand, uint8_t version, uint8_t *sres, uint8_t *kc); Since this is a public API I don't know if the old function can be removed. > +int comp128v3(const uint8_t *ki, const uint8_t *rand, uint8_t *sres, uint8_t *kc); > +int comp128v3(const uint8_t *ki, const uint8_t *rand, uint8_t *sres, uint8_t *kc); Copypaste error here. I think it's nice to add two new functions, but probably the old one needs to stay there. > +++ b/src/gsm/auth_comp128v23.c > @@ -31,7 +31,7 @@ static int c128v2_gen_vec(struct osmo_auth_vector *vec, > struct osmo_sub_auth_data *aud, > const uint8_t *_rand) > { > - comp128v23(aud->u.gsm.ki, _rand, 2, vec->sres, vec->kc); > + comp128v2(aud->u.gsm.ki, _rand, vec->sres, vec->kc); > vec->auth_types = OSMO_AUTH_TYPE_GSM; > > return 0; I like this change, thanks to the two new functions. //Peter From Max.Suraev at fairwaves.ru Tue Nov 19 12:25:52 2013 From: Max.Suraev at fairwaves.ru (=?UTF-8?B?4piO?=) Date: Tue, 19 Nov 2013 12:25:52 +0100 Subject: [PATCH] COMP128v23 improvements In-Reply-To: <20131119111618.1475.qmail@stuge.se> References: <528A52AA.1060109@fairwaves.ru> <20131119111618.1475.qmail@stuge.se> Message-ID: <528B4AC0.7060906@fairwaves.ru> 19.11.2013 12:16, Peter Stuge ?????: > > Since this is a public API I don't know if the old function can be removed. > I thought public api is in auth_comp128* e. g. osmo_auth_gen_vec() - see tests/comp128_test.c for usage examples. And functions like comp128v*() are internal implementation details. >> +int comp128v3(const uint8_t *ki, const uint8_t *rand, uint8_t *sres, uint8_t *kc); >> +int comp128v3(const uint8_t *ki, const uint8_t *rand, uint8_t *sres, uint8_t *kc); > > Copypaste error here. I think it's nice to add two new functions, but > probably the old one needs to stay there. > > Fixed, thank you. -- best regards, Max, http://fairwaves.ru -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Refactor-COMP128v23-implementation-and-add-test-suit-v3.patch Type: text/x-patch Size: 188101 bytes Desc: not available URL: From peter at stuge.se Tue Nov 19 12:42:36 2013 From: peter at stuge.se (Peter Stuge) Date: Tue, 19 Nov 2013 12:42:36 +0100 Subject: [PATCH] COMP128v23 improvements In-Reply-To: <528B4AC0.7060906@fairwaves.ru> References: <528A52AA.1060109@fairwaves.ru> <20131119111618.1475.qmail@stuge.se> <528B4AC0.7060906@fairwaves.ru> Message-ID: <20131119114236.3350.qmail@stuge.se> ? wrote: > > Since this is a public API I don't know if the old function can be removed. > > I thought public api is in auth_comp128* e. g. osmo_auth_gen_vec() - > see tests/comp128_test.c for usage examples. And functions like > comp128v*() are internal implementation details. Using osmo_auth_*() is the recommended API but comp128v*() are also in the installed header files and thus also part of the public API. //Peter From Max.Suraev at fairwaves.ru Tue Nov 19 12:46:47 2013 From: Max.Suraev at fairwaves.ru (=?UTF-8?B?4piO?=) Date: Tue, 19 Nov 2013 12:46:47 +0100 Subject: [PATCH] COMP128v23 improvements In-Reply-To: <20131119114236.3350.qmail@stuge.se> References: <528A52AA.1060109@fairwaves.ru> <20131119111618.1475.qmail@stuge.se> <528B4AC0.7060906@fairwaves.ru> <20131119114236.3350.qmail@stuge.se> Message-ID: <528B4FA7.7070307@fairwaves.ru> 19.11.2013 12:42, Peter Stuge ?????: > ? wrote: >>> Since this is a public API I don't know if the old function can be removed. >> >> I thought public api is in auth_comp128* e. g. osmo_auth_gen_vec() - >> see tests/comp128_test.c for usage examples. And functions like >> comp128v*() are internal implementation details. > > Using osmo_auth_*() is the recommended API but comp128v*() are also > in the installed header files and thus also part of the public API. > Is there any reason not to deprecate it? -- best regards, Max, http://fairwaves.ru From peter at stuge.se Tue Nov 19 13:29:06 2013 From: peter at stuge.se (Peter Stuge) Date: Tue, 19 Nov 2013 13:29:06 +0100 Subject: [PATCH] COMP128v23 improvements In-Reply-To: <528B4FA7.7070307@fairwaves.ru> References: <528A52AA.1060109@fairwaves.ru> <20131119111618.1475.qmail@stuge.se> <528B4AC0.7060906@fairwaves.ru> <20131119114236.3350.qmail@stuge.se> <528B4FA7.7070307@fairwaves.ru> Message-ID: <20131119122906.6584.qmail@stuge.se> ? wrote: > > Using osmo_auth_*() is the recommended API but comp128v*() are also > > in the installed header files and thus also part of the public API. > > Is there any reason not to deprecate it? Even if it is deprecated it would have to stay, otherwise the libosmocore ABI breaks without a very good reason. //Peter From 246tnt at gmail.com Tue Nov 19 14:10:36 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Tue, 19 Nov 2013 14:10:36 +0100 Subject: [PATCH] COMP128v23 improvements In-Reply-To: <20131119122906.6584.qmail@stuge.se> References: <528A52AA.1060109@fairwaves.ru> <20131119111618.1475.qmail@stuge.se> <528B4AC0.7060906@fairwaves.ru> <20131119114236.3350.qmail@stuge.se> <528B4FA7.7070307@fairwaves.ru> <20131119122906.6584.qmail@stuge.se> Message-ID: That function hasn't been there long enough for anyone to use it. There also wasn't any tagged version so far with it, so no ABI guarantee. On Tue, Nov 19, 2013 at 1:29 PM, Peter Stuge wrote: > ? wrote: >> > Using osmo_auth_*() is the recommended API but comp128v*() are also >> > in the installed header files and thus also part of the public API. >> >> Is there any reason not to deprecate it? > > Even if it is deprecated it would have to stay, otherwise the > libosmocore ABI breaks without a very good reason. > > > //Peter > From peter at stuge.se Tue Nov 19 14:32:48 2013 From: peter at stuge.se (Peter Stuge) Date: Tue, 19 Nov 2013 14:32:48 +0100 Subject: [PATCH] COMP128v23 improvements In-Reply-To: References: <528A52AA.1060109@fairwaves.ru> <20131119111618.1475.qmail@stuge.se> <528B4AC0.7060906@fairwaves.ru> <20131119114236.3350.qmail@stuge.se> <528B4FA7.7070307@fairwaves.ru> <20131119122906.6584.qmail@stuge.se> Message-ID: <20131119133248.11255.qmail@stuge.se> Sylvain Munaut wrote: > That function hasn't been there long enough for anyone to use it. > There also wasn't any tagged version so far with it, so no ABI guarantee. Ok - great! //Peter From Max.Suraev at fairwaves.ru Tue Nov 19 15:03:15 2013 From: Max.Suraev at fairwaves.ru (=?UTF-8?B?4piO?=) Date: Tue, 19 Nov 2013 15:03:15 +0100 Subject: [PATCH] COMP128v23 improvements In-Reply-To: References: <528A52AA.1060109@fairwaves.ru> <20131119111618.1475.qmail@stuge.se> <528B4AC0.7060906@fairwaves.ru> <20131119114236.3350.qmail@stuge.se> <528B4FA7.7070307@fairwaves.ru> <20131119122906.6584.qmail@stuge.se> Message-ID: <528B6FA3.3090801@fairwaves.ru> It might make sense to add __attribute__ ((deprecated)) to comp128 function to discourage it's use. 19.11.2013 14:10, Sylvain Munaut ?????: > That function hasn't been there long enough for anyone to use it. > > There also wasn't any tagged version so far with it, so no ABI guarantee. > > On Tue, Nov 19, 2013 at 1:29 PM, Peter Stuge wrote: >> ? wrote: >>>> Using osmo_auth_*() is the recommended API but comp128v*() are also >>>> in the installed header files and thus also part of the public API. >>> >>> Is there any reason not to deprecate it? >> >> Even if it is deprecated it would have to stay, otherwise the >> libosmocore ABI breaks without a very good reason. >> >> >> //Peter >> > -- best regards, Max, http://fairwaves.ru From laforge at gnumonks.org Fri Nov 22 16:40:38 2013 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 22 Nov 2013 16:40:38 +0100 Subject: [PATCH] Add A5 and GEA ciphers In-Reply-To: <5162CFD8.1000405@fairwaves.ru> References: <51616FD3.7060001@fairwaves.ru> <5162CFD8.1000405@fairwaves.ru> Message-ID: <20131122154038.GH18191@nataraja.gnumonks.org> Dear Max, I'm getting back to this old thread about your kasumi, A5/3 and A5/4 patches. There were lots of comments during the review in April, but I never saw a follow-up patchset that adressed those comments. Particularly, from the discussion, I remember: 1) follow kernel coding style 2) whitespace / tab spacing 3) line wrapping 4) naming of helper routines which are generic accessor functions. On Mon, Apr 08, 2013 at 04:10:32PM +0200, ? wrote: > > +uint16_t osmo_get2bytes(const uint8_t *a); > > +void osmo_64pack2pbit(uint64_t in, pbit_t *out); > > > > Theses essentially look like integer accessors, one is a read for > > uint16_t in big endian and the other a store for uint64_t in little > > endian, but same basic idea. But you're using completely different > > naming schemes for both ... I think they should reflect that their > > name should reflect the LE/BE part and the unaligned part as well, I > > even think there are already macro somewhere for that. I would also > > add other formats like LE/BE 16/32/64 bits store/load all at once > > rather than each format when needed. If we add accessort, might as > > well add all the basic types. And finally those should really be > > inline functions in the .h, no point of doing a function call for > > that. > > Is there some library I can use for that? It's indeed fairly trivial > accessors but I didn't managed to find those in osmocom code. If there is no function / macro in libosmo* yet, then looking for kernel function names is always a good idea. we have msgb_{put,get,pull}_u{8/16/32}() as accessors for working with message buffers. If msgb doesn't make sense in the context you are working in, then aligning the names to the same scheme might be another idea. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Fri Nov 22 16:44:26 2013 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 22 Nov 2013 16:44:26 +0100 Subject: [PATCH] COMP128v23 improvements In-Reply-To: <528B4AC0.7060906@fairwaves.ru> References: <528A52AA.1060109@fairwaves.ru> <20131119111618.1475.qmail@stuge.se> <528B4AC0.7060906@fairwaves.ru> Message-ID: <20131122154426.GI18191@nataraja.gnumonks.org> Hi Max, I would like to merge your patch, but: On Tue, Nov 19, 2013 at 12:25:52PM +0100, ? wrote: > +int > +comp128v2(const uint8_t *ki, const uint8_t *rand, uint8_t *sres, uint8_t *kc) > +{ > + int r = comp128v3(ki, rand, sres, kc); > + kc[7] = 0; /* 10 last bits of Kc forced to 0 */ > + kc[6] &= 0xfc; > + return r; > +} this is space-indented, not tab-indented. > +static struct osmo_sub_auth_data test_aux2 = { > + .type = OSMO_AUTH_TYPE_GSM, > + .algo = OSMO_AUTH_ALG_COMP128v2, > + .u.gsm = { > + .ki = { 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA }, those lienes are too long for 80-character wide terminals > + uint8_t buf[12]; > + osmo_hexparse(res, buf, 12); > + if (0 != memcmp(buf, vec->sres, 4)) { > + printf("%d FAIL SRES:\n", rc); there's again mixed space and tab indentation. > +void test_comp128v3(char * rand, char * res) { we put the curly braces at the beginning of the line, not at the end of the line. And again the functions are space indented. Furthermore, your patch does not apply on top of master. It's sad to see that valuable contributions are lost due to basic coding style issues not being observed. We had this back in April with your KASUMI related patches, and it was never fixed. Please take the time to fix those issues, thanks. 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 noloader at gmail.com Fri Nov 22 17:59:28 2013 From: noloader at gmail.com (Jeffrey Walton) Date: Fri, 22 Nov 2013 11:59:28 -0500 Subject: [PATCH] COMP128v23 improvements In-Reply-To: <20131122154426.GI18191@nataraja.gnumonks.org> References: <528A52AA.1060109@fairwaves.ru> <20131119111618.1475.qmail@stuge.se> <528B4AC0.7060906@fairwaves.ru> <20131122154426.GI18191@nataraja.gnumonks.org> Message-ID: On Fri, Nov 22, 2013 at 10:44 AM, Harald Welte wrote: > Hi Max, > > I would like to merge your patch, but: > > On Tue, Nov 19, 2013 at 12:25:52PM +0100, ? wrote: >> +int >> +comp128v2(const uint8_t *ki, const uint8_t *rand, uint8_t *sres, uint8_t *kc) >> +{ >> + int r = comp128v3(ki, rand, sres, kc); >> + kc[7] = 0; /* 10 last bits of Kc forced to 0 */ >> + kc[6] &= 0xfc; >> + return r; >> +} > > this is space-indented, not tab-indented. > >> +static struct osmo_sub_auth_data test_aux2 = { >> + .type = OSMO_AUTH_TYPE_GSM, >> + .algo = OSMO_AUTH_ALG_COMP128v2, >> + .u.gsm = { >> + .ki = { 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA }, > > those lienes are too long for 80-character wide terminals > >> + uint8_t buf[12]; >> + osmo_hexparse(res, buf, 12); >> + if (0 != memcmp(buf, vec->sres, 4)) { >> + printf("%d FAIL SRES:\n", rc); > > there's again mixed space and tab indentation. > >> +void test_comp128v3(char * rand, char * res) { > > we put the curly braces at the beginning of the line, not at the end of > the line. And again the functions are space indented. > > Furthermore, your patch does not apply on top of master. > > It's sad to see that valuable contributions are lost due to basic coding > style issues not being observed. We had this back in April with your > KASUMI related patches, and it was never fixed. Please take the time > to fix those issues, thanks. I should probably keep my mouth shut here, but I've always wondered why.... Why not just fix it since this is a community effort? It takes longer to complain about it and reject it than it does to perform the actual work. (Sans the merge problem on Master). Anyway, please don't take it as a personal attack because its not. Lots of folks do it and I'm interested in understanding why they do it. Jeff From Max.Suraev at fairwaves.ru Fri Nov 22 18:14:39 2013 From: Max.Suraev at fairwaves.ru (=?UTF-8?B?4piO?=) Date: Fri, 22 Nov 2013 18:14:39 +0100 Subject: [PATCH] COMP128v23 improvements In-Reply-To: References: <528A52AA.1060109@fairwaves.ru> <20131119111618.1475.qmail@stuge.se> <528B4AC0.7060906@fairwaves.ru> <20131122154426.GI18191@nataraja.gnumonks.org> Message-ID: <528F90FF.5060909@fairwaves.ru> 22.11.2013 17:59, Jeffrey Walton ?????: > Why not just fix it since this is a community effort? It takes longer > to complain about it and reject it than it does to perform the actual > work. (Sans the merge problem on Master). > I second that. I mean I do understand that nobody wants to do the boring work which could be offloaded to others, and rightfully so. But that's also discouraging - and that's why those patches are stalled since spring: I use patched version locally and keep working on my research. Because it's research project, not some product there's no maintenance burden for me in this setup, while with pushing stuff upstream - there is. Hence the efforts to mainline things are not as ideal as they could be. Of course I would try to fix the patches anyway, so that they will please upstream, but not today - Friday evening, and so on :) I hope I do not sound complaining - just would like to clarify the difference. -- best regards, Max, http://fairwaves.ru From laforge at gnumonks.org Fri Nov 22 18:35:24 2013 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 22 Nov 2013 18:35:24 +0100 Subject: [PATCH] COMP128v23 improvements In-Reply-To: References: <528A52AA.1060109@fairwaves.ru> <20131119111618.1475.qmail@stuge.se> <528B4AC0.7060906@fairwaves.ru> <20131122154426.GI18191@nataraja.gnumonks.org> Message-ID: <20131122173524.GS18191@nataraja.gnumonks.org> Hi Jeffery, On Fri, Nov 22, 2013 at 11:59:28AM -0500, Jeffrey Walton wrote: > Why not just fix it since this is a community effort? It takes longer > to complain about it and reject it than it does to perform the actual > work. (Sans the merge problem on Master). well, number one reason is 'because this is the culture'. All (at least most) of the projects I have been involved in have a coding style. It is the duty of every developer to follow that. If I want to get something merged to wireshark, I have to use their coding style, not my personal one, no matter if I like it or not. If an occasional mistake happens, then that is excusable. But if I always post my patches without caring about the rules (including coding style), then it measn that I am perceived as being ignorant towards the project. Having a unified coding style is important for many software developers. Why am I not fixing it up? Because * I might break the code doing so (and I might not have the same test setup and familiarity with that paticular code / functionalty as the original subitter) * maintainers are typically overloaded in all projects. For efficient collaborative development it is important that the work for the maintainers is reduced, as they are single-point-of-failures. * maintainers are developers. They primarily like to write code, and like to be efficient/productive. 'wiping the floor' after other developers/contributors who have been too lazy to care about the rules of the project is tiresome, annoying, and generally not very productive use of their time It is not only the content of your work that matters, but also the style. Many people also consider it as disrespectful, if contributors are not willing to align with a projects style / rules / architecture. As a maintainer [and I'm not saying that I have been maintaining openbsc or related projects during the last year, I'm just generally speaking], I want contributors to learn how to write patches that I can simply apply without having to spend time on it except reading through the code. If I always fix up everyones patches, I will do that for the years to come and will not do anything else (more productive). Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From 246tnt at gmail.com Fri Nov 22 19:35:37 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 22 Nov 2013 19:35:37 +0100 Subject: [PATCH] Add A5 and GEA ciphers In-Reply-To: <20131122154038.GH18191@nataraja.gnumonks.org> References: <51616FD3.7060001@fairwaves.ru> <5162CFD8.1000405@fairwaves.ru> <20131122154038.GH18191@nataraja.gnumonks.org> Message-ID: Hi Harald, I actually got back to Max about this patch and I'll handle getting it merged and test it OTA as part of some security improvement stuff I'm working on. Cheers, Sylvain On Fri, Nov 22, 2013 at 4:40 PM, Harald Welte wrote: > Dear Max, > > I'm getting back to this old thread about your kasumi, A5/3 and A5/4 > patches. > > There were lots of comments during the review in April, but I never saw > a follow-up patchset that adressed those comments. > > Particularly, from the discussion, I remember: > 1) follow kernel coding style > 2) whitespace / tab spacing > 3) line wrapping > 4) naming of helper routines which are generic accessor functions. > > On Mon, Apr 08, 2013 at 04:10:32PM +0200, ? wrote: >> > +uint16_t osmo_get2bytes(const uint8_t *a); >> > +void osmo_64pack2pbit(uint64_t in, pbit_t *out); >> > >> > Theses essentially look like integer accessors, one is a read for >> > uint16_t in big endian and the other a store for uint64_t in little >> > endian, but same basic idea. But you're using completely different >> > naming schemes for both ... I think they should reflect that their >> > name should reflect the LE/BE part and the unaligned part as well, I >> > even think there are already macro somewhere for that. I would also >> > add other formats like LE/BE 16/32/64 bits store/load all at once >> > rather than each format when needed. If we add accessort, might as >> > well add all the basic types. And finally those should really be >> > inline functions in the .h, no point of doing a function call for >> > that. >> >> Is there some library I can use for that? It's indeed fairly trivial >> accessors but I didn't managed to find those in osmocom code. > > If there is no function / macro in libosmo* yet, then looking for kernel > function names is always a good idea. > > we have msgb_{put,get,pull}_u{8/16/32}() as accessors for working with > message buffers. If msgb doesn't make sense in the context you are > working in, then aligning the names to the same scheme might be another > idea. > > Regards, > Harald > -- > - Harald Welte http://laforge.gnumonks.org/ > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) > From laforge at gnumonks.org Fri Nov 22 20:50:20 2013 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 22 Nov 2013 20:50:20 +0100 Subject: [PATCH] Add A5 and GEA ciphers In-Reply-To: References: <51616FD3.7060001@fairwaves.ru> <5162CFD8.1000405@fairwaves.ru> <20131122154038.GH18191@nataraja.gnumonks.org> Message-ID: <20131122195020.GF25481@nataraja.gnumonks.org> Hi Sylvain, On Fri, Nov 22, 2013 at 07:35:37PM +0100, Sylvain Munaut wrote: > I actually got back to Max about this patch and I'll handle getting it > merged and test it OTA as part of some security improvement stuff I'm > working on. Ah, ok. thanks. Sorry in case I missed that on the list. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From noloader at gmail.com Fri Nov 22 22:02:12 2013 From: noloader at gmail.com (Jeffrey Walton) Date: Fri, 22 Nov 2013 16:02:12 -0500 Subject: [PATCH] COMP128v23 improvements In-Reply-To: <20131122173524.GS18191@nataraja.gnumonks.org> References: <528A52AA.1060109@fairwaves.ru> <20131119111618.1475.qmail@stuge.se> <528B4AC0.7060906@fairwaves.ru> <20131122154426.GI18191@nataraja.gnumonks.org> <20131122173524.GS18191@nataraja.gnumonks.org> Message-ID: On Fri, Nov 22, 2013 at 12:35 PM, Harald Welte wrote: > Hi Jeffery, > > On Fri, Nov 22, 2013 at 11:59:28AM -0500, Jeffrey Walton wrote: > >> Why not just fix it since this is a community effort? It takes longer >> to complain about it and reject it than it does to perform the actual >> work. (Sans the merge problem on Master). > > well, number one reason is 'because this is the culture'. All (at least > most) of the projects I have been involved in have a coding style. It > is the duty of every developer to follow that. If I want to get > something merged to wireshark, I have to use their coding style, not my > personal one, no matter if I like it or not. > > If an occasional mistake happens, then that is excusable. But if I > always post my patches without caring about the rules (including coding > style), then it measn that I am perceived as being ignorant towards the > project. > > Having a unified coding style is important for many software developers. > > Why am I not fixing it up? Because > * I might break the code doing so (and I might not have the same > test setup and familiarity with that paticular code / functionalty as > the original subitter) > * maintainers are typically overloaded in all projects. For efficient > collaborative development it is important that the work for the > maintainers is reduced, as they are single-point-of-failures. > * maintainers are developers. They primarily like to write code, and > like to be efficient/productive. 'wiping the floor' after other > developers/contributors who have been too lazy to care about the > rules of the project is tiresome, annoying, and generally not very > productive use of their time > > It is not only the content of your work that matters, but also the > style. Many people also consider it as disrespectful, if contributors > are not willing to align with a projects style / rules / architecture. > > As a maintainer [and I'm not saying that I have been maintaining openbsc > or related projects during the last year, I'm just generally speaking], I > want contributors to learn how to write patches that I can simply apply > without having to spend time on it except reading through the code. If > I always fix up everyones patches, I will do that for the years to come > and will not do anything else (more productive). Thanks Harald. I think there are a lot of good points here. If these things matter that much, why not use a commit hook that enforces policy by applying formatting without prejudice? With a commit hook, you don't waste your time or get frustrated with committers, and developers don't waste their time learning yet another set of standards and idiosyncrasies. The time could then be better spent on things like writing code or reviewing proposed functionality. Jeff From zero-kelvin at gmx.de Fri Nov 22 22:06:23 2013 From: zero-kelvin at gmx.de (dexter) Date: Fri, 22 Nov 2013 22:06:23 +0100 Subject: UPDATE -- Osmocom Berlin User Group meeting -- NEXT MEETING In-Reply-To: <20130605121428.GA10030@nataraja.gnumonks.org> References: <502d01a9.mirider@mirider.augusta.de> <20120818115942.GV29525@prithivi.gnumonks.org> <51AF0097.10402@gmx.de> <20130605121428.GA10030@nataraja.gnumonks.org> Message-ID: <528FC74F.3090705@gmx.de> Hi All. It's time Again! This is the announcement for the next Osmocom Berlin meeting. Nov 27, 8pm @ CCC Berlin, Marienstr. 11, 10117 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. I am looking forward to see you there! regards. Philipp From acassis at gmail.com Sat Nov 23 22:27:15 2013 From: acassis at gmail.com (Alan Carvalho de Assis) Date: Sat, 23 Nov 2013 19:27:15 -0200 Subject: [OT] The second operating system hiding in every mobile phone Message-ID: This post is about the proprietary baseband RTOS. It is calling public attention about the danger of running a proprietary RTOS on your phone: http://www.osnews.com/story/27416/The_second_operating_system_hiding_in_every_mobile_phone From Max.Suraev at fairwaves.ru Sun Nov 24 11:03:15 2013 From: Max.Suraev at fairwaves.ru (=?UTF-8?B?4piO?=) Date: Sun, 24 Nov 2013 11:03:15 +0100 Subject: [OT] The second operating system hiding in every mobile phone In-Reply-To: References: Message-ID: <5291CEE3.4040308@fairwaves.ru> They forgot to mention 3rd OS running inside each sim card :) 23.11.2013 22:27, Alan Carvalho de Assis ?????: > This post is about the proprietary baseband RTOS. > > It is calling public attention about the danger of running a > proprietary RTOS on your phone: > > http://www.osnews.com/story/27416/The_second_operating_system_hiding_in_every_mobile_phone > -- best regards, Max, http://fairwaves.ru From craig_comstock at yahoo.com Sun Nov 24 14:05:00 2013 From: craig_comstock at yahoo.com (Craig Comstock) Date: Sun, 24 Nov 2013 05:05:00 -0800 (PST) Subject: [OT] The second operating system hiding in every mobile phone In-Reply-To: References: Message-ID: <1385298300.97909.YahooMailNeo@web121002.mail.ne1.yahoo.com> Does anyone know if there are other models other than the Icon 225 that have this diagnostic mode? I just bought and Icon 225 via ebay but it is a CDMA version from Hungary. If all I can do is play around with the diagnostic mode that's fine but if another device would also work with GSM that would be more fun. Thanks Alan, Craig On Saturday, November 23, 2013 3:38 PM, Alan Carvalho de Assis wrote: This post is about the proprietary baseband RTOS. It is calling public attention about the danger of running a proprietary RTOS on your phone: http://www.osnews.com/story/27416/The_second_operating_system_hiding_in_every_mobile_phone -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig_comstock at yahoo.com Sun Nov 24 14:26:26 2013 From: craig_comstock at yahoo.com (Craig Comstock) Date: Sun, 24 Nov 2013 05:26:26 -0800 (PST) Subject: [OT] The second operating system hiding in every mobile phone In-Reply-To: <1385298300.97909.YahooMailNeo@web121002.mail.ne1.yahoo.com> References: <1385298300.97909.YahooMailNeo@web121002.mail.ne1.yahoo.com> Message-ID: <1385299586.80997.YahooMailNeo@web121002.mail.ne1.yahoo.com> I am trying two sticks: http://www.ebay.com/itm/Qualcomm-3G-CDMA-model-GIO-225-T-Mobile-HU-locked-webnwalk-stick-USB-dongle-/271329079775? and http://www.ebay.com/itm/HSDPA-EDGE-7-2Mbps-Wireless-USB-3G-Network-Modem-Adapter-TF-SIM-Card-Slot-G9-/171176662900? I'll let y'all know how it goes. I'm curious if that diagnostic channel is available in other devices. I have a geeksphone keon that I sure would like to make more free... -Craig On Sunday, November 24, 2013 7:05 AM, Craig Comstock wrote: Does anyone know if there are other models other than the Icon 225 that have this diagnostic mode? I just bought and Icon 225 via ebay but it is a CDMA version from Hungary. If all I can do is play around with the diagnostic mode that's fine but if another device would also work with GSM that would be more fun. Thanks Alan, Craig On Saturday, November 23, 2013 3:38 PM, Alan Carvalho de Assis wrote: This post is about the proprietary baseband RTOS. It is calling public attention about the danger of running a proprietary RTOS on your phone: http://www.osnews.com/story/27416/The_second_operating_system_hiding_in_every_mobile_phone -------------- next part -------------- An HTML attachment was scrubbed... URL: From Max.Suraev at fairwaves.ru Mon Nov 25 12:20:33 2013 From: Max.Suraev at fairwaves.ru (=?UTF-8?B?4piO?=) Date: Mon, 25 Nov 2013 12:20:33 +0100 Subject: [PATCH] COMP128v23 improvements In-Reply-To: <20131122154426.GI18191@nataraja.gnumonks.org> References: <528A52AA.1060109@fairwaves.ru> <20131119111618.1475.qmail@stuge.se> <528B4AC0.7060906@fairwaves.ru> <20131122154426.GI18191@nataraja.gnumonks.org> Message-ID: <52933281.5000908@fairwaves.ru> All fixed. Let me know if I've overlooked something. 22.11.2013 16:44, Harald Welte ?????: > Hi Max, > > I would like to merge your patch, but: > > On Tue, Nov 19, 2013 at 12:25:52PM +0100, ? wrote: >> +int >> +comp128v2(const uint8_t *ki, const uint8_t *rand, uint8_t *sres, uint8_t *kc) >> +{ >> + int r = comp128v3(ki, rand, sres, kc); >> + kc[7] = 0; /* 10 last bits of Kc forced to 0 */ >> + kc[6] &= 0xfc; >> + return r; >> +} > this is space-indented, not tab-indented. > >> +static struct osmo_sub_auth_data test_aux2 = { >> + .type = OSMO_AUTH_TYPE_GSM, >> + .algo = OSMO_AUTH_ALG_COMP128v2, >> + .u.gsm = { >> + .ki = { 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA }, > those lienes are too long for 80-character wide terminals > >> + uint8_t buf[12]; >> + osmo_hexparse(res, buf, 12); >> + if (0 != memcmp(buf, vec->sres, 4)) { >> + printf("%d FAIL SRES:\n", rc); > there's again mixed space and tab indentation. > >> +void test_comp128v3(char * rand, char * res) { > we put the curly braces at the beginning of the line, not at the end of > the line. And again the functions are space indented. > > Furthermore, your patch does not apply on top of master. > > It's sad to see that valuable contributions are lost due to basic coding > style issues not being observed. We had this back in April with your > KASUMI related patches, and it was never fixed. Please take the time > to fix those issues, thanks. > > Regards, > Harald -- best regards, Max, http://fairwaves.ru -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Refactor-COMP128v23-implementation-and-add-test-suit-v4.patch Type: text/x-patch Size: 187908 bytes Desc: not available URL: From Max.Suraev at fairwaves.ru Wed Nov 27 17:33:58 2013 From: Max.Suraev at fairwaves.ru (=?UTF-8?B?4piO?=) Date: Wed, 27 Nov 2013 17:33:58 +0100 Subject: [PATCH] RFC - change GPRS cipher API Message-ID: <52961EF6.4060107@fairwaves.ru> Hello. Attached is a trivial patch which breaks existing GPRS cipher API of libosmocore by switching from fixed 64-bit length Kc to variable-length. There are several justifications for that: - compliance with ETSI TS 155.22 (GEA4 - 128 bits Kc) and all further versions - similarity to existing auth api (osmocom/crypt/auth.h uses 128 bits as well) - nobody uses this API anyway (except my other patches with GEA) - patch breaks nothing within libosmocore (make check succeeds) and openbsc (uses gea0 only) That's why I think next libosmocore version should apply this patch and change unused API before someone actually start using it and makes transition more difficult. -- best regards, Max, http://fairwaves.ru -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Change-GPRS-cipher-API-to-comply-with-ETSI-TS-155-22.patch Type: text/x-patch Size: 2491 bytes Desc: not available URL: From osmocom at ngolde.de Wed Nov 27 17:47:22 2013 From: osmocom at ngolde.de (Nico Golde) Date: Wed, 27 Nov 2013 17:47:22 +0100 Subject: [OT] The second operating system hiding in every mobile phone In-Reply-To: References: Message-ID: <20131127164722.GI26456@ngolde.de> Hi, * Alan Carvalho de Assis [2013-11-23 22:41]: > This post is about the proprietary baseband RTOS. Yeah and most of the information in that article is either pretty uninformed when it comes to details or heavily outdated. Cheers Nico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From omarzia88 at gmail.com Wed Nov 27 11:35:10 2013 From: omarzia88 at gmail.com (Omar Zia) Date: Wed, 27 Nov 2013 15:35:10 +0500 Subject: Help regarding osmocombb installation Message-ID: i am referring to the following url http://lists.osmocom.org/pipermail/baseband-devel/2013-March/003907.html It seems that you had the same problem.please guide me how to resolve the issue in detail. Thankyou -------------- next part -------------- An HTML attachment was scrubbed... URL: From Max.Suraev at fairwaves.ru Thu Nov 28 12:59:55 2013 From: Max.Suraev at fairwaves.ru (=?UTF-8?B?4piO?=) Date: Thu, 28 Nov 2013 12:59:55 +0100 Subject: format-security Message-ID: <5297303B.5080802@fairwaves.ru> Hi all. Fedora recently enabled -Werror=format-security by default for all packages to prevent format string vulnerabilities from appearing. Should we do this as well for libosmocore? openbsc? other (sub)projects as well? What do you think? -- best regards, Max, http://fairwaves.ru