[TUHS] TCP/IP networking in 8th edition unix

[TUHS] TCP/IP networking in 8th edition unix

[Paul Ruizendaal]

I'm trying to figure out how tcp/ip networking worked in 8th edition Unix.

I'm starting from dmr's paper about streams (http://cm.bell-labs.co/who/dmr/st.html), the V8 man pages (http://man.cat-v.org/unix_8th/3/) and browsing the source code (tarball here http://www.tuhs.org/Archive/Distributions/Research/Dan_Cross_v8/).

In the below I use 'socket' to mean a file descriptor bound to a network connection. My current understanding is like this:

- The hardware interface is exposed as a character device; for tcp/ip only ethernet is supported. Directly accessing this device reads/writes ethernet frames.

- One can push an 'ip' module (only) onto an ethernet device; this module also handles ARP. Once this is done IP messages are queued to the virtual ip devices, /dev/ipXX. The device minor number XX equals the protocol number, i.e. the ip packets are demultiplexed into separate virtual devices. IP packets from multiple ethernet cards all end up on the same virtual ip devices. I'm not sure if one can still read/write to the ethernet device after pushing the ip module, but I think you can, creating a raw IP interface so to say.

- On /dev/ip6 one can push a TCP module. The TCP module handles the TCP protocol and demultiplexes incoming traffic to the virtual /dev/tcpXX devices. On /dev/ip17 one can push a UDP module. The UDP module handles the UDP protocol and demultiplexes incoming traffic to the virtual /dev/udpXX devices. Not sure wether the ip6 and ip17 devices can still be read/written after pushing these disciplines.

- There are 100 udp devices, /dev/updXX. To open a UPD socket, one opens an unused udp device (through linear search). This socket accepts binary commands ('struct upduser') through the read()/write() system calls. There is a command to set the local port (effectively 'bind') and a comment to also set the foreign address and port (effectively 'bind+connect'). As long as the socket is not connected actual datagrams are preceded by a command header with the address/port information (effectively 'sendto'/'recvfrom'). Once the socket is connected, it is no longer possible to send further commands, but each write/read is a datagram. For udp sockets it is not possible to specify the local address: it is chosen by the system to match with the given foreign address.

- There are 100 tcp devices /dev/tcpXX. Initial connection is always over an odd numbered device. To open a TCP socket, one opens an unused tcp device (through linear search). This socket accepts binary commands ('struct tcpuser') through the read()/write() system calls. There is a command to actively connect (effectively 'connect' with optional 'bind'), and a command to passively listen (effectively 'bind'+'listen'). If the connect command is sent, one can read one more response block and then the socket becomes a regular tcp socket. If the listen command is sent, one can read multiple response blocks, one for each new client (effectively 'accept'). Those response blocks contain a device number for the new client connection, i.e. one has to subsequently open device /dev/tcpXY to talk to the client. This number is always even, i.e. locally initiated tcp connections are over odd numbered tcp devices, and remotely initiated connections are over even numbered tcp devices - not sure what the significance of this is.

- The above seems to be modeled on the Datakit setup, where the network is exposed as 520 virtual devices, one for each channel, as /dev/dk/dkXXX. These channels than also seem to accept binary command blocks through the read()/write() interface, with a 'connect' type command changing the connection into a data only channel.


Anybody on the list with 8th edition experience who can confirm that the above understanding is about correct?

Paul

[TUHS] TCP/IP networking in 8th edition unix

[Paul Ruizendaal]

Found a post by dmr about this in the 'net.unix-wizards' newsgroup:
https://groups.google.com/forum/#!topicsearchin/net.unix-wizards/subject$3Astreams/net.unix-wizards/b7W_j_0qASU

It would seem that my understanding of it is indeed how dmr designed it.

At the end of the post there is an example: "For example, from my machine, I can type "rlogin purdy" and connect to a Sequent machine running 4.2; the TCP connection goes over Datakit to machine "research" where it is gatewayed to a local ethernet that purdy is connected to."

I'm not quite sure how on the Sequent machine the Datakit channel would be hooked up to the 4.2BSD TCP stack. Perhaps something equivalent to e.g. 'SLiRP' was used, perhaps there was a pseudo device that hooked into the network interface layer.

Paul

Begin forwarded message:

> From: Paul Ruizendaal <pnr at planet.nl>
> Subject: TCP/IP networking in 8th edition unix
> Date: 22 November 2017 0:41:27 GMT+01:00
> To: TUHS main list <tuhs at minnie.tuhs.org>
> 
> 
> I'm trying to figure out how tcp/ip networking worked in 8th edition Unix.
> 
> I'm starting from dmr's paper about streams (http://cm.bell-labs.co/who/dmr/st.html), the V8 man pages (http://man.cat-v.org/unix_8th/3/) and browsing the source code (tarball here http://www.tuhs.org/Archive/Distributions/Research/Dan_Cross_v8/).
> 
> In the below I use 'socket' to mean a file descriptor bound to a network connection. My current understanding is like this:
> 
> [... details removed ...]

> Anybody on the list with 8th edition experience who can confirm that the above understanding is about correct?
> 
> Paul
> 
> 
> 

[TUHS] TCP/IP networking in 8th edition unix

[William Cheswick]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3102 bytes --]

> On 24Nov 2017, at 6:52 PM, Paul Ruizendaal <pnr at planet.nl> wrote:
> 
> Found a post by dmr about this in the 'net.unix-wizards' newsgroup:
> https://groups.google.com/forum/#!topicsearchin/net.unix-wizards/subject$3Astreams/net.unix-wizards/b7W_j_0qASU <https://groups.google.com/forum/#!topicsearchin/net.unix-wizards/subject$3Astreams/net.unix-wizards/b7W_j_0qASU>
> 
> It would seem that my understanding of it is indeed how dmr designed it.
> 
> At the end of the post there is an example: "For example, from my machine, I can type "rlogin purdy" and connect to a Sequent machine running 4.2; the TCP connection goes over Datakit to machine "research" where it is gatewayed to a local ethernet that purdy is connected to."
> 
> I'm not quite sure how on the Sequent machine the Datakit channel would be hooked up to the 4.2BSD TCP stack. Perhaps something equivalent to e.g. 'SLiRP' was used, perhaps there was a pseudo device that hooked into the network interface layer.
> 
> Paul

Nope, not IP over Datakit, as I recall.  It was quite interesting to work at a site (Bell Labs) where there were two distinct network technologies.  

We connected to a lot of familiar services through Datakit using the application level.  For example, the smtp client in upas connected to an SMTP service thus:
       if ((s = ipcopen(path, "")) < 0) {
where path might be one of:
	tcp!bowell!smtp
	dk!coma/astro/nj!smtp
	inet!ftp.uu.net <http://ftp.uu.net/>!smtp

On V10 Unix and in Plan 9, these were handled by stuff that Dave Presotto wrote.  I distributed this code throughout internal AT&T.  

The first is the obvious tcp connection.  Datakit connected to a server running in V10’s equivalent to inetd.  The last one was a proxy connection, a circuit-level gateway running on a particular host that I supported for many years.  It had a little protocol and initiated the tcp link from the proxy machine.

These proxy machines had some interesting features.  For one, I could log the destination of volume of each connection.  For another, all connections to a sensitive site (think porn) seemed to come from the proxy host.  Some porn sites showed their top ten users, and several major corporations were represented there.

This library was socks about seven years before socks, originally written by Presotto and Howard Trickey.  The relay program was originally called “gated”, but that wouldn’t do after a while.  I renamed it “proxyd”, and that is the first use of “proxy" in this context that I am aware of.

 If you were on AT&T’s intranet and wanted to connect externally, you ripped out the entire socket dance and replaced it with an ipcopen call.  I also distributed common modified clients, like ptelnet, pftp, pfinger, etc.  

I still have all this code, and I suppose it ought to go in an archival repository.  I can’t imagine that AT&T/Lucent/Alcatel/Nokia would care at this point. Anyone want it?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171125/44e671fc/attachment.html>

[TUHS] TCP/IP networking in 8th edition unix

[Gregg Levine]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3354 bytes --]

Hello!
Ordinarily I would say "Yes!", but given this list, I'd promptly
suggest that if it isn't already available via our host's site, then
he's got first dibs, and then I'll get my copy for a local mirror.

But that's definitely a very interesting method of networking hardware
together then.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."


On Sat, Nov 25, 2017 at 4:50 PM, William Cheswick <ches at cheswick.com> wrote:
> On 24Nov 2017, at 6:52 PM, Paul Ruizendaal <pnr at planet.nl> wrote:
>
> Found a post by dmr about this in the 'net.unix-wizards' newsgroup:
> https://groups.google.com/forum/#!topicsearchin/net.unix-wizards/subject$3Astreams/net.unix-wizards/b7W_j_0qASU
>
> It would seem that my understanding of it is indeed how dmr designed it.
>
> At the end of the post there is an example: "For example, from my machine, I
> can type "rlogin purdy" and connect to a Sequent machine running 4.2; the
> TCP connection goes over Datakit to machine "research" where it is gatewayed
> to a local ethernet that purdy is connected to."
>
> I'm not quite sure how on the Sequent machine the Datakit channel would be
> hooked up to the 4.2BSD TCP stack. Perhaps something equivalent to e.g.
> 'SLiRP' was used, perhaps there was a pseudo device that hooked into the
> network interface layer.
>
> Paul
>
>
> Nope, not IP over Datakit, as I recall.  It was quite interesting to work at
> a site (Bell Labs) where there were two distinct network technologies.
>
> We connected to a lot of familiar services through Datakit using the
> application level.  For example, the smtp client in upas connected to an
> SMTP service thus:
>        if ((s = ipcopen(path, "")) < 0) {
> where path might be one of:
> tcp!bowell!smtp
> dk!coma/astro/nj!smtp
> inet!ftp.uu.net!smtp
>
> On V10 Unix and in Plan 9, these were handled by stuff that Dave Presotto
> wrote.  I distributed this code throughout internal AT&T.
>
> The first is the obvious tcp connection.  Datakit connected to a server
> running in V10’s equivalent to inetd.  The last one was a proxy connection,
> a circuit-level gateway running on a particular host that I supported for
> many years.  It had a little protocol and initiated the tcp link from the
> proxy machine.
>
> These proxy machines had some interesting features.  For one, I could log
> the destination of volume of each connection.  For another, all connections
> to a sensitive site (think porn) seemed to come from the proxy host.  Some
> porn sites showed their top ten users, and several major corporations were
> represented there.
>
> This library was socks about seven years before socks, originally written by
> Presotto and Howard Trickey.  The relay program was originally called
> “gated”, but that wouldn’t do after a while.  I renamed it “proxyd”, and
> that is the first use of “proxy" in this context that I am aware of.
>
>  If you were on AT&T’s intranet and wanted to connect externally, you ripped
> out the entire socket dance and replaced it with an ipcopen call.  I also
> distributed common modified clients, like ptelnet, pftp, pfinger, etc.
>
> I still have all this code, and I suppose it ought to go in an archival
> repository.  I can’t imagine that AT&T/Lucent/Alcatel/Nokia would care at
> this point. Anyone want it?
>
>

[TUHS] TCP/IP networking in 8th edition unix

[Brad Spencer]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2861 bytes --]

William Cheswick <ches at cheswick.com> writes:

[snip]

>> Paul
>
> Nope, not IP over Datakit, as I recall.  It was quite interesting to work at a site (Bell Labs) where there were two distinct network technologies.  
>
> We connected to a lot of familiar services through Datakit using the application level.  For example, the smtp client in upas connected to an SMTP service thus:
>        if ((s = ipcopen(path, "")) < 0) {
> where path might be one of:
> 	tcp!bowell!smtp
> 	dk!coma/astro/nj!smtp
> 	inet!ftp.uu.net <http://ftp.uu.net/>!smtp
>
> On V10 Unix and in Plan 9, these were handled by stuff that Dave Presotto wrote.  I distributed this code throughout internal AT&T.  
>
> The first is the obvious tcp connection.  Datakit connected to a server running in V10’s equivalent to inetd.  The last one was a proxy connection, a circuit-level gateway running on a particular host that I supported for many years.  It had a little protocol and initiated the tcp link from the proxy machine.
>
> These proxy machines had some interesting features.  For one, I could log the destination of volume of each connection.  For another, all connections to a sensitive site (think porn) seemed to come from the proxy host.  Some porn sites showed their top ten users, and several major corporations were represented there.
>
> This library was socks about seven years before socks, originally written by Presotto and Howard Trickey.  The relay program was originally called “gated”, but that wouldn’t do after a while.  I renamed it “proxyd”, and that is the first use of “proxy" in this context that I am aware of.
>
>  If you were on AT&T’s intranet and wanted to connect externally, you ripped out the entire socket dance and replaced it with an ipcopen call.  I also distributed common modified clients, like ptelnet, pftp, pfinger, etc.  
>
> I still have all this code, and I suppose it ought to go in an archival repository.  I can’t imagine that AT&T/Lucent/Alcatel/Nokia would care at this point. Anyone want it?


I used this code when I worked at 6200 Broad St. in Reynoldsburg.
Someone hooked it into the web browsers at the time which would have
been Mosaic.  At some point I got a hold of the client side code and I
"ported" it to NetBSD so I could use utilities when I was dialed back
into the company.  I think I hooked it into ssh at one point, but it has
been a long time, and I don't exactly remember.  I know I hooked in the
NetBSD ftp and telnet clients.

I do know that at 6200, and probably company wide, this whole scheme was
replaced by filtering firewalls of some ilk and the proxy gateway was
done away with.  That would have been early 2000s or so, assuming my
memory is not faulty.





-- 
Brad Spencer - brad at anduin.eldar.org - KC8VKS
http://anduin.eldar.org  - & -  http://anduin.ipv6.eldar.org [IPv6 only]

[TUHS] TCP/IP networking in 8th edition unix

[Paul Ruizendaal]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1845 bytes --]

Thanks for explaining that. I think it may be for 10th edition though.

I searched for ipcopen() and 'gated' in the 8th edition source and could
not find them. In that search I did find a few bits that strongly suggest that
IP over Datakit was what was used in late '85 (when dmr posted about this).

In /usr/src/cmd/inet/READ_ME there is an example configuration that seems
to match with dmr's example. In that file an IP over a Datakit channel
appears to be configured.
(see http://chiselapp.com/user/pnr/repository/v8unix/artifact/6d09b05c7f06a2cc?ln=119-120)

The program 'dkipconfig' sets up a circuit and pushes the IP discipline on
the stream, both on the local end and on the remote end. It sets fixed local
and remote addresses, much the same as with a 'slip' line.
(see http://chiselapp.com/user/pnr/repository/v8unix/artifact/6c5f3267b58721a6?ln=78,91)
 
On Sat, Nov 25, 2017 at 4:50 PM, William Cheswick <ches at cheswick.com> wrote:
>
> Nope, not IP over Datakit, as I recall.  It was quite interesting to work at
> a site (Bell Labs) where there were two distinct network technologies.
>
> [--snip--]
>
> This library was socks about seven years before socks, originally written by
> Presotto and Howard Trickey.  The relay program was originally called
> “gated”, but that wouldn’t do after a while.  I renamed it “proxyd”, and
> that is the first use of “proxy" in this context that I am aware of.
>
>  If you were on AT&T’s intranet and wanted to connect externally, you ripped
> out the entire socket dance and replaced it with an ipcopen call.  I also
> distributed common modified clients, like ptelnet, pftp, pfinger, etc.
>
> I still have all this code, and I suppose it ought to go in an archival
> repository.  I can’t imagine that AT&T/Lucent/Alcatel/Nokia would care at
> this point. Anyone want it?
>