baseband-devel

baseband-devel@lists.osmocom.org

2022 discussions

strange crashes in current main branch
by Tim Ehlers 22 Jan '13

22 Jan '13

Hi, I already mentioned a strange behavior, sometimes when running osmocom for a few days. I think this is a different issue, because it happens more frequently and the situation is a bit different. This problem does not occur with a binary from june 2012. So it has to be some change between june and now. But now the problem: When running a phone with the main branch (only tested), it sometime come to the situation that the phone says "connection pending" and is not reacting anymore. osmocon only logs periodically this line: TOA AVG is not 16 qbits, correcting (got 15) And mobile says: <0003> gsm322.c:474 Sync to ARFCN=694(DCS) rxlev=-80 (No sysinfo yet, ccch mode NONE) <000e> gsm48_mm.c:353 Periodic location update <0005> gsm48_mm.c:355 timer T3212 (periodic loc. upd. delay) has fired <0005> gsm48_mm.c:4338 (ms 1) Received 'MM_EVENT_TIMEOUT_T3212' event in state MM IDLE, normal service <000e> gsm48_mm.c:2222 Perform location update (MCC 262, MNC 07 LAC 0x27e9) <0005> gsm48_mm.c:2356 LOCATION UPDATING REQUEST <0005> gsm48_mm.c:2378 using LAI (mcc 262 mnc 07 lac 0x27e9) <0005> gsm48_mm.c:2386 using TMSI 0xXXXXXXXX <0005> gsm48_mm.c:917 new state MM IDLE, normal service -> wait for RR connection (location updating) <0001> gsm48_rr.c:5575 (ms 1) Message 'RR_EST_REQ' received in state idle (sapi 0) <000e> gsm48_rr.c:1352 Establish radio link due to mobility management request <0003> gsm322.c:4049 (ms 1) Event 'EVENT_LEAVE_IDLE' for Cell selection in state 'C3 camped normally' <0003> gsm322.c:829 new state 'C3 camped normally' -> 'connected mode 1' <0003> gsm322.c:3665 Going to camping (normal) ARFCN 664(DCS). <0003> gsm322.c:452 Sync to ARFCN=664(DCS), but there is a sync already pending <0001> gsm48_rr.c:355 new state idle -> connection pending <0001> gsm48_rr.c:1504 CHANNEL REQUEST: 00 (Location Update no NECI) Mobile says nothing when shutting the phone off or on: OsmocomBB(ms)#shutdown OsmocomBB(ms)# OsmocomBB(ms)#no shutdown OsmocomBB(ms)# Only logs: <0005> gsm48_mm.c:4342 (ms 1) Received 'MM_EVENT_IMSI_DETACH' event in state wait for RR connection (location updating) <0005> gsm48_mm.c:1992 IMSI detach delayed. Killing and restarting mobile leads to: eeepc:~ # mobile -i 127.0.0.1 Copyright (C) 2008-2010 ... Contributions by ... License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. <000f> sim.c:1223 init SIM client <0006> gsm48_cc.c:63 init Call Control <0007> gsm480_ss.c:231 init SS <0017> gsm411_sms.c:63 init SMS <0001> gsm48_rr.c:5626 init Radio Ressource process <0005> gsm48_mm.c:1327 init Mobility Management process <0005> gsm48_mm.c:1040 Selecting PLMN SEARCH state, because no SIM. <0002> gsm322.c:5037 init PLMN process <0003> gsm322.c:5038 init Cell Selection process <0003> gsm322.c:5095 Read stored BA list (mcc=262 mnc=01 Germany, T-Mobile) <0003> gsm322.c:5095 Read stored BA list (mcc=262 mnc=07 Germany, O2) Mobile '1' initialized, please start phone now! VTY available on port 4247. And layer1 still logs some: TOA AVG is not 16 qbits, correcting (got 15) TOA AVG is not 16 qbits, correcting (got 15) TOA AVG is not 16 qbits, correcting (got 15) Has anybody a clue how this could happen from time to time? Cheers Tim

1 1

What's the difference between the hello_world.e88flash.bin and hello_world.compalram.bin
by qiuhan1989 22 Jan '13

22 Jan '13

As said in the topic, I don't know what is the difference between the two .bin file. And when I try the osmocon app, only the hello_world.compalram.bin works, why? Thanks in advance. -- View this message in context: http://baseband-devel.722152.n3.nabble.com/What-s-the-difference-between-th… Sent from the baseband-devel mailing list archive at Nabble.com.

3 3

sylvain/testing: apps/trx/trx.c: inttypes.h:No such file or directory
by Erich Dachleger 21 Jan '13

21 Jan '13

