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
