baseband-devel

baseband-devel@lists.osmocom.org

2 participants
2003 discussions

OsmoDevCon 2018 schedule planning
by Harald Welte 06 Dec '17

06 Dec '17

Dear Osmocom Community, [please respect the Reply-To and post all follow-up discussion to this to openbsc(a)lists.osmocom.org, so we avoid having long threads cross-posted to several mailing lists.] Like every year in early December, it is time to discuss as schedule for OsmoDevCon in the upcoming year. Note: Ths is about OsmoDevCon, the more private meeting of developers, *NOT* about OsmoCon, the public conference. == When, Who, Where == I propose the following date for OsmoDevCon 2018: April 20 - April 23rd, 2018 * Who: Active developers/contributors of Osmocom projects (as usual) * Where: IN-Berlin, Berlin (as usual) Please let me know ASAP if that proposed date works for everyone who'd want to attend. We can still change it now, but I would want to nail down the date pretty soon. == Format == After the experiment of reducing from 4 to 3 days last year (due to OsmoCon), we will again go for *four days* in 2018. However, we should clearly divide the days in a way that e.g. "GSM/3G" topics are on two days, while SDR+Other topics are on the other days, so people not interested in some topics can skip one or two days, as needed. We could even divide it further like: * 1 day 3GPP RAN (osmo-bts, osmo-bsc, osmo-pcu, virt_phy, fake_trx, ...) * 1 day 3GPP CN (osmo-msc, osmo-hlr, osmo-sip-connector, nextepc, etc.) * 2 days misc Regards, and looking forward to meeting you [again] in 2018, 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)

1 1

Re: Classmark Testing
by Vadim Yanitskiy 06 Dec '17

06 Dec '17

Hi Sebastian, > My query is : my test network is supporting A5/1,2,3. Is it feasible to > set A5/1 on MS1 (though it supports A5/2 and A5/3 also) and A5/2 for MS2 > (though it supports A5/1 and A5/3 also) for a call in between them using > "Early Classmark Sending" ??? I think it will work without any problems because the A5/X encryption is not 'end-to-end' (in our case MS-to-MS), but there are two separate encrypted sessions between MS1-BTS and MS2-BTS. With best regards, Vadim Yanitskiy.

2 1

Classmark Testing
by f12.sebastian 06 Dec '17

06 Dec '17

Hi I am trying to test osmocom-bb/fixeria-Trx. After configuring test-sim the functions for receiver side like the " network selection mode " " select ARFCN" do work. But how to test or configure " Early Classmark Sending" for varying set of encryption (A5/1,2,3,4...). Regards. --

4 4

Re: Classmark Testing
by Vadim Yanitskiy 06 Dec '17

06 Dec '17

Hi Max, This work is a part of "GSM and GPRS Security Using OsmocomBB" thesis written by Francois Ponsgen and was published a quite time ago. Moreover, I already have the changes in my local repo, which is mostly used for research purposes. I can push them, if it's really required. BTW: if I remember correctly, this work was done in NTNU ;) With best regards, Vadim Yanitskiy.

2 1

[PATCH] mtk: fix firmware makefile to work with current osmocom-bb makefile system
by Craig Comstock 06 Dec '17

06 Dec '17

--- src/target/firmware/Makefile.mtk | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/src/target/firmware/Makefile.mtk b/src/target/firmware/Makefile.mtk index 30fa2fcf..927e31a0 100644 --- a/src/target/firmware/Makefile.mtk +++ b/src/target/firmware/Makefile.mtk @@ -4,14 +4,16 @@ BOARDS?=mt62xx # List of all applications (meant to be overridden on command line) APPLICATIONS?=loader_mtk -mtkram_LDS=board/mediatek/ram.lds -mtkram_OBJS=board/mediatek/start.ram.o +APP_loader_mtk_ENVIRONMENTS=mtkram + +ENV_mtkram_LDS=board/mediatek/ram.lds +ENV_mtkram_OBJS=board/mediatek/start.ram.o mtk_COMMON_OBJS=board/mediatek/uart.o # Mediatek MT62xx -mt62xx_OBJS=$(mtk_COMMON_OBJS) board/mt62xx/init.o -mt62xx_ENVIRONMENTS=mtkram +BOARD_mt62xx_OBJS=$(mtk_COMMON_OBJS) board/mt62xx/init.o +BOARD_mt62xx_ENVIRONMENTS=mtkram # Global include path INCLUDES=-Iinclude/ -I../../../include -I../../shared/libosmocore/include -- 2.15.0

