HP3000-L Archives

February 2010, Week 3

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Keven Miller <[log in to unmask]>
Reply To:
Keven Miller <[log in to unmask]>
Date:
Tue, 16 Feb 2010 13:44:35 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (36 lines)
>Would that happen to a blocked IP in INETDSEC?
>
>Let me think:
>
>1) An inbound Telnet packet hits the HP.  
>2) INETDSEC is configured to block that IP.
>3) JINETD says I'm not going to return a colon prompt.
>

One feature that I thought was nice in NetIPC,
but not found with BSD sockets (as far as I've tried/looked),
is with IPCCONTROL, you can set up the scenario
where IPCRECVCN returns with the incoming 
new connection -- you can get the incoming IP.

But the connection is not complete. 
With IPCCONTROL you can pass a
REJECT or an ACCEPT code.

If you do an ACCEPT, it acts like the BSD accept() call
and the user gets connected.
But if you do REJECT, the user gets a connection error,
NOT connection reset by peer. 
(I don't recall the error, maybe
 239 connection refused, or 238 connection timed out)

With BSD, when you do an accept() to get the connection
and IP, you can close the socket, but the user gets
the error connection reset by peer (232).

i.e.. NetIPC allows it to look like they never had a connection.
Keven

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2