July 2016 - OpenBSC - lists.osmocom.org

Re: Profiling data of decoding EPDAN compressed bitmap

by Holger Freyther

> On 13 Jul 2016, at 12:21, Max <msuraev(a)sysmocom.de> wrote: > Hi all, > After looking at the code, I don't think reusing table implementation > would be easy - the approaches are too different as well as underlying > data structures. okay. then we will need to use the tree based version and from my point of view we should do it the following way: * Remove osmo_t4_decode (and related routines) from libosmocore (last step) * Make the tree based decoder ready in terms of the surrounding style * Adopt/Clone the osmo_t4_decode tests and move them to the PCU (as part of the commit that adds the decoder to the PCU) @Me: After the infrastructure is in the PCU I will remove osmo_t4_decode (and tests) from libosmocore @Radisys: I am afraid the tree based decoding is not ready yet and as it impacts the upcoming encoder (and other RLE code as far as I understand) let me put it here. In osmo-pcu (and all other projects) we use libtalloc for memory allocations. This means the tree should use talloc with proper parent/child allocations. This way the destructor of the decoder will also free all nodes of the tree. There should be no call to malloc/free in the PCU. Please take the tests from libosmocore and make sure they work with the new decoder. Tests are the lifeline and we need more and not less of them. The decoder needs to be robust against invalid input. search_runlen can fail but the caller doesn't check for that. Please test with invalid/truncated or broken inputs to see we don't end in a never terminating while loop. Test using unit tests. Similar the current osmo_t4_decode can return an error that is propagated back to the compressed bitmap decoding and we should have the same. Reduce code duplication. With the decoder the only difference between the if/else is if the data is filled with 0x00 or 0xFF and which table/root to use. Instead of having code clones please parameterize either by having local variables in the beginning or by calling different (inline) functions. kind regards holger

7 years, 5 months

1
1
0 0

Moving from trac to a single redmine

by Holger Freyther

Hi guys, I think some of us would like to move to redmine and start using public tickets more frequently. So in case we move there are some topics to be discussed and I would like to start with a couple of them right now. Tickets: Redmine has a global linear sequence of ticket numbers. If we move from many tracs to a single redmine we can either: * not import tickets * only import from one project * deal with changing ticket numbers In terms of installations the GMR trac is broken in regard to tickets, there are some for SDR that are probably not being fixed anytime soon, baseband might be relevant and OpenBSC is unlikely to be relevant. I don't think we have ever used ticket reference in OpenBSC commit messages so in terms of OpenBSC having changing ticket numbers would not be a big deal. E.g. we could add a custom field with the old trac number? Wiki: We have external references that should be redirected to the new place. Is there any way besides maintaining a list in the apache2/nginx configuration and making redirects as we find broken references? Can we proactively manage this? Is anybody willing to come up with a script and nginx configuration for doing this? kind regards holger

7 years, 6 months

6
15
0 0

SS MM Messages (Call forwarding etc)

by Keith Whyte

Hi All, A few weeks ago, I wrote to the list about a handset that was opening and holding an lchan after doing IMSI attach. After some investigation I see this phone is querying the network for call forwarding status. This phone then cannot send any more USSD codes, or make calls, although it can receive, but for some reason insists on doing the query again after call termination. Doing the same from other handsets, by dialling such codes as *#21# in each case gives the same result of eternal lchan usage, although some (more modern) phones seem to eventually timeout, releasing the channel while others do not. I connected numerous phones and did the same on each one and pretty soon I have a kind of DOS situation on the network in that SDCCH is at capacity. The last log message resulting from the request is /openbsc/openbsc/src/libmsc/gsm_04_08.c:3586 Dispatching 04.08 message, pdisc=11 although strangely with one phone, this is followed shortly by: libosmocore/src/gsm/gsm0480.c:219 USSD Request is too short. openbsc/openbsc/src/libmsc/ussd.c:55 Unhandled SS so for that one phone, it would seem handle_rcv_ussd() is being called from gsm0408_dispatch() I have been going through the code, basically adding more debug output to try to verify what is being called from where, and I also found the functionality in libosmocore such as gsm0480_decode_ss_request(), although this is not called at anytime from the nitb. This is an enormous project! I notice these lines in openbsc/openbsc/src/linmsc/gsm_04_08.c in gsm48_rx_mm_serv_req() /* we will send a MM message soon */ conn->expire_timer_stopped = 1; It would seem that we don't ever send this MM message. It's not clear to me where I might try to check again on the status of this MM request, or if the problem is a lack of full implementation of these supplementary service requests. Would anybody be interested in working on this with me? Keith.

7 years, 8 months

2
5
0 0

[PATCH] remove INSTALL file to have a clean git status

by Neels Hofmeyr

From: Neels Hofmeyr <neels(a)hofmeyr.de> The INSTALL file is being overwritten by autoreconf, but it is committed as empty file. As a result, the INSTALL file always shows as modified. Instead, remove INSTALL from git and ignore it. --- .gitignore | 1 + INSTALL | 0 2 files changed, 1 insertion(+) delete mode 100644 INSTALL diff --git a/.gitignore b/.gitignore index e15c19b..d1a0b33 100644 --- a/.gitignore +++ b/.gitignore @@ -39,6 +39,7 @@ libtool ltmain.sh missing stamp-h1 +INSTALL # vim *.sw? diff --git a/INSTALL b/INSTALL deleted file mode 100644 index e69de29..0000000 -- 2.1.4

7 years, 8 months

3
4
0 0

signal quality measurements in osmo-trx

by Max

Hi. I'm working on http://projects.osmocom.org/issues/1616 and wonder about $subj. In case of sysmobts, osmo-pcu obtain this data directly from DSP: * RSSI (dBm) * burst timing (in quarter of bits) * link quality (in dB) * BER The first and last value seems to be easy from what I see in src/osmo-bts-trx/scheduler_trx.c What about burst timing (necessary to compute TA in the absence of PTCCH) and link quality (measure of C / I where C is carrier and I is interference power) - how can I compute those or some estimator to those values? -- Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

7 years, 8 months

4
5
0 0

Re: OsmoNITB + Asterisk

by Anonim Stefan

Hi, Is there any intention / interest among current community developers to implement the DTMF for osmo sip connector?! Thanks, Stefan On Jul 27, 2016 3:33 PM, "Holger Freyther" <holger(a)freyther.de> wrote: > On 27 Jul 2016, at 20:19, Brian Butterly <bbutterly(a)ernw.de> wrote: > > Hi, Hi! > has anyone recently put together a functional setup with OsmoNITB and > Asterisk (+LCR)? why asterisk? why LCR? The osmo-sip-connector is a "trivial" piece of software that bridges MNCC to SIP (and back) and let's everyone else do the heavy lifting. In contrast to LCR it currently lacks: * Multi-party calls (a bit harder) * DTMF (quite easy but not done) holger

7 years, 8 months

2
1
0 0

OsmoNITB + Asterisk

by Brian Butterly

Hi, has anyone recently put together a functional setup with OsmoNITB and Asterisk (+LCR)? I've got multiple errors while compiling LCR with Asterisk, mainly unknown definitions and a set of missing functions. My setup: -NanoBTS -current OpenBSC (running perfectly) -Ubuntu Xenial, 64Bit, VBox VM -current LCR from Osmocom Repos -Asterisk (build without any issues) --1.8.32.3 from Asterisk Page --1.6.2.24 from Asterisk Page --11.32.0 form Asterisk Page --last 13.x release vie apt I had expected the newer versions to be incompatible, still gave them a shot anyways. I've started fiddling with LCR, but before I go deeper into that, I just wanted to check if there was some defined approach which would get everything up and running. I'd be very thankful for any hint or maybe some information on which versions of what will actually work together. Thanks! Brian

