home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
CD Loisirs 26
/
CDL26.iso
/
PLANETPC
/
WIN311
/
ELEMENTS
/
CUSEEME
/
FAQ.TXT
< prev
next >
Wrap
Text File
|
1995-05-30
|
8KB
|
155 lines
CU-SeeMe for Windows Frequently Asked Questions:
Here are a couple of FAQ questions and answers for Windows. We'll be
adding to this soon.
* Hostname Requirement for Windows CU-SeeMe
* WSAAsyncSelect blew chow (11004)!
* "No Response from <ip address>" error.
* Video Blaster ??-??? is not detected by CU-SeeMe
---------------------------------------------------------------------------
Hostname Requirement for Windows CU-SeeMe
Your Windows machine will need a hostname. CU-SeeMe for Windows
will not work without it (this requirement may disappear soon).
The way to provide a hostname is to make an entry into the hosts file
called "hosts" (with no extension):
The format for the hosts file is:
<your IP address> <name for your PC>
For example, you might decide to use the hostname WillieBob. If
your IP address was 128.32.64.88, the entry in your hosts file would
look like:
128.32.64.88 WillieBob
Your HOSTS file should be in your Windows Sockets directory (the
same directory that contains your 'winsock.dll'). This directory must
be in the PATH before windows is started. Note: the HOSTS file needs
to be accessed by the Winsock stack, not CU-SeeMe - putting the HOSTS
file in the directory with CU-SeeMe will not accomplish anything.
If you don't already have a hostname for your PC, you may want to
contact your network administrator about getting one assigned. If your
host name is defined in a Domain Name Server (DNS) accessible to your
PC, you won't need to have a HOSTS file. Keep in mind, in this case,
that if you can't reach your DNS, you'll get the "GetHostByName() Error"
message.
While this issue has been a problem for many it has worked on all
stacks after some work (The FTP software hitch mentioned below took
many phone calls to a very patient user at NSF before solving).
Things to verify:
*) Verify that you've only got one HOSTS file (there might be a bad one
earlier in your path). Use FILE MANAGER, File Menu, Search - Search
for hosts, start from c:\, check the 'Search All Subdirectories box.
If you find entries other than the one you expect to find in your
Winsock directory, consider removing or updating them.
Possible stumbling blocks:
*) You're using FTP PCTCP and you've something set in the "Domain
Completion" box. This can cause your software to not find its real
hostname in the hosts file.
*) When Defining your hostname with your Winsock Customization software,
do not include the domain name in the hostname specification. For
example, if WillieBob is in the domain cit.cornell.edu, do NOT specify
WillieBob.cit.cornell.edu as the hostname. Just enter WillieBob and
enter the domain in its place.
---------------------------------------------------------------------------
WSAAsyncSelect blew chow (11004)!
Some Winsock stacks, especially Lan WorkPlace for Dos, often report
this error. The error 11004 means that your winsock stack either does
not support UDP or is not set up to do so. Check the configuration
options for your network installation to make sure UDP is enabled if
possible. Unfortunately, we're not sure what to do in many cases and
we don't know why some LWP users work OK and some do not.
---------------------------------------------------------------------------
"No Response from <ip address>" error.
Assuming that you have tested other winsock network applications so you
know you have basic network connectivity, there are several possible reasons
why you might be getting this response:
* The reflector machine is down - Try to telnet, FTP, or PING the host
address to check this. Even if you can't log in, any 'login' -type response
will indicate that the host is on the net.
* The reflector software is not currently running on the reflector host. Try
a couple of reflector sites - it is not likely that too many will be down at
the same time.
* You have a 'firewall' somewhere at 'your end' - between your local network
and the Internet. A firewall prevents traffic of certain types from
passing in and out of a network or networks. For example, a 'firewall'
may exist to reduce traffic volume by disallowing UDP packets - this will
prevent PING and NFS (Network File System) packets from passing through.
And, since CU-SeeMe uses UDP, it will not work either. It is also possible
for a firewall to disallow certain UDP port and allow others. Your network
provider can decide what type(s) of 'firewall' restrictions if any to
impose on your network.
It can be difficult to determine whether or not there is a firewall in
place on your network. If you can telnet to a reflector host (even though
you can't log on) but CU-SeeMe doesn't work then it could be a firewall.
You can contact your network provider to see if there are any restrictions
on the traffic passing in and out of your network. CU-SeeMe uses UDP
(not TCP) on UDP port 7648. You can ask your network provider to allow
UDP traffic on port 7648 to get through the 'firewall'.
Or, if you're using a PC with Winsock, it could be:
* There is a DNS IP address problem or 'proxy' DNS is being done. Somehow,
with Winsock, it is possible for the machine to make a DNS query to the
network for its own address which is not really the actual address of the
Windows PC. CU-SeeMe uses this address in the CU-SeeMe packet header which
is different from the address in the IP header (apparently). This can be
caused by having two DNS servers with different IP addresses or, by a
machine doing 'proxy' DNS where it claims to be 'you' so it will get
your packets which it will then forward to you. This latter example has
been found in a situation where SLIP IP addresses were being 'spoken for'
by the slip server. Unfortunately, we don't have good information about
what can be done to really solve this problem. I would recommend having
your host and actual IP address in a HOSTS file locally so the DNS call
is either not made or not favored over the local hosts entry.
* You're using TIA. Here's a quote from a knowledgable user:
"TIA will not work with CU-See me because CU-SeeMe needs an IP address of the
machine you are connecting with. TIA does not give you machine an IP address
but gives you the IP address of the machine you are connecting to, so instead
of trying to connect back to your machine CU-SeeMe is connecting back to your
providers machine (the machine that you are running tia on). In order for
CU-SeeMe to work you need a PPP or SLIP account where you have your own
individual IP address."
---------------------------------------------------------------------------
Video Blaster ??-??? is not detected by CU-SeeMe
Sometimes a Creative Labs Video Blaster can be installed in the system
and the Video Capture program supplied by Creative Labs works fine. But,
CU-SeeMe does not generate a local video picture and the 'File-Video Devices'
option is greyed out.
Edit your system.ini file in the /windows directory and, in the [drivers]
section, make sure there's an entry for msvideo=. For example, one use with
a blaster FS200 has the entry:
msvideo=fs200cap.drv
in system.ini. Check your installation guide to see what it should be for
your model. This entry is needed for software to locate the driver; apparently
the Creative labs software itself does not require this.