Bug #2714
closedOsmoBSC doesn't refuse/close RSL connections from unknown Unit ID
0%
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
Updated by stsp about 6 years 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?
Updated by laforge about 6 years 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.
Updated by stsp about 6 years 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
Updated by laforge about 6 years 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.
Updated by stsp about 6 years ago
Proposed a ttcn3 test case in https://gerrit.osmocom.org/#/c/6406/
Updated by stsp about 6 years 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.