baseband-devel

baseband-devel@lists.osmocom.org

2022 discussions

libosmocom VERSION doesn't get set properly
by jakob borg 26 Oct '10

26 Oct '10

hi, when building libosmocom in osmocom-bb/src/shared (using the git-subtree script to keep everything up to date), the Makefile in src/shared/libosmocore/build-host doesn't have the version information set properly, instead i get: PACKAGE_VERSION = UNKNOWN VERSION = UNKNOWN this is causing problems compiling stuff that require libosmocom at a specific version, like some of the airprobe tools. i'm running mac os x 10.6.4, using autoconf 2.68, automake 1.11.1, binutils 2.20.1, gcc 4.5.1. when building the master git branch of libosmocom outside of osmocom-bb (bootstrapping using the bootstrap script from airprobe/gsm-receiver), the version gets set properly. thanks jakob -- jakob borg jakborg(a)fastmail.fm -- http://www.fastmail.fm - One of many happy users: http://www.fastmail.fm/docs/quotes.html

3 3

command line options for layer23 apps
by Andreas.Eversberg 26 Oct '10

26 Oct '10

hi, i like to change the handling of command line options in layer23 applications, because different layer23 applications require different individual options, and common options also. (e.g. the "mobile" application does not required "--arfcn" option, but "--vty-port". others do not require "--vty-port", but might require a "--gps-device". all apps together require "--socket" and "--gsmtap-ip".) therefore i like to leave all common options in common/main.c. additional options i like to put in the individual app_*.c files. each options i like to check at the individual app file. if it doesn't exist there, the main.c checks if the option is a common option: ... c = l23_app_handle_options(); if (c == -1) c = getopt_long(argc, argv, "hs:S:a:i:v:d:", long_options, &option_index); if (c == -1) break; ... an individual help for each application: l23_app_print_help(); any suggestions or complains? best regards, andreas

3 4

AW: LAPDm bug: How to exit LAPDm_STATE_TIMER_RECOV state
by Andreas.Eversberg 25 Oct '10

25 Oct '10

>> you are right. in case of an RR "response" (or an I frame) with the F >> bit set to "1", there is no clearing of the "timer recovery state". in >> other cases (RNR, REJ) it is handled. > Where did you see that an I-Frame with the F bit set should clear the > condition ? you are right. i searched through the document. the I-Frame is handled during "timer recovery state", but this state is not cleared then. anyway: i am missing the description for "Receiving RR frames". A general description for RR, RNR, REJ is given in 5.5.3, but it does not describe what todo on a valid RR response with F bit set to "1". this is why i missed it.

1 0

AW: LAPDm bug: How to exit LAPDm_STATE_TIMER_RECOV state
by Andreas.Eversberg 25 Oct '10

25 Oct '10

> The timer recovery condition is only cleared if the data link layer > entity receives a valid supervisory frame response > with the F bit set to "1". If the N(R) of this received supervisory > frame is within the range from its current state variable > V(A) to its current send state variable V(S) inclusive, it shall set > its send state variable V(S) to the value of the received > N(R). Timer T200 shall be reset if the received supervisory frame > response is an RR or REJ response with F bit set to > "1". The data link layer entity shall then resume with I frame > transmission or retransmission, as appropriate. > Timer T200 shall be set if the received supervisory response is an RNR > response, and the data link layer shall proceed > with the enquiry process in accordance with subclause 5.5.5. hi sylvain, you are right. in case of an RR "response" (or an I frame) with the F bit set to "1", there is no clearing of the "timer recovery state". in other cases (RNR, REJ) it is handled. i would like to test this with a prepared frame drop tonight. if this works, i will commit it. regards, andreas

2 1

Switching to TCH
by Sylvain Munaut 24 Oct '10

24 Oct '10