7 years, 8 months

2
2
0 0

dyn TS tweaks and fixes

by Neels Hofmeyr

Hi all, I have some patches that probably fix some corner cases of dynamic pchan switching. However, since I'm technically already in vacation, I will only be able to properly test them in about 10 days' time. If they should become interesting before that, the changes are pushed to branches called neels/dyn_fixes in openbsc and osmo-bts. ~Neels -- - Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Harald Welte

7 years, 8 months

1
0
0 0

osmo-bts: rach_ind.ra size

by Neels Hofmeyr

I just came across this compiler warning: l1sap.c: In function 'gsmtap_ph_rach': l1sap.c:291:8: warning: assignment from incompatible pointer type [enabled by default] *data = &l1sap->u.rach_ind.ra; ^ It's a uint16_t ra and used like this in common/l1sap.c: static int gsmtap_ph_rach(struct osmo_phsap_prim *l1sap, uint8_t *chan_type, uint8_t *tn, uint8_t *ss, uint32_t *fn, uint8_t **data, int *len) { [...] *data = &l1sap->u.rach_ind.ra; *len = 1; A cast like this would fix the compiler warning and make sense if data is interpreted to point at a 16 bit data block, probably in host byte order though: *data = (uint8_t*)&l1sap->u.rach_ind.ra; *len = 1; But *len = 1 means that **data is an 8bit value? This is sent to gsmtap. Is *len = 1 something we should fix? ~Neels -- - Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Harald Welte

7 years, 8 months

3
4
0 0

New subscriber not created automatically with accept-all/subscriber-create-on-demand configuration

by Shaddi Hasan

Hi folks, I'm seeing some unexpected behavior from OsmoNITB. I am running from the Debian 8 nightly builds from July 25 for everything. My OpenBSC configuration is set as follows: network [...] auth policy accept-all [...] nitb subscriber-create-on-demand assign-tmsi [...] When a new phone tries to camp to the network, it's rejected as follows: https://gist.github.com/shaddi/7674680c329f14c0042fbeca5227962e ("Failed to find subscriber"). My full openbsc.cfg is in that gist as well. If I create the subscriber by IMSI via the VTY though, it camps fine and everything else works as expected. When I tested this this configuration a few weeks ago with an earlier build (sorry, can't recall which one), adding the subscriber manually wasn't necessary, and with the configuration above seems like it also shouldn't be necessary. Couple questions: - Is this the expected behavior for this configuration? - If so, is there currently a way to achieve the prior behavior (subscriber created automatically when a new phone tries to camp, rather than being rejected)? Thanks, Shaddi

7 years, 8 months

2
2
0 0

HEADS UP: openbsc.git: force push on master

by Neels Hofmeyr

Today, gerrit has merged four of my changesets twice for some reason (even though they had the very same Change-Id), meaning that openbsc.git master got four empty commits. It could end up being a stupid thing to do, but I thought if at all then right now and no later: I forced master HEAD back so that we don't have empty commits in it, back to d1c0e3755f2832270a16bdb2d350463409cad887. I apologize in advance for any inconvenience caused. If you need help to recover from a diverged master branch, don't hesitate to ask! ~Neels -- - Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Harald Welte

7 years, 8 months

1
1
0 0

NITB hangs if many subscribes and/or subsr. exists with empty extension in hlr

by Keith

Hi All, On one of our sites osmo-nitb was hanging a few seconds after startup. It took me a while to track it down, and I'm sorry I do not have log output as it has gone to scroll buffer heaven, and I do not want to break the system again right now to get another output, but I can say more or less what happens. If I see it again, I'll be sure to capture full debug log. I also have a backup of the state of the offending hlr, so I can bring it up locally and see if I can replicate and send the log. In fact, there was nothing out of the ordinary in the log anyway before nitb simply stops responding. (CTRL-C still shuts down cleanly if would seem) This 'bad' hlr has some 30,815 subscriber entries, one of them has empty string for extension. (We normally never get to anything near 30,000 as we purge inactive subscribers regularly, but the blank extension had broken our purge job) On this blank extension issue, i'm not sure it coincides with the hang, but I noted this error followed by DBI traceback from here: http://git.osmocom.org/openbsc/tree/openbsc/src/libmsc/db.c#n54 Error was non unique value for column extension, which makes sense of course, as we don't give it a value. Also seems we don't recover from this, as |db_subscriber_alloc_exten() will never be called? | I deleted some 28,000 subscriber entries that were not commissioned users, and the nitb then functions, so I'm at a loss to know where it might have been actually stuck, or if it might be related to the blank extension, or to the large amount of subscriber entries, or something else. Maybe it's obvious to somebody. I have of course deleted the blank extension entry now from the hlr. Thanks! Keith.

7 years, 8 months

2
1
0 0

openbsc build broken due to new GSM_PCHAN value

by Neels Hofmeyr

Just to let you know, the addition of GSM_PCHAN_TCH_F_TCH_H_PDCH in libosmocore implicitly broke the ctrl interface tests in openbsc. FAIL: testBtsChannelLoad (__main__.TestCtrlBSC) ---------------------------------------------------------------------- Traceback (most recent call last): File "./ctrl_test_runner.py", line 237, in testBtsChannelLoad self.assertEquals(r['value'], 'CCCH+SDCCH4,0,0 TCH/F,0,0 TCH/H,0,0 SDCCH8,0,0 TCH/F_PDCH,0,0 CCCH+SDCCH4+CBCH,0,0 SDCCH8+CBCH,0,0') AssertionError: 'CCCH+SDCCH4,0,0 TCH/F,0,0 TCH/H,0,0 SDCCH8,0,0 TCH/F_PDCH,0,0 CCCH+SDCCH4+CBCH,0,0 SDCCH8+CBCH,0,0 unknown 0xb,0,0' != 'CCCH+SDCCH4,0,0 TCH/F,0,0 TCH/H,0,0 SDCCH8,0,0 TCH/F_PDCH,0,0 CCCH+SDCCH4+CBCH,0,0 SDCCH8+CBCH,0,0' because this is unexpected output: "unknown 0xb,0,0" So *any* commit submitted to openbsc will currenty fail. I'll probably fix it shortly with a commit to openbsc... This also directed my attention towards the pchan_load mechanics. It always shows a TCH/F_PDCH entry, but in PDCH mode those would not have any load. I guess it makes sense in the current scheme of things, though it could make even more sense to record channel load not as separate TCH/F_PDCH but in the TCH/F slot, depending on current pchan mode? Similarly for upcoming TCH/F_TCH/H_PDCH: record in the TCH/F or TCH/H slot according to current pchan mode... (For now I'm focusing on completion of TCH/F_TCH/H_PDCH usability, if at all pchan_load tweaks would come later) ~Neels -- - Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Harald Welte

7 years, 8 months

2
3
0 0

gerrit: permission to submit

by Neels Hofmeyr

