Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092018-11-22T14:58:20ZOpen Source Mobile Communications
Redmine OsmoBTS - Bug #3703 (Resolved): sporadic failures of TC_tch_sign_l2_fill_frame test casehttps://osmocom.org/issues/37032018-11-22T14:58:20Zstsp
<p>We are seeing sporadic failures of TTCN3 BTS test case TC_tch_sign_l2_fill_frame on Jenkins.</p>
<p>Two different instances of such failures are shown below.</p>
<p>The first one looks as if a process on the other side of the L1 interface disappeared:</p>
<pre>
07:24:28.736125 509 L1CTL_PortType.ttcn:171 Sent on L1CTL to system @L1CTL_Types.L1ctlUlMessage : { header := { msg_type := L1CTL_RESET_REQ (13), flags := { padding := '0000000'B, f_done := false }, padding := '0000'O }, ul_info := omit, ul_info_tbf := omit, ul_info_abs := omit, payload := { reset_req := { reset_type := L1CTL_RES_T_FULL (1), padding := '000000'O } } }
07:24:28.736177 509 L1CTL_PortType.ttcn:208 enc_L1ctlUlMessageLV(): Encoding @L1CTL_Types.L1ctlUlMessageLV: { len := <unbound>, msg := { header := { msg_type := L1CTL_RESET_REQ (13), flags := { padding := '0000000'B, f_done := false }, padding := '0000'O }, ul_info := omit, ul_info_tbf := omit, ul_info_abs := omit, payload := { reset_req := { reset_type := L1CTL_RES_T_FULL (1), padding := '000000'O } } } }
07:24:28.736293 509 L1CTL_PortType.ttcn:208 enc_L1ctlUlMessageLV(): Stream after encoding: '00080D00000001000000'O
07:24:28.736355 509 L1CTL_PortType.ttcn:171 Outgoing message was mapped to @UD_Types.UD_send_data : { data := '00080D00000001000000'O, id := 0 }
07:24:28.736389 509 L1CTL_PortType.ttcn:171 Dynamic test case error: Write error (Broken pipe)
07:24:28.736416 509 L1CTL_PortType.ttcn:171 setverdict(error): none -> error
07:24:28.736435 509 L1CTL_PortType.ttcn:171 Performing error recovery.
</pre><br /><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/309/artifact/logs/bts-tester/BTS_Tests.TC_tch_sign_l2_fill_frame.merged/*view*/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/309/artifact/logs/bts-tester/BTS_Tests.TC_tch_sign_l2_fill_frame.merged/*view*/</a>
<p>Note that this build run also lacks a pcap file for this test:<br /><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/309/artifact/logs/bts-tester/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/309/artifact/logs/bts-tester/</a></p>
<p>The second one could have the same underlying reason, but the problem occurred while waiting to receive a message rather than sending:<br /><pre>
07:19:46.788830 518 L1CTL_PortType.ttcn:176 Timeout T: 2 s
07:19:46.788936 518 L1CTL_PortType.ttcn:177 setverdict(fail): none -> fail reason: "Timeout waiting for RESET.conf", new component reason: "Timeout waiting for RESET.conf"
07:19:46.788969 518 L1CTL_PortType.ttcn:178 Stopping MTC. The current test case will be terminated.
07:19:46.789001 518 L1CTL_PortType.ttcn:178 Stopping test component execution.
</pre><br /><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/303/artifact/logs/bts-tester/BTS_Tests.TC_tch_sign_l2_fill_frame.merged/*view*/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/303/artifact/logs/bts-tester/BTS_Tests.TC_tch_sign_l2_fill_frame.merged/*view*/</a></p> OsmoBSC - Bug #3690 (Resolved): BSC_Tests.TC_dyn_pdch_osmo_act_deact failure: Unexpected TS Mode:...https://osmocom.org/issues/36902018-11-13T10:45:39Zstsp
<p>We have seen BSC_Tests.TC_dyn_pdch_osmo_act_deact fail with:</p>
<pre>
BSC_Tests.ttcn:2754 setverdict(fail): none -> fail reason: "Unexpected TS Mode: "NONE mode"
</pre>
<p>For instance, see <a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test/402/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test/402/</a></p>
<p>This failure needs to be investigated.</p> libosmo-netif - Bug #3685 (Resolved): heap use after free in osmo_stream_srv_write()https://osmocom.org/issues/36852018-11-09T13:27:55Zstsp
<p>Running the TTCN3 MSC test suite on binaries with address sanitizer enabled, I found this crash in libosmo-netif:</p>
<p>{{{<br />Fri Nov 9 14:05:02 2018 DLINP <0002> stream.c:849 connected read/write<br />Fri Nov 9 14:05:02 2018 DLINP <0002> stream.c:789 message received<br />Fri Nov 9 14:05:02 2018 DLSS7 <000c> osmo_ss7.c:1424 asp-virt-bsc0-0: xua_srv_conn_cb(): sctp_recvmsg() returned 12 (flags=0x8080)<br />Fri Nov 9 14:05:02 2018 DLSS7 <000c> osmo_ss7.c:1357 asp-virt-bsc0-0: xUA SRV SCTP NOTIFICATION 32773 flags=0x0<br />Fri Nov 9 14:05:02 2018 DLSS7 <000c> osmo_ss7.c:1370 asp-virt-bsc0-0: xUA SRV SHUTDOWN_EVENT<br />Fri Nov 9 14:05:02 2018 DLSS7 <000c> osmo_ss7.c:1616 virt-bsc0-0: SCTP connection closed<br />Fri Nov 9 14:05:02 2018 DLSS7 <000c> osmo_ss7.c:1622 XUA_ASP(virt-bsc0-0){ASP_ACTIVE}: Received Event SCTP-COMM_DOWN.ind<br />Fri Nov 9 14:05:02 2018 DLSS7 <000c> xua_asp_fsm.c:591 XUA_ASP(virt-bsc0-0){ASP_ACTIVE}: state_chg to ASP_DOWN<br />Fri Nov 9 14:05:02 2018 DLSS7 <000c> xua_asp_fsm.c:404 XUA_AS(virt-bsc0){AS_ACTIVE}: Received Event ASPAS-ASP_DOWN.ind<br />Fri Nov 9 14:05:02 2018 DLSS7 <000c> xua_as_fsm.c:263 XUA_AS(virt-bsc0){AS_ACTIVE}: state_chg to AS_PENDING<br />Fri Nov 9 14:05:02 2018 DLSS7 <000c> xua_asp_fsm.c:125 asp-virt-bsc0-0: No Layer Manager, dropping M-ASP_DOWN.indication<br />Fri Nov 9 14:05:02 2018 DLSS7 <000c> xua_asp_fsm.c:125 asp-virt-bsc0-0: No Layer Manager, dropping M-SCTP_RELEASE.indication<br />Fri Nov 9 14:05:02 2018 DLINP <0002> stream.c:811 sending data
=================================================================<br />28165ERROR: AddressSanitizer: heap-use-after-free on address 0x611000007298 at pc 0x7ffff3d20f2f bp 0x7fffffffd6d0 sp 0x7fffffffd6c0<br />READ of size 8 at 0x611000007298 thread T0<br /> #0 0x7ffff3d20f2e in llist_empty /home/stsp/osmo/prefix/include/osmocom/core/linuxlist.h:167<br /> <a class="issue tracker-2 status-5 priority-5 priority-highest closed" title="Feature: port Dieter's windows code to mISDN (Closed)" href="https://osmocom.org/issues/1">#1</a> 0x7ffff3d25b17 in osmo_stream_srv_write /home/stsp/osmo/libosmo-netif/src/stream.c:813<br /> <a class="issue tracker-1 status-5 priority-3 priority-high3 closed" title="Bug: Fix / finish the paging code (Closed)" href="https://osmocom.org/issues/2">#2</a> 0x7ffff3d26312 in osmo_stream_srv_cb /home/stsp/osmo/libosmo-netif/src/stream.c:853<br /> <a class="issue tracker-1 status-5 priority-3 priority-high3 closed" title="Bug: Finish TRAU frame demultiplex/remultiplex (Closed)" href="https://osmocom.org/issues/3">#3</a> 0x7ffff61c0843 in osmo_fd_disp_fds /home/stsp/osmo/libosmocore/src/select.c:217<br /> <a class="issue tracker-1 status-5 priority-2 priority-default closed" title="Bug: multiple TRX support (Closed)" href="https://osmocom.org/issues/4">#4</a> 0x7ffff61c0b44 in osmo_select_main /home/stsp/osmo/libosmocore/src/select.c:257<br /> <a class="issue tracker-2 status-5 priority-2 priority-default closed" title="Feature: multiple BTS support (Closed)" href="https://osmocom.org/issues/5">#5</a> 0x555555556c43 in main /home/stsp/osmo/libosmo-sccp/stp/stp_main.c:210<br /> <a class="issue tracker-2 status-5 priority-2 priority-default closed" title="Feature: cell broadcast support (Closed)" href="https://osmocom.org/issues/6">#6</a> 0x7ffff5038b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)<br /> <a class="issue tracker-1 status-5 priority-3 priority-high3 closed" title="Bug: SMS switching (Closed)" href="https://osmocom.org/issues/7">#7</a> 0x5555555563e9 in _start (/home/stsp/osmo/prefix/bin/osmo-stp+0x23e9)</p>
<p>0x611000007298 is located 152 bytes inside of 200-byte region [0x611000007200,0x6110000072c8)<br />freed by thread T0 here:<br /> #0 0x7ffff6ef87b8 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xde7b8)<br /> <a class="issue tracker-2 status-5 priority-5 priority-highest closed" title="Feature: port Dieter's windows code to mISDN (Closed)" href="https://osmocom.org/issues/1">#1</a> 0x7ffff6829a52 in _talloc_free (/usr/lib/x86_64-linux-gnu/libtalloc.so.2+0x3a52)</p>
<p>previously allocated by thread T0 here:<br /> #0 0x7ffff6ef8b50 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb50)<br /> <a class="issue tracker-2 status-5 priority-5 priority-highest closed" title="Feature: port Dieter's windows code to mISDN (Closed)" href="https://osmocom.org/issues/1">#1</a> 0x7ffff682bd20 in _talloc_zero (/usr/lib/x86_64-linux-gnu/libtalloc.so.2+0x5d20)</p>
<p>SUMMARY: AddressSanitizer: heap-use-after-free /home/stsp/osmo/prefix/include/osmocom/core/linuxlist.h:167 in llist_empty<br />Shadow bytes around the buggy address:<br /> 0x0c227fff8e00: fd fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa<br /> 0x0c227fff8e10: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd<br /> 0x0c227fff8e20: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd<br /> 0x0c227fff8e30: fd fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa<br /> 0x0c227fff8e40: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd<br />=>0x0c227fff8e50: fd fd fd[fd]fd fd fd fd fd fa fa fa fa fa fa fa<br /> 0x0c227fff8e60: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa<br /> 0x0c227fff8e70: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa<br /> 0x0c227fff8e80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa<br /> 0x0c227fff8e90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa<br /> 0x0c227fff8ea0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa<br />Shadow byte legend (one shadow byte represents 8 application bytes):<br /> Addressable: 00<br /> Partially addressable: 01 02 03 04 05 06 07<br /> Heap left redzone: fa<br /> Freed heap region: fd<br /> Stack left redzone: f1<br /> Stack mid redzone: f2<br /> Stack right redzone: f3<br /> Stack after return: f5<br /> Stack use after scope: f8<br /> Global redzone: f9<br /> Global init order: f6<br /> Poisoned by user: f7<br /> Container overflow: fc<br /> Array cookie: ac<br /> Intra object redzone: bb<br /> ASan internal: fe<br /> Left alloca redzone: ca<br /> Right alloca redzone: cb<br />28165ABORTING<br />}}}</p> libosmocore - Bug #3674 (Resolved): 'show rate-counters' VTY command uses ambiguous group titleshttps://osmocom.org/issues/36742018-10-26T13:53:19Zstsp
<p>The 'show rate-counters' command added in commit 73b7fa61096c69c137bc3a1cbac0a83355cf8b5f shows the name of each counter group. If there are multiple instances of a given counter group, they all share the same description. This makes it hard to tell where the displayed counters belong.</p>
<p>For instance, osmo-mgw maintains RTP statistics per connection, and if more than one connection exists, we get a list of counter groups with no indication which connection the counters belong to:</p>
<pre>
OsmoMGW> show rate-counters
rtp connection statistics:
stream_err_tstmp:in: 0 (0/s 0/m 0/h 0/d) Inbound rtp-stream timestamp errors.
stream_err_tstmp:out: 0 (0/s 0/m 0/h 0/d) Outbound rtp-stream timestamp errors.
rtp:packets_rx: 3 (0/s 0/m 0/h 0/d) Inbound rtp packets.
rtp:octets_rx: 48 (0/s 0/m 0/h 0/d) Inbound rtp octets.
rtp:packets_tx: 0 (0/s 0/m 0/h 0/d) Outbound rtp packets.
rtp:octets_rx: 0 (0/s 0/m 0/h 0/d) Outbound rtp octets.
rtp:dropped: 0 (0/s 0/m 0/h 0/d) dropped rtp packets.
rtp connection statistics:
stream_err_tstmp:in: 0 (0/s 0/m 0/h 0/d) Inbound rtp-stream timestamp errors.
stream_err_tstmp:out: 0 (0/s 0/m 0/h 0/d) Outbound rtp-stream timestamp errors.
rtp:packets_rx: 0 (0/s 0/m 0/h 0/d) Inbound rtp packets.
rtp:octets_rx: 0 (0/s 0/m 0/h 0/d) Inbound rtp octets.
rtp:packets_tx: 3 (0/s 0/m 0/h 0/d) Outbound rtp packets.
rtp:octets_rx: 48 (0/s 0/m 0/h 0/d) Outbound rtp octets.
rtp:dropped: 0 (0/s 0/m 0/h 0/d) dropped rtp packets.
</pre> OsmoPCU - Bug #3643 (Resolved): osmo-pcu NULL-pointer dereference after socket bind failurehttps://osmocom.org/issues/36432018-10-10T13:55:16Zstsp
<p>osmo-pcu can crash in the following way if it cannot bind to a particular port:</p>
<pre>
<000e> telnet_interface.c:104 telnet at 127.0.0.1 4240
<0001> osmobts_sock.cpp:248 Opening OsmoPCU L1 interface to OsmoBTS
<0001> osmobts_sock.cpp:311 osmo-bts PCU socket /tmp/pcu_bts has been connected
<0001> osmobts_sock.cpp:315 Sending version 0.5.1.6-07612-dirty to BTS.
<0001> pcu_l1_if.cpp:113 Sending 0.5.1.6-07612-dirty TXT as PCU_VERSION to BTS
<0001> pcu_l1_if.cpp:443 BTS available
<000b> gprs_ns.c:266 NSVCI=65534 Creating NS-VC
<000e> socket.c:228 unable to bind socket: 0.0.0.0:23000: Address already in use
<000e> socket.c:237 no suitable local addr found for: 0.0.0.0:23000
<000b> gprs_ns.c:1622 Listening for nsip packets from 127.0.0.1:23020 on 0.0.0.0:23000
<000c> gprs_bssgp_pcu.cpp:912 Failed to create socket
../include/osmocom/core/linuxlist.h:114:13: runtime error: member access within null pointer of type 'struct llist_head'
ASAN:DEADLYSIGNAL
=================================================================
==25074==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000008 (pc 0x7ff61ceb5981 bp 0x7ffc629c4a30 sp 0x7ffc629c4a20 T0)
==25074==The signal is caused by a WRITE memory access.
==25074==Hint: address points to the zero page.
#0 0x7ff61ceb5980 in __llist_del ../include/osmocom/core/linuxlist.h:114
#1 0x7ff61ceb5a8f in llist_del ../include/osmocom/core/linuxlist.h:126
#2 0x7ff61ceb621e in osmo_fd_unregister /home/stsp/osmo/libosmocore/src/select.c:140
#3 0x7ff61dc42d7f in gprs_ns_close /home/stsp/osmo/libosmocore/src/gb/gprs_ns.c:1484
#4 0x7ff61dc42df0 in gprs_ns_destroy /home/stsp/osmo/libosmocore/src/gb/gprs_ns.c:1497
#5 0x55a2be9b7b04 in gprs_bssgp_create_and_connect(gprs_rlcmac_bts*, unsigned short, unsigned int, unsigned short, unsigned short, unsigned
short, unsigned short, unsigned short, unsigned short, bool, unsigned short, unsigned short, unsigned short) /home/stsp/osmo/osmo-pcu/src/gprs_b
ssgp_pcu.cpp:913
#6 0x55a2be9bb2ed in pcu_rx_info_ind /home/stsp/osmo/osmo-pcu/src/pcu_l1_if.cpp:495
#7 0x55a2be9bb95c in pcu_rx(unsigned char, gsm_pcu_if*) /home/stsp/osmo/osmo-pcu/src/pcu_l1_if.cpp:626
#8 0x55a2be9b0736 in pcu_sock_read /home/stsp/osmo/osmo-pcu/src/osmobts_sock.cpp:162
#9 0x55a2be9b0960 in pcu_sock_cb /home/stsp/osmo/osmo-pcu/src/osmobts_sock.cpp:229
#10 0x7ff61ceb7573 in osmo_fd_disp_fds /home/stsp/osmo/libosmocore/src/select.c:217
#11 0x7ff61ceb7874 in osmo_select_main /home/stsp/osmo/libosmocore/src/select.c:257
#12 0x55a2be986efc in main /home/stsp/osmo/osmo-pcu/src/pcu_main.cpp:337
#13 0x7ff61c290b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
#14 0x55a2be9864d9 in _start (/home/stsp/osmo/prefix/bin/osmo-pcu+0x1b4d9)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV ../include/osmocom/core/linuxlist.h:114 in __llist_del
==25074==ABORTING
</pre> OsmoBTS - Bug #3513 (Resolved): unsolicited channel activation acknowledgehttps://osmocom.org/issues/35132018-08-31T15:16:38Zstsp
<p>While running TTCN3 tests with a sysmobts and osmocom-bb, I ran into test failure "RSL for unknown Dchan"</p>
<p>Specifically, while the BTS is being configured, this code in RSL Emulation is triggered by an<br />unsolicited channel activation acknowledge RSL message:</p>
<pre> [not dchan_suspended] IPA_PT.receive(tr_RSL(tr_RSL_MsgTypeDR(?))) -> value rx_rsl {
/* dispatch to channel based on ChanId */
cid := f_cid_by_chan_nr(f_trx_by_streamId(rx_rsl.streamId),
rx_rsl.rsl.ies[0].body.chan_nr);
if (cid != -1) {
CLIENT_PT.send(rx_rsl.rsl) to ConnectionTable[cid].comp_ref;
} else {
setverdict(fail, "RSL for unknown Dchan");
mtc.stop;
}
}
</pre>
<pre>
Frame 396: 76 bytes on wire (608 bits), 76 bytes captured (608 bits) on interface 0
Ethernet II, Src: Sysmocom_00:00:0a (24:62:78:00:00:0a), Dst: WistronI_9e:0e:57 (f0:de:f1:9e:0e:57)
Internet Protocol Version 4, Src: 192.168.100.3, Dst: 192.168.100.11
Transmission Control Protocol, Src Port: 47256, Dst Port: 3003, Seq: 46, Ack: 11, Len: 10
IPA protocol ip.access, type: RSL
DataLen: 7
Protocol: RSL (0x00)
Radio Signalling Link (RSL)
0000 100. = Message discriminator: Dedicated Channel Management messages (4)
.... ...0 = T bit: Not considered transparent by BTS
.010 0010 = Message type: CHANnel ACTIVation ACKnowledge (0x22)
Channel number IE
Element identifier: Channel Number (0x01)
0010 0... = C-bits: SDCCH/4 + ACCH (sub-chan 0) (4)
.... .000 = Time slot number (TN): 0
Frame Number IE
Element identifier: Frame Number (0x08)
0000 0... = T1': 0
.... .011 001. .... = T3: 25
...1 1000 = T2: 24
</pre>
<p>Here is another example after changing the control channel 0 to BCCH:</p>
<pre>
Frame 53997: 76 bytes on wire (608 bits), 76 bytes captured (608 bits) on interface 0
Ethernet II, Src: Sysmocom_00:00:0a (24:62:78:00:00:0a), Dst: WistronI_9e:0e:57 (f0:de:f1:9e:0e:57)
Internet Protocol Version 4, Src: 192.168.100.3, Dst: 192.168.100.11
Transmission Control Protocol, Src Port: 47660, Dst Port: 3003, Seq: 46, Ack: 11, Len: 10
IPA protocol ip.access, type: RSL
DataLen: 7
Protocol: RSL (0x00)
Radio Signalling Link (RSL)
0000 100. = Message discriminator: Dedicated Channel Management messages (4)
.... ...0 = T bit: Not considered transparent by BTS
.010 0010 = Message type: CHANnel ACTIVation ACKnowledge (0x22)
Channel number IE
Element identifier: Channel Number (0x01)
1000 0... = C-bits: BCCH (16)
.... .000 = Time slot number (TN): 0
Frame Number IE
Element identifier: Frame Number (0x08)
0000 0... = T1': 0
.... .100 001. .... = T3: 33
...0 0110 = T2: 6
</pre>
<p>This unsolicited message should not be sent.</p> osmo-gbproxy - Bug #3466 (Resolved): gprs_gb_parse_dtap does not handle "DEACT PDP ACK"https://osmocom.org/issues/34662018-08-16T10:38:13Zstsp
<p>While investigating issue <a class="issue tracker-1 status-6 priority-2 priority-default closed" title="Bug: gbproxy: failed to parse invalid BSSGP-UNITDATA message (Rejected)" href="https://osmocom.org/issues/3178">#3178</a>, we found that gprs_gb_parse_dtap() is logging unhandled messages:</p>
<pre>
<0011> gprs_gb_parse.c:384 Unhandled GSM 04.08 message type unknown 0x47 for protocol discriminator SM
</pre>
<p>The meaning of message type 0x47 is "DEACT PDP ACK"</p>
<p>From osmo-sgsn's gsm_04_08_gprs.h:<br /><pre>
/* Table 10.4a, GPRS Session Management (GSM) */
#define GSM48_MT_GSM_ACT_PDP_REQ 0x41
#define GSM48_MT_GSM_ACT_PDP_ACK 0x42
#define GSM48_MT_GSM_ACT_PDP_REJ 0x43
#define GSM48_MT_GSM_REQ_PDP_ACT 0x44
#define GSM48_MT_GSM_REQ_PDP_ACT_REJ 0x45
#define GSM48_MT_GSM_DEACT_PDP_REQ 0x46
#define GSM48_MT_GSM_DEACT_PDP_ACK 0x47
</pre></p>
<p>This happened with a Sony Ericsson "Cyber Shot" phone (I cannot look up the exact model number right now, unfortunately) using an On-Waves test SIM (if in doubt ask <a class="user active" href="https://osmocom.org/users/30187">pespin</a> for details). The message appears after setting up a data connection profile in the phone's settings menu (select PS connection type, put in an arbitrary APN/user/password), and then trying to visit any website with the phone's browser (labeled "Internet" on the phone's main menu screen).</p>
<p>Browsing websites does not work with this phone (this could be part of larger problem which might not be strictly related to "DEACT PDP ACK"). It shows a full screen error message which states that there was a connection problem. Note that the phone's default homepage is a WAP page that is no longer served by Sony, so I tried browsing <a class="external" href="http://www.sysmocom.de">www.sysmocom.de</a> and saw the same error. However, browsing works with other phones, e.g. it works with a Samsung Galaxy S2 which doesn't seem to send "DEACT PDP ACK".</p>
<p>The base station was an On-Waves AU running current experimental ONW images (libosmocore 94c0031297abb0bb42a4ea23e68f944622f50469 and osmo-pcu 3df1532e97c5c774a4abefffc2d62b8cc2d468da). I don't know the exact commit of osmo-sgsn, but it is likely close to current master commit 9b5d7f6398295af2ea33493f72917f161e8048de.</p>
<p>In any case, it is obvious that the switch statement in gprs_gb_parse_dtap() does not yet have a case for "DEACT PDP ACK" messages. We still need to determine whether this is an actual problem and if so how it could be fixed.</p>
<p>Please keep in mind that when investigating this issue we might also want to consider other message types which are not yet handled by gprs_gb_parse_dtap() and possibly file issues for any of those other cases as well.</p> OsmoBTS - Bug #3418 (Closed): BTS TTCN-3 tests generate L2 frames with incorrect lengthhttps://osmocom.org/issues/34182018-07-25T15:42:00Zstsp
<p>Since issue <a class="issue tracker-1 status-5 priority-2 priority-default closed" title="Bug: heap overflow in trxcon / tch_fr_disassemble() (Closed)" href="https://osmocom.org/issues/3415">#3415</a> has been fixed, some BTS tests have started failing<br />because trxcon is now dropping frames generated by these tests.</p>
<p>The newly failing tests are:</p>
<p>BTS_Tests.TC_meas_res_sign_tchf<br />BTS_Tests.TC_meas_res_sign_tchh<br />BTS_Tests.TC_meas_res_sign_tchf<br />BTS_Tests.TC_meas_res_sign_tchh<br />BTS_Tests.TC_meas_res_sign_sdcch4<br />BTS_Tests.TC_meas_res_sign_sdcch8<br />BTS_Tests.TC_meas_res_sign_tchh_toa256<br />BTS_Tests.TC_rll_est_ind<br />BTS_Tests.TC_rll_rel_ind_DCCH_0<br />BTS_Tests.TC_rll_rel_ind_DCCH_3<br />BTS_Tests.TC_rll_rel_ind_ACCH_0<br />BTS_Tests.TC_rll_rel_ind_ACCH_3<br />BTS_Tests.TC_rll_unit_data_ind_DCCH<br />BTS_Tests.TC_chan_act_a51<br />BTS_Tests.TC_chan_act_a52<br />BTS_Tests.TC_chan_act_a53<br />BTS_Tests.TC_encr_cmd_a51<br />BTS_Tests.TC_encr_cmd_a52<br />BTS_Tests.TC_encr_cmd_a53</p> OsmocomBB - Bug #3415 (Closed): heap overflow in trxcon / tch_fr_disassemble()https://osmocom.org/issues/34152018-07-24T12:46:35Zstsp
<p>Using trxconn and libosmocore from latest master with address-sanitizer enabled, running TTCN3 BTS tests crashes trxconn:</p>
<pre>
<0005> sched_trx.c:420 Activating lchan=BCCH on ts=0
<0005> sched_trx.c:420 Activating lchan=RACH on ts=0
<0005> sched_trx.c:420 Activating lchan=CCCH on ts=0
<0001> l1ctl.c:502 Received RACH request (offset=0 ra=0x17)
<0005> sched_clck.c:140 Clock indication: fn=204
<0001> l1ctl.c:547 Received L1CTL_DM_EST_REQ (arfcn=871, chan_nr=0x09, tsc=7, tch_mode=0x00)
<0005> sched_trx.c:192 Add a new TDMA timeslot #1
<0005> sched_trx.c:263 (Re)configure TDMA timeslot #1 as TCH/F+SACCH
<0005> sched_trx.c:420 Activating lchan=TCH/F on ts=1
<0005> sched_trx.c:420 Activating lchan=SACCH/TF on ts=1
<0006> sched_lchan_tchf.c:110 Received incomplete traffic frame at fn=0 (0/104) for TCH/F
=================================================================
==17561==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60d000072413 at pc 0x7f917349b1ff bp 0x7ffdfc7b3cd0 sp 0x7ffdfc7b3cc0
READ of size 1 at 0x60d000072413 thread T0
#0 0x7f917349b1fe in tch_fr_disassemble /home/stsp/osmo/libosmocore/src/coding/gsm0503_coding.c:1546
#1 0x7f917349f540 in gsm0503_tch_fr_encode /home/stsp/osmo/libosmocore/src/coding/gsm0503_coding.c:1902
#2 0x561c306d5a72 in tx_tchf_fn /home/stsp/osmo/osmocom-bb/src/host/trxcon/sched_lchan_tchf.c:243
#3 0x561c306db384 in sched_frame_clck_cb /home/stsp/osmo/osmocom-bb/src/host/trxcon/sched_trx.c:118
#4 0x561c306d7f02 in sched_clck_tick /home/stsp/osmo/osmocom-bb/src/host/trxcon/sched_clck.c:93
#5 0x7f9173787fe0 in osmo_timers_update /home/stsp/osmo/libosmocore/src/timer.c:257
#6 0x7f917378ace4 in osmo_select_main /home/stsp/osmo/libosmocore/src/select.c:254
#7 0x561c306c4c6e in main /home/stsp/osmo/osmocom-bb/src/host/trxcon/trxcon.c:304
#8 0x7f9171ea6b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
#9 0x561c306c5009 in _start (/home/stsp/osmo/prefix/bin/trxcon+0x2b009)
0x60d000072413 is located 0 bytes to the right of 131-byte region [0x60d000072390,0x60d000072413)
allocated by thread T0 here:
#0 0x7f9173dc7b50 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb50)
#1 0x7f9173ad9d20 in _talloc_zero (/usr/lib/x86_64-linux-gnu/libtalloc.so.2+0x5d20)
SUMMARY: AddressSanitizer: heap-buffer-overflow /home/stsp/osmo/libosmocore/src/coding/gsm0503_coding.c:1546 in tch_fr_disassemble
Shadow bytes around the buggy address:
0x0c1a80006430: 00 00 00 00 00 00 fa fa fa fa fa fa fa fa fd fd
0x0c1a80006440: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fa
0x0c1a80006450: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
0x0c1a80006460: 00 00 00 00 00 00 00 00 00 00 fa fa fa fa fa fa
0x0c1a80006470: fa fa 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c1a80006480: 00 00[03]fa fa fa fa fa fa fa fa fa 00 00 00 00
0x0c1a80006490: 00 00 00 00 00 00 00 00 00 00 00 00 03 fa fa fa
0x0c1a800064a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c1a800064b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c1a800064c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c1a800064d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==17561==ABORTING
</pre> OsmoPCU - Bug #3290 (Closed): osmo-pcu runtime errors due to clock drift in gprs_rlcmac_meas.cpphttps://osmocom.org/issues/32902018-05-25T12:49:50Zstsp
<p>The first jenkins verification run of <a class="external" href="https://gerrit.osmocom.org/#/c/osmo-pcu/+/9301/">https://gerrit.osmocom.org/#/c/osmo-pcu/+/9301/</a> failed because the substraction of two struct timevals lead to a negative number even though it should not:</p>
<pre>
(02:34:07 PM) stsp_: this failure in osmo-pcu jenkins looks like clock skew: +../../../src/gprs_rlcmac_meas.cpp:178:40: runtime error: left shift of negative value -999116
(02:34:20 PM) stsp_: also here: +../../../src/gprs_rlcmac_meas.cpp:134:42: runtime error: left shift of negative value -999039
</pre>
<p>Given the implicit assumption made in this code that time won't ever go backwards, it seems this code really wants to be using clock_gettime with CLOCK_MONOTONIC instead of gettimeofday().</p> OsmoPCU - Bug #3289 (Resolved): stack buffer overflow in pcu_l1if_tx_pch()https://osmocom.org/issues/32892018-05-25T12:15:36Zstsp
<p>Address sanitizer found the following stack buffer overflow.</p>
<p>I will submit a patch to gerrit shortly.<br />This is a one-byte overrun due to an off-by-one in the size of a buffer on the stack in pcu_l1if_tx_pch().</p>
<pre>
% Ignoring deprecated logging level everything
<000e> telnet_interface.c:104 telnet at 127.0.0.1 4240
<0001> osmobts_sock.cpp:248 Opening OsmoPCU L1 interface to OsmoBTS
<0001> osmobts_sock.cpp:308 osmo-bts PCU socket /tmp/pcu_bts has been connected
<0001> osmobts_sock.cpp:312 Sending version 0.5.0.3-7a9c to BTS.
<0001> pcu_l1_if.cpp:113 Sending 0.5.0.3-7a9c TXT as PCU_VERSION to BTS
<0001> pcu_l1_if.cpp:442 BTS available
<000b> gprs_ns.c:266 NSVCI=65534 Creating NS-VC
<000b> gprs_ns.c:1622 Listening for nsip packets from 127.0.0.1:23020 on 0.0.0.0:23000
<000b> gprs_ns.c:1641 NS UDP socket at 0.0.0.0:23000
<000b> gprs_ns.c:266 NSVCI=1234 Creating NS-VC
<000b> gprs_ns.c:1659 NSEI=1234 RESET procedure based on API request
<000b> gprs_ns.c:449 NSEI=1234 Tx NS RESET (NSVCI=1234, cause=O&M intervention)
<0001> pcu_l1_if.cpp:125 Sending activate request: trx=0 ts=4
<0001> pcu_l1_if.cpp:569 PDCH: trx=0 ts=4
<0001> pcu_l1_if.cpp:125 Sending activate request: trx=0 ts=5
<0001> pcu_l1_if.cpp:569 PDCH: trx=0 ts=5
<0001> pcu_l1_if.cpp:125 Sending activate request: trx=0 ts=6
<0001> pcu_l1_if.cpp:569 PDCH: trx=0 ts=6
<0001> pcu_l1_if.cpp:125 Sending activate request: trx=0 ts=7
<0001> pcu_l1_if.cpp:569 PDCH: trx=0 ts=7
<000b> gprs_ns.c:998 NSVCI=1234 Rx NS RESET ACK (NSEI=1234, NSVCI=1234)
<000b> gprs_ns.c:558 NSEI=1234 Tx NS UNBLOCK (NSVCI=1234)
<000b> gprs_ns.c:1420 NSEI=1234 Rx NS UNBLOCK ACK
<000d> gprs_bssgp_pcu.cpp:546 NS-VC 1234 is unblocked.
<000c> gprs_bssgp_pcu.cpp:825 Sending reset on BVCI 0
<000c> gprs_bssgp_bss.c:294 BSSGP (BVCI=0) Tx BVC-RESET CAUSE=O&M intervention
<000c> gprs_bssgp_pcu.cpp:431 rx BVCI_SIGNALLING gprs_bssgp_rx_sign
<000c> gprs_bssgp_pcu.cpp:304 Rx BSSGP BVCI=-1 (SIGN) BVC_RESET_ACK
<000c> gprs_bssgp_pcu.cpp:833 Sending reset on BVCI 1234
<000c> gprs_bssgp_bss.c:294 BSSGP (BVCI=1234) Tx BVC-RESET CAUSE=O&M intervention
<000c> gprs_bssgp_pcu.cpp:431 rx BVCI_SIGNALLING gprs_bssgp_rx_sign
<000c> gprs_bssgp_pcu.cpp:304 Rx BSSGP BVCI=-1 (SIGN) BVC_RESET_ACK
<000c> gprs_bssgp_pcu.cpp:841 Sending unblock on BVCI 1234
<000c> gprs_bssgp_bss.c:274 BSSGP (BVCI=1234) Tx BVC-BLOCK
<000c> gprs_bssgp_pcu.cpp:431 rx BVCI_SIGNALLING gprs_bssgp_rx_sign
<000c> gprs_bssgp_pcu.cpp:195 P-TMSI =
<0002> gprs_rlcmac.cpp:34 TX: [PCU -> BTS] Paging Request (CCCH)
=================================================================
==2858==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffc7c579b8a at pc 0x7fe285a6a33e bp 0x7ffc7c579ae0 sp 0x7ffc7c579ad0
WRITE of size 1 at 0x7ffc7c579b8a thread T0
#0 0x7fe285a6a33d in bitvec_pack /home/stsp/osmo/libosmocore/src/bitvec.c:439
#1 0x556b9b7155e1 in pcu_l1if_tx_pch(bitvec*, int, char const*) /home/stsp/osmo/osmo-pcu/src/pcu_l1_if.cpp:230
#2 0x556b9b71060c in gprs_rlcmac_paging_request(unsigned char*, unsigned short, char const*) /home/stsp/osmo/osmo-pcu/src/gprs_rlcmac.cpp:38
#3 0x556b9b70b51f in gprs_bssgp_pcu_rx_paging_ps(msgb*, tlv_parsed*) /home/stsp/osmo/osmo-pcu/src/gprs_bssgp_pcu.cpp:208
#4 0x556b9b70dd4e in gprs_bssgp_pcu_rx_sign /home/stsp/osmo/osmo-pcu/src/gprs_bssgp_pcu.cpp:312
#5 0x556b9b70dd4e in gprs_bssgp_pcu_rcvmsg /home/stsp/osmo/osmo-pcu/src/gprs_bssgp_pcu.cpp:432
#6 0x7fe2867c649c in gprs_ns_rx_unitdata /home/stsp/osmo/libosmocore/src/gb/gprs_ns.c:785
#7 0x7fe2867ce236 in gprs_ns_process_msg /home/stsp/osmo/libosmocore/src/gb/gprs_ns.c:1401
#8 0x7fe2867cbb6f in gprs_ns_rcvmsg /home/stsp/osmo/libosmocore/src/gb/gprs_ns.c:1171
#9 0x7fe2867cfe19 in handle_nsip_read /home/stsp/osmo/libosmocore/src/gb/gprs_ns.c:1549
#10 0x7fe2867d0106 in nsip_fd_cb /home/stsp/osmo/libosmocore/src/gb/gprs_ns.c:1582
#11 0x7fe285a60763 in osmo_fd_disp_fds /home/stsp/osmo/libosmocore/src/select.c:217
#12 0x7fe285a60a64 in osmo_select_main /home/stsp/osmo/libosmocore/src/select.c:257
#13 0x556b9b66a766 in main /home/stsp/osmo/osmo-pcu/src/pcu_main.cpp:337
#14 0x7fe284111b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
#15 0x556b9b66bf39 in _start (/home/stsp/osmo/prefix/bin/osmo-pcu+0x152f39)
Address 0x7ffc7c579b8a is located in stack of thread T0 at offset 58 in frame
#0 0x556b9b7153df in pcu_l1if_tx_pch(bitvec*, int, char const*) /home/stsp/osmo/osmo-pcu/src/pcu_l1_if.cpp:219
This frame has 1 object(s):
[32, 58) 'data' <== Memory access at offset 58 overflows this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
(longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow /home/stsp/osmo/libosmocore/src/bitvec.c:439 in bitvec_pack
Shadow bytes around the buggy address:
0x10000f8a7320: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10000f8a7330: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10000f8a7340: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10000f8a7350: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10000f8a7360: 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00
=>0x10000f8a7370: 00[02]f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00
0x10000f8a7380: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
0x10000f8a7390: 00 00 f2 f2 00 00 00 00 00 00 00 00 00 00 00 00
0x10000f8a73a0: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 02 f2 f2 f2
0x10000f8a73b0: f2 f2 f2 f2 00 00 00 00 00 00 00 00 00 00 00 00
0x10000f8a73c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
</pre> OsmoBSC - Bug #3282 (Resolved): heap use after free in handle_ts1_write_input()https://osmocom.org/issues/32822018-05-22T11:48:36Zstsp
<p>Address sanitizer reports a heap-use-after-free in osmo-bsc.</p>
<p>I can trigger this by running the TTCN3 BTS test suite.</p>
<pre>
Tue May 22 11:55:59 2018 DRSL <0004> acc_ramp.c:166 (bts=0,trx=0) ACC RAMP: operational state Enabled -> Enabled
Tue May 22 11:55:59 2018 DRSL <0004> acc_ramp.c:175 (bts=0,trx=0) ACC RAMP: ignoring state change because RSL link is down
Tue May 22 11:55:59 2018 DLINP <0013> input/ipaccess.c:244 Sign link problems, closing socket. Reason: Connection reset by peer
Tue May 22 11:55:59 2018 DLINP <0013> input/ipaccess.c:71 Forcing socket shutdown with no signal link set
Tue May 22 11:55:59 2018 DLINP <0013> bts_ipaccess_nanobts.c:426 (bts=0) Dropping OML link.
Tue May 22 11:55:59 2018 DLMI <0015> bsc_init.c:411 Lost some E1 TEI link: 1 0x7f4c41e69860
=================================================================
==28697==ERROR: AddressSanitizer: heap-use-after-free on address 0x62e000408a68 at pc 0x7f4c3fbc3bc6 bp 0x7fff331629f0 sp 0x7fff331629e0
READ of size 8 at 0x62e000408a68 thread T0
#0 0x7f4c3fbc3bc5 in handle_ts1_write input/ipaccess.c:379
#1 0x7f4c3fbc3ceb in ipaccess_fd_cb input/ipaccess.c:399
#2 0x7f4c3feea763 in osmo_fd_disp_fds /home/stsp/osmo/libosmocore/src/select.c:217
#3 0x7f4c3feeaa64 in osmo_select_main /home/stsp/osmo/libosmocore/src/select.c:257
#4 0x563ad5314aa8 in main /home/stsp/osmo/osmo-bsc/src/osmo-bsc/osmo_bsc_main.c:532
#5 0x7f4c3e451b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
#6 0x563ad5312339 in _start (/home/stsp/osmo/prefix/bin/osmo-bsc+0x234339)
0x62e000408a68 is located 1640 bytes inside of 48072-byte region [0x62e000408400,0x62e000413fc8)
freed by thread T0 here:
#0 0x7f4c40f347b8 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xde7b8)
#1 0x7f4c4092fa52 in _talloc_free (/usr/lib/x86_64-linux-gnu/libtalloc.so.2+0x3a52)
previously allocated by thread T0 here:
#0 0x7f4c40f34b50 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb50)
#1 0x7f4c40931d20 in _talloc_zero (/usr/lib/x86_64-linux-gnu/libtalloc.so.2+0x5d20)
SUMMARY: AddressSanitizer: heap-use-after-free input/ipaccess.c:379 in handle_ts1_write
Shadow bytes around the buggy address:
0x0c5c800790f0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c5c80079100: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c5c80079110: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c5c80079120: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c5c80079130: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
=>0x0c5c80079140: fd fd fd fd fd fd fd fd fd fd fd fd fd[fd]fd fd
0x0c5c80079150: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c5c80079160: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c5c80079170: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c5c80079180: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c5c80079190: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==28697==ABORTING
</pre> OsmoBSC - Feature #3245 (Resolved): statistics about BTS disconnections due to unit ID mismatchhttps://osmocom.org/issues/32452018-05-08T12:01:32Zstsp
<p>A common configuration error is running BSC and BTS with mismatching unit_id parameters in their respective configuration files.</p>
<p>It would help if osmo-bsc kept statistics about failed connections due to unit_id match which are displayed at an appropriate place in the VTY.</p> OsmoBTS - Bug #3161 (Resolved): osmo-bts does not send State Changed Event Reports when RF is loc...https://osmocom.org/issues/31612018-04-12T09:24:45Zstsp
<p>A nanobts sends 'State Changed Event Reports' when RF is locked/unlocked.<br />This same state change is redundantly reported in an 'Administrative State Change ACK'.</p>
<p>osmo-bts only reports the administrative state change in the 'Administrative State Change ACK'.<br />For better interop with ipaccess equipment it should also send a 'State Changed Event Report'<br />just like the nanobts does.</p>
<p>For instance, consider the following 'State Changed Event Report' sent by a nanobts.<br />osmo-bts does not send such a report at present. It only sends 'State Changed Event Reports'<br />for operational and availability state changes, but not administrative ones.</p>
<pre>
Frame 8: 74 bytes on wire (592 bits), 74 bytes captured (592 bits) on interface 0
Ethernet II, Src: IpAccess_00:5a:d7 (00:02:95:00:5a:d7), Dst: WistronI_9e:0e:57 (f0:de:f1:9e:0e:57)
Internet Protocol Version 4, Src: 192.168.100.4, Dst: 192.168.100.11
Transmission Control Protocol, Src Port: 6611, Dst Port: 3002, Seq: 19, Ack: 19, Len: 20
IPA protocol ip.access, type: OML
GSM A-bis OML, Radio Carrier(00,00,ff) State Changed Event Report
Message Discriminator: Formatted O&M (0x80)
Placement Indicator: Only (0x80)
Sequence Number: 0x00
Length Indicator: 13
FOM Message Type: State Changed Event Report
FOM Object Class: Radio Carrier (0x02)
FOM Object Instance BTS: 0
FOM Object Instance TRX: 0
FOM Object Instance TS: 255
FOM Attribute ID: Operational State
FOM Attribute Length: 1
Operational State: Disabled (0x01)
FOM Attribute ID: Availability Status
FOM Attribute Length: 1
Availability Status: Off line (0x03)
FOM Attribute ID: Administrative State
FOM Attribute Length: 1
Administrative State: Unlocked (0x02)
</pre>
<p>The above report was preceded by the Administrative State Changed ACK:</p>
<pre>
Frame 5: 68 bytes on wire (544 bits), 68 bytes captured (544 bits) on interface 0
Ethernet II, Src: IpAccess_00:5a:d7 (00:02:95:00:5a:d7), Dst: WistronI_9e:0e:57 (f0:de:f1:9e:0e:57)
Internet Protocol Version 4, Src: 192.168.100.4, Dst: 192.168.100.11
Transmission Control Protocol, Src Port: 6611, Dst Port: 3002, Seq: 5, Ack: 19, Len: 14
IPA protocol ip.access, type: OML
GSM A-bis OML, Radio Carrier(00,00,ff) Change Administrative State ACK
Message Discriminator: Formatted O&M (0x80)
Placement Indicator: Only (0x80)
Sequence Number: 0x00
Length Indicator: 7
FOM Message Type: Change Administrative State ACK
FOM Object Class: Radio Carrier (0x02)
FOM Object Instance BTS: 0
FOM Object Instance TRX: 0
FOM Object Instance TS: 255
FOM Attribute ID: Administrative State
FOM Attribute Length: 1
Administrative State: Unlocked (0x02)
</pre>
<p>This issue was discovered during work on issue <a class="issue tracker-2 status-3 priority-2 priority-default closed" title="Feature: ramp up cell slowly based on access control class to avoid severe RACH/SDCCH overload (Resolved)" href="https://osmocom.org/issues/2591">#2591</a>, in particular in changeset: <a class="external" href="https://gerrit.osmocom.org/#/c/7770/">https://gerrit.osmocom.org/#/c/7770/</a></p> OsmoHLR - Bug #3154 (Resolved): osmo-hlr should send updated subscriber data to relevant VLR/SGSN...https://osmocom.org/issues/31542018-04-10T16:09:15Zstsp
<p>When subscriber data is changed in the HLR database, osmo-hlr sends Insert Subscriber Data messages to all connected GSUP clients.<br />This behaviour was introduced in patch <a class="external" href="https://gerrit.osmocom.org/#/c/7685/">https://gerrit.osmocom.org/#/c/7685/</a> (see osmo_hlr_subscriber_update_notify() in hlr.c) for issue <a class="issue tracker-1 status-3 priority-3 priority-high3 closed" title="Bug: OsmoHLR forgets to send InsertSubscriberData to VLR/SGSN when data changes (Resolved)" href="https://osmocom.org/issues/2785">#2785</a>.</p>
<p>As noted in the code comment added in this patch, it would be better to only send notifications to VLR/SGSN which are responsible for the subscriber.</p> libosmocore - Bug #3124 (Resolved): rename CELL_IDENT_LAI_AND_LAC to CELL_IDENT_LAIhttps://osmocom.org/issues/31242018-03-29T14:41:04Zstsp
<p>The constant CELL_IDENT_LAI_AND_LAC is part of an enum defined in include/osmocom/gsm/protocol/gsm_08_08.h.<br />"LAI and LAC" is a misnomer.</p>
<p>Quoting Neels in <a class="external" href="http://lists.osmocom.org/pipermail/openbsc/2018-March/011862.html">http://lists.osmocom.org/pipermail/openbsc/2018-March/011862.html</a>:<br /><pre>
A "LAI" is by definition a PLMN (MCC+MNC) plus a LAC.
So saying "LAI and LAC" is like saying "My family and my brother".
I think we should rename it and have a backwards compat:
#define CELL_IDENT_LAI_AND_LAC CELL_IDENT_LAI
</pre></p> OsmoBSC - Feature #3098 (Rejected): ramping of transmit powerhttps://osmocom.org/issues/30982018-03-22T11:52:09Zstsp
<p>This feature issue is about ramping of transmit power.</p>
<p>For details, see issue <a class="issue tracker-2 status-3 priority-2 priority-default closed" title="Feature: ramp up cell slowly based on access control class to avoid severe RACH/SDCCH overload (Resolved)" href="https://osmocom.org/issues/2591">#2591</a>, which this issue was split off from.</p> OsmoBSC - Feature #3097 (New): ramping of "rxlev access min"https://osmocom.org/issues/30972018-03-22T11:51:18Zstsp
<p>This feature issue is about ramping of "rxlev access min" <br />For details, see issue <a class="issue tracker-2 status-3 priority-2 priority-default closed" title="Feature: ramp up cell slowly based on access control class to avoid severe RACH/SDCCH overload (Resolved)" href="https://osmocom.org/issues/2591">#2591</a>, which this issue was split off from.</p> Cellular Network Infrastructure - Feature #3090 (Closed): osmo-ttcn3-hacks: Add automatic managem...https://osmocom.org/issues/30902018-03-20T15:09:02Zstsp
<p>Currently the 'make deps-update' target must be invoked manually to update git repositories stored beneath the deps/ directory.<br />The build process would be more convenient and less error-prone if this were automated.</p>
<p>A related problem is that we are always pulling the master reference, which means our ttcn3 tests could be affected by changes made independently at eclipse.org.<br />The Makefiles should keep track of the exact commit hash (or a tag, if available) which should be retrieved, and update repositories under deps/ accordingly.</p>
<p>The mechanism should also be able to cope with changes to the remote URL of a dependency's git repository.</p>
<p>This might be a good use case for git submodules, but custom Makefile logic should also be able to maintain repositories in sync with the desired state.</p> Cellular Network Infrastructure - Bug #2967 (Resolved): ensure that all programs using osmo_fsm c...https://osmocom.org/issues/29672018-02-20T16:57:53Zstsp
<p>Some programs, for instance osmo-msc, currently do not call osmo_fsm_vty_add_cmds() and thus lack the corresponding commands in the VTY.</p>
<p>All programs using osmo_fsm should call this function. Also consider the possibility to make this happen automatically (e.g. directly in libosmocore).</p> OsmocomBB - Feature #2966 (Resolved): virtphy should have a localhost-only modehttps://osmocom.org/issues/29662018-02-20T12:57:21Zstsp
<p>I am using a virual-um setup on my laptop for osmocom development and testing without additional hardware.</p>
<p>In this situation I do not want virtphy's traffic leaking to the local network,<br />however the traffic currently leaks.</p>
<p>As a workaround, virtphy could be run in a separate network namespace or a virtual machine.<br />But this issue seeks a solution which works without resorting to a separate network stack.</p>
<p>Blocking the traffic with iptables leads to errors on virtphy's socket, and adding a route to 224/4 via lo does<br />not have the desired effect as multicast traffic is still routed towards the default route.</p>
<p>Possible solutions:<br />Harald suggested trying to set the TTL of multicast packets to 0, and there's also the IP_MULTICAST_IF socket option<br />which could be used to bind virtphy to a specific interface.</p> OsmoBSC - Bug #2899 (New): channel attributes are sent to BTS even for NONE channelshttps://osmocom.org/issues/28992018-01-30T16:19:34Zstsp
<p>While trying to set up a network with very few channels, I disabled most channels for bts 0 in the OsmoBSC configuration file by setting them to NONE.</p>
<p>In this configuration, an osmo-bts-virtual BTS refuses channel attributes sent by OsmoBSC, resulting in a failure of the connection between BTS and BSC.</p>
<p>A pcap file showing the protocol exchange is attached (filter for gsm_abis_oml).</p>
<p>The BSC side log says this:<br /><pre>
<0024> input/ipa.c:263 accept()ed new link from 127.0.0.1 to port 3002
<0024> bts_ipaccess_nanobts.c:420 Identified BTS 6969/0/0
<0005> abis_nm.c:1644 Get Attr (bts=0)
<0005> abis_nm.c:1644 Get Attr (bts=0)
<0005> abis_nm.c:382 OC=SITE-MANAGER(00) INST=(ff,ff,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff)
<0005> abis_nm.c:1981 OC=SITE-MANAGER(00) INST=(ff,ff,ff) Sending OPSTART
<0005> abis_nm.c:382 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=NULL AVAIL=Dependency(05)
<0005> abis_nm.c:1662 Set BTS Attr (bts=0)
<0005> abis_nm.c:1981 OC=BTS(01) INST=(00,ff,ff) Sending OPSTART
<0005> abis_nm.c:382 OC=GPRS-NSE(f0) INST=(00,ff,ff) STATE CHG: OP_STATE=NULL AVAIL=Dependency(05)
<0005> abis_nm.c:382 OC=GPRS-CELL(f1) INST=(00,ff,ff) STATE CHG: OP_STATE=NULL AVAIL=Dependency(05)
<0005> abis_nm.c:382 OC=GPRS-NSVC(f2) INST=(00,00,ff) STATE CHG: OP_STATE=NULL AVAIL=Dependency(05)
<0005> abis_nm.c:382 OC=GPRS-NSVC(f2) INST=(00,01,ff) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03)
<0005> abis_nm.c:382 OC=RADIO-CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=NULL AVAIL=Power off(02)
<0005> abis_nm.c:382 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=NULL AVAIL=Power off(02)
<0005> abis_nm.c:382 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=NULL AVAIL=Power off(02)
<0005> abis_nm.c:382 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=NULL AVAIL=Power off(02)
<0005> abis_nm.c:382 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=NULL AVAIL=Power off(02)
<0005> abis_nm.c:382 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=NULL AVAIL=Power off(02)
<0005> abis_nm.c:382 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=NULL AVAIL=Power off(02)
<0005> abis_nm.c:382 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=NULL AVAIL=Power off(02)
<0005> abis_nm.c:382 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=NULL AVAIL=Power off(02)
<0005> abis_nm.c:382 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=NULL AVAIL=Power off(02)
<0005> abis_nm.c:552 OC=BTS(01) INST=(00,ff,ff) Get Attributes Response for BTS0
<0005> abis_nm.c:464 BTS0 Get Attributes Response Info: 65 bytes total with 0 unreported attributes
<0005> abis_nm.c:508 BTS0 feature 'GPRS' reported via OML does not match statically set feature: 0 != 1. Please fix.
<0005> abis_nm.c:508 BTS0 feature 'EGPRS' reported via OML does not match statically set feature: 0 != 1. Please fix.
<0005> abis_nm.c:575 BTS0: ARI reported sw[0/2]: sysmobts is 0.7.0.54-e5b6
<0005> abis_nm.c:447 BTS0 reported variant: unknown
<0005> abis_nm.c:552 OC=BTS(01) INST=(00,ff,ff) Get Attributes Response for BTS0
<0005> abis_nm.c:464 BTS0 Get Attributes Response Info: 32 bytes total with 1 unreported attributes
<0005> abis_nm.c:469 BTS0 Attribute Manufacturer Dependent State is unreported
<0005> abis_nm.c:575 BTS0: ARI reported sw[0/1]: TRX_PHY_VERSION is Unknown
<0005> abis_nm.c:814 OC=SITE-MANAGER(00) INST=(ff,ff,ff) Opstart ACK
<0005> abis_nm.c:382 OC=RADIO-CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=OK(ff)
<0005> abis_nm.c:1981 OC=RADIO-CARRIER(02) INST=(00,00,ff) Sending OPSTART
<0005> abis_nm.c:382 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=NULL AVAIL=OK(ff)
<0005> abis_nm.c:382 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05)
<0005> abis_nm.c:1874 Set Chan Attr (bts=0,trx=0,ts=0)
<0005> abis_nm.c:1981 OC=CHANNEL(03) INST=(00,00,00) Sending OPSTART
<0005> abis_nm.c:382 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05)
<0005> abis_nm.c:1874 Set Chan Attr (bts=0,trx=0,ts=1)
<0005> abis_nm.c:1981 OC=CHANNEL(03) INST=(00,00,01) Sending OPSTART
<0005> abis_nm.c:382 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05)
<0005> abis_nm.c:1874 Set Chan Attr (bts=0,trx=0,ts=2)
<0005> abis_nm.c:1981 OC=CHANNEL(03) INST=(00,00,02) Sending OPSTART
<0005> abis_nm.c:382 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05)
<0005> abis_nm.c:1874 Set Chan Attr (bts=0,trx=0,ts=3)
<0005> abis_nm.c:1981 OC=CHANNEL(03) INST=(00,00,03) Sending OPSTART
<0005> abis_nm.c:382 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05)
<0005> abis_nm.c:1874 Set Chan Attr (bts=0,trx=0,ts=4)
<0005> abis_nm.c:1981 OC=CHANNEL(03) INST=(00,00,04) Sending OPSTART
<0005> abis_nm.c:382 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05)
<0005> abis_nm.c:1874 Set Chan Attr (bts=0,trx=0,ts=5)
<0005> abis_nm.c:1981 OC=CHANNEL(03) INST=(00,00,05) Sending OPSTART
<0005> abis_nm.c:382 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05)
<0005> abis_nm.c:1874 Set Chan Attr (bts=0,trx=0,ts=6)
<0005> abis_nm.c:1981 OC=CHANNEL(03) INST=(00,00,06) Sending OPSTART
<0005> abis_nm.c:382 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05)
<0005> abis_nm.c:1874 Set Chan Attr (bts=0,trx=0,ts=7)
<0005> abis_nm.c:1981 OC=CHANNEL(03) INST=(00,00,07) Sending OPSTART
<0005> abis_nm.c:382 OC=RADIO-CARRIER(02) INST=(00,00,ff) Software Activated Report
<0005> abis_nm.c:1679 Set TRX Attr (bts=0,trx=0)
<0005> abis_nm.c:1981 OC=RADIO-CARRIER(02) INST=(00,00,ff) Sending OPSTART
<0005> abis_nm.c:382 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) Software Activated Report
<0005> abis_nm.c:1981 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) Sending OPSTART
<0005> abis_nm.c:2800 ip.access RSL CONNECT IP=0.0.0.0 PORT=3003 STREAM=0x00
<0005> abis_nm.c:382 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff)
<0005> abis_nm.c:814 OC=BTS(01) INST=(00,ff,ff) Opstart ACK
<0005> abis_nm.c:382 OC=RADIO-CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff)
<0005> abis_nm.c:814 OC=RADIO-CARRIER(02) INST=(00,00,ff) Opstart ACK
<0005> abis_nm.c:818 OC=CHANNEL(03) INST=(00,00,00) Set Channel Attributes ACK
<0005> abis_nm.c:382 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff)
<0005> abis_nm.c:814 OC=CHANNEL(03) INST=(00,00,00) Opstart ACK
<0005> abis_nm.c:768 OC=CHANNEL(03) INST=(00,00,01) SET CHANNEL ATTRIBUTE NACK CAUSE=Parameter value outside permitted range
<0005> bsc_init.c:62 Got SET CHANNEL ATTRIBUTE NACK going to drop the OML links.
</pre></p>