On Monday 12 August 2002 04:06, Thiago Macieira wrote: > The address used to communicate can only be discovered with certainty when > the communication is already established, via getsockname(2) and > getpeername(2). Yes, but this does not help me, because in many cases the connection is not established and in some cases I dont even know the IP of the other side. I need the IP for two things: - to announce a service via SLP. SLP requires me to broadcast the URL of my service, so I need a IP of the system that is reachable in the local LAN -to send invitation mails for Desktop Sharing. I need to include an internet-reachable IP of the system in the mail so the invited person knows to which system she must connect to And there are other protocols which require the local IP as well, for example SIP. > And in the light of all the NAT that is being done, trying > to discover one's IP address locally doesn't help much. Yes, I am still hoping that a more mature version of TURN (http://www.jdrosen.net/midcom_turn.html) will be released soon. Right now the only way to get the public IP for TCP connections is UPnP's IGD spec, as used by Windows, but I really don't want to mess with UPnP stuff. > As you said yourself in the comments, configuring the addresses using a > KCM should be better. On most systems the auto-discovery feature should work very well. The typical situation of a multi-homed system is one ethernet card and a PPP connection. In these cases it will take the PPP connection as "private" internet address and the ethernet address for LAN. You only need to configure manually when you have more than one ethernet card or PPP connection. The problem with KCM configuration is that the interfaces names are not stable. Configuring the IP address itself will fail in many cases (IP assigned by DHCP or PPP), and then you need to specify the interface name for the LAN and the "private" internet address. But as the name of the interface usually depends on the order they came up, this is not reliable. bye...