pouriyajamshidi/tcping

Ping TCP ports using tcping. Inspired by Linux's ping utility. Written in Go

TCPING

A cross-platform ping program for TCP ports inspired by the Linux's ping utility. This program will send TCP probes to an IP address or a hostname specified by you and prints the results. It supports both IPv4 and IPv6.

TCPING uses different TCP sequence numbering for successful and unsuccessful probes, so that when you look at the results and spot a failed probe, inferring the total packet drops to that point would be easy.

Here are some of the features of TCPING:

• An alternative to ping in environments that ICMP is blocked.
• Monitor your network connection.
• Determine packet loss.
• Analyze the network's latency.
• Calculate minimum, average and maximum latency of network probes.
• Print connection statistics by pressing the Enter key, without stopping the program.
• Retry hostname resolution after a predetermined number of probe failures by using the -r flag . Suitable to test your DNS load balancing or Global Server Load Balancer (GSLB).
• Enforce using IPv4 or IPv6.
• Display the longest encountered downtime and uptime duration and time.
• Monitor and audit your peers network (SLA).
• Calculate the total uptime or downtime of your network when conducting a maintenance.

---

Table of Contents

• TCPING
  • Table of Contents
  • Demos
    • Basic usage
    • Retry hostname lookup (-r) flag
    • JSON output (-j --pretty) flag
  • Download
  • Usage
    • Linux - Debian and Ubuntu
    • Linux, BSD and mac OS
    • Windows
    • Docker
  • Flags
  • Tips
  • Check for Updates
  • Contributing
  • Feature Requests and Issues
  • Tested on
  • Help The Project
  • License

---

Demos

Basic usage

---

Retry hostname lookup (-r) flag

---

JSON output (-j --pretty) flag

---

Download

• Windows

• Linux - Also available through brew and .deb package

• macOS - Also available through brew

• macOS M1 - ARM - Also available through brew

• FreeBSD

When the download is complete, head to the usage section.

Alternatively, you can:

• Use the Docker images:

  docker pull pouriyajamshidi/tcping:latest

  Image is also available on GitHub container registry:

  docker pull ghcr.io/pouriyajamshidi/tcping:latest

• Install using go install:

  go install github.com/pouriyajamshidi/tcping@latest

• Install using brew:

  brew install pouriyajamshidi/tap/tcping

• Or compile the code yourself by running the make command in the tcping directory:

  make build

  This will give you a compressed file with executables for all the supported operating systems inside the executables folder.

---

Usage

Follow the instructions below for your operating system:

• Linux - Debian and Ubuntu
• Linux, BSD and macOS
• Windows
• Docker images

Also check the available flags here.

Linux - Debian and Ubuntu

On Debian and its flavors such as Ubuntu, download the .deb package:

wget https://github.com/pouriyajamshidi/tcping/releases/latest/download/tcping_amd64.deb -O /tmp/tcping.deb

And install it:

sudo apt install -y /tmp/tcping.deb

If you are using different Linux distros, proceed to this section.

Linux, BSD and mac OS

Extract the file:

tar -xvf tcping_Linux.tar.gz
#
# Or on Mac OS
#
tar -xvf tcping_MacOS.tar.gz
#
# on Mac OS ARM
#
tar -xvf tcping_MacOS_ARM.tar.gz
#
# on BSD
#
tar -xvf tcping_FreeBSD.tar.gz

Make the file executable:

chmod +x tcping

Copy the executable to your system PATH like /usr/local/bin/:

sudo cp tcping /usr/local/bin/

Run it like:

tcping www.example.com 443
# Or
tcping 10.10.10.1 22

Windows

We recommend Windows Terminal for the best experience and proper colorization.

Copy tcping.exe to your system PATH like C:\Windows\System32 and run it like:

tcping www.example.com 443
# Or provide the -r flag to
# enable name resolution retries after a certain number of failures:
tcping www.example.com 443 -r 10

TCPING might falsely get flagged by Windows Defender or some anti-malware software. This is common among Go programs. Check out the official documentation from Go here.

Docker

