Project

General

Profile

Bug #2714

OsmoBSC doesn't refuse/close RSL connections from unknown Unit ID

Added by laforge 8 months ago. Updated 5 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
A-bis RSL
Target version:
-
Start date:
12/06/2017
Due date:
% Done:

0%

Estimated time:
Spec Reference:

Description

When establishing a RSL connection to OsmoBSC and sending an unknown UnitID, OsmoBSC doesn't seem to close the TCP coection and/or otherwise reject this connection

History

#1 Updated by laforge 7 months ago

  • Project changed from OpenBSC to OsmoBSC

#2 Updated by laforge 7 months ago

  • Category set to A-bis RSL

#3 Updated by laforge 6 months ago

  • Assignee set to stsp

#4 Updated by stsp 5 months ago

  • Status changed from New to In Progress

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?

#5 Updated by laforge 5 months ago

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.

#6 Updated by stsp 5 months ago

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 

#7 Updated by laforge 5 months ago

On Tue, Feb 13, 2018 at 11:38:52AM +0000, stsp [REDMINE] wrote:

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

yes.

In the wireshark trace, I see only one TCP exchange between BTS and BSC (port 10000 is the BTS, port 3003 is the BSC).

3003 is RSL, 3002 is OML.

#8 Updated by stsp 5 months ago

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

#9 Updated by stsp 5 months ago

  • Status changed from In Progress to Resolved

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.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)