Project

General

Profile

Actions

Bug #1768

open

VTY show llc displays State TLLI Unassigned permanently

Added by dexter over 7 years ago. Updated about 4 years ago.

Status:
Stalled
Priority:
Low
Assignee:
-
Category:
-
Target version:
-
Start date:
07/07/2016
Due date:
% Done:

0%

Spec Reference:

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.

Actions #1

Updated by laforge over 7 years ago

  • Assignee set to dexter
Actions #2

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.

Actions #3

Updated by dexter over 7 years ago

  • Status changed from New to Stalled
Actions #4

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 <> http://laforge.gnumonks.org/ ============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)

Actions #5

Updated by laforge almost 5 years ago

  • Assignee changed from dexter to lynxis
Actions #6

Updated by laforge about 4 years ago

  • Assignee deleted (lynxis)
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)