osmocom-net-gprs November 2013

osmocom-net-gprs@lists.osmocom.org

5 participants
5 discussions

Coverity issues in gsm_rlcmac.cpp
by Holger Hans Peter Freyther 15 Jan '14

15 Jan '14

Dear Ivan, could you please have a look at the coverity issues in the gsm_rlcmac.cpp routines? Uninitialized scalar variable: gsm_rlcmac.cpp:5321 ar.direction not initialized gsm_rlcmac.cpp:5039 ar.direction not initialized gsm_rlcmac.cpp:5155 ar.direction not initialized gsm_rlcmac.cpp:4872 ar.direction not initialized Just initialize it in csnStreamInit? Out-of-bounds read: gsm_rlcmac.cpp:5502 " Overrunning array "data->RLC_DATA" of 20 bytes at byte offset 22 using index "i" (which evaluates to 22)." gsm_rlcmac.cpp:5440 " Overrunning array "data->RLC_DATA" of 20 bytes at byte offset 22 using index "i" (which evaluates to 22)." Maybe just add an assert that dataNumOctets <= 20? -- - Holger Freyther <hfreyther(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Schivelbeiner Str. 5 * 10439 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte

4 7

Summary of osmo-pcu failures/defects
by Holger Hans Peter Freyther 27 Nov '13

27 Nov '13

Hi, I have added rate counters to the PCU and noticed that a lot of frames in the DL are re-sent without there actually being any NACK or transmission errors. I have also re-produced a "stall" by just using ping with a big enough data size and a low enough interval (the PCU appears to transmit the ICMP PING but the MS never gets to send a PONG packet). In both cases it could be a scheduling issue (e.g. we don't schedule the UL Packet ACK/NACK). Is any of you aware of it? I had already highlighted that the scheduling is not fair. I wonder if we are seeing starvation (and will re-factor to be able to unit test this). In terms of scheduling. For the SBA we are already having a reservation that we try to honor in multiple places. Maybe it is time to extend it and have more reservations? holger -- - Holger Freyther <hfreyther(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Schivelbeiner Str. 5 * 10439 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte

2 6

gprs_rlcmac_received_lost() in gprs_rlcmac_meas.cpp
by Daniel Willmann 19 Nov '13

19 Nov '13

Hello Andreas, while looking through the osmo-pcu code to figure out why some connections stall we had some problems making sense of the elapsed time calculations in gprs_rlcmac_meas.cpp. Could you confirm/deny my assumptions about it or explain the idea behind it? > gettimeofday(&now_tv, NULL); > elapsed = ((now_tv.tv_sec - loss_tv->tv_sec) << 7) > + ((now_tv.tv_usec - loss_tv->tv_usec) << 7) / 1000000; I assume here you're calculating the duration of the measurement period so far and since you want to have sub-second accuracy you multiply everything with 128. Why 128? Is it becasue it simplifies the throughput calculation? (tbf->meas.dl_bw_octets/elapsed in gprs_rlcmac_dl_bw()) > if (elapsed < 128) > return 0; Is the intention here that the duration of the measurements is supposed to be one second? So every second these measurements are printed out and reset? Regards Daniel Willmann -- - Daniel Willmann <dwillmann(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Schivelbeiner Str. 5 * 10439 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte

2 1

Dropping LLC frames due the TBF destruction
by Holger Hans Peter Freyther 07 Nov '13

07 Nov '13

Hi, my clean-ups are not done but there is a basic structure now that can be refined. I started to add statistics to the BTS (and then will add statistics per tbf but they are short lived so one would need to be quick to see them). E.g. in tbf_free we are freeing still pending llc_frames and I assume that these are related to the "Killing pending DL TBF" and others. I am wondering why: * there is no indication to the SGSN for dropped frames/octets? * can't the DL-TBF be re-associated/updated after the assignment is done again? holger -- - Holger Freyther <hfreyther(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Schivelbeiner Str. 5 * 10439 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte

3 6

Losing ACKs due TLLI changes?
by Holger Hans Peter Freyther 05 Nov '13

05 Nov '13

Hi, I got this log from the pcu while using my E71 (the only sub in this network). <0007> gprs_rlcmac_meas.cpp:103 UL RSSI of TLLI=0x88661bc6: -67 dBm <0002> bts.cpp:945 Got ACK, but UL TBF is gone TLLI=0xe512eba3 <0007> gprs_rlcmac_meas.cpp:158 DL packet loss of IMSI=274080000004765 / TLLI=0xe512eba3: 0% <0002> tbf.cpp:668 TBF TFI=0 TLLI=0x88661bc6 T3169 timeout during transsmission <0002> tbf.cpp:690 - Assignment was on PACCH <0002> tbf.cpp:694 - No uplink data received yet So there is an ACK for TLLI=0xe512eba3 but at the same time the tlli 0x88661bc6 is timing out. PCU->SGSN TLLI=0x88661bc6 Attach Request SGSN->PCU TLLI=0x88661bc6 Attach Accept (new P-TMSI) PCU->SGSN TLLI=0xe512eba3 Attach Complete (new TLLI) (6s later) Now the question is how the PCU should behave. I think the MS is allowed to change the TLLI (after a P-TMSI assignment) after the contention resolution is completed. From my reading there is no content resolution on the UL. My E71 appears to run into a timeout and then issue a RACH request to send the Attach Complete. I think I have seen other equipment failing to transmit the Attach Complete at all. I think for the SGSN -> PCU side we should generally look things up by IMSI (there is already a warning in the code), for the MS->PCU side. I think we should store the old and new TLLI (and then put new_tlli into tlli once the new one is being used). comments? holger -- - Holger Freyther <hfreyther(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Schivelbeiner Str. 5 * 10439 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte

4 9

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

osmocom-net-gprs November 2013