Hello! I Need Help
I install these three programs OpenBTS, OsmocomBB, Asterisk
Then run them, Everything works well
OpenBTS sent an SMS to my phones
I answered and he checked me
I registered into OpenBTS a second phone
I tried to transfer SMS between phones - all good
but when I try to call from one to another I did not get
Asterisk writes
================================================================
*CLI> Retransmission timeout reached on transmission 755803415(a)127.0.0.1 for
seqno 179 (Critical Response) -- See
wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
Packet timed out after 32001ms with no response
================================================================
Why?
What do I do?
--
View this message in context: http://baseband-devel.722152.n3.nabble.com/OpenBTS-OsmocomBB-Asterisk-tp402…
Sent from the baseband-devel mailing list archive at Nabble.com.
Hey there, I bumped into this error when testing gprsdecode from srldabs.de When I try the sample .dat files provided from srlabs.de it works fine though. Any hints?
Kind Regards
George AndguladzeSenior Software EngineerBusiness Management Technology
www.bmt.ge
Hey, I finally watched Nico's talk "let me answer that for you" and heard him say he ported layer2/3 to target.
Also found a mailing list message about him cleaning it up and putting it up on git and sending it to a few folks.
Did that code ever get shared? Would be cool to play around with and is certainly something I would eventually want to accomplish for my project of making a phone that works by itself.
-Craig
Dear all, I vae the C115 with a T1 USB to Serial cable with the Prolific
chipset.
When i run osmocon i get :- an its just sits there with no further
processing.
./osmocon -p /dev/ttyUSB0 -m c123xor
../../target/firmware/board/compal_e88/loader.compalram.bin
read_file(../../target/firmware/board/compal_e88/loader.compalram.bin):
file_size=17120, hdr_len=4, dnload_len=17127
read_file(../../target/firmware/board/compal_e88/loader.compalram.bin):
file_size=17120, hdr_len=4, dnload_len=17127
got 1 bytes from modem, data looks like: 00 .
got 2 bytes from modem, data looks like: 2f 00 /.
got 1 bytes from modem, data looks like: 1b .
got 3 bytes from modem, data looks like: f6 02 00 ...
got 1 bytes from modem, data looks like: 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
got 1 bytes from modem, data looks like: 66 f
got 1 bytes from modem, data looks like: 74 t
got 1 bytes from modem, data looks like: 6d m
got 1 bytes from modem, data looks like: 74 t
got 1 bytes from modem, data looks like: 6f o
got 1 bytes from modem, data looks like: 6f o
got 1 bytes from modem, data looks like: 6c l
Received FTMTOOL from phone, ramloader has aborted
got 1 bytes from modem, data looks like: 65 e
got 1 bytes from modem, data looks like: 72 r
got 1 bytes from modem, data looks like: 72 r
got 1 bytes from modem, data looks like: 6f o
got 1 bytes from modem, data looks like: 72 r
got 1 bytes from modem, data looks like: 00 .
got 1 bytes from modem, data looks like: 00 .
I think the cable is ok as when i run my fingers on the tip i get random
Zeros so it appears to be talking to the cable.
Also when i tried to run Mobile i get the :- even though i created the
Mobile.cfg file in /etc/osmoco
Failed to parse the config file: '/home/raz/.osmocom/bb/mobile.cfg'
Please check or create config file using: 'touch
/home/raz/.osmocom/bb/mobile.cfg'
I have spent some hours researching the lists and trying various things to
no avail but I want to continue until I resolve this issues and use this
great stack to learn about the GSM network.
Please advise.
Great full for any help or pointers but this maybe a timing issue that is
difficult to debug.
Thanks
Raz
hi,
i did a lot of resarch and testing on cell selection and re-selection
process the last two week.
the cell selection process, network selection process (manual and
automatic) and mobility management process were already implemented in
OsmocomBB a long time, but turned out to be buggy and incomplete. i made
test drives to check the process and debugged it.
the re-selection process is new. it is used to track surrounding cells
while listening to the BCCH of the current cell (camping on a cell).
special extension to the layer1 firmare is used to measure neighbour
cells. if an neighbour cell becomes 'better', the mobile switches to
that cell, depening on different criteria. now it is possible to move
with OsmocomBB.
the re-selection process is not handover! handover is a process where a
phone switches between cells while doing a call. handover is one next
step to implement. the process is a little more complex, because it
requires not only neighbour cell measurements, but also syncing to them
without interrupting the traffic channel. most layer 3 stuff of handover
is already implemented.
if you like to play and test your moving OsmocomBB, you can check out
the "jolly/roaming" branch. it contains the extension to layer1, as well
as sim reader and fixes from "sylvain/testing" branch. use both "mobile"
and "layer1" firmware from this branch.
in order to see some process at VTY, you can do:
enable
monitor network 1 (continously display the strongest cell and neighbour
cells)
show ms 1 (to see current states)
show neighbour-cells 1 (to see a more detailed current list of
neighbours)
andreas
Hi,
in the osmocom bb mobile.cfg I don't see any posibility to set a fixed
Kc encryption key and the tmsi.
How could I achieve that osmocom uses my defined Kc and tmsi?
cheers,
Simian
FWIW, someone asked me whether c113 worked. I found a cheap 113a and hello_world loaded pretty well. The screen on my phone is shot but the backlight did come on.it works fine with the following command:
craig@craig:~/c115-osmocom-bb/src$ host/osmocon/osmocon -p /dev/ttyUSB0 -m c123xor target/firmware/board/compal_e88/hello_world.compalram.bin
OsmocomBB Hello World (revision osmocon_v0.0.0-1754-gfc20a37)
======================================================================
Device ID code: 0xb4fb
Device Version code: 0x0000
ARM ID code: 0xfff3
cDSP ID code: 0x0128
Die ID code: c5c63637a5039778
======================================================================
REG_DPLL=0x2413
CNTL_ARM_CLK=0xf0a1
CNTL_CLK=0xff91
CNTL_RST=0xfff3
CNTL_ARM_DIV=0xfff9
======================================================================
REG_DPLL=0x2413
CNTL_ARM_CLK=0xf0a1
CNTL_CLK=0xff91
CNTL_RST=0xfff3
CNTL_ARM_DIV=0xfff9
======================================================================
entering interrupt loop
Hello,
The sim driver was not working with my sim card.
After some successful apdu requests, it was ceasing to work.
It turned out that the sim is sending waiting chars before some rx acks.
The following patch solved the problem.
diff --git a/src/target/firmware/calypso/sim.c
b/src/target/firmware/calypso/sim.c
index 752628f..b35909f 100644
--- a/src/target/firmware/calypso/sim.c
+++ b/src/target/firmware/calypso/sim.c
@@ -536,6 +536,8 @@ void sim_handler(void)
/* Case 2: No input / Output of known length */
if (mode == SIM_APDU_PUT) {
sim_state = SIM_STATE_RX_ACK;
+ /* ignore waiting char here*/
+ sim_ignore_waiting_char = 1;
calypso_sim_receive(response, 1);
break;
/* Case 4: Input / No output */
@@ -563,6 +565,8 @@ void sim_handler(void)
break; /* wait until data is received */
/* Disable all interrupt driven functions */
writew(0xFF, REG_SIM_MASKIT);
+ /*stop ignoring waiting char*/
+ sim_ignore_waiting_char = 0;
/* error received */
if (sim_rx_character_count == 2) {
puts("SIM: command failed\n");
Regards,
Etienne
--
View this message in context: http://baseband-devel.722152.n3.nabble.com/patch-sim-c-waiting-char-issue-t…
Sent from the baseband-devel mailing list archive at Nabble.com.
OsmocomBB could be used for many things, one example is demonstrating GSM’s insecurity, but the research and work to do that was done by people who were interested in the topic and did this on their own. Of course the creators of the project are not trying to limit anyone to do anything with OsmocomBB, that’s the main idea behind free and open source, however the project’s main aim is still to provide a framework, which one can use to do different things with GSM easily (not necessarily security related stuff!). So that’s why I told you not to expect much help (especially specific help or instructions) about sniffing with osmocomBB.
> 2015. júl. 19. dátummal, 13:16 időpontban g0tcha <g0tcha(a)3gp.za.net> írta:
>
> Hi
>
> Thanks for the info, although I find it strange that you say I won’t get far with sniffing questions here. When most of the talk and information presented on using osmocombb were only about interception , locating to demonstrate the insecurities about GSM.
>
> But thanks for clarifying
>
> From: Tomcsányi Domonkos <domi(a)tomcsanyi.net <mailto:domi@tomcsanyi.net>>
> Date: Sunday 19 July 2015 at 13:09
> To: "." <g0tcha(a)3gp.za.net <mailto:g0tcha@3gp.za.net>>
> Subject: Re: osmocommBB and USRP2
>
> USRP is not capable of hopping for example.
> OsmocomBB’s main goal is not to do sniffing, so I don’t think you will get far with these questions here.
> Also you can easily find out about the neighbor cells with a USRP.
>
> Regards,
> Domi
>
>> 2015. júl. 19. dátummal, 12:26 időpontban g0tcha <g0tcha(a)3gp.za.net <mailto:g0tcha@3gp.za.net>> írta:
>>
>> Thanks of rthe response
>>
>> But can you clarify what is the difference between the 2 ? My impression was that the USRP2 can do all the osmocomBB can do and more.
>>
>> Are you saying that the osmocomBB firmware can do a lot more ?
>>
>> I am reffering to the sniffing capabilities, I know that detecting neighbouring cells etc can’t be done with USRP2 I usually use a nokia 3310 with netmonitor.
>>
>> Any clarity appreciated
>>
>> From: Tomcsányi, Domonkos <domi(a)tomcsanyi.net <mailto:domi@tomcsanyi.net>>
>> Date: Sunday 19 July 2015 at 12:11
>> To: "baseband-devel(a)lists.osmocom.org <mailto:baseband-devel@lists.osmocom.org>" <baseband-devel(a)lists.osmocom.org <mailto:baseband-devel@lists.osmocom.org>>
>> Subject: Re: osmocommBB and USRP2
>>
>> No.
>>
>>
>> 2015. júl. 19. dátummal, 12:02 időpontban g0tcha írta:
>>
>> > Hi
>> >
>> > Just to clarify and understand the osmocomBB is only a cheaper alternative to the USRP2 , currently the USRP2 can do all the osmocomBB with all its DSP patches etc etc can do?
>> >
>> > regards
>
Hi
Just to clarify and understand the osmocomBB is only a cheaper alternative
to the USRP2 , currently the USRP2 can do all the osmocomBB with all its DSP
patches etc etc can do?
regards
Hi everyone,
First of all congratulations for the community's work, i've seen Talks about gsm/osmocom/Core network (Karsten, Harald, Sylvain, Tobias). It's impressive.
I'm pretty new in the GSM world.
I would like to practice tests concerning the obtention of LAC,CID (1/ of the phone using osmocombb, 2/on regular phone in same area of the osmo-bb phone 3/on a phone somewhere)
According to the talks this can be achieved using MAP/SCCP and core network access, but i dont really want to mess with this.
Can O-bb helps me to retrieve this LAC,CID informations in these three situations? (for the first case, i'm sure it can.)
According to gsm protocol stack ( http://www.rfwireless-world.com/images/gsm-protocol-stack.jpg ) we can see that the BSC is able to talk with MSC using BSS MAP/SCCP does that mean that i actually need to use openbsc on a phone
and osmoBB on another phone to achieve my tests?
For all of this, will i find a good starting code in sylvain/burst_ind branch? will i need non standard baud-rates serial cable? (You guessed it right, i still not have ordered my serial cables).
What i've done so far is getting E88 device and compiled the core libs and bb.(i really start)
I know my questions are pretty noob compared to all other messages in this list, please accept my apologies if i'm posting in the wrong list.
Thank you in advance.
Jean.
---
(Playmobile, en avant les histoires)
I am making progress getting nuttx running from flash on the C139 but I suspect I might be running into an issue where when code is trying to store a value into flash memory where nuttx code and data are that nuttx seems to stall/halt, maybe an exception vector is being jumped to by the CPU but nuttx isn't quite setup to handle it just yet.
Am I right that I would need to unlock flash in order to write even just one byte/word?
I tried doing the same sequence of writes that are in cfi_flash.c flash_block_unlock() but that seemed to stall as well... maybe I need to do some initialization of some sort? I may try to port over cfi_flash.c|h into nuttx.
nuttx is loaded into two pages: 0x10000 and 0x20000
I copied the macros for writew and __arch_putw and didwritew(0x60,0x0); // CFI_CMD_PROTECTwritew(0xD0,0x10000); // CFI_PROT_UNLOCKwritew(0xff,0x0); // CFI_CMD_RESETwritew(0x60,0x0); // CFI_CMD_PROTECTwritew(0xD0,0x20000); // CFI_PROT_UNLOCKwritew(0xff,0x0); // CFI_CMD_RESET
Seemed to halt at the first write.
Thanks for any hints, at this point I'm just hacking to try and get things working.
-Craig
Hi.
Anyone else experienced this with latest libosmocore from git?
./testsuite.at:124: $abs_top_builddir/tests/gb/gprs_bssgp_test
stderr:
MESSAGE to 0x7f0000ff, msg length 12
02 00 81 01 01 82 0b 56 04 82 0b 55
All NS-VCs for NSEI 2901 are either dead or blocked!
All NS-VCs for NSEI 2901 are either dead or blocked!
BSSGP BVCI=0 Rx BVC STATUS, cause=Protocol error - unspecified
BSSGP BVCI=1234 Rx BVC STATUS, cause=Unknown BVCI
NSEI=2901/BVCI=2989 Cannot handle PDU type 34 for unknown BVCI, NS BVCI 2989
Unable to resolve NSEI 4660 to NS-VC!
Assert failed rc >= 0 gb/gprs_bssgp_test.c:229
/home/user/source/libosmocore/tests/testsuite.dir/at-groups/19/test-source: line 25:
8497 Aborted (core dumped) $abs_top_builddir/tests/gb/gprs_
bssgp_test
--
best regards,
Max, http://fairwaves.co
