OpenBSC January 2023

openbsc@lists.osmocom.org

5 participants
23 discussions

GCR (osmo_store16be/osmo_store32be)
by Keith 18 Jan '23

18 Jan '23

Hi All, I was working a few months back on some LCLS implementation with bts-loop and I got it working, including that the pbx can use SIP Re-INVITES to get in and out of the audio loop during calls. However, I only ever tested it with one call, that is with two phones. When I tested it on alive site, immediately there where problems so I reverted and left it. Looking at it again now, there's a very obvious problem which is that osmo-msc generates the same GCR for (almost) every call. I had noticed this before but for some reason I thought I had seen it generating different GCR for a second simultaneous call, but no. Anyway, the above is extraneous info to the question: Could somebody take a look at this: https://gitea.osmocom.org/cellular-infrastructure/osmo-msc/src/branch/maste… where we have: osmo_store32be(trans->callref, lcls->gcr.cr); osmo_store16be(use_lac ? trans->msc_a->via_cell.lai.lac : trans->msc_a->via_cell.cell_identity, lcls->gcr.cr + 3); Now, If I change the order, such that would seem logical: osmo_store16be(use_lac ? trans->msc_a->via_cell.lai.lac : trans->msc_a->via_cell.cell_identity, lcls->gcr.cr + 3); osmo_store32be(trans->callref, lcls->gcr.cr); Then I get a different GCR, reflecting the trans->callref for each call. But am I then maybe overwriting the LAC/CI ? Would seem to make sense, but I'm just not sure if that is all there is to it, as I don't really grok osmo_store_xxxx for(i = 0; i < n; q[i] = (x >> ((n - 1 - i) * 8)) & 0xFF, i++); Is it just a simple order error, and is everything OK with lcls->gcr.cr + 3 as the pointer *p passed to osmo_store32be_ext() ? given that: struct osmo_lcls *lcls; where: struct osmo_lcls { struct osmo_gcr_parsed gcr; }; struct osmo_gcr_parsed { uint8_t cr[5]; }; I guess I'm still not really 100% on the char/uint8_t thing and advancing pointers. Thanks! k.

2 2

OsmoDevCall on Jan 18, 2023: ice40-usbtrace OSHW USB protocol tracer
by Harald Welte 17 Jan '23

17 Jan '23

Dear Osmocom community, we're happy to announce the next incarnation of OsmoDevCall. when: January 18, 2023 at 20:00 CET where: https://osmocom.org/OsmoDevCall This time, @tnt will be presenting on ice40-usbtrace OSHW USB protocol tracer In case you never heard about ice40-usbtrace before: It's a low-cost full-speed USB protocol tracer built around the iCE40 FPGA. This meeting will have the following schedule: 20:00 meet + greet 20:10 presentation as outlined above 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 soon! 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

Distributed GSM
by Keith 17 Jan '23

17 Jan '23

Hi all, I was thinking about how to deal with the so called "evil twins" in the distributed hlr, and also how to have a subscriber-create-on-demand situation at the same time as a having an mslookup client. The problem being that if we have mslookup client + fallback to create-on-demand if no HLR responds for an IMSI, we will eventually create a duplicate because the HLR that owns the IMSI is not contactable at the time of an IMSI ATTACH attempt. Anyway, just in terms of investigating the situation on my HLRs, I added features [1] - so far, an ability to do a gsup.hlr lookup and not exit on the first age:0 - so that I can see all HLRs that respond as having the imsi in local HLR, and also to ask via mDNS for HLRs that have an IMSI, but only if it's active on that HLR, that is, it has nam_cs/nam_ps So this is really asking about what people feel about expanding the D-GSM features in osmo-hlr, as I think it may be the case that rhizomatica/TIC are the only people that use it? [1] https://gitlab.tic-ac.org/rhizomatica/osmo-hlr

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC January 2023