"The Linux Gazette...making Linux just a little more fun!"

TCPMux Revisited: You'll need a Daemon for it, or a Better inetd

From Helpdesk on Wed, 01 Sep 1999

I was trying to configure a few services using the tcpmux - inetd internal service. but while trying to connect to tcpmux on port 1 it gives me an i/o error on socket and fails to establish a connection.

could you please elaborate on this.

i was also hunting to find some info on tcpmux but was not able to.

Pleaseeeeeeeeeeeeeeeeeeeeeeeee help. doing some serious bussiness programming on linux. stuck up.

jaggu

The default 'inetd' that ships with most Linux distributions doesn't support the tcpmux protocol. You'd either need to get a replacement Internet Dispatch Daemon (like Mike Neuman's BINETD, "Better INETD" at: http://www.engarde.com/~mcn/binetd/index.htm), or you'd need to write a standalong tcpmuxd and configure your 'inetd' to launch it for new connections on TCP port 1.

I also found a web page that suggests that some versions of BSD 4.4 inetd include support for TCPMux services:

Manpage of INETD

http://theoryx5.uwinnipeg.ca/gnu/inetutils/inetd.8.html

This impression seems to be supported by the online man pages at the FreeBSD web site:

FreeBSD Hypertext Man Pages: inetd

http://www.freebsd.org/cgi/man.cgi?query=inetd&apropos=0&sektion=0&manpath=FreeBSD+4.0-current&format=html

So perhaps you could (re-)port that to Linux. Or, perhaps you could write a standalone daemon to implement the protocol. All it would do is a simple handshake and launch.

Presumably your tcpmuxd daemon would (if you wrote it) use a separate configuration file (maybe /etc/tcpmux.conf would be a good name) which would tell it which services were available (names with the custom protocol versions encoded into them perhaps) and what programs to launch to handle requests for each of those protocols/services. Obviously this would be serving a very similar function to the existing inetd.

If you were going to write such a daemon, it seems like it would make sense to derive it from TCP Wrappers. tcpd performs very similar operations, and you could link the tcpmuxd against libwrap so that its services could be subjected to the same access controls and logging that TCP Wrappers provides, while allowing the administrator to continue using just the /etc/hosts.allow and /etc/hosts.deny files for those controls.

The TCPMux protocol is described in RFC1078. There are a number of archives of RFCs on the 'net. Any could search engine should find them (start with the search engine at Linux Gazette's site since I know I've provided links to a couple of them in my past columns).

Here's one description of this protocol with some notes about where it's supported:

http://www.con.wesleyan.edu/~triemer/network/tcpmux/tcpmux.html

I've suggested this project to a few open source programmers, but none have stepped upto the plate. Perhaps you could do it. Once a good implementation is available, we could encourage distribution maintainers to include it and programmers to use it rather than grabbing new ports and perpetuating the problems of "WKS" (well-known service port numbering).

I'd particularly like to see 'mcserv' (the Midnight Commander communications service) and AMANDA (the "Advanced Maryland Network Disk Archiver") use this for their networking protocols. Those or such specialized protocols that they should use TCPMux rather than grabbing a port number for a protocol which will never be implemented in any other clients or servers.

Copyright © 1999, James T. Dennis
Published in The Linux Gazette Issue 46 October 1999

HTML transformation by of Starshine Technical Services, http://www.starshine.org/

		1	2	3	5	5	6
7	8	9	10	11	12