[TCPIP V5.4] Session Disconnects (and DISCONNECT)

[TCPIP V5.4] Session Disconnects (and DISCONNECT)

Post by pete » Sat, 21 Feb 2004 08:25:19


I seem to have problems with the use of (service) alias addresses (which
I do with IFCONFIG). When I delete the alias address(es) the sessions
(eg. DECnet over IP) don't get terminated.

1) Is there a chance that UCX at some time will do this right ?
eg. do you have an idea what parameters to try (besides how to do
keepalive for DECnet over IP)

2) I can do an DISCONNECT DEVICE_SOCKET for the remaining sessions, but
unfortunately TCPware has an /LOCAL and /REMOTE qualifier for KILL CONNECTIONS
but TCPIP has not not. Is there any chance that UCX will narrow this gap
(which exists now for a decade) in the very near future ? Otherwise I will
have to write a DCL script instead of using one simple TCPIP command...

3) Is there a chance that a lexical function (F$GETDVI comes to mind) will
(in the very near future) give me IP information (like the local IP address
and/or port number) on BG devices ? Otherwise I will have to parse output
files (written by CRTL).

Any hope ?

--
Peter "EPLAN" LANGSTOEGER
Network and OpenVMS system specialist
E-mail XXXX@XXXXX.COM
A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist
 
 
 

[TCPIP V5.4] Session Disconnects (and DISCONNECT)

Post by Matt Mugge » Sat, 21 Feb 2004 09:18:12

>When I delete the alias address(es) the sessions

That is a good thing. Protocol modularity and all that.


I'm not sure what your expectations are. Using "tcpip disconnect" seems the
right approach. Your 3rd point suggests you would like to see this enhanced
to accept /LOCAL and /REMOTE qualifiers for the port number.


Sorry to say that I haven't seen this request on our recent requirements
list. However, I will forward it along. But before I do, is there more to
it than:

tcpip disco dev /LOCAL=<local port number> /REMOTE=<remote port number>

Of course, like all work, this will be prioritised accordingly. You can
check in periodically to see where it is up to. If you need our product
manager's email address, drop me a line.


That will have to be your solution in the near term.

address

In the very near future... no. If you can email me your requirement (the
more detail the better) it will be added to our requirements list and
reviewed during the next cycle.


There is always hope. Keep smiling. :-)

Matt.

--
-------------------------------------------------------------
OpenVMS TCP/IP Engineering
Enterprise Computing Group
Hewlett-Packard Company
Gold Coast, AUSTRALIA
-------------------------------------------------------------




CONNECTIONS
address

 
 
 

[TCPIP V5.4] Session Disconnects (and DISCONNECT)

Post by Matt Mugge » Sat, 21 Feb 2004 10:07:39

Oh, I should have also mentioned this command, in case it meets your
immediate needs:

$ ifconfig ie0 10.10.10.10 abort

This will abort all connections to the 10.10.10.10 address on interface ie0.

Matt.


--
-------------------------------------------------------------
OpenVMS TCP/IP Engineering
Enterprise Computing Group
Hewlett-Packard Company
Gold Coast, AUSTRALIA
-------------------------------------------------------------




CONNECTIONS
address
 
 
 

[TCPIP V5.4] Session Disconnects (and DISCONNECT)

Post by JF Meze » Sat, 21 Feb 2004 10:08:10


I would second this request. Being able to easily get information about where
a BG device is coming from and going to would be very good.

When you're under attack, you want tools that get you the iformation ASAP to
track hackers.

Another suggestion I would make is some sort of hook to have a process
notified whenever that node makes an outgoing call which fails to connect. (so
that we can trigger fault isolation in the network.
 
 
 

[TCPIP V5.4] Session Disconnects (and DISCONNECT)

Post by Matt Mugge » Sat, 21 Feb 2004 10:17:21

Without trying to hijack this thread too much...

(so

I see this as a separate system administration function. Failure to connect
somewhere usually results in the user realising they specified the wrong
nodename, or a call to the network administrator because they checked their
typing and still can't connect. In my mind, that seems more than
sufficient. Why have a process automatically notified anytime a connect
fails? It seems the process would have to include responses like: "oops
you mistyped the remote nodename again..."

If you want reachability confirmation to specific/important end-points, then
a separate process to monitor that would be in order.

Matt.

--
-------------------------------------------------------------
OpenVMS TCP/IP Engineering
Enterprise Computing Group
Hewlett-Packard Company
Gold Coast, AUSTRALIA
-------------------------------------------------------------





will
(the
where
to
(so
 
 
 

[TCPIP V5.4] Session Disconnects (and DISCONNECT)

Post by pete » Sun, 22 Feb 2004 08:16:21

In article <8ncZb.67244$ XXXX@XXXXX.COM >, "Matt Muggeridge" < XXXX@XXXXX.COM > writes:

I disagree. The address is gone, the sessions should too.


Yes. But I want both.
A DISCONNECT is the 2nd choice. 1st is the automatic session termination.


Is this list done by user requests only ?
Or does some marketing guy occassionally look on competing products, too ?
I surely discussed it on more than one occasion (but didn't submit an SPR).
(And I still have the impression that PSC did add KILL CONNECTION on my own
request way back in the very early nineties)


Thanks a lot.


/LOCAL=<local-ia|*>.<local-port|*>
/REMOTE=<remote-ia|*>.<remote-port|*>


Dropped ;-)
Does he accept hobbyists, too ?


And this is a problem I'm afraid off.

eg. There is a difference between BG devices and sockets. F$DEVICE ("_BG*:")
So even getting a list of sockets is parsing output in files. Shudder.



Many Thanks.
I think the requirements should and will grow here in the news group...


I already do. Such a fast answer. And from the right person. Wonderful...

--
Peter "EPLAN" LANGSTOEGER
Network and OpenVMS system specialist
E-mail XXXX@XXXXX.COM
A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist
 
 
 

[TCPIP V5.4] Session Disconnects (and DISCONNECT)

Post by pete » Sun, 22 Feb 2004 09:00:05

In article <v5dZb.67309$ XXXX@XXXXX.COM >, "Matt Muggeridge" < XXXX@XXXXX.COM > writes:

It does indeed meet my immediate needs (if it works of course).
But the enhancements to DISCONNECT are still on my wish list (greater
flexibility) and if they are there, then this abort becomes obsolete.

btw Where is this documented ? I didn't find it so far.
If not, is it supported already (and only documentation missing) ?
Did it already exist in TCPIP V5.3 (ECO ?) ?


Now to my first tries:

--------------------------------------------------------------------------------
$ ucx ifconfig we0 alias 1.2.3.4
$ ucx ifconfig -a
LO0: flags=100c89<UP,LOOPBACK,NOARP,MULTICAST,SIMPLEX,NOCHECKSUM>
inet 127.0.0.1 netmask ff000000 ipmtu 4096

TN0: flags=80<NOARP>

TN1: flags=80<NOARP>

WE0: flags=8000c63<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST,SIMPLEX>
inet 1.2.3.4 netmask ff000000 broadcast 1.255.255.255 ipmtu 1500
inet 192.168.50.81 netmask ffffff00 broadcast 192.168.50.255 ipmtu 1500

$ ucx ifconfig we0 1.2.3.4 abort
1.2.3.4: aborting 53 tcp connection(s)
--------------------------------------------------------------------------------
53 connections ? There wasn't even one existing yet.
OTOH no connection was disconnected and so it is only a cosmetical problem.
--------------------------------------------------------------------------------
$ ucx ifconfig -a
LO0: flags=100c89<UP,LOOPBACK,NOARP,MULTICAST,SIMPLEX,NOCHECKSUM>
inet 127.0.0.1 netmask ff000000 ipmtu 4096

TN0: flags=80<NOARP>

TN1: flags=80<NOARP>

WE0: flags=8000c63<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST,SIMPLEX>
*inet 1.2.3.4 netmask ff000000 broadcast 1.255.255.255 ipmtu 1500
inet 192.168.50.81 netmask ffffff00 broadcast 192.168.50.255 ipmtu 1500

$ ucx ifconfig we0 -alias 1.2.3.4
--------------------------------------------------------------------------------
What does the asterisk indicate. A pending ABORT ?

And now with a connection (to itself via this address) again:
--------------------------------------------------------------------------------
$ ucx ifconfig we0 1.2.3.4 abort
Unexpected error in status, deleting TCB (QIO).
Possibly in TIME_WAIT state of 120 seconds for BG device: 0.
Unable to abort connections for address 1.2.3.4:
--------------------------------------------------------------------------------
OTOH after the 120 seconds passed, this message came and the session aborted.


Means, there is room for improvement but so far seems usable. Thanks for this.

--
Peter "EPLAN" LANGSTOEGER
Network and OpenVMS system specialist
E-mail XXXX@XXXXX.COM
A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist
 
 
 

[TCPIP V5.4] Session Disconnects (and DISCONNECT)

Post by Matt Mugge » Tue, 24 Feb 2004 11:50:48

ou are right, it doesn't appear in our documentation... and subsequently is
not officially supported. I will also be adding this to our requirements.
I tend to use the 'abort' command from time to time, but from your
demonstration, it clearly needs a little more work.


That is an indication that the address is considered "at home" on that
interface. This is important for failSAFE, whereupon an interface recovers,
it requests that its 'children' also return home.

Matt.

--
-------------------------------------------------------------
OpenVMS TCP/IP Engineering
Enterprise Computing Group
Hewlett-Packard Company
Gold Coast, AUSTRALIA
-------------------------------------------------------------


"Peter 'EPLAN' LANGSTOEGER" < XXXX@XXXXX.COM > wrote in message
news:newscache$akqeth$ak32$ XXXX@XXXXX.COM ...
Muggeridge" < XXXX@XXXXX.COM > writes:
ie0.
------
1500
------
problem.
------
1500
------
------
------
aborted.
this.


 
 
 

[TCPIP V5.4] Session Disconnects (and DISCONNECT)

Post by Matt Mugge » Tue, 24 Feb 2004 12:33:21

gt; I disagree. The address is gone, the sessions should too.

OK. I won't try to force you over to my side of the fence :-). I will say
that there are many cool features we have been able to implement because of
this level of modularity. The most recent example being failSAFE IP, where
connections can be maintained as the IP address is reconfigured on a
different interface on the same node.


Yep. I've collected and pass on many requirements from this newsgroup.
Though, during more demanding times, I don't get to scan the newsgroup as
much as I would like. If it is really important to you, then the best way
is to use the official channels via VMS product management.


We look at the competing products and user requests. Though, it doesn't
make a lot of sense to emulate behaviour in a competing product if the user
demand does not exist to back it up. Even with the user demand, we still
need to prioritise and allocate the work.

BTW, the TCPIP DISCO requirement is now in the hands of our PM. It will be
reviewed during the next pass.

Cheers,
Matt.

--
-------------------------------------------------------------
OpenVMS TCP/IP Engineering
Enterprise Computing Group
Hewlett-Packard Company
Gold Coast, AUSTRALIA
-------------------------------------------------------------


"Peter 'EPLAN' LANGSTOEGER" < XXXX@XXXXX.COM > wrote in message
news:newscache$ejoeth$3g32$ XXXX@XXXXX.COM ...
Muggeridge" < XXXX@XXXXX.COM > writes:
the
enhanced
SPR).
own
to
number>
("_BG*:")
will
address
output