I've added permission to submit a reviewed patch to the known users group, re: On Sun, Jul 24, 2016 at 04:08:35PM +0000, lynxis lazus wrote: > @Holger: I'm not allowed to do so on gerrit. On Mon, Jul 25, 2016 at 08:08:00AM +0000, Tom Tsou wrote: > Holger, Gerrit does not allow me to submit. ~Neels -- - Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Harald Welte

7 years, 8 months

1
0
0 0

Looking for trace with GPRS XID / SNDCP-CID messages

by Philipp Maier

Hi Folks, I am busy with implementing XID / SNDCP-XID parameter negotiation to use data and header compression with GPRS. It would be very helpful to have an example at hand that shows me how an SNDCP-XID is performed in real life. If someone of you has a GB-Interface trace at hand it would be very helpful for me. regards. Philipp

7 years, 8 months

1
0
0 0

Re:Need Help In installing openBSC for establishing GSM network with EDGE support

by ayush gupta

Hello everyone, i am noob to this field and currently trying to establishing a GSM network with EDGE support using this page as guide http://openbsc.osmocom.org/trac/wiki/Ettus_USRP_B2xx_family#no1 i am stuck at this command sudo osmo-nitb -C -c openbsc.conf -T -P -m its giving me following error There is no such command. Error occurred during reading below line: extension-prefix 0 % 'dtx-used' is now deprecated: use dtx * configuration options of BTS instead Fri Jul 15 05:35:26 2016 <0005> bsc_init.c:492 Failed to parse the config file: '/home/ryker/openbsc.conf' any help would be highly appreciated thanks

7 years, 9 months

5
4
0 0

TCH_H and TCH_F

by Neels Hofmeyr

I have this problem: DCC <0001> gsm_04_08.c:1649 Cannot patch through call with different channel types: local = TCH_F, remote = TCH_H (At first I thought it was a bug in dynamic TCH_F/TCH_H/PDCH, but it's actually about any situation where both TCH/H and TCH/F are available. Tested with master:) If I configure the BSC to have both TCH_H and TCH_F slots, my two test phones try to call each other with mismatching TCH types. The CHANNEL REQUIRED messages send TCH/H and TCH/F, respectively. phones: Samsung S4 vs. Sony Ericsson SE K800i. If the CN is configured with only TCH/H or only TCH/F, the two phones talk to each other fine. So is this a missing feature in openbsc? In this sense: If one side started off in TCH/H, the other side should be urged towards TCH/H as well. This breaks the dynamic TS feature #1776: with fully dynamic TS, we're implicitly allowing both TCH/H and TCH/F, so if an MS asks for a TCH/F, it will get one before even considering a TCH/H, even if that mismatches the MS peer. So we should fix openbsc to "clamp" the callee to the caller's pchan type. We could also offer a limited TCH/H_PDCH type (or some other config to disable TCH/F on dyn TS, for example). ~Neels -- - Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Harald Welte

7 years, 9 months

1
1
0 0

Re: PDTCH and PTCCH activation

by Harald Welte

Hi Neels, [posting to the openbsc mailing list, as this discussion is not GPRS related] On Thu, Jul 21, 2016 at 12:25:25PM +0200, Neels Hofmeyr wrote: > On Wed, Jul 20, 2016 at 06:50:24PM +0200, Max wrote: > > It's called from lchan_act_compl_cb() via sapi_queue_send() which is > > also in mph_send_activate_req() - I have hard time understanding how > > this works at all. Do we have this documented somewhere? > > Both the TCH/F_TCH/H_PDCH timeslot feature and the TCH/F_PDCH on osmo-trx > are stuck on some post-lchan_act_compl SAPI stuff. can you be more specific about what "stuff"? It's hard to be of assistance without details. Also, SAPIs exist completely separately on every SAP, such as the (M)PH-SAP of the physical layer and the (M)DL-SAP of LAPDm, wich is implemented via RSL. So it is useful to explicitly state which SAP we are talking about when mentioning "SAPI stuff". > So, I would also benefit from better understanding the actions after > lchan_act. I actually think the L1 SAPI activation/deactivation is rather simple. You have the tables that list the SAPI+Direction combinations needed for every lchan type (what I just quoted for PDCH in my recent mail), and then the code iterates over the list of SAPI+Direction at time of lchan activation or deactivation. > Apparently related: libosmocore/gsm/lapd*.c How are the SAPIs of the data link layer should be related to SAPIs of the physical layer? LAPDm is establishing reliable channels over the already established physical layer, and LAPDm is not by iself activating/deactivating any channels, i.e. not talking to the MPH-SAP. -- - 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)

7 years, 9 months

2
5
0 0

range error in RSL_CHAN_SDCCH4_ACCH + lchan_nr?

by Neels Hofmeyr

