sipp icon indicating copy to clipboard operation
sipp copied to clipboard

Published 20 hours ago • verified publisher icon SIPp

TCP: Source port is chosen randomly not from -p flag

Open kadabusha opened this issue 3 years ago • 2 comments

Possibly caused/related to #83

Short Description

When using "-t t1" and "-p my_port" the souce port used to send messages is not my_port but the random free one. Issue observed with SIPp v3.6.1-TLS-SCTP-PCAP-RTPSTREAM

Checked those versions as well - the same issue appears from time to time, on some test system it happens, on other - no. SIPp v3.7-dev-18-g9f62be0-TLS-SCTP-PCAP-RTPSTREAM-RTPCHECK SIPp v3.5.1-TLS-RTPSTREAM SIPp v3.3-TLS-PCAP

Steps to Reproduce

On the "server" side start netcat

sudo nc -v -l -n 192.168.1.100 5060

On the "client" side run built-in UAC scenario using -t t1 and -p my_port

sipp 192.168.1.100 -i 192.168.1.200 -d 2000 -m 1 -s 1234 -t t1 -max_socket 50 -sn uac -p 5060

On the "server" side you'll see something like this on the output on netcat

[1@1box ~]$ sudo nc -v -l -n 192.168.1.100 5060
Connection from 192.168.1.200 51912 received!
INVITE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/TCP 192.168.1.200:5060;branch=z9hG4bK-327-1-0
From: sipp <sip:[email protected]:5060>;tag=327SIPpTag001
To: 1234 <sip:[email protected]:5060>
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: sip:[email protected]:5060
Max-Forwards: 70
Subject: Performance Test
Content-Type: application/sdp
Content-Length:   137

v=0
o=user1 53655765 2353687637 IN IP4 192.168.1.200
s=-
c=IN IP4 192.168.1.200
t=0 0
m=audio 6000 RTP/AVP 0
a=rtpmap:0 PCMU/8000

Observed Result

If you look at the first line of the nc output it says the connection is from 51912 port instead of 5060 (the my_port provided with the -p flag).

If I use -t u1 flag and nc is run with -u flag, then the first line of output of nc is "Connection from 192.168.1.200 5060 received!".

[1@1box ~]$ sudo nc -v -l -n 192.168.1.100 5060 -u
Connection from 192.168.1.200 5060 received!
INVITE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.200:5060;branch=z9hG4bK-1189-1-0
From: sipp <sip:[email protected]:5060>;tag=1189SIPpTag001
To: 1234 <sip:[email protected]:5060>
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: sip:[email protected]:5060
Max-Forwards: 70
Subject: Performance Test
Content-Type: application/sdp
Content-Length:   137

v=0
o=user1 53655765 2353687637 IN IP4 192.168.1.200
s=-
c=IN IP4 192.168.1.200
t=0 0
m=audio 6000 RTP/AVP 0
a=rtpmap:0 PCMU/8000

tcpdump is attached below. tcp.zip

Expected Result

The my_port 5060 should be used as source one whether -t is t1 or u1 when making connections.

Client Environment

$ uname -r
11.3-RELEASE-p6
$ ifconfig
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
        ether 08:00:27:d7:ac:3b
        hwaddr 08:00:27:d7:ac:3b
        inet 192.168.0.200 netmask 0xffffff00 broadcast 192.168.0.255
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
em1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
        ether 08:00:27:8e:99:9a
        hwaddr 08:00:27:8e:99:9a
        inet 192.168.137.200 netmask 0xffffff00 broadcast 192.168.137.255
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
em2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
        ether 08:00:27:f3:b0:37
        hwaddr 08:00:27:f3:b0:37
        inet 192.168.1.200 netmask 0xffffff00 broadcast 192.168.1.255
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
        inet 127.0.0.1 netmask 0xff000000
        inet 10.100.0.1 netmask 0xffffffff
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        groups: lo

$ netstat -rn -4
Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
default            192.168.0.1        UGS         em0
10.100.0.1         link#4             UH          lo0
127.0.0.1          lo0                UHS         lo0
192.168.0.0/24     link#1             U           em0
192.168.0.200      link#1             UHS         lo0
192.168.1.0/24     link#3             U           em2
192.168.1.200      link#3             UHS         lo0
192.168.137.0/24   link#2             U           em1
192.168.137.200    link#2             UHS         lo0

Server environment

$ uname -r
11.3-RELEASE-p12
$ ifconfig
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
        ether 08:00:27:df:89:d7
        hwaddr 08:00:27:df:89:d7
        inet 192.168.0.159 netmask 0xffffff00 broadcast 192.168.0.255
        inet 192.168.0.160 netmask 0xffffff00 broadcast 192.168.0.255
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
em1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
        ether 08:00:27:9d:eb:82
        hwaddr 08:00:27:9d:eb:82
        inet 192.168.137.100 netmask 0xffffff00 broadcast 192.168.137.255
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
em2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
        ether 08:00:27:82:b1:20
        hwaddr 08:00:27:82:b1:20
        inet 192.168.1.100 netmask 0xffffff00 broadcast 192.168.1.255
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
        inet 127.0.0.1 netmask 0xff000000
        inet 10.100.0.1 netmask 0xffffffff
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        groups: lo

$ netstat -rn -4
Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
default            192.168.0.1        UGS         em0
10.100.0.1         link#4             UH          lo0
127.0.0.1          link#4             UH          lo0
192.168.0.0/24     link#1             U           em0
192.168.0.159      link#1             UHS         lo0
192.168.0.160      link#1             UHS         lo0
192.168.1.0/24     link#3             U           em2
192.168.1.100      link#3             UHS         lo0
192.168.137.0/24   link#2             U           em1
192.168.137.100    link#2             UHS         lo0

kadabusha avatar Jul 13 '21 12:07 kadabusha

This is normal and expected - the SIP RFC confirms that TCP traffic will generally have an ephemeral source port:

   Note that, because the source
   port is often ephemeral, but it cannot be known whether it is
   ephemeral or selected through procedures in [[4](https://www.rfc-editor.org/rfc/rfc3261#ref-4)], connections accepted
   by the transport layer will frequently not be reused.  The result is
   that two proxies in a "peering" relationship using a connection-
   oriented transport frequently will have two connections in use, one
   for transactions initiated in each direction.

(https://www.rfc-editor.org/rfc/rfc3261#section-18)

rkday avatar Apr 01 '23 09:04 rkday

(This is different between connection-oriented transports like TCP and datagram-oriented transports like UDP, as you observe, but again that's normal.)

rkday avatar Apr 01 '23 10:04 rkday