> but when i doing so , it is chasing up to SDCCH , and after this it is > started to dropping frames .. and not getting tune to any TCH/F Have you even _read_ the code of layer23 ... it _will_ not do what you want directly. It's a starting point, but you're gonna have to learn to write things by yourself. > though there is no encryption being used. A5/0, i have seen , no ciphering. > in traces. Well it's a perfectly normal behavior that after some time you only see lost frames. I suggest you re-read the code and the specs until you understand _why_ it's normal. > kindly confirm with layer1.compalram.bin , if i will be able to listen > TCH/F assign to some other MS , Not out of the box, as I said, you will need to do some programming. Given the question you ask, you obviously don't understand GSM or the code enough yet to do it. Cheers, Sylvain PS: Please don't hijack a thread that has nothing to do with what you're writing about by just clicking the reply button and not even bothering to change the subject ... seems like you need to read the emails RFC as well ...

2 1

LAPDm bug: How to exit LAPDm_STATE_TIMER_RECOV state
by Sylvain Munaut 24 Oct '10

24 Oct '10

Hi, In GSM 05.06 Section 5.5.7 at the end it says : --- The timer recovery condition is only cleared if the data link layer entity receives a valid supervisory frame response with the F bit set to "1". If the N(R) of this received supervisory frame is within the range from its current state variable V(A) to its current send state variable V(S) inclusive, it shall set its send state variable V(S) to the value of the received N(R). Timer T200 shall be reset if the received supervisory frame response is an RR or REJ response with F bit set to "1". The data link layer entity shall then resume with I frame transmission or retransmission, as appropriate. Timer T200 shall be set if the received supervisory response is an RNR response, and the data link layer shall proceed with the enquiry process in accordance with subclause 5.5.5. --- And I don't see where this is supposed to be handled in the code. I tried this quick fix: diff --git a/src/host/layer23/src/common/lapdm.c b/src/host/layer23/src/common/lapdm.c index b1c0d40..8bd42a7 100644 --- a/src/host/layer23/src/common/lapdm.c +++ b/src/host/layer23/src/common/lapdm.c @@ -1081,8 +1081,12 @@ static int lapdm_rx_s(struct msgb *msg, struct lapdm_msg_ctx *mctx) /* 5.4.2.2: Inidcate error on supervisory reponse F=1 */ if (LAPDm_ADDR_CR(mctx->addr) == CR_BS2MS_RESP && LAPDm_CTRL_PF_BIT(mctx->ctrl)) { - LOGP(DLAPDM, LOGL_NOTICE, "S frame response with F=1 error\n"); - rsl_rll_error(RLL_CAUSE_UNSOL_SPRV_RESP, mctx); + if (dl->state != LAPDm_STATE_TIMER_RECOV) { + LOGP(DLAPDM, LOGL_NOTICE, "S frame response with F=1 error\n"); + rsl_rll_error(RLL_CAUSE_UNSOL_SPRV_RESP, mctx); + } else { + dl->state = LAPDm_STATE_MF_EST; + } } switch (dl->state) { which seems to fix the issue I encountered but my understanding of how lapdm.c works is very limited and I doubt that it's all that's needed to properly handle this case. Cheers, Sylvain Munaut

2 1

cross-compiling osmocom on mac os x
by jakob borg 24 Oct '10

24 Oct '10

