osmocom-net-gprs

osmocom-net-gprs@lists.osmocom.org

482 discussions

by Holger Hans Peter Freyther

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

11 years, 6 months

[PATCH] alloc_algorithm_b: Remove obsolete 'i' incrementation from for-loop

by Andreas Eversberg

--- src/gprs_rlcmac_ts_alloc.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gprs_rlcmac_ts_alloc.cpp b/src/gprs_rlcmac_ts_alloc.cpp index 58dd2e9..366732c 100644 --- a/src/gprs_rlcmac_ts_alloc.cpp +++ b/src/gprs_rlcmac_ts_alloc.cpp @@ -459,7 +459,7 @@ inc_window: "1 slot assigned\n"); break; } - if (++i == ms_max_txslots) { + if (i+1 == ms_max_txslots) { LOGP(DRLCMAC, LOGL_DEBUG, "- Done, because " "slots / window reached maximum " "allowed Tx size\n"); -- 1.8.1.5 --------------010607040705070003040009--

11 years, 6 months

[RFC] [ADMIN] Making lists subscriber-only?

by Harald Welte

Dear all, so far the osmocom.org mailing lists have always been in a 'non-members are manually moderated' mode. This has created a lot of work for manual list moderation, where a lot of the messages caught are simply spam, and only the occasional valid message is being received. I'd like to thank the list moderators for taking care of this. However, in more recent discussions, we were considering to move the lists to a completely closed mode, i.e. postings would automatically be rejected from non-members. The automatic response would contain a description of how to subscribe in 'nomail' mode, i.e. to subscribe in a way to be able to post to the list, while still not receiving any incoming traffic. The latter should be fine for occasional posters who don't want the bulk e-mail that goes with a full/regular subscription. Please provide feedback in case you disagree with that change. Unless there is major opposition, we will likely transition to the 'closed' mode within one month. Thanks, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

11 years, 6 months

Status of sysmocom/master W50

by Holger Hans Peter Freyther

Good Afternoon, last week at the sysmocom office Daniel and me continued to work on the window handling. We have now a proper abstraction that allows us to unit test the DL and UL window handling. The encode/decode of the RBB is now compatible to itself. While doing our manual tests (sending a big enough ICMP echo request) we noticed that in the alloc algorithm b case the we get a lot of NACKs. In the same setup (only alloc algorithm is changed) the A algorithm has no NACKs. I am now going to re-write the allocation handling. In terms of operation on the first DL assignment (through the PCH) we can only use a singleslot but when re-using the TBF we might go for multislot. In case the of UL handling we could always try to use multislot assignments. Is this understanding correct? 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

11 years, 7 months

Current list of failures in the pcu

by Holger Hans Peter Freyther

Good Morning, we at sysmocom continued to add structure/architecture to the PCU code and started to systematically test the code (using something as simple as ICMP ping/reply) Observations: * "alloc algorithm b" has little (3kbit/s) more bandwidth than just using the single slot assignment with CS4. There are also some open coverity issues about this multi slot code. * Congestion is badly handled. When using a ping that creates IP fragments the LLC queue of the TBF gets so long that we expire half the IP fragments before sending them. This means the MS at the downlink never receives all the IP fragments of a PING. We played with the BSVC-FLOW-CONTROL parameters but they don't have any influence here. We have added counting of queue size and calculation of the average queue delay to the LLC class. One option is to drop packages based on the PDU lifetime and the current queue delay. $ sudo ping -s 1800 -i 0.1 10.23.42.6 (CS4, alloc-algorithm a) is enough to re-produce this issue. * RLC V(Q) V(R) handling. It appears that after and before the refactoring the Received Block Bitmap (RBB) is wrongly encoded. The encode and decode are not compatible to each other (thanks to the architecture sysmocom is adding to the code this can now be unit tested!). So as soon as we don't receive a frame from the UL. The send window at the phone and the PCU is going out of sync. After making changes to the window we have also witnesses that on a fully received window V(Q) and V(R) were WindowSize away from each other. <0005> tbf.cpp:1579 UL DATA TFI=0 received (V(Q)=55 .. V(R)=60) <0005> tbf.cpp:1624 - BSN 60 storing in window (55..118) <0005> rlc.cpp:173 - Raising V(R) to 61 <0005> tbf.cpp:1690 - Scheduling Ack/Nack, because 20 frames received. <0005> encoding.cpp:374 Encoding Ack/Nack for TBF(TFI=0 TLLI=0xfa45049d DIR=UL) (final=0) SSN=61 <0005> encoding.cpp:408 - V(N): "RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR" R=Received N=Not-Received This part might be something we broke but we will try to re-produce with a unit test. We will continue to work on unit-testing the RLC window handling if anyone outside sysmocom interested in getting a more stable PCU? 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

11 years, 7 months

Summary of osmo-pcu failures/defects

by Holger Hans Peter Freyther

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

11 years, 8 months

gprs_rlcmac_received_lost() in gprs_rlcmac_meas.cpp

by Daniel Willmann

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

11 years, 8 months

Dropping LLC frames due the TBF destruction

by Holger Hans Peter Freyther

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

11 years, 8 months

Losing ACKs due TLLI changes?

by Holger Hans Peter Freyther

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

11 years, 8 months

Fwd: Losing ACKs due TLLI changes?

by Vladimir Rolbin

Hi, I don't see any print connected to the Uplink TBF request for "Attach accept" (by MS). At this moment the TLLI has been already updated but UL TBF still does not exist (what bts->tbf_by_tlli(m_tlli, GPRS_RLCMAC_UL_TBF) returns?). Corresponding to TS 04.60, 11.2.29 Packet Uplink Assignment possibly may use DL TFI to address the MS in place of TLLI (we still don't know if it's accepted or not by MS). Also the uplink FN may be used to find corresponding UL TBF context (according to Packet Uplink Assignment RRBP field) for UL Packet Control Ack which contains relevant TLLI. So is it really necessary to link UL and DL TBFs in the case? ... Regards, Vladimir Rolbin On Wed, Oct 30, 2013 at 1:17 PM, Holger Hans Peter Freyther < hfreyther(a)sysmocom.de> wrote: > On Sun, Oct 27, 2013 at 01:33:13PM +0100, Holger Hans Peter Freyther wrote: > > Hi, > > > > <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 > > this is from a routing area update (with some printf debugging): > > > TBF(TFI=0 TLLI=0xb68154e6 DIR=DL) TLLLI changed...... > 0xb68154e6->0xc782d1de > <0002> tbf.cpp:1626 TBF(TFI=0 TLLI=0xb68154e6 DIR=DL) changing tlli to > TLLI=0xc782d1de > <0002> bts.cpp:941 Got ACK, but UL TBF is gone TLLI=0xc782d1de > <0007> gprs_rlcmac_meas.cpp:158 DL packet loss of IMSI=274080000004765 / > TLLI=0xc782d1de: 0% > <0002> tbf.cpp:664 TBF(TFI=0 TLLI=0xb68154e6 DIR=UL) T3169 timeout during > transsmission > <0002> tbf.cpp:686 - Assignment was on PACCH > <0002> tbf.cpp:690 - No uplink data received yet > > So the DL TLLI has been changed and then we get an ACK for a UL tbf > with the new TLLI and can't find it. And run into a timeout. > > > I have applied this change: > > diff --git a/src/tbf.cpp b/src/tbf.cpp > index fac5aaf..19bb83c 100644 > --- a/src/tbf.cpp > +++ b/src/tbf.cpp > @@ -1618,6 +1618,17 @@ void gprs_rlcmac_tbf::update_tlli(uint32_t tlli) > if (tlli == m_tlli) > return; > > + printf("%s TLLLI changed...... 0x%08x->0x%08x\n", > + tbf_name(this), m_tlli, tlli); > + > + if (direction == GPRS_RLCMAC_DL_TBF) { > + gprs_rlcmac_tbf *ul_tbf; > + ul_tbf = bts->tbf_by_tlli(m_tlli, GPRS_RLCMAC_UL_TBF); > + > + if (ul_tbf) > + ul_tbf->m_tlli = tlli; > + } > + > #warning "TODO.. find the DL/UL opposite and update the TLLI too" > LOGP(DRLCMAC, LOGL_NOTICE, "%s changing tlli to TLLI=0x%08x\n", > tbf_name(this), tlli); > > > and now the "Attach Complete" comes immediately after the Attach Accept. > I will push something like this but we really need a better way to link > the DL/UL TBFs together. > > > 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 > > >

11 years, 9 months

← Newer
1
...
40
41
42
43
44
45
46
...
49
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

osmocom-net-gprs