Project

General

Profile

Actions

Bug #4881

open

osmo-bsc with unixsocket to osmo-el2tpd fails to bring up rbs6k (dug20+rrus12)

Added by firs over 3 years ago. Updated about 3 years ago.

Status:
Feedback
Priority:
Normal
Assignee:
Category:
Ericsson BTS
Target version:
-
Start date:
11/30/2020
Due date:
% Done:

0%

Spec Reference:

Description

We have a working RBS 6k with a DUG 20, using a RRUS12 radio. With a DAHDI card and nightly build, the RBS comes up with osmo-bsc without issue. We obtained a TCU 02, configured it, and connected to osmo-el2tpd. The IDB of the DUG was changed to include the SIU in the transmission config. When running osmo-bsc, the BTS partially initializes, then errors come up like:

<0016> lapd_core.c:2227 ((0:1-T0-S62)) Message 1/0 unhandled at this state LAPD_STATE_SABM_SENT
<0017> input/unixsocket.c:156 E1TS no message available (line=0x55f005f3d7f0)

I have attached configuration files, pcap from both osmo-bsc and the ethernet interface that connects to the TCU. There are also log files from osmo-bsc and osmo-el2tpd.

The IP Configuration is:
TCU: 10.245.67.10/24
BSC: 10.245.70.15/24

There is a router between the two subnets.

Code is the latest from git as of 11/29/2020 2300 GMT.


Files

osmo-bsc.log osmo-bsc.log 70.1 KB osmo-bsc log firs, 11/30/2020 05:44 PM
osmo-bsc.tcu.dug20.4trx.cfg osmo-bsc.tcu.dug20.4trx.cfg 5.02 KB osmo-bsc config firs, 11/30/2020 05:44 PM
ens224-ethernet-tcu02.pcap ens224-ethernet-tcu02.pcap 184 KB ethernet interface pcap firs, 11/30/2020 05:44 PM
osmo-el2tpd.log osmo-el2tpd.log 28.9 KB osmo-el2tpd log firs, 11/30/2020 05:44 PM
rbs6k-dug20-tcu02.pcap rbs6k-dug20-tcu02.pcap 93.1 KB osmo-bsc pcap firs, 11/30/2020 05:44 PM
Actions #1

Updated by laforge over 3 years ago

stupid question: Did you patch the hard-coded IP addresses in the osmo-el2tpd code?

Actions #2

Updated by laforge over 3 years ago

  • Status changed from New to Feedback
  • Assignee set to firs
looking at the EHDLC pcap file in wirehark (mainline wirshark has all required decoders), we can see that the OM2000 initialization actually starts up quite well:
  • IS CONNECT CMD
  • IS CONNECT CMPL
  • IS RESET CMD
  • IS RESET CMPL
  • IS START REQ
  • IS START REQ ACK
  • IS START RES
  • IS START RES OK
  • IS CONF REQ
  • IS CONF REQ ACK
  • IS CONF RES
  • IS CONF RES ACK
  • ENABLE REQ
  • ENABLE REQ ACK

at that point then, the BTS and the RBS6k switch into Superchannnel (also known as "Packet Abis over TDM") mode (ALTC command)

Finally, half as second later there's the IS ENABLE RESULT + ACK and some IS Operational Information.

I think the problem is that the IS may not be configured correctly for operation via the Superchannel. Or maybe it's required to use the CON (concentrator) in this situation.

In any case, from that pcap it looks like a configuration problem to me, not [yet] a bug in the actual osmo-el2tpd.

Actions #3

Updated by laforge over 3 years ago

actually, I thought the many SABME are related to the voice (TFP) and GPRS (P-GSL) only. I was wrong.

We actually see SABME for TEI 10,11,12,13 (4 TRX?) and each for SAPI 0 (RSL) and SAPI 62 (OML)

So I guess the problem is that somehow those are not answered.

Actions #4

Updated by laforge over 3 years ago

the EHDLC trace shows TEI 10,11,12,13 but the BSC is configured to use TEI 0,1,2,3

So keep the oml e1 tei 62 but
  • change rsl e1 tei 0 to rsl e1 tei 10, and
  • likewise 1->11, 2->12, 3->13
Actions #5

Updated by laforge over 3 years ago

false alarm. The wireshark COL_INFO contains a typo regarding TEIs:

commit d7bab0b46e72eb30e50ad1b6a0b56275394406b4
Author: Anders Broman <anders.broman@ericsson.com>
Date:   Wed Nov 29 09:14:32 2017 +0100

    [packer-ehdlc.c] Mark some fields as generated, enhance info col.

    Change-Id: I10241389dbd3c463b36c5dfcd7a4fa929a1bbf6a
    Reviewed-on: https://code.wireshark.org/review/24644
    Petri-Dish: Anders Broman <a.broman58@gmail.com>
    Tested-by: Petri Dish Buildbot
    Reviewed-by: Anders Broman <a.broman58@gmail.com>

