Bug #1768
openVTY show llc displays State TLLI Unassigned permanently
0%
Description
Expecting at least some assigned TLLI states in in SAPI list on globally Assigned TLLI state.
TLLI e625e4fb (Old TLLI ffffffff) BVCI=2 NSEI=101 Age=0: State TLLI Assigned SAPI 1 State TLLI Unassigned (1) VUsend=4, VUrecv=5 Vsent=0 Vack=0 Vrecv=0, RetransCtr=0 T200=5, N200=3, N201-U=400, N201-I=0, mD=0, mU=0, kD=0, kU=0 SAPI 2 State TLLI Unassigned (1) VUsend=0, VUrecv=0 Vsent=0 Vack=0 Vrecv=0, RetransCtr=0 T200=5, N200=3, N201-U=270, N201-I=0, mD=0, mU=0, kD=0, kU=0 SAPI 3 State TLLI Unassigned (1) VUsend=91, VUrecv=64 Vsent=0 Vack=0 Vrecv=0, RetransCtr=0 T200=5, N200=3, N201-U=500, N201-I=1503, mD=1520, mU=1520, kD=16, kU=16 SAPI 5 State TLLI Unassigned (1) VUsend=0, VUrecv=0 Vsent=0 Vack=0 Vrecv=0, RetransCtr=0 T200=10, N200=3, N201-U=500, N201-I=1503, mD=760, mU=760, kD=8, kU=8 SAPI 7 State TLLI Unassigned (1) VUsend=0, VUrecv=0 Vsent=0 Vack=0 Vrecv=0, RetransCtr=0 T200=20, N200=3, N201-U=270, N201-I=0, mD=0, mU=0, kD=0, kU=0 SAPI 8 State TLLI Unassigned (1) VUsend=0, VUrecv=0 Vsent=0 Vack=0 Vrecv=0, RetransCtr=0 T200=20, N200=3, N201-U=270, N201-I=0, mD=0, mU=0, kD=0, kU=0 SAPI 9 State TLLI Unassigned (1) VUsend=0, VUrecv=0 Vsent=0 Vack=0 Vrecv=0, RetransCtr=0 T200=20, N200=3, N201-U=500, N201-I=1503, mD=380, mU=380, kD=4, kU=4 SAPI 11 State TLLI Unassigned (1) VUsend=0, VUrecv=0 Vsent=0 Vack=0 Vrecv=0, RetransCtr=0 T200=40, N200=3, N201-U=500, N201-I=1503, mD=190, mU=190, kD=2, kU=2
Already checked if the get_value_string(gprs_llc_state_strs, lle->state) returns the right string. Seems to work, numerical state is always 1 as well.
Updated by dexter over 7 years ago
Investigated a little bit further on this. By our implementation, lle->state in fact never changes.
gprs_llc_hdr_rx() in gprs_llc.c is responsible to handle the state changes. However, all cases where lle->state seem to occur never. Holger told me that in case GPRS_LLC_UI lle->state should be changed but we omit that. This is a bit of spec violation but according to Holger not really a problem.
Updated by laforge over 7 years ago
On Fri, Oct 07, 2016 at 09:39:19AM +0000, dexter [REDMINE] wrote:
Investigated a little bit further on this. By our implementation, lle->state in fact never changes.
gprs_llc_hdr_rx() in gprs_llc.c is responsible to handle the state
changes. However, all cases where lle->state seem to occur never.
Holger told me that in case GPRS_LLC_UI lle->state should be changed
but we omit that. This is a bit of spec violation but according to
Holger not really a problem.
Still, it seems to be confusing to print a state that is not correct.
So if you already analyzed the problem and the code to this point, how
much time would you think is required to fix it?
--
- Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)