Re: Free TCP/IP port numbers?
- Date: Sun, 1 Oct 2017 07:43:47 -0400
- From: Gene Heskett <gheskett@xxxxxxxxxxx>
- Subject: Re: Free TCP/IP port numbers?
On Sunday 01 October 2017 03:34:19 tomas@xxxxxxxxxx wrote:
> On Sun, Oct 01, 2017 at 01:28:39AM -0400, Gene Heskett wrote:
> > > > Assuring that my port is not in this IANA list is not enough to
> > > > ensure that my port number will not clash with a port number
> > > > used by a Debian package (by default).
> > > >
> > > > So your answer to my question is wrong.
> > In which case debian should publish the unlisted ports they do use,
> > if for no other reason than to "stake a claim".
> "Debian" "should". Gene, you "should" know better ;-)
> Want to start with it? Write a script which scans the /etc files in
> all Debian packages for network configurations.
That might be possible IF you wanted to use a tool like grep, but in 30
years I've not found a way to silence the "binary file matches" messages
from grep. That apparently un-muffle-able noise without chaining two or
more invocations of grep makes it worthless for 95% of the searches I
might do. The best I can do finds 460 instances of " port " in my
own /etc tree, but from looking at that output, less than 100 actually
assign a number, most use the output of some other function to assign
So opening up every deb in /var/cache/apt/archives to search thru each
ones /etc files might take this machine a week or more, and you would
still have less than 25% of the numerical values. One things for sure,
it would take a more imaginative approach than mine because so much of
it appears to be dynamic assignments. One would have to emulate how each
goes about it, and then its only valid for that machine at that box of
time, however long it took.
However, since it seems so much of that is dynamic, one could possibly
use the dynamic method to find a currently unused server port when the
client requests a connection, and the client can check the number
assigned against its own list of ports, and accept or reject, wash rinse
repeat until one is usable by both. Correctly done, I see at least
20,000 possibilities in the /etc/services list. The OP just needs to
find a coder who can write such a critter.
Sometimes necessity IS the mother of invention. If I am reading between
the lines with sufficient clairvoyance, he wants another level of
isolation to prevent data cross leakage between clients while all the
traffic is on one switch per floor or some such a cable build.
> What else have folks forgotten here?
> - dynamic port assignments (X, rpc/portmapper: the last is known for
> having conflicted with CUPS in some distant past).
> - semi-dynamic things (e.g. Debian's way to migrate PostgreSQL)
> Unfortunately, there's no "perfect" solution for the OP's problem
> (among other things because there are other people having the same
> problem and solving it the same way).
> My advice: start with /etc/services. Find a suitable "hole", far away
> from others (note that typical "dynamic" or "semi-dynamic" assignments
> tend to cluster around canonical values, e.g. PostgreSQL: 5432, 5433,
> 5434...). Plan for collissions (this might be something as complicated
> as re-trying ports until success plus some "registry" to look up where
> things ended or something as simple as "notify the sysadmin", lest she
> spends a night debugging the bugger).
> -- tomás
Cheers, Gene Heskett
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>