diff --git a/epan/dissectors/packet-ehdlc.c b/epan/dissectors/packet-ehdlc.c
index e166a8b1c3..5e7ef084d3 100644
--- a/epan/dissectors/packet-ehdlc.c
+++ b/epan/dissectors/packet-ehdlc.c
@@ -231,6 +231,10 @@ dissect_ehdlc(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree, void* data _U
                ctei = (hdr2 >> 9) & 0xF;
                tei = tei_from_ctei(ctei);

+               /* Add TEI to INFO column */
+               col_append_fstr(pinfo->cinfo, COL_INFO, " | TEI:1%u | ", tei);
+               col_set_fence(pinfo->cinfo, COL_INFO);

note the "TEI:1%u" ....

Actions #7

Updated by laforge over 3 years ago

I cannot really debug this any further right now, but it looks to me like those incoming SABM are either not passed by el2tpd to osmo-bsc, or they are somehow lost inside osmo-bsc. In any case those SABM messages should trigger LAPDM DL establishment for those further per-TRX OM2000 and RSL links. Once those are up, OM2000 initialization of each TRX should continue.

Actions #8

Updated by firs over 3 years ago

laforge wrote:

stupid question: Did you patch the hard-coded IP addresses in the osmo-el2tpd code?

Yes, I patched the code for my IP range.

Actions #9

Updated by firs over 3 years ago

laforge wrote:

I cannot really debug this any further right now, but it looks to me like those incoming SABM are either not passed by el2tpd to osmo-bsc, or they are somehow lost inside osmo-bsc. In any case those SABM messages should trigger LAPDM DL establishment for those further per-TRX OM2000 and RSL links. Once those are up, OM2000 initialization of each TRX should continue.

If I look at the pcap for osmo-bsc, that should show if the incoming SABM messages are making it to osmo-bsc, correct?

Actions #10

Updated by laforge over 3 years ago

firs wrote:

If I look at the pcap for osmo-bsc, that should show if the incoming SABM messages are making it to osmo-bsc, correct?

In theory, yes. I don't think anyone has ever used the osmo-bsc internal pcap generation with the unixdomain / el2tp based input. It was added/used/tested for real E1 interfaces.

Actions #11

Updated by firs over 3 years ago

laforge wrote:

firs wrote:

If I look at the pcap for osmo-bsc, that should show if the incoming SABM messages are making it to osmo-bsc, correct?

In theory, yes. I don't think anyone has ever used the osmo-bsc internal pcap generation with the unixdomain / el2tp based input. It was added/used/tested for real E1 interfaces.

Good Morning,

I did confirm that the DUG 20 Transmission is set to use the SIU. The TCU was configured the same as the Wiki: https://osmocom.org/projects/ericsson-rbs-6xxx/wiki/TCU_02

I took a closer look at both the ethernet, and E1 pcap taken by osmo-bsc. All initialization traffic between the BSC and BTS matches up, through "ENABLE REQ ACK". After that, the BSC tries to initialize the TRXC, on line 589 of osmo-bsc.log:

<0004> abis_om2000.c:1115 Tx MO=TRXC/00/ff/00 Reset Command
<0016> lapd_core.c:2227 ((0:1-T0-S62)) Message 1/0 unhandled at this state LAPD_STATE_SABM_SENT
<0017> input/unixsocket.c:156 E1TS no message available (line=0x55f005f3d7f0)
<0016> lapd_core.c:426 ((0:7-T2-S0)) sending MDL-ERROR-IND cause 1 from state LAPD_STATE_IDLE

I do not see the TRXC reset message from the BSC appear in either pcap. At that point, both pcap's show a flood of SABM's from the BSC to the BTS.

Is the BTS expecting the TRXC reset command, which never comes?

Actions #12

Updated by laforge about 3 years ago

Hi,

On Sat, Dec 26, 2020 at 07:25:42PM +0000, firs [REDMINE] wrote:

I took a closer look at both the ethernet, and E1 pcap taken by osmo-bsc. All initialization traffic between the BSC and BTS matches up, through "ENABLE REQ ACK".

side note: Always mention the MO, ther are dozzns of MOs, each with their own ENABLE + ENABLE-ACK
cycle.

After that, the BSC tries to initialize the TRXC, on line 589 of osmo-bsc.log:

<0004> abis_om2000.c:1115 Tx MO=TRXC/00/ff/00 Reset Command
<0016> lapd_core.c:2227 ((0:1-T0-S62)) Message 1/0 unhandled at this state LAPD_STATE_SABM_SENT
<0017> input/unixsocket.c:156 E1TS no message available (line=0x55f005f3d7f0)
<0016> lapd_core.c:426 ((0:7-T2-S0)) sending MDL-ERROR-IND cause 1 from state LAPD_STATE_IDLE

Just looking at those four log lines it seems that the BSC is trying to send something via the
LAPD datalink for the TRXC-OML (TEI0/SAPI62) before that data link is setablished.

I do not see the TRXC reset message from the BSC appear in either pcap. At that point, both pcap's show a flood of SABM's from the BSC to the BTS.

The expectation (on normal E1 at least) is that the TRXC in the BTS will respond to that SABM
(with a UA) and thereby confirm establishment of the LAPD datalink.

The "flood" is intentional as at least some RBS are using auto-detection of the signaling timeslot
based on those SABM appearing at a certain rate.

Is the BTS expecting the TRXC reset command, which never comes?

Slightly lower: The communication between TRXC and BSC only works once a related LAPDm data link
is established. And since that data link is not established, no OM2000 signalling can happen
to the TRXC.

To be honest, I don't remember how all of this was supposed to work in the presence of a SIU/TCU.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)