Live data from Hacker News

Testing if a port can be reached, using built-in tools other than ol' telnet

carehart.org

11–20 of 87 posts

Re: Testing if a port can be reached, using built-in tools other than ol' telnet

#11
post #8
post #5

Windows can install full Linux distro via WSL. You can have a nmap in two minutes! I like it much better than MacBook with its incompatible ARM cpu, and outdated commands from some ancient BSD!

It's been a year or two but last time I tried networking tools like nmap in WSL I would get all kinds of errors.

I was getting errors from ping. Update fixed that, my guess is WSL2 is much better

Re: Testing if a port can be reached, using built-in tools other than ol' telnet

#12
post #6
post #5

Windows can install full Linux distro via WSL. You can have a nmap in two minutes! I like it much better than MacBook with its incompatible ARM cpu, and outdated commands from some ancient BSD!

Yes ever since the M1 chip it’s just annoying to work on the M1. Day to day it doesn’t matter much but it wastes days of times the few times i ran into an issue. I wish companies would stop defaulting to macs for development

What?

Re: Testing if a port can be reached, using built-in tools other than ol' telnet

#13
Ha! This was probably the first serious problem I ever tackled with an open source contribution!

The year was 2002, the 2.4 Linux kernel had just been released and I was making money on the side building monitoring software for a few thousand (mostly Solaris) hosts owned by a large German car manufacturer. Everything was built in parallel ksh code, “deployed” to Solaris 8 on Sun E10Ks, and mostly kicked off by cron. Keeping total script runtime down to avoid process buildup and delay was critical. The biggest offender: long timeouts for host/port combinations that would sporadically not be available.

Eventually, I grabbed W. Richard Stevens’ UNIX network programming book and created tcping [0]. FreeBSD, NetBSD, a series of Linux distros picked it up at the time and it was steady decline from there… good times!

[0]: https://github.com/mkirchner/tcping

edit: grammar

Re: Testing if a port can be reached, using built-in tools other than ol' telnet

#15
post #6
post #5

Windows can install full Linux distro via WSL. You can have a nmap in two minutes! I like it much better than MacBook with its incompatible ARM cpu, and outdated commands from some ancient BSD!

Yes ever since the M1 chip it’s just annoying to work on the M1. Day to day it doesn’t matter much but it wastes days of times the few times i ran into an issue. I wish companies would stop defaulting to macs for development

Would not work at a company who only offered macs.

Re: Testing if a port can be reached, using built-in tools other than ol' telnet

#18
I built a tool for this purpose, inspired by a comment on lobste.rs[0].

You can check a port like this, saves a few round trips on a good day.

    $ dstp google.com --port 80

    Ping: 27.44ms
    DNS: resolving 216.58.212.14
    SystemDNS: resolving 2a00:1450:4017:804::200e, 142.250.187.174
    TLS: certificate is valid for 64 more days
    HTTPS: got 200 OK


[0]: https://github.com/ycd/dstp#motivation

Re: Testing if a port can be reached, using built-in tools other than ol' telnet

#19
post #16

I sometimes wonder why we still use port numbers. Wouldn't it make much more sense to use strings to name ports?

/etc/services assigns a string to every port number.

It's ancient, but still present on every Linux and MacOS system.

Re: Testing if a port can be reached, using built-in tools other than ol' telnet

#20
post #16

I sometimes wonder why we still use port numbers. Wouldn't it make much more sense to use strings to name ports?

/etc/services assigns a string to every port number. It's ancient, but still present on every Linux and MacOS system.

Yeah, but it's still port numbers under the hood.

The big downside of this is that you can get clashes. For example, VNC uses 5901 and up on my system. What if I have some other service that uses ports in the same range?

A more sane approach would be to call those ports e.g. vnc/work, vnc/meeting, etc. so there would be no conflicts and you would know what each port is used for. And it would work even if you don't have write-access to /etc/services.

Post reply on HN