baseband-devel January 2013

baseband-devel@lists.osmocom.org

40 participants
71 discussions

[PATCH] Fix: Correctly handle return value of msgb_pull()
by Andreas Eversberg 05 Jan '13

05 Jan '13

Now it is possible to use osmoload again to flash. Flashing was successfully tested with c123 and c155. --- src/host/osmocon/osmoload.c | 2 +- src/target/firmware/apps/loader/main.c | 7 +++++-- src/target/firmware/apps/loader_mtk/main.c | 4 ++-- 3 files changed, 8 insertions(+), 5 deletions(-) diff --git a/src/host/osmocon/osmoload.c b/src/host/osmocon/osmoload.c index 9b64935..e83f98a 100644 --- a/src/host/osmocon/osmoload.c +++ b/src/host/osmocon/osmoload.c @@ -307,7 +307,7 @@ loader_handle_reply(struct msgb *msg) { length = msgb_pull_u8(msg); crc = msgb_pull_u16(msg); address = msgb_pull_u32(msg); - data = msgb_pull(msg, length); + data = msgb_pull(msg, length) - length; break; case LOADER_MEM_WRITE: length = msgb_pull_u8(msg); diff --git a/src/target/firmware/apps/loader/main.c b/src/target/firmware/apps/loader/main.c index 50a39dd..fd07d0f 100644 --- a/src/target/firmware/apps/loader/main.c +++ b/src/target/firmware/apps/loader/main.c @@ -273,7 +273,7 @@ static void cmd_handler(uint8_t dlci, struct msgb *msg) crc = msgb_pull_u16(msg); address = msgb_pull_u32(msg); - data = msgb_pull(msg, nbytes); + data = msgb_pull(msg, nbytes) - nbytes; mycrc = osmo_crc16(0, data, nbytes); @@ -391,7 +391,7 @@ static void cmd_handler(uint8_t dlci, struct msgb *msg) chip = msgb_pull_u8(msg); address = msgb_pull_u32(msg); - data = msgb_pull(msg, nbytes); + data = msgb_pull(msg, nbytes) - nbytes; mycrc = osmo_crc16(0, data, nbytes); @@ -439,6 +439,9 @@ static void key_handler(enum key_codes code, enum key_states state) puts("Resetting due to keypress.\n"); device_reset(); break; + case KEY_MENU: + device_jump((void *)0x10000); + break; default: break; } diff --git a/src/target/firmware/apps/loader_mtk/main.c b/src/target/firmware/apps/loader_mtk/main.c index 7748dc4..3a12d27 100644 --- a/src/target/firmware/apps/loader_mtk/main.c +++ b/src/target/firmware/apps/loader_mtk/main.c @@ -213,7 +213,7 @@ static void cmd_handler(uint8_t dlci, struct msgb *msg) crc = msgb_pull_u16(msg); address = msgb_pull_u32(msg); - data = msgb_pull(msg, nbytes); + data = msgb_pull(msg, nbytes) - nbytes; mycrc = osmo_crc16(0, data, nbytes); @@ -331,7 +331,7 @@ static void cmd_handler(uint8_t dlci, struct msgb *msg) chip = msgb_pull_u8(msg); address = msgb_pull_u32(msg); - data = msgb_pull(msg, nbytes); + data = msgb_pull(msg, nbytes) - nbytes; mycrc = osmo_crc16(0, data, nbytes); -- 1.7.3.4 --------------060605070405050509030107 Content-Type: text/plain; name="0001-Generate-Compal-E99-binaries-for-loader-and-flash-lo.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="0001-Generate-Compal-E99-binaries-for-loader-and-flash-lo.pa"; filename*1="tch"

1 0

baseband-devel unsubscribe notification
by mailman-bounces＠lists.osmocom.org 05 Jan '13

05 Jan '13

osmocom(a)slewe.com has been removed from baseband-devel.

1 0

OsmoDevCon 2013 brainstorming
by Harald Welte 04 Jan '13

04 Jan '13

Hi all, as the year 2012 has already ended or will soon end depending on your timezone, it might be a good occasion to start thinking of an OsmoDevCon 2013. I personally percevied OsmoDevCon 2012 as a big success, and it was fun to bring everyone together. Generally, I prefer to keep the spirit of an invitation-only developer+contributor-only event of those involved in Osmocom. At the same time, I would consider it a good idea to add a one day user-conference to the schedule, where we try to get interested users up to speed with the various projects, possibly including some workshops and the like. So schedule-wise, I would suggest something like: * one day user conference * two day developer/contributor event * optionally: 1-2 "hacking days". The concept of "hacking days" has proven to be quite useful for the netfilter project in the past (Pablo and I can acknowledge to that fact). I'm not sure how many people would be able to spend even more days of their schedule, but even if it's a much smaller group it would still be useful, IMHO. I'd like you to 1) provide feedback on the ideas about the one-day user event and the hacking days 2) consider whether late march (like 2012) would be a good schedule again 3) what we can improve from the last event In terms of improvements, I so far have noted down: * larger venue needs to be found * complaints about the venue not having sufficient heating Venue-wise, I would again suggest to hold it in Berlin, as it's reasonbly well connected, has lots of low-cost flights to it, accomodation is not too expensive and holger/me/sysmocom can take care of local organization related activities. Hoewver, if somebody has a strong opinion against berlin _and_ is willing to organize it, I'm not completely against another venue. Regards and happy new year, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

