Yrurtj

When sending packets from an application that binds to a local address TCP uses a different source address than UDP. For example, bind to 10.10.0.51 (alias IP), the src addr for UDP is 10.10.0.51 but the src addr for TCP is 10.10.0.2 (primary IP address of the machine). This is observed using tcpdump packet capture.

The output of "ip route show" includes this line: "10.10.0.0/22 dev eth1 proto kernel scope link src 10.10.0.2"

My question: why does TCP use the source address from the routing table but UDP uses the source address the application binds to?

This is on CentOS 6.

[user@host ~]$ ip route show

10.10.0.0/22 dev eth1  proto kernel  scope link  src 10.10.0.2 

10.20.0.0/22 via 10.10.0.1 dev eth1 

10.145.192.0/18 dev eth0  proto kernel  scope link  src 10.145.194.226 

169.254.0.0/16 dev eth0  scope link  metric 1002 

169.254.0.0/16 dev eth1  scope link  metric 1003 

169.254.0.0/16 dev eth2  scope link  metric 1004 

default via 10.145.255.254 dev eth0 







[user@host ~]$ uname -a

Linux machinename 2.6.32-358.6.1.el6.x86_64 #1 SMP Tue Apr 23 19:29:00 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux







[user@host ~]$ ip address show

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue 

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

    inet 127.0.0.1/8 scope host lo

    inet6 ::1/128 scope host 

       valid_lft forever preferred_lft forever

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000

    link/ether 00:50:56:01:c3:96 brd ff:ff:ff:ff:ff:ff

    inet 10.145.194.226/18 brd 10.145.255.255 scope global eth0

    inet6 fe80::250:56ff:fe01:c396/64 scope link 

       valid_lft forever preferred_lft forever

3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000

    link/ether 00:50:56:01:c3:97 brd ff:ff:ff:ff:ff:ff

    inet 10.10.0.2/22 brd 10.10.3.255 scope global eth1

    inet 10.10.0.51/22 scope global secondary eth1:1

    inet 10.10.0.52/22 scope global secondary eth1:2

    inet 10.10.0.53/22 scope global secondary eth1:3

    inet 10.10.0.54/22 scope global secondary eth1:4

    inet 10.10.0.55/22 scope global secondary eth1:5

    inet6 2002::10:10:0:55/96 scope global 

       valid_lft forever preferred_lft forever

    inet6 2002::10:10:0:54/96 scope global 

       valid_lft forever preferred_lft forever

    inet6 2002::10:10:0:53/96 scope global 

       valid_lft forever preferred_lft forever

    inet6 2002::10:10:0:52/96 scope global 

       valid_lft forever preferred_lft forever

    inet6 2002::10:10:0:51/96 scope global 

       valid_lft forever preferred_lft forever

    inet6 fe80::250:56ff:fe01:c397/64 scope link 

       valid_lft forever preferred_lft forever

4: eth2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000

    link/ether 00:50:56:01:c3:98 brd ff:ff:ff:ff:ff:ff

5: ip6tnl0: <NOARP> mtu 1460 qdisc noop 

    link/tunnel6 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 brd 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00

EDIT:
The application in question is SIPp.

sipp -sn uac -i 10.10.0.51 -t tn -p 5060 -m 1 -r 1 10.10.0.1



sipp -sn uac -i 10.10.0.51 -t un -p 5060 -m 1 -r 1 10.10.0.1

EDIT 2:

[user@host ~]$ ss -tplan | grep 5060

LISTEN     0      100              10.10.0.51:5060                     *:*      users:(("sipp",14837,3))

SYN-SENT   0      1                 10.10.0.2:50903            10.10.0.1:5060   users:(("sipp",14837,7))



[user@host ~]$ ss -uplan | grep 5060

UNCONN     0      0                10.10.0.51:5060                     *:*      users:(("sipp",14850,3))

I was able to confirm (to an extent) that the issue is with SIPp and not in Linux in general.

I have created a ticket with SIPp: https://sourceforge.net/p/sipp/bugs/147/

My troubleshooting was as follows:

On "server" side open netcat:

nc -v -l 10.10.0.55 5060

On "client side open netcat:

nc -v -s 10.10.0.5 10.10.0.55 5060

Output on "server" side:

Connection from 10.10.0.5 port 5060 [tcp/*] accepted

Output on "client" side:

Connection to 10.10.0.55 5060 port [tcp/sip] succeeded!

When I don't specify a specific IP on the "client" side:

nc -v 10.10.0.55 5060

Then the output on the "server" side is:

Connection from 10.10.0.4 port 5060 [tcp/*] accepted

This means that specifying a specific IP address works and it's SIPp that doesn't work that way when using the -i flag.