Hi list, Yesterday when I tried to to make a new build of sylvain/testing I encountered following errors when running make(and also when running make HOST_layer23_CONFARGS=--enable-transceiver): -------------------------------------- make -C target/firmware CROSS_COMPILE=arm-elf- make[1]: Entering directory `/root/osmocom-bb/src/target/firmware' apps/trx/trx.c:22:22: inttypes.h: No such file or directory make[1]: Leaving directory `/root/osmocom-bb/src/target/firmware' make[1]: Entering directory `/root/osmocom-bb/src/target/firmware' apps/trx/trx.c:22:22: inttypes.h: No such file or directory make[1]: *** No rule to make target `apps/trx/trx.p', needed by `all'. Stop. make[1]: Leaving directory `/root/osmocom-bb/src/target/firmware' make: *** [firmware] Error 2 ------------------------------------------- Master branch builds fine on backtrack 5 r2 and so did also Sylvain/testing earlier. Searching mailing-list gives some info that removing inttypes.h can be done as that "is taken care of by upstrean libosmocore".However I have read that inntypes.h should exist. I tested and removed inttypes.h in trx/trx.c. Recompiling gives an error message about parse error before debug-message PRIu32 on line 69 in trx/trx.c. Commenting out that line makes it build, but as info obtained earlier I now guess I have also removed some key-functionality and my approach is wrong? Further searching gave some unclear/vague(mostly for other situations) hints that the line #include <inttypes.h> could be replaced by: #ifdef HAVE_STDINT_H #include <stdint.h> #else #include <include <inttypes.h> #endif I tested replacing #include <inttypes.h> by the abovein trx.c also but it didn't work. Any ideas or hints what migh be wrong? Enclosed is the full build-error-log from running without making any changes to inttypes.h. Regards erich

2 4

Jan 23, 8pm / Osmocom Berlin User Group meeting
by Harald Welte 21 Jan '13

21 Jan '13

Hi all! This is the announcement for the latest incarnation of our bi-weekly Osmocom Berlin meeting. January 23, 8pm @ CCC Berlin, Marienstr. 11, 10113 Berlin There is no formal presentation scheduled for this meeting. However, we'll have a progress report + demonstration of current osmo-pcu. If you are interested to show up, feel free to do so. The meeting is free as in "free beer", despite no actual free beer being around ;) 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)

1 0

gsm450 in belgium
by g.roelant＠telenet.be 21 Jan '13

21 Jan '13

Hi, Does anyone know if gsm450 is encrypted with A5/1? and who is using gsm450 in belgium I can see signals on my ettus + external ant. there... kind regards

3 2

Filter Modification
by Akib Sayyed 19 Jan '13

19 Jan '13

Dear List I tried to modify filter of osmocom c118 but i found that its not getting signals. loosing all signalls and showing all on 115dbm to 120dbm. what could have gone wrong ?? -- Akib Sayyed Matrix-Shell akibsayyed(a)gmail.com akibsayyed(a)matrixshell.com Mob:- +91-966-514-2243

2 1

tranceiver support for osmo-bts
by Andreas Eversberg 19 Jan '13

19 Jan '13

hi, i would like to start implementing the trx manager interface support to osmo-bts. before going to work, i'm writing this mail, because i like to read some pros and cons for my approach. as already stated, thomas a. cooper already implemented an interface between sysmo-bts's dsp device and trx manager interface by using code from openbts, running in an own process [1]. i would like to follow a different approach by writing a scheduler and adding the udp interface for the trx(s). some benefits are in my oppinion: - not having an extra process running with additional latency and overhead - smaller code, because only a small multiframe scheduler + udp interface for the trx is required (coding scheme and forward error correction code can be used from libosmocore.) - no running after dsp's api changes, (caused by newer firmware of sysmobts) - trx specific features and limitations can be considered. (vty options for setting special features, limitations can affect oml ack/nack responses to be considered by bsc) - no use of multithreading, use of talloc. the code is easier to debug and so becomes more stable. - easy to add initial support for BCCH(+SDCCH4), SDCCH8, TCH/F, TCH/H, PDCH (gprs) for a whide range of applications. comments are welcome. regards, andreas [1] http://scholar.lib.vt.edu/theses/available/etd-05082012-141540/unrestricted…

3 4

drawing of state machines
by Andreas Eversberg 19 Jan '13

19 Jan '13

hi, while reading about SMS state machines, i found some drawings that are not in the specs, but quite useful to understand some processes. they are: - MM idle process (MS side) - additions to CC (MS side) - SMC process (MS and network side) see http://home.eversberg.eu/gsm they might be useful and so i think they should be placed in the wiki. i would suggest to put them to OsmocomBB wiki in the "GSM Documentation" section. but i don't know if it is ok to publish the CC process, because it contains a scan of the original spec. any suggestions? regards, andreas

