OpenBSC

openbsc@lists.osmocom.org

14 participants
4246 discussions

None
by None 03 Jan '22

03 Jan '22

cell into=20 operation, but during normal operation?! > -- > Regards, > Alexander Chemeris. > CEO, Fairwaves LLC / =D0=9E=D0=9E=D0=9E = =D0=A3=D0=BC=D0=A0=D0=B0=D0=B4=D0=B8=D0=BE > http://fairwaves.ru Ralph.

1 0

None
by None 03 Jan '22

03 Jan '22

> Anyway, I thought that the GPRS support is part of the OpenBTS > development, and any hardware that can run OpenBTS is also capable of > doing GPRS, but it is clear, that there are differences in the level > of support, even between SDR like devices. The majority of the code of osmo-pcu has been contributed by or on behalf of sysmocom. If you take a look at the development of the PCU for the last 6 months you will clearly see that sysmocom is doing all the work. Just like with OpenBSC a lot of others benefit from our work though. ;) > I still think that it would be nice, to clarify all this packet data > related stuff on the site.

1 0

None
by None 03 Jan '22

03 Jan '22

* When an external protocol changes, the version number needs to change. I added MNCC protocol versioning as OpenBSC and LCR were out of sync and then funny things happened. This one line change of the version number can save you hours in debugging! * When a new feature is added, ask for a testcase. E.g. specially the E1 bit fiddling as it is so rarely used that it is likely to bitrot. * Check the error paths. Developers tend to only test with a single phone, not run into error paths, not force them to be taken during development (faul injection). * For things like device work-arounds ask if they are really necessary, e.g. I have my doubts for the RTP timestamp handling. * General code hygiene. Don't have the action take place four tabs in in a thousand line code method, don't use magic numbers, don't repeat yourself etc. Code is read a lot more than it is written. Besides smaller methods being easier to write unit tests for, they are easier to understand/review. I have merged two patches from this patchset but they required multiple rounds and my spare time is really limited. cheers holger

1 0

None
by None 03 Jan '22

03 Jan '22