hi, i'm struggling to get a working cross-compile toolchain for osmocom-bb on os x, i've been playing with a script called summon-arm-toolchain (http://github.com/esden/summon-arm-toolchain) for a while now without success, my toolchain seems to build fine, but when trying to compile for my target, i get: checking for arm-elf-linux-gcc... arm-elf-gcc checking whether the C compiler works... no config.log says: configure:3106: checking whether the C compiler works configure:3128: arm-elf-gcc -Os -ffunction-sections -I../../../../target/firmware/include conftest.c >&5 /usr/local/arm-elf/lib/gcc/arm-elf/4.5.1/../../../../arm-elf/lib/libc.a(lib_a-exit.o): In function `exit': /usr/local/src/summon-arm-toolchain/build/arm-elf/newlib/libc/stdlib/../../../../../newlib-1.18.0/newlib/libc/stdlib/exit.c:65: undefined reference to `_exit' collect2: ld returned 1 exit status i'm running mac os x 10.6.4, using autoconf 2.68, automake 1.11.1, binutils 2.20.1, gcc 4.5.1. any idea what i might be doing wrong? has anybody successfully cross-compiled the arm part of osmocom-bb on osx? thanks jakob -- jakob borg jakborg(a)fastmail.fm -- http://www.fastmail.fm - Faster than the air-speed velocity of an unladen european swallow

2 1

DSP TCH task : time to get/put FAACH
by Sylvain Munaut 22 Oct '10

22 Oct '10

Hi Dieter, Hi everyone, (cc'd the list, for the record and if other people are interested in the inner workings :) I'm pretty satisfied with the current state of the TCH primitive (as it is in my testing branch now). But there is still two things I'm stumbling upon: * When to put / read data for FACCH. Getting downlink FACCH blocks looks quite logic: just check the B_BLUD bit on the TCH response of the last burst of the block. So with rx_time being the time at which the burst was received (i.e., one frame before the response is executed) - For TCH/F: (rx_time.fn % 13) % 4 == 3 - For TCH/H: (rx_time.t2 - subchannel) in {6,15,23} But for when to load the next FACCH block, it seems weird. From what I understand of what you did and what the TSM30 does, you need to load the data on the TCH cmd corresponding to the bursts _before_ the first burst. So with tx_time being the time at which the burst will transmitted (i.e., one frame after the command is executed = l1s.next_time) - For TCH/F (tx_time.fn % 13) % 4 == 3 - For TCH/H (tx_time.t2 - subchannel) in {6,15,23} (2 TDMA before the first burst because on TCH/H, we're executed one once every two frame) Why the need to load it one burst in advance ? (while on the RX side, which seems more complex to do, data is available directly after the last burst is received). * TCH/H support: AFAIK, I did everything that should be required for it to work: - set fn_report properly for TCH/H - set chan_type to TCH_H in dsp_load_tch_parameters - Use a different condition for when to put/read FACCH bursts (according to 05.02) - Schedule the TCH task appropriately ... But still can't get it to work (testing with the racal). SACCH seems to work fine (I see the SI messages), but I don't see a single FACCH message (and eventually the racal says T3107 expired, assignement to TCH failed). Do you see anything else that would be required ? Cheers, Sylvain

1 1

TCH.. OsmocomBB
by Marten Christophe 21 Oct '10

21 Oct '10

Hello Deiter ,Sylvian As u advised I completed reading GSM standard, and dig down source code AFAIK , i have recognized the files and parameters where i need to change values to tune for particular TCH, and also understood that how important signaling is to be involved . I just want to know one thing that is , during the channel request MS send burst on RACH with RA ref number, where this RAF or RA reference number stored on MS side , because when Immediate assignment send from the network it must be match before tuning to particular SDCCH, i want to apply a trick here i will copy the RA reference from the immediate assignment message and will replace with original one stored in MS, hence MS will think this channel is for me and tune to the SDCCH accordingly, further it will keep on listening all process like authentication, location updating , again the TCH channel information is send SDCCH without encryption as only authentication procedure needs Kc Ki and SRES, SDCCH is not encrypted and all MS hosting on that SDCCH can decode TCH parameter like FN , TS, ARFCN hopping sequence. but again i need to clarify how L1ctl.c and L23_api.c fetch the decoded data, from immediate assinment masseg. as it is written printf..........%u . From where this will scan or fetch. if i will be able to know, where MS kept stored the input values advised in signaling messages by BTS on PCH, or AGCH. so i can manipulate them and land on CCCH, and then SDCCH then TCH. kindly tell me if it is feasible , or there is more i need to think. Kind Regards,

2 1

Re: osmocom on windows
by Dieter Spaar 21 Oct '10

21 Oct '10

Hello Peter, On Thu, 7 Oct 2010 11:54:28 +0200, "Peter Stuge" <peter(a)stuge.se> wrote: > > Does e.g. the CodeSourcery toolchain really need Cygwin? That would > suck. I don't know CodeSourcery, I use GNU ARM directly from www.gnuarm.com. According to the CodeSourcery FAQ, they do not require Cygwin. Are there any benefit using CodeSourcery ? I had issues in the past with the firmware using a different GNU ARM version, so I switched back to 4.0.2 which seems to be the same other use on Linux and so far it works OK. You don't seem to like Cygwin, my experience with it is not that bad, OpenBSC (not with GPRS yet due to the need for the TUN device), OsmocomBB, GNUradio and Airprobe run with minor adjustments (just to name GSM related stuff I use under Cygwin). Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

4 4

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel