Re: Problem with Multi-homed Win32 PC's

Brian Godette (bgodette@idcomm.com)
Tue, 14 Jul 1998 15:13:42 -0600


At 08:59 PM 7/14/98 +0200, you wrote:
> Hi, since my email to cu-seeme-bugs@cornell.edu returned with a DNS
>error I thought I try the mailing list next... Please accept my apologies
>in advance if this arrives now for the 3rd time! I've encountered a
>problem with CU-SeeMe version 1.0 on Windows NT. This problem should be
>present at least in all Win32 operating systems using the MS-TCP
>implementation: CU-SeeMe detects the IP-address it uses to connect to
>the reflector server when it starts (the address is shown in the status
>bar). This might lead to wrong addresses transmitted in multi-homed PC's
>(those having more than one IP-address). My machine for example has a fixed
> IP-address assigned to the network card but gets dynamic addresses when
>connection to the Internet via my ISDN-card. Since I made the same
>mistake in an IP-software myself, I would like to present a solution for
>the problem: It seems to be impossible to decide which IP-address to use
>as the source address in a multi-homed Win32-environment. The correct
>IP-address depends on the server you connect and is determined by the
>MS-IP-stack. The solution is quite simple: Don't try to know your local
>address before you're connected! Simply connect() to the Reflector-server.
>After a successful connect, do the following:
> struct sockaddr_in LocalIP; int AddrLen = sizeof(struct sockaddr_in);
>&&AddrLen); if (*status == 0) MyLocalIPAdr = LocalIP.sin_addr.s_addr;
> This works reliable on all MS-implementations. Since I need this fix to
>run CU-SeeMe on my system, I hope I could be of some assistance...
>Thanks in advance for fixing this.. Regards Uwe

This works only for TCP protocols, which CU-SeeMe isn't, excluding the
conf-selection-box which is a WP ref thingy. I've yet to run any tests with
ERef + WP client to see what would happen if I put in a listen tcp socket
on 7648 and accepted & closed the connection (maybe this week... still
working on finding an acceptable ref solution to chat spew other than
dropping the packets).