Re: "Phantom" connections

Jason Williams (
Fri, 10 Jul 1998 19:35:15 -0500 (CDT)

On Fri, 10 Jul 1998 wrote:
> Who can explain the "phantom" connection? We've all seen one, probably
> even been one: A nickname will pop into the participant list and athe
> window will open but no data will appear and all the connector's rates
> remain at zero. To the person trying to connect it appears as if the ref
> is not answering.

Whenever I've seen this happen, it's usually due to a hung UDP port
(7648). You can easily reproduce this by connecting to a reflector with
any version of CU, then picking up your phone and dropping the connection.
Then redial in and try to connect somewhere. You won't be able to connect
anywhere due to the hung port.

More easily, after you redial in, quit CU and go to a DOS window. do a
"netstat -a" and you'll see UDP port 7648 still active. So far, I haven't
been able to find any way around this except rebooting. It'd be nice to
have an application that would clear the ports somehow. Unlike TCP ports
which would eventually timeout (unless they're in the FIN_WAIT_2 state or
something), UDP ports don't timeout. I have yet to determine if the
problem still exists in Win98.

> Usually a reboot will solve it, so you would be inclined to say some
> portion of your local client went out to lunch, but you can also
> usually still connect to other refs, so what is happening between the
> client and the ref?

Whenever the UDP port hang problem happens, you can't connect to ANY maybe something different is happening to you. I do know
that the Win95/NT WP 2.0.X/2.1 reflectors can hang on connects to TCP port
7648 for CU 3.X clients.

> When this happens to me, RefMarshall will show my nick as being
> connected but the my client either says nothing or unable to connect.
> Yet I can still connect to other refs.

Sounds like a hold down time is in effect for some reason. Enhanced
Reflectors don't seem to hold down the time after a kill/deny or repeat
connections. With White Pine 2.1/3.X reflectors, there's a hold down time
to prevent people from constantly trying connections over and over as fast
as they can. If you just tried to connect and got a full message (or
another error), it will prevent any conections from your IP for a minute
or so. If you try to connect immediately, the client may timeout first.

The real trick is getting to the reflector logs and monitoring them while
you try to connect. Most of the time when I've seen it happen, the
reflector reports "invalid protocol mismatch" or something similar which
means (I'm guessing) that the port is bound to a different address than
the UDP packet headers report.

> Doesn't seem to matter whether I am running Cornell or WP clients. It's
> as if a temporary "deny" has been entered for my IP and yet I do not get
> the deny error message when trying to connect. Experts? -RedDawg

Temp denies do exist for kills, whenever you reach a timelimit,
that could be it too.

> Re: My previous post. Could this be related to the Alt-J thing, i.e.,
> could some undocumented keystroke enable the connection when this
> happens?

If it's at the reflector end, then I doubt any key combination will allow
you to bypass a temp deny.

--    * Jason Williams -- Austin, Tx.  |     |       * University of Texas at Austin  | ___ |         * BS Computer Science             \_|_/
*************** **************|