Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092021-02-17T13:31:41ZOpen Source Mobile Communications
Redmine Cellular Network Infrastructure - Bug #5030 (Resolved): jenkins ttcn3-bsc-test and ttcn3-bts-test...https://osmocom.org/issues/50302021-02-17T13:31:41Zdexter
<p>The following two TTCN3 testsuites fail in jenkins.</p>
<p><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test/1285/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test/1285/</a><br /><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/1190/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/1190/</a></p>
<p>building osmo-bts fails with the following errror message:<br />../../include/osmo-bts/gsm_data.h:326:29: error: field 'l1_info' has incomplete type</p>
<p>This is due to the following patch:<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/22938">https://gerrit.osmocom.org/c/osmo-bts/+/22938</a></p>
<p>which depends on</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/libosmocore/+/22932">https://gerrit.osmocom.org/c/libosmocore/+/22932</a></p>
<p>both are merged and were built without problems in gerrit. It might be that the libosmocore change is not propagated into the libosmocore package yet.</p> osmo-sip-connector - Bug #4159 (Resolved): osmo-sip-connector segfaultshttps://osmocom.org/issues/41592019-08-20T11:38:29Zdexter
<pre>
Tue Aug 20 13:16:12 2019 DMNCC <0001> mncc.c:956 MNCC rcvd message type: MNCC_DISC_IND
Tue Aug 20 13:16:12 2019 DMNCC <0001> mncc.c:575 Rcvd MNCC_DISC_IND, Cause: NORM_CALL_CLEAR
Tue Aug 20 13:16:12 2019 DMNCC <0001> mncc.c:577 leg(2147483649) was disconnected. Releasing
Tue Aug 20 13:16:12 2019 DMNCC <0001> mncc.c:68 Starting Timer for MNCC_REL_CNF
Tue Aug 20 13:16:12 2019 DMNCC <0001> mncc.c:142 MNCC sent message type: MNCC_REL_REQ
Tue Aug 20 13:16:12 2019 DSIP <0000> sip.c:457 sip_release_call(): Release with MNCC cause(NORM_CALL_CLEAR)
Tue Aug 20 13:16:12 2019 DSIP <0000> sip.c:429 cause2status(): Mapping cause(NORM_CALL_CLEAR) to status(200)
Tue Aug 20 13:16:12 2019 DSIP <0000> sip.c:481 Ending leg(0x55d0078bb090) in connected state.
Tue Aug 20 13:16:12 2019 DSIP <0000> sip.c:327 SIP event[nua_r_bye] status(200) phrase(OK) 0x55d0078bb090
Tue Aug 20 13:16:12 2019 DSIP <0000> sip.c:376 leg(0x55d0078bb090) got resp to bye
Tue Aug 20 13:16:12 2019 DMNCC <0001> mncc.c:956 MNCC rcvd message type: MNCC_REL_CNF
Tue Aug 20 13:16:12 2019 DMNCC <0001> mncc.c:82 Got response(MNCC_REL_CNF), stopping timer on leg(2147483649)
Tue Aug 20 13:16:12 2019 DMNCC <0001> mncc.c:624 leg(2147483649) was cnf released.
Tue Aug 20 13:24:18 2019 DSIP <0000> sip.c:327 SIP event[nua_i_invite] status(100) phrase(Trying) (nil)
Tue Aug 20 13:24:18 2019 DSIP <0000> sip.c:392 Processing INVITE Call-ID: 6deb60a42abf482b0f4555df2a0e06fb@10.9.1.122:5060
Tue Aug 20 13:24:18 2019 DSIP <0000> sip.c:115 Incoming call(6deb60a42abf482b0f4555df2a0e06fb@10.9.1.122:5060) handle(0x55d0078bfaf0)
Tue Aug 20 13:24:18 2019 DSIP <0000> sip.c:167 SDP Extracted: IP=(10.9.1.122) PORT=(14472) PAYLOAD=(3).
Tue Aug 20 13:24:18 2019 DSIP <0000> sip.c:327 SIP event[nua_i_state] status(100) phrase(Trying) 0x55d0078c2170
Tue Aug 20 13:24:18 2019 DSIP <0000> sip.c:415 Did not handle event[nua_i_state] status(100)
Tue Aug 20 13:24:21 2019 DMNCC <0001> mncc.c:946 Failed to read 0/Function not implemented. Re-connecting.
Tue Aug 20 13:24:21 2019 DAPP <0002> app.c:50 Going to release call(5020) due MNCC.
Tue Aug 20 13:24:21 2019 DSIP <0000> sip.c:457 sip_release_call(): Release with MNCC cause(unknown 0x0)
Tue Aug 20 13:24:21 2019 DSIP <0000> sip.c:433 cause2status(): Cause(unknown 0x0) not found in map.
Tue Aug 20 13:24:21 2019 DSIP <0000> sip.c:468 Cancelling leg(0x55d0078c2170) in confirmed state
Tue Aug 20 13:24:21 2019 DMNCC <0001> mncc.c:290 MNCC not connected releasing leg(5020)
Tue Aug 20 13:24:26 2019 DMNCC <0001> mncc.c:925 Failed to connect(/tmp/bsc_mncc). Retrying
Tue Aug 20 13:24:31 2019 DMNCC <0001> mncc.c:925 Failed to connect(/tmp/bsc_mncc). Retrying
Tue Aug 20 13:24:36 2019 DMNCC <0001> mncc.c:925 Failed to connect(/tmp/bsc_mncc). Retrying
Tue Aug 20 13:24:41 2019 DMNCC <0001> mncc.c:925 Failed to connect(/tmp/bsc_mncc). Retrying
Tue Aug 20 13:24:46 2019 DMNCC <0001> mncc.c:925 Failed to connect(/tmp/bsc_mncc). Retrying
Tue Aug 20 13:24:51 2019 DMNCC <0001> mncc.c:925 Failed to connect(/tmp/bsc_mncc). Retrying
Tue Aug 20 13:24:56 2019 DMNCC <0001> mncc.c:925 Failed to connect(/tmp/bsc_mncc). Retrying
Tue Aug 20 13:25:01 2019 DMNCC <0001> mncc.c:925 Failed to connect(/tmp/bsc_mncc). Retrying
Tue Aug 20 13:25:04 2019 DSIP <0000> sip.c:327 SIP event[nua_i_invite] status(100) phrase(Trying) (nil)
Tue Aug 20 13:25:04 2019 DSIP <0000> sip.c:392 Processing INVITE Call-ID: 2465a4853348db406e3bd1d618d95ce8@10.9.1.122:5060
Tue Aug 20 13:25:04 2019 DSIP <0000> sip.c:115 Incoming call(2465a4853348db406e3bd1d618d95ce8@10.9.1.122:5060) handle(0x55d0078bd160)
Tue Aug 20 13:25:04 2019 DSIP <0000> sip.c:167 SDP Extracted: IP=(10.9.1.122) PORT=(15736) PAYLOAD=(3).
Tue Aug 20 13:25:04 2019 DMNCC <0001> mncc.c:906 Failed to send message leg(5021)
./start-osmo-sip-connector.sh: line 5: 20158 Segmentation fault sudo osmo-sip-connector -c ./osmo-sip-connector.cfg
</pre> OsmoBSC - Bug #3833 (Resolved): Fix storage location of AMR S15-S0 bitshttps://osmocom.org/issues/38332019-03-11T17:44:34Zdexter
<p>The current storage location of s15_s0 (lchan->activate.info.s15_s0) is incorrect by the current memory model. This should be fixed by finding a proper storage location that fits into the current memory model.</p>
<p>See also:<br /><a class="external" href="https://gerrit.osmocom.org/#/c/osmo-bsc/+/13200/">https://gerrit.osmocom.org/#/c/osmo-bsc/+/13200/</a><br /><a class="external" href="https://gerrit.osmocom.org/#/c/osmo-bsc/+/13039/">https://gerrit.osmocom.org/#/c/osmo-bsc/+/13039/</a></p> OpenBSC - Bug #3657 (Resolved): fix support for non voice configurationhttps://osmocom.org/issues/36572018-10-16T13:32:46Zdexter
<p>At the moment osmo-bsc does not permit non voice configurations. A valid voice codec configuration must be in place, otherwise the COMPLETE LAYER 3 INFORMATION message generation will fail because the SPEECH CODEC LIST (BSS supported) IE can not be generated. The speech codec list is a mandatory IE, but only if the network supports an IP based user plane interface. In networks that intentionally do not support voice, it could be garmented that those networks do not have such an interface and therefore the inclusion of the speech codec list is not needed. Also a speech codec list with 0 elements is indeed permitted by the spec. We could also include a speech codec list with 0 elements for the non-voice configurations.</p> libosmocore - Bug #3441 (Resolved): two processes can open the same UDP port without errorhttps://osmocom.org/issues/34412018-08-01T11:00:32Zdexter
<p>When two processes open a socket with the same UDP port there will be no error since we set SO_REUSEADDR also for UDP ports. This is dangerous and might lead into situations that are very difficult to debug. There is no point in setting SO_REUSEADDR for UDP ports since UDP is connection less and there can not be any lingering connections like with TCP.</p> OsmoBSC - Bug #3413 (Resolved): TC_lcls_connect_clear does not pass anymore.https://osmocom.org/issues/34132018-07-23T19:39:02Zdexter
<p>After we increased the test coverage in <a class="issue tracker-1 status-3 priority-3 priority-high3 closed" title="Bug: BSC_Tests.ttcn is too tolerant in MGCP validation (Resolved)" href="https://osmocom.org/issues/3292">#3292</a> we observed problems with the LCLS tests. (TC_ho_int is a real regression) Those were then fixed, but now TC_lcls_connect_clear indicates problems again. It is not clear yet what causes the failure, but it the location of the problems seems to be in the second interleave after the clear command is sent. The testcase seems to have problems with receiving/matching the tr_RSL_RF_CHAN_REL() template. The test case passes when CONN_A.receive(tr_RSL_RF_CHAN_REL(?)) is removed from the interleave.</p>
<p>When the interactions are traced using wirshark, the RSL CHANNEL RELEASE message can be seen, so it must be somewhere in the template/interleave processing.</p> Cellular Network Infrastructure - Bug #3384 (Resolved): Translate PT before sending RTP packets (...https://osmocom.org/issues/33842018-07-05T15:06:40Zdexter
<p>When dynamic payload types are used and the call-agent configures two connections with the same codec, but different payload type numbers then osmo-mgw must ensure that the RTP packets are sent with the correct payload type number. This means on the ingress connection the MGW must lookup the codec by the payload type number. On the egress connection the MGW must use the previously looked up codec to determine the matching payload type number that is configured for that codec on the egress connection.</p>
<p>We need: Payload-type number re-writing in osmo-mgw and a TTCN3 testcase that verifies this behavior.</p> osmo-sip-connector - Feature #2950 (Resolved): create OE-Package for osmo-sip-connectorhttps://osmocom.org/issues/29502018-02-16T15:20:42Zdexter
<p>It appears to be that osmo-sip-connector is not built as OE package, so it is not available for easy install on sysmoBTS or sysmoNITB. However, having osmo-sip-connector available on those platform would make sense.</p>
<p>Dependencies:<br />SOFIASIP, sofia-sip-ua-glib >= 1.12.0</p> libosmocore - Bug #2915 (Resolved): FSM: Do not terminate child FSMs earlyhttps://osmocom.org/issues/29152018-02-09T11:35:35Zdexter
<p>When an FSM is terminated _osmo_fsm_inst_term() first terminates the child FSMs and then executes the cleanup callback of the respective FSM. This prevents the FSM to perform actions on its children while it is terminated. Eventually this behavior prevents a graceful exit of the child FSMs. The parent FSM should always be able to signal last actions to its child FSMs before the final termination happens.</p>
<p>The patch that got merged recently caused unexpected fallout on the unit-tests of osmo-msc and had to be reverted:</p>
<p><a class="external" href="https://gerrit.osmocom.org/6318">https://gerrit.osmocom.org/6318</a></p>
<p>Manual tests on the test-network (includes osmo-bsc, osmo-msc, osmo-hlr, osmo-stp and osmo-mgw) did not reveal any behavioral difference. Also the TTCN3 testsuit for the BSC did not show any sign of problems caused by the patch. However, the fallout needs to be investigated and we need to check if it actually changes behavior or or if it just changes the position of some log-lines (expected, cleanup_cb now runs before the child termination).</p>
<p>Attached one finds a patch that shows the difference of the changed log-output of the test (.err).</p> OsmoBSC - Bug #2823 (Resolved): Use bsc_subscr_conn_fsm in BSChttps://osmocom.org/issues/28232018-01-08T22:28:12Zdexter
<p>On laforge/fsm a draft FSM implementation can be found to make the handling of the subscriber connection safer and stateful.</p> libosmocore - Bug #2613 (Closed): vty crashes on tab-completionhttps://osmocom.org/issues/26132017-11-02T16:11:14Zdexter
<p>The problem is located in libosmocore, so it exists in all our products. It<br />looks like it is somehow liked to the tab-completion. The problem can be<br />triggered for example by logging into a vty and try to tab-complete some<br />items of the help menu, it seems to bail at the second level of tab completion.</p>
<pre>
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
Welcome to the osmo-stp control interface
Copyright (C) 2015-2017 by Harald Welte <laforge@gnumonks.org>
Contributions by Holger Freyther, Neels Hofmeyr
License GPLv2+: GNU GPL Version 2 or later <http://gnu.org/licenses/gpl-2.0.html>
This is free software: you are free ot change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Free Software lives by contribution. If you use this, please contribute!
osmo-stp>
show Show running system information
list Print command list
exit Exit current mode and down to previous mode
help Description of the interactive help system
enable Turn on privileged mode command
terminal Set terminal line parameters
who Display who is on vty
logging Configure log message to this terminal
osmo-stp> h
osmo-stp> help
</pre>
<p>Attached the logtext including backtrace.</p> libosmocore - Feature #2587 (Closed): helper function to finde the right interface for a remote I...https://osmocom.org/issues/25872017-10-20T14:48:40Zdexter
<p>In some cases (mgcp-gw) it is important to know the IP-Address of the interface through which a remote IP-Address is reachable. This can be done using the syscalls connect() and getsockname(). Implement a helper function in socket.c that takes a remote ip-address as input and outputs the coresponding local interface</p> OpenBSC - Feature #2515 (Closed): integrate osmo-mgw in osmo-bschttps://osmocom.org/issues/25152017-09-18T15:48:17Zdexter
<p>osmo-mgw has reached a development state, where it makes sens to try out how it performs in a real life situation. Osmo-bsc seems like a good test target for that and requires mgcp features anyway to support handover. The complexity can be limited by leaving osmo-msc on the legacy mgcp, while performing changes only to osmo-bsc. When done, osmo-bsc should not behave any different on the A-Interface.</p> libosmo-sccp + libosmo-sigtran - Bug #2441 (Closed): chopped-off pointcodeshttps://osmocom.org/issues/24412017-08-15T11:16:54Zdexter
<p>It seems that that the pointcode data is chopped off when receiving unittdata.</p>
<p>When looking at the attached trace.pcapng file, one can see that the RESET<br />command is correctly transmitted, but the response, the RESET ACK is always<br />sent to the wrong destination address. (187 instead of 2235). When converting<br />those to numbers one can see that the addresses seem to be chopped off,<br />presumably at the 8th bit:</p>
<pre>
2235 = 100010111011
187 = 10111011
</pre>
<p>When investigating further it turns out that the pointcode is already chopped<br />off when the RESET is received:</p>
<pre>
Tue Aug 15 11:35:20 2017 <000a> a_iface.c:531 N-UNITDATA.ind(00 04 30 04 01 20 )
Tue Aug 15 11:35:20 2017 <000a> a_iface_bssap.c:184 Rx BSC UDT: 00 04 30 04 01 20
Tue Aug 15 11:35:20 2017 <000a> a_iface_bssap.c:157 Rx BSC UDT BSSMAP RESET
Tue Aug 15 11:35:20 2017 <000a> a_iface_bssap.c:110 Rx RESET from BSC RI=SSN_PC,PC=0.23.3,SSN=unknown 0xfe,GTI=NO_GT, sending RESET ACK
Tue Aug 15 11:35:20 2017 <000a> fsm.c:176 FSM RESET(FSM RESET INST)[0x55555589b7a0]{DISC}: Timeout of T0
Tue Aug 15 11:35:20 2017 <000a> a_reset.c:102 (RI=SSN_PC,PC=0.23.3,SSN=unknown 0xfe,GTI=NO_GT) reset-ack timeout (T0) in state ST_DISC (disconnected), resending...
Tue Aug 15 11:35:20 2017 <000a> a_iface.c:443 Sending RESET to BSC RI=SSN_PC,PC=0.23.3,SSN=unknown 0xfe,GTI=NO_GT
</pre>
<p>Presumably the upcoming primitive already contains the chopped pointcode.</p> OpenBSC - Bug #2424 (Closed): use osmo_sccp_addr_set_ssn() in osmo-bschttps://osmocom.org/issues/24242017-08-07T15:14:20Zdexter
<p><a class="external" href="https://gerrit.osmocom.org/#/c/3359/">https://gerrit.osmocom.org/#/c/3359/</a> is still in review, use the provided function osmo_sccp_addr_set_ssn() as soon as it is merged.</p> libosmo-sccp + libosmo-sigtran - Feature #2417 (Closed): function to check sccp-addresseshttps://osmocom.org/issues/24172017-08-01T10:37:29Zdexter
<p>sccp-addresses consist of a number of components. A presence bitmask denotes if a component has a valid value or not. Add a function that checks the presence field against a given value. Also check if the values fall into the correct range, so that a malformed sccp-address is detected early.</p> OpenBSC - Feature #2396 (Closed): Comfortable CS7/SS7 VTY configuration for osmo-bsc and osmo-mschttps://osmocom.org/issues/23962017-07-24T19:54:54Zdexter
<p>osmo-msc and osmo-bsc currently lack important SS7 related VTY configuration features. Add proper VTY configuration commands to both applications</p> libosmo-sccp + libosmo-sigtran - Bug #2381 (Closed): function to automatically generate a local S...https://osmocom.org/issues/23812017-07-20T08:27:17Zdexter
<p>In some cases it would be very helpful if the user could just ask the sccp API for a local address. Such an address can be derived from the configuration data we have set for the CS7 instance via VTY.</p> libosmo-sccp + libosmo-sigtran - Bug #2376 (Closed): search for an sscp-address and return ss7 in...https://osmocom.org/issues/23762017-07-19T08:09:09Zdexter
<p>By the current API definition, the user can limit the search range to a specific ss7 instance (if that instance is known). When the given ss7 instance pointer is NULL, the global list is searched. This scheme will be changed to:</p>
<p>When searching, always the global list is searched. If found, the address will be copied to the pointer which the caller has issued. We will also return the pointer to the ss7 instance. A returned NULL pointer indicates that the entry was not found. By creating a copy of the addressbook entry we also prevent that the caller might change the address data in the addressbook. The only legal way to change addressbook entries is the VTY.</p>
<p>The API should look like this:</p>
<p>struct osmo_ss7_instance *osmo_sccp_addr_by_name(const char *name, struct osmo_sccp_addr *dest);</p>
<p>const char *osmo_sccp_name_by_addr(const struct osmo_sccp_addr *addr);</p> libosmo-sccp + libosmo-sigtran - Bug #2375 (Closed): enforce unique names in sccp-addressbookhttps://osmocom.org/issues/23752017-07-19T07:56:56Zdexter
<p>Each sccp-addressbook entry is referenced by a name. Make sure that a name can not be used twice.</p>
<p>Inside a single ss7 instace, reusing a name twice is not possible, but a user could use the same name twice in different ss7 instance. This situation mus be prevented.</p> libosmo-sccp + libosmo-sigtran - Bug #2351 (Closed): unify sccp instance configurationhttps://osmocom.org/issues/23512017-07-06T09:41:55Zdexter
<p>The configuration of the sccp instance can be unified. The parameters of osmo_sccp_simple_client() which is used to create the sccp instance could be configured using the built in VTY of libosmo-sccp. This would unify the configuration of SCCP and offload the application specific VTY. It also would help to simplify the configuration from the users perspective. The user will not have to learn a new way to configur SS7 applications all the time.</p>
<pre>
struct osmo_sccp_instance *
osmo_sccp_simple_client(void *ctx, const char *name, uint32_t pc,
enum osmo_ss7_asp_protocol prot, int local_port,
const char *local_ip, int remote_port, const char *remote_ip);
</pre> OpenBSC - Bug #2347 (Closed): osmo-msc Make SSCP address configurablehttps://osmocom.org/issues/23472017-07-03T10:58:36Zdexter
<p>The SSCP-Address in osmo-msc is not configurable via VTY. Add the required VTY Commands</p> libosmo-sccp + libosmo-sigtran - Bug #2345 (Closed): VTY: Check returncode of osmo_ss7_pointcode_...https://osmocom.org/issues/23452017-06-30T13:50:30Zdexter
<p>The function osmo_ss7_pointcode_parse() may yield -EINVAL as result. Make sure that if this is the case, the result will not be used and a CMD_WARNING is returned.</p> OpenBSC - Bug #2342 (Closed): fix MSC co located MGCPhttps://osmocom.org/issues/23422017-06-28T12:47:28Zdexter
<p>There is a problem with the handling of the MGCP on the MSC side. A crash/restart of the MSC might leave open MGCP endpoints. The endpoints will stay open and will be not available for new connections.</p>
<p>To get around problems after restarting the MSC we currently send a DLCX before we seize a new enpoint. This ensures that the endpoint is closed before we try to seize it. This works fine but is a spec violation. Normally a DLCX requires a connection identifier ("C"). Since our MGCP gateway ignores the connection identifier in a DLCX the current method work. However, it might fail when using an MGCP gateway from another vendor.</p>
<p>So sending a DLCX is not a good option becaus on restart we lost all information about the connection identifiers. Holger suggested to use an already existing "reset all endpoints" vendor extension in our MGCP. This would be a possible solution. However, it would reset everything at once. It would work, but this would certainly disturb possible other users of the MGCPGW. I do not know if this is even planned or required.</p> libosmo-sccp + libosmo-sigtran - Bug #2328 (Closed): sccp-address nodeshttps://osmocom.org/issues/23282017-06-15T10:04:54Zdexter
<p>the SCCP level addresses. Unfortunately a SCC (called|calling) party<br />address is rather complex and hence it cannot easily be supplied by a<br />single VTY command. My idea is thus to add 'sccp-address' nodes,<br />where one can specify a SCCP address like this:</p>
<pre><code>sccp-address my-bsc-addr<br /> routing-indicator 1<br /> point-code 2.3.1<br /> subsystem-number 253<br /> global-title<br /> gti 4<br /> digits 2342<br /> ...</code></pre>
<p>The above vty code would become part of libosmo-sigtran, and the<br />BSC/MSC then can simply have a single vty line like<br />"bsc sccp-address my-bsc-addr" <br />and then call a function that resolves this address by it's<br />string-name "my-bsc-addr"</p> libosmo-sccp + libosmo-sigtran - Bug #2259 (New): problem with local referencehttps://osmocom.org/issues/22592017-05-16T13:05:55Zdexter
<p>When a connection attemt (local reference = 2) is made, libosmo-sccp complains with "<000d> sccp_scoc.c:1528 Cannot find connection for local reference 2". Current master is at 872c6b2a8e309ca6739ef295f1fc468c189e4ec9. The problem seems to be introduced with commit 5527df78adc08b76df07c4b682263b5bdd6181d4 (libosmo-sccp.git). When the commit is reverted, the correct functionality of libosmo-sccp seems to be restored.</p>
<p>The problem can be demonstrated by using the client/server example that is shipped with libosmo-sccp. The following VTY-Commands were used to trigger the problem:</p>
<pre>
enable
sccp-user
called-addr-ssn 202
connect-req 2 hello
</pre>
<p>Note: In the good case I can see the normal CR with payload attached and the CC that with the payload that is echoed by the the echo subsystem. The bad case results in an CREF message, which contains an refusal cause code 0x0F (unqalified)</p> libosmo-sccp + libosmo-sigtran - Bug #2004 (Closed): Problem sending CR without datahttps://osmocom.org/issues/20042017-04-10T12:03:00Zdexter
<p>When attempting to send a connection response (CR) without any data using:</p>
<pre>
osmo_sccp_tx_conn_resp(scu, scu_prim->u.connect.conn_id,
&scu_prim->u.connect.called_addr,
NULL, 0);
</pre>
<p>Wireshark displays a malformed packet. To me it looks like if there is an optional parameter (the data part) announced, but the data is (of course) not there. However. CR seems to work fine when no data is attached.</p> libosmo-sccp + libosmo-sigtran - Bug #1995 (Closed): Segfault when callin osmo_sccp_tx_unitdata()...https://osmocom.org/issues/19952017-04-07T08:44:51Zdexter
<p>The problem occurs when a peer (server role) tries to send unitdata to a remote peer (client) that is not connected.</p>
<p>The attached code contains the source code snippets I used for experimentation.</p>
<p>Good case:<br />fist start dummy_msc (client), then dummy_bsc (server). The client will connect and when the timer at the server expires unitdata is sent from the server to the client.</p>
<p>Bad case:<br />start dummy_bsc, when the timer expires, the segfault occurs.</p>
<p>Note: The scheme is a bit odd and not covered by the examples, since there, the server never actively sends data without being stimulated through an existing connection. It is questionable if a server should send unsolicited data at all. In this test, the server role has been chosen for one side because of the lack of an STP.</p> libosmocore - Bug #1938 (Resolved): lapd_core human readable connection IDs in debug loghttps://osmocom.org/issues/19382017-02-03T11:31:12Zdexter
<p>At the moment we print the pointer address to identify the log lines belonging to a specific connection. Since pointer addresses are difficult to work with, a human readable ID should be printed instead.</p>
<p>e.g. "This is LAPD instance for SAPI3 on bts0/trx1/ts5/lchan3"</p>
<p>This can be implemented by adding a string member to the lapd_datalink struct. The user would set the string to a human readable identifier when the link is created. (See also osmo_fsm).</p>
<p>See also: <a class="external" href="https://gerrit.osmocom.org/#/c/1724/">https://gerrit.osmocom.org/#/c/1724/</a></p> OpenBSC - Bug #1779 (Closed): Problems with automatic subscriber creation.https://osmocom.org/issues/17792016-07-21T22:50:12Zdexter
<p>Maybe this is a problem with my configuration, but after long time I tried the automatic subscriber creation mode again. It constantly rejects the location update with the cause that no subscriber could be found. I traced the problem down to gsm_04_08.c:static bool subscr_regexp_check(). There the regexec() seems to fail.</p>
<p>The VTY show s the following:</p>
<p>OpenBSC> show network <br />BSC is on Country Code 1, Network Code 1 and has 1 BTS<br /> Long network name: 'Vaderfone'<br /> Short network name: 'Vaderfone'<br /> Authentication policy: accept-all, authorized regexp: *<br /> Auto create subscriber: yes<br /> Auto assign extension: yes<br /> Location updating reject cause: 13<br /> Encryption: A5/0<br /> NECI (TCH/H): 1<br /> Use TCH for Paging any: 0<br /> RRLP Mode: none<br /> MM Info: On<br /> Handover: Off<br /> Current Channel Load:<br /> Last RF Command: <br /> Last RF Lock Command:</p>
<p>If i get things right, "authorized regexp: *" should be ok with any IMSI. When I hardcode the returnvalue of subscr_regexp_check() to true it accepts any IMSI again and happyly creates the subscriber.</p>