Re: CU-Seeme problems

Jesus Arango (
Mon, 13 Feb 1995 18:37:33 -0500

I already solved this problem, CU-SeeMe can work with SLIP and a
non-permanent IP address. I am running trumpet winsock and what I did is
the following:

I dial into the SLIP server at my university, as soon as I connect and know
which IP address was assigned to me, I go on and modify the host file and
add an entry for my machine with that address.

Hope this helps. If you have any doubts I'd be glad to help


On Mon, 13 Feb 1995, gordon whelpley wrote:

> I am also getting these errors when everything else (video, software, etc.)
> seem to be work. The errors continue untill I am "timed out". As I am
> using a dialup SLIP connection, I asked my provider about a permanent IP
> address (vs. random). As it turns out, that for a small fee they will
> provide me with one. The question is then; Will a permanent IP address
> solve this problem? Any opinions or direct experience? GW
> At 08:01 PM 2/9/95 -0500, wrote:
> >> The most recent version of the reflector software does not work with
> >> your set-up. The reason is that when SLIP sends a UDP packet, the
> >> packet contains the address of your SLIP client. The reflector,
> >> instead of reading this address from your packet, does a DNS lookup for
> >> your IP address (which of course is different since you are using SLIP
> >> and have essentially circumvented the normal domain name service.)
> >> Thus, the packets are probably arriving at the reflector, but the
> >> return packets from the reflector are going to a bogus address.
> >
> >For the record, this is not exactly correct. To quote from a posting of
> >several days ago:
> >
> >Each CU-SeeMe packet contains the (apparent) IP address of the machine on
> >which it originated (CU-SeeMe trying to find its own IP address is the
> >source of the dreaded "GetHost" error that Windows folks experience). This
> >is not intended to be used for network addressing, but just as a unique ID,
> >e.g., to identify which window a video packet belongs to. Currently, the
> >reflector software compares this supposed IP address with the actual source
> >IP address (from the IP header) and rejects the packet if they don't match.
> > I'm not sure why it does that; I think it was a quick fix to some problem
> >we observed. In any case, anyone who is in a situation where the IP
> >address that your machine thinks it has is different from the actual IP
> >source of the packet that reaches the reflector will not be able to connect
> >to a reflector.
> >
> >
> >It doesn't have anything to do with DNS, but with packets arriving from an
> >IP address that is different from the IP address where they originated
> >(where the "originating IP" is whatever the TCP/IP stack tells CU-SeeMe).
> >At least I'm pretty sure that's what's going on.
> >
> >-Tim
> >__________________________________________________________________
> >Tim Dorcey
> >Sr. Programmer/Analyst (607) 255-5715
> >Advanced Technologies & Planning
> >CIT Network Resources
> >Cornell University
> >Ithaca, NY 14850
> >__________________________________________________________________
> >
> >
> >
> >

______ ||
Jesus Arango e-mail:
Adress: Calle 5F #301-101 Apto. 503
Medellin, Colombia
Tel: 311-9158
Phrase of the day:

"You know what you are....PUNK! You're dog shit. A lot of bad things can
happen to dog shit on the street. It can get stepped on and squashed, it
can get scooped up and thrown out, or it can dry up and blow away in the
-Clint Eastwood