4 7

linking sdr trx with osmo-bts/openbsc
by jolly 03 Jan '13

03 Jan '13

hi thomas, i saw your work for your master of science. i must say: congratulations! it really brings both openbts and openbsc projects together. it allows to use both sdr and real bts together in one network. as shown at the chaos communication congress (29c3), sylvain presented a compal phone with firmware to turn it into a trx for openbts. with your code, it is possible to use it with openbsc. this is something i aimed at too. i like to know if your work is (only) a proof of concept or something that could be used in a productive environment. i would help to review the changes to osmo-bts and help to get them merged to the current master branch. iirc, there are just some fixes and minor issues to solve. i already had planed a similar approach: but instead of using source from openbts, i wanted to do scheduling and coding/fec inside osmo-bts. code from libosmocore could be used for that. instead of using the device to the femto-dsp as an interface, i wanted to add the trx manager's udp interface to osmo-bts code. this way it would not require an additional process to run a trx with osmo-bts. special things regarding to the trx could be configured with the osmo-bts' config. as some guys at the 29c3 might have noticed, i was a little shocked when i read about your work. i was highly motivated to do a work that i found it was already done, so my motivation dropped to zero. i would like to apologize for my bad mood at the congress. best regards, andreas

2 1

[PATCH] Custom range in cell_log
by Dario Lombardo 02 Jan '13

02 Jan '13

Hi guys Please find attached a patch to cell_log that allows a user to specify a custom frequency range instead of the standard one. In the past I've done the same job changing the code by hand and recompiling, but a command line switch is more feasible. This is useful when one wants to monitor a subset of arfcns (like in GSM900) or even a single one. Any comment appreciated. Dario.

2 3

[PATCH] l23 sysinfo: defer SI4 CBCH mobile allocation until SI1 is received
by Alex Badea 02 Jan '13

02 Jan '13

When parsing SI4, there's a check and a log message saying that CBCH MA is ignored until SI1 is received. Then the MA is decoded anyway -- incorrectly -- such that it remains incorrect even after receiving the next SI1. Fix that with an "else". Signed-off-by: Alex Badea <vamposdecampos(a)gmail.com> --- src/host/layer23/src/common/sysinfo.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/host/layer23/src/common/sysinfo.c b/src/host/layer23/src/common/sysinfo.c index 2816c26..b42bd65 100644 --- a/src/host/layer23/src/common/sysinfo.c +++ b/src/host/layer23/src/common/sysinfo.c @@ -753,6 +753,7 @@ short_read: LOGP(DRR, LOGL_NOTICE, "Ignoring CBCH allocation of " "SYSTEM INFORMATION 4 until SI 1 is " "received.\n"); + } else { gsm48_decode_mobile_alloc(s->freq, data + 2, data[1], s->hopping, &s->hopp_len, 1); } -- 1.7.0.4

2 1

Potential bug / problematic code in gsm411_rx_rl_data()
by Bhaskar11 02 Jan '13

02 Jan '13

In gsm411_sms.c the function gsm411_rx_rl_data receives "struct gsm48_hdr *gh" as input then in very first line typecasts the pointer to "struct gsm411_rp_hdr *rp_data" to access its "data" field. struct gsm411_rp_hdr *rp_data = (struct gsm411_rp_hdr*)&gh->data; But the two header structures have their "data" fields offset by one byte as in: struct gsm411_rp_hdr { > uint8_t len; > uint8_t msg_type; > uint8_t msg_ref; > uint8_t data[0]; > } __attribute__ ((packed)); > > struct gsm48_hdr { > uint8_t proto_discr; > uint8_t msg_type; > uint8_t data[0]; > } __attribute__((packed)); Obviously this displacement has been compensated for elsewhere in the code as the application works. But this seems to be inadvertent. And if it is deliberate, it is risky programming practice and could create problems later on. Request you to correct and update suitably. Thanks. B.

2 1

Re: 29c3 youtube video
by Luca Bongiorni 02 Jan '13

02 Jan '13

