This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/osmocom-net-gprs@lists.osmocom.org/.
Andreas Eversberg andreas at eversberg.eu> > * 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!). > dear holger, is it already fixed? how can i test it? running "make check" does not cause any failure. (i use zecke/features/clean-up branch) > 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) > this means that our receive array contains blocks from 55 to 59... > <0005> tbf.cpp:1624 - BSN 60 storing in window (55..118) > <0005> rlc.cpp:173 - Raising V(R) to 61 > as we received block 60, our receive array contains blocks from 55 to 60 now. in your code i can see that "gprs_rlc_ul_window::raise_v_q(gprs_rlc_v_n *v_n)" is called. since there is no debugging that shows something like "- Taking block 55 out, raising V(Q) to 56", i assume that the if-condition "if (!v_n->is_received(v_q()))" is positive. this means that v_n.state(55) is not 'R'... > <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 > so i would expect that there is no 'R' at position last but 5 in this debug string, but there is one. is there a way to reproduce this? you said "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.". does this mean that it can be reproduced by dropping one frame on the uplink? (e.g. dropping frame with BSN 55 once.) best regards, andreas