Yesterday I came across gsm_ts2chan_nr() in openbsc gsm_data_shared.c (which is used both in openbsc and osmo-bts). IIUC this case would expect lchan_nr to be in the range 0..3: case GSM_PCHAN_CCCH_SDCCH4: case GSM_PCHAN_CCCH_SDCCH4_CBCH: cbits = 0x04; cbits += lchan_nr; break; Because if we'd add 4 or more, we would be walking into this cbits space: case GSM_PCHAN_SDCCH8_SACCH8C: case GSM_PCHAN_SDCCH8_SACCH8C_CBCH: cbits = 0x08; cbits += lchan_nr; break; The thing is, I added an assert for lchan_nr < 4, and it hits. We're actually passing lchan_nr == 4 and thus use cbits = 0x08 for a GSM_PCHAN_CCCH_SDCCH4: wrong. This code in osmo-bts-*/oml.c:opstart_compl() activates lchan[4] of a CCCH+SDCCH4 ts: /* ugly hack to auto-activate all SAPIs for the BCCH/CCCH on TS0 */ if (mo->obj_class == NM_OC_CHANNEL && mo->obj_inst.trx_nr == 0 && mo->obj_inst.ts_nr == 0) { struct gsm_lchan *cbch = gsm_bts_get_cbch(mo->bts); DEBUGP(DL1C, "====> trying to activate lchans of BCCH\n"); mo->bts->c0->ts[0].lchan[4].rel_act_kind = LCHAN_REL_ACT_OML; lchan_activate(&mo->bts->c0->ts[0].lchan[4]); if (cbch) { cbch->rel_act_kind = LCHAN_REL_ACT_OML; lchan_activate(cbch); } } This [4] the first SDCCH4, because this has CCCH in the first [0..3], right? But then we should use lchan->nr - 4 to add to the cbits, right? It seems pretty much everyone, our code and various BTS models, are ignoring the erratic cbits, but would be good to fix. My SysmoBTS GSM cell still works if I pass cbits = 0x04 instead of 0x08, like this: case GSM_PCHAN_CCCH_SDCCH4: case GSM_PCHAN_CCCH_SDCCH4_CBCH: /* SDCCH4 is in lchan_nr 4..7, so subtract 4 before adding to * the cbits. */ if (lchan_nr >= 4) lchan_nr -= 4; OSMO_ASSERT(lchan_nr < 4); cbits = 0x04; cbits += lchan_nr; However, I guess passing 0x04 cbits for a CCCH lchan is wrong as well (0x04 is RSL_CHAN_SDCCH4_ACCH). Instead, we should pass RSL_CHAN_RACH (Uplink CCCH) or RSL_CHAN_PCH_AGCH (Downlink CCCH), right? How to decide which of the two? Thanks for any hints, ~Neels [[[ [...] <0001> oml.c:830 OC=CHANNEL(03) INST=(00,00,00) Rx OPSTART <0006> oml.c:500 (bts=0,trx=0,ts=0,ss=0) pchan=CCCH+SDCCH4 ts_connect_as(CCCH+SDCCH4) logChComb=4 ^ SDCCH4 <0007> l1_if.c:164 Tx L1 prim MPH-CONNECT.req <0001> oml.c:249 OC=CHANNEL INST=(00,00,00) AVAIL STATE Dependency -> OK <0001> oml.c:256 OC=CHANNEL INST=(00,00,00) OPER STATE Disabled -> Enabled <0001> oml.c:217 OC=CHANNEL INST=(00,00,00) Tx STATE CHG REP <0006> oml.c:285 ====> trying to activate lchans of BCCH <0006> lchan.c:31 (bts=0,trx=0,ts=0,ss=4) state NONE -> ACTIVATION REQUESTED ^ ss=4 means lchan->nr=4 <0006> oml.c:1040 (bts=0,trx=0,ts=0,ss=4) MPH-ACTIVATE.req (hL2=0x000004bb, FCCH TxDL) <0007> l1_if.c:164 Tx L1 prim MPH-ACTIVATE.req <0006> oml.c:777 (bts=0,trx=0,ts=0,ss=4) MPH-ACTIVATE.conf (FCCH TxDL) <0006> oml.c:783 Successful activation of L1 SAPI FCCH on TS 0 <0006> oml.c:1040 (bts=0,trx=0,ts=0,ss=4) MPH-ACTIVATE.req (hL2=0x000004bb, SCH TxDL) <0007> l1_if.c:164 Tx L1 prim MPH-ACTIVATE.req <0006> oml.c:777 (bts=0,trx=0,ts=0,ss=4) MPH-ACTIVATE.conf (SCH TxDL) <0006> oml.c:783 Successful activation of L1 SAPI SCH on TS 0 <0006> oml.c:1040 (bts=0,trx=0,ts=0,ss=4) MPH-ACTIVATE.req (hL2=0x000004bb, BCCH TxDL) <0007> l1_if.c:164 Tx L1 prim MPH-ACTIVATE.req <0006> oml.c:777 (bts=0,trx=0,ts=0,ss=4) MPH-ACTIVATE.conf (BCCH TxDL) <0006> oml.c:783 Successful activation of L1 SAPI BCCH on TS 0 <0006> oml.c:1040 (bts=0,trx=0,ts=0,ss=4) MPH-ACTIVATE.req (hL2=0x000004bb, AGCH TxDL) <0007> l1_if.c:164 Tx L1 prim MPH-ACTIVATE.req <0006> oml.c:777 (bts=0,trx=0,ts=0,ss=4) MPH-ACTIVATE.conf (AGCH TxDL) <0006> oml.c:783 Successful activation of L1 SAPI AGCH on TS 0 <0006> oml.c:1040 (bts=0,trx=0,ts=0,ss=4) MPH-ACTIVATE.req (hL2=0x000004bb, PCH TxDL) <0007> l1_if.c:164 Tx L1 prim MPH-ACTIVATE.req <0006> oml.c:777 (bts=0,trx=0,ts=0,ss=4) MPH-ACTIVATE.conf (PCH TxDL) <0006> oml.c:783 Successful activation of L1 SAPI PCH on TS 0 <0006> oml.c:1040 (bts=0,trx=0,ts=0,ss=4) MPH-ACTIVATE.req (hL2=0x000004bb, RACH RxUL) <0007> l1_if.c:164 Tx L1 prim MPH-ACTIVATE.req <0006> oml.c:777 (bts=0,trx=0,ts=0,ss=4) MPH-ACTIVATE.conf (RACH RxUL) <0006> oml.c:783 Successful activation of L1 SAPI RACH on TS 0 <0006> lchan.c:31 (bts=0,trx=0,ts=0,ss=4) state ACTIVATION REQUESTED -> ACTIVE Assert failed lchan_nr < 4 gsm_data_shared.c:518 ^ from mph_info_chan_confirm(), lchan_nr == 4 (gdb) bt #0 0x47d47208 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x47d4ad8c in __GI_abort () at abort.c:89 #2 0x000186e4 in gsm_ts2chan_nr (ts=<optimized out>, lchan_nr=<optimized out>) at ../../../openbsc/openbsc/src/libcommon/gsm_data_shared.c:518 #3 0x00018710 in gsm_lchan2chan_nr (lchan=lchan@entry=0xb6d5b000) at ../../../openbsc/openbsc/src/libcommon/gsm_data_shared.c:540 #4 0x0000eb0c in mph_info_chan_confirm (lchan=0xb6d5b000, lchan@entry=0xb6d283c8, type=type@entry=PRIM_INFO_ACTIVATE, cause=cause@entry=0 '\000') at oml.c:56 #5 0x00010730 in sapi_activate_cb (lchan=0xb6d283c8, status=0) at oml.c:1080 #6 0x000108d4 in sapi_queue_dispatch (lchan=0x1, lchan@entry=0xb6d283c8, status=<optimized out>) at oml.c:729 #7 0x00010c2c in lchan_act_compl_cb (trx=<optimized out>, l1_msg=l1_msg@entry=0x4f850, data=<optimized out>) at oml.c:814 #8 0x0000da2c in l1if_handle_l1prim (wq=<optimized out>, fl1h=0xafdc0, msg=msg@entry=0x4f850) at l1_if.c:1037 ]]] -- - Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Harald Welte

7 years, 9 months

2
1
0 0

jenkins matrix + --enable-iu

by Neels Hofmeyr

Hi list, I've got a jenkins job ready that adds --enable-iu to the openbsc build matrix. I'd like to verify with you guys: so far we had a build matrix of 2 x 2, so openbsc and all its dependencies are built four times over (~22 min). Adding --enable-iu doubles this matrix to eight times. This means that any new commit would take about 55 min to verify with jenkins, even if it is just a comment tweak. I assume we want to bring this time down a bit? I'd have these suggestions: (1) Just add --enable-iu, let jenkins build for hours and proliferate global warming, and care about this once it actually bugs us. (2) Limit the build matrix: Only build --enable-iu once, e.g. with --enable-smpp and --enable-mgcp-transcoding, not with all of the other combinations. (Would --disable-mgcp make more sense?) (3) Don't build all of the dependencies over and over. In pseudo sort of: dep_hashes = "" for dep in libosmo*: dep_hashes += "," + dep.get_current_git_hash() if dep.last_hashes == dep_hashes: dep."make install" continue dep.wipe_out() dep."autoreconf; configure; make check; make install" cat dep_hashes > "${dep.dir}/last_hashes" That would shorten the build time substantially, and we could keep the build matrix fully featured without taking too much time. I've so far spent 5 minutes on implementing something like this and could polish that up, maybe using a global dependencies workspace somewhere else on the build slave so the separate matrix items benefit from each other. But do we like that? I would consider re-using previous builds safe enough for our jenkins verifier, since all deps would be rebuilt even if only one dep's git hash changes; assuming that it *works*, of course. Do you guys agree? http://jenkins.osmocom.org/jenkins/job/OpenBSC-gerrit-test/ openbsc.git branches osmocom/jenkins-test and neels/speed_up_matrix_builds Thanks for your opinions! ~Neels -- - Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Harald Welte

7 years, 9 months

2
1
0 0

Problem with running omso-nitb

by Gof .

Hello all, I am playing around with osmocom now for more then 2 years. i pretty much seen every possible error's when compiling and building stuff but i always used OpenBTS for running my network, but now a couple months back i wanted to try and do the same thing using openbsc I got most off the tools working on a Debian 8.5, but when i try to run osmo-nitb -c ~/.osmocom/open-bsc.cfg i get the an error Aborted since there is no more information about the error i can't seem to figure out what is wrong maybe something to do with ipaccess?Did anyone else also came up to this problem ?I tried many many times with a fresh installOn Ubuntu 12.04Debian 8.5Kali linux 2016.1also with kali in a docker container i got pretty far with doing it in docker, and osmo-nitb worked, until i installed all the rest and then when i needed to run osmo-nitb i also got back the error Aborted when trying to run it Please help me out Thanks in advance Develectron

7 years, 9 months

3
2
0 0

Re: osmo-bts: Repository write acces / Gerrit migration

by Neels Hofmeyr

On Wed, Jul 06, 2016 at 04:15:08PM +0300, Alexander Chemeris wrote: > Username: ipse > Full Name: Alexander Chemeris Misunderstanding: this is your osmocom.org redmine account. Please also register with gerrit.osmocom.org for commit access. You may do so using above osmocom.org account as OpenID provider: http://osmocom.org/projects/cellular-infrastructure/wiki/Gerrit#Configuring… ~Neels

7 years, 9 months

2
3
0 0

include grouping

by Neels Hofmeyr

Hi Max, in e.g. e6052c4cc756f7d3a5023a0ba57fe8d80783967c you have added #include <stdbool.h> in various files. I'd like to nitpick about the place where you put it: index 3cba5d1..3d7c244 100644 --- a/openbsc/include/openbsc/gsm_subscriber.h +++ b/openbsc/include/openbsc/gsm_subscriber.h @@ -5,6 +5,8 @@ #include <osmocom/core/linuxlist.h> #include <osmocom/gsm/protocol/gsm_23_003.h> +#include <stdbool.h> + (there are also some more instances) I'd prefer if we keep system headers grouped on top. Thanks :) ~Neels

7 years, 9 months

4
3
0 0

fully dynamic TS, naming

by Neels Hofmeyr

About http://osmocom.org/issues/1757#note-4 With the current naming scheme, the logical name for a fully dynamic TCH/F-TCH/H-PDCH channel would be GSM_PCHAN_TCH_F_TCH_H_PDCH timeslot 2 phys_chan_config TCH/F_TCH/H_PDCH Is it asking for trouble to just name it DYN instead? GSM_PCHAN_DYN timeslot 2 phys_chan_config DYN I'm in (at least) two minds about it, opinions welcome... ~Neels

7 years, 9 months

3
3
0 0

Full state machine implementation

by Sipos Csaba

Dear Harald, Just seen your branch regarding FSM: http://cgit.osmocom.org/openbsc/log/?h=laforge/om2000-fsm Do you think this is also doable for the Nokia Site BTS series? Because if you think its doable, based on your work I a would like to try and implement this for Nokia support too, as even between different Site versions (InSite, Metro and UltraStie), there are some differences in the OML initialization (especially in the timing of it) which is now handled by hard coded values, instead of a proper state machine. Regards, Csaba

7 years, 9 months

4
5
0 0

osmo-bts-trx: patch 498

by Neels Hofmeyr

Hi osmo-bts-trx folks, reviews on https://gerrit.osmocom.org/498 would be appreciated :) Thanks! ~Neels -- - Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Harald Welte

7 years, 9 months

1
0
0 0

Error compiling libosmocore under Mac Osx

by Juan Antonio Barea Lopez

Hello all, in order to try grgsm software, it asked for the libosmocore library and i proceed to configura and install it. Configure process went ok, but when trying to "make", it gets a error about unidentified symbols. I have been searching on the web and got several hints that it could be based on the 64bit version of gcc used. The error in question is this: **********Output error begins here********** /Applications/Xcode.app/Contents/Developer/usr/bin/make all-recursive Making all in include make[2]: Nothing to be done for `all'. Making all in src /Applications/Xcode.app/Contents/Developer/usr/bin/make all-am make[3]: Nothing to be done for `all-am'. Making all in src/vty make[2]: Nothing to be done for `all'. Making all in src/codec CCLD libosmocodec.la Undefined symbols for architecture x86_64: "_bitvec_get_bit_pos", referenced from: _osmo_fr_check_sid in gsm610.o "_bitvec_get_uint", referenced from: _osmo_hr_check_sid in gsm620.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[2]: *** [libosmocodec.la] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 *********End of output error************ I tried to also made a reconfigure -i but without success. Has anyone experienced this error or have an idea about what could be happening?. Thanks in advance!!!!

7 years, 9 months

3
2
0 0

GPRS on osmo-trx not working

by Neels Hofmeyr

Hi List, Voice is working well, but I can't seem to get GPRS working on osmo-trx. I used the standard debian 8.4 packages for UHD which seem to work, and documented that at http://osmocom.org/projects/osmotrx/wiki/OsmoTRX#Dependencies I also tried to use a PCU from before EDGE support was merged, so that's not causing it. Any ideas on what might be causing this? With sysmobts, for example, I needed to configure the pcu with --enable-sysmocom-dsp. Any such things with osmo-trx? I'm running both pcu and osmo-bts-trx as root with -r 1. Some of the log messages look quite bad, like 20160628170840743 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 I didn't do the rts-advance increase by 5, because when that log message is issued, the PCU is not running yet: 20160628170837632 DL1C <0006> scheduler.c:240 Prim for trx=0 ts=0 at fn=272652 is out of range, or channel already disabled. If this happens in conjunction with PCU, increase 'rts-advance' by 5. (current fn=272658) Below are some logs and attached are the config files. The identical setup is working for other BTS models, the osmo-bts.cfg is the only difference. Thanks for any hints! ~Neels TRX: linux; GNU C++ version 4.9.1; Boost_105500; UHD_003.007.003-0-unknown opening configuration table from path :memory: Config Settings Log Level............... NOTICE Device args............. TRX Base Port........... 5700 TRX Address............. 127.0.0.1 Channels................ 1 Tx Samples-per-Symbol... 4 Rx Samples-per-Symbol... 1 EDGE support............ Disabled External Reference...... Disabled C0 Filler Table......... Disabled Diversity............... Disabled Tuning offset........... 0 RSSI to dBm offset...... 0 Swap channels........... 0 -- Operating over USB 2. -- Initialize CODEC control... -- Initialize Radio control... -- Performing register loopback test... pass -- Performing register loopback test... pass -- Performing CODEC loopback test... pass -- Performing CODEC loopback test... pass -- Asking for clock rate 32.000000 MHz -- Actually got clock rate 32.000000 MHz -- Performing timer loopback test... pass -- Performing timer loopback test... pass -- Asking for clock rate 26.000000 MHz -- Actually got clock rate 26.000000 MHz -- Performing timer loopback test... pass -- Performing timer loopback test... pass -- Setting B210 4 SPS -- Transceiver active with 1 channel(s) NOTICE 140232141276928 17:27:18.0 Transceiver.cpp:241:start: Starting the transceiver NOTICE 140232141244160 17:27:18.5 Transceiver.cpp:380:pushRadioVector: dumping STALE burst in TRX->USRP interface ^ I see ~130 of these notices of a stale burst, but all with an identical timestamp, and only once after osmo-bts-trx starts up. PCU: 20160628170840742 DL1IF <0001> osmobts_sock.cpp:227 Opening OsmoPCU L1 interface to OsmoBTS 20160628170840742 DL1IF <0001> osmobts_sock.cpp:285 osmo-bts PCU socket has been connected 20160628170840742 DL1IF <0001> pcu_l1_if.cpp:359 BTS available 20160628170840742 DNS <0008> gprs_ns.c:233 NSVCI=65534 Creating NS-VC 20160628170840742 DNS <0008> gprs_ns.c:233 NSVCI=1800 Creating NS-VC 20160628170840742 DNS <0008> gprs_ns.c:1568 NSEI=1800 RESET procedure based on API request 20160628170840742 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170840742 DL1IF <0001> pcu_l1_if.cpp:83 Sending activate request: trx=0 ts=5 20160628170840743 DL1IF <0001> pcu_l1_if.cpp:486 PDCH: trx=0 ts=5 20160628170840743 DL1IF <0001> pcu_l1_if.cpp:83 Sending activate request: trx=0 ts=6 20160628170840743 DL1IF <0001> pcu_l1_if.cpp:486 PDCH: trx=0 ts=6 20160628170840743 DL1IF <0001> pcu_l1_if.cpp:83 Sending activate request: trx=0 ts=7 20160628170840743 DL1IF <0001> pcu_l1_if.cpp:486 PDCH: trx=0 ts=7 20160628170843743 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170846743 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170849743 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170852743 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170855743 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170858743 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170901743 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170904744 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170907744 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170910744 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170913744 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170916744 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170919744 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170922744 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170925745 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170928745 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170931745 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170934745 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170937745 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170940745 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170943746 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) SGSN: <0010> gprs_ns.c:233 NSVCI=65534 Creating NS-VC 20160628170817898 DGPRS <000f> sgsn_main.c:361 VTY at 127.0.0.1 4245 20160628170817898 DGPRS <000f> sgsn_main.c:370 CTRL at 127.0.0.1 4251 20160628170817898 DLGTP <0023> gtp.c:701 GTP: gtp_newgsn() started 20160628170840743 DNS <0010> gprs_ns.c:233 NSVCI=65535 Creating NS-VC 20160628170840743 DNS <0010> gprs_ns.c:1262 Creating NS-VC for BSS at 10.9.1.120:23000 20160628170840743 DNS <0010> gprs_ns.c:834 NSVCI=65535(invalid) Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170840743 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170840743 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170840743 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170843743 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170843743 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170843743 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170843743 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170846743 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170846743 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170846743 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170846743 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170847899 DGPRS <000f> gprs_sgsn.c:790 Checking for inactive LLMEs, time = 16442 20160628170849743 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170849743 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170849743 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170849743 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170852743 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170852743 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170852743 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170852743 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170855743 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170855743 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170855743 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170855743 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170858743 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170858743 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170858743 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170858743 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170901744 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170901744 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170901744 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170901744 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170904744 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170904744 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170904744 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170904744 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170907744 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170907744 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170907744 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170907744 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170910744 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170910744 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170910744 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170910744 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170913744 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170913744 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170913744 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170913744 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170916744 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170916744 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170916744 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170916744 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170917900 DGPRS <000f> gprs_sgsn.c:790 Checking for inactive LLMEs, time = 16472 20160628170919744 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170919744 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170919745 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170919745 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170922745 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170922745 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170922745 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170922745 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170925745 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170925745 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170925745 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170925745 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170928745 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170928745 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170928745 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170928745 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170931745 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170931745 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170931745 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170931745 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170934745 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170934745 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170934745 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170934745 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170937745 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170937745 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170937745 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170937745 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170940746 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170940746 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170940746 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170940746 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170943746 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170943746 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170943746 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170943746 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170946746 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170946746 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170946746 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170946746 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 osmo-bts-trx: [...] 20160628170836837 DOML <0001> oml.c:217 OC=CHANNEL INST=(00,00,06) Tx STATE CHG REP 20160628170836877 DOML <0001> oml.c:817 OC=CHANNEL INST=(00,00,07) SET CHAN ATTR (TSC = 7) 20160628170836877 DL1C <0006> scheduler.c:1273 Configuring multiframe with PDCH trx=0 ts=7 20160628170836877 DOML <0001> oml.c:884 ADM state already was Unlocked 20160628170836877 DOML <0001> oml.c:249 OC=CHANNEL INST=(00,00,07) AVAIL STATE Dependency -> OK 20160628170836877 DOML <0001> oml.c:256 OC=CHANNEL INST=(00,00,07) OPER STATE Disabled -> Enabled 20160628170836877 DPCU <0009> pcu_sock.c:627 PCU socket not connected, dropping message 20160628170836877 DOML <0001> oml.c:217 OC=CHANNEL INST=(00,00,07) Tx STATE CHG REP 20160628170836984 DL1C <0006> scheduler_trx.c:1433 GSM clock skew: old fn=272611, new fn=272536 20160628170837632 DL1C <0006> scheduler.c:240 Prim for trx=0 ts=0 at fn=272652 is out of range, or channel already disabled. If this happens in conjunction with PCU, increase 'rts-advance' by 5. (current fn=272658) 20160628170840742 DPCU <0009> pcu_sock.c:824 PCU socket connected to external PCU 20160628170840743 DL1C <0006> scheduler.c:1310 Activating PDTCH on trx=0 ts=5 20160628170840743 DL1C <0006> scheduler.c:1310 Activating PTCCH on trx=0 ts=5 20160628170840743 DRSL <0000> rsl.c:579 (bts=0,trx=0,ts=5,ss=0) not sending CHAN ACT ACK 20160628170840743 DL1C <0006> scheduler.c:1310 Activating PDTCH on trx=0 ts=6 20160628170840743 DL1C <0006> scheduler.c:1310 Activating PTCCH on trx=0 ts=6 20160628170840743 DRSL <0000> rsl.c:579 (bts=0,trx=0,ts=6,ss=0) not sending CHAN ACT ACK 20160628170840743 DL1C <0006> scheduler.c:1310 Activating PDTCH on trx=0 ts=7 20160628170840743 DL1C <0006> scheduler.c:1310 Activating PTCCH on trx=0 ts=7 20160628170840743 DRSL <0000> rsl.c:579 (bts=0,trx=0,ts=7,ss=0) not sending CHAN ACT ACK 20160628170857756 DL1C <0006> scheduler_trx.c:907 Received incomplete PDTCH block ending at fn=276994 (42/104) for PDTCH 20160628170857756 DL1C <0006> scheduler_trx.c:921 Received bad PDTCH block ending at fn=276994 (42/104) for PDTCH 20160628170940774 DL1C <0006> scheduler_trx.c:907 Received incomplete PDTCH block ending at fn=286315 (3/104) for PDTCH 20160628170940775 DL1C <0006> scheduler_trx.c:921 Received bad PDTCH block ending at fn=286315 (3/104) for PDTCH 20160628170945250 DL1C <0006> scheduler_trx.c:907 Received incomplete PDTCH block ending at fn=287285 (37/104) for PDTCH 20160628170945250 DL1C <0006> scheduler_trx.c:921 Received bad PDTCH block ending at fn=287285 (37/104) for PDTCH -- - Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Harald Welte

7 years, 9 months

3
9
0 0

merging iu specific branches to master

by Neels Hofmeyr

Hi 3G folks, I would like to make our osmocom jenkins build openbsc with --enable-iu, which still requires use of non-master branches in aper-prefix, libosmo-sccp and libosmo-netif. I will at first make the jenkins build use these branches to build 3G, but since we'd like them to be merged to master anyway, let's try to push this forward. Here are the remaining tasks again, as from the openbsc@ mail on Feb 19, 2016: http://lists.osmocom.org/pipermail/openbsc/2016-February/007906.html ( <20160219083519.GA4570@nataraja> ) First the good news for libosmo-sccp: On Fri, Feb 19, 2016 at 09:35:19AM +0100, Harald Welte wrote: > > libosmo-sccp: * laforge/wip > > My main problem with this patch set is naming. We are creating an 'SCCP > User SAP' which should look the same no matter what the underlying > transport protocol stacking is. [...] This boils down to a mere rename of opaque structs osmo_sua_link and osmo_sua_user, which I've started to submit. https://gerrit.osmocom.org/477 > > asn1c: * aper-prefix First of all, it looks like we imported from svn, but Lev Walkin later did another migration to git, which we fetched as well. So our master is on our old svn import, while the upstream master has different hashes in its history. Our aper-prefix branch is based on the upstream history, not our "stale" master, which made a rebase a bit easier. Furthermore, on https://github.com/vlm/asn1c/commits/master there are scores of new commits we don't have in our asn1c. our last commit from Lev Walkin is from 2015-04-28, "?= was confusing some environments", 62913d8b8e1eb96d74315ff I have thus: * fetched upstream master from github's vlm/asn1c, pushed as new branch vlm/master to our git.osmocom.org/asn1c * rebased our aper-prefix branch to that master (with minor conflicts), pushed as new branch aper-prefix-onto-upstream We should probably: * reset --hard our master to vlm/master * reset --hard our aper-prefix to aper-prefix-onto-upstream (after testing) Agreed? Then follows: On Fri, Feb 19, 2016 at 09:35:19AM +0100, Harald Welte wrote: > > If you look at the aper code I took from OpenAirInterface and re-based, For the record: https://gitlab.eurecom.fr/oai/openair-cn/tree/master/SRC/S1AP/MESSAGES/ASN1 https://gitlab.eurecom.fr/oai/openair-cn/blob/master/SRC/S1AP/MESSAGES/ASN1… https://gitlab.eurecom.fr/oai/openair-cn/blob/master/SRC/S1AP/MESSAGES/ASN1… > you will see that it does not look 100% complete and would > probably not yet qualify for submitting it to the upstream asn1c > project. The situation is not made better by my hackish way to > implement the type prefixing on top of it by means of an environment > variable. > > Specifically, it > * contains commented-out code which might just have been a work-around > of some buggy code, rather than fit for removal in general > * contains TODO comments like "/* TODO: act upon NOTE in #18.7 for > canonical PER */" which hints that it is not properly implementing > parts of the PER specification > * contrary to the rest of asn1c, it does not come with a comprehensive > test suiet for the APER encoding and decoding routines of all types > > Any help in cleaning this code up (it could be done for the type > prefixing independent of the APER support) would be much appreciated. > The goal is to get this merged in asn1c, after all. > > It might also be worth to contact the OpenAirInterface guys about their > thoughts on moving this code forward. I fear there might be none, as > they are using an ancient version of asn1c to begin with. But they are > a much larger project and might be convinced to put some resources on > doing this properly? I've written to the openair-cn-devel list. https://lists.eurecom.fr/sympa/arc/openaircn-devel/2016-07/msg00001.html > Unless we think something is ready for pushing to upstream asn1c, we > should keep it out of our local master, too. > > libosmo-netif: * sysmocom/sctp > > commit d484b0593112222cef3f106da654df07c3d40919 (hash changed after rebases) > basically just > prints some messages to the log file in case there are association state > changes like UP and LOST. This is clearly not the intended behavior. > > The application should be notified accordintly in such events, > particularly in 'connection lost' events that can be communicated in the > same way as they can for e.g. TCP sockets. > > Only after that is resolved, we can merge it to master. This doesn't look like a lot of work, though I'm not familiar with how exactly this should be done. ret = sctp_recvmsg(conn->ofd.fd, msgb_data(msg), msgb_tailroom(msg), NULL, NULL, &sinfo, &flags); if (flags & MSG_NOTIFICATION) { union sctp_notification *notif = (union sctp_notification *) msgb_data(msg); LOGP(DLINP, LOGL_DEBUG, "NOTIFICATION %u flags=0x%x\n", notif->sn_header.sn_type, switch (notif->sn_header.sn_type) { case SCTP_ASSOC_CHANGE: LOGP(DLINP, LOGL_DEBUG, "===> ASSOC CHANGE:"); switch (notif->sn_assoc_change.sac_state) { case SCTP_COMM_UP: LOGPC(DLINP, LOGL_DEBUG, " UP\n"); call accept_cb? break; case SCTP_COMM_LOST: LOGPC(DLINP, LOGL_DEBUG, " LOST\n"); osmo_stream_srv_destroy() ? break; case SCTP_RESTART: LOGPC(DLINP, LOGL_DEBUG, " RESTART\n"); break; case SCTP_SHUTDOWN_COMP: LOGPC(DLINP, LOGL_DEBUG, " SHUTDOWN COMP\n"); break; case SCTP_CANT_STR_ASSOC: LOGPC(DLINP, LOGL_DEBUG, " CANT STR ASSOC\n"); break; } break; case SCTP_PEER_ADDR_CHANGE: LOGP(DLINP, LOGL_DEBUG, "===> PEER ADDR CHANGE\n"); break; case SCTP_SHUTDOWN_EVENT: LOGP(DLINP, LOGL_DEBUG, "===> SHUTDOWN EVT\n"); /* Handle this like a regular disconnect */ osmo_stream_srv_destroy() ? return 0; break; } return -EAGAIN; Thanks for any thoughts or even help :) ~Neels -- - Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Harald Welte

7 years, 9 months

2
1
0 0

OsmoTRX / BER, RSSI and Link Quality

by Harald Welte

Hi Tom and List, we're currently introducing some code that will make more use of measurement related information associated with the PH-RACH.req and PH-DATA.ind coming from the PHY up into L2. The first part is to introduce a reasonable BER limit fo 17% for RACH ghost elimination, but I have more plans for unifying the measurement processing/generation accross all supported BTS models. For osmo-bts-{sysmo,lc15,octphy} it is clear to me how to get the related information on RSSI, BER and LinkQuality for each of the RACH and DATA indications from the PHY. However, how can I get the related information from osmo-bts-trx? osmo-bts-trx seems to lack any BER reporting toward the common part, which among other things is the reason why link/rate adaption in the PCU can not work with it. Could you sched some light on this? -- - 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)

7 years, 9 months

3
4
0 0

[PATCH 0/2] osmo-trx: add .gitignore, add a configure check

by Neels Hofmeyr

From: Neels Hofmeyr <neels(a)hofmeyr.de> Rebased the patches onto updated master, added a binary to .gitignore. Neels Hofmeyr (2): add basic .gitignore configure.ac: check for boost/config.hpp header .gitignore | 44 ++++++++++++++++++++++++++++++++++++++++++++ configure.ac | 3 +++ 2 files changed, 47 insertions(+) create mode 100644 .gitignore -- 2.1.4

7 years, 9 months

2
3
0 0

dynamic PDCH

by Neels Hofmeyr

> I am Tiger. Glad to connect with you.From osmo-bts commitment I see you are > working on dynamic PDCH which I think is a breakthrough. Is it working now? > It looks like only support PDCH and Full TCH switch,right? Hi Tiger, thanks for your comments and enquiry! I am still working on TCH/F <-> PDCH switching for the osmo-bts-trx SDR platform, but for ip.access nanobts, SysmoBTS and the litecell15, dynamic TCH/F <-> PDCH switching is already functional. TCH/F <-> PDCH could be called the ip.access compatibility mode, as it uses ip.access vendor specific messages to activate and deactivate PDCH on a TCH/F_PDCH timeslot. There are plans to include TCH/H as well, using a different vendor specific extension. Though development has not commenced yet, which will depend on funding by interested parties. See: http://osmocom.org/issues/1565 http://osmocom.org/issues/1757 BTW, Tiger, you have contacted my private email address. Instead, I'm replying from my sysmocom address, Bcc to you and copying to our mailing list, which would be the most appropriate place for questions on osmocom development. ~Neels -- - Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Harald Welte

7 years, 9 months

2
1
0 0

Re: osmo-bts: Repository write acces / Gerrit migration

by Harald Welte

Dear Tom, I hope you don't mind me Cc'ing the list, as this question might come up again. On Fri, Jul 01, 2016 at 02:42:25AM -0700, Tom Tsou wrote: > I appear to no longer have write access to the osmo-bts repository. > "ERROR:gitosis.serve.main:Repository write access denied" > Can I have write access restored? As decided at the Osmocom Developer Conference in April 2016, we have started to use gerrit for a more formalized tool for code review. The advantages are plentiful, among other things submitted patches are running through 'make distcheck' on several supported platforms before even being eligible to merge. Please see https://osmocom.org/projects/cellular-infrastructure/wiki/Gerrit for a short intro in how to use it. There are instructions both for submitting patches against master, as well as for pushing to user-private branches. 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)

7 years, 9 months

3
3
0 0

dynamic traffic channels

by Neels Hofmeyr

On Tue, Jun 28, 2016 at 10:05:28AM +0200, Harald Welte wrote: > [translated from german] > is it certain that we switch a channel to PDCH only when > gprs mode != none? A TS can be GSM_PCHAN_TCH_F_PDCH; those are the only ones for which we send a PDCH ACT message. We send a PDCH ACT message - during init (CHANNEL OML's state changed to enabled -> send PDCH ACT), - and upon channel release ack when pchan == GSM_PCHAN_TCH_F_PDCH. So the question is, when we receive a channel release ack, could that be the PDCH release and we switch PDCH right back on by accident? No, because we only receive a chan rel ack when the *TCH/F* is being released. That is because the PDCH release is initiated "internally" from the PDCH DEACT, and thus this condition in common/rsl.c rsl_tx_rf_rel_ack() catches on, which existed before dyn PDCH: if (lchan->rel_act_kind != LCHAN_REL_ACT_RSL) { LOGP(DRSL, LOGL_NOTICE, "%s not sending REL ACK\n", gsm_lchan_name(lchan)); return 0; } In rsl_rx_rf_chan_rel() the rel_act_kind is set to LCHAN_REL_ACT_RSL, but not in the rsl_rx_dyn_pdch(). This is analogous to the ip.access way -- the ip.access nanobts replies to a PDCH DEACT with a PDCH DEACT ACK and doesn't send a separate channel release ack. Maybe we could set rel_act_kind to some new LCHAN_REL_ACT_IPAC_DYN_PDCH for clarity? (But we shouldn't actually send a release ack, to stay compatible.) Even though it works as-is, we should indeed add another flag check: - We do check the flags that no ACT/DEACT is already pending; - And we do send a PDCH DEACT only if ts->flags & TS_F_PDCH_ACTIVE; - But we would send a PDCH ACT despite ts->flags & TS_F_PDCH_ACTIVE. This should never happen, but it would make sense to ensure that. ~Neels

7 years, 9 months

2
3
0 0

error install openbsc

by sms makhof

Hi all I am installing OpenBSC.I just following http://openbsc.osmocom.org/trac/wiki/Building_OpenBSC (I am just Building libosmocore, Building libosmo-abis, Building libosmo-netif, Building OpenBSC and install library.) But when I tried to run OpenBSC,I encounter with this error(problem). user12@ubuntu:~$ cd '/home/user12/openbsc/openbsc/src/osmo-nitb' user12@ubuntu:~/openbsc/openbsc/src/osmo-nitb$ sudo ./osmo-nitb <0005> bsc_init.c:492 Failed to parse the config file: 'openbsc.cfg' Or how do I run the software(OpenBSC)! Or do I have to install something missing? Note: My Linux is version ubuntu 12.04 . Please help me. thank you.

7 years, 9 months

2
1
0 0

freebsd and jenkins

by Max

Hi. Yet again I've hit an issue with jenkins build failing on freebsd only: http://jenkins.osmocom.org/jenkins/job/libosmocore-gerrit/label=FreeBSD_amd… No warnings, no errors, just a failure which I'm unable to reproduce locally as I do not have access to any machine with freebsd. If we can't make freebsd tests optional (which I personally would prefer) can we at least configure jenkins in a way that it runs "cat tests/testsuite.log" so it's available via "console output" part of jenkins web ui? Or somehow else provide access to build artifacts. That will give at least some clue as to what exactly is broken on freebsd. Any ideas as to why build fails are highly appreciated as well. -- Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

7 years, 9 months

2
3
0 0

Is there a maximum separation in Mhz for ARFCNs on one BTS?

by Keith Whyte

Hi all, Would somebody who is familiar with the relevant part of the GSM spec be able to comment? I'm wondering if there's any issue in GSM running a dual TRX BTS with two ARFCNs on opposite ends of the band? For example, in GSM850, this would mean the downlinks could be on 869.2 and 893.8 Mhz so the phone could have to tune across a wider range between the SDCCH and TCH for example. Thanks!

7 years, 9 months

2
1
0 0

osmo-nitb/osmo-bts-trx: Logging traffic on A-bis interface

by Sebastian Stumpf

Hi all, I wanted to check if the bts - bsc communication works properly with my configuration. For example, if my osmo-nitb does send the system information messages to the bts. I tried the vty logging interface of osmo-bts and logged some messages, but they were not the messages I expected. I configured the groups rsl, oml, rll, rr and abis to "notice", all to "everything" and everything else to "error" and got following log output (lots of these and nothing else): ... <0006> scheduler.c:405 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00 fn=993588 ts=0 trx=0 <0006> scheduler.c:341 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=993588 ts=0 trx=0 ... PH-RTS.ind and PH-DATA.req seem to come from layer1 SAP, the osmo-trx and have probably nothing to do with the SI messages. Is traffic on abis generally not logged or is my log config faulty? I ended up configuring the gsmtap interface for osmo-bts and could so see the uplink/downlink in wireshark and could see that the SI information is properly sent. But gsmtap only works for the air interface. What is the best way for logging/sniffing the communication on the A-bis interface? With kind regards, Sebastian Stumpf

7 years, 9 months

3
2
0 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC July 2016