Re^2: Proving a UDP port is closed

[davis]

*nods at L~R

Hmmm. Maybe; I hadn't really thought of that... However, I'm not sure that a netstat would show all services that are started by inetd (the reason I switched to rpcbind here is because more people are likely to have rpcbind available, hence the failure's easier to prove). I'm also trying to get as close to evidential proof as possible -- e.g. "You want port 1234 closed?": "Let's prove it's closed by trying to connect to it"

[Limbic~Region]

davis,
The netstat command shows network information and is not concerned with what services/processes are running. Also, inetd isn't magical and can't establish a connection without a listener. In order for the server to accept connections on a port then there has to be a listener for that port. The netstat command can be used to show what listeners are out there.

As far as proving it by attempting to connect to it, I would have no way of testing presently.

[davis]

Sorry, I realised the stupidity of what I'd said (the implied magic) fairly quickly! Yeah, grokking the "netstat -af inet" output would almost certainly work for me for both TCP and UDP listeners, but there's still something somehow... cleaner about the attempted connection method, at least in my head.

[Anonymous Monk]

Is it possible for a listener to black-hole the port, and soak up messages (possibly acting on them) with no replies or indication that it has happened to the outside world?

Such a case would require checking for listener processes rather than just shouting at the computer and waiting for echoes.