it should return gsm_phys_chan_config? In the implementation we do have: static const enum abis_nm_chan_comb chcomb4pchan[] = { and at the indexes we use values from gsm_phys_chan_config. Do you think the below is correct? holger diff --git a/include/osmocom/gsm/abis_nm.h b/include/osmocom/gsm/abis_nm.h index 4dee012..4682ead 100644 --- a/include/osmocom/gsm/abis_nm.h +++ b/include/osmocom/gsm/abis_nm.h @@ -43,7 +43,7 @@ const char *abis_nm_test_name(uint8_t test); int abis_nm_chcomb4pchan(enum gsm_phys_chan_config pchan); -enum abis_nm_chan_comb abis_nm_pchan4chcomb(uint8_t chcomb); +enum gsm_phys_chan_config abis_nm_pchan4chcomb(uint8_t chcomb); /*! @} */ diff --git a/src/gsm/abis_nm.c b/src/gsm/abis_nm.c index bb7008b..2c8f871 100644 --- a/src/gsm/abis_nm.c +++ b/src/gsm/abis_nm.c @@ -407,7 +407,7 @@ const struct value_string abis_nm_adm_state_names[] = { { 0, NULL } }; -static const enum abis_nm_chan_comb chcomb4pchan[] = { +static const enum gsm_phys_chan_config chcomb4pchan[] = { [GSM_PCHAN_NONE] = 0xff, [GSM_PCHAN_CCCH] = NM_CHANC_mainBCCH, [GSM_PCHAN_CCCH_SDCCH4] = NM_CHANC_BCCHComb, @@ -430,7 +430,7 @@ int abis_nm_chcomb4pchan(enum gsm_phys_chan_config pchan) } /*! \brief Obtain physical channel config for OML Channel Combination */ -enum abis_nm_chan_comb abis_nm_pchan4chcomb(uint8_t chcomb) +enum gsm_phys_chan_config abis_nm_pchan4chcomb(uint8_t chcomb) { int i; for (i = 0; i < ARRAY_SIZE(chcomb4pchan); i++) {

1 0

None
by None 03 Jan '22

03 Jan '22

<div><br></div><div>" #if defined(L1_HAS_EFR) && defined(USE_L= 1_RTP_MODE) "</div><div><br></div><div>is why I'm seeing this mess= age logged, but it seems to be #define...</div><div><br></div><div>Any poin= ters, ideas ? This doesn't seem like a configuration thing, but a compi= lation time option?</div> <div>I'd have expected that EFR is fully supported?</div><div><br></div= ><div><br></div><div>osmo-bts.cfg snippet</div><div>-----------------------= -------</div><div><div>bts 0</div><div>=A0band 850</div><div>=A0ipa unit-id= 1801 0</div> <div>=A0oml remote-ip 127.0.0.1</div><div>=A0rtp jitter-buffer 100</div><di= v>=A0paging queue-size 200</div><div>=A0paging lifetime 0</div><div>=A0trx = 0</div><div>=A0 clock-calibration 603</div><div>=A0 trx-calibration-path (n= ull)</div> <div>=A0 clock-source ocxo</div><div>=A0 uplink-power-target -75</div><div>= =A0 min-qual-rach -5</div><div>=A0 min-qual-norm -5</div></div><div><br></d= iv><div><br></div><div><br></div><div>Regards,</div><div>Roelf.</div><div><= br></div> </div> --bcaec51b1b6f7f08e204e11a4392--

1 0

None
by None 03 Jan '22

03 Jan '22

I deduct that " #if defined(L1_HAS_EFR) && defined(USE_L1_RTP_MODE) " is why I'm seeing this message logged, but it seems to be #define... Any pointers, ideas ? This doesn't seem like a configuration thing, but a compilation time option? I'd have expected that EFR is fully supported? osmo-bts.cfg snippet ------------------------------ bts 0 band 850 ipa unit-id 1801 0 oml remote-ip 127.0.0.1 rtp jitter-buffer 100 paging queue-size 200 paging lifetime 0 trx 0 clock-calibration 603 trx-calibration-path (null) clock-source ocxo uplink-power-target -75 min-qual-rach -5 min-qual-norm -5 Regards, Roelf. --bcaec51b1b6f7f08e204e11a4392 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div>I have FINALLY gotten to play with my sysmoBTS acquired many months ag= o, and updated to the latest packages using okpg, and am running a NITB.</d= iv><div><br></div><div>GSM850 test setup in open mode A5/0, and I can SMS a= nd call between devices.</div> <div><br></div><div>However, there is no audio, and BTS console logs report= s many repeats of the following during an established call.</div><div><br><= /div><0006> tch.c:601 (bts=3D0,trx=3D0,ts=3D7,ss=3D0) Rx Payload Type= EFR is unsupported<div> <0006> tch.c:601 (bts=3D0,trx=3D0,ts=3D7,ss=3D0) Rx Payload Type EFR = is unsupported</div><div><0006> tch.c:601 (bts=3D0,trx=3D0,ts=3D7,ss= =3D0) Rx Payload Type EFR is unsupported</div><div><br><div><br></div><div>=

1 0

None
by None 03 Jan '22

03 Jan '22

the script? Libosmocore and install it as part of it? A new repo?

1 0

None
by None 03 Jan '22

03 Jan '22

about it and demonstrate it operating OpenBTS and OsmoBTS. I could talk about our open-source development of OpenBTS, if there would be any interest. Also I'd love to talk about OsmoBTS/OpenBSC which the new cool. Only few people heard about OsmoBTS, while it provides great capabilities: * it works with off-the-shelf SDR transceivers like UmTRX * it could use VoIP (SIP) soft-switches to connect calls * it connects to MSCs of legacy GSM networks * it supports encryption, handover, FR/HR/AMR codecs and GPRS (in beta) * standards compliant L1/L2 layers, so there are no issues with various phone models I love Osmocom approach to development as well - development is open to all contributors, the code is well structured and tested, even build results for all sub-projects are available through a continuous integration suite: http://jenkins.osmocom.org/jenkins/ On Sat, May 4, 2013 at 9:00 AM, Robin Coxe <coxe(a)close-haul.com> wrote: > (Apologies for cross-posting. We wanted to reach everyone who might be > interested in attending. Please respond responsibly.) > > Anders Brownworth (Switchcoder), Alexander Chemeris (Fairwaves), and Robi= n > Coxe (Close-Haul Communications & Analog Devices) invite those interested= in > open GSM hardware and software development to an informal gathering in > Cambridge, MA on Friday 10 May 2013 from 6-8 pm. Alexander will be visit= ing > the Boston area from Moscow. > > If you are interested in participating in any capacity in the Boston-area > open source GSM development community, we look forward to meeting you. O= ur > goal is to identify like-minded people involved in or interested in learn= ing > more about projects such as OpenBTS, OsmocomBTS, OsmocomBB, and OpenBSC. > If you have a portable, self-contained demo, feel free to bring it with y= ou. > > When: Friday 10 May 2013, 6-8 pm EDT > Where: Cambridge Innovation Center, 1 Broadway, 4th Floor, Cambridge, MA > 02142 USA > Photo ID required for building entry. > > Please RSVP on Eventbrite: http://opengsmboston.eventbrite.com/ > > > > > > > > --=20 Regards, Alexander Chemeris. CEO, Fairwaves LLC / =D0=9E=D0=9E=D0=9E =D0=A3=D0=BC=D0=A0=D0=B0=D0=B4=D0= =B8=D0=BE http://fairwaves.ru

1 0

None
by None 03 Jan '22

03 Jan '22

keep doing the same style. Good food makes a brain work better. > Venue-wise, I would again suggest to hold it in Berlin, as it's > reasonbly well connected, has lots of low-cost flights to it, > accomodation is not too expensive and holger/me/sysmocom can take care > of local organization related activities. Hoewver, if somebody has a > strong opinion against berlin _and_ is willing to organize it, I'm not > completely against another venue. Berlin is perfect. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / =D0=9E=D0=9E=D0=9E =D0=A3=D0=BC=D0=A0=D0=B0=D0=B4=D0= =B8=D0=BE http://fairwaves.ru

1 0

None
by None 03 Jan '22

03 Jan '22

of what if the msgb is 'borrowed' or 'owned/transferred'. Whenever we reach a _send method we actually transfer the ownership (as the data might be queued or such). The other technical part is to make sure we first establish a rule by 1.) adding doxygen/API documentation to the sendmsg function 2.) maybe look into introducing dummy annotations like __borrow, __takes that we could autocheck in the future (e.g. by extending spaze/smack) The issue with reviewing such a patch is the question if you have catched everything. E.g. I think you missed need to convert (and what it calls): static int gprs_ns_tx(struct gprs_nsvc *nsvc, struct msgb *msg) { ... default: LOGP(DNS, LOGL_ERROR, "unsupported NS linklayer %u\n", nsvc->ll); msgb_free(msg); ret = -EIO; break; } return ret; } > As reported in ticket #55 SGSN can crash due to double free-ing. You > can replace 'can' by 'will' in that last phrase. I had a sift through > the code and tried to solve this by removing the free in gprs_ns.c. > Whenever the calling function created the msgb-struct, I have made the > function free it after its use. If the function got the msgb from a > calling function, there will not be a free (hoping that will be done > on the higher level). > > HTH/F

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC