Attention Windows Users!!!

pstingley@smtpgate.ssmc.noaa.gov
Mon, 30 Jan 1995 17:19:17 -0500


It appears that the Windows version of the client software and the new
release of the reflector software are particularly sensitive to
Domain Name Service (DNS) irregularities. The result is that Windows
users are always given "No response from [ reflectorname ]".

In my own case, this happened because two IP addresses/host names had
been issued (and aliased) for my machine(s) in my domain on two
different servers. I could tell from our testbed that my client was
sending and receiving UDP packets, but was still not able to connect.

Last Friday, Rich Kennerly called me up on the phone and we tried a few
tests. It turned out that we could video teleconference in
point-to-point mode. We could also confer when using the old reflector
software. However, I could not establish a conference with him using
the new reflector. Rich then analyzed the packets and found that they
had two different IP addresses in them. One apparently came from my
machine and the other from the DNS. Obviously one IP address is needed
in order for packets to find their way back to the user. IP addresses
are also used to keep separate windows open for each user.
Unfortunately these two functions are using two different methods of
getting the address. As a result the reflector is recieving packets
from one IP address and sending them back to another.

There have been several other users experiencing these symptoms but we
have been attributing them to other causes. For instance, the user who
suspected that the international Internet link was suddenly blocking
UDP packets may have simply been experiencing this problem as a result
of the reflector site being upgraded.

Another user has been able to get CU-SeeMe to work from the office
(where the system has been set up as a SLIP server) but been unable to
get Cu-SeeMe to work from home via that server.

In all of these cases (including my own) the users were inadvertently
spoofing the IP address. In my own case, I was able to remedy the
situation by having the DNS entry fixed. With the SLIP server, and
others, the solution may not be so easily implemented. I am sure the
hard working staff at Cornell will have this fixed in the next
reflector release.

Many thanks to Rich Kennedy and others for helping me to get Cu-SeeMe
working.

We will be leaving the test server up for the forseeable future. So,
if you are a Windows user and cannot get a connection, try the testbed
at 140.90.24.87. If your client is working properly you will see your
own name appear in the status menu (because the test server bounces
your own UDP packet back to you). If you do not see this then e-mail
me, I will check to see if we received your packet (to check your
ability to transmit).

If you were able to see your name bounced back from the test server,
but still cannot connect to a reflector site, find someone on this list
who has a camera and try a point-to-point connection. Your client
software should work point-to-point. If your system cannot work
point-to-point, but has passed the previous tests then perhaps your
client software is defective. If reinstallation does not solve the
problem, then alert this list because there may be a problem in the
software.

I hope this helps. Best Regards,

Patrick T. Stingley
(301) 713-0882 x104
stingley@apwk01g1.nws.noaa.gov