Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092024-03-14T08:21:57ZOpen Source Mobile Communications
Redmine libosmocore - Feature #6402 (New): consider using IORING_RECVSEND_POLL_FIRST for our socket-readshttps://osmocom.org/issues/64022024-03-14T08:21:57Zlaforge
<p>io_uring has an IORING_RECVSEND_POLL_FIRST which will increase the performance of read/recv/recvmsg/recvfrom calls if no data is present in the socket at the time we submit a read.</p>
<p>This works by going directly into poll, bypassing the initial attempt to recv/recvmsg.</p>
<p>Given that our sockets are often very low traffic and work in a request/response fashion, this might be worth a shot.</p> libosmocore - Feature #6401 (New): benchmark batching io_uring operationshttps://osmocom.org/issues/64012024-03-14T08:10:59Zlaforge
<p>right now we <code>io_uring_submit()</code> reads/writes right when they are added. This triggers the kernel processing on those without the benefit of batching multiple operations.</p>
<p>We might want to try to benefit from batching by waiting until we enter osmo_select_main().</p> OsmoHNBGW - Feature #6395 (New): PFCP URR support in osmo-hnbgwhttps://osmocom.org/issues/63952024-03-08T13:38:17Zlaforge
<p>Implement basic support for URR (Usage Reporting Rule).</p>
The goal here is to use PFCP URR to instruct the UPF to:
<ul>
<li>count the number of packets and bytes within each TEID (ul/dl separately)</li>
<li>periodically report those counters via PFCP to the control plane</li>
<li>report the final counters when the tunnel is closed</li>
</ul>
<p>The osmo-hnbgw side then will have to report those packet/byte counters [at the very least] as per-hnb aggregate figures.</p>
<p>Until osmo-upf has the related features (<a class="issue tracker-2 status-7 priority-1 priority-lowest" title="Feature: Basic URR (Usage Reporting Rule) support for tunnel mapping (Stalled)" href="https://osmocom.org/issues/6394">#6394</a>), testing of the osmo-hnbgw side can be done against open5gs-upf, which should already suport it since <a class="user active" href="https://osmocom.org/users/30187">pespin</a> taught it URR support in April 2022.</p> OsmoUPF - Feature #6394 (Stalled): Basic URR (Usage Reporting Rule) support for tunnel mappinghttps://osmocom.org/issues/63942024-03-08T13:33:39Zlaforge
<p>Implement basic support for URR (Usage Reporting Rule).</p>
The goal here is to
<ul>
<li>count the number of packets and bytes within each TEID (ul/dl separately)</li>
<li>periodically report those counters via PFCP to the control plane</li>
<li>report the final counters when the tunnel is closed</li>
</ul>
<p><a class="user active" href="https://osmocom.org/users/30187">pespin</a> had implemented something like this for open5gs-upf in<br /><pre>commit fb8ebcdbeae0648e30d04fd016a956642131dddd
Author: Pau Espin Pedrol <pespin@sysmocom.de>
Date: Fri Apr 8 16:10:42 2022 +0200
[UPF] Add initial support for URR Usage Report (#1476)
</pre><br />and following commits.</p>
<p>Now sadly, open5gs-upf is more like a lab-grade upf and nothing that scales at all, and we hence have users of osmo-upf that use it for its fast kernel path.</p>
<p>The primary goal for this feature is the <em>tunnel mapping</em> case in a osmo-hnbgw co-located osmo-upf. The packet and byte counters hence will have to be added to the nftables rules.</p> libosmocore - Feature #6390 (New): port CTRL over to osmo_io / io_uringhttps://osmocom.org/issues/63902024-03-02T18:45:00Zlaforge
<p>In theory this should be fairly trivial to mogirate over. It uses a tx_queue anyway for writes today, so handing those msgb's over to osmo_io should be easy.</p>
<p>However, the user API of ctrl is a nightmare and it exposes a lot of internal details - among them are the use of ctrl_connection by a ctrl <strong>CLIENT</strong> from sysmobts_mgr.</p>
<p>Let's not do this now, the performance of CTRL is not that significant.</p> libosmocore - Feature #6389 (New): port VTY over to osmo_io / io_uringhttps://osmocom.org/issues/63892024-03-02T16:55:56Zlaforge
<p>The VTY uses its 'buffer' layer between writes by the software and writing to the acutal socket file descriptor. buffer_flush_all is currently used whenever the socket is write-able. So it's a pull model.</p>
<p>We'd probably have to change that logic to work the other way around: Once a buffer has a certain fill-level (or age?), proactively push it via osmo_io.</p>
<p>Unless somebody uses a lot of scripts acccessing the VTY, it's also unlikely that the syscall load of a human VTY user would place significant I/O load on an osmocom program. So it's not super criticial.</p> osmo-ePDG - VoWifi Evolved Packet Data Gateway - Feature #6354 (New): investigate UE behavior in ...https://osmocom.org/issues/63542024-02-07T16:10:55Zlaforge
<p>As we've seen in <a class="issue tracker-1 status-5 priority-2 priority-default closed" title="Bug: connect a real phone to the epdg to test strongswan ipsec configuration (Closed)" href="https://osmocom.org/issues/6114">#6114</a> it might be interesting to control the eDPG hostname so we can generate a certificate for it (signed by letsencrypt which presumably is trusted by default in unmodified android). It's not critical as EAP-only authentication appeared to be working in the test case there.</p>
<p>It would be good to find some time to test with a couple of different UE whether they actually respect the ePDG related files / configs that can be stored in the USIM/ISIM.</p>
<p>A quick look in TS 31.102 revaled:</p>
<ul>
<li><code>EF.ePDGId</code>
<ul>
<li>contains a TLV-wrapped IPv4, IPv6 or hostname of the ePDG</li>
</ul>
</li>
<li><code>EF.ePDGSelection</code>
<ul>
<li>control the <em>Selection of the ePDG</em> proceduer in the UE (3GPP TS 24.302)</li>
<li>contais a number of (plmn, epdg_priority, epdg_fqdn_indicator)
<ul>
<li>the epdg_fqdn_indicator state whether the <em>Operator Identifier FQDN</em>, or a <em>location based FQDN</em> format shall be used</li>
</ul></li>
</ul></li>
</ul>
<ul>
<li><code>EF.ePDGIdEm</code>
<ul>
<li>same as above, but for emergency calls</li>
</ul>
</li>
<li><code>EF.ePDGSelectionEm</code>
<ul>
<li>same as above, but for emergency calls.</li>
</ul></li>
</ul>
<p>So <code>EF.ePDGId</code> is really the most interesting one.</p> osmo-ePDG - VoWifi Evolved Packet Data Gateway - Feature #6345 (New): osmo-epdg: Implement SWm in...https://osmocom.org/issues/63452024-01-25T16:32:08Zpespin
<p>In current architecture of osmo-epdg, the process contains both the ePDG and the AAA Server nodes.</p>
<p>These 2 nodes speak Diameter SWm interface between them.</p>
<p>We may want to split the 2 nodes into 2 processes and properly implement SWm at some point, or use another AAA server implementation.</p>
<p>Anyway, creating the ticket as a reference point to look up/comment on related communication between ePDG and AAA nodes.</p>
Spec references:
<ul>
<li>TS 29.273 section 7</li>
<li>TS 23.402 (grep for "SWm")</li>
</ul> Cellular Network Infrastructure - Feature #6327 (New): Osmocom-build-tags-against-master job buil...https://osmocom.org/issues/63272024-01-11T20:17:59Zfixeria
<p>The idea behind this job is to check if [a limited set of] old tagged versions of various Osmocom projects can still compile with the most recent versions of Osmocom libraries.</p>
<p>I checked the build logs and found out that it's building the default configurations for Osmocom projects (no <code>--with-foo</code> flags passed to configure scripts).<br />For instance, the default build configuration for osmo-bts does not include any models except the <code>-virtual</code>, so <code>osmo-bts-{trx,sysmo,...}</code> are not covered.<br />Same applies to osmo-trx: we build only the common code, but not the <code>-uhd/-lms</code> variants.</p>
<p>The more complete configurations we build, the more chances we have to catch various backwards compatibility problems.<br />A good example is <a class="external" href="https://cgit.osmocom.org/osmo-ci/tree/coverity/build_Osmocom.sh">https://cgit.osmocom.org/osmo-ci/tree/coverity/build_Osmocom.sh</a>, where we do enable much more features / variants.<br />Maybe this code can be generalized and re-used somehow?</p> pySim - Feature #6315 (New): have test data for all supported fileshttps://osmocom.org/issues/63152023-12-23T09:33:25Zlaforge
<p>We long have the support for <code>_test_de_encode</code> and related class attributes specifiying per-file test data. This is still lacking for a number of files.</p>
<p>For some files it is easy to get real-world data, but for other files (specifically ADF.ISIM related, or mdoern DF.5GS) there simply are no real-world SIMs of production operators that would provide us with test data.</p>
<p>It might be worth looking at the UE/SIM conformance test specs, maybe those can help</p> OsmoPCU - Feature #6303 (New): Convert pcuif to TLV to make backwards compatibility more feasiblehttps://osmocom.org/issues/63032023-12-12T16:07:01Zosmith
<p>In a meeting today with <a class="user active" href="https://osmocom.org/users/30187">pespin</a> and <a class="user active" href="https://osmocom.org/users/67">fixeria</a>, we figured it would be useful to have a TLV based PCUIF protocol so we could extend it in the future without always breaking backwards compatibility. If it was backwards compatible, we would not need to have osmo-pcu, osmo-bts and osmo-bsc all speak the exact same PCUIF version as it is currently the case.</p> OsmoHNBGW - Feature #6285 (New): IUFP needs not CRCX in loopback modehttps://osmocom.org/issues/62852023-12-04T03:58:47Zneelsnhofmeyr@sysmocom.de
<p>doing CRCX in loopback mode was necessary for early 3G support in osmo-mgw.<br />We faked an IuUP Initialization ACK message using loopback and some header patching -- ugly.</p>
<p>osmo-mgw supports IuUP Initialization to work in any mode since I6c365559a7bd197349f0ea99f7a13b56a4bb580b.</p>
<p>osmo-msc has removed the loopback hack from its CRCX for IUFP in march 2023, and creates the initial IUFP conn in recvonly.<br />osmo-hnbgw should do the same.</p>
<p>Using loopback or not should be completely orthogonal to using IUFP or not.<br />So techincally, osmo-hnbgw is free to use loopback if it wants to.<br />But currently the only reason to use loopback was the IuUP hack -- with that gone, let's not keep a confusing RTP mode.</p> OCTOI - Osmocom Community TDM over IP - Feature #6246 (New): co-locate cisco 2811 for FrameRelay...https://osmocom.org/issues/62462023-11-06T13:48:35Zlaforge
<p>let's put a Cisco 2811 into the co-location, ideally with support for both X.25 as well as FrameRelay.</p>
<p>The idea would be to use it as basis for interop testing any Linux/FOSS work on X.25/framerelay routing/switching that would happen on the OCTOI hub.</p> OCTOI - Osmocom Community TDM over IP - Feature #6245 (New): co-locate cisco 2811 ITP/STP in data...https://osmocom.org/issues/62452023-11-06T13:46:23Zlaforge
<p>The Cisco 2811 is a nice small 1U system that can run as ITP ("Internet transfer point"), i.e. a SS7 STP with support for SIGTRAN and classic TDM.</p>
<p>cisco 2811 supports up to 4xE1 as TDM connection.</p>
let's
<ul>
<li>figure out if one can have multiple signaling timeslots/links on one E1</li>
<li>connect one or multiple E1 via TE820 to AVSt</li>
</ul> Retronetworking - Feature #6244 (New): scan more/all EWS(O) documentation laforge hashttps://osmocom.org/issues/62442023-11-01T21:50:15Zlaforge
<p><a class="user active" href="https://osmocom.org/users/7">laforge</a> has multiple folders full of low-level documentation even including circuit diagrams of the EWS-O (digitally controlled bu analog switched) EWSD predecessor.</p>
<p>Part one is at <a class="external" href="https://people.osmocom.org/laforge/ftz/FTZ-161D1_14-Teil1.pdf">https://people.osmocom.org/laforge/ftz/FTZ-161D1_14-Teil1.pdf</a> but the other parts apparently are not yet scanned/released</p> Cellular Network Infrastructure - Feature #6243 (New): vty cfg: make changing startup defaults of...https://osmocom.org/issues/62432023-11-01T00:56:38Zneelsnhofmeyr@sysmocom.de
<p>Sometimes our recommendation of what the usual/good setting should be for a given vty config item changes.<br />Then we have the problem that we cannot change it without endangering running installations,<br />and/or creating hassle for admins.</p>
<p>So how about a general mechanism in all of our config files in form of a vty command, maybe like this:</p>
<p>osmo-foo.cfg:<br /><pre>
defaults (v0|v1.5|v1.6)
</pre></p>
<p>so a user can decide when to make the cfg upgrade, independently from binary upgrades.</p>
<p>When 'defaults' is not specified, we would have to assume like 'defaults v0'.<br />(A bit more convenient for new users would be to add the newest available 'defaults' setting automatically somehow,<br />but I guess that also breaks the entire feature then, unless someone can think of an elegant way.)</p> libosmo-sccp + libosmo-sigtran - Feature #6241 (New): M3UA "Network Appearance" supporthttps://osmocom.org/issues/62412023-10-31T15:00:11Zlaforge
<p>M3UA has the notion of an (entirely optional) "Network Appearance" IE. We don't support it at all</p>
<p>The spec says:</p>
<blockquote>
<p><strong>Network Appearance</strong> - The Network Appearance is a M3UA local reference shared by SG and AS (typically an integer) that, together with an Signaling Point Code, uniquely identifies an SS7 node by indicating the specific SS7 network to which it belongs. It can be used to distinguish between signalling traffic associated with different networks being sent between the SG and the ASP over a common SCTP association. An example scenario is where an SG appears as an element in multiple separate national SS7 networks and the same Signaling Point Code value may be reused in different networks.</p>
</blockquote>
<p>Supporting this properly in libosmo-sigtran is likely non-trivial, as it means that everywhere where right now only the point code is considered, we need to consider point code + network appearance. This affects not only routing decisions, but it also affects things like peer addresses of SCCP connections.</p> Retronetworking - Feature #6237 (New): Design + Build PCBA for NE555 based fake fan rpm sensor https://osmocom.org/issues/62372023-10-30T01:38:59Zlaforge
<p>Sometimes one has to spoof fan rpm sensors.</p>
<p><a class="external" href="https://www.techidiots.net/notes/fake-fan-sensor">https://www.techidiots.net/notes/fake-fan-sensor</a> has a nice/simple design circuit. Let's build a simple PCBA around it, using parts available from JLCPCB, like</p>
<ul>
<li><a class="external" href="https://jlcpcb.com/partdetail/Hgsemi-LM555MTR/C356723">https://jlcpcb.com/partdetail/Hgsemi-LM555MTR/C356723</a> (NE555 clone)</li>
<li><a class="external" href="https://jlcpcb.com/partdetail/120172-3362P_1502/C118903">https://jlcpcb.com/partdetail/120172-3362P_1502/C118903</a> (potentiometer)</li>
</ul>
The board should have a
<ul>
<li>one or multiple 3-pin fan headers for the real fan (tacho line not connected)</li>
<li>one or multiple 3-pin fan headers (for jumper cables to mainboard)
<ul>
<li>only one of them used as power source, others have VCC disconnected</li>
<li>all of them get the same tacho signal</li>
</ul></li>
</ul> pySim - Feature #6211 (In Progress): decode security attributes _compact_ in human-readable way, ...https://osmocom.org/issues/62112023-10-06T08:59:16Zlaforge
<p>See <a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Bug: create_ef failed, Expected 9000 and got 6982: Command not allowed - Security status not satisfied (Resolved)" href="https://osmocom.org/issues/6178">#6178</a>: It would be great to add human-readable decode for those security attributes to pySim-shell... I think we already do that for <em>referenced</em> (via EF.ARR), but not for compact.</p> Retronetworking - Feature #6195 (New): Wiki page on Cisco *WIC-* line cards for 26xx/28xx serieshttps://osmocom.org/issues/61952023-09-27T12:47:42Zlaforge
<p>I have a large collection of various line cards (sync/async/BRI/E1/....). Let's create a wiki page about those line cards with some description and high-res PCB photographs.</p> Retronetworking - Feature #6194 (New): wiki page on MultiTech MT5600-BLhttps://osmocom.org/issues/61942023-09-27T12:46:25Zlaforge
<p>I have recently obtained three MT5600-BL 4-wire leased line modems. Let's create a wiki page with PCB photogrphs etc.</p> Retronetworking - Support #6193 (New): Replace "event rack" PM3 power supplyhttps://osmocom.org/issues/61932023-09-27T12:14:08Zlaforge
<p>Today I wanted to test the <a class="wiki-page" href="https://osmocom.org/projects/retronetworking/wiki/Event_Setup">Event_Setup</a> ahead of CC2023 and noticed that the PM3 won't power up :(</p>
<p>Luckily I have a few spare PM3 around so I could replace the broken PSU with one from another unit.</p>
<p>As I've now already seen two PM3 with broken PSU, let's make sure to replace them in all of them according to the procedure I documented in <a class="wiki-page" href="https://osmocom.org/projects/retronetworking/wiki/Livingston_Portmaster_3">Livingston_Portmaster_3</a></p> OsmoBTS - Feature #6167 (New): csd_v110: implement rate adaptation for TCH/F14.4https://osmocom.org/issues/61672023-09-01T11:58:07Zfixeria
<p>We do implement scheduling of TCH/F14.4 in osmo-bts-trx, however the rare adaptation is missing. This is why current osmo-bts-trx would NACK CHANnel ACTIVation attempts for this data rate. The rate adaptation functions for TCH/F14.4 are different from the ones employed for TCH/F9.6, TCH/F4.8, and TCH/F2.4. According to 3GPP TS 48.020, chapter 10, we would need to implement RA1'/RAA' and RA1'/RAA". Other relevant specs: 3GPP TS 44.021 and 3GPP TS 48.060.</p> pySim - Feature #6104 (New): reduce number of python dependencieshttps://osmocom.org/issues/61042023-07-20T15:52:39Zlaforge
<p>In terms of overall dependency reduction, I think by refactoring we can get rid of pytlv (we have much more powerful TLV code in pySim internally now). We should also be able to get rid of bidict. For pyyaml I don't even know why we depend on it... ah, the card_handler. Should also be possible to do in a simpler way without introducing that dependency.</p> pySim - Feature #6092 (New): "export" suport for ARA-Mhttps://osmocom.org/issues/60922023-07-10T18:47:34Zlaforge
<p>right now the "export" command is focussed around exporting files present in the file system hierarchy of the MF, as well as the various ADFs.</p>
<p>However, there are applications like ARA-M, which have data stored outside of the filesystem. So we should probably introduce an <code>export(self)</code> method within the <code>CardApplication</code> class. If that method is present, use this to export, and fall back to the filesystem for all others.</p>
<p>This way the ARA-M <code>CardApplication</code> could implement a custom method for doing the equivalent of the <code>aram_get_all</code> vty command. However, that wouldn't by itself be something that can be executed when the "export" text is re-run as a script by pySim-shell. For that to work we'd have to export different aram_* vty commands depending on the data we are reading from aram_get_all.</p> pySim - Feature #6086 (New): implement features of sysmo-{usim,isim}-toolhttps://osmocom.org/issues/60862023-07-07T11:25:49Zlaforge
<p>I always found it rather odd that there are OS-specific executables in the sysmo-usim-tool software. The purpose was always to have a separate tool for those bits which are sysmo*SIM specific, and not normal ETSI/3GPP Standard. However, that was designed at a time before pySim-shell existed, and only pySim-prog was available.</p>
<p>As more sysmocom card models got introduced, those were not supported from within one sysmo-*sim-tool program, but with copy+pasted+edited command line tools. As a result, users need to know which card they have and execute the right tool for it, which is cumbersome. Even more so, as there are tools (specifically, the sysmo-isim-tool.sja2.py) which actually also supports the sysmoTSIM (3GPP Test profile).</p>
<p>Rather than unifying this inside the sysmo-usim-tool.git repo, I think it's better to reimplement the same functionality based on (and likely inside) pysim.git.</p>
<p>Now that we have the "new" capabilities of pySim-shell and its associated class model, we shouldn't really need separate[ly maintained] software for the actual functionality.</p>
What can sysmo-usim-tool do is:
<ul>
<li>set the imsi
<ul>
<li>3GPP standard, not sysmocom specific</li>
</ul>
</li>
<li>set mnc length
<ul>
<li>3GPP standard, not sysmocom specific</li>
</ul>
</li>
<li>show ICCID
<ul>
<li>3GPP standard</li>
</ul>
</li>
<li>show AID list
<ul>
<li>3GPP standard</li>
</ul>
</li>
<li>show milenage parameters</li>
<li>set milenage parameters</li>
<li>show ki value</li>
<li>set ki value</li>
<li>show [supported and configured] authentication algorithms</li>
<li>set 2g/3g auth algo</li>
<li>show OP/OPc configuration</li>
<li>set OP/OPc</li>
<li>show milenage SEQ/SQN parameters</li>
<li>set milenage SEQ/SQN parameters to default</li>
<li>dump proprietary file contents</li>
</ul>
<p>Let's add whatever functionality is missing to the pySim class model, and then try to implement a potentially command-line compatible replacement for at least the most common operations. For the more esoteric ones (like milenage parameters), I think it's fine to have the user go through pySim-shell and do an edit_binary_decoded or something like that to change the parameters.</p> OsmoHNBGW - Feature #6085 (New): context_map_sccp.c parrots states/events that the SCCP-SCOC FSM ...https://osmocom.org/issues/60852023-07-04T22:22:53Zneelsnhofmeyr@sysmocom.de
<p>When I implemented the SCCP handling FSM for osmo-hnbgw, I was thinking in lines of what events I expect to happen on the SCCP wire, and overlooked the handling that the libosmo-sigtran SCCP-SCOC FSM already provides.</p>
<p>For example, if we want to disconnect while still waiting for an SCCP CC, IIUC there is no need for the context_map_sccp FSM to wait for the CC first -- the SCCP-SCOC already does that.<br />We should just dispatch the DISCONN primitive e.g. via osmo_sccp_tx_disconn(), and SCCP-SCOC will wait for the CC and then RLSD under the hood, for free.</p>
<p>Likely there are more unnecessary dups of SCCP-SCOC features in that FSM.</p> OsmoHNBGW - Feature #6051 (New): misnomer in internal SCCP functionshttps://osmocom.org/issues/60512023-06-02T15:08:18Zneelsnhofmeyr@sysmocom.de
<p>code review has indicated that functions talking to the SCCP User SAP should not be named tx_foo().</p>
<p>See <br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-hnbgw/+/32915">https://gerrit.osmocom.org/c/osmo-hnbgw/+/32915</a><br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-hnbgw/+/33128">https://gerrit.osmocom.org/c/osmo-hnbgw/+/33128</a></p>
<p>It came up in code review for these patches, after the functions in question had already been merged by earlier patches.</p>
<p>List the functions that should be renamed,<br />and choose names that everyone agrees with.</p> Distributed GSM - Support #4737 (New): How to configure Queries gsup.hlr.123456789.imsi, sip.voic...https://osmocom.org/issues/47372020-08-31T05:37:37Zedgard21031969
<p>Hello,</p>
<p>I work on D-GSM to test it with FreeSWITCH, but after configuration, all of my following command give "not-found" answer.</p>
<p>edgard@osmocom-u16-svr:~$ osmo-mslookup-client sip.voice.1001.msisdn<br />query result last age v4_ip v4_port v6_ip v6_port<br />sip.voice.1001.msisdn not-found last 0<br />edgard@osmocom-u16-svr:~$ osmo-mslookup-client gsup.hlr.901700000014701.imsi<br />query result last age v4_ip v4_port v6_ip v6_port<br />gsup.hlr.901700000014701.imsi not-found last 0<br />edgard@osmocom-u16-svr:~$ osmo-mslookup-client gsup.hlr.111111.imsi<br />query result last age v4_ip v4_port v6_ip v6_port<br />gsup.hlr.111111.imsi not-found last 0<br />edgard@osmocom-u16-svr:~$ osmo-mslookup-client gsup.hlr.1001.msisdn sip.voice.10 01.msisdn smpp.sms.1001.msisdn foo.1001.msisdn<br />query result last age v4_ip v4_port v6_ip v6_port<br />foo.1001.msisdn not-found last 0<br />smpp.sms.1001.msisdn not-found last 0<br />sip.voice.1001.msisdn not-found last 0<br />gsup.hlr.1001.msisdn not-found last 0<br />edgard@osmocom-u16-svr:~$ osmo-mslookup-client --csv-headers gsup.hlr.9017000000 14701.imsi<br />osmo-mslookup-client: unrecognized option '--csv-headers'<br />Error in command line options. Exiting.<br />edgard@osmocom-u16-svr:~$ osmo-mslookup-client -f json gsup.hlr.901700000014701. imsi
{"query": "gsup.hlr.901700000014701.imsi", "result": "not-found", "last": true, "age": 0}<br />edgard@osmocom-u16-svr:~$</p>
<p>Did I forget something about queries in my configuration? How can I implemente URL notation, typical mslookup queries look like pleae?<br /> gsup.hlr.123456789.imsi<br /> sip.voice.123.msisdn<br /> smpp.sms.123.msisdn</p>
<p>My osmo-hlr.cfg configuration is:<br />!<br />! OsmoHLR example configuration<br />!<br />log stderr<br /> logging filter all 1<br /> logging color 1<br /> logging print category 1<br /> logging print category-hex 0<br /> logging print level 1<br /> logging print file basename last<br /> logging print extended-timestamp 1<br /> logging level main notice<br /> logging level db notice<br /> logging level auc notice<br /> logging level ss notice<br /> logging level linp error<br />!<br />line vty<br /> bind 127.0.0.1<br />ctrl<br /> bind 127.0.0.1<br />hlr<br /> gsup<br /> bind ip 127.0.0.1<br /> bind ip 192.168.43.84<br /> bind ip 0.0.0.0<br /> ipa-name hlr-23<br /> subscriber-create-on-demand 5 cs+ps<br /> subscriber-create-on-demand 5 none<br /> store-imei<br />mslookup<br /> mdns bind 239.192.23.42 4266<br /> mdns domain-suffix mdns.osmocom.org<br /> mdns bind<br /> server<br /> service sip.voice at 192.168.43.84 5060<br /> service smpp.sms at 192.168.43.84 2775<br /> service gsup.hlr at 192.168.43.84 4222</p>
<p>Thanks to your help</p> OsmocomBB - Support #1627 (Stalled): DCS_8BIT and DCS_UCS2 encoding supprothttps://osmocom.org/issues/16272016-02-29T03:46:52Zfixeria
<p>Currently it is impossible to send/receive SMS messages and USSD encoded in 8-bit or 16-bit alphabet.</p>