Open Source Mobile Communications: Issues 2019-12-10T14:39:13Z Open Source Mobile Communications Redmine osmo-pcap - Bug #4317 (New): external tests not enabled in 2019-12-10T14:39:13Z osmith <p>The external tests are not running in jenkins. As time of writing, they were broken because the config paths were wrong. I'll submit a patch to fix that.</p> <p>With that fix, the first 3 tests are running now. However, it fails later:</p> <pre> Failed to verify src/osmo-pcap-client -c /home/user/code/osmo-dev/src/osmo-pcap/doc/examples/osmo-pcap-client/osmo-pcap-client-tls.cfg Current directory: /home/user/code/osmo-dev/src/osmo-pcap Error was [Errno 111] Connection refused </pre> <p>Running the command manually:<br /><pre> $ src/osmo-pcap-client -c /home/user/code/osmo-dev/src/osmo-pcap/doc/examples/osmo-pcap-client/osmo-pcap-client-tls.cfg &lt;0005&gt; ../../../../src/libosmocore/src/vty/telnet_interface.c:104 Available via telnet 4237 &lt;0001&gt; osmo_client_core.c:296 Failed to open the device: any: You don't have permission to capture on that device (socket: Operation not permitted) &lt;0001&gt; osmo_client_core.c:234 Filter will only be applied later. Error occurred during reading the below line: pcap filter host Failed to set the device. &lt;0001&gt; osmo_client_main.c:236 Failed to parse the config file: /home/user/code/osmo-dev/src/osmo-pcap/doc/examples/osmo-pcap-client/osmo-pcap-client-tls.cfg </pre></p> <p>With setcap, the tests are passing:<br /><pre> $ sudo setcap 'CAP_NET_RAW+eip CAP_NET_ADMIN+eip' src/osmo-pcap-client </pre></p> <p>However, sudo is not configured in docker, so we can't do that in</p> OsmoHLR - Bug #4312 (New): GSUP keepalives / connection loss detection 2019-12-06T17:44:45Z neels <p>In the presence of unreliable back-haul mesh between villages, the GSUP<br />connection can also not be seen as reliable. We would expect to see TCP<br />stalls due to packet loss, etc.</p> <p>Have you considered this in your implementation and/or done any testing<br />based on simulated lossy networks to ensure we properly use either TCP<br />keepalives or IPA application-level PING/PONG to detect lost connections<br />and recover from such situations (by closing the old and<br />re-establishing)?</p> <p>Unreliable networks can be easily simulated by Linux built-in 'tc netem'<br />for providing configurable packet loss / latency / jitter.</p> <p>I also saw some comments / code related to "if a second connection using<br />the same IPA ID arrives, we're screwed" (paraphrasing here). I would<br />expect this not to be uncommon even if every MSC/HLR out there is<br />configred correctly exactly because e.g .the remote MSC/HLR has already<br />decided that the TCP/GSUP is dead and starts to reconnect by performing<br />a local-end release, while the "local" MSC/HLR still thinks the old<br />connection is alive. If the old connection "wins" (i.e. is preferred)<br />I see potential trouble here.</p> <p>Situations like that probably warrant some carefully designed tests to<br />create exactly those situations.</p> <p>Goals:<br />a) ensuring that keepalive on either TCP or IPA is enabled and works, and<br />b) creating situations where the same peer establishes a second new connection<br /> while the old one is still not torn down (timeout not expired yet, FIN packets<br /> lost, ...)</p> <p>(Keeping as one issue because these aspects are tightly related...)</p> libosmocore - Feature #4311 (New): blocking stderr output inhibits the program? 2019-12-06T13:33:06Z neels <p>I'm currently using urxvt (rxvt-unicode) as terminal program (not sure why, but...)<br />and I am every now and then seeing odd behavior when the terminal is scrolled up into scrollback, so that new output lines are not seen.</p> <p>It seems to me that after a while urxvt stops reading from stdout/stderr. That is weird enough in itself, but the Osmocom related problem:<br />Apparently the server program stops interacting when the log output stops reading?</p> <p>Even though stderr (or any other log target) is not writable, IMO we should still continue to serve all protocols as usual.<br />A blocking log target should not affect server operation.</p> <p>Investigate whether my vague impression is correct and find ways to fix that in logging.c.</p> osmo-sip-connector - Bug #4310 (New): sends BYE to self 2019-12-05T11:15:09Z neels <p>During analysis of a pcap of a short call, I noticed that the final SIP ACK as well as BYE goes back to its own address.<br />This is using osmo-sip-connector and Kamailio</p> <p>This is a text representation of the entire SIP negotiation,<br />the point being the last three 'SIP->(self)' in the end.</p> <p>(MO -> sipcon -> kamailio -> sipcon -> MT)<br /><pre> SIP2 sip.***New:SIP2= 452 SIP sip.***New:SIP= 452 SIP---&gt;SIP2 sip.INVITE udp{'src'='', 'dst'=''} 452 SIP&lt;---SIP2 sip.INVITE-trying udp{'src'='', 'dst'=''} 460 SIP&lt;---SIP2 sip.INVITE udp{'src'='', 'dst'=''} 462 SIP---&gt;SIP2 sip.INVITE-Trying udp{'src'='', 'dst'=''} 469 SIP---&gt;SIP2 sip.INVITE-Ringing udp{'src'='', 'dst'=''} 1200 SIP&lt;---SIP2 sip.INVITE-Ringing udp{'src'='', 'dst'=''} 1202 SIP---&gt;SIP2 sip.INVITE-OK udp{'src'='', 'dst'=''} 1324 SIP&lt;---SIP2 sip.INVITE-OK udp{'src'='', 'dst'=''} 1328 SIP-&gt;(self) sip.ACK udp{'src'='', 'dst'=''} 1353 SIP-&gt;(self) sip.BYE udp{'src'='', 'dst'=''} 1702 SIP-&gt;(self) sip.BYE-OK udp{'src'='', 'dst'=''} 1706 </pre><br />(the final numbers are the packet index in the attached pcap;<br />output generated by 'osmo-gsm-shark -f short_call_flt.pcapng --filter-msg sip --show-traits udp')</p> <p>I'm not entirely sure whether that is intended, i.e. that Kamailio connects both peers and takes itself out of the loop (like it does with RTP),<br />and I can in fact find a 'Contact URI' in the SIP package that might intend to do that, but it has no port number?<br />Or is it the 'Via' header ... ?</p> <p>Figure this out to see whether osmo-sip-connector has a bug.</p> Distributed GSM - Feature #4309 (In Progress): MOSS stage 2 review item: mslookup mDNS: add IANA ... 2019-12-04T16:08:28Z neels <p>add '' or '' or '' to the URL string sent in mDNS queries.<br />We could add it all around end-to-end, or just on the wire in the DNS packets: add when sending and strip when receiving.</p> <p>- Only on the DNS wire makes sense when considering that if we invent other methods for mslookup, it might be by GSUP or whatever, which doesn't compete with IANA naming.<br />- end-to-end makes sense when trying to be conform / similar across all query methods.</p> <p>I think I slightly favor only on the DNS wire.</p> <p>So that in osmo_mslookup_client all we see is still, as now, 'sip.voice.12345.msisdn', but in DNS packets sent and received we have ''</p> Distributed GSM - Support #4308 (New): thoughts about incorporating credit / billing in D-GSM 2019-12-04T14:04:46Z neels <p>it is not a priority to really implement a working setup, but we should have a bit of a plan for the future, to not block progress later.</p> <p>- how could credit management be standardized?<br />- how to handle link loss? keep a set amount of credit on each site to use even if the subscriber's home village is unreachable?<br />- think about credit for: voice, sms, data connections.<br />- Look at DIAMETER accounting specs, CCR / CCA <a class="external" href=""></a></p> Distributed GSM - Feature #4307 (In Progress): test routing SMS-over-GSUP in DGSM 2019-12-04T13:59:47Z neels <p>route an SMS via osmo-hlr directly to the target MSC and see what happens.</p> Distributed GSM - Feature #4306 (New): GSUP proxy cache: store data persistently 2019-12-04T13:58:28Z neels <p>when we store auth tuples (<a class="issue tracker-2 status-1 priority-3 priority-high3" title="Feature: GSUP proxy: cache auth tuples to re-use / fall back to simpler auth methods (New)" href="">#4305</a>), even a local power outage should retain those tuples in the proxy.</p> <p>options:<br />- store in the HLR DB<br />- just dump to a local .csv file to recover on startup</p> Distributed GSM - Feature #4305 (New): GSUP proxy: cache auth tuples to re-use / fall back to sim... 2019-12-04T13:56:41Z neels <p>if a link goes away, we'd like to still allow continued operation for some time.</p> <p>Goals:</p> <p>- we don't want to replicate the auth keys themselves; just ask for tuples from the home HLR.<br />- for a later attach, assume the link to home hlr is broken.<br />- we have cached the previous auth tuples and attempt to re-use them.<br />- Maybe we have asked for N more tuples on auth tuple request.<br />- milenage sqn: use a separate SQN IND bucket for each site, so going back to a previous site will be fine with SQN number jumps.<br />- if that doesn't work, fall back to 2G auth if possible.<br />- if that doesn't work, fall back to no auth (for some time/during link failure, for continued service)</p> libosmocore - Bug #4304 (New): missing unit tests for many gsm48_{encode,decode} functions 2019-12-04T13:50:28Z laforge <p>At least the following functions regarding GSM 04.08 IE encode/decode are in lack of unit tests:</p> <pre> + /* gsm48_{en,de}code_cccap() */ + /* gsm48_{en,de}code_called() */ + /* gsm48_{en,de}code_callerid() */ + /* gsm48_{en,de}code_cause() */ + /* gsm48_{en,de}code_facility() */ + /* gsm48_{en,de}code_notify() */ + /* gsm48_{en,de}code_signal() */ + /* gsm48_{en,de}code_keypad() */ + /* gsm48_{en,de}code_progress() */ + /* gsm48_{en,de}code_useruser() */ + /* gsm48_decode_ssversion() */ + /* gsm48_encode_more() */ </pre> OsmoHLR - Bug #4303 (New): various minor issues about evaluation of rc = db_subscr_get_by_*() 2019-12-03T22:56:57Z neels <p>vty function 'subscriber imsi IDENT create':</p> <p>We create the subscriber, and then db_subscr_get_by_imsi(), which might produce an error.<br />It's unlikely since creationg rc is evaluated just before that, but still.<br />If the rc returns an error, we should echo that to the VTY user.</p> <pre> rc = db_subscr_get_by_imsi(g_hlr-&gt;dbc, imsi, &#38;subscr); vty_out(vty, "%% Created subscriber %s%s", imsi, VTY_NEWLINE); subscr_dump_full_vty(vty, &#38;subscr); return CMD_SUCCESS; } </pre> OsmoTRX - Feature #4301 (In Progress): set up raspi4 build slave for jenkins 2019-12-03T16:44:07Z laforge <p>given the long standing OS#3061 and lack of progress in upstream, we decided to avoid cross-compilation and add a raspi4 based build slave to jenkins.</p> <p>I ordered a raspi4 with 4GB and 64GB high-performance uSD card as well as a power supply and a large heatsink with fan.</p> <p>Please assemble the unit and install raspbian 10 on it. I would argue it could go in our enclosd 19" rack next to the firewall, in the "osmocom jenkins reachable" vlan.</p> <p>Once there is my ssh key on it, I'm happy to try running our normal build-slave ansible playbook against it and check if any x86/arm specifics need t obe ironed out there.</p> OsmoBSC - Bug #4300 (Feedback): osmo-bsc segfaults when logging is enabled 2019-12-03T14:37:10Z roh <p>to reproduce:</p> <p>run osmo-bsc in terminal (to see the segfault)</p> <p>telnet localhost 4242<br />enable<br />logging enable<br />logging filter all 1<br />logging level force-all debug<br />close connection via &lt;ctrl-d&gt;</p> <pre> usr/bin/osmo-bsc -c /etc/osmocom/osmo-bsc.cfg -s logging level cc (debug|info|notice|error|fatal) logging level mgcp (debug|info|notice|error|fatal) % dyn_ts_allow_tch_f is deprecated, rather use msc/codec-list to pick codecs &lt;0013&gt; ../../../git/src/vty/telnet_interface.c:104 Available via telnet 4242 &lt;0015&gt; ../../git/src/input/ipaccess.c:859 enabling ipaccess BSC mode on with OML 3002 and RSL 3003 TCP ports &lt;001a&gt; ../../../git/src/ctrl/control_if.c:911 CTRL at 4249 &lt;0023&gt; ../../../git/src/libosmo-mgcp-client/mgcp_client.c:777 MGCP client: using endpoint domain '@mgw' &lt;0007&gt; ../../../git/src/osmo-bsc/osmo_bsc_sigtran.c:494 Initializing SCCP connection to MSC msc-0 ... BTS 0 reported connected PCU version 0.7.0 BTS 0 reported connected PCU version 0.7.0 BTS 0 reported connected PCU version 0.7.0 Segmentation fault (core dumped) </pre> <p>the same happens when 'set-all' is used (not only with 'force-all'</p> osmo-remsim - Bug #4299 (New): proper libusb/libosmocore select loop integration 2019-12-03T00:26:03Z laforge <p>This would register the libusb fds with libosmocore select.c code to asynchronously notify libusb if any of its fds are readable/writable.</p> <p>Same code can be used from osmo-e1d and simtrace2 host code.</p> osmo-remsim - Bug #4298 (New): remsim-client: use new libosmo-simtrace2 from simtrace2.git 2019-12-03T00:23:32Z laforge <p>osmo-remsim currently uses copy+pasted code. Let's avoid that by using the newly provided shared library from simtrace2.git</p> OsmoGSMTester - Feature #4297 (New): osmo-gsm-tester "core 4g support" 2019-12-02T14:06:53Z laforge <p>This includes the conceptual changes / extensions required for 4G support, irrespective of any specific eNB or EPC in use.</p> I would guess this covers common parameters of a eNB such as <ul> <li>bandwidth (number of PRB)</li> <li>eARFCN</li> <li>eNB-ID</li> <li>PCID (physical cell ID)</li> <li>band support</li> </ul> OsmoGSMTester - Feature #4296 (New): support for executing srsEPC as LTE core 2019-12-02T13:58:26Z laforge we'd have to parametrize the "usual" stuff, including <ul> <li>K/OPc/algo of the subscribers/SIM cards</li> <li>IP address on which to bind the S1 interface towards the eNB</li> </ul> OsmoGSMTester - Feature #4295 (New): support for executing srsENB on USRP B2xx hardware 2019-12-02T13:56:16Z laforge we'd have to parametrize settings like <ul> <li>eARFCN</li> <li>gain values ({rx,tx}_gain)</li> <li>enb_id, cell_id, phy_cell_id</li> <li>bandwidth (n_prb)</li> <li>MCC/MNC/TAC</li> <li>ip address of the S1 interface on the EPC side (mme_addr)</li> <li>ip address to bind the S1 interface of the eNB to ({gtp,s1c}_bind_addr)</li> <li>logfile</li> <li>pcap file</li> </ul> Osmocom Conferences (OsmoDevCon + OsmoCon) - Bug #4293 (In Progress): CfP for OsmoDevCon 2020 2019-12-01T10:52:45Z laforge osmo-ccid-firmware - Feature #4291 (New): hardware setup with OCTSIM attached to a jenkins build ... 2019-11-30T15:02:40Z laforge <p>The idea here is to have a sysmoQMOD attached to one designated jenkins build slave (could be the "left APU" in the 19" rack which also runs sim card reader tests? or any other suitable machine?).</p> <p>Having this unit would allow us to run tests such as the TTCN3 CCID_Tests test suite.</p> The unit should have <ul> <li>dedicated, known SIM cards inserted in all but one slot(so we can execute tests both against present and absent slots)</li> <li>ability to completely power cycle the unit via USB (upstream hub port must support usb power switching)</li> <li>ideally, also a way by which we can press the "DFU" button programmatically to update the SAME54x firmware</li> </ul> <p>Lets try to sort out how we can achieve this in a safe manner.</p> osmo-ccid-firmware - Bug #4290 (New): have firmware version in USB descriptor (like simtrace2) 2019-11-30T14:58:50Z laforge osmo-ccid-firmware - Feature #4289 (New): have chip-unique serial number in iSerial string on USB 2019-11-30T14:58:25Z laforge OsmoPCU - Feature #4286 (New): Support configuration using 8PSK on dowlink while staying GSMK-onl... 2019-11-28T13:58:45Z pespin <p>Ensure and test that ocmo-pcu can actually deal with 8PSK only in downlink.</p> <p>The 3GPP specifications permit 8PSK only in downlink and GMSK only in uplink. The question is whether our implementation deals with this properly.</p> <p>This behavior is completely 3GPP Compliant, as EGPRS specifies 9 MCS, only half of which are 8PSK while the others are GMSK. The choice of coding schemes is entirely under network control, so we can instruct the MS/UE to transmit always in GMSK only.</p> <p>Scenario: an L1 may support transmitting 8PSK but not support it on the receiver side.</p> <p>Given that most traffic is present mostly on the downlink, this may make a big difference if L1 has such limitations.</p> OsmoBTS - Bug #4281 (New): MS power control loop is interrupted when bad frames are received 2019-11-26T13:25:54Z dexter <p>See <a class="external" href=""></a><br />When a bad frame is received the on l1sap.c, then it is checked if it was a SACCH frame and if it was only radio_link_timeout() is called. The function then exits with -EINVAL. However, later in the code one can find that there is a call to lchan_ms_pwr_ctrl(). We should not skip this step. Instead we should supply the power control loop so that it knows that the reception is not enough and the MS power must be increased.</p> <p>See also @pespin's comment at <a class="external" href=""></a>:<br />That means in this case lchan_ms_pwr_ctrl() is not called and the MS power loop is missing information. For instance it could mean the strength being used by the MS is not enough and precisely lchan_ms_pwr_ctrl() should be notified so that BTS can instruct the MS to increase the signal strength.</p> <p>If in this case we don't have block data (data<sup><a href="#fn0">0</a></sup>) then MS Power Level value is not available for lchan_ms_pwr_ctrl(). In that case I'd probably makes sense to pass a special value to it, for instance -1, so that it knows the value is not available. Internally it can then for instance use lchan->ms_power_ctrl.current as input for calculations, or simply raise the current MS Power level if rssi is detected to be bad.</p> SIMtrace 2 - Support #4280 (New): “Insert SIM card” message 2019-11-26T12:08:39Z OSMOCOMER <p>When I connect SimTrace2 to my phone I always get “Insert SIM card” message on the csreen of the phone.<br />There are 2 LEDs on the board are lighting well.<br />How to check the hardware?<br />And how to connect the board to PC correctly?</p> <p>I use SIMtrace 2,<br />v1.4,<br />Serial 01225</p> Cellular Network Infrastructure - Feature #4277 (New): implement an SMSC to work with OsmoMSC 2019-11-22T14:45:20Z neels <p>The single remaining legacy from OsmoNITB that is still present in OsmoMSC is the integrated SMS database.<br />It would be nice to be able to offload SMS delivery to a separate SMSC process.<br />It would be appropriate to implement that using SMS-over-GSUP, and connect the SMSC to OsmoHLR as GSUP client.</p> OsmoSTP - Feature #4275 (New): Add TTCN3 STP_Tests_IPA.TC_tmt_broadcast 2019-11-21T15:52:09Z pespin <p>The broadcast traffic mode was implemented for both M3UA and IPA in osmo-stp in libosmo-sccp.git af55d4a4a4368d20bc395a5c4712a612b7d954d7.</p> Test already exists for STP_Tests_M3UA, but it's missing in IPA.<br />This task is a reminder to add the test. Steps: <ul> <li>Copy and adapt the test from STP_Tests_M3UA similarly to how it was done for TC_tmt_override and TC_tmt_broadcast.</li> <li>New ASPs and AS need to be added to docker-playground.git's ttcn3-stp-test/osmo-stp.cfg with broadcast traffic mode configured.</li> </ul> OsmoSTP - Bug #4274 (New): AS Name isn't displayed 2019-11-21T10:47:29Z roch <p>Hi,</p> <p>It looks like AS Name isn't displayed properly even if both AS and ASPs are active.</p> <p>OsmoSTP# show cs7 instance 0 asp<br /> Effect Primary<br />ASP Name AS Name State Type Remote IP Addr:Rmt Port SCTP<br />------------ ------------ ------------- ---- ----------------------- ----------<br />stp2 ? ASP_ACTIVE m3ua <br />asp-dyn-0 ? ASP_ACTIVE ipa <br />asp-dyn-1 ? ASP_ACTIVE ipa</p> <p>OsmoSTP# show cs7 instance 0 as all<br /> Routing Routing Key Cic Cic Traffic<br />AS Name State Context Dpc Si Opc Ssn Min Max Mode<br />------------ ------------ ---------- ------------- ---- ------------- --- ----- ----- -------<br />STP2 AS_ACTIVE 56 0.8.6 loadshare<br />telnahub AS_ACTIVE 0 0.0.0 loadshare</p> Distributed GSM - Bug #4268 (In Progress): duplicate SMS when SMPP handler sends back to the orig... 2019-11-16T05:51:57Z neels <p>When receiving an SMS from a phone, the SMS is added to the sms.db, then handled.<br />When receiving an SMS from SMPP, also, the SMS is added to the sms.db, then handled.<br />Now, if handling the SMS sends it to SMPP, that SMPP decides (mslookup) that it goes back to the same MSC, then the same SMS comes back and is added again.</p> <p>When it is being delivered, the subscriber is connected, and hence SMS delivery is done immediately for both instances of the same SMS.<br />(IIUC this saves us an infinite MSC -> SMPP -> MSC -> SMPP loop)</p> <p>possible solutions...?</p> <p>- the SMPP handler must not send back to the same MSC, instead it must respond with "subscriber unknown" so that osmo-msc attempts to handle the SMS internally?<br /> Detect if the mslookup IP:port for SMS delivery == the esme handler's msc's SMPP IP:port.<br /> Breaks if more than one IP reaches the MSC's SMPP, e.g. osmo-msc listens on, the esme connects via and mslookup responds with a public IP :/</p> <p>- Somehow mark the SMS so that osmo-msc detects a round-trip SMS and avoids adding the same message to the db again?</p> <p>- Somehow mark SMS differently, by config: if smpp-first is on, then SMS received via RAN must never go back to RAN, received via SMPP may be delivered to RAN...</p> <p>- just before sending an SMS to SMPP, mark it in the DB as sent? (and if sending fails, undo that marking?)</p> <p>we can't really generally skip adding SMS to the DB, because in both cases of incoming SMS we need to first queue it in the DB, for spooling and everything else...</p> libosmocore - Bug #4265 (New): --enable-embedded doesn't work as expected 2019-11-12T11:18:36Z laforge <p>--enable-embedded is supposed to automatically set flags like --disable-libsctp. In theory that<br /> is implemented, but in practise it doesn't work, as the actual <strong>check</strong> is still performed, even if later down the configure[.ac] script we set ENABLE_LIBSCTP to "false". So we perform the check (and abort in case it isn't present), but later would discard the result.</p> <p>Re-ordering the blocks in to first have the embedded handling doesn't help. I guess we would need to take the "$embedded" variable into account somehow in each of the enable/disable clauses?</p> <p>Unless somebody knows a quick fix, it's not worth spending time on right now, but just for the record...</p>