[Home]

Summary:ASTERISK-24282: chan_sip communicating via TCP on IP assigned to physical interface when Asterisk is bound to virtual interface/alias
Reporter:Zohair Raza (zuhairraza)Labels:
Date Opened:2014-08-28 12:48:48Date Closed:
Priority:MajorRegression?
Status:Open/NewComponents:Channels/chan_sip/General Channels/chan_sip/Interoperability Channels/chan_sip/TCP-TLS
Versions:11.3.0 11.20.0 13.18.4 Frequency of
Occurrence		Constant
Related
Issues:
is a clone ofASTERISK-24926 CLONE - Asterisk listening/communicating on undefined IP
Environment:Vmware Esxi / Centos 6 Attachments:( 0) 7may.pcapng
( 1) ast.pcap
( 2) issue24282
( 3) mylog.log
( 4) rusty_asterisk24282.pcap
( 5) rusty_extensions.txt
( 6) rusty_full.txt
( 7) rusty_lsof.txt
( 8) rusty_messages.txt
( 9) rusty_sip_show_peer_ALICE.txt
(10) rusty_sip_show_peer_BOB.txt
(11) rusty_sip_show_peers.txt
(12) rusty_sip_show_settings.txt
(13) rusty_sip.txt
(14) s1.pcap
Description:Hi,

I am running asterisk on VMs with standby heartbeat configuration, Heartbeat assigns a virtual IP 172.20.255.40 on machine afterwards asterisk is started. In the sip.conf, I have explicitly define bindaddr=172.20.255.40 but sometimes I see packets coming from physical IP 172.20.255.41

I have both tcp and udp transport enabled

Here is the lsof -ni :5060 output

asterisk 2878 asterisk  613r  IPv4 40060683      0t0  TCP 172.20.255.41:52381->10.100.210.110:sip (ESTABLISHED)
asterisk 2878 asterisk  528u  IPv4 29757779      0t0  TCP 172.20.255.41:55627->10.200.14.29:sip (ESTABLISHED)
asterisk 2878 asterisk  530u  IPv4 19211854      0t0  TCP 172.20.255.40:sip->10.100.157.32:49227 (ESTABLISHED)

sip show settings


Global Settings:
----------------
 UDP Bindaddress:        172.20.255.40:5060
 TCP SIP Bindaddress:    172.20.255.40:5060



Comments:By: Rusty Newton (rnewton) 2014-09-02 18:20:30.201-0500

Thank you for taking the time to report this bug and helping to make Asterisk better. Unfortunately, we cannot work on this bug because your description did not include enough information. You may find it helpful to read the Asterisk Issue Guidelines http://www.asterisk.org/developers/bug-guidelines. We would be grateful if you would then provide a more complete description of the problem. At a minimum, we need:

1. the specific steps or actions you took that caused you to encounter the problem,
2. the behavior you expected, and
3. the behavior you actually encountered (in as much detail as possible).

This likely includes output from the console with debug level logging, a SIP trace (if this is SIP related), and configuration information such as dialplan (e.g. extensions.conf) and channel configuration (e.g. sip.conf). Thanks!


By: Rusty Newton (rnewton) 2014-09-02 18:21:27.698-0500

Specifically please provide a packet capture and Asterisk log(including SIP trace and verbose output) showing the issue. Attach the sip.conf configuration as well.
By: Zohair Raza (zuhairraza) 2014-09-08 08:55:31.504-0500

Hi Rusty

Sorry I didnt get email alert for some reason and couldnt reply earlier

Here are more details, I hope this will help

Steps:
On a Linux machine, I have two IPs from same network i.e. 172.20.255.40 and 172.20.255.41 cidr 24
In sip.conf, I specified bindaddr to be 172.20.255.40 so I expected asterisk to be responding via one IP only as defined in the bindaddr field but on the linux machine itself and on when I do a packet capture on remote endpoint, I see some requests being originated with 172.20.255.41 which should not be the case

And lsof/netstat also showing connections being established on .41 IP
lsof -ni :5060 output
asterisk 2878 asterisk 613r IPv4 40060683 0t0 TCP 172.20.255.41:52381->10.100.210.110:sip (ESTABLISHED)
asterisk 2878 asterisk 528u IPv4 29757779 0t0 TCP 172.20.255.41:55627->10.200.14.29:sip (ESTABLISHED)
asterisk 2878 asterisk 530u IPv4 19211854 0t0 TCP 172.20.255.40:sip->10.100.157.32:49227 (ESTABLISHED)

