OsmoNITB: Issueshttps://projects.osmocom.org/https://projects.osmocom.org/favicon.ico?16647414092020-07-03T14:29:29ZOpen Source Mobile Communications
Redmine Bug #4642 (New): Attempting to set illegal id for FSM instance of type 'OM2000-MO'https://projects.osmocom.org/issues/46422020-07-03T14:29:29Zlaforge
<p>At least with current libosocore, osmo-nitb fails to set the names of OM2000 MOs.</p>
<pre>
<0005> bts_ericsson_rbs2000.c:118 inp_sig_cb(): Input signal 'TEI-UP' received
<0005> bts_ericsson_rbs2000.c:36 bootstrapping OML for BTS 0
<0005> fsm.c:461 OM2000-BTS(0)[0x556f9acf5ca0]{INIT}: Allocated
<0005> abis_om2000.c:2322 OM2000-BTS(0)[0x556f9acf5ca0]{INIT}: Received Event START
<0005> abis_om2000.c:2163 OM2000-BTS(0)[0x556f9acf5ca0]{INIT}: state_chg to WAIT-CF
<001e> fsm.c:391 Attempting to set illegal id for FSM instance of type 'OM2000-MO': "0-CF/00/ff/00"
<0005> abis_om2000.c:59 OM2000-BTS(0)[0x556f9acf5ca0]{WAIT-CF}: Received Event CF-DONE
<0005> abis_om2000.c:2175 OM2000-BTS(0)[0x556f9acf5ca0]{WAIT-CF}: state_chg to WAIT-TF
<001e> fsm.c:391 Attempting to set illegal id for FSM instance of type 'OM2000-MO': "0-TF/00/ff/00"
<0005> abis_om2000.c:59 OM2000-BTS(0)[0x556f9acf5ca0]{WAIT-TF}: Received Event TF-DONE
<0005> abis_om2000.c:2188 OM2000-BTS(0)[0x556f9acf5ca0]{WAIT-TF}: state_chg to WAIT-CON
<001e> fsm.c:391 Attempting to set illegal id for FSM instance of type 'OM2000-MO': "0-CON/00/ff/00"
<0005> abis_om2000.c:59 OM2000-BTS(0)[0x556f9acf5ca0]{WAIT-CON}: Received Event CON-DONE
<0005> abis_om2000.c:2201 OM2000-BTS(0)[0x556f9acf5ca0]{WAIT-CON}: state_chg to WAIT-IS
<001e> fsm.c:391 Attempting to set illegal id for FSM instance of type 'OM2000-MO': "0-IS/00/ff/00"
<0005> abis_om2000.c:59 OM2000-BTS(0)[0x556f9acf5ca0]{WAIT-IS}: Received Event IS-DONE
<0005> abis_om2000.c:2214 OM2000-BTS(0)[0x556f9acf5ca0]{WAIT-IS}: state_chg to WAIT-TRX
<001e> fsm.c:391 Attempting to set illegal id for FSM instance of type 'OM2000-TRX': "0/0"
<0005> abis_om2000.c:59 OM2000-BTS(0)[0x556f9acf5ca0]{WAIT-TRX}: Received Event TRX-DONE
</pre>
<p>Looking at <code>om2k_mo_name()</code> in osmo-bsc, I would suggest the problem also exists in osmo-bsc.</p> Bug #2691 (Feedback): Old TMSI paged after LUhttps://projects.osmocom.org/issues/26912017-11-29T09:37:38Zzecke
<p>While working on the scripting of "mobile" I noticed a funny paging issue.</p>
<ul>
<li>Do UL from mobile</li>
<li>Send SMS from NITB and start paging to mobile</li>
<li>"shutdown" mobile</li>
<li>"no shutdown" mobile
<ul>
<li>UL happens</li>
<li>TMSI reallocation</li>
</ul>
</li>
<li>NITB will continue paging the old TMSI</li>
</ul>
<p>The issue got introduced in 6d804b1a7e375213cb4b3e437c2b9b8c68872164 when separating the subscribers...</p> Bug #2438 (New): MS not registered from osmocom PoV, but registered from ofono PoVhttps://projects.osmocom.org/issues/24382017-08-14T09:36:29Zpespin
<p>From time to time since recently, I see some tests failing with a "Wait Timeout" while waiting for the subscriber to be online (asking via "GET_REPLY 0 subscriber-list-active-v1"). However, the same validation done just before in ofono side states that the MS is in fact registered with the network.</p>
<p>I attach run directories (with logs, pcap, etc.) of 2 jobs which showed the mentioned issue. The other test failing on those archives (smpp/esme_ms_sms_storeforward.py) should be unrelated to this one and is being tracked in another issue (<a class="issue tracker-1 status-5 priority-2 priority-default closed" title="Bug: SMSC: deiverSM message with bad user_message_reference (Closed)" href="https://projects.osmocom.org/issues/2429">#2429</a>).</p>
<p>The issue seems to appear in both OsmoNITB and AoIP.</p>
<p>2040.tar.gz -> failing test is sms:sysmo/mo_mt_sms.py<br />2083.tar.gz -> failing test is aoip_smpp:sysmo/esme_ms_sms_transaction.py</p> Bug #2433 (New): Drop MGCP_DUMMY_LOAD frames and use proper Osmux Dummy frameshttps://projects.osmocom.org/issues/24332017-08-11T13:11:47Zpespin
<p>In some places we are using some manually crafted dummy packets with payload = 0x23 = MGCP_DUMMY_LOAD. With latest wireshark versions, those packets are recognized as "Osmux AMR Old Dummy".<br />However, Osmux supports Dummy frames with its own FT type (2). Better analyze and drop these crafted MGCP_DUMMY_LOAD and use proper Dummy frames as explained on the reference osmux doc (<a class="external" href="http://ftp.osmocom.org/docs/latest/osmux-reference.pdf">http://ftp.osmocom.org/docs/latest/osmux-reference.pdf</a>).</p>
<p>Add APIs if needed to send some dummy packet instantly or similar.</p>
<pre>
$ ag MGCP_DUMMY_LOAD
openbsc/tests/mgcp/mgcp_test.c
443:#define MGCP_DUMMY_LOAD 0x23
458: if (len == 1 && ((const char *)buf)[0] == MGCP_DUMMY_LOAD ) {
openbsc/src/libmgcp/mgcp_network.c
95: static char buf[] = { MGCP_DUMMY_LOAD };
705: if (rc == 1 && buf[0] == MGCP_DUMMY_LOAD) {
797: if (rc == 1 && buf[0] == MGCP_DUMMY_LOAD) {
859: if (rc == 1 && buf[0] == MGCP_DUMMY_LOAD) {
openbsc/src/libmgcp/mgcp_osmux.c
280: if (msg->data[0] == MGCP_DUMMY_LOAD)
373: if (msg->data[0] == MGCP_DUMMY_LOAD)
517: buf[0] = MGCP_DUMMY_LOAD;
openbsc/include/openbsc/mgcp_internal.h
308:#define MGCP_DUMMY_LOAD 0x23
</pre> Bug #2414 (New): SMSC: deliverSM message with no user_message_referencehttps://projects.osmocom.org/issues/24142017-07-31T16:08:10Zpespin
<p>In osmo-gsm-tester-run jenkins job there was a FAILED test whith the following issue in test smpp/esme_ms_sms_storeforward.py:</p>
<pre>
11:11:55.154065 tst esme-22982: DBG: message received: {seq=665772384} [trial-1824↪smpp↪esme-22982] [esme.py:117]
11:11:55.190338 tst esme-22982: DBG: message received: {references_pending_receipt=[2, 3], user_message_reference=None} [trial-1824↪smpp↪esme-22982] [esme.py:121]
11:11:55.194636 tst esme_ms_sms_storeforward.py:49: ERR: ValueError: list.remove(x): x not in list [trial-1824↪smpp↪esme_ms_sms_storeforward.py:49] [esme.py:122: self.references_pending_receipt.remove(pdu.user_message_reference)]
11:11:55.200672 tst esme_ms_sms_storeforward.py:49: TRACEBACK: Traceback (most recent call last):
File "/home/jenkins/workspace/osmo-gsm-tester_run/osmo-gsm-tester/src/osmo_gsm_tester/suite.py", line 105, in run
self.path)
File "/home/jenkins/workspace/osmo-gsm-tester_run/osmo-gsm-tester/src/osmo_gsm_tester/util.py", line 282, in run_python_file
SourceFileLoader(module_name, path).load_module()
File "<frozen importlib._bootstrap>", line 539, in _check_name_wrapper
File "<frozen importlib._bootstrap>", line 1614, in load_module
File "<frozen importlib._bootstrap>", line 596, in _load_module_shim
File "<frozen importlib._bootstrap>", line 1220, in load
File "<frozen importlib._bootstrap>", line 1200, in _load_unlocked
File "<frozen importlib._bootstrap>", line 1129, in _exec
File "<frozen importlib._bootstrap>", line 1471, in exec_module
File "<frozen importlib._bootstrap>", line 321, in _call_with_frames_removed
File "/home/jenkins/workspace/osmo-gsm-tester_run/osmo-gsm-tester/suites/smpp/esme_ms_sms_storeforward.py", line 49, in <module>
wait(ms.sms_was_received, msg)
File "/home/jenkins/workspace/osmo-gsm-tester_run/osmo-gsm-tester/src/osmo_gsm_tester/test.py", line 47, in <lambda>
wait = lambda *args, **kwargs: event_module.wait(suite_run, *args, **kwargs)
File "/home/jenkins/workspace/osmo-gsm-tester_run/osmo-gsm-tester/src/osmo_gsm_tester/event_loop.py", line 59, in wait
if not wait_no_raise(log_obj, condition, condition_args, condition_kwargs, timeout, timestep):
File "/home/jenkins/workspace/osmo-gsm-tester_run/osmo-gsm-tester/src/osmo_gsm_tester/event_loop.py", line 50, in wait_no_raise
poll()
File "/home/jenkins/workspace/osmo-gsm-tester_run/osmo-gsm-tester/src/osmo_gsm_tester/event_loop.py", line 39, in poll
func()
File "/home/jenkins/workspace/osmo-gsm-tester_run/osmo-gsm-tester/src/osmo_gsm_tester/esme.py", line 78, in poll
self.client.poll()
File "/usr/local/lib/python3.4/dist-packages/smpplib/client.py", line 321, in poll
self.read_once(ignore_error_codes)
File "/usr/local/lib/python3.4/dist-packages/smpplib/client.py", line 297, in read_once
self._message_received(p)
File "/usr/local/lib/python3.4/dist-packages/smpplib/client.py", line 237, in _message_received
self.message_received_handler(pdu=p)
File "/home/jenkins/workspace/osmo-gsm-tester_run/osmo-gsm-tester/src/osmo_gsm_tester/esme.py", line 122, in _message_received_handler
self.references_pending_receipt.remove(pdu.user_message_reference)
ValueError: list.remove(x): x not in list
[trial-1824↪smpp↪esme_ms_sms_storeforward.py:49] [suite.py:148]
11:11:55.208186 tst esme_ms_sms_storeforward.py:49: Test FAILED (58.8 sec) [trial-1824↪smpp↪esme_ms_sms_storeforward.py:49] [suite.py:149]
</pre>
<p>The issue comes from the following fact --> user_message_reference=None<br />Which potentially means a deliverSM pdu was received which didn't contain the field user_message_reference.</p>
<p>The issue doesn't seem to happen usually, seems like sporadic (only saw it once for now). I attach the run trial which should provide some information. Due to issue <a class="issue tracker-1 status-5 priority-1 priority-lowest closed" title="Bug: osmo-gsm-tester: smpp: ESME traffic not logged in nitb pcap file (Closed)" href="https://projects.osmocom.org/issues/2413">#2413</a>, the pcap file in the archive doesn't contain the SMPP traces, it may be a good idea to fix that issue first.</p>
<p>Try to reproduce the issue or have a look at related python-smpplib and openbsc SMSC code to see possible issues which can explain this.</p>
<p>Check the SMPP reference to see what it has to say about that PDU field too.</p> Bug #1955 (New): Investigate "Bad signalling message" errorhttps://projects.osmocom.org/issues/19552017-02-20T12:35:41Zmsuraev
<p>Sometimes after BTS (observed with osmo-bts-sysmo at least) connects to BSC there's error message:</p>
<p><001e> input/ipaccess.c:283 Bad signalling message, sign_link returned error: Operation not permitted.</p>
<p>It's originated from libosmo-abis src/input/ipaccess.c:282</p>
<p>It doesn't seem to affect operation (both calls and gprs works nevertheless) but it's still worth checking what's causing it (and fixing spelling of "signaling").</p> Bug #1904 (New): get rid of deprecated functionshttps://projects.osmocom.org/issues/19042017-01-06T13:23:57Zmsuraev
<p>While compiling OpenBSC there are warnings due to use of libosmo* functions which are deprecated (for example comp128). Fix those by using proper alternatives to facilitate eventual removal of deprecated function from libosmo* in one of the future releases.</p> Bug #1829 (New): Fix warnings introduced by ctrl constifyhttps://projects.osmocom.org/issues/18292016-10-19T13:02:38Zmsuraev
<p>Commit ed9d6da5df98538adc70aa03cb569eb9505d04b6 in libosmocore changes some part of ctrl_cmd struct to const. This is necessary to avoid additional warnings in OpenGGSN ctrl-related code. Regrettably, this results in numerous warnings in OpenBSC du to use of strtok_r for parsing of ctrl_cmd fields.</p>
<p>This should be fixed as follows:<br />- add unit (or python) tests for functions which have those warnings in OpenBSC<br />- replace (maybe using some helper functions) direct strtok_r parsing with code working with copies (talloc_strdup?)<br />- check that tests still pass<br />- double-check for memleaks</p> Feature #1812 (New): Report gsm0408_dispatch() failures to MS / UEhttps://projects.osmocom.org/issues/18122016-09-17T02:26:20Zneelsnhofmeyr@sysmocom.de
<p>gsm0408_dispatch() has error paths, but the rc for these are so far ignored.<br />Report failures back to the mobile subscriber / user equipment, e.g.<br />the MS should be notified somehow that a given protocol descriptor didn't exist.</p> Bug #1725 (Stalled): iPhone6 network selection issue with GSM1900https://projects.osmocom.org/issues/17252016-05-17T20:07:23Zzecke
<p>We have some form of issue with the iPhone 6S (we can use messenger to move it around). Now the iPhone is a really bad phone (manual network selection not re-scanning, selecting it not trying to access the network in a reasonable amount of time). But what I can re-produce:</p>
<ul>
<li>Put customer IMSI in the phone</li>
<li>Wait for the network to be selected</li>
<li>Enter airplane mode</li>
<li>Leave airplane mode</li>
</ul>
<p>Theory:</p>
<p>The LU should lead to the <abbr title="+band?">ARFCN</abbr> be written to the SIM card. This ARFCN should be tried <em>after</em> the airplane mode (or reboot) is used. But the phone ends up in "No Service". I make my tests with with a RevA hardware and maybe slightly incorrect calibration but other phones behave a lot better.</p>
<p>Reality:</p>
<p>What happens is that after the airplane mode.. the phone does <em>not</em> select a network (It goes to Searching and then prints No Network). Toggling "Automatic" to "Manual" network seaearch it sometimes starts to connect it (after many many minutes).</p>
<p>Stats:<br /><pre>
iPhone 6s
Version 9.3.2 (14F69)
Carrier 24.0
Model MKQK2ZD/A
Modem Firmware 1.60.00
</pre></p>
<p>For reference the SIs of another small network at 1900</p>
<pre>
SI1 5506198f0e0000000000000000000000000000bb00006b
SI2 59061a00000000000000000000000000000000ffbb0000
SI3 49061b9c4072f480101949030f07c346bb00008000832b
SI4 41061c72f4801019c346bb00006430021c80008b2b2b2b
SI13 <empty>
SI5 49061d10000000000000000000000000000000
SI6 2d061e9c4072f480101997ff3b2b2b2b2b2b2b
</pre> Bug #1671 (Stalled): Combined 850/1800 NITB not seen by Option Icon2 stickhttps://projects.osmocom.org/issues/16712016-03-24T06:53:41Zzecke
<p>When having a NITB with one GSM1800 BTS on ARFCN 877 and one on GSM850 on ARFCN 130 (that is not broadcasting), the Icon2 stick failed to join the network. When removing this cell (and hence the neighborcell information) it works immediately. The test was done with a nanoBTS.</p>
<p>Tests:</p>
<ul>
<li>Make this stable, I had issued another AT+CFUN=0/CFUN=1 today morning and while I did this yesterday it is not a clear call</li>
<li>Test with sysmoBTS and the nanoBTS (e.g. maybe some SIs are not scheduled)</li>
<li>Look if all generated SIs are being sent</li>
<li>Look at the spec if such config is legal..</li>
<li>Look at the generated SIs</li>
</ul>
<p>BTS 1 config<br /><pre>
bts 1
type sysmobts
band GSM850
cell_identity 0
location_area_code 1
base_station_id_code 63
ms max power 15
cell reselection hysteresis 4
rxlev access min 0
periodic location update 30
radio-link-timeout 32
channel allocator ascending
rach tx integer 9
rach max transmission 7
channel-descrption attach 1
channel-descrption bs-pa-mfrms 5
channel-descrption bs-ag-blks-res 1
ip.access unit_id 1802 0
oml ip.access stream_id 255 line 0
neighbor-list mode automatic
codec-support fr
gprs mode none
no force-combined-si
trx 0
rf_locked 0
arfcn 130
nominal power 23
max_power_red 22
rsl e1 tei 0
timeslot 0
phys_chan_config CCCH+SDCCH4
hopping enabled 0
timeslot 1
phys_chan_config SDCCH8
hopping enabled 0
timeslot 2
phys_chan_config TCH/F
hopping enabled 0
timeslot 3
phys_chan_config TCH/F
hopping enabled 0
timeslot 4
phys_chan_config TCH/F
hopping enabled 0
timeslot 5
phys_chan_config TCH/F
hopping enabled 0
timeslot 6
phys_chan_config TCH/F
hopping enabled 0
timeslot 7
phys_chan_config TCH/F
hopping enabled 0
</pre></p> Feature #1667 (New): Handle callref betterhttps://projects.osmocom.org/issues/16672016-03-22T19:17:24Zzecke
<p>There is a theoretical race of external MNCC app and OpenBSC to assign the same callref. The probability of this is very low because uint32_t is a big space and the numbers start at different positions (NITB==0x80000001, ==1 on external app). We should avoid it anyway. One should have separate spaces and enforce it.</p> Bug #72 (New): struct gsm_call can leak..https://projects.osmocom.org/issues/722016-02-19T22:47:33Z
<p>During BTS testing I saw that gsm_call appears to be leaked.</p>
<p>Setup:<br />sysmoBTS... configure the bind IP wrongly so the CRCX will be NACKED..</p>
<p>Place a call to an unattached subscriber. Hangup immediately after placing the call, sometimes wait for the network error indication. This was tested with a E71.</p>
<pre>
gsm_call contains 560 bytes in 29 blocks (ref 0) 0x865d318
struct gsm_call contains 20 bytes in 1 blocks (ref 0) 0x87c7040
struct gsm_call contains 20 bytes in 1 blocks (ref 0) 0x8711a90
struct gsm_call contains 20 bytes in 1 blocks (ref 0) 0x87c7428
struct gsm_call contains 20 bytes in 1 blocks (ref 0) 0x8781168
struct gsm_call contains 20 bytes in 1 blocks (ref 0) 0x8716218
struct gsm_call contains 20 bytes in 1 blocks (ref 0) 0x8711ea8
struct gsm_call contains 20 bytes in 1 blocks (ref 0) 0x87c9d28
struct gsm_call contains 20 bytes in 1 blocks (ref 0) 0x87aed50
struct gsm_call contains 20 bytes in 1 blocks (ref 0) 0x87819e0
struct gsm_call contains 20 bytes in 1 blocks (ref 0) 0x8711c28
struct gsm_call contains 20 bytes in 1 blocks (ref 0) 0x8711f28
struct gsm_call contains 20 bytes in 1 blocks (ref 0) 0x8713a20
struct gsm_call contains 20 bytes in 1 blocks (ref 0) 0x87139d8
struct gsm_call contains 20 bytes in 1 blocks (ref 0) 0x8713990
struct gsm_call contains 20 bytes in 1 blocks (ref 0) 0x8713948
struct gsm_call contains 20 bytes in 1 blocks (ref 0) 0x8716e88
struct gsm_call contains 20 bytes in 1 blocks (ref 0) 0x8716e40
struct gsm_call contains 20 bytes in 1 blocks (ref 0) 0x8716df8
struct gsm_call contains 20 bytes in 1 blocks (ref 0) 0x8787668
struct gsm_call contains 20 bytes in 1 blocks (ref 0) 0x872b1d8
struct gsm_call contains 20 bytes in 1 blocks (ref 0) 0x8781da0
struct gsm_call contains 20 bytes in 1 blocks (ref 0) 0x8716090
struct gsm_call contains 20 bytes in 1 blocks (ref 0) 0x8713b90
struct gsm_call contains 20 bytes in 1 blocks (ref 0) 0x872bf70
struct gsm_call contains 20 bytes in 1 blocks (ref 0) 0x8713a98
struct gsm_call contains 20 bytes in 1 blocks (ref 0) 0x8716048
struct gsm_call contains 20 bytes in 1 blocks (ref 0) 0x87289c8
struct gsm_call contains 20 bytes in 1 blocks (ref 0) 0x8711fe8
</pre> Bug #70 (New): nitb crashes in the rtp_proxy when a phone on a MT-call sends a 'CONNECT' before t...https://projects.osmocom.org/issues/702016-02-19T22:47:33Z
<p>Using the <a class="wiki-page new" href="https://projects.osmocom.org/projects/osmonitb/wiki/FakeBTS">FakeBTS</a> it is possible to crash nitb on a MT-call. It appears to that if the MS sends a CALL CONFIRMED and then a CONNECT the rtp_socket is not fully setup and when one attempts to bridge them we have a crash.</p> Bug #54 (New): osmo-nitb keeps rtp-proxy socket open in case no DLCX_IND is senthttps://projects.osmocom.org/issues/542016-02-19T22:47:32Z
<p>sysmobts was sending a wrong DLCX IND, this kept the rtp proxy socket open, on second call the code sends a MDCX early on.</p> Bug #48 (New): Periodic timer and paginghttps://projects.osmocom.org/issues/482016-02-19T22:47:32Z
<p>We set the lac to invalid in case paging fails but this should be co-ordinated with periodic LU. Right now we 'purge' it from the VLR.</p> Bug #38 (New): subscr_update should sync database before dispatching the signalhttps://projects.osmocom.org/issues/382016-02-19T22:47:31Z
<p>The subscr_update routine should synchronize the database before dispatching the signal. Right now the db code to find unset SMS will fail if a given subscriber is not attached and then re-attaches to the network.</p> Bug #37 (New): RTP Proxy dealing with SSRC change and sequence numbershttps://projects.osmocom.org/issues/372016-02-19T22:47:31Z
<p>The rtp_proxy.c code should detect if the SSRC of the input is changing and only then determine the difference in sequence numbers. It should also not try to change the presentation time of one sample to make up the lost ones.</p> Bug #28 (New): Old siemens phones cannot make voice calls (04.08 channel mode)https://projects.osmocom.org/issues/282016-02-19T22:47:31Zlaforge
<p>Some older Siemens phones, notably the S11, implicitly reject the 04.08 CHANNEL MODE MODIFY from signalling to VOICE mode, thus all<br />voice calls fail.</p>
<p>Either they do not support very early assignment, or we are sending the mode modify a bit too soon for their state machines.</p> Bug #21 (New): we don't see CHANnel ReQireD from motorola EZX phones at call setuphttps://projects.osmocom.org/issues/212016-02-19T22:47:31Zlaforge
<p>This is very weird. The EZX phones like E6, A1200, etc. can do a successful LOCATION UPDATING procedure, but after they are registered they can only process incoming calls.</p>
<p>so paging request is working, and the channel request procedure is working as part of the paging request and the location updating.</p>
<p>IF you want to start a MO call, we never see any channel required (i.e. RACH burst).</p> Feature #18 (New): store last location identity to databasehttps://projects.osmocom.org/issues/182016-02-19T22:47:30Zlaforge
for every location update request we get, we should store the info in the db:
<ul>
<li>the previous TMSI, if it is contained</li>
<li>the mnc/mcc/location area of the previous registration</li>
<li>a timestamp</li>
</ul>
<p>it would be great to introduce a new table for this, so we can store any number of those events<br />for any given IMEI and thus create a history.</p>