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
Hi all,
*I connected, sent and made call successful with osmocombb (with real IMSI
and IMEI).
But, now, I get error, always be rejected:*
OsmocomBB# show ms
MS '1' is up, service is limited
IMEI: 357337016773249
IMEISV: 3573370167732490
IMEI generation: fixed
automatic network selection state: A0 null
cell selection state: PLMN search
radio ressource layer state: idle
mobility management layer state: MM idle, PLMN search
OsmocomBB#
% (MS 1)
% Trying to registering with network...
*in my config file (/root/.osmocom/bb/mobile.cfg)**:*
!
! OsmocomBB () configuration saved from vty
!!
!
line vty
no login
!
gps device /dev/ttyACM0
gps baudrate default
no gps enable
!
no hide-default
!
ms 1
layer2-socket /tmp/osmocom_l2
sap-socket /tmp/osmocom_sap
sim reader
network-selection-mode auto
imei 357337016773249 0
imei-fixed
emergency-imsi 452040399998391
sms-service-center +84980200030
no call-waiting
no auto-answer
no force-rekey
no clip
no clir
tx-power auto
no simulated-delay
no stick
location-updating
neighbour-measurement
codec full-speed prefer
codec half-speed
no abbrev
support
sms
a5/1
a5/2
p-gsm
e-gsm
r-gsm
gsm-850
dcs
pcs
class-900 4
class-850 4
class-dcs 1
class-pcs 1
channel-capability sdcch+tchf+tchh
full-speech-v1
full-speech-v2
half-speech-v1
min-rxlev -106
dsc-max 90
no skip-max-per-band
exit
test-sim
imsi 001010000000000
ki xor 00 00 00 00 00 00 00 00 00 00 00 00
no barred-access
no rplmn
hplmn-search foreign-country
exit
no shutdown
exit
!
Anyone help me???, thanks a lot!
--
Thanks and Best Regards
--
From: Hoàng Mạnh Hùng
Hi,
I'm trying to run the latest osmocom-bb git on a Motorola C118 phone.
After a minor problem with the build (as you may've noticed in the
patch I've sent). I got to the point of successfuly running layer1 on
the phone and the mobile app on the PC (I have also enabled TX). The
process seems to be stuck on trying to perform a location update. The
status of the ms is always either:
show ms
MS '1' is up, MM connection active
IMEI: 000000000000000
IMEISV: 0000000000000000
IMEI generation: fixed
automatic network selection state: A1 trying RPLMN
MCC=104 MNC=002 (104, 002)
cell selection state: connected mode 1
ARFCN=19 MCC=104 MNC=002 LAC=0xb00f CELLID=0x4fd9
(104, 002)
radio ressource layer state: connection pending
mobility management layer state: wait for RR connection (location updating)
OsmocomBB>
or
show ms
MS '1' is up, service is limited (pending)
IMEI: 000000000000000
IMEISV: 0000000000000000
IMEI generation: fixed
automatic network selection state: A1 trying RPLMN
MCC=104 MNC=002 (104, 002)
cell selection state: C3 camped normally
ARFCN=19 MCC=104 MNC=002 LAC=0xb00f CELLID=0x4fd9
(104, 002)
radio ressource layer state: idle
mobility management layer state: MM idle, attempting to update
OsmocomBB>
I think, that because of this I can't make any calls or send sms (all
the requests are being rejected):
OsmocomBB# call 1 <X>
call 1 <X>
OsmocomBB#
% (MS 1)
% Call has been rejected
The log information from mobile when it's trying to do a location
update is show below:
<000b> gsm48_rr.c:2174 PAGING REQUEST 1
<000b> gsm48_rr.c:2141 IMSI 260021964220249 (not for us)
<000b> gsm48_rr.c:2132 TMSI fd82a501 (not for us)
<000e> gsm48_mm.c:344 Location update retry
<0005> gsm48_mm.c:345 timer T3211 (loc. upd. retry delay) has fired
<0005> gsm48_mm.c:4311 (ms 1) Received 'MM_EVENT_TIMEOUT_T3211' event
in state MM IDLE, attempting to update
<000e> gsm48_mm.c:2199 Perform location update (MCC 104, MNC 002 LAC 0xb00f)
<0005> gsm48_mm.c:2333 LOCATION UPDATING REQUEST
<0005> gsm48_mm.c:2355 using LAI (mcc 104 mnc 002 lac 0xb00f)
<0005> gsm48_mm.c:2363 using TMSI 0x28a3d62e
<0005> gsm48_mm.c:914 new state MM IDLE, attempting to update -> wait
for RR connection (location updating)
<0001> gsm48_rr.c:5428 (ms 1) Message 'RR_EST_REQ' received in state
idle (sapi 0)
<000e> gsm48_rr.c:1318 Establish radio link due to mobility management request
<0003> gsm322.c:4037 (ms 1) Event 'EVENT_LEAVE_IDLE' for Cell
selection in state 'C3 camped normally'
<0003> gsm322.c:823 new state 'C3 camped normally' -> 'connected mode 1'
<0003> gsm322.c:3653 Going to camping (normal) ARFCN 19.
<0003> gsm322.c:463 Sync to ARFCN=19 rxlev=-74 (Sysinfo, ccch mode NON-COMB)
<0001> gsm48_rr.c:366 new state idle -> connection pending
<0001> gsm48_rr.c:1465 CHANNEL REQUEST: 00 (Location Update with NECI)
<0003> gsm322.c:2938 Channel synched. (ARFCN=19, snr=16, BSIC=17)
<0001> gsm322.c:2959 using DSC of 90
<0003> gsm48_rr.c:4816 Channel provides data.
<0001> gsm48_rr.c:1601 RANDOM ACCESS (requests left 5)
<0001> gsm48_rr.c:1658 RANDOM ACCESS (Tx-integer 50 combined no
S(lots) 0 ra 0x0e)
<0001> gsm48_rr.c:1697 Use MS-TXPWR-MAX-CCH power value 5 (33 dBm)
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:1601 RANDOM ACCESS (requests left 4)
<0001> gsm48_rr.c:1658 RANDOM ACCESS (Tx-integer 50 combined no
S(lots) 55 ra 0x07)
<0001> gsm48_rr.c:1697 Use MS-TXPWR-MAX-CCH power value 5 (33 dBm)
<0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT:
<0001> gsm48_rr.c:2462 (ta 2/1107m ra 0x75 chan_nr 0x0a MAIO 0 HSN 38
TS 2 SS 0 TSC 0)
<0001> gsm48_rr.c:2503 Request, but not for us.
<0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT:
<0001> gsm48_rr.c:2462 (ta 2/1107m ra 0x75 chan_nr 0x0a MAIO 0 HSN 38
TS 2 SS 0 TSC 0)
<0001> gsm48_rr.c:2503 Request, but not for us.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:673 MON: f=19 lev=-78 snr= 0 ber= 0 LAI=104 002 b00f ID=4fd9
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:1601 RANDOM ACCESS (requests left 3)
<0001> gsm48_rr.c:1658 RANDOM ACCESS (Tx-integer 50 combined no
S(lots) 55 ra 0x0f)
<0001> gsm48_rr.c:1697 Use MS-TXPWR-MAX-CCH power value 5 (33 dBm)
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:1601 RANDOM ACCESS (requests left 2)
<0001> gsm48_rr.c:1658 RANDOM ACCESS (Tx-integer 50 combined no
S(lots) 55 ra 0x01)
<0001> gsm48_rr.c:1697 Use MS-TXPWR-MAX-CCH power value 5 (33 dBm)
<0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT:
<0001> gsm48_rr.c:2473 (ta 1/553m ra 0x18 chan_nr 0x59 ARFCN 19 TS 1
SS 3 TSC 1)
<0001> gsm48_rr.c:2503 Request, but not for us.
<0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT:
<0001> gsm48_rr.c:2473 (ta 1/553m ra 0x18 chan_nr 0x59 ARFCN 19 TS 1
SS 3 TSC 1)
<0001> gsm48_rr.c:2503 Request, but not for us.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:1601 RANDOM ACCESS (requests left 1)
<0001> gsm48_rr.c:1658 RANDOM ACCESS (Tx-integer 50 combined no
S(lots) 55 ra 0x0a)
<0001> gsm48_rr.c:1697 Use MS-TXPWR-MAX-CCH power value 5 (33 dBm)
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:673 MON: f=19 lev=-78 snr= 0 ber= 1 LAI=104 002 b00f ID=4fd9
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:1601 RANDOM ACCESS (requests left 0)
<0001> gsm48_rr.c:1605 Done with sending RANDOM ACCESS bursts
<0001> gsm48_rr.c:836 starting T3126 with 5.000 seconds
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2225 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:673 MON: f=19 lev=-78 snr= 0 ber= 0 LAI=104 002 b00f ID=4fd9
<0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT:
<0001> gsm48_rr.c:2473 (ta 2/1107m ra 0x0a chan_nr 0x41 ARFCN 19 TS 1
SS 0 TSC 1)
<0001> gsm48_rr.c:2393 request 0a matches but not frame number
(IMM.ASS fn=22,6,30 != RACH fn=22,5,25)
<0001> gsm48_rr.c:2503 Request, but not for us.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT:
<0001> gsm48_rr.c:2473 (ta 2/1107m ra 0x05 chan_nr 0x49 ARFCN 19 TS 1
SS 1 TSC 1)
<0001> gsm48_rr.c:2503 Request, but not for us.
<0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT:
<0001> gsm48_rr.c:2473 (ta 2/1107m ra 0x05 chan_nr 0x49 ARFCN 19 TS 1
SS 1 TSC 1)
<0001> gsm48_rr.c:2503 Request, but not for us.
<0001> gsm48_rr.c:2225 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:673 MON: f=19 lev=-77 snr= 0 ber= 6 LAI=104 002 b00f ID=4fd9
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT:
<0001> gsm48_rr.c:2473 (ta 2/1107m ra 0x00 chan_nr 0x61 ARFCN 19 TS 1
SS 4 TSC 1)
<0001> gsm48_rr.c:2503 Request, but not for us.
<0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT:
<0001> gsm48_rr.c:2473 (ta 2/1107m ra 0x00 chan_nr 0x61 ARFCN 19 TS 1
SS 4 TSC 1)
<0001> gsm48_rr.c:2503 Request, but not for us.
<0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT:
<0001> gsm48_rr.c:2462 (ta 2/1107m ra 0x7d chan_nr 0x0b MAIO 0 HSN 38
TS 3 SS 0 TSC 0)
<0001> gsm48_rr.c:2503 Request, but not for us.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT:
<0001> gsm48_rr.c:2462 (ta 2/1107m ra 0x7d chan_nr 0x0b MAIO 0 HSN 38
TS 3 SS 0 TSC 0)
<0001> gsm48_rr.c:2503 Request, but not for us.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:673 MON: f=19 lev=-78 snr= 0 ber= 0 LAI=104 002 b00f ID=4fd9
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2225 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2225 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:673 MON: f=19 lev=-78 snr= 0 ber= 3 LAI=104 002 b00f ID=4fd9
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT:
<0001> gsm48_rr.c:2462 (ta 2/1107m ra 0x77 chan_nr 0x09 MAIO 0 HSN 38
TS 1 SS 0 TSC 0)
<0001> gsm48_rr.c:2503 Request, but not for us.
<0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT:
<0001> gsm48_rr.c:2462 (ta 2/1107m ra 0x77 chan_nr 0x09 MAIO 0 HSN 38
TS 1 SS 0 TSC 0)
<0001> gsm48_rr.c:2503 Request, but not for us.
<0001> gsm48_rr.c:2225 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:673 MON: f=19 lev=-78 snr= 0 ber= 6 LAI=104 002 b00f ID=4fd9
<0001> gsm48_rr.c:765 timer T3126 has fired
<000e> gsm48_rr.c:770 Requesting channel failed
<0001> gsm48_rr.c:366 new state connection pending -> idle
<0003> gsm322.c:4037 (ms 1) Event 'EVENT_RET_IDLE' for Cell selection
in state 'connected mode 1'
<0003> gsm322.c:3565 Selecting ARFCN 19. after LOC.UPD.
<0003> gsm322.c:463 Sync to ARFCN=19 rxlev=-74 (Sysinfo, ccch mode NON-COMB)
<0003> gsm322.c:823 new state 'connected mode 1' -> 'C3 camped normally'
<0005> gsm48_mm.c:3902 (ms 1) Received 'RR_REL_IND' from RR in state
wait for RR connection (location updating) (sapi 0)
<0005> gsm48_mm.c:2732 RR link released after loc. upd.
<000e> gsm48_mm.c:2676 Location update failed
<000e> gsm48_mm.c:2686 Try location update later
<0005> gsm48_mm.c:2688 Loc. upd. failed, retry #0
<0005> gsm48_mm.c:413 starting T3211 (loc. upd. retry delay) with 15.0 seconds
<0005> gsm48_mm.c:1143 We are camping normally as returning to MM IDLE
<0005> gsm48_mm.c:1159 Loc. upd. allowed.
<0005> gsm48_mm.c:919 new state wait for RR connection (location
updating) -> MM IDLE, location updating needed
<0005> gsm48_mm.c:909 new MM IDLE state location updating needed ->
attempting to update
<0005> gsm48_mm.c:2215 Loc. upd. already pending.
<0005> gsm48_mm.c:4311 (ms 1) Received 'MM_EVENT_CELL_SELECTED' event
in state MM IDLE, attempting to update
<0005> gsm48_mm.c:2215 Loc. upd. already pending.
<0003> gsm322.c:2938 Channel synched. (ARFCN=19, snr=16, BSIC=17)
<0001> gsm322.c:2959 using DSC of 90
Can you provide me any hints on how to debug this ? Why is the
location update failing constantly ?
Thanks in advance for your help.
Best regards,
Maciej Grela
Ravi Sharan <ravisharan(a)iith.ac.in> wrote:
> I am trying out osmocom-bb with the Motorla C115. [...]
< I get the following error:
>
> $ osmocon -p /dev/ttyUSB0 -m c123
> ~/osmocom-bb/src/target/firmware/board/compal_e88/hello_world.compalram.bin
> [snipped the part where everything goes as it should]
> got 1 bytes from modem, data looks like: 1b .
> got 1 bytes from modem, data looks like: f6 .
> got 1 bytes from modem, data looks like: 02 .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 45 E
> got 1 bytes from modem, data looks like: 53 S
> got 1 bytes from modem, data looks like: 16 .
> Received DOWNLOAD NACK from phone, something went wrong :(
Try -m c123xor instead of -m c123.
HTH,
SF
Hi All
Just wanted to confirm that I got Osmocom-BB up and running on a Raspberry Pi.
I did not use the GPIO UART pins but USB <-> serial converters.
I tried Motorola C118 and C155 with success.
Everything you need is already described:
http://bb.osmocom.org/trac/wiki/GnuArmToolchainhttp://bb.osmocom.org/trac/wiki/libosmocorehttp://bb.osmocom.org/trac/wiki/Software/GettingStarted?redirectedfrom=Gett…
My previous problem seems to have been a not fully compatible crosscompiled toolchain. (it worked mostly, but I could not log-in to a cell and the spectrum view crashed on the RSSI Firmware.
Also if you want transmit capability (or flashing) then you need to activate those features in the makefile.
Thanks Sylvain (confirming c118 will work) and all others who are involved!!
PS: Any news on the "emulated BTS" that has been presented at last years chaos communication congress?
I have 2 C118s + 1 normal USB serial dongle + 1 capable of burst ind.
I hope this will suffice to also run also a possible future 1 trasmit phone + 1 receive phone configuration.
I assume that even without the filter change it should be enough to send a few meters of distance.
Hi
I lost many sms(sent by myself) using the luca/gsmmap branch with my c118
and cp2102;
Could the sylvain/burst_ind branch or other branches fix the problem?
Regards,
Swift.
--
View this message in context: http://baseband-devel.722152.n3.nabble.com/about-sms-lost-tp4026485.html
Sent from the baseband-devel mailing list archive at Nabble.com.
Hi
I built the luca/gsmmap branch, and saw many messages in the wireshark with protocol GSM_SMS;
but when I tried to capture my sms (sending by my own phone), it does not work, I can not see my sms in wireshark;
then I used another phone to send a message to my phone, I saw nothing in wireshark too;
Could anyone tell me why?
Is it a problem about time slot ?
Regards,
Swift
changchuan618(a)gmail.com
Hi
I built the luca/gsmmap branch, and saw many messages in the wireshark with
protocol GSM_SMS;
but when I tried to capture my sms (sending by my own phone), it does not
work, I can not see my sms in wireshark;
then I used another phone to send a message to my phone, I saw nothing in
wireshark too;
Could anyone tell me why?
Is it a problem about time slot ?
Regards,
Swift
--------------------------------------------------------------------------------
--
View this message in context: http://baseband-devel.722152.n3.nabble.com/lost-sms-tp4026483.html
Sent from the baseband-devel mailing list archive at Nabble.com.
Hi,
While browsing through the wiki, I did not find a page for the VTY interface.
Does it really not exist or did I miss it ?
If it does not exist, I am planning to write one and send it to the
mailing list.
I have gone through some of the commands while reading the code and I
want to share what I have learnt.
Regards,
RM
On Wed, May 28, 2014 at 3:00 PM, Holger Hans Peter Freyther wrote:
> which language (simplified chinese?) do you offer to trac. There
> were no pending updates for babel/trac. Could you give me the HTTP
> request you make?
wget --header='Accept-Language: zh-cn,en;q=0.5' http://bb.osmocom.org/trac/
--
bye,
pabs
http://bonedaddy.net/pabs3/
This is a Mailman mailing list bounce action notice:
List: baseband-devel
Member: bjoern.riemer(a)fokus.fraunhofer.de
Action: Subscription disabled.
Reason: Excessive or fatal bounces.
The triggering bounce notice is attached below.
Questions? Contact the Mailman site administrator at
mailman(a)lists.osmocom.org.
Hi there,
> Try master or jolly/testing
> The sylvain/testing branch has some patches for the BTS mode that seem
> to break 'normal phone' mode.
It means that, at the state of art, the best branch to work with CalypsoBTS is the jolly/testing or the sylvain/testing?
Cheers,
Luca
****************
Il 5 x mille alla nostra Università è un investimento sui giovani,
sui loro migliori progetti.
Sostiene la libera ricerca.
Alimenta le loro speranze nel futuro.
Investi il tuo 5 x mille sui giovani.
Università degli Studi di Milano
codice fiscale 80012650158
http://www.unimi.it/13084.htm?utm_source=firmaMail&utm_medium=email&utm_con…
Hi,
I am trying to build the Sylvain testing branch. I am facing an issue
there. What I did is as follows:
1. I got the Sylvain testing branch to my computer.
2. I tried to build it and it failed saying that it cannot find the
libosmocore library.
3. I changed the top most Makefile to install libosmocore after building.
4. Again I tried to build and it built and installed libosmocore but
now Its complaining about osmocom/core/talloc.h not found in sim.c in
layer23 folder
6. As per the top Makefile, talloc is disabled in libosmocore but
sim.c file does not have conditional include for this header file.
Is this a problem or I am doing something wrong ?
Regards,
RM
I'm at the point w/ flashing firmware where I feel like I need to use a debugger w/ JTAG. I figured I could probably use serial line logging somehow but JTAG seems better and I should learn it anyway.
Has anyone pried open the shield on a c139/c140 and tried attaching to the JTAG test points that are just inside the shield next to the test points which are accessible via the battery compartment?
Hi,
Have you complied the libosmocore separately ? If you are using fedora
based distro make sure you have set the path correctly.
Regards,
Ravi Sharan
Hello fellow hackers,
Following my successful reverse eng of Tracfone "unlocking" utility
mot931c.exe, I wrote a native Unix/Linux program (tfc139, based on
FreeCalypso rvinterf tools) that breaks into locked-down TF C139
phones in the same fashion, with an IRAM payload that enables and
jumps to the Calypso boot ROM. Doing so allowed me to run fc-loadtool
against one of these Tracfones that still has its original locked-down
bootloader intact (*not* overwritten with mot931c), and make a dump of
the latter for examination.
So here is how the bootloader lock works: the bootloader which sits in
the first 0x2000 bytes of flash sector 0 is clearly built together
with the main fw image as a single whole (TI's reference firmware is
built the same way, so no surprise), and thus the bootloader version
changes in sync with the main fw version. Most of the versions seen
in the wild are almost byte-identical, the only diffs being some
unused signature (?) words at 0x20 and the word at 0x964 giving the
initial value to be loaded into the stack pointer - variations in the
latter are a linker artifact resulting from how this bootloader is
built together with the main fw.
Despite the way in which they must have been compiled, the older
versions of the bootloader have one good quality: if you are going to
break into the bootloader serially (in our familiar way), then only
the first 0x2000 bytes of the flash (in fact, even less than that)
need to be good; the flash from 0x2000 onward can be blank or filled
with garbage or malware or whatever - as long as the boot process is
interrupted with a serial download, the jump to 0x20f8 doesn't happen
and nothing from 0x2000 onward affects anything. So far, so good.
But the newer versions of the bootloader that are part of the newer
firmwares for both C11x/123 and C139/140 have an added malicious
feature. Before sending what we call PROMPT1 out the serial port and
waiting for a possible serial download, the boot code now checks the
word in flash at 0x2060. This word needs to equal 0xDDDDDDDD (was it
some developer's fascination with bras? - scnr); if this word contains
any other value, no serial download opportunity is offered, and the
code proceeds directly to the silly routine that emits that "ftmtool
error" nonsense, followed by the jump to 0x20f8.
All TF-branded C139 phones I've seen have fw version 8.8.17, which
features the new malware bootloader. And the word at 0x2060 is zeroed
out, resulting in the observed behavior of no serial download
opportunity being given on boot. I speculate that perhaps the newer
fw versions containing boot code with this malicious feature start out
with 0xDDDDDDDD in the word at 0x2060, so that their own developers
could do their job, but when shipping phones to end users, the bastards
issued some ETM or whatever command to zero that word out, disabling
the serial download access - remember that any NOR flash bit can be
changed from 1 to 0 at any time, but going the other way around
requires erasing and rewriting the whole sector.
So what do we do about it? Well, at least the TF-branded C139s still
have that ETM memory write command that allows us to break in by
writing a little payload into IRAM and smashing the stack while the
main fw is running, and we now have a free, source-enabled, Unix/Linux-
based tool for performing this break-in. Not too long ago there was
someone else on this list who had a newer C139 with Cingular branding
(not TF) that also featured the maliciously locked bootloader. Not
surprisingly, mot931c wouldn't work on that phone, as this closed
source Weendoze binary does a fw version query and refuses to work
with any versions other than TF's 8.8.x. But now that we have our own
free tool for the hack in question, it may be worth testing if one can
break into non-TF phones by the same method. The addresses for the
IRAM payload download and the stack smashing may need to be tweaked
experimentally, but hey...
When the time comes to flash our own FreeCalypso firmware into these
phones, I'm thinking of adopting one of the old bootloader versions as
our "standard". In fact, the only diff between C11x/123 and C139/140
versions of this boot code is that the latter adds the check for "1003"
at 0x803ce0, whereas the former has no such check. Thus we can use
the more basic C11x/123 version of the boot code on all hw versions,
and make our chainloading more efficient by loading 32 bytes instead
of 15332. :)
All of the work described above has already been pushed into the
freecalypso-sw and freecalypso-reveng Hg repositories on Bitbucket.
VLR,
SF
Hey folks,
Since I am planning to delve deeper into the Calypso-BTS...
I was wondering if.... after Sylvain and Jolly's last commits into their "*/testing" branches [1][2]...
- Someone else have made some (private) changes/improvements to the sources?!
- Is there a TO DO list available for suggested improvements?
- Is anyone working on it or it would be interested?
And another question... why those branches have not been merged?
Cheers,
Luca
[1] http://cgit.osmocom.org/osmocom-bb/commit/?h=sylvain/testing&id=1b8f488f396…
[2] http://cgit.osmocom.org/osmocom-bb/commit/?h=jolly/testing&id=c1d728975f4c0…
****************
Il 5 x mille alla nostra Università è un investimento sui giovani,
sui loro migliori progetti.
Sostiene la libera ricerca.
Alimenta le loro speranze nel futuro.
Investi il tuo 5 x mille sui giovani.
Università degli Studi di Milano
codice fiscale 80012650158
http://www.unimi.it/13084.htm?utm_source=firmaMail&utm_medium=email&utm_con…
Hello fellow hackers,
As has been discussed on this list a little over a month ago, Mot C139
phones sold with Tracfone branding usually have firmware version
8.8.17, which contains a bootloader in which the serial break-in and
download capability has been disabled. However, this locked-down
firmware version still has the **16379# keypad command that switches
the headset jack back to the UART and presents a variant of TI's
RVTMUX interface on this UART; and there exists a Weendoze program
called mot931c.exe that:
1. connects to this RVTMUX interface;
2. does some black magic to break into the otherwise locked-down phone;
3. erases and rewrites flash sector 0, replacing the "bad" bootloader
version with a "good" one.
The elusive part has been step 2 above - just what does this closed
source Winblows binary send to the phone to make the initial break-in?
Whoever was responsible for producing the locked-down fw in these
Tracfones really did close all of the well-known holes: not only have
they tied the nIBOOT pin high directly underneath the BGA and disabled
the serial access in their own bootloader, but TI's standard ETM_CORE
commands which would normally be available over RVTMUX don't work
either.
Well, I have finally reverse-engineered what this mot931c.exe tool
does (by running it under Wine, pointing the Wine-emulated COM port to
a Unix pseudo-tty instead of a real serial port, and listening and
talking back on the master side of the Unix pty), and here is the
secret: Compal's firmware features some non-standard commands of their
own invention in their version of TI's ETM, these non-standard commands
have *not* been disabled in the TF-branded fw, and one of them is a raw
memory write command.
(The following description assumes that the reader is familiar with
TI's standard versions of RVTMUX and ETM; if you aren't familiar
with these things, read my write-up thereof in the FreeCalypso
documentation.)
Compal's non-standard ETM memory write command has the following format:
0x14 octet: tells the RiViera Trace MUX that the packet is for ETM
0x40 octet: non-std opcode in the place where ETM component ID would
normally go
4 octets: absolute address at which the bytes are to be written,
in LE bytes order
remaining octets before ETM checksum: raw bytes to be written
1 octet: standard ETM command packet checksum at the end
(Wrapped in the RVTMUX STX/DLE byte stuffing as usual.)
The mot931c tool uses the above ETM memory write command to write 204
(0xCC) bytes at address 0x800000, at the low end of IRAM - this happens
with the regular fw still running! So far, so good. How is control
then transferred to this downloaded payload? Answer: by smashing the
stack!
After downloading its payload (in two chunks: first 120 bytes, then
the remaining 84), the mot931c tool sends more ETM memory write
command packets in exactly the same format, but this time each write
is just 4 bytes long. The address being written into starts at
0x837C54, and increments by 4 from there. The data written with each
of these commands is 00 00 80 00, i.e., 32-bit word 0x800000 in LE.
It is obviously seeking to hit a return address location on the stack,
in order to transfer control to the payload it just downloaded. If it
keeps getting "ETM command successful" responses from the target, it
keeps retrying with incrementing write addresses until it reaches
0x838BF0, at which point it gives up.
If this procedure succeeds in hitting the function return address on
the stack and thus transferring control to 0x800000, which will indeed
succeed when run against the TF firmware in question, the code that's
been downloaded into that IRAM location then provides its own very
simple serial download protocol whereby the next code stage is
downloaded and run. I haven't pursued the process further, as the
initial break-in was/is all I'm interested in. I strongly dislike
this mot931c.exe tool's Heisenbergian approach of altering the flash
content without saving the original first, and my plan is to use this
break-in procedure to make FreeCalypso's fc-loadtool work with these
TF C139s. Once we are running fc-loadtool, all of this tool's
functions will be available just like it currently offers on Openmoko
and Pirelli targets: flash dump2bin, flash erase, flash program-bin
etc. Put the user back in control, instead of a closed source Weendoze
binary that does all of the reflashing without asking the user if she
wants it or not.
Viva la Revolucion,
SF
Hi,
I have recently purchased a SIM card. When I use the SIM in Nokia 3310, and
try to manually select a particular cell, it says no access. SIM belongs to
the same network.
If I insert the same SIM in Blackberry Bold 9780, I am able to manually
select the same network and even make phone calls. I have set the Network
selection mode in Blackberry to Manual. I have also asked it connect only
to 2G networks.
To debug the issue, I connected the Nokia 3310 to my laptop and observed
the messages it exchanged with the network. From the messages, I see that
Nokia 3310 is getting a TIMSI assigned from the same cell.
But my Nokia 3310 says, No Access.
I also see a "DTAP Radio Resources Management Message Type: Channel Release
(0x0d)" message from the Network to the phone.
What does the above message mean ?
Is there any way for me to further debug the issue ?
Thanks and Regards,
RM
"E:V:A" <xdae3v3a(a)gmail.com> wrote:
> That was indeed a very nice and entertaining find. Also the many links
> within that document should let you find both useful code and
> contacts. Furthermore, what is interesting is that it also provides
> a historical perspective of the xgold modems, which should be useful in
> paving the way to deeper studies in the more modern versions.
Entertaining as it is, keep in mind that the fellow who did that hack
and wrote the article about it got *paid* to make those Kosher phones
for the religious customers in question. In the absence of such a
paid arrangement, I don't really understand why someone would willingly
waste her time trying to hack a "modern" phone, dealing with chips sans
docs, tivoized bootloaders and firmware that only exists as binaries
without source or even semi-src. The big question is: WHY would anyone
willingly choose to suffer through that mess, when instead one can
choose to use a phone based on the good old Calypso chipset, with full
docs, full schematics for some models, and a published semi-src for
TI's reference firmware version?
Yes, Calypso is old. Ancient, to be more precise. But so what? It
still works! If it ain't broke, don't fix it. Dismissing a perfectly
working and usable solution merely because of its mature age is
irrational.
Yes, Calypso-based phones are no longer made, and every existing model
that is still obtainable on ebay etc is crippled in one way or another.
But so what? We can solve this problem by building our own Calypso-
based "dumbphone", and making it exactly the way we like.
Yes, Calypso chips themselves aren't made any more either. But what
is the total number of people in the world who would want a "dumbphone"
running their own free firmware? Is it greater or less than 100? If
the number of people desiring such a phone is <= 100, I already have
enough Calypso+etc chipsets for all 100 of us sitting in my desk
drawer. If the number of interested persons is > 100, there should be
more chips still available in the vast nation of China.
Yes, the available surplus of Calypso/Iota/Rita chips won't last
forever. But if there really are so many of us to exhaust that supply,
then surely we could pay some Chinese chip fab to reverse-eng that old
silicon and fab new verbatim clones in whatever quantity we need.
I just posted an update to the other mailing list, showing where the
free & usable Calypso dumbphone project currently stands and how it is
progressing:
http://lists.openmoko.org/pipermail/community/2014-May/069469.html
VLR,
SF
Hi,
I am trying out osmocom-bb with the Motorla C115. I have compiled
libosmocore as a shared library and osmocom successfully. Also, I have
compiled a "arm-none'eabi" cross toolchain from scratch. I get the
following error:
$ osmocon -p /dev/ttyUSB0 -m c123
~/osmocom-bb/src/target/firmware/board/compal_e88/hello_world.compalram.bin
got 1 bytes from modem, data looks like: 00 .
got 2 bytes from modem, data looks like: 00 00 ..
got 4 bytes from modem, data looks like: 1b 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
read_file(/home/ravi/osmocom-bb/src/target/firmware/board/compal_e88/hello_world.compalram.bin):
file_size=25184, hdr_len=4, dnload_len=25191
got 1 bytes from modem, data looks like: 1b .
got 1 bytes from modem, data looks like: f6 .
got 1 bytes from modem, data looks like: 02 .
got 1 bytes from modem, data looks like: 00 .
got 1 bytes from modem, data looks like: 41 A
got 1 bytes from modem, data looks like: 02 .
got 1 bytes from modem, data looks like: 43 C
Received PROMPT2 from phone, starting download
handle_write(): 4096 bytes (4096/25191)
handle_write(): 4096 bytes (8192/25191)
handle_write(): 4096 bytes (12288/25191)
handle_write(): 4096 bytes (16384/25191)
handle_write(): 4096 bytes (20480/25191)
handle_write(): 4096 bytes (24576/25191)
handle_write(): 615 bytes (25191/25191)
handle_write(): finished
got 1 bytes from modem, data looks like: 1b .
got 1 bytes from modem, data looks like: f6 .
got 1 bytes from modem, data looks like: 02 .
got 1 bytes from modem, data looks like: 00 .
got 1 bytes from modem, data looks like: 45 E
got 1 bytes from modem, data looks like: 53 S
got 1 bytes from modem, data looks like: 16 .
Received DOWNLOAD NACK from phone, something went wrong :(
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 .
got 1 bytes from modem, data looks like: 00
Can the error be because of the toolchain ? Or can it be that my device is
refusing connection with osmocon ?
Thanks in advance.
Ravi Sharan
Hi folks,
Came across this article in the latest PoC||GTFO journal describing (part
of) the process for patching firmware on Nokia DCT4+ phones. The good
stuff is pages 22-29 of this file:
http://openwall.info/wiki/_media/people/solar/pocorgtfo03.pdf
Alas, this does not appear to permit patching the first 1MB of firmware, so
may not be helpful for OsmocomBB. But perhaps someone with more time on
their hands can take this and run with it...
Cheers,
-Andrew