When socket is not bound explicitly to particular interface it is not
possible to specify what IP will be used to send datagrams. OS decides
On Tue, Jun 1, 2010 at 11:39 AM, Alexander Zhukov <z...@yandex.ru> wrote:
>>>>>> Fredrik Thulin (FT) writes:
> FT> On Tue, 2010-06-01 at 15:52 +0400, Alexander Zhukov wrote:
> FT> ...
> >> 192.168.67.1 is an IP of the vmnet8 (virtual network interface used
> >> by vmware workstation) on the host where incomingpproxy is running.
> >> When I stopped vmware virtual interfaces the call was established
> >> without problems.
> >> The question is: is this is a bug or a feature?
> >> If an additional info is required I'm ready to supply it.
> FT> Can't be called a feature, but I'm not sure it could be said to be
> FT> a bug in YXA that it does not work when you have unusable IP
> FT> addresses on interfaces in your server =).
> FT> The code in siphost.erl tries to avoid unusable interfaces, such as
> FT> those that are down (function usable_if), or has a loopback
> FT> address.
> FT> Since someone might actually _want_ to run YXA on a vmnet
> FT> interface, we can't just ignore those interfaces.
> FT> I can't think of any other solution than for you to configure the
> FT> list of "good" IP addresses for your server. See the configuration
> FT> option 'myips'. From the README :
> FT> myips (no default) For some platforms autodetection of the IP
> FT> addresses of the network interfaces doesn't work. If you have that
> FT> problem, list your IP addresses in this configuration parameter.
> Thank you very much for your answer!
> I added myips option and it works.
> But I still do not undestand some points.
> In my case incomingproxy should send an INVITE to the 10.10.16.157. The
> correct interface to send the packet by is one with an address from the
> same network -- 10.10.18.71.
> Why incomingroxy sets source IP address of the outgoing packet? Usually
> this job is done by an IP stack. Application which sits on the
> "application" level should not bother with such low level details.
> Alexander Zhukov
> Yxa-devel mailing list
Yxa-devel mailing list