Below is the sip.conf's general section, I am also attaching pcaps.
1. "7may.pcap" is an old one but has relevant info that you can see requests coming from .41.
2. "s1.pcap" is taken on the asterisk server
3. mylog.log has the debug and verbose level 5

[general]
bindaddr=172.20.255.40
;udpbindaddr=172.20.255.40
transport=udp,tcp
tcpenable=yes
tlsenable=no
;tcpbindaddr=172.20.255.40
directrtpsetup=no
directmedia=yes
allowguest=no
sdpsession=EMC
callerid=EMCPBX
realm=emc
match_auth_username=yes
tos_sip=af31
tos_audio=ef
tos=0xB8
tos_video=af41                 ; Sets TOS for RTP video packets.
tos_text=af41                  ; Sets TOS for RTP text packets.
trustrpid = yes                 ; If Remote-Party-ID should be trusted
sendrpid = yes                 ; If Remote-Party-ID should be sent (defaults to no)
disallow=all
allow=alaw
allow=ulaw
allow=g729
maxforwards=70
relaxdtmf=yes
rpid_update = yes
maxexpiry=3600
minexpiry=60
defaultexpiry=600
qualify=no ;
notifycid = yes ; Control whether caller ID information is sent along with dialog-info+xml notifications (supported by snom phones)
qualifypeers=15
qualifygap=2000
progressinband=never
ignoreregexpire=no
recordofffeature=
recordonfeature=
localnet=172.16.0.0/12
localnet=10.0.0.0/8

Thanks
By: Rusty Newton (rnewton) 2014-09-23 09:31:08.068-0500

Thanks for the debug. That will be helpful. Have you confirmed this behavior happens in a recent version of 11? I noticed you are using 11.3.0 which was released back in March of last year.
By: Rusty Newton (rnewton) 2014-10-08 14:53:58.970-0500

Suspended due to lack of activity. Please request a bug marshal in #asterisk-bugs on the IRC network irc.freenode.net to reopen the issue should you have the additional information requested.  Further information can be found at http://www.asterisk.org/developers/bug-guidelines


By: Zohair Raza (zuhairraza) 2014-12-17 04:53:49.419-0600

Hi Rusty

Sorry I didn't get email alert for this

No I haven't tried it on latest version, was debug information any helpful to you ?
By: Zohair Raza (zuhairraza) 2015-03-30 12:44:21.388-0500

Hello Team

Any update

I just tested the latest version from certified branch

and found the same problem

My Asterisk is supposed to listen on 172.20.255.66 only but it is also communicating with wrong IP

[root@RAI-TESTPBX-01 certified-asterisk-11.6-cert10]# lsof -i :5060
COMMAND   PID     USER   FD   TYPE    DEVICE SIZE/OFF NODE NAME
asterisk 3494 asterisk   12u  IPv4 125728629      0t0  UDP 172.20.255.66:sip
asterisk 3494 asterisk   13u  IPv4 125728630      0t0  TCP 172.20.255.66:sip (LISTEN)
asterisk 3494 asterisk   21u  IPv4 125742847      0t0  TCP 172.20.255.66:sip->10.100.210.110:xds (ESTABLISHED)
asterisk 3494 asterisk   27u  IPv4 125742863      0t0  TCP 172.20.255.65:48591->10.100.210.110:sip (ESTABLISHED)

The version I tested this on is
certified-asterisk-11.6-cert10

By: Michael L. Young (elguero) 2015-03-30 15:01:43.701-0500

Zohair,

Can you please provide a complete debug log based on this latest version you are running?

https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information

Thanks
By: Zohair Raza (zuhairraza) 2015-03-31 08:21:26.501-0500

Hello Michael

Attaching the files as requested

By: Zohair Raza (zuhairraza) 2015-03-31 08:21:57.169-0500

Asterisk debug log
By: Zohair Raza (zuhairraza) 2015-03-31 08:35:19.441-0500

pcap of 5060 port on asterisk box
By: Rusty Newton (rnewton) 2015-04-14 13:15:28.998-0500

Thanks. Unfortunately it isn't clear to me what is going on from the log. Also, your packet capture does not show all of the same traffic seen in your Asterisk log which is unhelpful in troubleshooting. I can see some SIP traffic originating from *.65, but it isn't clear why.

For us to investigate this further you will need to provide a complete reproduction plan including:

* Including all necessary configuration files (that may be modified for our own test network).
* An explanation of the steps required to reproduce the issue.

