Cellular Network Infrastructure » Radio Access Network » OsmoBSC

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

• 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.

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.

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

• change rsl e1 tei 0 to rsl e1 tei 10, and
• likewise 1->11, 2->12, 3->13

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" ....

https://gitlab.com/wireshark/wireshark/-/merge_requests/1089

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.

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.

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?

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.

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?