The Docker image can be used like:

# Using Docker Hub
docker run -it pouriyajamshidi/tcping:latest example.com 443

# Using GitHub container registry:
docker run -it ghcr.io/pouriyajamshidi/tcping:latest example.com 443

---

Flags

The following flags are available to control the behavior of application:

Flag	Description
-4	Only use IPv4 addresses
-6	Only use IPv6 addresses
-r	Retry resolving target's hostname after <n> number of failed probes. e.g. -r 10 to retry after 10 failed probes
-c	Stop after <n> probes, regardless of the result. By default, no limit will be applied
--db	Path and file name to store tcping output to sqlite database. e.g. --db /tmp/tcping.db
-t	Time to wait for a response, in seconds. Real number allowed. 0 means infinite timeout
-i	Interval between sending probes
-I	Interface name to use for sending probes
-j	Output in JSON format
--pretty	Prettify the JSON output
-v	Print version
-u	Check for updates
--show-failures-only	Only show probe failures and omit printing probe success messages

Without specifying the -4 and -6 flags, tcping will randomly select an IP address based on DNS lookups.

---

Tips

• Press the Enter key while the program is running to examine the summary of all probes without terminating the program, as shown in the demos section.

---

Check for Updates

TCPING is constantly being improved, adding numerous new features and fixing bugs. Be sure to look for updated versions.

tcping -u

Contributing

Pull requests are welcome to solve bugs, add new features and also to help with the open issues that can be found here

1. Pick any issue that you feel comfortable with.
2. Fork the repository.
3. Create a branch.
4. Commit your work.
5. Add tests if possible.
6. Run the tests go test or make test and ensure they are successful.
7. Create a pull request

Current number of open issues: .

Please make sure that your pull request only covers one specific issue/feature and doesn't handle two or more tickets. This makes it simpler for us to examine your pull request and helps keeping a clean git history.

Feature Requests and Issues

Should you need a new feature or find a bug, please feel free to open a pull request or submit an issue.

For larger features/contributions, please make sure to first communicate it on an issue before starting your work.

Tested on

Windows, Linux and macOS.

Help The Project

If tcping proves to be useful for you, consider giving it a ⭐ to extend its reach and help other people to also benefit from it.

Furthermore, you can support the project using the links below.

Buy me a coffee:

GitHub Sponsors:

Total number of sponsors:

License

tcping's Issues

Custom timeout values

Summary

Currently tcping is having a hard-coded timeout value of 1 second. Being able to change this value through a flag can be useful for some scenarios but requires a major refactoring.

DNS resolver does not account for timing

Summary

Upon specifying the -r flag, the retryResolve function is called whenever there is a need to resolve the hostname again. This can be useful when the target is geographically distributed and when there are GSLBs involved. The function is defined here:

tcping/tcping.go

Line 262 in 2464548