As it is right now, many people, including the Digium development team run Asterisk within virtual machines and we haven't seen this issue. That means that if you are experiencing a bug that there is something very specific to either your configuration or environment that is not obvious. We need your help to pinpoint what that factor is.
By: Rusty Newton (rnewton) 2015-04-14 13:15:59.612-0500

Please press "Send Back" or "Enter Feedback" to make sure we see your response.
By: Zohair Raza (zuhairraza) 2015-04-21 10:28:13.055-0500

Hi Rusty

You may give a try this way

Use one IP on a physical interface and another on a virtual one like below
eth0      Link encap:Ethernet  HWaddr 00:50:56:A0:12:01
         inet addr:172.20.255.41  Bcast:172.20.255.255  Mask:255.255.255.0
eth0:0    Link encap:Ethernet  HWaddr 00:50:56:A0:12:01
         inet addr:172.20.255.40  Bcast:172.20.255.255  Mask:255.255.255.0
         UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

In sip.conf, set asterisk to listen on the IP address that is on virtual interface
[general]
bindaddr=172.20.255.40
transport=udp,tcp
tcpenable=yes

Create some extensions and register two or three softphones, I suggest using microsip as it is the one I am using (issue is not related to softphone because I have seen the same with some IP phones as well)

Use TCP transport for the softphone and then see on asterisk machine in netstat or "lsof -i :5060", you will see some connections from the IP that is on physical interface i.e in above case 172.20.255.41

Let me know if you need anything else

thanks



By: Zohair Raza (zuhairraza) 2015-06-30 07:23:59.519-0500

hello

any update on this please
By: Joshua C. Colp (jcolp) 2015-06-30 07:28:06.435-0500

You did not press the "Send Back" or "Enter Feedback" button as Rusty said, and thus it was still waiting for feedback from you. I've now moved it.
By: Joshua C. Colp (jcolp) 2015-06-30 07:29:23.527-0500

Actually, it appears as though you set it to Waiting For Feedback from yourself after asking for an update. I've moved it back.

There has been no change in this issue. If there is it will be reflected here and updated.
By: Zohair Raza (zuhairraza) 2015-06-30 08:04:36.418-0500

Oh, I remember I did send back and Enter feedback

not sure what has happened
anyway, thanks
By: Zohair Raza (zuhairraza) 2015-07-17 23:38:03.948-0500

Hello Team

Any luck on this?

I noticed another thing, I tried the latest certified-asterisk and initiate a call from Asterisk to a tcp sip peer and it was sourced from the primary interface eth0 instead of eth0:0
I had a private IP address on eth0 and public on eth0:0, my asterisk is configured to listen on the public IP and it works as expected in UDP but in TCP I got private IP as source at the other side and also in the tcpdump on server.
By: Joshua C. Colp (jcolp) 2015-07-18 05:20:31.896-0500

As I previously mentioned any updates will be posted to this issue. Asking for one will not accomplish anything.
By: Rusty Newton (rnewton) 2015-10-07 14:36:27.377-0500

I'm no expert with virtual interface or IP Aliasing but I was able to reproduce this after some trouble (mostly in getting virtual interfaces working properly).

I'm attaching a range of files each prefixed with 'rusty_'

The sip.txt and extensions.txt can be used to reproduce the issue.

I registered Microsip from a windows machine to ALICE. Configured for UDP.
I registered a Digium D40 with BOB. Configured for TCP.

To reproduce I had 6001(ALICE) call 6002(BOB).

Upon making this call (without answering) I could see:

{noformat}
COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
asterisk 24011 root   13u  IPv4  63054      0t0  TCP 192.168.1.110:sip->192.168.1.102:58599 (ESTABLISHED)
asterisk 24011 root   15u  IPv4  62952      0t0  UDP 192.168.1.110:sip
asterisk 24011 root   16u  IPv4  62953      0t0  TCP 192.168.1.110:sip (LISTEN)
asterisk 24011 root   36u  IPv4  63274      0t0  TCP 192.168.1.101:49069->192.168.1.102:sip (ESTABLISHED)
{noformat}

As with Zohair's configuration, I have Asterisk bound to the virtual interface only which in my case is 192.168.1.110.  The .101 address is the eth0 and .110 is eth0:0.

{noformat}
[general]
bindaddr=192.168.1.110
transport=udp,tcp
tcpenable=yes
tlsenable=no
{noformat}

Calling the other direction... 6002 to 6001 establishes a connection via 110 which seems appropriate. I tried switching which transport each extension uses, but then the problem didn't occur at all. That is, with the D40 using UDP and Microsip using TCP the problem didn't occur.