GNOME Bugzilla – Bug 324564
Multiple network interfaces should be handled. Registration/unregistration should occur when interfaces are going up and down.
Last modified: 2008-09-06 15:58:39 UTC
Please describe the problem: I'm using the CVS snapshot to register to a SIP server though an OpenVPN (bridged) link. Doing an ethereal trace seems to suggest that Gnomemeeting isn't trying to route via the right interface. I can register to the server using Linphone and I have some ethereal traces to demonstrate this. Steps to reproduce: 1. Set up an bridged mode OpenVPN link (which works for UDP) 2. Start the SIP server 3. Try and register (wait for it to time out) 4. Record a packet trace Actual results: The SIP register packet uses the default interface to send packets to instead of the correct interface. Expected results: SIP register packets should be sent on the tap0 interface, not the eth0 interface. Does this happen every time? Yes Other information: The quick trace I did suggests that gnomemeeting is trying to connect to 172.20.1.1 (which is my SIP server) but the originating IP is 144.131.20.163 (which is wrong) and the SIP register packets time out. Gnomemeeting: 1.185038 144.131.20.163 -> 172.20.1.1 SIP Request: REGISTER sip:shake 5.188584 144.131.20.163 -> 172.20.1.1 SIP Request: REGISTER sip:shake 11.189030 144.131.20.163 -> 172.20.1.1 SIP Request: REGISTER sip:shake Using Linphone, the same SIP request is sent out, but the difference is that the packet is originating from the right IP address (172.20.1.16) Linphone: 28.118238 172.20.1.16 -> 172.20.1.1 SIP Request: REGISTER sip:shake 28.140048 172.20.1.1 -> 172.20.1.16 SIP Status: 100 Trying (1 bindings) 28.158061 172.20.1.1 -> 172.20.1.16 SIP Status: 401 Unauthorized (1 bindings) 28.579643 172.20.1.16 -> 172.20.1.1 SIP Request: REGISTER sip:shake 28.612163 172.20.1.1 -> 172.20.1.16 SIP Status: 100 Trying (1 bindings) 28.639937 172.20.1.1 -> 172.20.1.16 SIP Status: 200 OK (1 bindings) 28.639967 172.20.1.1 -> 172.20.1.16 SSH Encrypted response packet len=208 33.752169 172.20.1.16 -> 172.20.1.1 SIP Request: REGISTER sip:shake 33.782001 172.20.1.1 -> 172.20.1.16 SIP Status: 100 Trying (1 bindings) 33.801967 172.20.1.1 -> 172.20.1.16 SIP Status: 401 Unauthorized (1 bindings) 33.854565 172.20.1.16 -> 172.20.1.1 SIP Request: REGISTER sip:shake 33.882006 172.20.1.1 -> 172.20.1.16 SIP Status: 100 Trying (1 bindings) 33.898207 172.20.1.1 -> 172.20.1.16 SIP Status: 200 OK (1 bindings) 33.898745 172.20.1.1 -> 172.20.1.16 SSH Encrypted response packet len=96 A route -n shows: Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 144.131.20.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 172.20.1.0 0.0.0.0 255.255.255.0 U 0 0 0 tap0 127.0.0.0 127.0.0.1 255.0.0.0 UG 0 0 0 lo 0.0.0.0 144.131.20.1 0.0.0.0 UG 0 0 0 eth0
Have you selected the rigth interface to "listen on" in the preferences?
Yeah, my bad. That fixed it. Thanks Damien.
The problem is that it is not really a good solution, because you could have several accounts using different routes. I'm still looking for a better way to do this. So I'll leave the bug "open". Just know there is a solution, but I don't like it :)
(was just about to file a bug about the only-listen-on-one-interface issue, but will add here instead) I have the same problem, though it's worse, because I have two asterisk boxen, on two different VPNs. I can't connect to both at the same time, and to switch between the two, I have to change the preferences. Solution:?: have a list of detected interfaces, and the user selects which ones they want ekiga to listen on. There should be a "Listen on all interfaces" which probably should be the default.
Another twist on the same problem: My laptop uses either of three net interfaces, depending on circumstances (eth0 for wired, wlan0 for wireless, or tun0 for OpenVPN). This changes several times a day. Shouldn't Ekiga listen on all interfaces by default, like most network applications?
*** Bug 345685 has been marked as a duplicate of this bug. ***
Changing component to OPAL. The bug is there.
*** Bug 397768 has been marked as a duplicate of this bug. ***
*** Bug 335088 has been marked as a duplicate of this bug. ***
There are several problems with network interfaces : - a single box can have several of them, and we should be able to do something about it ; - not every account may route through each of those interfaces ; - if there are interface changes, say in the case of roaming, then we should be able to cope with network interfaces appearing/disappearing. I'm trying to melt all reports we have into this only one :-)
Another problem with the way this is currently handled is that ekiga advertises itself as being available on all interfaces (via mDNS/Avahi/Bonjour) but can only be contacted on one. It is probably possible to fix this on the mDNS end (tell Avahi that the service is only available on the specified interface) but a better way to fix it, if possible, would be to make OPAL listen on all interfaces by default. Because of the way SIP works it's probably fairly difficult to make it handle more than one IP address at a time but in terms of making the product "just work" it may be worth the effort. The next best thing would be to choose the default gateway interface by default. Perhaps this is what ekiga already does?
*** Bug 495917 has been marked as a duplicate of this bug. ***
Retitling to make it more explicit.
*** Bug 504218 has been marked as a duplicate of this bug. ***
*** Bug 521008 has been marked as a duplicate of this bug. ***
*** Bug 390890 has been marked as a duplicate of this bug. ***
*** Bug 473013 has been marked as a duplicate of this bug. ***
*** Bug 491814 has been marked as a duplicate of this bug. ***
This should be fixed by now, shouldnt it?
I just did the last commit.