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...
Testing if a port can be reached, using built-in tools other than ol' telnet
31–40 of 87 posts
Re: Testing if a port can be reached, using built-in tools other than ol' telnet
#32Not 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: :
can you elaborate? From a stealth perspective, probing for a port will always reveal to the other side that they are being probed
Re: Testing if a port can be reached, using built-in tools other than ol' telnet
#33I’ve never used ‘curl host:port’ but use ‘curl -v telnet://host:port’ all the time on Linux boxes that don’t happen to have telnet installed. Perhaps he omits the telnet on the curl because I believe the windows curl doesn’t support it..
Re: Testing if a port can be reached, using built-in tools other than ol' telnet
#34Not 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: :
> Not sure if I'd like to send anything into tested port just to tell if it is open. can you elaborate? From a stealth perspective, probing for a port will always reveal to the other side that they are being probed
Re: Testing if a port can be reached, using built-in tools other than ol' telnet
#35`nc -Z x.x.x.x nnnn` works well enough for me.
Re: Testing if a port can be reached, using built-in tools other than ol' telnet
#36Ha! 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
#37Earlier quoted context omitted.
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
#38Not 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
#39Re: Testing if a port can be reached, using built-in tools other than ol' telnet
#40Not 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?