Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site qubix.UUCP Path: utzoo!linus!decvax!decwrl!sun!qubix!msc From: msc@qubix.UUCP (Mark Callow) Newsgroups: net.bugs.4bsd,net.unix-wizards Subject: BEWARE of TCP port numbers in 4.1c & 4.2BSD Message-ID: <747@qubix.UUCP> Date: Wed, 4-Jan-84 16:46:36 EST Article-I.D.: qubix.747 Posted: Wed Jan 4 16:46:36 1984 Date-Received: Fri, 6-Jan-84 02:00:16 EST Organization: Qubix Graphic Systems, Saratoga, CA Lines: 33 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@qubix.UUCP, decwrl!qubix!msc@Berkeley.ARPA ...{decvax,ucbvax,ihnp4}!decwrl!qubix!msc, ...{ittvax,amd70}!qubix!msc