Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site seismo.UUCP Path: utzoo!watmath!clyde!floyd!harpo!seismo!ra From: ra@seismo.UUCP (Rick Adams) Newsgroups: net.unix-wizards Subject: Re: TCP/IP Communications (over serial lines) Message-ID: <604@seismo.UUCP> Date: Thu, 9-Feb-84 19:39:42 EST Article-I.D.: seismo.604 Posted: Thu Feb 9 19:39:42 1984 Date-Received: Fri, 10-Feb-84 07:15:42 EST References: <16475@sri-arpa.UUCP> Organization: Center for Seismic Studies, Arlington, VA Lines: 58 Newsgroups: net.unix-wizards Subject: Re: TCP/IP Communications (on a tty line) References: <16475@sri-arpa.UUCP> I have modified the 4.2BSD TCP/IP facility to work over serial lines in addition to the currently supported devices. It supports the full TCP/IP functionality just like all the other devices (although obviously slower). One instalation is running an IMP, ethernet and several serial lines, so there shouldn't be any problems with compatibility. As, a bonus, it will talk to systems running UNET. (It uses the same line encapsulation as UNET. This was determined with a line monitor, so there should be no problems distributing it. It's not very clever anyway. Just a frame marking character and an escape so you can have a frame character embedded in your data). There are basically 4 files involved. One is a user mode program, /etc/slattach, which configures a tty as a device (I decided not to build in specific lines when the kernel was built. It is much more flexible to do it in the /etc/rc file.) The others are kernel modules. One is /sys/vaxif/if_sl.c (sl for serial line). The others are modified net/route.c and net/ip.c It was necessary to modifiy the routing, because the 4.2 implementation cannot handle the idea of more than one physical device (each serial line is treated as if it were a seperate device) on one logical network. This means that if you wanted all of your machines to be on the same logical network(e.g. a class C network hanging off of an ARPAnet imp), the old code couldn't handle it. It would shove everything onto the Ethernet (if you had one) instead of checking for a more specific connection. This implementation goes through part of the tty driver. I did it this way so I would not have to write a specific driver for every dz/dh/dmf in creation. Files transfer at about 8500 baud on a 9600 baud line. (The ip and tcp headers are not counted, so it's using most of the line). There doesn't seem to be much of an impact on the vax, so it probably isn't worth doing a device specific driver. Basically the way it works is that an outgoing packet is encapsulated and put on the clist (so it doesn't go through "most" of the tty driver). The tty structure is conned into thinking that it is running a different line discipline, so it hands over incoming characters to a routine which unencapsulates it and hands it to IP. It's been running here for about 4 months and seems quite stable. The only problem with distributing it (for the first few people anyway) would be making sure that I send you "eveything" I modified. I did the majority of the work 5 months ago, so I'm not 100% sure of all the routines I changed. I am willing to distribute it to anyone with a 4.2 source license. (I'm not sure what use it would be if you didn't have 4.2, but we might as well be paranoid about these things) Rick Adams ra@seismo.ARPA {ihnp4|philabs|hao|harpo|rlgvax}seismo!ra