Some of the other low TCP ports that used to have public debugging-oriented services: echo 7/tcp echo 7/udp This one would echo back wha

Some of the other low TCP ports that used to have public debugging-oriented services: echo 7/tcp echo 7/udp This one would echo back what you sent it, kind of like running cat, except on another computer across the Internet. discard 9/tcp sink null discard 9/udp sink null This one would discard what you sent it, kind of like running cat >/dev/null, except on another computer across the Internet. systat 11/tcp users This one would sometimes give information about the remote system's status. daytime 13/tcp daytime 13/udp This one would show you what the other machine thought the current time was. I know of one machine that still supports it to this day; try $ telnet time-a.timefreq.bldrdoc.gov daytime to see how it works. netstat 15/tcp I don't know what this one did. qotd 17/tcp quote This one is like running the Unix "fortune" command or something, except on another machine. chargen 19/tcp ttytst source chargen 19/udp ttytst source And this is the one mentioned in the article, with the goal of helping you find bit-level errors on the network path between hosts. I think many of these were implemented by default and enabled by default in the inetd service, which was a daemon that would bind various TCP ports and then dispatch the connections by forking and execing a specified command with the input and output bound to the socket that the connection had arrived on. However, at least some versions of inetd could also sometimes implement simple services' logic internally instead of using an external command. The use of inetd has now become rare because of the pressure to run fewer network services for security reasons, and because most daemons that provide network services now handle TCP for themselves. I think one argument for inetd was that there might be services that are typically unused most of the time, so there was no reason to permanently allocate the memory for a daemon to handle those services in between connections. By contrast, as the Internet has gotten larger, faster, and more popular, it's more common to have dedicated machines running individual services that are essentially always in use by multiple remote users, so it's preferable to have the daemon with the relevant logic to answer new requests already running and ready to go. (In fact, now some services will prefork a pool of worker processes to prepare for requests that haven't even arrived yet.) Edit: does anyone know why these services all received odd-numbered TCP ports?