baseband-devel April 2011

baseband-devel@lists.osmocom.org

48 participants
69 discussions

Sniff Tool Development offer
by Marten Christophe 25 Apr '11

25 Apr '11

Hello List, I would like students or free time programmers to develop custom application for sniffing it should be cable for manually entries for (as option of command line) means the tool must be able to tune C131 in Mobile application mode( under full voice function) the desired parameter of user's choice 1 ARFCN 2 TS ( time slot) 3 Hoping sequence it is something we can tune C131 in full voice support to our own choice of AFRCN TS and hopping sequence we must be able to manually enter these parameter while MS is in mobile application mode( DSP in full voice support) I would like you to decide your remunerations /expanses/ development fees. http://bb.osmocom.org/trac/wiki/Sniffing Kind Regards, Maten ========== ======== Hi, Since a lot of people are asking the same questions and there seems to be a rush on the C123 on ebay I tought some clarification is needed. Short version: - The exact tools I used on stage are _not_ and will _not_ be released (or sold ... several people asked ...) - Any one willing to re-code them without any apriori knowledge of GSM would most likely need months to read/understand both the specifications and the way the code works. (That's thousands of page of GSM spec and thousands of line of code) - Osmocom-BB project is not designed to be a sniffer, it's a baseband implementation, I just used part of it as a base. So basically, unless you are really interested in GSM and are willing to dedicate time to understand it deeply and to contribute the various projects, there is not much point in you buying phones, or hanging out in the ml/irc or whatever ... For those who are still reading and interested here's a little more detail: * The HLR query step: -> Go watch the awesome 25C3 talk about it * The TMSI recovering step - Won't be published - If you know how paging works, you know what to do anyway and it's trivial. Method is in the talk, there is nothing to it. * The targeted sniffing application - Won't be published either - Some improvements to the layer23 app frame work will be done but these are generic framework stuff, not app-specific - Again, if you know how L2 works and have looked at several traces, it's obvious what to do. - The 'DSP' part of the sniffer is public for a while with a small demo app (single phone and doesn't exploit the full potential of the DSP patch) and it's perfectly sufficient to debug things on your o wn controlled network. (This is basically what I showed at Deepsec 2010). * The tool to generate the input to Kraken - Won't be published either - Making the guesses is easy for anyone that knows what he's doing. * The improved Kraken - No idea about it, see with Karsten / Sacha / Frank, I only got access to it 1 hour or so before the talk :) * Conversion from burst to audio - This was a hacked software mostly with airprobe code. - The exact app will not be released but I'd like to see the capability put in some clean library we can re-use from airprobe and other application without having to multiply the code each time. - ... But since I'd like it to support AMR and viterbi softoutput before that happens, it could take some time. - Anyone familiar with GSM, airprobe and C could re-hack the same thing in an hour ... As you can see, everything you need to analyze your own network / your own traffic, even at the burst level is already published and has been for more than a month. The other tools have been written only so that we could demonstrate that what we _say_ is possible for about year, we can now do it _practically_. It's apparently needed to get people attentions, "theoretical" attacks are not enough to get the operators / gsma to react. We'll see if that did it ... A few advices that are always good: - Make sure to checkout the a5/1 project ML and airprobe project ML and try to ask your questions in the proper mailing list as much as possible. - Check the wiki and mailing list archives toroughly before asking questions. Cheers, Sylvain Munaut PS: I only posted on this list because it seems a lot of people were pointed here while in fact airprobe would probably be more appropriate to discuss attack scenarios and such, so make sure to answer / start new discussion on the right list.

2 2

buzzer driver
by José Luis Pereira 24 Apr '11

24 Apr '11

Hi all, my name is Jose Pereira, and i'm very interested in helping you with some code! I've wrote the buzzer driver for calypso, not so sure if will help you of anything, but was just for experimenting :) Anyway, i send the patch in attachement. The interface can be simply #include <calypso/buzzer.h> buzzer_mode_pwt(1); buzzer_volume(40); buzzer_note(NOTE(NOTE_E,OCTAVE_5)); Please let me know what do you think of the code, and in what way i can further help. Best regards, -- José Pereira http://onaips.blogspot.com

2 1

