BEWARE of TCP port numbers in 4.1c & 4.2BSD

[Mark Callow]

Arrgh!! I've just spent a frustating hour trying to find out why
binding to tcp port number 2048 failed with "permission denied" on a
vax running 4.2 and worked on a Sun running 4.1c.

It seems the port number specified in the 'struct sockaddr_in' must
be in NETWORK order.  This is the same as host order on a sun (68010)
hence the program (which sun supplied) worked fine.  On the vax
it is byte and word swapped from host order so the program bombed
when it tested the port against the reserved port numbers. (ie,
was it < 1024?)

I have not seen this *important* fact documented anywhere.  I looked up
the inet(4f) page and it doesn't say anything about the port address.
It does say that "internet addresses are four byte quantities, stored
in network standard format".  This must be refering to the 'struct
in_addr sin_addr' portion of the 'struct sockaddr_in'

This seems an incredibly strange choice.  Intuitively the user should
be able to deal only with host order and leave it to the kernel to
convert addresses as necessary.  It is incredibly confusing to look up
the constant IPPORT_RESERVED in /usr/include/netinet/in.h and find it
has a value 1024 when a similar constant in your own program must be
declared as 0x0004 or you must use htons(1024).  Whoever wrote the code
in the kernel that checks against IPPORT_RESERVED thought so too.
{Her,His} comment was "GROSS".

I was all set to change the kernel thinking it had to be a bug when I
looked at the source for rlogind and for getservbyname and discovered
that they byte swap port numbers.
-- 
>From the Tardis of Mark Callow
msc at qubix.UUCP,  decwrl!qubix!msc at Berkeley.ARPA
...{decvax,ucbvax,ihnp4}!decwrl!qubix!msc, ...{ittvax,amd70}!qubix!msc