Port 5353 : how to open it?

It says that in the man page in OS X but, as with most open source programs, there are variations in the different distributions. The man page for the OS X distribution is relatively meaningless in any case since the switches don't appear to do anything, at least when run from a user account.

The right-most column should show the process ID and the program name, information that is missing from the OS X version, as in this example for the http port (port 80) from a Linux server:

tcp 0 0 *:http : LISTEN 2758/httpd

The above port is obviously idle but if there were an active connection the left-side localhost column, which currently shows "*:http" would look something like "this.servername.com:http" and the right-side remote host column, which currently shows " :" would look something like "adsl.someisp.com:61223" to indicate the remote host and port number.

OS X obviously uses a "." rather than a ":" as a seperator between the host name and the port, thus the " ." would indicate that there is currently no remote host connected at port 5353, in the case of the previous OS X example. The localhost "*.5353" indicates that a service is listening on port 5353 but there is currently no active connection.

It's a bit of a mystery as to why the PID and the program name don't show up in the OS X implementation of netstat. Also, I have Apache running on my iMac but I noticed that http doesn't show as listening on my netstat output. It appears that netstat on OS X doesn't provide complete information at the user level.

iMac Mac OS X (10.4.9)

I'm out of my element here, but I believe the reason the info you want isn't displayed & switches don't work as you expect is because this is a BSD UNIX implementation, not a Linux "UNIX-like" one. (For instance, help is not invoked with an "-h" switch.) All the switches I have tried with Terminal so far work as the man page indicates they should (AFAIK).

Working through the various BSD man pages, it appears port 5353 is for Multicast DNS, which won't resolve a "foreign" or remote address (unless it has an entry in the appropriate /etc/ database?) because for this protocol, the domain is meaningful only locally ... I think.

Regarding app names & PID's, I can only hazard a guess that since network connections in BSD UNIX are organized around socket abstractions rather than processes, some other, process-oriented command would show this info. I would pursue this further but as I say, I'm lazy & prefer the GUI tools Apple provides.

Anyway, I think that as long as port 5353 shows up in netstat or an appropriate GUI app output, the OP can assume that the port is open.

Don't worry, I'm in my element here. While there are significant technical differences between Unix and Linux, they are both POSIX systems thus have similar operational characteristics.

Regarding netstat specifically, the hostname:port conventions are the same. After all, netstat's primary function is to show which ports are active and who is connected to them.

In the case of port 5353, the originator of this thread seemed to believe that port 5353 was involved in the connection problems he was having with his Apple TV, thus I was trying to explain how ports work.

iMac Mac OS X (10.4.9)

With all due respect, it seems your element is more Linux than OS X, so it might be worth considering testing commands with OS X's Terminal.app before posting them here. We normally assume an OS X context unless otherwise specified & (I, at least!) become easily confused otherwise.

Apparently, there are significant differences in how the two implement network connections that result in equally significant differences in what info netstat can return, not the least of which is socket ownership (or so I'm told).

I'm also told (more like scolded, actually) that while OS X is fully POSIX compliant, Linux isn't.

I think you've googled yourself into a state of confusion on this. Netstat functions the same in OS X as it does in Linux and provides the same information with the exception that the "Status" and "PID/Program Name" columns are missing in the OS X implementation. It simply isn't any other way. You appear to be confused between the internal technical differences between these operating systems and the end results of the applications running on them.

My posts regarding the issue of "opening" port 5353 are valid. I was simply trying to save Alec312 the trouble of going on a wild goose chase in his effort to solve the connection problems he was having with his Apple TV. I doubt that the off-topic debates that followed have been of much use to anyone.

iMac Mac OS X (10.4.9)

I was confused not by Google but by your posting netstat syntax that doesn't work with the OS X version & isn't consistent with the BSD man page. You called that page "relatively meaningless," yet the command appears to work exactly as that page indicates it should. In trying to sort that out, I was told (in no uncertain terms) that there are fundamental differences in how different UNIX variants implement network connections, & that the OS X command is not "missing" anything consistent with a BSD implementation.

I was not trying to debate you about this, only to learn what command syntax works with OS X & how to interpret the results. I apologize to all if this took the discussion off topic.

Well, I tried everything.

It would be helpful to provide more detail than that, if not for your own sake then for the sake of others who might read this thread looking for answers to their own problems.

For instance, you never replied regarding trying suggestions for checking individual Macs with Disk Utility prior to running the Combo update, which was only one step in what could have been an interactive process that would eliminate a lot of potential causes. Even though three different Macs are involved, there is clearly some common factor here, which may not be in your Apple TV but instead the result of something applied to the Macs.

It is very difficult to cover everything in one post, & some things are dependent on the results of others, so if you still want to solve this, please let us know more than you have so far.