Unable to dump traffic with wireshark using C139
by Benedikt Braunger 24 Apr '11

24 Apr '11

Hi, i launched following commands: 1) ./osmocon -p /dev/ttyUSB0 -m c140xor -c ../../target/firmware/board/compal_e86/layer1.highram.bin ../../target/firmware/board/compal_e86/chainload.compalram.bin http://pastebin.com/xcJTuNDF 2) ./mobile -i 127.0.0.1 http://pastebin.com/h3aPFgs1 3) telnet localhost 4247 http://pastebin.com/7nA7KbN8 mobile.cfg: http://pastebin.com/FBM6PCqq unfortunately wireshark 1.5+ devel) or tcpdump couldn't sniff any traffic on lo-interface. can anyone find a missconfiguration? any hint would be awesome! thank you :)

1 0

R: Channel sync error (problem with mobile application)
by screaming-pain＠libero.it 22 Apr '11

22 Apr '11

Hi everybody, I looked a bit more at the code and output of the mobile application, and it seems the problem is that the connection is always dropped because of channel sync failure. Sylvain suggested (to someone having a similar problem) to use the stick option, and actually after trying this, I observed a different behavior it seems the phone performed the identification and the authentication procedures and during a different trial the location update was performed. Can someone explain the stick option? Anyway, I still can't receive or make calls this is what usally happens when trying to make a call <0007> mnccms.c:534 Make call to 150 <0007> mnccms.c:150 support TCH/H also <0007> mnccms.c:174 support full rate v2 <0007> mnccms.c:178 support full rate v1 <0007> mnccms.c:187 support half rate v1 <0005> gsm48_cc.c:496 Sending MMCC_EST_REQ <0004> gsm48_mm.c:3568 (ms 1) Received 'MMCC_EST_REQ' event in state MM idle <0004> gsm48_mm.c:3571 -> substate normal service <0004> gsm48_mm.c:3573 -> callref 8, transaction_id 255 <0004> gsm48_mm.c:2873 Init MM Connection. <0004> gsm48_mm.c:1332 New MM Connection (proto 0x03 trans_id 255 ref 8) <0004> gsm48_mm.c:1291 (ref 8) new state IDLE -> CONN_PEND <0004> gsm48_mm.c:2650 CM SERVICE REQUEST (cause 9) <0004> gsm48_mm.c:2685 -> Using IMSI 234------------- <0001> gsm48_rr.c:4911 (ms 1) Message 'RR_EST_REQ' received in state idle <0001> gsm48_rr.c:4271 Not camping normally, rejecting! (cs->state = 7) <000d> gsm48_rr.c:4241 Establishing radio link not possible <0004> gsm48_mm.c:887 new state MM IDLE, normal service -> wait for RR connection (MM connection) <0004> gsm48_mm.c:3695 (ms 1) Received 'RR_REL_IND' from RR in state wait for RR connection (MM connection) <0004> gsm48_mm.c:1367 Release any MM Connection <0004> gsm48_mm.c:1348 Freeing MM Connection <0004> gsm48_mm.c:1291 (ref 8) new state CONN_PEND -> IDLE <0004> gsm48_mm.c:1055 We are in registered LAI as returning to MM IDLE <0004> gsm48_mm.c:892 new state wait for RR connection (MM connection) -> MM IDLE, normal service <0005> gsm48_cc.c:2122 (ms 1) Received 'MMCC_ERR_IND' in CC state MM_CONNECTION_PEND <0005> gsm48_cc.c:189 (ms 1 ti ff) Sending 'MNCC_REL_IND' to MNCC. <0007> mnccms.c:336 Call has been released (cause 21) Can someone help me with this? I do not understand why is not possible to establish the radio link, and does anyone know where I can find out what 'cause 21' means? Thanks, loretta

1 0

Re: eres de Spain?
by Manuel Borrego 20 Apr '11

20 Apr '11

Sip! Que tal? Pebsaba contactar con los españoles de la lista, pero no he tenido tiempo :P Enviado desde mi iPhone El 18/04/2011, a las 06:55, "Pedro Collado" <edrocoyote(a)yahoo.es> escribió: > por el nombre > >

1 0

Re: RFC: RTOS for Calypso
by Marius Cirsta 19 Apr '11