1 0

GAPK status update
by Vadim Yanitskiy 03 Dec '17

03 Dec '17

Dear Osmocom community, I have been working on GAPK (GSM Audio Packet Knife) for some time, and now I would like to share some achievements. Previously GAPK was represented as a single binary that could be called with some command line arguments in order to perform required operations. This is only handy for humans, but not for other programs, which may also need to perform some format / codec conversations or audio capture / playback. One of such programs is the mobile from OsmocomBB project. Currently, when you're making a voice call, both audio capture and playback are only possible on the L1 side, i.e. on a Calypso based phone. Of course, the audio stream can be redirected via MNCC socket, but this is not what a regular OsmocomBB user would like to do. Moreover, there is a lack of AMR codec support. Also, there is another GNURadio based project named GR-GSM. In short, this is a set of blocks for GSM signal reception, demodulation and further processing. At the moment, one has TCH Full Rate decoding capabilities only. Audio playback is not supported yet. Having these projects in my mind, I have got an idea of creating a shared library from the GAPK source code. And, a few days ago I was managed to get the audio playback working in OsmocomBB. I hope, this library will be also usable for other projects. Brief list of changes were made: - Composed a shared library named libosmogapk - All exposed symbols have got an 'osmo_gapk' prefix - Added a pkg-config manifest and a symbol export map - Integrated the Osmocom logging framework - Benchmarking is now disabled by default - Processing queue now based on the linuxlist - Fixed program exit due to ALSA buffer underrun - Fixed ALSA audio playback from file - Old gapk application was renamed to 'osmo-gapk' and linked against the library - Adjusted verbosity level (normal / debug) - Fixed I/O combinations (ALSA, RTP, file...) check All changes could be found at the fixeria/lib branch of GAPK. I hope to see them merged, and open for discussions ;) With best regards, Vadim Yanitskiy.

2 4

Osmocon failed to flash
by felangga＠gmail.com 03 Dec '17

03 Dec '17

Hello, I'm newbie and want to learn about osmocombb. I already compiled all of the programs, but when I try to upload helloworld program, it stuck on this error $ host/osmocon/osmocon -p /dev/ttyUSB0 -m c123xor target/firmware/board/ compal_e88/hello_world.compalram.bin -c got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: f7 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 72 r got 2 bytes from modem, data looks like: 82 bf .. got 1 bytes from modem, data looks like: 7d } got 1 bytes from modem, data looks like: fd . got 1 bytes from modem, data looks like: 7f . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: a6 . got 1 bytes from modem, data looks like: 51 Q got 1 bytes from modem, data looks like: d2 . got 1 bytes from modem, data looks like: 51 Q got 1 bytes from modem, data looks like: 0a . got 1 bytes from modem, data looks like: 3a : got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 4d M got 1 bytes from modem, data looks like: a3 . got 1 bytes from modem, data looks like: a3 . got 1 bytes from modem, data looks like: da . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . I don't know if it hardware problem, or software problem. When I try to debug using putty to listen to /dev/ttyUSB0 there is no fmttool erro just like this article said http://www.linuxx.eu/2014/09/osmocombb-hardware-and-software-setup.html Regards.

5 6

State of primitives and lua bindings
by Holger Freyther 29 Nov '17

29 Nov '17