func retryResolve(tcpStats *stats) {

Problem

The function does not account for timing. For instance, when the internet connection is down, this function takes 4~5 seconds to timeout while nothing gets added to the respective timers here:

tcping/tcping.go

Lines 415 to 418 in 2464548

	tcpStats.totalDowntime += time.Second
	tcpStats.totalUnsuccessfulPkts += 1
	tcpStats.lastUnsuccessfulProbe = now
	tcpStats.ongoingUnsuccessfulPkts += 1

Solution

The retryResolve function needs to control and add to those timers as well.

Check for updates

Summary

TCPING is constantly being worked on and updated. Our users could benefit from these features.

We need to check for updates upon running the program and display a message if there is a newer version.

Important Notes

This should not cause tcping to get flagged as a malicious program on Windows. If we see this is the case but the benefits of checking for a newer versions exceeds the inconvenience, we might end up splitting the Windows version or to just make it an optional flag.

Fix GitHub Actions workflows

Summary

There are a few shortcomings in the current workflows and the goal of this ticket is to fix these issues:

1. Go version is not being picked up by the CI system
2. Docker images are not being tagged. This used to work before

Time report is not accurate

Summary

PR #76 helped tidying up a lot of technical debt surrounding the way we were handling timing and helped standardizing the code.

However, as a by product, for downtimes that are around a second, we are reporting the time as 0 instead of 1. Although it is a cosmetic matter, based on the discussion in the aforementioned PR, we decided to pursue those fixes in a sperate issue.

In the image below, we can see:

• No response received for 0 seconds showing 0 but should be 1
• The from to to appear to be incorrect. They have overlapping values

longest consecutive uptime:   2 seconds from 2023-05-18 22:31:43 to 2023-05-18 22:31:45
longest consecutive downtime: 1 second from 2023-05-18 22:31:43 to 2023-05-18 22:31:44

How to reproduce

run the program:

go run . fb.com 443

Cause a downtime to the destination and recover after a second:

sudo iptables -A OUTPUT -d 179.60.195.36 -j DROP; sleep 1; sudo iptables -F

Statistics is not displayed when rtt is less than 1 ms.

There are cases where rtt is less than 1ms, such as when the remote server is exists in a private network.
In this case, statistics is not displayed with enter or signal.

I feel that rttResults.hasResults should be based on whether arrLen is greater than 0, not whether accum is not equal to 0.

tcping/tcping.go

Lines 154 to 157 in 1533ad5

	if accum != 0 {
	rttResults.hasResults = true
	rttResults.average = float32(accum) / float32(arrLen)
	}

Is it okay if I fix it?

[Research] Switch to `ParseAddr` in net/ip library

Description

We are currently using ParseIP from net library to parse the IP address

tcping/tcping.go

Line 228 in 9478b2c

ipRaw := net.ParseIP(tcpStats.hostname)

Go 18 introduced ParseAddr in net/ip standard library. We need to investigate and see if it is beneficial to switch to ParseAddr instead.

If ParseAddr is not providing any additional benefits to us, we can close this ticket.

Move any output-related logic to printers (and vice-versa)

Currently, some output logic exists directly in tcping.go, like in example below

tcping/tcping.go

Lines 290 to 304 in 4032ed2

	func resolveHostname(tcpStats *stats) ipAddress {
	ip, err := netip.ParseAddr(tcpStats.hostname)
	if err == nil {
	return ip
	}
	ipAddrs, err := net.LookupIP(tcpStats.hostname)
	if err != nil && (tcpStats.totalSuccessfulProbes != 0 || tcpStats.totalUnsuccessfulProbes != 0) {
	/* Prevent exit if application has been running for a while */
	return tcpStats.ip
	} else if err != nil {
	colorRed("Failed to resolve %s\n", tcpStats.hostname)
	os.Exit(1)
	}

This is probably how it was initially, when there was only 1 printer. But now we have 2 printers, but also more could be added later, thus I think anything related to output should be handled by the printer of a user's choice.

Example: I'm using a JSON printer and some other tool to automatically parse it. As a user, I'd probably expect something like

{ "status":"error", "hostname":"example.com.123", "port": "80" }

(not the exact output, just an example)

But not

Describe the solution you'd like
Move output-related functions to printers, except for usage()

---

For discussion

Dockerize TCPING

Summary

We need to have a very lightweight Docker container hosting tcping to provide more convenience for our users.

This should account for an easy or automated way to update the container image with each new tcping release.

⚠️ Alpine Linux should not be used

-4 and -6 switch for IP protocol

Hi again 😉

Is your feature request related to a problem? Please describe.
Nope

Describe the solution you'd like
Can you add -4 and -6 switch to force IP version protocol?

Using `-r n` is not retrying exactly n times

To be honest, I was rewriting the issue a couple of times because I got a little confused, what's even considered a retry here? Red no reply ... text or yellow retrying to resolve .... It seems like the red one, I don't know if it's just me or it could also confuse others. Maybe it's working as expected, feel free to close this issue then.

Initially I assumed that the program should just os.Exit(0) after n yellow retrying to resolve ... lines, which is definitely wrong.

Describe the bug
When using -r flag, it supposed to stop execution after n retries, but it seems like it does 1 extra.

To Reproduce
Steps to reproduce the behavior:

1. Clone repo
2. make test
3. go build -o tcping tcping.go statsprinter.go (tried using the one from /executables tar, same)
4. ./tcping example.com 81 -r 3

Expected behavior
Program should output Retying to resolve after exactly n tries.

Screenshots

Screen.Recording.2023-05-08.at.12.18.19.AM.mp4

Desktop (please complete the following information):

• OS: MacOS (M1) 13.3.1
• TCPING version: 1.21.0
• Go version: 1.20.4

`-c` flag does not print `TCPing ended at` information

Describe the bug

PR #87 added the -c flag so that users can specify how many probes need to be sent before exiting the program.

Manually (ctrl+c) exiting the program displays something like:

Whereas the -c option yields:

The TCPing ended at is missing from the output when -c is used.

To Reproduce
Steps to reproduce the behavior:

Run the program with -c option:

tcping example.com 443 -c 1

Expected behavior

The TCPing ended at to be printed upon exit.

Add option to store output in a database

Summary

We need to provide an option to store the output to a database preferably, sqlite.

This will further simplify integrating it to monitoring solutions such as Prometheus and Grafana

It'd be nice to have a wiki or a small tutorial showing how this can be integrated with the aforementioned monitoring solutions.

Requirements

1. This sqlite3 package can be used to work with sqlite3 databases and store the data. I am not aware of any other ones but open to suggestions.

2. All the information that is being shown on the terminal, whether plane text or JSON (which is the same data in different formats) should be stored in a table with the name of the "target + start time" and have columns same as the terminal output. For instance check this output and pay attention to IP changes in the report as well:

   

3. The code has to go in a file called db.go

4. The flag should be -d or -db

P.S. This is a rough idea of how this should be implemented. Some requirements might change as progress is made.

Error while using TCPING

[root@master ~]# tcping
/usr/bin/tcping: line 8: syntax error near unexpected token newline' /usr/bin/tcping: line 8: '

Show longest uptime

Summary

Currently the longest downtime is shown in the reports. It could be a nice feature to show the longest uptime as well.

Wrong `longest downtime` timing information after multiple TCP connection failures

Description

Longest downtime information shows wrong timing values after multiple TCP connection failures.

Reproduce

for i in 1 5 2 1; do iptables -A OUTPUT -d 93.184.216.34 -j DROP; sleep $i && iptables -F && date; sleep $i; done

omitted output for brevity:

longest downtime: 3 seconds from 23:09:58 to 23:10:00
longest downtime: 5 seconds from 23:10:04 to 23:10:08
longest downtime: 9 seconds from 23:10:14 to 23:10:22
longest downtime: 9 seconds from 23:10:32 to 23:10:34

Windows terminal link in `README.md` is broken

Windows terminal link in README.md is probably missing https://. Right now it leads to https://github.com/pouriyajamshidi/tcping/blob/master/apps.microsoft.com/store/detail/windows-terminal/9N0DX20HK701 which is probably not intended.

Improve print statistics

Summary

Currently, the printStatistics function is a big ugly and polluted. It needs some work to make it smaller and cleaner.

A good starting point would be to address this section

tcping/tcping.go

Lines 387 to 398 in 9ab1239

	colorYellow("rtt ")
	colorGreen("min")
	colorYellow("/")
	colorCyan("avg")
	colorYellow("/")
	colorRed("max: ")
	colorGreen("%d", rttResults.fastest)
	colorYellow("/")
	colorCyan("%.2f", rttResults.average)
	colorYellow("/")
	colorRed("%d", rttResults.slowest)
	colorYellow(" ms\n")

One failed probe prints `No response received for 0 seconds`

Describe the bug
When only 1 probe is failed, it prints No response received for 0 seconds. Works fine with 2 and more probes.

(probably) not a printer bug

To Reproduce
On latest master:

1. go run . example.com 80
2. Try to fail only 1 probe

Expected behavior
No response received for 1 second

Screenshots

Additional context
As far as I know, almost all durations are hardcoded as duration += time.Second right now. My guess would be that this extra second is missing somewhere.

Show statistics even if host is 100% unreachable

• Is your feature request related to a problem? Please describe.

Hi,
is it possible to show statistics even if host has always been unreachable during tcping execution?
It could be useful to show to someone that the distant host is offline.

• Describe the solution you'd like

Showing statistics if 100% fails, maybe something like that:
TCPing statistics
15 probes transmitted, 0 received, 100.00% packet loss
successful probes: 0
unsuccessful probes: 15
last successful probe: N/A or never
last unsuccessful probe: Always or 100%
total uptime: N/A or never
total downtime: second
longest consecutive uptime: N/A or never
retried to resolve hostname <x> times
rtt min/avg/max: N/A

TCPing started at: <start time>
TCPing ended at: <end time>
duration (HH:MM:SS): <duration>

Best regards.

Error when running tcping

[root@localhost ~]# ./tcping 
./tcping: /lib64/libc.so.6: version `GLIBC_2.32' not found (required by ./tcping)
./tcping: /lib64/libc.so.6: version `GLIBC_2.34' not found (required by ./tcping)

Since version 1.19.0 started to report errors, I suspect it has something to do with the compilation parameter CGO_ENABLED

Provide a flag to check for newer versions

Summary

We need a CLI flag to check for newer versions of the program. For instance -u.

This requires having a test case too.

blocked by #14

Starting and exiting immediately prints "NaN% packet loss"

Describe the bug
Quickly exiting from the cli prints "NaN" in packet loss %

To Reproduce
Steps to reproduce the behavior:

1. Start pinging something
2. Immediately ^C

Expected behavior
Probably 0% (maybe 100%?)

Screenshots

Update demo GIFs in the README

Summary

The program has evolved and the output display has changed quite a bit. Yet, the demo GIFs in the README are demonstrating the old version of TCPING.

We need new GIFs show casing the new output similar to the current ones.

output interface

Hi,

Could you please add the possibility to define output interface ?
I am using this to monitor multiple wan links.

Thanks.

Add hostname, IP and port number in the summary output

Hi,

Is your feature request related to a problem? Please describe.
No.

Describe the solution you'd like

• Your summary statistics is a very useful, is it possible to had some more info?

For e.g. have the ip address of the host name if it was resolved and the port number

$ tcping github.com 80
...
^C
--- github.com (140.82.121.4) TCPing statistics ---
2 probes transmitted on port 80, 2 received...
...

$ tcping example.com 25
...
^C
--- example.com (2606:2800:220:1:248:1893:25c8:1946) TCPing statistics ---
4 probes transmitted on port 25, 0 received...
...

$ tcping 140.82.121.4 21
...
^C
--- 140.82.121.4 TCPing statistics ---
6 probes transmitted on port 21, 0 received...
...

• Like classic ping command is it possible to have -4 and -6 switch to force IPv4 or IPv6 protocol?

Thanks.

Increase RTT resolution/verbosity

First of all, this is a very useful tool, thank you for creating it and keeping it updated.

I'd like to ask to implement the time= resolution up to a microsecond resolution.
Currently, the report shows as follows:

What I'd love to see is the report show more verbose time, like this:

Reply from 10.180.1.248 on port 80 TCP_conn=2 time=0.253 ms

I am using the tool in a datacenter environment where the RTT times are usually sub-millisecond and if I'd be able to see such times, it would greatly expand the usefulness of tcping in DC troubleshooting / testing scenarios.

Thank you for considering this.

Retry resolving target's hostname after a certain number of failed requests

Summary

If a hostname is given, it could be beneficial to retry resolving it after a certain amount of probe failures since tcping could be used to check and analyze Anycast sites. However automatically doing this might yield undesirable results.

It could be better to introduce a flag to give users control.

Report hostname changes

Summary

We now support resolving the hostnames after a certain number of failures again, using the -r flag.

It is beneficial to report the changes and time of them to our users. For instance:

Retried to resolve hostname 2 times
IP address changed from 1.2.3.4 to 5.6.7.8     at 2022-05-29 16:30:21
IP address changed from 5.6.7.8 to 9.10.11.12  at 2022-05-29 17:50:01

Add BSD support

Add BSD support in:

• Makefile
• Release files

Add Arm64 support

Summary

With the rise of Arm chips, we should also add the binaries for those.

We need:

1. Linux Arm64
2. Apple Arm64

This should be instructed inside our Makefile.

Please make sure to test this and make sure the binaries work before submitting a PR.

Make a logo for TCPING

Summary

We are at a stage that many people are using this software yet we don't have a logo :).

If anyone has the capabilities to make one, we greatly appreciate it.

Time conversion - Minutes to hours

Summary

We have the ability to convert and print different time values to minutes for better readability.
It is nicer to implement minute to hour conversion function to make it even more readable.

fix database user input flag

Summary

PR #129 by @wizsk added support for saving reports to the database. However, it is currently not activated due to permuteArgs behavior that caused some problem when db name and path was passed by the user.

This issue intends to fix that.

v2.0.0 is not listed on Go module proxy due to missing /v2 suffix in the "module" path

Describe the bug
The most recent version v2.0.0 is not listed on the Go module proxy.

Go is very picky about versions and requires that v2.x.x versions add /v2 suffix to the "module" path in the project go.mod.

The FreeBSD ports framework (and probably others) rely on modules being listed on the Go proxy.

I've implemented a workaround for the FreeBSD port.

To Reproduce
Steps to reproduce the behavior:

1. Go to 'https://pkg.go.dev/github.com/pouriyajamshidi/tcping?tab=versions'
2. Observe that v2.0.0 is not listed

Expected behavior
v2.0.0 should be listed on the Go module proxy

• OS: OS agnostic problem
• Browser: Browser agnostic problem
• Version: v2.0.0

Credits for debugging: @dmgk

Please add "count" and "interval" option

Describe the solution you'd like
A clear and concise description of what you want to happen.
-c : ping count
-i : interval between ping requests

README Translation - Chinese

Summary

TL;DR

We need community contributors to add Chinese (Mandarin or Cantonese or both) documentation for this project.

---

TCPING has come a long way and we have a lot of users from all around the world.

This issue along some others, will ask the community for contributions to add README files in Chinese (Mandarin or Cantonese or both) to broaden the reach of the tool.

add `-c` flag to stop after n probes

Summary

Similar to the ping utility, we should also introduce the option to stop after sending n probes. For instance to stop after sending 4 probes:

tcping example.com 443 -c 4

We need to ensure that the report summary is displayed after exit.

The readme file should also be updated with the new info.

add TTL in output please

add TTL in output please

when i use native windows ping tools via icmp, I can see TTL in over response
but in tcping I don't see TTL :(

I have to use wireshark to see TTL, it makes me sad...

Add tcping to winget

Summary

winget is Windows' package manager. Windows users will benefit from easily installing tcping from their CLI rather than manually downloading the release file.

More information can be found here and here.

Most preferably, this should be integrated into the CI.

intermittent inconsistent timing report

Summary

At times, we see a difference between total downtime, longest downtime and duration reports. This is highly probable to the fact that we are using different methods for calculating time.

Examples of this can be seen in these places:

tcping/statsprinter.go

Line 86 in 8296319

durationDiff = p.endTime.Sub(p.startTime)

and:

tcping/statsprinter.go

Line 83 in 8296319

durationDiff = time.Since(p.startTime)

We should use a unified pattern.

Please refer to the attached picture for reference in which total downtime, longest downtime and duration are showing odd values.

Automate the release process

Summary

Currently, the release process is manual and usually consists of:

1. Running make build locally
2. Taking a note of the sha256 sums generated by make for brew
3. Update the version and SHA of the homebrew repo
4. Create a release and upload the compressed files
5. Assign the latest tag
6. Paste in the specific changes for this release from the changelog

The docker release has been automated and can be referenced here.

The objective is:

1. Automate the steps mentioned above
2. Stay with the current procedure. No straying unless we agree upon it

This is a sensitive issue and might result in a lot of change requests. Please only pick this up, if you are willing to drive it to completion.

Module path should be "github.com/pouriyajamshidi/tcping", not "tcping"

Hi,
Thank you for this program.

Do you have plans to make this go gettable by changing the module path from tcping to github.com/pouriyajamshidi/tcping in the go.mod file?

 🕙 05:58:54 ❯ go get github.com/pouriyajamshidi/tcping
go: downloading github.com/pouriyajamshidi/tcping v1.2.0
go get: github.com/pouriyajamshidi/[email protected]: parsing go.mod:
	module declares its path as: tcping
	        but was required as: github.com/pouriyajamshidi/tcping

Use standard `time.Duration` for storing/working with durations

Is your feature request related to a problem? Please describe.
When working on #37 I found that there are some instances where duration was passed as uint

tcping/tcping.go

Line 389 in 8c3d3b7

func calcTime(time uint) calculatedTimeString {

or float64

tcping/tcping.go

Line 52 in 8c3d3b7

duration float64

(Maybe there are others I haven't noticed)

Using bare types makes it unclear, what unit it's expecting, seconds, milliseconds or something else.

Describe the solution you'd like
Use canonical time.Duration, because all time-relation operations from the time package returns time.Duration and then a user could decide which unit does he want: hours, mins, seconds, etc.

Please tell me if there's a specific reason why it's used like that, I can be missing some context.

Add Linux binary installation into Brew tap

Is your feature request related to a problem? Please describe.
Can't install tcping on Linux using Homebrew despite having Linux binaries and Homebrew supporting Linux.

Describe the solution you'd like
Add Linux binaries to Homebrew tap.

Describe alternatives you've considered
Homebrew is a great package manager support on Linux too.

Fix code scanning alert - Incorrect conversion between integer types

Tracking issue for:

• https://github.com/pouriyajamshidi/tcping/security/code-scanning/1

Update actions versions used in workflows

Update actions versions used in workflows

There are quite a few actions being used in the workflows, it is a good time to have a look at the versions being in use and see which ones need an update (without breaking the flows)

Workflows can be found here https://github.com/pouriyajamshidi/tcping/tree/master/.github/workflows

fix CI warnings

Summary

There are some legacy statements in the CI container publish workflow resulting in:

The `save-state` command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/

These should be replaced with the recommended method mentioned in the link.

Ouput in JSON

Summary

Some monitoring systems could use the output of tcping to be in JSON for easier parsing and processing.

Having a flag to change the output type would be nice. However, there are a lot to be changed since the current output is colorized.

Better JSON output support

Summary

We have introduced a preliminary JSON output support with which can be activated using the -j flag. For instance:

{"message":"TCPinging example.com on port 443"}
{"message":"Reply from example.com (93.184.216.34) on port 443 TCP_conn=1 time=128 ms"}
{"message":"Reply from example.com (93.184.216.34) on port 443 TCP_conn=2 time=108 ms"}
{"message":"Reply from example.com (93.184.216.34) on port 443 TCP_conn=3 time=108 ms"}
^C{"message":"example.com TCPing statistics: 3 probes transmitted, 3 received"}
{"message":"0.00% packet loss"}
{"message":"successful probes: 3"}
{"message":"unsuccessful probes: 0"}
{"message":"last successful probe:   2022-07-10 17:57:29"}
{"message":"last unsuccessful probe: Never failed"}
{"message":"total uptime: 3 seconds"}
{"message":"total downtime: 0 second"}
{"message":"longest consecutive uptime: 2 seconds from 2022-07-10 17:57:27 to 2022-07-10 17:57:29"}
{"message":"retried to resolve hostname 0 times"}
{"message":"rtt min/avg/max: 108/114.666664/128"}
{"message":"started at: 2022-07-10 17:57:27 ended at: 2022-07-10 17:57:30 duration (HH:MM:SS): 00:00:02"}

The ultimate goal is to have the output in a way that is easily extractable in form of keys and values so with tools such as jq to feed to the monitoring solutions.

Further discussion might be necessary to determine how and what exactly needs to be emitted.