5 8

[PATCH] Improve hex parser
by ☎ 16 Jan '13

16 Jan '13

Hello. Current implementation of osmo_hexparse have couple of limitations (which are undocumented btw): * it refuses to parse odd-length numbers (e. g. 7abdf) * it fails while parsing 0x prefix (e. g. 0xdead) Both could be worked around by upper-layer code of course but since both cases above are perfectly valid hexadecimal numbers I think they should be handled by osmo_hexparse internally without complicating life of library users. Attached patch does just that. Please review and merge if it feels OK. -- best regards, Max, http://fairwaves.ru

3 6

osmocombb: TS 3 -> TS failed
by jolly 15 Jan '13

15 Jan '13

hi, i just encountered the following problem: the network assigns me from TS 1 to TS 3 it worked, but not when it did another assigment from TS 3 to TS4. i just got noise instead of valid SACCH frames. TS Chg forth: 1 -> 3 | 1856 ... TS Chg forth: 3 -> 4 | 1875 this is the wireshark trace of both assignments. they only differ in the assigned slot: Frame 3225: 81 bytes on wire (648 bits), 81 bytes captured (648 bits) Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00) Internet Protocol Version 4, Src: 127.0.0.1 (127.0.0.1), Dst: 127.0.0.1 (127.0.0.1) User Datagram Protocol, Src Port: 52261 (52261), Dst Port: gsmtap (4729) GSM TAP Header, ARFCN: 34 (Downlink), TS: 1, Channel: SDCCH/8 (0) Link Access Procedure, Channel Dm (LAPDm) GSM A-I/F DTAP - Assignment Command Protocol Discriminator: Radio Resources Management messages DTAP Radio Resources Management Message Type: Assignment Command (0x2e) Channel Description 2 - Description of the First Channel, after time 0000 1... = TCH/F + FACCH/F and SACCH/F .... .011 = Timeslot: 3 000. .... = Training Sequence: 0 ...1 .... = Hopping channel: Yes Hopping channel: MAIO 0 Hopping channel: HSN 0 Power Command 0... .... = Spare: 0 .0.. .... = EPC_mode: Channel(s) not in EPC mode ..0. .... = FPC_EPC: FPC not in use/C not in use for uplink power control ...0 0101 = POWER LEVEL: 5 Frequency List - Frequency List, after time Element ID: 5 Length: 16 00.. 000. = Format Identifier: bit map 0 (0x00) List of ARFCNs = 99 34 Channel Mode - Mode of the First Channel(Channel Set 1) Element ID: 99 Channel Mode: speech full rate or half rate version 2(GSM EFR) (33) No. Time Source Destination Protocol Info 3243 464.672890 127.0.0.1 127.0.0.1 LAPDm I, N(R)=1, N(S)=2(DTAP) (RR) Assignment Command Frame 3243: 81 bytes on wire (648 bits), 81 bytes captured (648 bits) Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00) Internet Protocol Version 4, Src: 127.0.0.1 (127.0.0.1), Dst: 127.0.0.1 (127.0.0.1) User Datagram Protocol, Src Port: 52261 (52261), Dst Port: gsmtap (4729) GSM TAP Header, ARFCN: 99 (Downlink), TS: 3, Channel: FACCH/F (0) Link Access Procedure, Channel Dm (LAPDm) GSM A-I/F DTAP - Assignment Command Protocol Discriminator: Radio Resources Management messages DTAP Radio Resources Management Message Type: Assignment Command (0x2e) Channel Description 2 - Description of the First Channel, after time 0000 1... = TCH/F + FACCH/F and SACCH/F .... .100 = Timeslot: 4 000. .... = Training Sequence: 0 ...1 .... = Hopping channel: Yes Hopping channel: MAIO 0 Hopping channel: HSN 0 Power Command 0... .... = Spare: 0 .0.. .... = EPC_mode: Channel(s) not in EPC mode ..0. .... = FPC_EPC: FPC not in use/C not in use for uplink power control ...0 0101 = POWER LEVEL: 5 Frequency List - Frequency List, after time Element ID: 5 Length: 16 00.. 000. = Format Identifier: bit map 0 (0x00) List of ARFCNs = 99 34 Channel Mode - Mode of the First Channel(Channel Set 1) Element ID: 99 Channel Mode: speech full rate or half rate version 2(GSM EFR) (33) any idea why this does not work? i used the "[WIP] Ugly hack to compensate lost time on TS change (high TS -> low TS)" path. regards, andreas

3 2

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel