bmw@isgtec.UUCP (Bruce Walker) (08/22/89)
I acquired a copy of ka9q from osu-cis in July. Inside were about
four different versions of 'net'-sources and two different net.exe's.
[Minor gripe: I *wish* there was a READ.ME for the package as a whole!]
The documentation inside net_doc appears to be accurate only for the
stuff inside net_pc and net_src. In particular, the newer bigger net.exe
(which I assume was built from the sources in the subdir 'src') does
not read my 'hosts.net' file and so I am unable to refer to IP addresses
symbolically (eg: "mysys 192.9.200.1").
Reading the source has revealed only that some kind of support for
'domains' has been added, but not how to use this new function.
It appears that I can create a 'domain-server' and that it reads
'domain.txt', but nothing about the file data format is obvious.
Playing around with the domain command results in frequent disk
accesses for unknown reasons, but no cigar.
The questions:
a) how can I replace the functionality of 'hosts.net'?
b) is there any more up-to-date info on ka9q?
The environment:
- ka9q: "890416 NOS Turbo-C" (from memory ... at least the date is accurate)
- two PC/XT turbo's tied with rs232 (I'm just trying SLIP for now)
- floppies (I'm really paranoid since experimenting with this stuff has
resulted in trashed FAT's now and then!)
While I'm here, has anyone else noticed the following SLIP behaviour:
- works OK on one serial port (COM2)
- starts up OK when attaching other serial port (COM1) but hangs(!) when
a packet is received (either from the other system ping'ing or echoing
a ping). (BTW, only attaching one port at a time.)
- both serial ports work OK with other applications (mouse, modem, etc.).
- using net_pc/net.exe for this experiment.
Thanks a bunch!
--
Bruce Walker ...uunet!mnetor!lsuc!isgtec!mutant!bmw
"Better Living Through Connectivity" ...utzoo!lsuc!isgtec!mutant!bmw
ISG Technologies Inc. 3030 Orlando Dr. Mississauga. Ont. Can. L4V 1S8karn@jupiter (Phil R. Karn) (08/23/89)
The only version of the KA9Q package that I am personally supporting is the so-called "NOS" version. It can be obtained by anonymous FTP from flash.bellcore.com: /pub/ka9q/src.arc - sources in ARC format (use PKXARC to extract) /pub/ka9q/net.exe - executable for IBM PC This version does indeed use the domain system. It has a local disk cache that resides in /domain.txt. Each entry in that file consists of a line of ascii text in the following format: sun.ka9q.ampr.org. IN A 128.96.160.1 (note the trailing period on the domain name!) You need to "seed" the domain.txt file with enough entries to get you through the autoexec.net file. Once you're up and running, you can telnet, ping, FTP or send mail to sites not in the domain.txt file if you have specified at least one domain server with the "domain addserver" command. Responses from the server(s) will be appended to the domain.txt file in the order they arrive so that subsequent searches for the same name will not cause additional requests on the network. I am very concerned about your report of FAT-trashing. This is the first such report I've received, and if you can isolate the problem I would very much appreciate the details. Be sure you start with the latest code. Phil
bmw@isgtec.UUCP (Bruce Walker) (08/30/89)
Bruce Walker: (me) >> The environment: >> - floppies (I'm really paranoid since experimenting with this stuff has >> resulted in trashed FAT's now and then!) Phil Karn: > I am very concerned about your report of FAT-trashing. This is the first > such report I've received, and if you can isolate the problem I would > very much appreciate the details. Be sure you start with the latest > code. Sorry about the delay ... I better clarify; I don't wish to start rumours. Summary: 1) my problem was NOT caused by KA9Q code. 2) my problem WAS caused by bad handling of args by Clarkson packet driver. I had been having some troubles getting two PC's to talk SLIP to each other. While fiddling around, I thought "maybe there is no 8250 code in here" (meaning net.exe) and so I tried loading the 8250 packet driver from Clarkson. Well I didn't fully understand the command line syntax, particularly the first argument, so I invoked it like this: slip8250 sl0 slip 3 0x2f8 9600 ^^^ and my machine hung with the hard disk led on. After reboot I had the dreaded cross-linked clusters on some files (luckily expendable). My prognosis is that the Clarkson packet drivers are negligent in their parsing of arguments and managed to turn "sl0" into a number (!) which became the interrupt vector to take over (maybe int zero?). Zang! I don't take kindly to software that causes this sort of minor disaster so I have been using extreme caution since. -- Bruce Walker ...uunet!mnetor!lsuc!isgtec!bmw "Better Living Through Connectivity" ...utzoo!lsuc!isgtec!bmw ISG Technologies Inc. 3030 Orlando Dr. Mississauga. Ont. Can. L4V 1S8