Bug #6318
openShow lchan shows wrong number of channels for TCH
Added by matanp 5 months ago. Updated 5 months ago.
0%
Description
When configuring a channel is configured as TCH, `show lchan` show 3 lchans for that channel.
tested on commit 9baa065c8da5ecd96e9a2f2c6d5d1c57ece754b2, I will test it on the master soon
Updated by laforge 5 months ago
you forgot to add the information from your pastebin on IRC:
OsmoBSC# show lchan 0 0 1
BTS 0, TRX 0, Timeslot 1, Lchan 0: Type TCH_F
Active for: 299.585 seconds
Connection: 1, State: ESTABLISHED
BS Power: 0 dBm, MS Power: 39 dBm
Interference Level: unknown
Channel Mode / Codec: SIGNALLING
Training Sequence: Set 1 Code 1
Subscriber:
IMSI: 001010123456789
Use count: 1 (conn)
Measurement Report:
Flags:
MS Timing Offset: 0
L1 MS Power: 39 dBm, Timing Advance: 0
RXL-FULL-dl: -47 dBm, RXL-SUB-dl: -47 dBm RXQ-FULL-dl: 0, RXQ-SUB-dl: 0
RXL-FULL-ul: -47 dBm, RXL-SUB-ul: -47 dBm RXQ-FULL-ul: 0, RXQ-SUB-ul: 0
BTS 0, TRX 0, Timeslot 1, Lchan 1: Type NONE
Connection: 0, State: UNUSED
BS Power: 0 dBm, MS Power: 39 dBm
Interference Level: unknown
Channel Mode / Codec: SIGNALLING
No Subscriber
Measurement Report:
Flags: DLinval
RXL-FULL-ul: -110 dBm, RXL-SUB-ul: -110 dBm RXQ-FULL-ul: 0, RXQ-SUB-ul: 0
BTS 0, TRX 0, Timeslot 1, Lchan 2: Type NONE
Connection: 0, State: UNUSED
BS Power: 0 dBm, MS Power: 39 dBm
Interference Level: unknown
Channel Mode / Codec: SIGNALLING
No Subscriber
Measurement Report:
Flags: DLinval
RXL-FULL-ul: -110 dBm, RXL-SUB-ul: -110 dBm RXQ-FULL-ul: 0, RXQ-SUB-ul: 0
Updated by laforge 5 months ago
- Status changed from New to Feedback
- Assignee set to fixeria
this appears to be an artefact of when we introduced VAMOS support. At that point, the number of lchan on a TCH/F increased from one to three.
I think it's useless to print those extra lchan if the BTS doesn't even support VAMOS.
Maybe we should simply skip all lchan that are of type NONE? In the end, there's no point in printing anything about them, right?
Updated by fixeria 5 months ago
- Assignee changed from fixeria to neels
laforge wrote in #note-2:
this appears to be an artefact of when we introduced VAMOS support. At that point, the number of lchan on a TCH/F increased from one to three.
neels was the one working on adding VAMOS support to osmo-bsc, and his approach is significantly different from what I implemented for osmo-bts.
I can work on fixing this, but I believe it's better if the author of the related code could take a look.
Updated by neels 5 months ago
This happens because of dump_lchan_trx_ts():
ts_for_n_lchans(lchan, ts, ts->max_lchans_possible) {
if (lchan_state_is(lchan, LCHAN_ST_UNUSED) && all == false)
continue;
dump_cb(vty, lchan);
}And yes, max_lchans_possible for one TCH/F in use is 3 because of VAMOS.
There already is a condition for skipping unused ones via the 'all' parameter,
and 'all' is passed in as true, to explicitly include unused lchans.
This comes in at
DEFUN(show_lchan,
show_lchan_cmd,
"show lchan [<0-255>] [<0-255>] [<0-7>] [<0-7>]",
SHOW_STR "Display information about a logical channel\n"
BTS_TRX_TS_LCHAN_STR)
{
return lchan_summary(vty, argc, argv, lchan_dump_full_vty, [all=]true);
}
Compare the 'summary' commands: for 'show lchan summary', we have both variants:
- If you call 'show lchan summary 0 0 1' it skips unused lchans;
- if you call 'show lchan summary-all 0 0 1' it shows unused lchans.
DEFUN(show_lchan_summary,
show_lchan_summary_cmd,
"show lchan summary [<0-255>] [<0-255>] [<0-7>] [<0-7>]",
SHOW_STR "Display information about a logical channel\n"
"Short summary (used lchans)\n"
BTS_TRX_TS_LCHAN_STR)
{
return lchan_summary(vty, argc, argv, lchan_dump_short_vty, false);
}
DEFUN(show_lchan_summary_all,
show_lchan_summary_all_cmd,
"show lchan summary-all [<0-255>] [<0-255>] [<0-7>] [<0-7>]",
SHOW_STR "Display information about a logical channel\n"
"Short summary (all lchans)\n"
BTS_TRX_TS_LCHAN_STR)
{
return lchan_summary(vty, argc, argv, lchan_dump_short_vty, true);
}
Maybe we can have the same for 'show lchan': 'show lchan all' passes all=true and 'show lchan' passes all=false?
Anyhow, it's not a bug, it's a feature...
