Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!ncar!gatech!bloom-beacon!eru!hagbard!sunic!mcsun!hp4nl!phigate!philica!geertj From: geertj@philica.ica.philips.nl (Geert Jan de Groot) Newsgroups: comp.protocols.nfs Subject: Re: Problem with PC-NFS programmers Toolkit Message-ID: <713@philica.ica.philips.nl> Date: 21 Nov 90 14:30:49 GMT References: <901019.190237.kjetilo@otter> Reply-To: geertj@ica00.ica.philips.nl (Geert Jan de Groot) Organization: Philips TDS, Innovation Centre Aachen Lines: 51 In article <901019.190237.kjetilo@otter> kjetilo@gollum.uio.no (Kjetil Otter Olsen) writes: >I am using PC-NFS 3.0.1 and PC-NFS Programmers Toolkit 1.00 and the >following problem has come up: > > When I try to open a TCP socket to a port by using the number > of a service, (and not getservbyname()) it fails. > > After _some_ debugging I found that the getservbyname() function > returned port number 5888 for telnet, that is 23 _* 256_. ( Telnet > is usually 23, according to Assigned Numbers ) The same weird > thing happens for other services (SMTP, NNTP ....) It's not weird, this is supposed to happen. Internet networking uses the right byte order, while (broken) intel processors do it the wrong way. There are library routines to convert between the two; outsmarting them will burn you, as you just have learned. There should be some macro's in an include file which swap bytes if the processor is of the wrong type. Check page 276 e.a of Comer's networking book, about the ntohs, htons, ntohl, and htonl macros. Or check page 192 of the toolkit manual. > For telnet, SMTP or NNTP this is no problem, I just use getservbyname() > or multiply, but in some cases that is not enough... When I want > to access a port > 256, I end up with >256 * 256 (= >64k ).. And > since the port is declared as an "unsigned short" in the sockaddr_in- > struct I have a problem... Nope, it's swapping bytes. Port 0x1234 must be 0x3412. Got it? DON'T JUST SWAP BYTES. If your program gets moved to a non-broken CPU, you'll be confused again. The macro's mentioned above take care of this. > OK, a bug in the Toolkit I assumed, but then i tried the CUTCP > telnet that uses the Toolkit, and it has no problems with port- > numbers > 256. There are many bugs in the toolkit, but not this one.. Geert Jan --8<--nip-nip--------------------------------------------------------------- Geert Jan de Groot, Email: geertj@ica.philips.nl Philips ICA, ..!hp4nl!philica!geertj Weisshausstrasse, Ham: PE1HZG 5100 Aachen, West-Germany phone: +49 241 6003 714 "Programs are like waffles: fax: +49 241 6003 709 you should always throw the first one out" [Standard disclaimers apply] - Sutherland