I tried to install CalypsoBTS have libosmocore installed, osmo-bts osmobsc,
libosmo-netif, libosmo-abis, ortp, trx, libosmo-dsp everything went without
errors, following the instructions I created: touch ~/.osmocom/open-bsc.cfg
, then when you run : osmo-nitb -c ~/.osmocom/open-bsc.cfg-l
~/.osmocom/hlr.sqlite3-P-C --debug=DRLL:CC:MM:RR:RSL:NM shows me:<0005>
bsc_init.c:498 Failed to parse the config file:
'/root/.osmocom/open-bsc.cfg' file tried to create as administrator but
without success , pleas help me
--
View this message in context: http://baseband-devel.722152.n3.nabble.com/Calypso-BTS-tp4026753.html
Sent from the baseband-devel mailing list archive at Nabble.com.
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 guys, first of all I want to express my deep respect for this project,
this is truly amazing project and very well developed.
Second, I'm doing a few studies regarding GSM security (no, I'm not
hacking.) and I need to develop a feature for osmocombb, which is: the
ability to turn the L23 app as a zombie (C unix domain socket) waiting for
instructions (e.g.: connect to the network with predefined parameters
(IMSI), collect RAND, send sms,...).
Is there any documentation or flow regarding the code? It's very hard for a
non C coder to follow the flow... Or is there someone that can help me in
the Architectural level?
Thank you.
Hi Sebastian,
On Sun, Feb 12, 2017 at 02:29:05PM +0100, Sebastian Stumpf wrote:
> The virtual layer 1 is currently in a state where the l23 app can
> successfully connect to the bts and most of the signaling messages
> will be forwarded and handled. TCH is not yet implemented.
this is excellent news! Thanks for sticking with this and pushing it
forward.
> - Trying to initiate a call via the mobile vty will result in
> VTY:
> call 1 123
> OsmocomBB#
> % (MS 1)
> % Call has been rejected
> call 1 123
> OsmocomBB#
> % (MS 1)
> % Call has been released
> And no actual call setup message is transfered over the Um interface.
> What could be reasons for that? I am using the test-sim option the
> mobile app offers.
I'm not sure if this is the root cause, but it seems there is some
timeslot mis-matches in your traces. The Immediate Assignment contains
TS 2 or TS 7, but I see Uplink frames for FACH on TS0, which is
impossible (TS0 never has a channel combination with FACCH).
Also, The uplink frames don't have the Uplink bit set in the GSMTAP
header. This is a bit confusing, and I think it would be a good idea to
introduce some consistency/invariant checking on both sides, i.e. the
BTS should drop all non-uplink frames received, and the MS should drop
all uplink frames received.
I'm also surprised to see you're seeing an immediate assignment reject
in downlink. This should only happen if all channels are allocated and
the BTS is out of resources.
Also, in your traces, there are typically several frames that are on the
same timeslot in the same GSM frame number. This is not possible
(probably related to the wrong TS above?). At maximum, there can be one
L2 signalling message for a given TS + FN. Also, on the real radio
interface a MAC block takes typically four frames on that channel, so
the actual rate is lower.
> - Occasionaly the T3210 timer is fired, which causes a new registering
> within the network.
well, it means that something got lost between MS and MSC for such a
long time (between sending the LU REQ and receving a response) that the
MS gives up.
> LOG:
> gsm48_mm.c:336 timer T3210 (loc. upd. timeout) has fired
> How can i prevent that?
The underlying problem must be resolved. On the simulated L1 you
shouldn't loose messages, so this shouldn't happen if all messages
arrive as expected on both sides.
> - I did not implement a tdma or multiframe scheduler in the mobile
> uplink as the logical channel is directly put to the gsmtap-header and
> thus known by the bts. As Harald used a multiframe based scheduling
> for the bts downlink, i wonder if this might be necessary, though. To
> submit msgs with the correct frame number for example.
It is primarily a question of how real the simulation should be. By
using a multiframe scheduler one can make sure that the actual
bandwidth/speed of GSM is maintained even over a virtual L1. Also, on
the BTS side it must be present to schedule the BCCH (system
information, ...) without which a MS would never even see the cell.
I think one can do without on the MS side, but then the BTS must
basically queue the incoming frames until the respective frame number
indicated in the frame matches the current frame number.
> - In my wireshark capture files, the gsmtap messages sent over the
> multicast sockets are only recognized as UDP messages. I have to
> "cast" them with the wireshark context menu "Decode as...". Why?
This seems because you're using a non-standard port for the messages:
In the capture I see UDP port 6666 rather than the IANA-registered port
for GSMTAP which is 4729.
> I would be super happy if someone of you could check out my project
> (osmo-bts, branch stumpf/virt-phy + osmocom-bb, branch
> stumpf/virt-phy) try to run it with the config files lying within the
> project folders and tell me the problems they see :).
I'll have a look, but not straight away now, sorry.
> Here you can find a wireshark capture file of 2 mobiles connecting to
> a virt bts. I also tried to init calls from both of them but the call
> setup is not send.
Already the LU is not working stable, so I think the first step is to
stabilize this. You can see in packet 740 that the MS is sneding a LU
Req, which the BTS forwards in frame 741 as RSL message to the NITB.
The NITB then responds with an IDENTITY REQUEST which can be seen on RSL
but which seems to disappear in the BTS without being ever sent on the
virtual Um interface. As a result, the MS never sends the identity
response, and the NITB will give up.
I also see that the RACH requesets all are sent with a bogus frame
number: 42. This will not work. The RACH request needs to be sent with
the current frame number at the time being. Also, RACH retransmissions
are happening way too quick. See Packets 600...644 where there are 7
RACH requests all within soemething like 10ms. The BTS then allocates
7 channels rather than one, ...
So I think those lower-layer issues should be addressed before moving on
to voice calls.
Keep up the good work!
Regards,
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)
You know that generally flashing the phone isn't needed. You can load all of the different osmocom images just with the osmocon loader into ram and "do things". The flashing can brick your device.
Just my $0.02,
Craig
--------------------------------------------
On Sat, 2/18/17, Dennis Schneck <dennisschneck(a)web.de> wrote:
Subject: Flashing Problem: C117
To: baseband-devel(a)lists.osmocom.org
Date: Saturday, February 18, 2017, 2:44 AM
Hello,
i try to Flash a Motorola C117. But did not work ...
what did i wrong ?
$ sudo host/osmocon/osmocon -p /dev/ttyUSB0 -m
c123xor
target/firmware/board/compal_e88/loader.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(target/firmware/board/compal_e88/loader.compalram.bin):
file_size=27072, hdr_len=4, dnload_len=27079
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/27079)
handle_write(): 4096 bytes (8192/27079)
handle_write(): 4096 bytes (12288/27079)
handle_write(): 4096 bytes (16384/27079)
handle_write(): 4096 bytes (20480/27079)
handle_write(): 4096 bytes (24576/27079)
handle_write(): 2503 bytes (27079/27079)
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: 41 A
got 1 bytes from modem, data looks like: 03 .
got 1 bytes from modem, data looks like: 42 B
Received DOWNLOAD ACK from phone, your code is running now!
Received DOWNLOAD ACK from phone, your code is running now!
battery_compal_e88_init: starting up
OsmocomBB Loader (revision
osmocon_v0.0.0-1773-g0cdf4b0-modified)
======================================================================
Running on compal_e88 in environment compalram
$ sudo host/osmocon/osmoload memdump 0x000000
0x2000 compal_loader.bin
[sudo] password for builder:
Dumping 8192 bytes of memory at 0x0 to file
compal_loader.bin
...................................done.
builder@buildervm:~/build/osmocom-bb/src$ sudo
host/osmocon/osmoload funlock 0x010000 0x10000
Unlocking 65536 bytes of flash at 0x10000
requesting flash info to determine block layout
chip 0 at 0x00000000 of 2097152 bytes in
2 regions
region 0 with 31 blocks of
65536 bytes each
block 0 with
65536 bytes at 0x00000000 on chip 0
block 1 with
65536 bytes at 0x00010000 on chip 0
block 2 with
65536 bytes at 0x00020000 on chip 0
block 3 with
65536 bytes at 0x00030000 on chip 0
block 4 with
65536 bytes at 0x00040000 on chip 0
block 5 with
65536 bytes at 0x00050000 on chip 0
block 6 with
65536 bytes at 0x00060000 on chip 0
block 7 with
65536 bytes at 0x00070000 on chip 0
block 8 with
65536 bytes at 0x00080000 on chip 0
block 9 with
65536 bytes at 0x00090000 on chip 0
block 10 with
65536 bytes at 0x000a0000 on chip 0
block 11 with
65536 bytes at 0x000b0000 on chip 0
block 12 with
65536 bytes at 0x000c0000 on chip 0
block 13 with
65536 bytes at 0x000d0000 on chip 0
block 14 with
65536 bytes at 0x000e0000 on chip 0
block 15 with
65536 bytes at 0x000f0000 on chip 0
block 16 with
65536 bytes at 0x00100000 on chip 0
block 17 with
65536 bytes at 0x00110000 on chip 0
block 18 with
65536 bytes at 0x00120000 on chip 0
block 19 with
65536 bytes at 0x00130000 on chip 0
block 20 with
65536 bytes at 0x00140000 on chip 0
block 21 with
65536 bytes at 0x00150000 on chip 0
block 22 with
65536 bytes at 0x00160000 on chip 0
block 23 with
65536 bytes at 0x00170000 on chip 0
block 24 with
65536 bytes at 0x00180000 on chip 0
block 25 with
65536 bytes at 0x00190000 on chip 0
block 26 with
65536 bytes at 0x001a0000 on chip 0
block 27 with
65536 bytes at 0x001b0000 on chip 0
block 28 with
65536 bytes at 0x001c0000 on chip 0
block 29 with
65536 bytes at 0x001d0000 on chip 0
block 30 with
65536 bytes at 0x001e0000 on chip 0
region 1 with 8 blocks of
8192 bytes each
block 31 with
8192 bytes at 0x001f0000 on chip 0
block 32 with
8192 bytes at 0x001f2000 on chip 0
block 33 with
8192 bytes at 0x001f4000 on chip 0
block 34 with
8192 bytes at 0x001f6000 on chip 0
block 35 with
8192 bytes at 0x001f8000 on chip 0
block 36 with
8192 bytes at 0x001fa000 on chip 0
block 37 with
8192 bytes at 0x001fc000 on chip 0
block 38 with
8192 bytes at 0x001fe000 on chip 0
confirmed operation on chip 0 address 0x00010000,
status FAILED
operation done
Thanks
