Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

carehart.org

Post reply on HN
Print view View original

51–60 of 87 posts

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

#51

Post by jagged-chisel »

medellin wrote: post #6
zee2345 wrote: 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

Can someone enumerate these problems? I’ve been on an M1 for almost 2yrs and I’m apparently missing out on what makes it a bad experience.

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

#52

Post by 1vuio0pswjnm7 »

mkirchner wrote: post #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.…

When I was reading his books I used the utility he wrote, sock.

https://github.com/keyou/sock

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

#53

Post by keepamovin »

Snawoot wrote: post #2

Not sure if I'd like to send anything into tested port just to tell if it is open. I'd rather stick with telnet or whatever is available. Also worth mentioning that bash also has network capabilities, you can check port like this: :

that is so cool, my god! Bash is this awesome underrated thing (relative to how I perceive it being used). It's so cool that there's basically a virtual filesystem that maps the internet to your disk...haha.

This even works on my Mac.

But one issue I encountered was timeout. I just tried:

  :
and it hung. So I asked ChatGPT and it suggested

  timeout 5 bash -c ':

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

#54

Post by void-star »

Snawoot wrote: post #2

Not sure if I'd like to send anything into tested port just to tell if it is open. I'd rather stick with telnet or whatever is available. Also worth mentioning that bash also has network capabilities, you can check port like this: :

Your concern about not wanting to send bytes is totally valid.

As it happens (if memory serves) telnet can send some bytes on connection also, in attempting to negotiate terminal settings with the remote “telnet server”. That said the /dev/tcp trick is indeed great for bash though!

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

#57

Post by zee2345 »

jagged-chisel wrote: post #51
medellin wrote: post #6

Earlier quoted context omitted.

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

Can someone enumerate these problems? I’ve been on an M1 for almost 2yrs and I’m apparently missing out on what makes it a bad experience.

Some X86 binaries do not run on M1, big deal in ERP. My collages spend like two weeks trying to emulate some older server.

It has little RAM, small disk... so you depend on cloud for build. No Nvidia GPU for CUDA... Some USB externals do not work...

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

#58

Post by lelanthran »

amelius wrote: post #20
hollerith wrote: post #19

Earlier quoted context omitted.

/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 ha…

> 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.

More sane, but absolutely slow. Every gateway, NAT, firewall, router and switch between two devices would need 15x more RAM, and even with that RAM would need to parse strings, deal with unicode, etc. All of those are slow operations.

Using 16-bit numbers makes identification and routing of packets very quick.

Post reply on HN