Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
TCP: Source address is from routing table not from -i flag #83
When using "-t tn" and "-i myip" the IP used to send messages is not myip but the IP from the OS (Linux) routing table.
Also filed the same bug on SourceForge: Issue 147. Posted on mailing list as well.
Steps to Reproduce
On the "server" side start netcat
On the "client" side run built-in UAC scenario using -t tn and -i myip
On the "server" side you'll see something like this on the output on netcat
If you look at the first line of the nc output it says the connection is from 10.10.0.4 instead of 10.10.0.5 (the IP we provided with the -i flag).
I have also tried -ci flag with the same result.
If I use -t un flag then the first line of output of nc is "Connection from 10.10.0.5 port 5060 [udp/*] accepted".
The IP 10.10.0.5 should be used whether -t is tn or un when making connections.
The version of SIPp tried:
A workaround I found was to add a SNAT rule to iptables to re-write the IP address. You may need to change the values according to your environment.
You can delete this rule when not needed.
added a commit
Aug 6, 2014
With this fix SIPp sends traffic using the IP address specified with the -i flag for both TCP and UDP. I confirmed it using Wireshark with the v3.3 binary and my private binary (with this fix).
I saw one issue when using -t tn versus -t t1 and -t un versus -t u1.
Using -t tn or -t un caused SIPp to fail to start with the following message when using the binary I compiled from the source code with this fix. SIPp started just fine using the v3.3 binary I was previously using.
With both v3.3 and my private binary, SIPp ran fine with -t t1 or -t u1, as below:
I was compiling the source with the fix for this issue on CentOS 6.4 (64-bit) as well as CentOS 5.10 (32-bit) and ran into two problems.
I am not experienced enough with C and compiling to know what effect my workarounds had. Maybe they contributed to the issue I observed with -t tn; I can't say for sure.
During ./configure I got the following error:
I made the error go away by commenting out the offending lines and replacing them with:
During make I got the following errors.
I got rid of them by running ./configure and make this way:
Thank you for looking into this issue and providing a fix so quickly. Looking forward to getting this fix in the next release so my team and I can upgrade to it on all our setups.
added a commit
Aug 7, 2014
referenced this issue
Sep 30, 2014
Possible fix -- which unfortunately breaks other regression tests. This needs better testing facilities:
added a commit
Jan 21, 2016
I have the patch but I am still seeing that source IP is not the same what has been mentioned with -i option.
Here is what sipp version I have:
Command I am using is:
Yet message received at remote end is from 172.16.80.1 which I think is what the kernel stack would have picked.