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: :
Testing if a port can be reached, using built-in tools other than ol' telnet
21–30 of 87 posts
Re: Testing if a port can be reached, using built-in tools other than ol' telnet
#22Re: Testing if a port can be reached, using built-in tools other than ol' telnet
#23Not 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
#24Ha! 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.…
Re: Testing if a port can be reached, using built-in tools other than ol' telnet
#25Earlier 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…
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
#26Ha! 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
#27Ha! 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.…
Re: Testing if a port can be reached, using built-in tools other than ol' telnet
#28I sometimes wonder why we still use port numbers. Wouldn't it make much more sense to use strings to name ports?
Re: Testing if a port can be reached, using built-in tools other than ol' telnet
#29Earlier 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…
It'd still be a massive undertaking though.
Re: Testing if a port can be reached, using built-in tools other than ol' telnet
#30I sometimes wonder why we still use port numbers. Wouldn't it make much more sense to use strings to name ports?
For ephemeral ports, it isn't clear what value there would be for a string identifier vs. the fixed-width integer.