19 Apr '11

Sorry about that , darn gmail..... Yes , nuttx seems pretty OK and it's author is very nice , a man to work with. The problem would be that it's written by just one man and I don't even know how it's doing on the GUI side. Nuttx though seems more oriented towards micro controllers and and targets with less resources. As for nano-x it's one of the lightest GUIs around and I don't know if there really are any better options for embedded open source graphics. It's not really an X11 , not a full one anyway. And from what I've heard you can get it to about 100 K which is certainly something in my opinion. On Tue, Apr 19, 2011 at 9:00 PM, Marius Cirsta <mforce2(a)gmail.com> wrote: > Yes , nuttx seems pretty OK and it's author is very nice , a man to > work with. The problem would be that it's written by just one man and > I don't even know how it's doing on the GUI side. > Nuttx though seems more oriented towards micro controllers and and > targets with less resources. > > As for nano-x it's one of the lightest GUIs around and I don't know if > there really are any better options for embedded open source graphics. > It's not really an X11 , not a full one anyway. And from what I've > heard you can get it to about 100 K which is certainly something in my > opinion. > > On Tue, Apr 19, 2011 at 5:59 PM, Alan Carvalho de Assis > <acassis(a)gmail.com> wrote: >> Hi Harald, >> >> On 4/18/11, Harald Welte <laforge(a)gnumonks.org> wrote: >>> >>> I have never found the time to actually make that decision/selection, >>> so there is no status update. >>> >>> I'd still like to have a say in the decision, but I'm welcome for the >>> discussion that has started right now and definitely like to look at >>> the proposals (like ethernut OS) >>> >> >> I think we could consider NuttX as well: >> >> http://nuttx.sourceforge.net >> >> This RTOS implements POSIX APIs and have many features "inherited" from Linux. >> It is completely reconfigurable to fit small foot-print microcontrollers. >> >> Just my 2 cents, I hope someone enjoy it. >> >> Best Regards, >> >> Alan >> >> >

1 0

t191 + c139
by labad jala 19 Apr '11

19 Apr '11

Thanks for your answers. I assume that the 0.2v instead of the 3.3v at the jack shouldn't fry my GSM, just wanted to know if someone had the same "issue". Best regards.

1 0

Re: Osmocom on Neo Freerunner can't finish loading / Solved (?)
by Dave Schmidt 19 Apr '11

19 Apr '11

Hello everyone, > From: Dave Schmidt > Sent: 04/18/11 04:09 PM [...] > Preparing block 45, block checksum is 0x97 > handle_write_block(): 1024 bytes (1024/1024) > handle_write_block(): Block 45 finished > > ...and it stalls at this point. After re-flashing of the phone, osmocom loads again. So this should be considered as "closed". Sorry for a false alarm. D.

1 0

HW advise
by labad jala 19 Apr '11

19 Apr '11

Hello and sorry to bother you for such little issue: I finally received the t191 cable and connected it to my rs232/usb converter. I only get 0.2v out at the 2,5mm jack, is this voltage workable, does someone faced the same ?... By the way, my Moto c139 is SIM locked, is this also a problem ? Thanks for any advices.

3 2

Osmocom on Neo Freerunner can't finish loading
by Dave Schmidt 18 Apr '11

18 Apr '11

Hello everyone, I have compiled osmocon binary for Neo Freerunner (after receiving explanations from the list - thanks Alex!). It worked... during some time. Now the loading does not finish: # ./osmocon -i 13 -m romload -p /dev/ttySAC0 layer1.highram.bin Sending Calypso romloader beacon... Sending Calypso romloader beacon... ... Received parameter ack from phone, starting download ... Preparing block 44, block checksum is 0x8c handle_write_block(): 1024 bytes (1024/1024) handle_write_block(): Block 44 finished Received block ack from phone Preparing block 45, block checksum is 0x97 handle_write_block(): 1024 bytes (1024/1024) handle_write_block(): Block 45 finished ...and it stalls at this point. Altogether, there were 47 blocks, if I remember right (so the feeling is that "I'm so close to it" :-))). The phone is otherwise accessible (via ssh). Any highlights on what could go wrong? I can't remember having "done" anything at all to the phone... Dave.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel April 2011