Not true. The ICMP port unreachable message relates to whether and
application is accepting connections or not from the port. A TCP RST is
sent when an non SYN message is received for a non-existent TCP
connection on the receiving system. Two different situations in the TCP
finite state machine. Refer to the TCP RFC for details. The initial
SYN which is transmitted by this application says I want to make a new
connection. The connection is not yet established and therefore the TCP
RST can not possibly be sent. The TCP RST is only sent when a
non-initial SYN has been sent but the receiveing system does not have an
already open connection which should not occur in this situation. This
usually occurs when a pre-existing connection tries to communicate with
a system which for some reason has dropped the connection (application
failure or system restart).
Harold Grovesteen, CCNP
Holger Kruse wrote:
> On Tue, Apr 10, 2001 at 06:15:04AM -0500, Harold Grovesteen wrote:
>
>> What you are attempting to do is open a TCP connection with a host on a
>> specific port. The open request is initiated by the application
>> (REBOL). Your TCP stack on your system actually handles the three way
>> handshake to open the connection. Without an "open" timeout in the
>> application, how long it takes for the open request to return to REBOL
>> depends upon how the remote host responds (assuming the host is there)
>> and timeout settings in the TCP stack. Some hosts will respond with an
>> ICMP message indicating the port is not available and that should be
>> very quick.
>
>
> Actually the returned message in that case is not an ICMP message but
> a TCP RST packet. ICMP is only returned for unavailable UDP (not TCP)
> ports or routing problems in the network.
>
> EVERY host is supposed to return TCP RST for unavailable ports, and
> AFAIK every one does. You may still not receive it though if there is
> a misconfigured firewall along the way that filters out TCP RSTs.
> Some "consumer firewalls" unfortunately do that.
>
> Regardless, if you are using Windows then the TCP RST may not help you
> time out quickly, because most versions of Windows ignore incoming TCP RSTs
> in most cases. (Don't ask why. This has to do with an ancient Windows
> bug that sometimes caused invalid, forged TCP RSTs to be processed
> by Windows, opening up a security hole, then in their "infinite wisdom"
> Microsoft "fixed" the bug by just ignoring TCP RSTs all the time. Sigh...)
> Other platforms do not have that problem though. That bug is the main
> reason why most port scanners have their own timeouts.
>
>
>> Others may ignore the request in which case the TCP stack
>> timeout controls how long it will take to complete.
>
>
> The real problem is that some client TCP/IP stacks ignore the TCP RST,
> and that's when the application timeout takes over.
>
>
>> There are also other ICMP messages the network may return which should
>> terminate the open request. If REBOL passes these status messages back,
>> assuming the TCP stack provides the reason for the failure to REBOL, you
>> may want to look at the error to decide what to do.
>
>
> ICMP errors are handled internally within the TCP stack and typically lead
> to errors at the socket level, which then trigger an error in REBOL. At the
> moment there is no way to check the specific error code. This is for a future
> version, through the get-modes API.
>
>
>> For example if the
>> destination host is not available you don't need to go through a bunch
>> of connection attempts, because none of them will succeed.
>
>
> Yes, except that "host not available" is rare and if it occurs it is
> usually transient, during a switch in dynamic routing.
>
>
>> And hopefully you are doing this program for a noble purpose. Internet
>> security people consider this type of program an indication of an
>> attempt to breach security--a hacker attack in progress.
>
>
> Yes. To make it very clear: depending on circumstances port-scanning
> machines for which you are not administratively responsible can be a
> criminal offense, and if prosecuted you may be sent to prison for it.
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.
