Live data from Hacker News

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

carehart.org

21–30 of 87 posts

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

#21
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: :

This is what I was trying to remember, I've seen this before but never understood it. What does the colon do?

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

#23
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: :

This is what I was trying to remember, I've seen this before but never understood it. What does the colon do?

it makes the smiley face look very sad : < while giving an exit status of zero (in this case only if bash can resolve the input redirection by opening that tcp port)

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

#24

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

RIP WRS. Such a fantastic book.

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

#25
post #20

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…

The reason this hasn't been done is that it would require changes to the headers of TCP and UDP, which would be a massive undertaking (for similar reasons to why IPv4 -> IPv6 is such a pain).

Would both the source and destination ports both be strings? Normally, for a client->server packet, the source port is meaningless, so what string would you use? Or would your new protocol support both string ports and integer ports?

Having ports be strings in the TCP header would make the header considerably longer - supposing your protocol had one fixed length 32 ASCII char string port, you'd be looking at something in the region of a 2x increase in header length.

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

#26

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

RIP WRS. Such a fantastic book.

[deleted]

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

#27

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

I worked for Rich when he was writing UNP. Seeing comments like this 30+ years later reminds me how fortunate I was to spend time with him early in my career.

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

#28
post #16

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

There are some attempts at doing that, such as https://en.m.wikipedia.org/wiki/SRV_record and https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https...

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

#29
post #20

Earlier quoted context omitted.

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…

The reason this hasn't been done is that it would require changes to the headers of TCP and UDP, which would be a massive undertaking (for similar reasons to why IPv4 -> IPv6 is such a pain). Would both the source and destination ports both be strings? Normally, for a client->server packet, the source port is meaningless, so what string would you use? Or would your new protocol support both string ports and integer p…

Couldn't the port string be mapped to a temporary port number when the TCP connection is initiated? It'd still be necessary for UDP though.

It'd still be a massive undertaking though.

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

#30
post #16

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

The wire format for UDP and TCP specifies 16 bit integer values. As another poster mentioned, you can uses OS level services to map a string to well-known ports, but encoding ports as strings at the wire level would've introduced a lot of serialization complications and performance concerns for parsing packets.

For ephemeral ports, it isn't clear what value there would be for a string identifier vs. the fixed-width integer.

Post reply on HN