Hey, I think I have the minimal patchset to add primitives and lua bindings to have useful functionality and know what is good/bad with it and extend/iterate it from here. I would like to share the state and what's next. On the higher level we have: * Primitive for timers * Primitives OP_IND for started/shutdown handling * Primitives OP_IND for SMS status and RX SMS * Primitives OP_IND for Mobility Management state changes Next steps: * Pack MNCC and enable/handle voice calls as well to do call control. What needs to change in future iterations: * SMS, MM, started/shutdown indications should be async. Especially for MM handling that will do further state changes from within the new_mm_state. So if we enable/disable the MS within this callback we ask for trouble. * The lua scripting code is calling some routines directly. E.g. for a "simple" SMS sending routine, to query state. This should probably be converted to primitives as well. But that can be done while keeping the lua API (e.g. with continuations or cache the MS status). * Finish the OsmocomBB manual documentation for the API * Bikeshed. Number vs. Bool... ;) Bugs found by scripting: * I found an ASAN issue in mobile (fix pending) * Noticed paging with outdated TMSI on NITB * Trying to encode an alphabetic phone number causes issue in libosmocore (bug report pending) cheers holger Examples: # Print through logging framework print("Hello from Lua"); log_notice("Notice from lua"); log_debug("Debug from Lua"); log_error("Error from Lua"); log_fatal("Fatal from Lua"); # Start a timer... and cancel it. Notice the ':' local timer = osmo.timeout(1000, function() print("After timeout!!!") end) timer:cancel() # Access a osmo.ms() singleton table/object print("MS", type(osmo.ms())); osmo.ms():imsi() osmo.ms():imei() osmo.ms():shutdown_state() osmo.ms():started() osmo.ms():sms_send_simple("1234", "21321324", "fooooooo", 23) osmo.ms():start() osmo.ms():shutdown(force) # Callbacks... function ms_started_cb(started) end function ms_shutdown_cb(old_state, new_state) end function sms_cb(sms, cause, valid) for i, v in pairs(sms) do print(i, v) end end function mm_cb(new_state, new_substate, old_substate) if new_state == 19 and new_substate == 1 then osmo.ms():sms_send_simple("1234", "21321324", "fooooooo", 23) end end local cbs = { Started=ms_started_cb, Shutdown=ms_shutdown_cb, Sms=sms_cb, Mm=mm_cb } osmo.ms():register(cbs)

1 0

Re: OsmocomBB layer1 with FreeCalypso changes
by Vadim Yanitskiy 28 Nov '17

28 Nov '17

Hi Mychaela, Great work! I just had a quick look and did some tests. Do you agree if I would merge your changes to the mainstream under GNU GPL version 2 license, keeping you as the author? With best regards, Vadim Yanitskiy.

3 4

primitives without msgb
by Holger Freyther 27 Nov '17

27 Nov '17

Hi, while I am adding scripting support to the mobile application I tried using a primitive interface between the scripting implementation and the mobile application. On new indications a callback in the primitive interface user will be invoked and there is a generic submit function that will dispatch (switch/case) over the primitive and call the right internal functions. To prototype this I have implemented "timer" support, SMS and the started/shutdown handling through primitives. The neat thing about this approach is that I don't tie a specific scripting solution into the code, the indications are generic enough to be useful in multiple contexts, the submit/dispatch is about high level operations ("send SMS", "switch device off") that map to other programming languages as well. E.g. it is easy to imagine that one writes a TCP/IP adapter to send these primitives to another process/application. The controversial part is that this code is not using a msgb. Normally the primitive header is inside a msgb and then more or less points to itself. But in the scripting layer case the "timer", "new sms", "network selection" are already fully parsed objects (or where never parsed from a network representation) so are normally not located in a msgb in any form. One option is not to bother and deal with the primitive header just being embedded in another structure. The concept of request/response/indication is bigger than network messages. The other is to create a dummy msgb to obey the interface and follow the existing users but I am not sure what we would gain. For XYZ->internal we can use direct function calls and avoid the indirection of the primitives and for indications either call directly into the scripting code or create a script_indications struct and put it into the struct osmocom_ms. Only downside that doing RPC requires more work? So far I only forsee a single "script_indications" callback. comments? opinions? holger

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel