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

71–80 of 87 posts

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

#71

Post by k0k0 »

amelius wrote: post #68
lelanthran wrote: post #67

Earlier quoted context omitted.

> It would also be faster if we referred to files by their inode numbers. But we have filenames, and I don't want to speak for everybody but I think people like them. Actually, we do refer to files by their inode number, not by their name. The system uses the name to lookup the inode number, and then use the inode number. Maybe I misunderstood you initially[1], but you weren't proposing to keep the numbers and use a…

Well, frankly I don't care how the ports are implemented, by numbers would be fine. As long as it means that from the user's point of view they are names. A config file like /etc/services is too simple because I create ports all the time, even from scripts, and I don't want to always become root to change the config; and other systems that want to connect to ports on my machine can't read /etc/services on my machine.

DNS has SRV records. That is all you need, that is your solution, it exists. That they are not widely adopted in the manner you propose may be unfortunate, but completely upending protocols doesn't seem like a better or more realistically adopted solution either.

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

#72

Post by k0k0 »

gwright wrote: post #31
vitaliyf wrote: post #28

Earlier quoted context omitted.

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

I wish SRV records were more widely adopted, but they are still just a (string -> integer) mapping process above the 16-bit integer values on the wire. Different layers.

And? That's primarily what DNS is for: mapping strings to numbers.

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

#74

Post by amelius »

lelanthran wrote: post #69
amelius wrote: post #68

Earlier quoted context omitted.

Well, frankly I don't care how the ports are implemented, by numbers would be fine. As long as it means that from the user's point of view they are names. A config file like /etc/services is too simple because I create ports all the time, even from scripts, and I don't want to always become root to change the config; and other systems that want to connect to ports on my machine can't read /etc/services on my machine.

If you want to do a lookup translation and only use names on your local machine, it's only an hour of work or so to create a program that modifies the services file, and then make that program setuid root. However it only works on your machine. If you want to have it work on your local machine, DNS SRV records on your local network would work. The proposal to use names and not numbers breaks down when you want the re…

> The proposal to use names and not numbers breaks down when you want the rest of the world to follow suit, because it's not technically possible within IP, only on top of IP.

This is exactly my point.

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

#75

Post by lelanthran »

amelius wrote: post #74
lelanthran wrote: post #69

Earlier quoted context omitted.

If you want to do a lookup translation and only use names on your local machine, it's only an hour of work or so to create a program that modifies the services file, and then make that program setuid root. However it only works on your machine. If you want to have it work on your local machine, DNS SRV records on your local network would work. The proposal to use names and not numbers breaks down when you want the re…

> The proposal to use names and not numbers breaks down when you want the rest of the world to follow suit, because it's not technically possible within IP, only on top of IP. This is exactly my point.

> > The proposal to use names and not numbers breaks down when you want the rest of the world to follow suit, because it's not technically possible within IP, only on top of IP.

> This is exactly my point.

In which case, refer to my original response to your proposal - it's not practical to slow down every networking device in the world by a large factor.

It's like asking "why aren't we commuting at 1/3 the speed of light?": it's neither feasible nor practical.

Sure, it's possible, in that the physics involved make it possible, but not practical, because the limiting factor is not the physics involved.

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

#76

Post by BenjiWiebe »

keepamovin wrote: post #53
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 ':

There isn't a virtual filesystem; bash just pretends there is. You can't use the /dev/tcp path in your own program as it doesn't exist.

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

#77

Post by matt-attack »

arp242 wrote: post #38
politelemon wrote: post #21

Earlier quoted context omitted.

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

: is a special built-in that always succeeds and always returns an exit of 0. You typically use it when you need a command for syntax reasons, but don't actually need/want to run a command.

Example?

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

#78

Post by bradknowles »

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

He, I asked for Windows laptop. I am the only one in like 30 people. My laptop has 64GB RAM and 2TB ssd. And unlike Mac, it drives 4x4k displays via USB4 hub. Even with all those extras, it costs less than Macbook, and I have some hardware budget still available:) And it came with unlocked bios, no spy software... Windows are basically unsupported by our IT...

Depends on what Mac you get, but 64GB of RAM and 2TB of SSD with support for four 4k displays is pretty easy with the current MacBook Pro. It might be more expensive than your garden variety Windows laptop, or maybe not if you find one of the great deals that are frequently offered by B&H Photo or Adorama.

No spy software will be installed, and the latest version of macOS is making it harder and harder for people to create malware that can easily infect Macs.

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

#79

Post by bradknowles »

zee2345 wrote: post #57
jagged-chisel wrote: post #51

Earlier quoted context omitted.

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

Depends on which model you get and how you configure it. You can easily get up to 96GB of RAM and 8TB of SSD, if that's what you really want. It's damn bloody expensive to do that, but the possibility is there.

So, you can't legitimately say that the memory is always low and the disk is always small. That's just a configuration thing. If you don't configure it right, then I don't hold out much sympathy for you.

Post reply on HN