Open Source Mobile Communications: Issueshttps://projects.osmocom.org/https://projects.osmocom.org/favicon.ico?16647414092024-02-27T17:53:18ZOpen Source Mobile Communications
Redmine erlang/osmo_ss7 - Bug #6377 (Feedback): ipa: Failure decoding ipa frames split between several tc...https://projects.osmocom.org/issues/63772024-02-27T17:53:18Zpespin
<p>This happens when a lot of IPA concurrent clients send messages and end up in the same TCP packet due to naggle algorithm.<br />When that happens, ipa code in osmo_ss7 fails to decode in osmo-epdg:</p>
<pre>
*DBG* epdg_ue_fsm_262424287925697 receive call {auth_request,33,"internet"} from <0.204.0> in state state_new
*DBG* epdg_ue_fsm_262424287925697 send ok to <0.204.0>
*DBG* gsup_server new state {gsups_state,#Port<0.16>,4222,#Port<0.19>,
{ipa_ccm_options,"EPDG-00-00-00-00-00-00",
"0/0/0","00:00:00:00:00:00","00:00:00:00:00:00",
"00:00:00:00:00:00","00:00:00:00:00:00",
"00:00:00:00:00:00","EPDG-00-00-00-00-00-00",
false},
{set,6,16,16,8,80,48,
{[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],
[]},
{{[],[],[],[],
[{gsups_ue,<<"262429242370912">>,<0.240.0>}],
[],
[{gsups_ue,<<"262423473100631">>,<0.243.0>}],
[],[],
[{gsups_ue,<<"262423491582839">>,<0.244.0>}],
[],[],
[{gsups_ue,<<"262424287925697">>,<0.248.0>}],
[{gsups_ue,<<"262426121377808">>,<0.245.0>}],
[{gsups_ue,<<"262426512097609">>,<0.246.0>}],
[]}}}}
*DBG* epdg_ue_fsm_262424287925697 consume call {auth_request,33,"internet"} from <0.204.0> in state state_new => state_wait_auth_res
p
*DBG* gsup_server got {ipa,#Port<0.19>,
{osmo,5},
#{imsi => <<"262425921669062">>,
message_type => send_auth_info_req,
pdp_info_list =>
[#{access_point_name => "internet",
pdp_address =>
#{address => #{},pdp_type_nr => 33,
pdp_type_org => 241},
pdp_context_id => 0}]}}
*DBG* epdg_ue_fsm_262425921669062 enter epdg_ue_fsm in state state_new
17:39:21.043 [error] Error in process <0.222.0> with exit value:
{{badmatch,<<0,32,238,5,8,1,8,98,66,98,68,72,146,87,244,5,18,16,1,0,17,2,241,33,18>>},[{ipa_proto,split_ipa_msg,1,[{file,"/tmp/osmo-
epdg/_build/default/lib/osmo_ss7/src/ipa_proto.erl"},{line,135}]},{ipa_proto,process_rx_ipa_msg,4,[{file,"/tmp/osmo-epdg/_build/defa
ult/lib/osmo_ss7/src/ipa_proto.erl"},{line,182}]},{ipa_proto,loop,3,[{file,"/tmp/osmo-epdg/_build/default/lib/osmo_ss7/src/ipa_proto
.erl"},{line,269}]}]}
</pre> osmo-ePDG - VoWifi Evolved Packet Data Gateway - Bug #6361 (Feedback): open5gs-upfd: Fix open5gs ...https://projects.osmocom.org/issues/63612024-02-15T19:50:49Zpespin
<p>From <a class="external" href="https://osmocom.org/issues/6235?issue_count=13&issue_position=5&next_issue_id=6229&prev_issue_id=6289#note-26">https://osmocom.org/issues/6235?issue_count=13&issue_position=5&next_issue_id=6229&prev_issue_id=6289#note-26</a>:</p>
<blockquote>
<p>Also, I had to tweak broken open5gs setup where open5gs-upfd ogtsun gets assigned IP address "10.45.0.1/16", but that IP address is actually also assigned to the first MS (my SWu emulator), and that creates problems in the network stack when the inner packet is decapsulated from GTP. In order to fix it:</p>
<pre>
> root@epc:~# ip addr del 10.45.0.1/16 dev ogstun
> root@epc:~# ip route add 10.45.0.0/24 dev ogstun
> </pre>
<p>According to lynxis this is a problem coming from open5gs package (file /etc/systemd/network/99-open5gs.network). The IP address is set in order to get the routing entry for free. Instead, it should only add the routing entry.</p>
</blockquote>
<p>We should look into fixing the open5gs package to avoid having to apply those changes every time open5gs-upf is restarted.</p> libosmo-sccp + libosmo-sigtran - Bug #6356 (New): DLGLOBAL ERROR Trying to dispatch event 17 to n...https://projects.osmocom.org/issues/63562024-02-08T22:27:51Zneelsnhofmeyr@sysmocom.de
<p>ML reports:</p>
<p>DLGLOBAL ERROR Trying to dispatch event 17 to non-existent FSM instance! (osmo_ss7_as.c:118)</p>
<p>during startup of both osmo-msc and osmo-bsc.<br />Probably related: <a class="external" href="https://gerrit.osmocom.org/c/libosmo-sccp/+/35348">https://gerrit.osmocom.org/c/libosmo-sccp/+/35348</a></p> Linux Kernel GTP-U - Bug #6212 (In Progress): GTP extension headershttps://projects.osmocom.org/issues/62122023-10-06T11:11:59Zpablo
<p>GTP packets are dropped in the presence of extension header, add support for GTP driver to deal with this.</p> osmo-ePDG - VoWifi Evolved Packet Data Gateway - Bug #6045 (Feedback): report erlang diameter pro...https://projects.osmocom.org/issues/60452023-05-26T11:49:29Zlynxis
<p>Somehow is the erlang diameter code not generating all AVPs. I've the feeling it doesn't have enough inherits layer. e.g. when a dia spec inherits from another spec, from another spec, .. it comes to a limit without a failure. In the end the decoding of messages fails.</p>
<p>Create a test case with github repo to report the issue.</p> OsmoBTS - Bug #5895 (New): LC15: Audio Quality Problem sometime after cf7a7fcebf625a14fd764355c3b...https://projects.osmocom.org/issues/58952023-02-07T03:11:09Zkeith
<p>Writing this up now while it's a bit fresh...</p>
<p>I have spent the last 12 hours or so working with people on site to try to track down these problems:</p>
<p>Fierce complaints about audio quality (no audio, unintelligible, intermittent, chopped)</p>
<p>Observation of a lot of very variable Q in meas reps, especially on downlink (associated with bad audio) and more pronounced when the call B-leg was using another codec such as G.729 on the other side of the PBX, - in fact not transcoding at site and sending AMR to our data centre and trancoding there to PCMA/U for the upstream VoIP was giving better results most of the time.</p>
<p>However, today I discovered the extent of how bad this was on local MS to MS calls.</p>
<p>After exhausting everything I could think of, we went back to the timeline and there were some opinions that this started around a date last year which seemed to be around the time I changed this site away from osmo-nitb. Given I wasn't seeing any signalling problems, I had been looking for problems with maybe the MGW or something with RTP that would have changed. but I could find nothing.</p>
<p>Of course none of that was at fault, what happened was that along with the move to osmo-bsc, I built v1.4.0 of osmo-bts - I think not 1.5.0 because at the time 1.4.0 built against the libs I had on the BTS, anyway, going back to the binary I had built before from cf7a7fce "solves" the problem.</p>
<p>Given the current somewhat tense situation I don't envisage "test"-ing anything at this site for the time being so I can't exactly try to dissect between cf7a7fce and 1.4.0 not that it would be very easy to run each commit against a bunch of manual tests that annoy the local people, asking them to make calls to each other.</p>
<p>So what to do? Well note it at least. I don't have another lc15 to test on. <br />Maybe shout-out to the main devs who committed code that touched lc15 or common, (which seems to have to do with power control, interference measurements) to see if they have any ideas. My feeling is that something that was done is not happy on the LC15 PHY.</p>
<p>There's the chance that this was fixed since 1.4.0 or in another lib.</p>
<p><em>Trivia: cf7a7fce is the last commit that can do RSL/OML bring-up against osmo-nitb.. that's why that one.</em></p> Cellular Network Infrastructure - Feature #5771 (New): series of presentations about the invididu...https://projects.osmocom.org/issues/57712022-11-14T19:25:57Zlaforge
<p>Most of the talks we ever gave on setting up and running the Osmocom CNI are ages old and hence relatively outdated.</p>
<p>Given the number of network elements and the relate complexity, I think we should consider doing a talk on each of them. The talk doesn't have to be of a particular length, so some network elements might have shorter or longer presentations.</p>
<p>Looking at the checklist below, we already have 14 items. Covering this in OsmoDevCall is not an option, it would take too long (14 months if no other topic would be covered in between). So it is going to be on a separate schedule.</p>
<p>I would consider each presentation should then be prominently linked from the redmine project page of each network element, next to the user manual.</p>
<p>We may of course still be publishing those via the OsmoDevCall "event" on media.ccc.de, so all videos are in one location.</p>
<p>I think every presentation should start with a quick picture at the overal diagram of netwokr elements, describe the surrounding elements and their interfaces to then look in detail at the specific element that ist he subject of the talk.</p>
It should cover
<ul>
<li>basic configuration to get it started / connected</li>
<li>VTY for state introspection ("ar alle connections up?", ...)</li>
<li>looking at logs / protocol traces</li>
<li>practical demo; looking at what happens in pcaps + logs for some basic transaction like LU, SMS, voice call.</li>
</ul> libosmocore - Bug #5346 (New): osmo-release.sh doesn't work with %{sover} macro in spec.inhttps://projects.osmocom.org/issues/53462021-12-09T07:26:09Zlaforge
<p>When trying to release a new version of osmo-remsim, I run into the following error:</p>
<pre>
make REL=major release 415/0/0
Releasing 0.2.2.126-7382 -> 1.0.0...
OK: dependency specific versions in configure.ac and debian/control match
OK: dependency specific versions in configure.ac and contrib/*.spec.in match
OK: Found matching debian/lib*2.install for LIBVERSION=2:0:0
OK: Found 'Package: lib*2' in debian/control for LIBVERSION=2:0:0
ERROR: Found no matching '%files -n lib*2' in contrib/*.spec.in for LIBVERSION=2:0:0
make: *** [osmo-release.mk:9: release] Error 1
</pre>
<p>this seems to relate to the spec.in file using a %{sover} macro. This seems to be the case ever since this spec file was introduced to osmo-remsim, so I suppose the check in osmo-release.sh is more recent and didn't consider this situation?</p> Cellular Network Infrastructure - Feature #5045 (New): write libversion "major" on build files au...https://projects.osmocom.org/issues/50452021-02-24T12:41:58Zpespin
<p>As a reminder:<br /><a class="external" href="https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html">https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html</a></p>
<p>LIBVERSION = current:revision:age<br />LIBVERSION_MAJOR = current - age</p>
Right now we usually use the form "{*_}LIBVERSION = 1:2:3" in Makefile.am, and we hardcode the resulting LIBVERSION_MAJOR in lots of files, namely:
<ul>
<li>debian/control</li>
<li>debian/rules</li>
<li>contrib/*.spec.in</li>
</ul>
<p>The idea here would be to generate LIBVERSION_MAJOR automatically as a autconf/automake variable which can be fed into those files automatically, so we don't have to update them every time LIBCERSION_MAJOR changes (and hence potentially avoid breakage during release time).</p>
So, I'd follow these steps for each project:
<ul>
<li>Normalize the LIBVERSION variable to follow a standardized naming, so that we can track it later better on osmo-release.sh, for instance ${LIBNAME}_LIBVERSION (replacing "-" with "_"). Example: LIBOSMO_NETIF_LIBVERSION. Or even better, LIBVERSION_LIBOSMO_NETIF.</li>
<li>Have LIBVERSION variable be generated out of 3 new variables (also following normalized name with LIBNAME), example: <br /><pre>
LIBVERSION_CURRENT_LIBOSMO_NETIF = 3
LIBVERSION_REVISION_LIBOSMO_NETIF = 2
LIBVERSION_AGE_LIBOSMO_NETIF = 1
LIBVERSION_MAJOR_LIBOSMO_NETIF = LIBVERSION_CURRENT_LIBOSMO_NETIF - LIBVERSION_AGE_LIBOSMO_NETIF
</pre></li>
</ul>
<ul>
<li>Use $LIBVERSION_MAJOR_LIBOSMO_NETIF in the files mentioned above</li>
<li>Update osmo-release.sh to follow new naming</li>
</ul>
Considerations:
<ul>
<li>We may need to move debian/control to debian/control.in so we can template it? That means also configure must be run before generating the package, I guess that's expected?</li>
</ul> libosmocore - Feature #5034 (Stalled): logging: Enable category name instead of hex val by defaulthttps://projects.osmocom.org/issues/50342021-02-18T18:06:59Zpespin
<p>Discussion started in this patch:<br /><a class="external" href="https://gerrit.osmocom.org/c/libosmocore/+/12095">https://gerrit.osmocom.org/c/libosmocore/+/12095</a></p>
<p>Summary/outcome:<br /><pre>
As a reference, I think it makes more sense to change it for all log targets this way:diff --git a/src/logging.c b/src/logging.c
index a40008e9..f878be5a 100644
--- a/src/logging.c
+++ b/src/logging.c
@@ -918,7 +918,8 @@ struct log_target *log_target_create(void)
target->use_color = 1;
target->print_timestamp = 0;
target->print_filename2 = LOG_FILENAME_PATH;
- target->print_category_hex = true;
+ target->print_category_hex = false;
+ target->print_category = true;
So here actually by default we disable the hex output and we enable the string representation. Once this is applied, some tests will need to be adapted since they may not set those fields explicitly and use default ones.
</pre></p>
Steps:
<ul>
<li>Apply change in libosmocore locally</li>
<li>Build other projects and see if a test in any projects fails. For each test failing, make sure to set explicit values for log_set_print_category{_hex} to match current expectancies.</li>
<li>Once those patches are merged, submit + merge libosmocore patch changing the default.</li>
</ul> osmo-uecups - Feature #5012 (New): use osmo-uecups from GGSN_Tests.ttcnhttps://projects.osmocom.org/issues/50122021-02-06T10:02:49Zlaforge
Historically, we
<ol>
<li>developed GGSN_Tests.ttcn against osmo-ggsn, where the GTP-U plane is handled inside the tests itself
<ul>
<li>this limits the testing to very simple cases like sending single user IP packets back and forth</li>
</ul>
</li>
<li>much later developed PGW_Tests + osmo-uecups, where only the control plane is handled in TTCN3 and the user-plane goes via osmo-uecups
<ul>
<li>this allows to create one tun device per PDP context, each in a separate netns and then start any arbitrary test program (e.g. iperf) inside that netns</li>
</ul></li>
</ol>
<p>It would be great to also start using osmo-uecups from the GGSN_Tests.ttcn. Not really to replace the existing tests, but to add new tets that can do more in terms of user plane testing. See e.g. PGW_Tests.TC_createSession_ping4_256, which starts 256 concurrent Sessions (== pdp contexts) each with its tun device, netns and ping command inside. Of course "ping" is not neccessarily the best test program, but it illustrates what can be done with very few lines of TTCN3 code. Result codes of the ping commands are checked, so we see whether multiple concurrent PDP contexts work as expected.</p> Core testing infrastructure - Feature #4840 (New): migrate osmo-gsm-tester docker images to regis...https://projects.osmocom.org/issues/48402020-11-02T17:13:01Zlaforge
<p>As of <a class="issue tracker-1 status-3 priority-4 priority-high2 closed" title="Bug: docker.io sometimes returns EOF, breaking our builds (Resolved)" href="https://projects.osmocom.org/issues/4839">#4839</a>, we now have registry.osmocom.org. Hence, it makes sense to stop using sysmocom infrastructure (registry.sysmocom.de) for osmo-gsm-testerm image storage and migrate over.</p>
<p>The same "docker login" credentials should work on regsitry.osmocom.org.</p>
<p>Please make sure to notify <a class="user active" href="https://projects.osmocom.org/users/7">laforge</a> after the migration, so the old images can be deleted from registry.sysmocom.de</p> OsmoBTS - Bug #4446 (New): osmo-bts doesn't actually ever connect() its RTP/UDP socketshttps://projects.osmocom.org/issues/44462020-03-08T21:49:32Zlaforge
<p>In Abis/IP we are using fully-symmetric RTP over a UDP flow between a given set of IP:Port tuples on either side of the Abis link. As such, we would normally expect that the sockets are not just bound to a local port on the BTS side, but that they're also connect()ed to the remote side.</p>
<p>We are using <code>osmo_rtp_socket_connect()</code> in <a class="source" href="https://projects.osmocom.org/projects/osmobts/repository/osmo-bts/entry/src/common/rtp.c">source:src/common/rtp.c</a> and asume that this actually happens, but a look in netstat indicates differently :(</p> OsmoBTS - Bug #4364 (New): osmo-bts-trx configured with 2 TRX and osmo-trx with 1 TRX -> bad beha...https://projects.osmocom.org/issues/43642020-01-14T15:18:18Zpespin
<p>Configure osmo-bsc + osmo-bts-trx to run with 2 TRX, and osmo-trx to run with only one TRX (chan 0).</p>
<p>Current behavior: the network runs fine (of course only using TRX0) and osmo-bts is lots of times per second printing the error message:<br /><pre>
20200114161445605 DTRX <000b> trx_if.c:1110 phy0.1: send() failed on TRXD with rc=-1 (Connection refused)
</pre></p>
So there seems to be several flaws here:
<ul>
<li>If that log line is printed, it means the TRX1 is seen as ON (<code>trx_if_powered(l1h)</code> is returning true), but it's not since osmo-trx doesn't use it, so it shouldn't be on</li>
<li>Upon that failure, osmo-bts-trx should either: A) continue running but tell BSC over OML that the TRX is down, or B) stop the process (exit).</li>
</ul> libosmo-sccp + libosmo-sigtran - Feature #4356 (New): execute sccp_demo_user server+client agains...https://projects.osmocom.org/issues/43562020-01-10T12:23:16Zlaforge
<p>As we have those examples for testing both sides, we should actually execute them against each other as part of some automatically executed test, somewhere</p> Cellular Network Infrastructure - Bug #4141 (New): No osmux specific code in place during codec n...https://projects.osmocom.org/issues/41412019-08-05T15:57:19Zpespin
<p>Current code in OsmoBSC and OsmoMSC doesn't take into account that Osmux is to be used when codec negotiation goes one. That means that supported codec list needs to be correctly configured manually in VTY in order to avoid selecting incorrect codecs (like non-AMR). Moreover if an MS doesn't support AMR, since we don't have transcoding yet, the call cannot take place.</p>
<p>Different scenarios need to be listed here and think about what we want to do in each case.</p> Cellular Network Infrastructure - Feature #4091 (New): Osmux: Make sure all handover types work f...https://projects.osmocom.org/issues/40912019-07-05T14:10:17Zpespin
<p>It has never been tried and it could be it doesn't work.</p>
Let's add some TTCN3 tests to make sure we support different scenarios.<br />For instance:
<ul>
<li>intra-bsc handover between 2 BTS while BSC<->MSC is using Osmux</li>
<li>inter-bsc handover between 1 BSC with osmux enabled and 1 BSC with osmux disabled while a call is ongoing. Test both handover directions (A->B, B->A).</li>
<li>inter-msc handover between 2 MSC, one MSC having a BSC with Osmux enabled and another MSC having a BSC with Osmux disabled. Test both handover directions (A->B, B->A).</li>
</ul> libosmo-abis - Bug #3622 (New): Clear API mess in sign_link_up callbackhttps://projects.osmocom.org/issues/36222018-10-02T19:32:41Zpespin
<pre>
<pespin_> ipa sign_link_up() callback is so fucked up. It has so many hidden details on how it is called and handled, lots of intrinsic assumptions based on who uses it and which messages it expects to receive.
<LaF0rge> pespin_: welcome to an architecture designed for E1 which was later extended with Abis/IP support without introducing too many changes
<LaF0rge> pespin_: also, written when understanding nothing about Abis/IP as thre's no documentation on it...
<pespin_> LaF0rge, it's fine, I'm just trying to share my understanding and find possible solutions to make it more maintainable
<pespin_> 1st parameter is a void* which is only used by osmo-bsc during IPA_ID_RESP, and in that case is passed a "struct ipaccess_unit *"
<pespin_> from which it takes unit ID (including TRX ID)
<pespin_> Then 3rd paramenter is "enum e1inp_sign_type type", which can be basically either E1INP_SIGN_OML or E1INP_SIGN_RSL
<pespin_> but in case it's E1INP_SIGN_RSL, it's actually encoded as E1INP_SIGN_RSL+trx_num
<pespin_> and that only for expected BTS users, that is for message IPA_ID_GET/REQ
<pespin_> for BSC messages, as trx_num is passed inside the first parameter, that trick is not used
<pespin_> I'm willing to fix this, but of course it means breaking compat between osmo-bts/osmo-bsc and libosmo-abis.
<pespin_> we should basically send always a "struct ipaccess_unit *" correctly filled in the first param, and stop using this RSL+trx_num hack in the 3rd parameter
<pespin_> another option would be adding a new sign_link_up2 callback, and implement it in libosmo-abis + osmo-bsc and osmo-bts
<pespin_> and then deprecate sign_link_up
</pre>
<p>Related code map for BTS:<br /><pre>
log "Rx IPA RSL CONNECT IP=%s PORT=%u STREAM=0x%02x" --> e1inp_ipa_bts_rsl_connect_n(trx_nr)
e1inp_ipa_bts_rsl_connect [BTS connects TCP conn to BSC as requested by BSC]
e1inp_ipa_bts_rsl_connect_n
ipa_client_conn_create (set priv_nr E1INP_SIGN_RSL+trx_nr, read_cb=ipaccess_bts_read_cb updown_cb=ipaccess_bts_updown_cb
[BSC SENDS US A ID GET/REQ]
ipaccess_bts_read_cb
ipaccess_bts_handle_ccm
ops->sign_link_up (on ID_GET)
</pre></p>
<p>On the other hand, sign_link_up on BSC expects E1INP_SIGN_RSL to not contain the trx_num, that's why <code>ipaccess_rcvmsg</code> in libosmo-abis/src/input/ipaccess.c:168 calls it this way: <br /><pre>
line->ops->sign_link_up(&unit_data, line, E1INP_SIGN_RSL);
</pre></p> OsmoBSC - Feature #3330 (New): osmo-bsc: Implement IMMEDIATE ASSIGNMENT EXTENDEDhttps://projects.osmocom.org/issues/33302018-06-08T12:14:49Zpespin
<p>See 04.08 "9.1.19 Immediate assignment extended". It allows to send two Immediate Assignment to different MS in the same message.</p>
<p>Furthermore, according to 08.58 "5.7 IMMEDIATE ASSIGNMENT" section:</p>
<pre>
The IMMEDIATE ASSIGNMENT EXTENDED message is either sent by the BSC in the IMMEDIATE ASSIGN
COMMAND, or built by the BTS from up to two IMMEDIATE ASSIGN COMMAND messages.
</pre>
<p>It's probably more useful to implement it in osmo-bts (see <a class="issue tracker-2 status-1 priority-2 priority-default" title="Feature: osmo-bts: Implement IMMEDIATE ASSIGNMENT EXTENDED (New)" href="https://projects.osmocom.org/issues/3329">#3329</a>), but we may still want to support it in osmo-bsc if we connect to non osmo-bts which don't craft IMMEDIATE ASSIGNMENT EXTENDED from regular IMMEDIATE ASSIGNMENT on their own. I imagine for instance an scenario osmo-bsc<->nanobts.</p>
<p>We recently saw some production scenarios which high load in which the AGCH IMM Assign queue was saturated (1000 messages in the queue), so this should help maintain the queue len in lower numbers.</p> OsmoBTS - Feature #3329 (New): osmo-bts: Implement IMMEDIATE ASSIGNMENT EXTENDEDhttps://projects.osmocom.org/issues/33292018-06-08T12:02:32Zpespin
<p>See 04.08 "9.1.19 Immediate assignment extended". It allows to send two Immediate Assignment to different MS in the same message.</p>
<p>Furthermore, according to 08.58 "5.7 IMMEDIATE ASSIGNMENT" section:</p>
<pre>
The IMMEDIATE ASSIGNMENT EXTENDED message is either sent by the BSC in the IMMEDIATE ASSIGN
COMMAND, or built by the BTS from up to two IMMEDIATE ASSIGN COMMAND messages.
</pre>
<p>So we don't need to support IMMEDIATE ASSIGNMENT EXTENDED in osmo-bsc, we can already craft them in osmo-bts (bts.c) in a way similar to what we already do with IMMEDIATE ASSIGNMENT REJECT commands (we couple up to 4 messages in one in there).</p>
<p>We recently saw some production scenarios which high load in which the AGCH IMM Assign queue was saturated (1000 messages in the queue), so this should help maintain the queue len in lower numbers.</p> Cellular Network Infrastructure - Feature #3229 (New): build-system: jenkins.sh: Improve debian ...https://projects.osmocom.org/issues/32292018-05-03T12:40:28Zpespin
<p>The idea is to add extra tests/checks to avoid breaking debian package building during nightly builds in OBS. Instead, let's catch it during gerrit patch submission time and don't allow merging it until it's fixed.</p>
<p>We should investigate several tools, like pbuilder, dpkg-build, etc. I recall lynxis also told me something about some kind of lint tool available for this purposes.</p> OsmoBTS - Feature #3155 (Stalled): execute BTS_Tests.ttcn with real (C123) phone hardware in LTHW...https://projects.osmocom.org/issues/31552018-04-10T16:28:12Zlaforge
<p>We want to execute the BTS_Tests.ttcn against all real hardware BTS models of our LTHW setup.</p>
<a name="Hardware-Setup"></a>
<h2 >Hardware Setup<a href="#Hardware-Setup" class="wiki-anchor">¶</a></h2>
On the hardware side, his means, we need to
<ul>
<li>add a C123 with RF cabling to the "modem ports" of the setup</li>
<li>be able to power cycle this C123 from software</li>
<li>attach the C123 UART via CP2103 USB-UART to the main unit</li>
</ul>
<a name="Software-Setup"></a>
<h2 >Software Setup<a href="#Software-Setup" class="wiki-anchor">¶</a></h2>
<p>We will need to be able to execute the BTS_Tests.ttcn on the gsm tester main unit. This could be done either natively or via the existing docker containers. In any case, we don't want to <strong>build</strong> the ttcn source on the low-power APU, but we want that the compiled test suite is copied/transferred to the APU and then executed there.</p>
<p>We also want to make sure that we have proper locking/exclusivity with the osmo-gsm-tester stack, so that we either run osmo-gsm-tester or BTS_Tests.ttcn.</p>
<p>Finally, this should all be started from jenkins.osmocom.org.</p>
<p>It probably makes sense (as usual) to start with the R&D setup and then replicate the setup in production.</p> Cellular Network Infrastructure - Feature #3142 (New): Further simplification of "NITB like" setupshttps://projects.osmocom.org/issues/31422018-04-05T20:09:38Zlaforge
<p>Running the post-NITB network is quite a lot more complex than the old code.</p>
<p>There are some ideas on how to make it simpler to run small, self-contained networks while removing some complexity</p>
<ul>
<li>I was also wondering if we should spend time on "MGW-less operation". In theory, you only need OsmoMGW if you have no IP-level routing between your Abis / A / core network [like any decent network operator for security reasons]. But then, if you run everything on one machine, and don't need/want transcoding, and have transparent routing between all components, we could do without the MGW.</li>
</ul>
<ul>
<li>stp-less operation should also be possible (but make configuration actually more complicated), as both the "ASP" (client) and "SG" (server) role are inside libosmo-sigtran, and hence the server could run inside the MSC without the need of an external stp (osmo-stp is just a thin wrapper with vty around libosmo-sigtran)</li>
</ul>
<p>Let's keep this as a reminder and create sub-tasks as ideas materialize more</p> OsmoBTS - Bug #2675 (New): /usr/bin/lc15bts-mgr can't find GPS 3D fix to for calibrationhttps://projects.osmocom.org/issues/26752017-11-22T16:42:02Zrshack
<p>Hi,</p>
<p>We have a Litecell 1.5 unit. It is updated to the latest packages on the nightly build and configured to an osmo-bsc set up on an another machine.</p>
<p>On mobile phones, the network does not show the short or long name set, instead it shows just numbers "09070" and calls can not be made.</p>
<p>This has happened to us before when there was problem with the clock calibration on the BTS.</p>
<p>A GPS device is attached to the BTS, and when running cgps, there is a 3D Fix and a correct GPS location coordinates show up.</p>
<p>The lc15 bts should be able to calibrate automatically using the lc15bts-mgr package, however, it seems like it is failing to do so.</p>
<p>When we tried stopping the lc15bts-mgr service and start it manually to log the output by running:</p>
<pre>
/usr/bin/lc15bts-mgr -s -c /etc/osmocom/lc15bts-mgr.cfg
</pre>
<p>We notice the following errors:</p>
<pre>
Failed to open /mnt/storage/var/run/lc15bts-mgr/volt-supply-max due to 'No such file or directory' error
<0000> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_misc.c:315 Total hours of Operation: 393
<0003> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_mgr_calib.c:271 Going to calibrate the system.
<0003> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_mgr_calib.c:121 Last GPS 3D fix can not read (-2). Last GPS 3D fix sets to zero
<0003> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_mgr_calib.c:126 GPS has no fix
<0004> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_swd.c:126 Going to check for watchdog notification.
<0004> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_swd.c:67 Missing watchdog events: e:0x000000000000002e,m:0x000000000000007f
<0004> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_swd.c:126 Going to check for watchdog notification.
<0004> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_swd.c:67 Missing watchdog events: e:0x000000000000002f,m:0x000000000000007f
<0003> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_mgr_calib.c:271 Going to calibrate the system.
<0003> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_mgr_calib.c:121 Last GPS 3D fix can not read (-2). Last GPS 3D fix sets to zero
<0003> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_mgr_calib.c:126 GPS has no fix
<0004> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_swd.c:126 Going to check for watchdog notification.
<0004> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_swd.c:67 Missing watchdog events: e:0x000000000000002f,m:0x000000000000007f
</pre>
<p>It seems the lc15bts_mgr service can not read the values from the GPS device for some reason, can someone please advise what might be causing this issue?</p>
<p>Best Regards,<br />Rayan</p> OsmoBTS - Bug #2674 (New): osmo-bts-sysmo GPRS failing if running without "-M"https://projects.osmocom.org/issues/26742017-11-22T13:58:14Zpespin
<p>In osmo-gsm-tester setup (CN+BSC running in main unit, BTS+PCU in sysmobts).</p>
<p>RUnning osmo-bts-sysmo with -M (pcu direct access to PHDATA) works fine.</p>
<p>If run without -M, then the phdata_ind packets are printed in uplink GSMTAP (by function to_gsmtap()), but never arrive to the osmo-pcu through the unix socket, and then osmo-pcu neves sends Attach Request to osmo-sgsn.</p>
<p>What I debugged so far:<br />The packets arrive to l1sap.c:l1sap_up():<br /><pre>
case OSMO_PRIM(PRIM_PH_DATA, PRIM_OP_INDICATION):
to_gsmtap(trx, l1sap);
rc = l1sap_ph_data_ind(trx, l1sap, &l1sap->u.data);
break;
</pre></p>
<p>In there the packet is sent through GSMTAP, but l1sap_ph_data_ind() is returning -22 (EINVAL).</p>
<p>I verified that indeed that einval comes from l1sap.c:l1sap_ph_data_ind() code path which returns early and doesn't send content of the message through the unix socket:<br /><pre>
static int l1sap_ph_data_ind(struct gsm_bts_trx *trx,
struct osmo_phsap_prim *l1sap, struct ph_data_param *data_ind)
{
struct msgb *msg = l1sap->oph.msg;
uint8_t *data = msg->l2h;
int len = msgb_l2len(msg);
...
if (ts_is_pdch(&trx->ts[tn])) {
...
/* don't send bad frames to PCU */
if (len == 0) {
LOGP(DL1P, LOGL_ERROR, "pespin: len==0, avoid send to pcu\n");
return -EINVAL;
}
...
pcu_tx_data_ind(...)
...
}
</pre></p>
<p>I see several possible issues there:<br />- In lower layers (l1) in osmo-bts-sysmo, we are not packing the indication correctly into the msgb.<br />- We are not doing the correct check in l1sap_ph_data_ind() and there's good information in the packets.<br />- We are not doing the correct check in to_gsmtap() if the packet is actually containing non correct data. We should avoid sending it and logging a NOTICE or similar instead.</p> Cellular Network Infrastructure - Feature #2554 (New): Reference/Demo setup + documentation for u...https://projects.osmocom.org/issues/25542017-10-06T14:39:27ZlaforgeOsmoBSC - Feature #1946 (New): Add checks to the BSC VTY to prevent configurations known to not workhttps://projects.osmocom.org/issues/19462017-02-08T23:41:53Zneelsnhofmeyr@sysmocom.de
<p>e.g. running TCH/F_TCH/H_PDCH timeslots on a nanobts doesn't work,<br />similarly, the BS11 should reject any codec except HRv1, FR and EFR (i.e. no AMR),<br />and so on.</p> OsmoBTS - Feature #1755 (New): osmo-bts-sysmo L1: unify hLayer3 handlinghttps://projects.osmocom.org/issues/17552016-06-16T11:27:40Zneelsnhofmeyr@sysmocom.de
<p>In <a class="external" href="https://gerrit.osmocom.org/264">https://gerrit.osmocom.org/264</a> , some hLayer3 use was added.<br />However, some of the messages were already using hLayer3.</p>
<p>After the patch, the prim_init() sets a hLayer3 which is overwritten<br />shortly after that, so the other functionality is not affected by this patch.</p>
<p>Some functions to generate hLayer3 for a timeslot and similar already existed,<br />and also to retrieve a timeslot and similar back from a hLayer3 handle.</p>
<p>And also, the other hLayer3 functions use a "magic" byte<br />(like the most significant byte always set to 0xbb).</p>
<p>So in fact, we should have rejected this patch, and we should follow up with<br />a merger of my hLayer3 to the existing hLayer3 infrastructure.<br />The priority is low though, since no harm is done.</p>
<p>See:</p>
<ul>
<li>osmo-bts/src/osmo-bts-sysmo/oml.c
<ul>
<li>mph_send_activate_req()</li>
<li>mph_send_config_logchpar()</li>
<li>mph_send_config_ciphering()</li>
<li>mph_send_deactivate_req()</li>
</ul></li>
</ul> Cellular Network Infrastructure - Bug #1612 (New): more configuration consistency checkinghttps://projects.osmocom.org/issues/16122016-02-23T16:22:14Zlaforge
<p>Right now it is possible to configure various things that wouldn't work, like an ARFCN that is outside the band of the BTS, or even the TRX.</p>
<p>More consistency checks would make sense, together with reasonable error messages.</p> OsmoBTS - Feature #1576 (New): consider using hLayer2 as a pointer storagehttps://projects.osmocom.org/issues/15762016-02-23T15:38:30Zlaforge
<p>This would speed up the l1if_hLayer_to_lchan lookup. Not sure if it's worth the extra risk.</p>