kory@avatar.com (Kory Hamzeh) (03/21/91)
I have been playing extensivly with PC/IP and I am thinking of developing
some software using the libraries that come with it. I have several questions
that I thought some people might be able to answer:
1. It doesn't seem to be able to resolve host names and domain
names. I have a Sun Sparcstation 1+ running SunOS 4.1 acting
as a name server.
2. Lpr thinks it sent the file to the print server, but nothing
gets printed.
3. About 50% of the time when using rexec, I get the following
message:
Foreign host is trying to establish a connection with us
as we are to it. Perhaps you should quit.
It then proceeds to reset the TCP connection and restart. Every
thing works, even when this message is printed. Other programs
that use TCP don't exhibit this behavior.
4. I noticed that the programs and libraries are all built using the
small memory model. I need to use the large model. Has anyone tried
to convert it over to the large model. Any hints or pointers would
be very helpful.
5. Are there any other bugs that I should know about?
When using FTP's PC/TCP on the same PC and network, all of the above
functions work fine. This leads to believe that the network/Sun is all
setup correctly.
Any help would be greatly appreciated.
Thanks,
--kory
--
-------------------------------------------------------------------------------
Kory Hamzeh UUCP: avatar!kory or ..!uunet!avatar!kory
INTERNET: kory@avatar.com romkey@ASYLUM.SF.CA.US (John Romkey) (03/23/91)
Date: 21 Mar 91 02:30:34 GMT From: Kory Hamzeh <decwrl!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!think.com!linus!philabs!ttidca!quad1!avatar!kory> 1. It doesn't seem to be able to resolve host names and domain names. I have a Sun Sparcstation 1+ running SunOS 4.1 acting as a name server. This used to work back at MIT but the code is many years old. 2. Lpr thinks it sent the file to the print server, but nothing gets printed. Ditto. 4. I noticed that the programs and libraries are all built using the small memory model. I need to use the large model. Has anyone tried to convert it over to the large model. Any hints or pointers would be very helpful. It's a hassle. The problems are two-fold. First, the code's not very clean. Second, and more importantly, converting the tasking package to large memory model will be a real pain, especially if you use Microsoft C, which requires that all the stacks be in one segment. 5. Are there any other bugs that I should know about? PC/IP is not actively maintained, and is probably quite out of sync in many ways with today's ideal TCP/IP stack. I'm one of the original authors and I don't recommend using it. Use a supported commercial package, or NCSA Telnet or KA9Q if you must (KA9Q only for non-commercial applications unless you have Phil Karn's permission). When using FTP's PC/TCP on the same PC and network, all of the above functions work fine. This leads to believe that the network/Sun is all setup correctly. PC/TCP is a descendant of PC/IP, by the way; most every line of code rewritten but then most of the descendants have done that by now. - john romkey Epilogue Technology USENET/UUCP/Internet: romkey@asylum.sf.ca.us voice/fax: 415 594-1141
trier@adamwest.INS.CWRU.Edu (Stephen C. Trier) (03/23/91)
In article <9103220835.AA01350@asylum.sf.ca.us> romkey@asylum.sf.ca.us writes: >[Re: Non-small model PC/IP's] >It's a hassle. The problems are two-fold. First, the code's not very >clean. Second, and more importantly, converting the tasking package to >large memory model will be a real pain, especially if you use >Microsoft C, which requires that all the stacks be in one segment. I am in the process of converting a PC/IP descendent for memory model independence. It hasn't been too difficult so far, although I have spent a month or so working on it (15 hour workweeks, since I'm a student) The tricks are to replace as much assembly code as possible with C and with standard library calls, and then to set up the tasking package to use _nmalloc to allocate its stacks within the data segment. (You will also have to write four versions of the tk_swtch function, one for each memory model.) Of course, my converted programs are crashing occasionally, and the DNS code still doesn't seem to work right. I think there are still some sizeof(char *) == sizeof(int) assumptions I haven't yet found. Oh, the other advantage I have had as I've made this conversion is that I am converting a Stanford PC/IP derivative. As a result, most of the really ugly code is inside a TSR kernel that can stay small model. I have just had to convert the libraries. -- Stephen Trier Case Western Reserve University Work: trier@cwlim.ins.cwru.edu Information Network Services Home: sct@seldon.clv.oh.us %% Any opinions above are my own. %%
jrd@cc.usu.edu (03/31/91)
In article <9103220835.AA01350@asylum.sf.ca.us>, romkey@ASYLUM.SF.CA.US (John Romkey) writes: > Date: 21 Mar 91 02:30:34 GMT > From: Kory Hamzeh <decwrl!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!think.com!linus!philabs!ttidca!quad1!avatar!kory> > > 1. It doesn't seem to be able to resolve host names and domain > names. I have a Sun Sparcstation 1+ running SunOS 4.1 acting > as a name server. > > This used to work back at MIT but the code is many years old. > > 2. Lpr thinks it sent the file to the print server, but nothing > gets printed. > > Ditto. > > > 4. I noticed that the programs and libraries are all built using the > small memory model. I need to use the large model. Has anyone tried > to convert it over to the large model. Any hints or pointers would > be very helpful. > > It's a hassle. The problems are two-fold. First, the code's not very > clean. Second, and more importantly, converting the tasking package to > large memory model will be a real pain, especially if you use > Microsoft C, which requires that all the stacks be in one segment. > > 5. Are there any other bugs that I should know about? > > PC/IP is not actively maintained, and is probably quite out of sync in > many ways with today's ideal TCP/IP stack. I'm one of the original > authors and I don't recommend using it. Use a supported commercial > package, or NCSA Telnet or KA9Q if you must (KA9Q only for > non-commercial applications unless you have Phil Karn's permission). > > When using FTP's PC/TCP on the same PC and network, all of the above > functions work fine. This leads to believe that the network/Sun is all > setup correctly. > > PC/TCP is a descendant of PC/IP, by the way; most every line of code > rewritten but then most of the descendants have done that by now. > > - john romkey Epilogue Technology > USENET/UUCP/Internet: romkey@asylum.sf.ca.us voice/fax: 415 594-1141 And, if you've read this far, I suspect the lack of name translation might be in a missed out name server ident in netdev.sys. On my rendition of PC/IP the above items work (but I've not tried lpr). If you want to try my Packet Driver flavor then use anonymous ftp to netlab.usu.edu, 129.123.1.11, cd to [anonymous.netwatch], and please read the read.me file to choose the correct (but huge) file(s) to transfer. Joe D.