I perfectly understand and agree about being reluctant to publish code that could be used for malicious purposes. I was talking more about what Harald suggested: a public/private git repo related with Layers implementation into the MS. Cheers, Luca > Currently there is no commercial activity going on. and tool mostly contain testing tools like Multiple IMSI Detach .Identity impersonation , channel hijacking like one presented in this 29C3. Channel DOS. more issue is if we publish such tools we might get in trouble from Government and also from telecom Operator for creating such tools. for same purpose we didnt published those tools. its more like publishing complete sniffing app for GSM with all codec support. > > currently we shall publish l1 l2 l3 app on target code soon when code cleaning will be completed. but dont get time as code is having multiple changes and uses library from different osmocom git hosted locally. > > > about publishing tools and research papers we shall do it after total research is complete. > > and reason that its taking too much time is am single person who can do technical work and coding rest team is more on core telecom network security. > > thats major issue in completing research . > > > On Wed, Jan 2, 2013 at 10:07 AM, <luca.bongiorni1(a)studenti.unimi.it> wrote: > So, if I may ask, since you are NOT having anykind of commercial activity related with osmocom's tools and is more than one year that you are asking for technical explanations over this ml/irc... Why u didn't publish yet the sources/results of your researches into a public repo as Harald suggested? > > Cheers, > Luca > Sent from my Fuffaphone® > From: Akib Sayyed <akibsayyed(a)gmail.com> > Sender: baseband-devel-bounces(a)lists.osmocom.org > Date: Wed, 02 Jan 2013 08:36:46 +0300 > To: Luca Bongiorni<luca.bongiorni1(a)studenti.unimi.it> > Cc: <baseband-devel(a)lists.osmocom.org>; Harald Welte<laforge(a)gnumonks.org> > Subject: Re: 29c3 youtube video > > Damn typo mistake > On Jan 2, 2013 8:35 AM, "Akib Sayyed" <akibsayyed(a)gmail.com> wrote: > > > > Currently we are not in production stage. > > We are more focused on buying own stack or buying chipset with compatible stack as there is no gprs/edge/3g suppprt in osmocom. > > Our first tool was based on osmocom but we are not in production. > > > > On Jan 2, 2013 12:12 AM, "Luca Bongiorni" <luca.bongiorni1(a)studenti.unimi.it> wrote: > >> > >> Hey all, > >> actually is "interesting" his web site. > >> > >> Since it seems a commercial website*: > >> > >> * " Matrix Shell developed own GSM penetration testing tool.This tool is comprised of hardware unit and a laptop.it can perform various test on network using custom firmware. > >> Using this too tester can identify state in which end user is getting service in terms of security." > >> > >> * "We provide following services. > >> GSM Network Penetration Testing > >> Matrixshell have developed a tool that can be used for testing attack vectors from users point of view. That is attacks that can be carried out by using modified handsets which may cause misusing identity of GSM subscriber , mass cellphone cell phone switch off ,denial of service of subscriber etc. Such vulnerability may cause loss in reputation of provider. > >> We can find out such issues using our own tools. Our tools comprised of UM interface hardware and a laptop communicating with UM interface. This tool can run different tests on network like: Checking encryption type, Authentication bypass, Wrong way of TMSI assignment by network, Identity impersonating." > >> > >> I am wondering how his software tools are dealing with Osmocom's licenses. > >> > >> Cheers, > >> Luca > >> > >> > are you sharing your current progress in a public git repository? If > >> > not, I'd like to strongly encourage you to do so. I can also give you > >> > commit access so you can push to a private branch on git.osmocom.org, if you > >> > prefer that. > >> > > >> > -- > >> > - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ > >> > ============================================================================ > >> > "Privacy in residential applications is a desirable marketing option." > >> > (ETSI EN 300 175-7 Ch. A6) > >> > > >> > >> > > > > -- > Akib Sayyed > Matrix-Shell > akibsayyed(a)gmail.com > akibsayyed(a)matrixshell.com > Mob:- +91-966-514-2243 >

1 0

29c3 youtube video
by Vic Delorge 02 Jan '13

02 Jan '13

this is the 29c3 talk about GSM DOS and SMS sniffing . awesome work osmocom team. layer 1,2,3 now runs all on the phone :) http://youtu.be/a1iZV2nl28A

6 10

Filter replacement
by Clemens Gruber 01 Jan '13

01 Jan '13

Hi, yesterday I fucked up the second C123 while trying to replace the filters, so I decided to buy one model from Sysmocom (with the filters already replaced), but due to too many orders they do not offer this service anymore. Is somebody on this list able and willing to sell me one C123 with the filter kit already built in (and tested)? I'd really appreciate if someone, who is more experienced in SMD soldering than me, could help me out. If so, please contact me at: clemensgru(a)gmail.com I live in Austria, so delivery from Europe should not be a problem. Thanks. Clemens

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel January 2013