Bug#495325: ekiga: too restrictive listening policy
Bas Wijnen
wijnen at debian.org
Sat Aug 16 08:55:39 UTC 2008
Package: ekiga
Version: 2.0.12-1+nmu1
Tags: upstream
Ekiga goes through some trouble to find out what the "real" network
interface is (as opposed to the loopback, in particular), and starts
listening only on that. I don't see any advantage of this, but it does
have several drawbacks (compared to listening on all interfaces):
- If ekiga is started when no network is available, it complains about
being unable to listen for incoming connections. This is not as
unusual as it might seem: I start ekiga when my laptop boots. I would
prefer ekiga to be silent and start working when I connect my network.
Being silent can be a commanline option or preferences setting as far
as I'm concerned; automatically starting to work is very painful to
implement when keeping the current scheme, but works automatically
when listening on 0.0.0.0.
- I tried using Ekiga over some ppp interfaces (connecting two subnets).
I needed to add a route to the public address of the machine to go
through the tunnel, because I couldn't reach ekiga at the address of
the ppp interface. And even then it only worked because the computer
was masqueraded: if I would have needed to add the real public
address, it would have destroyed the tunnel (because it would be
unable to reach the host over the non-tunneled network then).
- For machines with more than one interface in general (the above is an
example of that), you need to make sure to use the exact interface
that ekiga expects, and not any of the others. This leads to
unexpected "unable to connect" errors.
- I think this may also be the source of several ways to set up a
"one-way" connection: one side hears (and sees) the other, but there
is no reply. This may also be unrelated though.
More information about the pkg-gnome-maintainers
mailing list