From holger at freyther.de Fri Feb 3 02:37:47 2017 From: holger at freyther.de (Holger Freyther) Date: Fri, 3 Feb 2017 10:37:47 +0800 Subject: Downtime due FreeBSD upgrade. Message-ID: <4E2306F1-3FBD-4C30-94D6-2B085FFD374A@freyther.de> Hi, the machine hosting most of *.osmocom.org is running FreeBSD9.3 which EOLed end of december and I would like to upgrade to FreeBSD10.3. I do not expect many problems but I also don't want to interfere with other peoples work. Even if it is short notice, any objections for Saturday->Sunday night of a European timezone? Otherwise I would pick next Friday->Saturday. regards holger From nhofmeyr at sysmocom.de Fri Feb 3 14:40:51 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 3 Feb 2017 15:40:51 +0100 Subject: Downtime due FreeBSD upgrade. In-Reply-To: <4E2306F1-3FBD-4C30-94D6-2B085FFD374A@freyther.de> References: <4E2306F1-3FBD-4C30-94D6-2B085FFD374A@freyther.de> Message-ID: <20170203144051.GA1586@my.box> Anytime is fine with me. ~N On Fri, Feb 03, 2017 at 10:37:47AM +0800, Holger Freyther wrote: > Even if it is short notice, any objections for Saturday->Sunday night > of a European timezone? Otherwise I would pick next Friday->Saturday. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From holger at freyther.de Sun Feb 5 00:52:51 2017 From: holger at freyther.de (Holger Freyther) Date: Sun, 5 Feb 2017 08:52:51 +0800 Subject: Downtime due FreeBSD upgrade. In-Reply-To: <4E2306F1-3FBD-4C30-94D6-2B085FFD374A@freyther.de> References: <4E2306F1-3FBD-4C30-94D6-2B085FFD374A@freyther.de> Message-ID: <20FF7514-838C-4CC0-B990-803787F38CB3@freyther.de> > On 3 Feb 2017, at 10:37, Holger Freyther wrote: > > Hi, Hi! > the machine hosting most of *.osmocom.org is running FreeBSD9.3 which > EOLed end of december and I would like to upgrade to FreeBSD10.3. I do > not expect many problems but I also don't want to interfere with other > peoples work. the base system has been upgraded, individual jails/containers are still based on 9.3 and will be handled one by one in the next days. If something seems to not work, please either create a ticket in our redmine and assign it to me or send an email to me. thank you holger From laforge at gnumonks.org Sun Feb 12 23:09:20 2017 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 13 Feb 2017 00:09:20 +0100 Subject: Virtual layer 1 - Questions In-Reply-To: References: Message-ID: <20170212230920.epvdsj7jwxzta23w@nataraja> 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 http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From dennisschneck at web.de Wed Feb 15 05:02:07 2017 From: dennisschneck at web.de (Dennis Schneck) Date: Wed, 15 Feb 2017 06:02:07 +0100 Subject: Compile error - osmocom-bb | No package 'libosmocore' found but libosmocore is installed Message-ID: ? Hello, I am suing Manjaro Linux (Arch Linux based) and do not get the osmocom-bb compiled. ? git clone https://github.com/osmocom/osmocom-bb cd osmocom-bb/src make .... .... checking pkg-config is at least version 0.9.0... yes checking for LIBOSMOCORE... no configure: error: Package requirements (libosmocore) were not met: No package 'libosmocore' found Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. Alternatively, you may set the environment variables LIBOSMOCORE_CFLAGS and LIBOSMOCORE_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details. make: *** [Makefile:69: host/layer23/Makefile] Fehler 1 ? ? but libosmocore is compiled and installed ( /usr/local ) ? $ ls -la /usr/local/include/osmocom/ insgesamt 40 drwxr-xr-x 10 root root 4096 12. Feb 06:45 . drwxr-xr-x? 3 root root 4096 12. Feb 06:45 .. drwxr-xr-x? 2 root root 4096 12. Feb 06:45 codec drwxr-xr-x? 2 root root 4096 12. Feb 06:45 core drwxr-xr-x? 2 root root 4096 12. Feb 06:45 crypt drwxr-xr-x? 2 root root 4096 12. Feb 06:45 ctrl drwxr-xr-x? 3 root root 4096 12. Feb 06:45 gprs drwxr-xr-x? 3 root root 4096 12. Feb 06:45 gsm drwxr-xr-x? 2 root root 4096 12. Feb 06:45 sim drwxr-xr-x? 2 root root 4096 12. Feb 06:45 vty ? $ ls -la /usr/local/lib/ insgesamt 3408 drwxr-xr-x? 3 root root?? 4096 12. Feb 06:45 . drwxr-xr-x 11 root root?? 4096 16. Feb 2015? .. -rwxr-xr-x? 1 root root??? 981 12. Feb 06:45 libosmocodec.la lrwxrwxrwx? 1 root root???? 21 12. Feb 06:45 libosmocodec.so -> libosmocodec.so.0.0.0 lrwxrwxrwx? 1 root root???? 21 12. Feb 06:45 libosmocodec.so.0 -> libosmocodec.so.0.0.0 -rwxr-xr-x? 1 root root? 26968 12. Feb 06:45 libosmocodec.so.0.0.0 -rwxr-xr-x? 1 root root??? 945 12. Feb 06:45 libosmocore.la lrwxrwxrwx? 1 root root???? 20 12. Feb 06:45 libosmocore.so -> libosmocore.so.8.0.0 lrwxrwxrwx? 1 root root???? 20 12. Feb 06:45 libosmocore.so.8 -> libosmocore.so.8.0.0 -rwxr-xr-x? 1 root root 441216 12. Feb 06:45 libosmocore.so.8.0.0 -rwxr-xr-x? 1 root root?? 1033 12. Feb 06:45 libosmoctrl.la lrwxrwxrwx? 1 root root???? 20 12. Feb 06:45 libosmoctrl.so -> libosmoctrl.so.0.0.0 lrwxrwxrwx? 1 root root???? 20 12. Feb 06:45 libosmoctrl.so.0 -> libosmoctrl.so.0.0.0 -rwxr-xr-x? 1 root root 100072 12. Feb 06:45 libosmoctrl.so.0.0.0 -rwxr-xr-x? 1 root root?? 1021 12. Feb 06:45 libosmogb.la lrwxrwxrwx? 1 root root???? 18 12. Feb 06:45 libosmogb.so -> libosmogb.so.4.0.0 lrwxrwxrwx? 1 root root???? 18 12. Feb 06:45 libosmogb.so.4 -> libosmogb.so.4.0.0 -rwxr-xr-x? 1 root root 430400 12. Feb 06:45 libosmogb.so.4.0.0 -rwxr-xr-x? 1 root root??? 969 12. Feb 06:45 libosmogsm.la lrwxrwxrwx? 1 root root???? 19 12. Feb 06:45 libosmogsm.so -> libosmogsm.so.6.1.0 lrwxrwxrwx? 1 root root???? 19 12. Feb 06:45 libosmogsm.so.6 -> libosmogsm.so.6.1.0 -rwxr-xr-x? 1 root root 957032 12. Feb 06:45 libosmogsm.so.6.1.0 -rwxr-xr-x? 1 root root?? 1018 12. Feb 06:45 libosmosim.la lrwxrwxrwx? 1 root root???? 19 12. Feb 06:45 libosmosim.so -> libosmosim.so.0.0.0 lrwxrwxrwx? 1 root root???? 19 12. Feb 06:45 libosmosim.so.0 -> libosmosim.so.0.0.0 -rwxr-xr-x? 1 root root 175416 12. Feb 06:45 libosmosim.so.0.0.0 -rwxr-xr-x? 1 root root??? 969 12. Feb 06:45 libosmovty.la lrwxrwxrwx? 1 root root???? 19 12. Feb 06:45 libosmovty.so -> libosmovty.so.3.0.0 lrwxrwxrwx? 1 root root???? 19 12. Feb 06:45 libosmovty.so.3 -> libosmovty.so.3.0.0 -rwxr-xr-x? 1 root root 378280 12. Feb 06:45 libosmovty.so.3.0.0 -rw-r--r--? 1 root root 578174? 6. Jan 2016? libphysfs.a lrwxrwxrwx? 1 root root???? 14? 6. Jan 2016? libphysfs.so -> libphysfs.so.1 lrwxrwxrwx? 1 root root???? 18? 6. Jan 2016? libphysfs.so.1 -> libphysfs.so.2.0.3 -rwxr-xr-x? 1 root root 340504? 6. Jan 2016? libphysfs.so.2.0.3 ? ? ? ? $ pacman -Ss arm- community/arm-none-eabi-binutils 2.27-2 [Installiert] ??? A set of programs to assemble and manipulate binary and object files for the ARM EABI (bare-metal) target community/arm-none-eabi-gcc 6.3.0-1 [Installiert] ??? The GNU Compiler Collection - cross compiler for ARM EABI (bare-metal) target community/arm-none-eabi-gdb 7.12-3 [Installiert] ??? The GNU Debugger for the ARM EABI (bare-metal) target community/arm-none-eabi-newlib 2.5.0-1 [Installiert] ??? A C standard library implementation intended for use on embedded systems (ARM bare metal) ? ?What did i wrong ? ? Thanks ? From dennisschneck at web.de Wed Feb 15 06:40:19 2017 From: dennisschneck at web.de (Dennis Schneck) Date: Wed, 15 Feb 2017 07:40:19 +0100 Subject: Aw: Re: Compile error - osmocom-bb | No package 'libosmocore' found but libosmocore is installed In-Reply-To: References: , Message-ID: An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Wed Feb 15 10:55:57 2017 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 15 Feb 2017 11:55:57 +0100 Subject: Compile error - osmocom-bb | No package 'libosmocore' found but libosmocore is installed In-Reply-To: References: Message-ID: <20170215105557.hfq3ndgkl3kfmzhv@nataraja> It seems like your pkgconfig installation/configuration is broken. Are you sure that /usr/local/lib/pkgconfig is included in your PKGCONFIG search path? To me it seems the .pc files of libosmocore are installed there but your sytem configuration never attempts to look for .pc files there. Have you used pkgconfig successfully with other libraries installed in /usr/local/* before? -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From dennisschneck at web.de Thu Feb 16 07:39:16 2017 From: dennisschneck at web.de (Dennis Schneck) Date: Thu, 16 Feb 2017 08:39:16 +0100 Subject: Aw: Re: Re: Compile error - osmocom-bb | No package 'libosmocore' found but libosmocore is installed Message-ID: An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Thu Feb 16 11:28:47 2017 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 16 Feb 2017 12:28:47 +0100 Subject: Compile error - osmocom-bb | No package 'libosmocore' found but libosmocore is installed In-Reply-To: References: Message-ID: <20170216112847.ipiekin52mfbhiqy@nataraja> Hi Dennis, On Thu, Feb 16, 2017 at 08:39:16AM +0100, Dennis Schneck wrote: > >It seems like your pkgconfig installation/configuration is broken. Are > >you sure that /usr/local/lib/pkgconfig is included in your PKGCONFIG > >search path? To me it seems the .pc files of libosmocore are installed > >there but your sytem configuration never attempts to look for .pc files > >there. > > $ ls -la /usr/local/lib/pkgconfig/ this is a list of the files in the directory, which doesn't say anything about your pkgconfig configuration/environment variables. > >Have you used pkgconfig successfully with other libraries installed in > >/usr/local/* before? > > nothing installed before Well, I suggest you make sure your PKGCONFIG_PATH includes the above directory :) -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From dennisschneck at web.de Fri Feb 17 05:34:56 2017 From: dennisschneck at web.de (Dennis Schneck) Date: Fri, 17 Feb 2017 06:34:56 +0100 Subject: Workaround - Aw: Re: Re: Re: Compile error - osmocom-bb | No package 'libosmocore' found but libosmocore is installed In-Reply-To: <20170216112847.ipiekin52mfbhiqy@nataraja> References: , <20170216112847.ipiekin52mfbhiqy@nataraja> Message-ID: An HTML attachment was scrubbed... URL: From dennisschneck at web.de Fri Feb 17 09:56:01 2017 From: dennisschneck at web.de (Dennis Schneck) Date: Fri, 17 Feb 2017 10:56:01 +0100 Subject: Motorola C117 - Is compal E87 ? Message-ID: An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Fri Feb 17 12:20:42 2017 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 17 Feb 2017 13:20:42 +0100 Subject: Workaround - Aw: Re: Re: Re: Compile error - osmocom-bb | No package 'libosmocore' found but libosmocore is installed In-Reply-To: References: <20170216112847.ipiekin52mfbhiqy@nataraja> Message-ID: <20170217122042.e2sakelehl43zerr@nataraja> On Fri, Feb 17, 2017 at 06:34:56AM +0100, Dennis Schneck wrote: > Hello, > no solution for Manjaro Linux but a workaround. Extending PKG_CONFIG_PATH didn't work? Did you check the man page of pkg-config? === ENVIRONMENT VARIABLES PKG_CONFIG_PATH A colon-separated (on Windows, semicolon-separated) list of directories to search for .pc files. The default directory will always be searched after searching the path; the default is libdir/pkgconfig:datadir/pkgconfig where libdir is the libdir for pkg-config and datadir is the datadir for pkg-config when it was installed. === -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From steve at steve-m.de Fri Feb 17 13:57:40 2017 From: steve at steve-m.de (steve at steve-m.de) Date: Fri, 17 Feb 2017 14:57:40 +0100 Subject: Motorola C117 - Is compal E87 ? In-Reply-To: References: Message-ID: <8201e5e4d9df53493955759c0e0de4ed@steve-m.de> Hi Dennis, On 2017-02-17 10:56, Dennis Schneck wrote: > a Motorola C117 is compal E87 ? As far as I know the board is E88, just like the C123 or C118. > But there is no *.bin file for: compal_e87 in > src/target/firmware/board/ The compal_e88 binary should work, make sure to use -m c123xor for osmocon. Regards, Steve From dennisschneck at web.de Fri Feb 17 15:52:13 2017 From: dennisschneck at web.de (Dennis Schneck) Date: Fri, 17 Feb 2017 16:52:13 +0100 Subject: Aw: Re: Motorola C117 - Is compal E87 ? In-Reply-To: <8201e5e4d9df53493955759c0e0de4ed@steve-m.de> References: , <8201e5e4d9df53493955759c0e0de4ed@steve-m.de> Message-ID: An HTML attachment was scrubbed... URL: From dennisschneck at web.de Sat Feb 18 08:44:15 2017 From: dennisschneck at web.de (Dennis Schneck) Date: Sat, 18 Feb 2017 09:44:15 +0100 Subject: Flashing Problem: C117 Message-ID: An HTML attachment was scrubbed... URL: From dennisschneck at web.de Sat Feb 18 09:06:55 2017 From: dennisschneck at web.de (Dennis Schneck) Date: Sat, 18 Feb 2017 10:06:55 +0100 Subject: Flashing Problem: C117 - additional info Message-ID: An HTML attachment was scrubbed... URL: From dennisschneck at web.de Sat Feb 18 09:31:58 2017 From: dennisschneck at web.de (Dennis Schneck) Date: Sat, 18 Feb 2017 10:31:58 +0100 Subject: SOLVED Aw: Flashing Problem: C117 - additional info In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From dennisschneck at web.de Sat Feb 18 09:35:34 2017 From: dennisschneck at web.de (Dennis Schneck) Date: Sat, 18 Feb 2017 10:35:34 +0100 Subject: Flashing Problem: target/firmware/board/compal_e88/menu.e88loader.bin mssing Message-ID: An HTML attachment was scrubbed... URL: From craig_comstock at yahoo.com Sat Feb 18 13:19:30 2017 From: craig_comstock at yahoo.com (Craig Comstock) Date: Sat, 18 Feb 2017 13:19:30 +0000 (UTC) Subject: Flashing Problem: C117 References: <1033600701.101928.1487423970501.ref@mail.yahoo.com> Message-ID: <1033600701.101928.1487423970501@mail.yahoo.com> 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 wrote: Subject: Flashing Problem: C117 To: baseband-devel at 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 at 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 From laforge at gnumonks.org Thu Feb 23 14:41:24 2017 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 23 Feb 2017 15:41:24 +0100 Subject: Virtual layer 1 - Questions In-Reply-To: References: <20170212230920.epvdsj7jwxzta23w@nataraja> Message-ID: <20170223144124.mdba7w7avdujy23g@nataraja> Hi Sebastian, On Sun, Feb 19, 2017 at 06:16:01PM +0100, Sebastian Stumpf wrote: > > 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. > > I fixed that and calculate the proper rach fn like in > https://github.com/osmocom/osmocom-bb/blob/master/src/target/firmware/layer1/prim_rach.c#L137-L151 good. > > Also, RACH retransmissions are happening way too quick. > > Calculating a proper frame number didn't fix the fast retransmissions. > They are caused by sending the channel request over the virtual um > immediately after getting the rach-request from layer23. Thus also the > rach-confirm is sent to l23 immediately, so layer23 thinks "oh fine its > already transmitted" and will generate the next rach-request for my > layer 1. i see. the confirmation should probably be delayed somehow. As a quick intermediate hack you might simply add a timer. > > 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. > > I think to fix the problem with the quick retransmission , I need some type > of scheduling. Because if I queue the incoming uplink-msgs in the > bts-virtual-layer1 instead, I don't know when they are processed on the ms > side and thus don't know when to send the rach-confirm to layer23... > > My idea for a simple scheduler would be: > -- no timing and timer interrupts on ms side, but just set the current fn in > the ms state each time we receive a message on downlink to the fn of > the received message, which is accessible in the gsmtap header. yes, that makes sense. > -- queue the outgoing uplink messages with their confirm callback to l2 > and process all that with a smaller fn than the current fn in the > scheduling function. yes, but please keep in mind that the frame number is wrapping every so often, so "smaller" must consider that modulo-arithmetic, or you will (after fn wrap) have pending downlink messages for much higher fn which are not sent as the wrapped fn is now very small. > -- calling the scheduling function each time we receive a msg on downlink > (so I do not need to handle timer interrupts) yes. I think it is reasonable to not have any actual timers on the ms side and always depend on the frame numbers in the downlink messages from the BTS. After all, in the worst case you have periodic messages like the BCCH messages that can be used to update the fn. > I hope that will be sufficent and try it out tomorrow. I am a bit > afraid of trouble caused by the frame number skipping values with the > upper incrementation logic. I don't think skips are that problematic. But then, I haven't tried it ;) -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Tue Feb 28 21:31:56 2017 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 28 Feb 2017 22:31:56 +0100 Subject: Virtual layer 1 - Questions In-Reply-To: References: <20170212230920.epvdsj7jwxzta23w@nataraja> <20170223144124.mdba7w7avdujy23g@nataraja> Message-ID: <20170228213156.q72chdhhjxtyazy4@nataraja> Hi Sebastian, On Tue, Feb 28, 2017 at 06:29:20PM +0100, Sebastian Stumpf wrote: > I implemented the simple scheduler and it seems to work fine. I was happy > to find the assignment of channels to their respective frame in the mframe > in > https://github.com/osmocom/osmocom-bb/blob/master/src/target/firmware/layer1/mframe_sched.c#L67-L292 > and used that to calculate the fn the messages should be scheduled in. good to hear. > I come some steps further but are still having trouble to: > > Send an sms to myself using the extension assigned to my ms from osmo-nitb > (see 2341 in cap-file). > VTY: > sms 1 12 "Hallo zusammen" > OsmocomBB# > % (MS 1) > % SMS to 12 failed: Semantically Incorrect Message The establishment from 2341 looks fine: * we first establish SAPI0 (signalling) on the SDCCH * we then establish SAPI3 (SMS) on the same SDCCH (SABM/UA) * we see The CP-DATA RP-DATA with the SMS-SUBMIT * we get an CP-ACK from the network Then the network tells us the SMS was semantically incorrect. This is a problem at a much higher level. I would expect this to also be the case if you used a real layer1 between an OsmocomBB phone and a BTS on the network side. from looking at the wireshark trace I cannot immediately identify an issue. I guess you need to 'logging enable sms debug' on the NITB and see if it tells you where/why it fails. > Call myself (11851 in cap file) > VTY: > OsmocomBB# call 1 12 > OsmocomBB# > % (MS 1) > % Call has been released Ok, in 11445-11449 we see the RACH/CHAN_RQD/IMM.ASS, which assigns Timeslot 7 to the MS. In 11466 we see the CM SERV REQ on the Um inteface, in 11470 on the Abis interface. In 11470 we see the BSC responding with CM SERV ACC, in 11475 this is forwaded over the Um inteface. However, the MS never reacts to it. Also, what's noteworthy (but likely unrelated) is that the BTS is sending empty idle/padding frames on the TS7 all the time (those containing 0x2b2b2b2b) but the MS is not doing that in uplink. In 11546 the CM SERV REQ is re-transmitted in a SABM frame, which is again acknowledged in the UA frame in 11548. So the BTS is doing everything correctly (it seems) but the MS somehow doesn't receive the UA (on LAPDm layer) nor the CM SERVICE ACCEPT (on layer 3 MM) As you can see there is no RSL communication this time, as it is just simply re-transmission on the LAPDm layer between BTS and MS. > Losing RR connection after some time. This is likely a result of the MS somehow not receiving/processing the downlink signalling messages. you could start a cell without any SDCCH to test if pure signalling works on TCH/FACCH at all. If you cannot even do a location update anymore, the problem is in the TCH/FACCH receiving code. If you can perform LU over TCH, the problem becomes more mysterious ;) > What I do not understand here is why I get a full power measurement request > from mobile although I did set a fixed arfcn in the config. maybe neighbor cell measurement reporting? > And of course a fbsb req for arfcn 33578 seems simply wrong... This is 0x832A which translates to ARFCN 810 decimal, with the highest bit set for (if I remember correctly) PCS? or Uplink/Downlink bit? In any case, the highest bit of the 16bit value is used for something else, check the code :P > Next step after fixing the false fbsb request from l23 would be to add a > second mobile and then try to get the mobile originated call to work. I think there's a problem with TCH/FACCH that needs to be resolved first, see above. But anyway, there's good progress and I'm happy you're pushing forward with this! I think a virtual L1 is a very useful foundation for all kinds of automatic testing of the higher protocol layers, in a way that everyone can execute, even without a real-world setup of BTSs and MSs. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From duarteetraud at gmail.com Sat Feb 11 18:25:24 2017 From: duarteetraud at gmail.com (Etraud) Date: Sat, 11 Feb 2017 18:25:24 -0000 Subject: =?UTF-8?Q?Re:_Why_not_have_the_=E2=80=9Csim_spoo?= =?UTF-8?Q?f_MS=E2=80=9D_command_in_now_OSMOCOM-BB?= In-Reply-To: <1463635808863-4026742.post@n3.nabble.com> References: <1463635808863-4026742.post@n3.nabble.com> Message-ID: <1486837155997-4026770.post@n3.nabble.com> Hi! Which branch was that code in? Thank you. -- View this message in context: http://baseband-devel.722152.n3.nabble.com/Why-not-have-the-sim-spoof-MS-command-in-now-OSMOCOM-BB-tp4026742p4026770.html Sent from the baseband-devel mailing list archive at Nabble.com. From duarteetraud at gmail.com Wed Feb 15 22:02:54 2017 From: duarteetraud at gmail.com (Duarte) Date: Wed, 15 Feb 2017 22:02:54 -0000 Subject: Osmocombb as a Zombie Message-ID: 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastian.stumpf87 at googlemail.com Sun Feb 19 17:16:09 2017 From: sebastian.stumpf87 at googlemail.com (Sebastian Stumpf) Date: Sun, 19 Feb 2017 17:16:09 -0000 Subject: Virtual layer 1 - Questions In-Reply-To: <20170212230920.epvdsj7jwxzta23w@nataraja> References: <20170212230920.epvdsj7jwxzta23w@nataraja> Message-ID: Hi Harald, thanks for the detailed response. > 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. I fixed that and calculate the proper rach fn like in https://github.com/osmocom/osmocom-bb/blob/master/src/target/firmware/layer1/prim_rach.c#L137-L151 . > Also, RACH retransmissions > are happening way too quick. Calculating a proper frame number didn't fix the fast retransmissions. They are caused by sending the channel request over the virtual um immediately after getting the rach-request from layer23. Thus also the rach-confirm is sent to l23 immediately, so layer23 thinks "oh fine its already transmitted" and will generate the next rach-request for my layer 1. > 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. I think to fix the problem with the quick retransmission , I need some type of scheduling. Because if I queue the incoming uplink-msgs in the bts-virtual-layer1 instead, I don't know when they are processed on the ms side and thus don't know when to send the rach-confirm to layer23... My idea for a simple scheduler would be: -- no timing and timer interrupts on ms side, but just set the current fn in the ms state each time we receive a message on downlink to the fn of the received message, which is accessible in the gsmtap header. -- queue the outgoing uplink messages with their confirm callback to l2 and process all that with a smaller fn than the current fn in the scheduling function. -- calling the scheduling function each time we receive a msg on downlink (so I do not need to handle timer interrupts) I hope that will be sufficent and try it out tomorrow. I am a bit afraid of trouble caused by the frame number skipping values with the upper incrementation logic. With kind regards, Sebastian Stumpf -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastian.stumpf87 at googlemail.com Tue Feb 28 17:29:23 2017 From: sebastian.stumpf87 at googlemail.com (Sebastian Stumpf) Date: Tue, 28 Feb 2017 17:29:23 -0000 Subject: Virtual layer 1 - Questions In-Reply-To: <20170223144124.mdba7w7avdujy23g@nataraja> References: <20170212230920.epvdsj7jwxzta23w@nataraja> <20170223144124.mdba7w7avdujy23g@nataraja> Message-ID: Hi Harald, here is an update on the virt-phy (and some more problems ;)). I implemented the simple scheduler and it seems to work fine. I was happy to find the assignment of channels to their respective frame in the mframe in https://github.com/osmocom/osmocom-bb/blob/master/src/target/firmware/layer1/mframe_sched.c#L67-L292 and used that to calculate the fn the messages should be scheduled in. Thanks to your suggestions I could also fix some errors and produced a new capture file. https://www.dropbox.com/s/145w5c5kqwlk5ey/mobile--ms-virt--bts-virt--bsc-nitb_170228%3Ahyperframe_fast_repeat_test.pcapng?dl=0 I come some steps further but are still having trouble to: Send an sms to myself using the extension assigned to my ms from osmo-nitb (see 2341 in cap-file). VTY: sms 1 12 "Hallo zusammen" OsmocomBB# % (MS 1) % SMS to 12 failed: Semantically Incorrect Message Call myself (11851 in cap file) VTY: OsmocomBB# call 1 12 OsmocomBB# % (MS 1) % Call has been released Losing RR connection after some time. LOG-mobile: Tue Feb 28 17:16:35 2017 DRR <0001> gsm48_rr.c:662 MON: no cell info LOG-virt-phy: Tue Feb 28 17:16:34 2017 DL1C Message incoming from layer 2: 0d 00 00 00 01 00 00 00 Tue Feb 28 17:16:34 2017 DL1C Received and handled from l23 - L1CTL_RESET_REQ (type=FULL) Tue Feb 28 17:16:34 2017 DL1C Sending to l23 - L1CTL_RESET_CONF (reset_type: 1) Tue Feb 28 17:16:34 2017 DL1C Message incoming from layer 2: 08 00 00 00 01 00 00 00 00 00 00 7c Tue Feb 28 17:16:34 2017 DL1C Received from l23 - L1CTL_PM_REQ TYPE=1, FROM=0, TO=124 Tue Feb 28 17:16:34 2017 DL1C Message incoming from layer 2: 08 00 00 00 01 00 00 00 00 80 00 fb Tue Feb 28 17:16:34 2017 DL1C Received from l23 - L1CTL_PM_REQ TYPE=1, FROM=128, TO=251 Tue Feb 28 17:16:34 2017 DL1C Message incoming from layer 2: 08 00 00 00 01 00 00 00 02 00 02 99 Tue Feb 28 17:16:34 2017 DL1C Received from l23 - L1CTL_PM_REQ TYPE=1, FROM=512, TO=665 Tue Feb 28 17:16:34 2017 DL1C Message incoming from layer 2: 08 00 00 00 01 00 00 00 02 9b 03 75 Tue Feb 28 17:16:34 2017 DL1C Received from l23 - L1CTL_PM_REQ TYPE=1, FROM=667, TO=885 Tue Feb 28 17:16:34 2017 DL1C Message incoming from layer 2: 08 00 00 00 01 00 00 00 03 bb 03 ff Tue Feb 28 17:16:34 2017 DL1C Received from l23 - L1CTL_PM_REQ TYPE=1, FROM=955, TO=1023 Tue Feb 28 17:16:34 2017 DL1C Message incoming from layer 2: 08 00 00 00 01 00 00 00 82 00 83 2a Tue Feb 28 17:16:34 2017 DL1C Received from l23 - L1CTL_PM_REQ TYPE=1, FROM=33280, TO=33578 Tue Feb 28 17:16:34 2017 DL1C Message incoming from layer 2: 0d 00 00 00 01 00 00 00 Tue Feb 28 17:16:34 2017 DL1C Received and handled from l23 - L1CTL_RESET_REQ (type=FULL) Tue Feb 28 17:16:34 2017 DL1C Sending to l23 - L1CTL_RESET_CONF (reset_type: 1) Tue Feb 28 17:16:34 2017 DL1C Message incoming from layer 2: 01 00 00 00 83 2a 00 64 27 10 03 20 03 07 00 00 3f Tue Feb 28 17:16:34 2017 DL1C Received and handled from l23 - L1CTL_FBSB_REQ (arfcn=33578, flags=0x7) What I do not understand here is why I get a full power measurement request from mobile although I did set a fixed arfcn in the config. And of course a fbsb req for arfcn 33578 seems simply wrong... Next step after fixing the false fbsb request from l23 would be to add a second mobile and then try to get the mobile originated call to work. Of course i would be happy about other suggestions :). With kind regards, Sebastian Stumpf -------------- next part -------------- An HTML attachment was scrubbed... URL: