Cellular Network Infrastructure » Radio Access Network » OsmoBSC

Starting to work on this. So far I could not reproduce the issue with osmo-bts-virtual configured to use an unknown unit ID. The TCP connection is closed properly. Perhaps there are other configurations where this problem happens?

The OML connection is closed by the BSC, if an unknown unit_id is presented, after which a well-behaving BTS closes the RSL connection. However, the BSC itself never closes the RSL connection (which is the bug here).

The IPA_Emulation in TTCN-3 or the ipa client C code in libosmo-netif can be used to reproduce this.

I have now written a ttcn3 test case (thanks again for providing help with this!).

If I understand correctly, we are expecting 2 TCP connections between BTS and BSC (one for OML, one for RSL)?

In the wireshark trace, I see only one TCP exchange between BTS and BSC (port 10000 is the BTS, port 3003 is the BSC).
I am not sure which one of the two expected TCP connections this corresponds to:

154    3.771484422    172.18.0.20    172.18.0.20    TCP    74    10000 → 3003 [SYN] Seq=0 Win=43690 Len=0 MSS=65495 SACK_PERM=1 TSval=1865236606 TSecr=0 WS=128
155    3.771495121    172.18.0.20    172.18.0.20    TCP    74    3003 → 10000 [SYN, ACK] Seq=0 Ack=1 Win=43690 Len=0 MSS=65495 SACK_PERM=1 TSval=1865236606 TSecr=1865236606 WS=128
156    3.771504061    172.18.0.20    172.18.0.20    TCP    66    10000 → 3003 [ACK] Seq=1 Ack=1 Win=43776 Len=0 TSval=1865236606 TSecr=1865236606
157    3.771589984    172.18.0.20    172.18.0.20    IPA    86    IPA IDENTITY REQUEST 
158    3.771597216    172.18.0.20    172.18.0.20    TCP    66    10000 → 3003 [ACK] Seq=1 Ack=21 Win=43776 Len=0 TSval=1865236606 TSecr=1865236606
159    3.773375902    172.18.0.20    172.18.0.20    IPA    127    IPA IDENTITY RESPONSE 
160    3.773386143    172.18.0.20    172.18.0.20    TCP    66    3003 → 10000 [ACK] Seq=21 Ack=62 Win=43776 Len=0 TSval=1865236608 TSecr=1865236608
161    3.773477480    172.18.0.20    172.18.0.20    TCP    66    3003 → 10000 [FIN, ACK] Seq=21 Ack=62 Win=43776 Len=0 TSval=1865236608 TSecr=1865236608
162    3.773550988    172.18.0.20    172.18.0.20    IPA    70    IPA IDENTITY ACK 
163    3.773565121    172.18.0.20    172.18.0.20    TCP    54    3003 → 10000 [RST] Seq=22 Win=0 Len=0

Details of the IPA messages are:

Frame 157: 86 bytes on wire (688 bits), 86 bytes captured (688 bits) on interface 0
Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00)
Internet Protocol Version 4, Src: 172.18.0.20, Dst: 172.18.0.20
Transmission Control Protocol, Src Port: 3003, Dst Port: 10000, Seq: 1, Ack: 1, Len: 20
IPA protocol ip.access, type: IPA
    DataLen: 17
    Protocol: IPA (0xfe)
GSM over IP ip.access CCM sub-protocol
    MessageType: IDENTITY REQUEST (0x04)
    Tag: Unit ID (0x08)
    Tag: MAC Address (0x07)
    Tag: Location (0x02)
    Tag: Unit Type (0x03)
    Tag: Equipment Version (0x04)
    Tag: Software Version (0x05)
    Tag: Unit Name (0x01)
    Tag: Serial Number (0x00)

Frame 159: 127 bytes on wire (1016 bits), 127 bytes captured (1016 bits) on interface 0
Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00)
Internet Protocol Version 4, Src: 172.18.0.20, Dst: 172.18.0.20
Transmission Control Protocol, Src Port: 10000, Dst Port: 3003, Seq: 1, Ack: 21, Len: 61
IPA protocol ip.access, type: IPA
    DataLen: 58
    Protocol: IPA (0xfe)
GSM over IP ip.access CCM sub-protocol
    MessageType: IDENTITY RESPONSE (0x05)
    Tag: Unit ID (0x08)
    String: 0/0/0
    Tag: MAC Address (0x07)
    String: 
    Tag: Location (0x02)
    String: 
    Tag: Unit Type (0x03)
    String: 
    Tag: Equipment Version (0x04)
    String: 
    Tag: Software Version (0x05)
    String: 
    Tag: Unit Name (0x01)
    String: Osmocom TTCN-3 BTS Simulator
    Tag: Serial Number (0x00)
    String: 

Frame 162: 70 bytes on wire (560 bits), 70 bytes captured (560 bits) on interface 0
Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00)
Internet Protocol Version 4, Src: 172.18.0.20, Dst: 172.18.0.20
Transmission Control Protocol, Src Port: 10000, Dst Port: 3003, Seq: 62, Ack: 22, Len: 4
IPA protocol ip.access, type: IPA
    DataLen: 1
    Protocol: IPA (0xfe)
GSM over IP ip.access CCM sub-protocol
    MessageType: IDENTITY ACK (0x06)

The decision to close the link is made in libbsc/ipaccess_sign_link_up():

<0024> input/ipa.c:263 accept()ed new link from 172.18.0.20 to port 3003                                  
<0026> input/ipaccess.c:246 RX 2: 05 00 06 08 30 2f 30 2f 30 00 01 07 00 01 02 00 01 03 00 01 04 00 01 05 00 1d 01 4f 73 6d 6f 63 6f 6d 20 54 54 43 4e 2d 33 20 42 54 53 20 53 69 6d 75 6c 61 74 6f 72 00 01 00      
<0026> input/ipaccess.c:118 ID_RESP                  
Unit_ID='0/0/0' MAC_Address='' Location_1='' Location_2='' Equipment_Version='' Software_Version='' Unit_Name='Osmocom TTCN-3 BTS Simulator' Serial_Number='' <0026> input/ipaccess.c:122                            
<0024> bts_ipaccess_nanobts.c:416 Unable to find BTS configuration for  0/0/0, disconnecting              
<0024> input/ipaccess.c:176 Unable to set signal link, closing socket.

By extending debug output I could determine that the connection which cannot be established is type 2 (i.e. E1INP_SIGN_RSL):

<0024> bts_ipaccess_nanobts.c:416 Unable to find BTS configuration for  0/0/0 for connection type 2 

Proposed a ttcn3 test case in https://gerrit.osmocom.org/#/c/6406/

The above ttcn3 test has been merged.

Since the test ensures that this problem doesn't occur now and won't re-occur unnoticed in the future, I am closing the issue.