kemp@convex.com (Phil Kemp) (04/26/91)
I retreived the source for ka9q ( a very old version of NOS/NET ) and compiled it under minix-386 ( 1.5.10 with Bruces patches; thanks Bruce ). I'm trying to use the slip interface. I can get NET started after establishing the slip connection but the packets don't seem to be passed to the modem.... Has anyone gotten ka9q to work under minix using the slip interface? Any war stories would be welcome. Thanks PK -- Phil Kemp CONVEX Computer of Canada Ltd. Voice:(403)-233-2815 UUCP:kemp@convex.com
wallace@iitmax.iit.edu (Wallace) (04/27/91)
In article <kemp.672646468@convex.convex.com> kemp@convex.com (Phil Kemp) writes: >I retreived the source for ka9q ( a very old version of NOS/NET ) and >compiled it under minix-386 ( 1.5.10 with Bruces patches; thanks Bruce >). > >I'm trying to use the slip interface. I can get NET started after >establishing the slip connection but the packets don't seem to be >passed to the modem.... > >Has anyone gotten ka9q to work under minix using the slip interface? >Any war stories would be welcome. Well, several years ago I ran ka9q on both IBM clones using COM! and COM2 to form a ring of machines. It worked fine. What a cabling mess thou. I also ran on Minix 1.1 with a couple of kernel hacks over Starlan cards, (1 Mbit ethernet). The hacks where to prevent core dumps from not being ready for a message. Ftp, ping, and someother utilities worked. Telnet did not. The whole thing ran as a user process with signals from the kernel. Best of Luck, Ralph ============================================================================= I am not in search of excellence, I am in search of perfection. Dr. Ralph W. Wallace USPS: Illinois Institute of Technology TEL#: (798 682-6030 Dept. of Computer Science UUCP: wallace@iitmax.IIT.EDU 210 E. Loop Road BITNET: CSWALLACE@IITVAX Wheaton, Illinois 60187 -- ============================================================================= I am not in search of excellence, I am in search of perfection. Dr. Ralph W. Wallace USPS: Illinois Institute of Technology TEL#: (798 682-6030 Dept. of Computer Science UUCP: wallace@iitmax.IIT.EDU 210 E. Loop Road BITNET: CSWALLACE@IITVAX Wheaton, Illinois 60187
des@basie.wpd.sgi.com (Des Young) (04/30/91)
Hi, way back on version 1.3 Minix I ported Ka9q to minix. I got it to work with SLIP and Ethernet. The ethernet board I used was a National Semiconductor demo board, though a WD card would have been easy since it uses the National chipset. I did my debugging by running against a DOS-constrained PC which was running the latest version of the executable, obtainable many places. I started with version 1.00 of ka9q (yes, there was one) because I found the later versions all compiled to 200-300k of executable. Since I run/ran PC Minix, I wanted <= 64K executable. It was a lot of work, but I kept adding to my version until I had as much in it from later versions as possible. I ran it interoperably on the main Ethernet at my previous employer. The debugging display of packets was really usefull at times. Anyway, to help you, you need to add FIONREAD to the kernel to properly support the SLIP interface. I got mine from Ed Hall, worked great. Also, there was a bug in the ioctl/sgtty interface for setting the line speed, which I believe is STILL IN MINIX today. The problem is that the speed is coded in the message in a long or something, and FS does not copy it over on the call. You need to fix that if you want SLIP to work with variable line speeds (not variable during a connection :-) Well, I never ported the stuff to Minix 1.5, as I do not have an Ethernet running TCP-IP in my home :-) Good Luck, hope the SLIP hints help, Cheers, Des. P.S. I have not any time to post any of the above :-( -- trademarks abound, usual disclaimers apply, opinions are mine des@pei.com Des Young (415) 335-1888 Protocol Engines Inc., Mountain View, CA
waltje@uwalt.nl.mugnet.org (Fred 'The Rebel' van Kempen) (05/20/91)
des@basie.wpd.sgi.com (Des Young) wrote: > Hi, > way back on version 1.3 Minix I ported Ka9q to minix. I got it to > work with SLIP and Ethernet. The ethernet board I used was a National > Semiconductor demo board, though a WD card would have been easy since > it uses the National chipset. > I did my debugging by running against a DOS-constrained PC which was > running the latest version of the executable, obtainable many places. > I started with version 1.00 of ka9q (yes, there was one) because I > found the later versions all compiled to 200-300k of executable. Since > I run/ran PC Minix, I wanted <= 64K executable. It was a lot of work, > but I kept adding to my version until I had as much in it from later > versions as possible. I ran it interoperably on the main Ethernet at > my previous employer. The debugging display of packets was really > usefull at times. After a long, long time of "careful thinking", I opened a PTY to myself, and told myself to go ahead and port Phil's N/OS to our version of MINIX. It now runs as a separate process server ("INET") in user space using DynaLink. This module also takes care of the complete BSD Socket(2) interface, plus the usual net(3) library (which, I have to admit, I took from BSD 4.3RENO with a lot of help from James Revell of UUNET). I can now compile standard BSD network tools (like ftpd.tar.Z and ftp.tar.Z, gnaa :-) and run them. The only problem is the resolver- it uses bitfields in the third byte of the request header. Barf.... named will have to wait.. :-( To get SLIP running, I first went back to the kernel, and implemented a crude form of Serial Line Line (eh?) Disciplines. This allows me to switch between TTY, MOUSE, SLIP and (soon) AMOEBA operation modes on a single serial line. TTY is, of course, the default mode. Bert Laverman and I are now finishing up the new "mouse" interface for MINIX- it is, at the driver level, identical between ST and PC versions of MINIX. Watch this space for his announcement... Anyway, back to TCP/IP. The two largest problems I found with any TCP/IP implementation are: 1. Memory allocation. Server processes cannot do malloc() and free(), so the process has to do its own allocation stuff. Barf. N/OS used a scheme that allocates buffers of 128 bytes in a ring-fashion; I liked that enough to choose for N/OS as a porting base... Also, remember that drivers for Ethernet and SLIP need lots of buffer space too. Actually, this is what made BSD 2.11 so much larger than 2.10 :-) 2. Driver intercommunication. I wanted to create a driver-server interface that could be used by all network protocol servers in my OS image. So, the Ethernet drivers (yeah, I have two of them: 3C503 and WD8003) should be usable by both INET and Amoeba, and, in the near future, my Novell NetWare server. The same more or less goes for the SLIP driver- it has to be able to do any kind of packet I/O in a point-to-point comms link. Item (1) is now solved adequately. In the kernel, I created a new series of memory allocation routines, with a global kernel space of up to 64Kbytes. This can be used by ALL drives in the kernel who need temporary buffer space for their clients. On 16-bit machines (like mine :-), the actual space is limited to some 17Kbyte. Oh well.... The second item is not yet fully finished. Everytime I think I got it all complete, I think of a new protocol that could be added in the future (like the damned IPX/SPX from Novell :-), and most of these protocols have some demands towards the drivers they use. However, the fine 'Packet Driver Protocol Specification' used by the newer versions of KA9Q-N/OS (thanks, Russ Nelson!) was a _great_ help. For those of you who don't know: this spec is a generalization of a spec created by FTP Software, Inc (beep- no affiliation here!) to reduce the number of changes in their software each time a new Ethernet board came out. The spec now serves as a general packet driver interface for MS-DOS systems. The Ethernet driver(s) are loaded as TSR (Terminate and Stay Resident) programs; they simply hook themselves to one or more software interrupt vectors (a bit like we have our IPC hooked to INT 32). Any application program (usually NET.EXE) can them query those drivers by issuing software interrupts to those vectors. Easy! I sort of mimiced the 'function calls' defined by those drivers. System Servers in MINIX (i.e. INET, AMOEBA and in future, NOVELL) can then issue these calls by sending the specified driver a message. Hurray! The problem is: how to make things like multiple Ether drivers, SLIP lines and, soon, AX.25/KISS drivers, work like one... :-( Any ideas, anyone?? Fred. -- MicroWalt Corporation, for MINIX Development waltje@uwalt.nl.mugnet.org Tel (+31) 252 230 205, Hoefbladhof 27, 2215 DV VOORHOUT, The Netherlands "An Operating System is what the _USERS_ think of it- me"