From laforge at gnumonks.org Sun Dec 1 14:35:01 2013 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 1 Dec 2013 14:35:01 +0100 Subject: [PATCH] RFC - change GPRS cipher API In-Reply-To: <52961EF6.4060107@fairwaves.ru> References: <52961EF6.4060107@fairwaves.ru> Message-ID: <20131201133501.GL3133@nataraja.gnumonks.org> Hi Max, On Wed, Nov 27, 2013 at 05:33:58PM +0100, ? wrote: > Attached is a trivial patch which breaks existing GPRS cipher API of > libosmocore by switching from fixed 64-bit length Kc to > variable-length. I like it. > There are several justifications for that: Agreed. > - nobody uses this API anyway (except my other patches with GEA) Well, there is libosmo-crypt-a53, which impements also GEA3 and which registers a cipher. That would need to change, too. > 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. There may very well be existing code that you or I don't know about. We will have to change LIBVERSION to announce ABI breakage, but that's not a problem... 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 Dec 1 14:39:22 2013 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 1 Dec 2013 14:39:22 +0100 Subject: [PATCH] COMP128v23 improvements In-Reply-To: <52933281.5000908@fairwaves.ru> References: <528A52AA.1060109@fairwaves.ru> <20131119111618.1475.qmail@stuge.se> <528B4AC0.7060906@fairwaves.ru> <20131122154426.GI18191@nataraja.gnumonks.org> <52933281.5000908@fairwaves.ru> Message-ID: <20131201133922.GM3133@nataraja.gnumonks.org> Hi Max, On Mon, Nov 25, 2013 at 12:20:33PM +0100, ? wrote: > All fixed. Let me know if I've overlooked something. thanks. it looks fine to me, and if it was applying to libosmocore/master, I would have merged it today :) Just for sake of completeness, the linux kernel checkpatch.pl script finds the following issues (which I would ignore, but just as a general rule, it is a good way to catch coding style issues): ------------ WARNING: line over 80 characters #45: FILE: include/osmocom/gsm/comp128v23.h:20: +int comp128v2(const uint8_t *ki, const uint8_t *rand, uint8_t *sres, uint8_t *kc); WARNING: line over 80 characters #46: FILE: include/osmocom/gsm/comp128v23.h:21: +int comp128v3(const uint8_t *ki, const uint8_t *rand, uint8_t *sres, uint8_t *kc); WARNING: please, no spaces at the start of a line #225: FILE: tests/comp128/comp128_test.c:18: + }$ WARNING: please, no spaces at the start of a line #234: FILE: tests/comp128/comp128_test.c:27: + }$ ERROR: "foo * bar" should be "foo *bar" #237: FILE: tests/comp128/comp128_test.c:30: +void print_check(int rc, char * res, struct osmo_auth_vector *vec) ERROR: trailing statements should be on next line #251: FILE: tests/comp128/comp128_test.c:44: + else printf("%d OK\n", rc); ERROR: else should follow close brace '}' #251: FILE: tests/comp128/comp128_test.c:44: + } + else printf("%d OK\n", rc); ERROR: "foo * bar" should be "foo *bar" #254: FILE: tests/comp128/comp128_test.c:47: +void test_comp128v3(char * rand, char * res) ERROR: "foo * bar" should be "foo *bar" #254: FILE: tests/comp128/comp128_test.c:47: +void test_comp128v3(char * rand, char * res) ERROR: "foo * bar" should be "foo *bar" #264: FILE: tests/comp128/comp128_test.c:57: +void test_comp128v2(char * rand, char * res) ERROR: "foo * bar" should be "foo *bar" #264: FILE: tests/comp128/comp128_test.c:57: +void test_comp128v2(char * rand, char * res) ------------ Regards, -- - 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 Dec 1 14:31:21 2013 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 1 Dec 2013 14:31:21 +0100 Subject: format-security In-Reply-To: <5297303B.5080802@fairwaves.ru> References: <5297303B.5080802@fairwaves.ru> Message-ID: <20131201133121.GK3133@nataraja.gnumonks.org> Hi Max, On Thu, Nov 28, 2013 at 12:59:55PM +0100, ? wrote: > Should we do this as well for libosmocore? openbsc? other > (sub)projects as well? Yes, I would consider that a useful change. But please also fix any of the current warnings in the same patchset, so we don't end up with code that doesn't compile anymore... -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From peter at stuge.se Sun Dec 1 19:17:07 2013 From: peter at stuge.se (Peter Stuge) Date: Sun, 1 Dec 2013 19:17:07 +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> <20131122173524.GS18191@nataraja.gnumonks.org> Message-ID: <20131201181707.23592.qmail@stuge.se> Jeffrey Walton wrote: > 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? Because we'd like to have developers share a cohesive culture around the code and code style rather than have developers that are unable to do better than agree to disagree about something so simple as style, and resign to have a computer fix up the differences. If not even agreement about style can be accomplished then it's not very likely that much other agreement can be had either. (Unfortunately I know that all too well from experience.) > developers don't waste their time learning yet another set of > standards and idiosyncrasies. I think that statement is quite intolerant of you. Learning a culture by slowly immersing oneself in it is never a waste of time, I think it enriches life in more ways than we can know. If developers do not want to work together then they shouldn't pretend; it would be much better to go separate ways. //Peter From peter at stuge.se Sun Dec 1 19:41:12 2013 From: peter at stuge.se (Peter Stuge) Date: Sun, 1 Dec 2013 19:41:12 +0100 Subject: [PATCH] COMP128v23 improvements In-Reply-To: <528F90FF.5060909@fairwaves.ru> References: <528A52AA.1060109@fairwaves.ru> <20131119111618.1475.qmail@stuge.se> <528B4AC0.7060906@fairwaves.ru> <20131122154426.GI18191@nataraja.gnumonks.org> <528F90FF.5060909@fairwaves.ru> Message-ID: <20131201184112.26360.qmail@stuge.se> ? 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). > > I second that. Complaining and rejecting might take longer but also sends a clear message that actually the development in this project has to follow style. Trust me, wiping the floor after other people, as Harald expressed it, is not sustainable and becomes much more frustrating for everyone. > I mean I do understand that nobody wants to do the boring work Right, so it seems reasonable that style is the responsibility of the original patch author, don't you think? Pro tip: Use the correct style already when creating the patch, that way there is no extra step of boring reformatting/cleanup work. > But that's also discouraging - and that's why those patches are > stalled since spring: I use patched version locally To me it says that you were too unattentive or too lazy to follow the coding style when originally creating those changes, and that now you don't care to fix the changes so that others can benefit from them. There are lots of valid reasons for not immediately using the correct style, but never fixing old commits makes me go: Sad face. :\ > Because it's research project .. no maintenance burden for me in > this setup, while with pushing stuff upstream - there is. Probably the upstream code has helped you save some time in the research project, so I think it is a fair tradeoff for you to spend time also giving back to the codebase - and you do! I think you're doing a great job, you're certainly contributing to the project, it's just unfortunate for everybody that you haven't tidied those old patches. If the project was developing at a higher pace they could have bitrotted already. :\ > Hence the efforts to mainline things are not as ideal as they could be. In the end that's always up to each individual contributor. > Of course I would try to fix the patches anyway, so that they will > please upstream, but not today - Friday evening, and so on :) For me it's not about pleasing upstream, but about recognizing the importance of following style in order to increase maintainability of the source code as a whole, and to decrease load on maintainers, so that development progress is as smooth as possible. > I hope I do not sound complaining I don't think you sound like you are complaining but I do think that the responsibility to format contributions according to project style lies firmly with each individual contributor and never anywhere else. Kind regards //Peter From holger at freyther.de Mon Dec 2 08:29:17 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 2 Dec 2013 08:29:17 +0100 Subject: format-security In-Reply-To: <20131201133121.GK3133@nataraja.gnumonks.org> References: <5297303B.5080802@fairwaves.ru> <20131201133121.GK3133@nataraja.gnumonks.org> Message-ID: <20131202072917.GB2877@xiaoyu.lan> On Sun, Dec 01, 2013 at 02:31:21PM +0100, Harald Welte wrote: > Hi Max, > > On Thu, Nov 28, 2013 at 12:59:55PM +0100, ? wrote: > > Should we do this as well for libosmocore? openbsc? other > > (sub)projects as well? > > Yes, I would consider that a useful change. But please also fix any of > the current warnings in the same patchset, so we don't end up with code > that doesn't compile anymore... Please have a look here[1] for some warnings and how to write tests for checking if the compiler supports them. In the long run I want the jenkins compile the code with -Werror. We introduce compiler warnings more quickly than the rest of us can fix them. holger [1] https://git.gnome.org/browse/folks/tree/configure.ac?id=18c629cf1d40a72c5f9f04a31dbdf4a265306cd9#n496 From noloader at gmail.com Mon Dec 2 09:13:46 2013 From: noloader at gmail.com (Jeffrey Walton) Date: Mon, 2 Dec 2013 03:13:46 -0500 Subject: format-security In-Reply-To: <20131202072917.GB2877@xiaoyu.lan> References: <5297303B.5080802@fairwaves.ru> <20131201133121.GK3133@nataraja.gnumonks.org> <20131202072917.GB2877@xiaoyu.lan> Message-ID: On Mon, Dec 2, 2013 at 2:29 AM, Holger Hans Peter Freyther wrote: > On Sun, Dec 01, 2013 at 02:31:21PM +0100, Harald Welte wrote: >> Hi Max, >> >> On Thu, Nov 28, 2013 at 12:59:55PM +0100, ? wrote: >> > Should we do this as well for libosmocore? openbsc? other >> > (sub)projects as well? >> >> Yes, I would consider that a useful change. But please also fix any of >> the current warnings in the same patchset, so we don't end up with code >> that doesn't compile anymore... > > Please have a look here[1] for some warnings and how to write tests for > checking if the compiler supports them. In the long run I want the jenkins > compile the code with -Werror. We introduce compiler warnings more quickly > than the rest of us can fix them. > > [1] https://git.gnome.org/browse/folks/tree/configure.ac?id=18c629cf1d40a72c5f9f04a31dbdf4a265306cd9#n496 The list is missing a number of useful flags. -Wconversion: its always a surprise when -1 > 1. -Wcast-align: save you from violating alignment and bricking your process on a processor that can't perform fixups -Wtrampolines: executable code on the stack -Woverloaded-virtual: relevant to C++ code Plus, you have the standard security options like PIC/PIE, stack protectors, nx stacks, nx heaps, fortify sources, relro (GOT hardening), now (PLT hardening), etc. I'm not sure how much is available to the project due to hardware and implementation restrictions, though. Jeff From Max.Suraev at fairwaves.ru Mon Dec 2 11:08:07 2013 From: Max.Suraev at fairwaves.ru (=?UTF-8?B?4piO?=) Date: Mon, 02 Dec 2013 11:08:07 +0100 Subject: [PATCH] RFC - change GPRS cipher API In-Reply-To: <20131201133501.GL3133@nataraja.gnumonks.org> References: <52961EF6.4060107@fairwaves.ru> <20131201133501.GL3133@nataraja.gnumonks.org> Message-ID: <529C5C07.1060404@fairwaves.ru> 01.12.2013 14:35, Harald Welte ?????: > Well, there is libosmo-crypt-a53, which impements also GEA3 and which > registers a cipher. That would need to change, too. > Speaking of which - as far as I recall it's based on sample implementation with license incompatible with (L)GPL. Could we just discontinue it once Sylvain massage my a5/3,4 gea3,4 patches into libosmocore? -- best regards, Max, http://fairwaves.ru From Max.Suraev at fairwaves.ru Mon Dec 2 11:36:08 2013 From: Max.Suraev at fairwaves.ru (=?UTF-8?B?4piO?=) Date: Mon, 02 Dec 2013 11:36:08 +0100 Subject: [PATCH] COMP128v23 improvements In-Reply-To: <20131201133922.GM3133@nataraja.gnumonks.org> References: <528A52AA.1060109@fairwaves.ru> <20131119111618.1475.qmail@stuge.se> <528B4AC0.7060906@fairwaves.ru> <20131122154426.GI18191@nataraja.gnumonks.org> <52933281.5000908@fairwaves.ru> <20131201133922.GM3133@nataraja.gnumonks.org> Message-ID: <529C6298.7090602@fairwaves.ru> 01.12.2013 14:39, Harald Welte ?????: > Hi Max, > > On Mon, Nov 25, 2013 at 12:20:33PM +0100, ? wrote: >> All fixed. Let me know if I've overlooked something. > > thanks. it looks fine to me, and if it was applying to > libosmocore/master, I would have merged it today :) Hmm... it applies with patch --dry-run -p1 < 0001-Refactor-COMP128v23-implementation-and-add-test-suit-v5.patch just fine. What exactly is wrong and how do I fix it? I've made a patch using "git format-patch" - is there some better way? > > Just for sake of completeness, the linux kernel checkpatch.pl script > finds the following issues (which I would ignore, but just as a general > rule, it is a good way to catch coding style issues): > > ------------ > WARNING: line over 80 characters > #45: FILE: include/osmocom/gsm/comp128v23.h:20: > +int comp128v2(const uint8_t *ki, const uint8_t *rand, uint8_t *sres, uint8_t *kc); > > WARNING: line over 80 characters > #46: FILE: include/osmocom/gsm/comp128v23.h:21: > +int comp128v3(const uint8_t *ki, const uint8_t *rand, uint8_t *sres, uint8_t *kc); > With all due respect - those are shorter than the line they are replacing which is already committed to the git. The rest I have corrected. -- best regards, Max, http://fairwaves.ru -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Refactor-COMP128v23-implementation-and-add-test-suit-v5.patch Type: text/x-patch Size: 187897 bytes Desc: not available URL: From holger at freyther.de Mon Dec 2 12:04:49 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 2 Dec 2013 12:04:49 +0100 Subject: [PATCH] COMP128v23 improvements In-Reply-To: <529C6298.7090602@fairwaves.ru> References: <528A52AA.1060109@fairwaves.ru> <20131119111618.1475.qmail@stuge.se> <528B4AC0.7060906@fairwaves.ru> <20131122154426.GI18191@nataraja.gnumonks.org> <52933281.5000908@fairwaves.ru> <20131201133922.GM3133@nataraja.gnumonks.org> <529C6298.7090602@fairwaves.ru> Message-ID: <20131202110449.GF2877@xiaoyu.lan> On Mon, Dec 02, 2013 at 11:36:08AM +0100, ? wrote: > > With all due respect - those are shorter than the line they are replacing which is > already committed to the git. Yes, that is why this is a warning. It can be okay to overflow the line. From laforge at gnumonks.org Sat Dec 7 18:21:22 2013 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 7 Dec 2013 18:21:22 +0100 Subject: [PATCH] RFC - change GPRS cipher API In-Reply-To: <529C5C07.1060404@fairwaves.ru> References: <52961EF6.4060107@fairwaves.ru> <20131201133501.GL3133@nataraja.gnumonks.org> <529C5C07.1060404@fairwaves.ru> Message-ID: <20131207172122.GC8435@nataraja.gnumonks.org> Hi Max, On Mon, Dec 02, 2013 at 11:08:07AM +0100, ? wrote: > Speaking of which - as far as I recall it's based on sample > implementation with license incompatible with (L)GPL. Could we just > discontinue it once Sylvain massage my a5/3,4 gea3,4 patches into > libosmocore? yes, if those are a feature-complete replacement, there is no need for the old library. -- - 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 Sat Dec 7 18:13:17 2013 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 7 Dec 2013 18:13:17 +0100 Subject: [PATCH] COMP128v23 improvements In-Reply-To: <529C6298.7090602@fairwaves.ru> References: <528A52AA.1060109@fairwaves.ru> <20131119111618.1475.qmail@stuge.se> <528B4AC0.7060906@fairwaves.ru> <20131122154426.GI18191@nataraja.gnumonks.org> <52933281.5000908@fairwaves.ru> <20131201133922.GM3133@nataraja.gnumonks.org> <529C6298.7090602@fairwaves.ru> Message-ID: <20131207171317.GB8435@nataraja.gnumonks.org> Hi Max, On Mon, Dec 02, 2013 at 11:36:08AM +0100, ? wrote: > Hmm... it applies with > patch --dry-run -p1 < 0001-Refactor-COMP128v23-implementation-and-add-test-suit-v5.patch > just fine. What exactly is wrong and how do I fix it? > I've made a patch using "git format-patch" - is there some better way? my apologies. It was a broken setup on my side. 'git format-patch' (on top of master branch) is the best way, of course. > With all due respect - those are shorter than the line they are > replacing which is already committed to the git. Yes. The original code is not perfect, and sometimes we bend the rules accidentially or intentionally. Also, the code normally doesn't go through the kernels checkpatch.pl - we simply write it with the coding style in mind. Also, as holger has indicated, those are warnings and not errors. Thanks for taking the extra time to clean it up, even if you are personally not convinced it would be neccessary. Please continue to do so with any other patches that you may have pending. We do want to get things merged and avoid fragmentation. 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 wsmd78 at gmail.com Sun Dec 8 14:30:09 2013 From: wsmd78 at gmail.com (shrek wu) Date: Sun, 8 Dec 2013 21:30:09 +0800 Subject: how i can send voice from PC to osmocom-bb, and recv traffic voice from osmocom-bb to PC Message-ID: hello everybody I want to use LCR send voice from PC to osmocom-bb, and recv traffic voice from osmocom-bb to PC. So at osmocom-bb/src/host/layer23/src/mobile/gsm48_rr.c int gsm48_rr_init(struct osmocom_ms *ms) I change >From : rr->audio_mode = AUDIO_TX_MICROPHONE | AUDIO_RX_SPEAKER; TO: rr->audio_mode = AUDIO_TX_TRAFFIC_REQ | AUDIO_RX_TRAFFIC_IND; And add some printf at voice.c when run bb, i used one c118, I can see that the voice data from L2/L3 to L1, and got some data from L1(the first char is 0xd) at l1ctr.c l1ctr_traffic_ind. All seem ok, but the called phone can not hear any data that LCR send, and the LCR also can not get any useful data. Especially I still can hear voice form C118 speaker that the called phone send, and the called phone can hear that the voice data the C118 michone send. But I already changed the audio mode in gsm48_rr.c at gsm48_rr_init. please give me some advice. best regards shrek From baseband at infodn.rmi.de Mon Dec 9 14:34:32 2013 From: baseband at infodn.rmi.de (Walter Doerr) Date: Mon, 09 Dec 2013 14:34:32 +0100 Subject: Problem uploading .bin files on Raspberry Pi Message-ID: Hello, I am running osmocom-bb on a Ubuntu x86 machine with a Motorola C121. Everything works (as far as I can tell). Now I would like to move the host programs to a Raspberry Pi. So, I did a "make nofirmware" on the Rpi and copied the *.compalram.bin files from the x86 Ubuntu box over to the Rpi. When I use osmocon on the pi to upload the bin file to the phone, the transfer stops after the "finished" line and then, after a while, the phone sends a DOWNLOAD NAK, instead of the usual "DOWNLOAD ACK your code is running now". Has anybody seen this behaviour and knows how to fix it? I have tried two USB/serial adapters (both FTDI based) just in case its a hw problem, but the result is always the same: the upload to the phone works on the Ubuntu/x86 box but not on the pi. Any help is greatly appreciated. Kind Regards, -Walter From Max.Suraev at fairwaves.ru Mon Dec 16 16:18:42 2013 From: Max.Suraev at fairwaves.ru (=?UTF-8?B?4piO?=) Date: Mon, 16 Dec 2013 16:18:42 +0100 Subject: [PATCH] warnings cleanup Message-ID: <52AF19D2.9060603@fairwaves.ru> Hi all. I'd like to see osmocom-bb builds less cluttered by compiler warnings - attached is (far from complete) attempt to do so. It's tested which means it builds on my machine and resulting mobile app seems to run fine - no in-depth testing were made. However I'd like to get some feedback before going further: there seems to be some evil hackery happening around src/target/firmware/apps/loader/main.c: Why do we have external "unsigned char _start" which later used as msgb_put_u32(msg, &_start); Do we make some assumptions on the size of unsigned char? Is this documented somewhere by any chance? Also there are plenty of warnings regarding alignment: some things are marked as "__attribute__ ((packed))" and some are not which seems to make compiler unhappy. Is there rule of thumb to decide when we should care about alignment? -- best regards, Max, http://fairwaves.ru -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-cleanup-some-compile-warnings.patch Type: text/x-patch Size: 7726 bytes Desc: not available URL: From lukash at backstep.net Mon Dec 16 16:56:59 2013 From: lukash at backstep.net (Lukas Kuzmiak) Date: Mon, 16 Dec 2013 16:56:59 +0100 Subject: patches for SIM in the firmware Message-ID: <64B37ED8-69BF-4C99-A141-6C346B8A5FEA@backstep.net> Hello guys, attached is a patch that fixes a few issues regarding SIM reader in Motorola phones (tested on C123), description: if there?s a lot of reading from SIM it happens a FIFO gets full, IMHO the right way is to read until the FIFO is empty (while-loop added) FETCH APDU has to be handled in the same way as GET RESPONSE (added) once REG_SIM_IT_SIM_NATR is triggered it should set the rxDoneFlag to 1 because otherwise there?s trouble recognising NO SIM state on L1 if SIM isn?t present in calypso_sim_powerup() and calypso_sim_reset() should set state to IDLE and put sim_len to 0 because if you do powerdown/powerup the state machine gets messed up unsetting CONFBYPASS should make the CONFSVCCLEV and CONFSRSTLEV irrelevant but it doesn?t, calypso_sim_powerdown() fixed based on calypso spec both calypso_sim_powerup() and calypso_sim_powerup() now return ATR as it should be when you poweron/reset the card some minor debug messages fixed to keep all the messages consistent Patch is apply-able on the current master. Cheers! Lukas -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sim_fw_fixes.patch Type: application/octet-stream Size: 6133 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3562 bytes Desc: not available URL: From Max.Suraev at fairwaves.ru Mon Dec 16 17:11:58 2013 From: Max.Suraev at fairwaves.ru (=?UTF-8?B?4piO?=) Date: Mon, 16 Dec 2013 17:11:58 +0100 Subject: [PATCH] adjust msgb api Message-ID: <52AF264E.1020903@fairwaves.ru> Hi. While looking at osmocom-bb compilation warnings I've noticed that there are plenty of those cause by signed-unsigned comparison with msgb-related functions. Attached is a trivial patch which fixes that by changing int -> uint16_t. For the sake of completeness I've also changed other functions to explicitly use uint16_t - this is used for length fields in "struct msgb" anyway. Although technically it's API change I do not expect any sane code to break. If you still think it's potentially insecure, this could be applied during next api version bump alongside with gprs api change. -- best regards, Max, http://fairwaves.ru -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-change-length-related-return-values-to-unsigned.patch Type: text/x-patch Size: 2737 bytes Desc: not available URL: From saxenaneetesh061 at rediffmail.com Wed Dec 18 14:43:21 2013 From: saxenaneetesh061 at rediffmail.com (neetesh saxena) Date: 18 Dec 2013 13:43:21 -0000 Subject: =?utf-8?B?TmVlZCBoZWxwOiByYWRpbyBpcyBub3Qgc3RhcnRlZA==?= Message-ID: <1387373729.S.4172.RU.sfs17, sfs17, 706, 930.25301.f4mail-235-148.rediffmail.com.old.1387374201.1242@webmail.rediffmail.com> Hi, I am a new user to osmocom. I am getting the following error: OsmocomBB# show ms 1 MS '1' is down, radio is not started IMEI: 000000000000000 IMEISV: 0000000000000000 IMEI generation: fixed automatic network selection state: A0 null cell selection state: C0 null radio ressource layer state: idle mobility management layer state: MM idle, PLMN search OsmocomBB# show subscriber 1 Mobile Subscriber of MS '1': IMSI: Status: U2_NOT_UPDATED IMSI detached LAI: invalid Access barred cells: no Access classes: can anyone tell me the solution what is the exact problem. I have also tried this one: "enable" -> "conf t" -> "ms 1" -> "no shutdown" and make "write" the config. Please help me. I am also using C118 phone in Germany. regards, Neetesh Get your own FREE website, FREE domain & FREE mobile app with Company email.  Know More > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas at eversberg.eu Wed Dec 18 15:56:47 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Wed, 18 Dec 2013 15:56:47 +0100 Subject: Need help: radio is not started In-Reply-To: <1387373729.S.4172.RU.sfs17, sfs17, 706, 930.25301.f4mail-235-148.rediffmail.com.old.1387374201.1242@webmail.rediffmail.com> References: <1387373729.S.4172.RU.sfs17, sfs17, 706, 930.25301.f4mail-235-148.rediffmail.com.old.1387374201.1242@webmail.rediffmail.com> Message-ID: <52B1B7AF.7000509@eversberg.eu> neetesh saxena wrote: > MS '1' is down, radio is not started hi neetesh, did you start your phone? what does "osmocon" (debugging ouput) show? does it load the layer1 binary when pressing the red button? best regards, andreas From saxenaneetesh061 at rediffmail.com Fri Dec 20 16:26:20 2013 From: saxenaneetesh061 at rediffmail.com (neetesh saxena) Date: 20 Dec 2013 15:26:20 -0000 Subject: =?utf-8?B?cHJvYmxlbSBpbiBsb2FkaW5nIGxheWVyMSBvbnRvIHBob25l?= Message-ID: <1387552849.S.4947.RU.sfs17, sfs17, 627, 111.2261.f4mail-235-235.rediffmail.com.old.1387553180.30883@webmail.rediffmail.com> Hi everyone, I am facing a new problem. When i am trying to load layer1 on to mobile phone, getting the following error:   saxena at cosec-ug-vm1-04:/opt/osmocom-bb/src/host/osmocon$ sudo -E ./osmocon -p /dev/ttyUSB0 -m c123xor ../..target/firmware/board/compal_e88/layer1.compalram.bin got 1 bytes from modem, data looks like: 2e  . got 1 bytes from modem, data looks like: c8  . got 1 bytes from modem, data looks like: 1b  . got 4 bytes from modem, data looks like: f6 02 00 41  ...A got 1 bytes from modem, data looks like: 01  . got 1 bytes from modem, data looks like: 40  @ Received PROMPT1 from phone, responding with CMD opening file: No such file or directory Next time when I am trying, it does not show anything and just hang like as: saxena at cosec-ug-vm1-04:/opt/osmocom-bb/src/host/osmocon$ sudo -E ./osmocon -p /dev/ttyUSB0 -m c123xor ../..target/firmware/board/compal_e88/layer1.compalram.bin (no display) Now, the phone is not able to switch on. I pressed red button many times but it doesn't work. can anyone tell me what is wrong in it? With regards Neetesh Saxena... Get your own FREE website, FREE domain & FREE mobile app with Company email.  Know More > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas at eversberg.eu Fri Dec 20 21:42:43 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Fri, 20 Dec 2013 21:42:43 +0100 Subject: problem in loading layer1 onto phone In-Reply-To: <1387552849.S.4947.RU.sfs17, sfs17, 627, 111.2261.f4mail-235-235.rediffmail.com.old.1387553180.30883@webmail.rediffmail.com> References: <1387552849.S.4947.RU.sfs17, sfs17, 627, 111.2261.f4mail-235-235.rediffmail.com.old.1387553180.30883@webmail.rediffmail.com> Message-ID: <52B4ABC3.8060209@eversberg.eu> neetesh saxena wrote: > saxena at cosec-ug-vm1-04:/opt/osmocom-bb/src/host/osmocon$ sudo -E > ./osmocon -p /dev/ttyUSB0 -m c123xor > ../..target/firmware/board/compal_e88/layer1.compalram.bin seems that you are missing a "/" before "target": sudo -E ./osmocon -p /dev/ttyUSB0 -m c123xor ../../target/firmware/board/compal_e88/layer1.compalram.bin -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbrewers at web.de Sun Dec 22 10:23:34 2013 From: mbrewers at web.de (osmoman13) Date: Sun, 22 Dec 2013 01:23:34 -0800 (PST) Subject: osmocom error at compiing Message-ID: <1387704213958-4026267.post@n3.nabble.com> Hello, at the compiling/installiation of osmocombb I get follow error: e checking dependency style of gcc... gcc3 ../configure: line 3786: syntax error near unexpected token pic-only' ../configure: line 3786: LT_INIT(pic-only)' make: *** [shared/libosmocore/build-target/Makefile] error 2 I made follow: $ git clone git://git.osmocom.org/osmocom-bb.git $ cd osmocom-bb $ git pull -rebase $ cd src $ make after make there are this error! I have the Ubuntu-version 12.04 LTS in a VBox von oracel (64bit) anyone an Idea? best regards -- View this message in context: http://baseband-devel.722152.n3.nabble.com/osmocom-error-at-compiing-tp4026267.html Sent from the baseband-devel mailing list archive at Nabble.com. From wtfdoing at yahoo.com Wed Dec 25 07:53:13 2013 From: wtfdoing at yahoo.com (Wdoing) Date: Tue, 24 Dec 2013 22:53:13 -0800 (PST) Subject: Cannot open serial device /dev/ttyUSB0 In-Reply-To: References: Message-ID: <1387954393473-4026268.post@n3.nabble.com> Experiencing the same problem with "cannot open serial device". LSUSB list group of USB devices, my T191 cable even has it's own name as UART ... when connected (by the way other cable looks like thin USB-jack does not appear in lsusb), but still every time getting "cannot open". What is it that I am doing wrong? -- View this message in context: http://baseband-devel.722152.n3.nabble.com/Cannot-open-serial-device-dev-ttyUSB0-tp4026053p4026268.html Sent from the baseband-devel mailing list archive at Nabble.com. From Max.Suraev at fairwaves.ru Thu Dec 26 18:34:35 2013 From: Max.Suraev at fairwaves.ru (=?UTF-8?B?4piO?=) Date: Thu, 26 Dec 2013 18:34:35 +0100 Subject: [PATCH] RFC - change GPRS cipher API In-Reply-To: <20131207172122.GC8435@nataraja.gnumonks.org> References: <52961EF6.4060107@fairwaves.ru> <20131201133501.GL3133@nataraja.gnumonks.org> <529C5C07.1060404@fairwaves.ru> <20131207172122.GC8435@nataraja.gnumonks.org> Message-ID: <52BC68AB.7060201@fairwaves.ru> 07.12.2013 18:21, Harald Welte ?????: > Hi Max, > > On Mon, Dec 02, 2013 at 11:08:07AM +0100, ? wrote: >> Speaking of which - as far as I recall it's based on sample >> implementation with license incompatible with (L)GPL. Could we just >> discontinue it once Sylvain massage my a5/3,4 gea3,4 patches into >> libosmocore? > yes, if those are a feature-complete replacement, there is no need for > the old library. > It is plus a5/4 and gea4. -- best regards, Max, http://fairwaves.ru From saxenaneetesh061 at rediffmail.com Fri Dec 27 12:59:09 2013 From: saxenaneetesh061 at rediffmail.com (neetesh saxena) Date: 27 Dec 2013 11:59:09 -0000 Subject: =?utf-8?B?R1NNIGZyZXF1ZW5jeSBiYW5kIGZvciBFdXJvcGU=?= Message-ID: <1387552849.S.4947.RU.sfs17, sfs17, 627, 111.2261.f4mail-235-235.rediffmail.com.old.forward.1388145549.23353@webmail.rediffmail.com> Hi everyone, Can anyone please tell me what is the GSM frequency band for Europe (Germany)? Do I need to enable such band before working on OsmocomBB ? I have uploaded the mobile layer1 onto phone but I am still not able to read the SIM. The message I got is ms 1 is down and radio is not started. Can someone comment on this ? With regards Neetesh -------------- next part -------------- An HTML attachment was scrubbed... URL: From Max.Suraev at fairwaves.ru Fri Dec 27 23:32:13 2013 From: Max.Suraev at fairwaves.ru (=?UTF-8?B?4piO?=) Date: Fri, 27 Dec 2013 23:32:13 +0100 Subject: [PATCH] RFC - change GPRS cipher API In-Reply-To: <20131201133501.GL3133@nataraja.gnumonks.org> References: <52961EF6.4060107@fairwaves.ru> <20131201133501.GL3133@nataraja.gnumonks.org> Message-ID: <52BDFFED.6080602@fairwaves.ru> Attached is another version of this patch - I like this more because instead of additional parameter for Kc length there is now dedicated function. When I tried to use updated API I quickly realized that we rarely need to have key length explicitly: algorithm implementations know it already for obvious reasons. Hence I think function is better than parameter. Looking forward to the LIBVERSION update. We can also merge cipher implementation a5/3 a5/4, gea3, gea4 at the same time which would use this new API. This way we would have more features to warrant such update. cheers, Max. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Update-GPRS-API-to-comply-with-ETSI-TS-155.22.patch Type: text/x-patch Size: 3361 bytes Desc: not available URL: From Max.Suraev at fairwaves.ru Fri Dec 27 23:44:48 2013 From: Max.Suraev at fairwaves.ru (=?UTF-8?B?4piO?=) Date: Fri, 27 Dec 2013 23:44:48 +0100 Subject: [PATCH] RFC - change GPRS cipher API In-Reply-To: <52BDFFED.6080602@fairwaves.ru> References: <52961EF6.4060107@fairwaves.ru> <20131201133501.GL3133@nataraja.gnumonks.org> <52BDFFED.6080602@fairwaves.ru> Message-ID: <52BE02E0.2040801@fairwaves.ru> Pardon, forgot to patch .map file. -- best regards, Max, http://fairwaves.ru -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Update-GPRS-API-to-comply-with-ETSI-TS-155.22-v2.patch Type: text/x-patch Size: 3716 bytes Desc: not available URL: From miguelrios35 at yahoo.com Sat Dec 28 13:56:11 2013 From: miguelrios35 at yahoo.com (Miguel Rios) Date: Sat, 28 Dec 2013 04:56:11 -0800 (PST) Subject: GSM frequency band for Europe In-Reply-To: <1387552849.S.4947.RU.sfs17, sfs17, 627, 111.2261.f4mail-235-235.rediffmail.com.old.forward.1388145549.23353@webmail.rediffmail.com> References: <1387552849.S.4947.RU.sfs17, sfs17, 627, 111.2261.f4mail-235-235.rediffmail.com.old.forward.1388145549.23353@webmail.rediffmail.com> Message-ID: <1388235371.59195.YahooMailNeo@web161604.mail.bf1.yahoo.com> Hi, A simple google search would give you this link where you can see what frequencies are used in which countries. http://www.worldtimezone.com/gsm.html On Friday, December 27, 2013 12:01 PM, neetesh saxena wrote: Hi everyone, Can anyone please tell me what is the GSM frequency band for Europe (Germany)? Do I need to enable such band before working on OsmocomBB ? I have uploaded the mobile layer1 onto phone but I am still not able to read the SIM. The message I got is ms 1 is down and radio is not started. Can someone comment on this ? With regards Neetesh Get your own FREE website, FREE domain & FREE mobile app with Company email. ? Know More > -------------- next part -------------- An HTML attachment was scrubbed... URL: From luca at srlabs.de Sat Dec 28 14:15:02 2013 From: luca at srlabs.de (Luca Melette) Date: Sat, 28 Dec 2013 14:15:02 +0100 Subject: GSM frequency band for Europe In-Reply-To: <3d2a7241-cd6a-41a4-aaa7-f997dc420bc6@lists.osmocom.org> References: <3d2a7241-cd6a-41a4-aaa7-f997dc420bc6@lists.osmocom.org> Message-ID: <20131228141502.012b5831@c7h5n3o6.sofago.net> Hi Neetesh, > Can anyone please tell me what is the GSM frequency band for Europe > (Germany)? GSM 900 and DCS 1800. > Do I need to enable such band before working on OsmocomBB ? In the mobile configuration (mobile.cfg) you should see these lines "p-gsm", "e-gsm", "dcs", in the support section without the "no" in front of them. > I have uploaded the mobile layer1 onto phone but I am still not able > to read the SIM. The message I got is ms 1 is down and radio is not > started. This seems to be the real problem. Your SIM is not responding to the firmware and the mobile cannot connect to any network. You can try to apply the patch created by Lukas. It was attached to the post "patches for SIM in the firmware" in list. Cheers, LM From Max.Suraev at fairwaves.ru Sat Dec 28 21:27:55 2013 From: Max.Suraev at fairwaves.ru (=?UTF-8?B?4piO?=) Date: Sat, 28 Dec 2013 21:27:55 +0100 Subject: [PATCH] Add generic LE/BE load/store uint type convertors and use them in msgb Message-ID: <52BF344B.1020001@fairwaves.ru> Attached is simple patch which adds little-endian & big-endian macro to move bytes to and from multibyte integer types like uint16_t, uint32_t etc. Some of this code is used right away in msgb.h but it will also be used in kasumi implementation later on. -- best regards, Max, http://fairwaves.ru -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-generic-LE-BE-load-store-uint-type-convertors-an.patch Type: text/x-patch Size: 10209 bytes Desc: not available URL: From Max.Suraev at fairwaves.ru Sat Dec 28 22:02:10 2013 From: Max.Suraev at fairwaves.ru (=?UTF-8?B?4piO?=) Date: Sat, 28 Dec 2013 22:02:10 +0100 Subject: [PATCH] Add generic LE/BE load/store uint type convertors and use them in msgb In-Reply-To: <52BF344B.1020001@fairwaves.ru> References: <52BF344B.1020001@fairwaves.ru> Message-ID: <52BF3C52.40207@fairwaves.ru> Improved version of 1st patch (rol16 implementation were missing) and actual kasumi implementation which uses macro from 1st patch. This is from the scratch GPL implementation, correctness verified using test vectors from 3GPP - see tests/kasumi/* -- best regards, Max, http://fairwaves.ru -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-generic-LE-BE-load-store-uint-type-convertors-an.patch Type: text/x-patch Size: 10280 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Add-Kasumi-cipher-implementation.patch Type: text/x-patch Size: 23957 bytes Desc: not available URL: From admin at lishixin.net Sun Dec 29 17:02:53 2013 From: admin at lishixin.net (warriornew) Date: Sun, 29 Dec 2013 08:02:53 -0800 (PST) Subject: what menu.e88loader.bin: No such file or directory Message-ID: <1388332973973-4026277.post@n3.nabble.com> what menu.e88loader.bin: No such file or directoryI refer to this article :http://bb.osmocom.org/trac/wiki/flashing_newBut why can't find menu.e88loader.bin??Does anyone know?thanks -- View this message in context: http://baseband-devel.722152.n3.nabble.com/what-menu-e88loader-bin-No-such-file-or-directory-tp4026277.html Sent from the baseband-devel mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From milinkoi at gmail.com Mon Dec 30 22:47:47 2013 From: milinkoi at gmail.com (Milinko Isakovic) Date: Mon, 30 Dec 2013 22:47:47 +0100 Subject: OsmoComBB Message-ID: Hello, I need some help and maybe you are able to help me. Before I made any decision I need confirm some of things I do not fully understand. First of all I have some tests to preform and to make some report: I need to receive CCCH or part of CCCH like PCH and to store results. After this results are stored I need to analyze them with following: 1) How many paging requests came from 3 different operators at one LAC (I know each of them will have separate LAC) 2) Than I need to confirm how many paging requests came calling IMSI how much with TMSI 3) If it is possible to be done on one computer with 3 devices, or I will need more computers ? Question is because I need to do some reports. I do not need to monitor or intercept any encrypted data, to monitor SMS or any call.7 My question is is this possible ? And is there anybody who can help me to do this ? I found that some TEST equipment is capable to give me this results, but it is to expensive to me. Also if there is anybody in region of Balkan who was doing something like this please contact me. Project I need to finish is to monitor some number of days with Paging requests, and to make Prediction on what way and what speed GSM network will grow . Regards Milinko Isakovic -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Tue Dec 31 15:28:05 2013 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 31 Dec 2013 15:28:05 +0100 Subject: OsmoDevCon 2014 / Date / Venue In-Reply-To: <20131130135720.GI3133@nataraja.gnumonks.org> References: <20131105155825.GK12353@nataraja.gnumonks.org> <20131130135720.GI3133@nataraja.gnumonks.org> Message-ID: <20131231142805.GM13435@nataraja.gnumonks.org> Dear all, just a quick reminder: On Sat, Nov 30, 2013 at 02:57:20PM +0100, Harald Welte wrote: > Please make sure to add your name to the list at > https://openbsc.osmocom.org/trac/wiki/OsmoDevCon2014 until December > 31st (latest). If you don't have a wiki account, ask somebody who has > one, apply for a wiki account or send an e-mail to me. so today is the last chance to indicate your intrest in attending OsmoDevCon. I'm surprised to not have seen the following names in the list: pablo, peter, nion, steve-m, dmitry, kaber. It would be great to have you around again this year. Looking forward to meeting all of you again! 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 galersekali at gmail.com Tue Dec 31 19:45:03 2013 From: galersekali at gmail.com (Anak Galer) Date: Wed, 1 Jan 2014 01:45:03 +0700 Subject: GSM frequency band for Europe In-Reply-To: <52bd6c0a.ea58c20a.30fc.ffff96ebSMTPIN_ADDED_BROKEN@mx.google.com> References: <52bd6c0a.ea58c20a.30fc.ffff96ebSMTPIN_ADDED_BROKEN@mx.google.com> Message-ID: On 12/27/13, neetesh saxena wrote: > Hi everyone, > > Can anyone please tell me what is the GSM frequency band for Europe > (Germany)? > > Do I need to enable such band before working on OsmocomBB ? > > I have uploaded the mobile layer1 onto phone but I am still not able to read > the SIM. > The message I got is ms 1 is down and radio is not started. > > Can someone comment on this ? > > > > With regards > > Neetesh > > your sim not connect to network . or maybe you can try use Blackberry engineer mode for other options http://ngerepotin.blogspot.com/2013/12/bbem-blackberry-engineer-mode.html Cheers! From kaber at trash.net Tue Dec 31 15:50:03 2013 From: kaber at trash.net (Patrick McHardy) Date: Tue, 31 Dec 2013 14:50:03 +0000 Subject: OsmoDevCon 2014 / Date / Venue In-Reply-To: <20131231142805.GM13435@nataraja.gnumonks.org> References: <20131105155825.GK12353@nataraja.gnumonks.org> <20131130135720.GI3133@nataraja.gnumonks.org> <20131231142805.GM13435@nataraja.gnumonks.org> Message-ID: <134d1fe1-302d-4782-974f-477a8762f27f@email.android.com> Hi, Sorry I didn't see the invitation before. I'm happy to come. Cheers & happy New year, Patrick Harald Welte schrieb: >Dear all, > >just a quick reminder: > >On Sat, Nov 30, 2013 at 02:57:20PM +0100, Harald Welte wrote: >> Please make sure to add your name to the list at >> https://openbsc.osmocom.org/trac/wiki/OsmoDevCon2014 until December >> 31st (latest). If you don't have a wiki account, ask somebody who >has >> one, apply for a wiki account or send an e-mail to me. > >so today is the last chance to indicate your intrest in attending >OsmoDevCon. > >I'm surprised to not have seen the following names in the list: pablo, >peter, nion, steve-m, dmitry, kaber. It would be great to have you >around again this year. > >Looking forward to meeting all of you again! > >Regards, > Harald >-- >- Harald Welte >http://laforge.gnumonks.org/ >============================================================================ >"Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. -------------- next part -------------- An HTML attachment was scrubbed... URL: