The release of this tool to the public domain has been requested and authorised by sncf tpf systems management.
The full code and documentation is available at https://bitbucket.org/iansw/public/src/master/IP%20Probe/
Background:
Whilst the use of telnet as a terminal emulator for remote systems is, baring a small number of niche cases, all but obsolete, it remains useful on many platforms as a quick and easy way to test tcp/ip connectivity to a remote address and port where nmap might be overkill, not installed, or otherwise unavailable. z/tpf does not provide such a facility. IP Probe fulfils this requirement.
Design objectives
Unlike most programs, IP Probe is designed to expose its inner workings specifically to identify any point of failure and the reason for that. Thus, its output is somewhat verbose, for example:
IP Probe Utility Version: 1.0; built: Jun 7 2023 11:15:52
Creating TCP socket...
...Created socket 12582949
Setting receive/connect timeout of 10 seconds on socket 12582949...
...Options set, rc = 0
Connecting socket 12582949 to 10.27.186.207:21...
...Connected TCP socket, rc = 0
Sending on socket 12582949 (15 bytes): EtoA(Metatron speaks)...
...Sent 15 bytes
Receiving on socket 12582949...
...Received 42 bytes: 220 TPF FTP server (Version 1.02) ready.
Setting receive/connect timeout of 1 seconds on socket 12582949...
...Options set, rc = 0
Receiving on socket 12582949...
...Receive timeout: no data received
Closing TCP socket 12582949...
...Closed TCP socket, rc = 0
Test finished.
The sequence of events is:
1. Create a TCP socket.
2. Set a primary timeout period to be used for both the initial connection and the receipt of the first response datagram.
3. Attempt to connect to target, wait for connection to be established.
4. Send some data.
5. Attempt to receive a datagram. We’re not overly bothered by its contents. Indeed the data we send is likely to be rejected by most servers so this operation will oftentimes fail.
6. In case any datagram sent to us has been fragmented, or more than one was sent, we’re going to issue another receive. But we don’t want to wait for a long time so set a short secondary timeout period.
7. Now issue the secondary receive.
8. On receiving a timeout or an error from the secondary receive close the socket and terminate the connection.
Usage
The utility itself provides full help text:
> zuipp --help
zuipp [-hV] [--version] [-d <string>] [-1 <positive integer>]
[-2 <positive integer>] IP_Address TCP_Port
Where:
-d <string>, --data <string>
The message data to send.
-1 <positive integer>, --timeout1 <positive integer>
Timeout for connect and first receive.
-2 <positive integer>, --timeout2 <positive integer>
Timeout for subsequent receives.
-V, --verbose (accepted multiple times)
Show some additional diagnostics
--, --ignore_rest
Ignores the rest of the labeled arguments following this flag.
--version
Displays version information and exits.
-h, --help
Displays usage information and exits.
IP_Address <string>
(required) Target IP Address to probe.
TCP_Port <positive integer.
(required) Target TCP Port to probe.
This is a telnet-style IP probe utility to test connectivity to a
specific IP address and port.
There are open source tools that can be used to validate the IP/PORT combination and network connectivity. Therefore, the priority of implementing this in TPF is low.