Bug #5131
closedCall setup failing on 3rd SETUP
0%
Description
Attempting to establish a 3rd simultaneous call causes all calls to drop no further calls can be established until the MGW is restarted.
100% reproducible.
This is the oddity in the osmo-mgw logs
Apr 26 00:34:50 test2-bsc osmo-mgw[2313]: DLMGCP mgcp_protocol.c:751 endpoint:ds/e1-0/s-2/su16-6@mgw CRCX: creating new connection ... Apr 26 00:34:50 test2-bsc osmo-mgw[2313]: DLINP input/e1d.c:350 E1L(0) Line update 0 0=E1D(0:0) 32 Apr 26 00:34:50 test2-bsc osmo-mgw[2313]: DLINP input/e1d.c:450 E1TS(0:3) Could not open timeslot 3 Apr 26 00:34:50 test2-bsc osmo-mgw[2313]: DE1 mgcp_e1.c:400 trunk:0 failed to update E1 timeslot 2.
After this, restart is required.
At the same time. osmo-e1d logs:
20210426003450977 DE1D ERROR (I0:L0:T3) Timeslot already open, rejecting re-open without F_FORCE (ctl.c:380) 20210426003450979 DE1D ERROR (I0:L0:T3) dead socket during write: Broken pipe (mux_demux.c:298)
Attached logs and pcaps did not necessarily start and end at the same time, but all timestamps should match.
Files
Updated by keith over 2 years ago
Apologies for large-ish pcap there, I guess I could have taken out the RTP.
Anyway, looking at the config while making this ticket, it become obvious that the 3rd call, (5th leg) is using a new E1 timeslot.
Changing osmo-bsc config so:
timeslot 3
phys_chan_config TCH/F
hopping enabled 0
e1 line 0 timeslot 6 sub-slot 1
(just choosing 6 at random)
results in:
Apr 26 00:44:33 test2-bsc osmo-mgw[2594]: DLMGCP mgcp_protocol.c:751 endpoint:ds/e1-0/s-6/su16-2@mgw CRCX: creating new connection ... Apr 26 00:44:33 test2-bsc osmo-mgw[2594]: DLINP input/e1d.c:350 E1L(0) Line update 0 0=E1D(0:0) 32 Apr 26 00:44:33 test2-bsc osmo-mgw[2594]: DLINP input/e1d.c:450 E1TS(0:3) Could not open timeslot 3 Apr 26 00:44:33 test2-bsc osmo-mgw[2594]: DE1 mgcp_e1.c:400 trunk:0 failed to update E1 timeslot 6.
And same message from the e1d:
20210426004433802 DE1D ERROR (I0:L0:T3) Timeslot already open, rejecting re-open without F_FORCE (ctl.c:380)
Changing osmo-bsc channel allocator to ascending causes the same error on the 2nd call, (3rd leg) as we only have two TS before moving E1 TS
It might be nice if somebody else would see if they can reproduce it?
Updated by laforge over 2 years ago
On Mon, Apr 26, 2021 at 05:38:07AM +0000, keith [REDMINE] wrote:
Attempting to establish a 3rd simultaneous call causes all calls to drop no further calls can be established until the MGW is restarted.
100% reproducible.
Thanks for this very clear report.
But... looking at your configuration file, it somehow seems to lack any e1 timeslot/sub-slot
assignments at all ?!?
Your config:
trx 0 rf_locked 0 arfcn 883 nominal power 23 max_power_red 20 rsl e1 tei 0 timeslot 0 phys_chan_config CCCH+SDCCH4 hopping enabled 0 timeslot 1 phys_chan_config TCH/F hopping enabled 0 timeslot 2 phys_chan_config TCH/F hopping enabled 0 timeslot 3 phys_chan_config TCH/F hopping enabled 0 timeslot 4 phys_chan_config TCH/F hopping enabled 0 timeslot 5 phys_chan_config TCH/F hopping enabled 0 timeslot 6 phys_chan_config TCH/F hopping enabled 0 timeslot 7 phys_chan_config TCH/F hopping enabled 0
example config:
trx 0 rf_locked 0 arfcn 123 nominal power 42 max_power_red 12 rsl e1 line 0 timeslot 1 sub-slot full rsl e1 tei 0 timeslot 0 phys_chan_config CCCH+SDCCH4 hopping enabled 0 e1 line 0 timeslot 1 sub-slot full timeslot 1 phys_chan_config TCH/F hopping enabled 0 e1 line 0 timeslot 2 sub-slot 1 timeslot 2 phys_chan_config TCH/F hopping enabled 0 e1 line 0 timeslot 2 sub-slot 2 timeslot 3 phys_chan_config TCH/F hopping enabled 0 e1 line 0 timeslot 2 sub-slot 3 timeslot 4 phys_chan_config TCH/F hopping enabled 0 e1 line 0 timeslot 3 sub-slot 0 timeslot 5 phys_chan_config TCH/F hopping enabled 0 e1 line 0 timeslot 3 sub-slot 1 timeslot 6 phys_chan_config TCH/F hopping enabled 0 e1 line 0 timeslot 3 sub-slot 2 timeslot 7 phys_chan_config TCH/F hopping enabled 0 e1 line 0 timeslot 3 sub-slot 3
For a E1 BTS, you need to configure which E1 timeslot and sub-slot is to be
used for which on-air timeslot. This has been the same since we first implemented
OpenBSC/bs11_hack in 2008. It is your responsibility to make sure every on-air-TS
has a dedicated, non-overlapping E1 sub-slot configured. You can use them as
you like, but the pattern from the example files is what we tend to test with.
Updated by keith over 2 years ago
Bizarre.. When I re-download and look at the osmo-bsc.cfg that I attached, I see the e1 timeslot assignments, plain and clear:
Also in the paste in your note, there is arfcn 883. So i think somehow what you are looking at is not my config.
Thanks!
trx 0
rf_locked 0
arfcn 250
nominal power 36
max_power_red 0
rsl e1 line 0 timeslot 1 sub-slot full
rsl e1 tei 0
timeslot 0
phys_chan_config CCCH+SDCCH4
hopping enabled 0
e1 line 0 timeslot 1 sub-slot full
timeslot 1
phys_chan_config TCH/F
hopping enabled 0
e1 line 0 timeslot 2 sub-slot 1
timeslot 2
phys_chan_config TCH/F
hopping enabled 0
e1 line 0 timeslot 2 sub-slot 2
timeslot 3
phys_chan_config TCH/F
hopping enabled 0
e1 line 0 timeslot 2 sub-slot 3
timeslot 4
phys_chan_config TCH/F
hopping enabled 0
e1 line 0 timeslot 3 sub-slot 0
timeslot 5
phys_chan_config TCH/F
hopping enabled 0
e1 line 0 timeslot 3 sub-slot 1
timeslot 6
phys_chan_config TCH/F
hopping enabled 0
e1 line 0 timeslot 3 sub-slot 2
timeslot 7
phys_chan_config TCH/F
hopping enabled 0
e1 line 0 timeslot 3 sub-slot 3
Updated by laforge over 2 years ago
keith wrote:
Also in the paste in your note, there is arfcn 883. So i think somehow what you are looking at is not my config.
sorry for that.
Updated by keith over 2 years ago
libosmo-abis: e1d.c:e1d_line_update()
iterates over all timeslots:
line 358:
for (ts=1; ts<line->num_ts; ts++)
...
osmo_e1dp_client_ts_open() seems to fail then on any TS already open?
Updated by keith over 2 years ago
Not yet sure if it's the complete solution, but this allows libosmo-abis to know the mode of the TS!
So now at least we don't close the fd in e1d_line_update()
Updated by keith about 2 years ago
- Status changed from New to Resolved
Closing as fixed by the above patch.
