OpenBSC

openbsc@lists.osmocom.org

4317 discussions

Re: INSTALL for install APDU failing
by Sabyrzhan Tasbolatov 17 Jan '22

17 Jan '22

Following up On Fri, Dec 24, 2021 at 2:51 AM Sabyrzhan Tasbolatov <snovitoll(a)gmail.com> wrote: > Hello, > > I need help with installing the HelloWorld.cap applet in my test SIM. > I know how to construct APDUs and osmocom's shadysim.py > <https://git.osmocom.org/sim/sim-tools/tree/shadysim/shadysim.py>, > does not work properly for me. So I've written the script myself. > > https://gist.github.com/Novitoll/2d8146b85f4384eb4dd039eb8116d1ed > > GP "Card Specification – Public Release v2.3.1". > > 1. Install for LOAD, Data = 00, SW = 9000 > 2. LOAD 0, SW = 9000 > 3. LOAD 1, SW = 9000 > 4. LOAD 2, SW = 9000 > 5. LOAD 3, SW = 9000, final > 6. Install for install and make selectable, SW = 6988 (Reference data not > found) > > Trying to figure out where the issue is. > I've tried to re-use `install_app` function from shadysim.py - same result. > > I'm using this https://github.com/mrlnc/HelloSTK2/blob/main/HelloSTK2.cap > > Could anyone assist? > > -- > Sabr > -- Sabr

2 2

osmo-msc codecs
by Neels Hofmeyr 13 Jan '22

13 Jan '22

Hi all, I'd like to draw attention again to the state of codecs handling in OsmoMSC master. The reason being that the recent IuUP changes create conflicts with the neels/mncc_codecs3 branch. I fear that we are currently doing the same thing that we discourage everyone else from doing: keeping an important branch on the side and not upstreaming it. There is recurrent overhead on rebasing the branch. Facts about OsmoMSC: master neels/codecs_mncc* heeds MS Bearer Cap from ComplL3 NO YES logically combines codec constraints NO YES communicates available codecs to/via SIP NO YES worked at last congress NO YES has the last IuUP patches YES NO I think the reasoning for completing that codecs work and merging the branch is compelling. Can we somehow achieve that before OsmoMSC diverges further? I could start maybe by holding a talk on it in an OsmoDevCall? That way I've read all of the code again and can explain what the patch does why, to ease review. Or maybe spend that time on merging the code instead? Or both? :) ~N

3 3

OsmoDevCall on Jan 14, 2022: Codecs in OsmoMSC, MNCC and SIP
by Harald Welte 11 Jan '22

11 Jan '22

Dear Osmocom community, It's my pleasure to announce the next OsmoDevCall on January 14, 2022 at 20:00 CET at https://meeting4.franken.de/b/har-xbc-bsx-wvs This meeting will have the following schedule: 20:00 meet + greet 20:10 presentation "Codesc in OsmoMSC, MNCC and SIP" by neels 21:00 unstructured supplementary social event [*] Attendance is free of charge and open to anyone with an interest in Osmocom or open source cellular technologies. More information about OsmoDevCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall Looking forward to meeting you on Friday. Best regards, Harald [*] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

Refreshing/Resetting UICC (SysmoISIM-SJA2)
by bryan coxwell 06 Jan '22

06 Jan '22

Hi all, I have a SysmoISIM-SJA2 which I believe doesn't have a CAT application and doesn't support the SUSPEND APDU (per the manual). Given that, is there any way to reset/refresh the card through APDU commands (or through any other means)? Would something along the lines of deactivating and then reactivating the USIM application work? Thanks, Bryan

2 4

lists.osmocom.org migrated to mailman3
by Harald Welte 03 Jan '22

03 Jan '22

Dear Osmocom community, today our mailing list server lists.osmocom.org has finally been migrated from mailman2-on-freebsd to mailman3-on-linux. This also included a variety of changes to DNS. I'll spare you the details, but everything _should_ be up and running now. * The List-Id headers should not have changed. * all list subscriptions + user accounts have been converted. * old 'static html' archives are still available (read only) at URLs like https://lists.osmocom.org/pipermail/baseband-devel/ * old List URLs like https://lists.osmocom.org/mailman/listinfo/baseband-devel are redirected to their respective modern counterparts In case you notice any mailing list related problem, please don't hesitate to contact me. Happy hacking, Harald -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

None
by None 03 Jan '22

03 Jan '22

those harmonics) must be above: -30 dBm @ 30 kHz span above 1 GHz -36 dBm @ 30 kHz span below 1 GHz In case of UmTRX without an amplifier it's enough to use a ceramic or SAW duplexer to bring harmonics below those levels. For those buying UmTRX's as a lab package of universal UmDESKs, we offer to buy an external ceramic duplexers. These improves coverage and solves the out of band noise issues. For those buying band-specific UmDESK's, we use SAW duplexers, which are even more efficient in reducing out of band noise. >> A calibrated USRP N200 running osmo-trx passes RF spectrum and >> modulation accuracy requirements of 3GPP 05.05 by very large margins >> and is competitive with commercial GSM equipment in this regard. Other >> SDR devices are also capable to varying degrees. > > The policy of FCC vs. European Union is quite different. There are more > norms that apply in Europe. You're obviously more proficient in European norms. Could you point me to a link where we could find these differences between the ETSI published GSM Standard and European harmonized norms? It would be a very good addition to the OpenBSC wiki's "Standards" page. --=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

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC