A similar report has been filed a while back with Ubuntu:

https://bugs.launchpad.net/ubuntu/+source/ekiga/+bug/138932

I have no clue why you're playing with 2.x which is obsolete, and 2.9.x which was experimental... when 3.x is out and stable...

Because the 2.0.x is the most current that is prebuilt as part of Ubuntu's distribution.  In searching for a more updated version I came across the 2.9.x in one of the PPA's and gave it a shot.

However, I have found a 3.0.1 package and the behavior is still the same:

INVITE sip:8500@mimir SIP/2.0
Date: Sun, 18 Jan 2009 14:57:59 GMT
CSeq: 2 INVITE
Via: SIP/2.0/UDP 192.168.61.1:5060;branch=z9hG4bK2c89de10-dee3-dd11-82ef-001f3a66d6cc;rport
User-Agent: Ekiga/3.0.1
From: "Jamin Collins" <sip:jcollins@*:5060;transport=udp>;tag=e47bde10-dee3-dd11-82ef-001f3a66d6cc
Call-ID: 7af2db10-dee3-dd11-82ef-001f3a66d6cc@thinkpad
To: <sip:8500@mimir>
Contact: <sip:jcollins@192.168.61.1>
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,SUBSCRIBE,NOTIFY,REFER,MESSAGE,INFO,PING
Content-Type: application/sdp
Content-Length: 545
Max-Forwards: 70


The IP/interface automatically selected by Ekiga is incorrect.  The IP address that should have been used is 192.168.10.100, the IP address of the host it was contact was 192.168.10.4.  Yet, Ekiga continues to select the same libvirt interface, every time.

Are you sure there is only ONE single INVITE ?

No, there appears to be one for every single interface and IP.  However, there should be only one for the IP with the default route.

Likewise with registration, it sends a register request with each of the IP addresses in turn.  Thus the last IP (one of the libvirt interfaces) is assigned as the registered IP address and consequently is unreachable, as shown by this output from Asterisk's console:

xlite-jwc/xlite-jwc        192.168.62.1     D   N      5060     UNREACHABLE

Under Ekiga 2.0.x it is possible to configure the use of only one interface.  This setting doesn't seem to be preserved very well and as a result seems to frequently fall back to using one of the libvirt interfaces.  However, at least this version allows the configuration to be changed.  With the more recent releases I see no way to control the behavior and the defaults don't seem to work.

Sending one REGISTER request per interface is perfectly correct. Only one should work if your configuration is correct; or all of them should be accepted.

If you don't want your server to accept REGISTER requests for libvirt addresses, don't make it bind to those interfaces.

The server isn't bound to those interfaces, it only has one interface on the 192.168.10.0/24 network.  These are libvirt interfaces on my laptop only.

If I shut the libvirt interfaces down, registration works properly and Ekiga is able to place calls.  However, as long as the libvirt interfaces are present on the laptop the registration reported by my asterisk server contains one of the libvirt IP address and Ekiga is not able to successfully place calls.

In short there is some sort of a problem.  Whether it is with libvirt or Ekiga I don't know.  However, Ekiga is the only application I'm experiencing the issue with.  As are others from the bug reports on Ubuntu.  Though that is with the older version, the experience is the same.

I'm willing to provide whatever trace information you think would help, if you're willing to try to get to the bottom of this with me.

The problem is that your Asterisk server accepts the registration when it should reject it and let the correct REGISTER succeed.

There is no other way, except adding back an option to force Ekiga to bind to only one IP address.

The real question is : why does Asterisk accept to register a contact with an IP address it can't handle ?

I'd believe the answer to that is that it believes it can since the packet got to it.  Though the packet should not have ever gotten onto the network with any of those source IP addresses.

I did some further digging and it would appear that all the Ekiga packets are being created on the physical interface, simply changing the IP address.  This doesn't seem right to me.  If the packets were created on the correct interfaces they either wouldn't get out at all or they would be properly masked on the laptop system before the Asterisk system ever sees them.

The laptop has the following interfaces at most times:

lo     - loopback
ath0   - wireless
wifi0  - alias for ath0?
eth0   - wired
virbr0 - libvirt
virbr1 - libvirt
virbr2 - libvirt

Each of the virbrX interfaces has its own MAC address.  A Wireshark of Ekiga starting shows that all the registration messages originate with the MAC address of ath0.  Further testing with ping and setting just the source IP address resulted in similar behavior.  However, if instead I set the source interface the packets never left the laptop (as should be the case for virbr1 and virbr2) or when they left they were properly NAT'd (as should be the case for virbr0).

This leads me to believe that Ekiga isn't setting the source interface but only the source IP.  As further evidence of this, a dedicated capture on each of the virbrX interfaces resulted in no packets from an Ekiga startup.

Can you try with 3.1 ?

If it is the case, it is indeed a bug.

Please also attach a -d 4 debug output.

Created attachment 126780 [details]
Debug log output

Tested with 3.1, same results.  The debug log output shows that Ekiga is aware of which interface it should be using, but the wireshark output shows that it is not doing so.

Created attachment 126781 [details]
wireshark capture

And here is the associated wireshark capture.

I see this :
SIP/2.0 200 OK
Date: Mon, 19 Jan 2009 17:25:35 GMT
CSeq: 1 REGISTER
Via: SIP/2.0/UDP 192.168.10.100:5060;branch=z9hG4bKf206eed9-bbe4-dd11-8918-001f3a66d6cc;received=192.168.10.100;rport=5060
User-Agent: Asterisk PBX
From: <sip:xlite-jwc@192.168.10.4>;tag=605dedd9-bbe4-dd11-8918-001f3a66d6cc
Call-ID: 5851edd9-bbe4-dd11-8918-001f3a66d6cc@thinkpad
To: <sip:xlite-jwc@192.168.10.4>;tag=as3d89918e
Contact: <sip:xlite-jwc@192.168.10.100>;expires=300
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Expires: 300
Content-Length: 0


It shows that Asterisk has explicitely accepted to register 192.168.10.100 as Contact field for the xlite-jwc user.

It looks correct...

And later it accepts the 192.168.51.1:

SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.51.1:5060;branch=z9hG4bK5c14efd9-bbe4-dd11-8918-001f3a66d6cc;received=192.168.10.100;rport=1024
From: <sip:xlite-jwc@192.168.10.4>;tag=605dedd9-bbe4-dd11-8918-001f3a66d6cc
To: <sip:xlite-jwc@192.168.10.4>;tag=as3d89918e
Call-ID: 5851edd9-bbe4-dd11-8918-001f3a66d6cc@thinkpad
CSeq: 1 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Expires: 300
Contact: <sip:xlite-jwc@192.168.51.1>;expires=300
Date: Mon, 19 Jan 2009 17:25:35 GMT
Content-Length: 0

I'm not saying that Asterisk doesn't at some point get the right registration request.  That was my initial impression, granted.  However, at this point it looks like it gets several and uses the last, which is frequently 192.168.62.1 which should belong to an interface that is not allowed out of the laptop.  If the packet had originated on that interface it would not be allowed out of the laptop.

Regardless of what it is, or isn't, being accepted by Asterisk the wireshark clearly shows that the outbound messages are originating on the wrong interface MAC address.

I had a chat with the developer of that part of the code, and here is our conclusion...

Logging clearly shows it being written to the 192.168.51.1 interface and yet
the packet appears on the 192.168.10.100 interface.

If, as you imply, this is happening EVERY time, then it clearly cannot be a
race condition, which I doubt anyway as that code is pretty well protected
by mutexes nowadays. I would bet money it is not in PTLib/OPAL.

You say these interfaces are for some virtualisation, presumably some vmware
type thing. So, what we think is happening is that you have some system, like
another Linux, running in a virtual system on that interface, and it is
acting as a router. Packet goes in, is detected as not for it and is routed
back out to that virtual machines default route. This appears to happen to
the other two virtual machines but THIS one also seems to have a NAT layer.

That's the only way we can see for that packet to be going out like that.


Now, a SIP proxy is in general able to support multiple registrations for the same extension, and when routing an incoming call, able to route it to the correct destination. Asterisk is still unable to do so. So what I would do is disabling registering from those virtual IP addresses. You can do that in your sip.conf file.

Except reintroducing an option to listen on a specific interface, there is nothing we can do in opal, ptlib or ekiga to fix that erroneous behavior.

(In reply to comment #17)
> I had a chat with the developer of that part of the code, and here is our
> conclusion...
> 
> Logging clearly shows it being written to the 192.168.51.1 interface and yet
> the packet appears on the 192.168.10.100 interface.

I'm not convinced that the packets are being written on the correct interface.  All wireshark tracing indications are that the packets are being written to the wrong interface only with the IP changed.  The wireshark capture that was uploaded was done as root on the "Pseudo-device that captures on all interfaces: any".  This captures anything generated on all interfaces on the system.  If you'd like I can perform the same capture again and perform some additional tests such as using ping and specifying a source IP and then again specifying a source interface.  I'm confident you'll see the first case mimic what is being seen from Ekiga and the second instance the packets will be created on the correct interface and be subject to the rules regarding those interfaces.

> If, as you imply, this is happening EVERY time, then it clearly cannot be a
> race condition, which I doubt anyway as that code is pretty well protected
> by mutexes nowadays. I would bet money it is not in PTLib/OPAL.

It is happening 100% of the time.

> You say these interfaces are for some virtualisation, presumably some vmware
> type thing. 

I'm using libvirt: http://libvirt.org/.  However, others using vmware have also experienced this problem.  Either case should be easy enough to setup on a development system.  I'd be happy to help setup or provide access to such a system.

> So, what we think is happening is that you have some system, like
> another Linux, running in a virtual system on that interface,

Nope.  No virtual machines running on the system at the time.  The only bit that is necessary is for the interfaces created by libvirt to exist.  If the libvirt process is stopped, and as a result the interfaces removed, Ekiga functions fine.

> and it is
> acting as a router. Packet goes in, is detected as not for it and is routed
> back out to that virtual machines default route. This appears to happen to
> the other two virtual machines but THIS one also seems to have a NAT layer.

If this were the case, the wireshark trace would have shown the packet on the libvirt interface going into the supposed virtual machine.

> Except reintroducing an option to listen on a specific interface, there is
> nothing we can do in opal, ptlib or ekiga to fix that erroneous behavior.

This would be acceptable provided that Ekiga always honored the configuration if set.  Under the 2.0.x series it would periodically ignore the setting and default to one of the libvirt interfaces again.  Forcing the user to go back into the configuration, reselected the preferred interface and restart the application/ 

(In reply to comment #17)
> > I had a chat with the developer of that part of the code, and here is our
> > conclusion...
> > 
> > Logging clearly shows it being written to the 192.168.51.1 interface and yet
> > the packet appears on the 192.168.10.100 interface.

> I'm not convinced that the packets are being written on the correct 
> interface. 
> All wireshark tracing indications are that the packets are being written to 
> the wrong interface only with the IP changed.  

I'm not convinced it is possible. If you have some time, perhaps you can simply add some checks in psockbun.cxx in PTLIB and try seeing what's wrong.

> > You say these interfaces are for some virtualisation, presumably some vmware
> > type thing. 

> I'm using libvirt: http://libvirt.org/.  However, others using vmware have 
> also experienced this problem.  Either case should be easy enough to setup on > a development system.  I'd be happy to help setup or provide access to such a
> system.

I will ask Robert if he is interested. Robert is the guy who coded that code in PTLIB.

> > Except reintroducing an option to listen on a specific interface, there is
> > nothing we can do in opal, ptlib or ekiga to fix that erroneous behavior.

> This would be acceptable provided that Ekiga always honored the configuration
> if set.  Under the 2.0.x series it would periodically ignore the setting and
> default to one of the libvirt interfaces again.  Forcing the user to go back
> into the configuration, reselected the preferred interface and restart the
> application/ 

That's either because your gconf installation is broken or because Ekiga is run with virt interfaces up and the eth interface down.

I've done some further testing with strace on Ekiga and on the standard ping binary and found something interesting.  When specifying the source interface to ping there are two an additional (and I think critical) system calls:

14866 setsockopt(4, SOL_SOCKET, SO_BINDTODEVICE, "virbr0\0", 7) = 0
14866 ioctl(3, SIOCGIFINDEX, {ifr_name="virbr0", ifr_index=5}) = 0

Otherwise the interface name never appears in the strace output, other than the initial output of the command line parameters.  And the interface never appears in the output from ping when the source is specified by IP address alone.

I suspect that the SO_BINDTODEVICE call is probably the required piece.

Hello *,

I'm suffering the same problem with Ekiga 3.2.0 on Kubuntu 9.04 running vmware. When vmware is started, Ekiga tries to authenticate at our Asterisk with the wrong IPs and - at least according to the Asterisk log - *NOT* with the correct IP. In other words: It tries to authenticate twice, but there are 3 network interfaces, where the correct one is the 3rd.

I definitely agree that it is nice to have such an auto detection feature. But it should be possible to force Ekiga to use a certain device/IP!!!

I do not understand, why the network preferences UI disappeared. If you think that it's too much for an average user, then please hide it in an "advanced" UI or similar. But it should definitely still exist and allow for advanced settings like how to traverse a firewall, which network interface(s) to use, and many more.

For a quick-fix, it would at least be cool, if either manual changes to Ekiga's config files or a startup parameter could force Ekiga to use a certain interface (or a list of interfaces). Right now, I can't use Ekiga and manual changes to the config would be a fast & easy-to-implement solution (before the UI is ready again).

Best regards, Marco :-)

The problem is at ASTERISK's side. It should accept both registrations or cleanly reject one.

We can only workaround it by adding back the ability to listen only on one interface.

I have also experienced this behavior with the 3.2.6 client and Aastra (Ericsson) MX-one. If you have multiple addresses bound to the nic it doesn't work. If I use 10.0.0.1 and 192.168.0.1 bound to the same nic it doesn't work.

I had the same problem with Ekiga 3.2.6 – 'random' source IP would be used when calling a LAN-connected Asterisk-based PBX.

I use Ekiga as a test client for a PBX development. My workstation, as the development workplace, is connected to a corporate VPN, a local test network, to the Internet and sometimes some virtual machines are also running here. I have a lot of interfaces and sometimes complicated routing and firewalling rules, but most software has no problem with that – the kernel does the right job using the right IP address for right interface.

Ekiga 2.x was not problematic either, I could force right interface and after restarting Ekiga I could use it with the SIP clients on that interface. Unfortunately with current Ekiga that option was removed and Ekiga tries to be smart… and does it _wrong_.

I agree listening on all interfaces is a good idea, but sending requests via all interfaces using other interfaces IP (and that is what Ekiga 3.2.6 does) is plain wrong. When contacting a client X reachable via interface ethX (as the routing table says) IP address of that interface should be used. When the client is contacted with other interface's IP address it will accept such request (why not?), but its answer will go wrong way (e.g. the device's default route).

After reading this bug comment I found a way to workaround the problem: I made my local workstation firewall drop the invalid outgoing requests (with source IP not matching interface IP), so the PBX receives only the right one. But that is only a workaround.

The right solution would be to let the kernel choose right source IP for the given target. Also, IMHO Ekiga should keep the functionality of choosing interface and source IP address. I agree these settings are not needed for 'regular user', but may be essential for handling various 'special cases'. I am ok with having those only available via gconf-editor or environment variable.

Does it still happen with ekiga >= 4.0.0 ?  There were changes related to this.

(In reply to comment #25)
> Does it still happen with ekiga >= 4.0.0 ?  There were changes related to this.

Hi Jamin, 
I am closing this bug report as no updated information has been provided.
Please feel free to reopen this bug if you can provide the information that was asked for in a previous comment.