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
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
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
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
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
