TUHS

tuhs@tuhs.org

29 participants
6557 discussions

by Don Hopkins

(I originally posted this to hacker news, but I’ll repost it here too.) At the University of Maryland, our network access was through the NSA's "secret" MILNET IMP 57 at Fort Mead. It was pretty obvious that UMD got their network access via NSA, because mimsy.umd.edu had a similar "*.57" IP address as dockmaster, tycho and coins. https://emaillab.jp/dns/hosts/ HOST : 26.0.0.57 : TYCHO : PDP-11/70 : UNIX : TCP/TELNET,TCP/SMTP,TCP/FTP : HOST : 26.0.0.57 : DOCKMASTER.NCSC.MIL,DOCKMASTER.DCA.MIL, DOCKMASTER.ARPA : HONEYWELL-DPS-8/70 : MULTICS : TCP/TELNET,TCP/FTP,TCP/SMTP,TCP/ECHO,TCP/DISCARD,ICMP : HOST : 26.1.0.57 : COINS-GATEWAY,COINS : PLURIBUS : PLI :: HOST : 26.2.0.57, 128.8.0.8 : MARYLAND,MIMSY,UMD-CSD,UMD8,UMCP-CS : VAX-11/780 : UNIX : TCP/TELNET,TCP/FTP,TCP/SMTP,UDP,TCP/ECHO,TCP/FINGER,ICMP : https://multicians.org/site-dockmaster.html Whenever the network went down (which was often), we had to call up a machine room at Fort Mead and ask them to please press the reset button on the box labeled "IMP 57". Sometimes the helpful person who answered the phone had no idea which box I meant, so I had describe to him which box to reset over the phone. ("Nope, that didn't work. Try the other one!" ;) They were even generous enough to issue us (CS department systems staff and undergrad students) our own MILNET TACACS card. On mimsy, you could get a list of NSA employees by typing "grep contact /etc/passwd", because each of their courtesy accounts had "network contact" in the gecos field. Before they rolled out TACACS cards, anyone could dial up an IMP and log in without a password, and connect to any host they wanted to, without even having to murder anyone like on TV: https://www.youtube.com/watch?v=hVth6T3gMa0 I found this handy how-to tutorial guide for "Talking to the Milnet NOC" and resetting the LH/DH, which was useful for guiding the NSA employee on the other end of the phone through fixing their end of the problem. What it doesn't mention is that the key box with the chase key was extremely easy to pick with a paperclip. Who would answer the Milnet NOC's 24-hour phone was hit or miss: Some were more helpful and knowledgeable than others, others were quite uptight. Once I told the guy who answered, "Hi, this is the University of Maryland. Our connection to the NSA IMP seems to be down." He barked back: "You can't say that on the telephone! Are you calling on a blue phone?" (I can't remember the exact color, except that it wasn't red: that I would have remembered). I said, "You can't say NSA??! This is a green phone, but there's a black phone in the other room that I could call you back on, but then I couldn't see the hardware." And he said "No, I mean a voice secure line!" I replied, "You do know that this is a university, don't you? We only have black and green phones.” Date: Thu, 11 Sep 86 13:53:45 EDT From: Steve D. Miller <steve(a)brillig.umd.edu> To: staff(a)mimsy.umd.edu Subject: Talking to the Milnet NOC This message is intended to be a brief tutorial/compendium of information you probably want to know if you need to see about getting the LH/DH thingy (and us) talking to the world. First, you need the following numbers: (1) Our IMP number (57), (2) Mimsy's milnet host address (26.2.0.57), (3) The circuit number for our link to the NSA (DSEP07500-057) (4) The NOC number itself (692-5726). Second, you need to know something about the hardware. There are three pieces of hardware that make up our side of the link: the LH/DH itself, the ECU, and the modem. The LH/DH and the ECU are the things in the vax lab by brillig; the ECU is the thing on top (with the switches), and the LH/DH is the thing on the bottom. The normal state is to have the four red LEDs on the ECU on and the Host Master Ready, HRY, Imp Master Ready, and IRY lights on at the LH/DH. If these lights are not on, something is wrong. If mimsy is down, then we'll only have some of the lights on, but that should fix itself when mimsy comes up. Some interesting buttons or switches on the ECU are: reset - resets something or another stop - stops something or another start - restarts something or another local loopback -- two switches and two leds; you may need to throw one or the other of these if the NOC asks you to. These loopback switches should be distinguished from those on the modem itself. remote loopback -- like local loopback, but does something else. The modem is in the phone room beside the terminal room (rm. 4322, if memory serves). It can be opened with the chase key from the key box...but if someone official and outside of staff asks you that, you probably shouldn't admit to it. It has a switch on it, too; it seems that switch normally rests in the middle, and there's a "LL" setting to the left which I assume puts the modem in local loopback mode. Now that you have some idea of where things are, call the NOC. Identify yourself as from the University of Maryland, and say that we're not talking to the outside world. They will probably ask for our Milnet address or the number of the IMP we're connected to, and will then poke about and see what's happening. They will ask you to do various things; ask if you're not sure what they mean, but the background info above should help in puzzling it out. Hopefully, this will make it easier to find people to fix our net problems in the future; it's still hard to do 'cause we have so little info (no hardware manual, for example), but this should give us a fighting chance. -Steve There were rumored to be "explosive bolts" on the ARPA/MILNET gateways (whether they were metaphorical or not, I don't know). Here's something interesting that Milo Medin wrote about dual homed sites like NSA and NASA, that were on both the ARPANET and MILNET: To: fair(a)ucbarpa.berkeley.edu (Erik E. Fair) Cc: Hackers_Guild(a)ucbvax.berkeley.edu, ucdavis!ccohesh(a)ucbvax.berkeley.edu Subject: Re: a question of definition Date: Thu, 29 Jan 87 15:33:35 PST From: Milo S. Medin (NASA ARC Code ED) <medin(a)orion.arpa> Right, the core has many gateways on it now, maybe 20-30. All the LSI's will be stubbed off the core however, and only buttergates will be left after the mailbridges and EGP peers are all converted. Actually, I think DARPA is paying for it all... Ames is *not* getting a mailbridge. You are right of course, that we could use 2 gateways, not just 1 (actually, there will be a prime and backup anyways), and then push routing info appropriately. But that's anything but simple. Firstly, the hosts have to know which gateway to send a packet to a given network, and thus have to pick between the 2. That's a bad idea. It also means that I have to pass all EGP learned info around on the local cable, and if I do that, then I can't have routing info from the local cable pass out via EGP. At least not without violating the current EGP spec. Think about it. It'd be really simple to create a loop that way. Thus, in order to maximize the use of both PSN's, you really need one gateway wired to both PSN's, and just have it advertise a default route inside. Or use a reasonble IGP, of which RIP (aka /etc/routed stuff) is not. I'm hoping to get an RFC out of BBN at this IETF meeting which may go a long way in reducing the use of RIP as an IGP. BTW, NSA is an example of a site on both MILNET and ARPANET but without a mailbridge... There is no restriction that a network can only be on ARPANET or MILNET. That goes against the Internet model of doing things. Our local NASA gatewayed nets will be advertised on both sides. The restriction on BARRNet is that the constituent elements of BARRNet do not all have access to MILNET. NSF has an understanding with DARPA and DCA that NSFnet'd sites can use ARPANET. That does not extend to the MILNET. Thus, Davis can use UCB's or Stanford's, our even NASA's ARPANET gateways, with the approval of the site of course, but not MILNET, even though NASA has MILNET coverage. Thus we are required to restrict BARRNet routing through our MILNET PSN. If we were willing to sponsor UCB's MILNET access, for some requirement which NASA had to implement, then we would turn that on. But BARRNet itself will but cutoff to MILNET (and probably ARPANET too) at Ames, but not cut off to other NASA centers or sites that NASA connects. There is no technical reason that prevents this, in fact, we have to take special measures to prevent it. But those are the rules. Anyways, mailbridge performance should improve after the conversion, so UCB should be in better shape. And you'll certainly be able to talk to us via BARRNnet... I have noticed recently that MILNET<-> ARPANET performance has been particularly poor... Sigh. The DCA folks feel that in case of an emergency they may be forced to use an unsecure network to pass certain info around. The DDN brochure mentions SIOP related data for example. Who knows, if the balloon goes up, the launch order might pass through Evans Hall on its way out to SAC... :-) Milo I dug up an "explosive bolts" reference -- fortunately that brilliant plan didn't get far. (Milo Medin knows this stuff first hand: https://innovation.defense.gov/Media/Biographies/Bio-Display/Article/139585… ) To: fair(a)ucbarpa.berkeley.edu (Erik E. Fair) Cc: ucdavis!ccohesh(a)ucbvax.berkeley.edu, Hackers_Guild(a)ucbvax.berkeley.edu Subject: Re: a question of definition Date: Thu, 29 Jan 87 12:29:36 PST From: Milo S. Medin (NASA ARC Code ED) <medin(a)orion.arpa> Actually its: SCINET -- Secret Compartmented Information Net (if you don't know what compartmented means, you don't need to ask) DODIIS -- DoD Intelligence Information Net The other stuff I think is right, at least without me looking things up. I probably shouldn't have brought this subject of the secure part of the DDN up. People like being low key about such things... Erik, all the BBN gateways on MILNET and ARPANET currently comprise the core, not just mailbridges. Some are used as site gateways, others as EGP neighbors, etc... And just because you are dual homed doesn't mean you get a mailbridge. And the IETF doesn't deal with low level stuff like that; DCA does all that. In fact, the reason we are getting an ARPANET PSN is because when DCA came out to do a site survey, they liked our site so much they asked if they could put one here! It's amazing how many sites have tried to get ARPANET PSN's the right way and have had to wait much longer than us... BTW, since we are dual homed (probably a gateway with 2 1822 interfaces in it), we are taking steps to be sure that people on ARPANET or MILNET can't use our gateway to bypass the mailbridges. The code will be hacked to drop all packets that aren't going to a locally reachable network. BARRNet, even though its locally reachable, will be excluded from this however, since the current procedural limitations call for not allowing any BARRNet traffic to flow out of BARRNet to MILNET and the reverse. NASA traffic of course can traffic through BARRNet, and even use ARPANET that way (though that's not a big deal when we get our own ARPANET PSN). That's because only NASA is authorized to directly connect to MILNET, not UCB or Stanford, etc... DCA must have the ability to partition the ARPANET and MILNET in case of an "emergency", and having non-DCA controlled paths between the nets prevents that. There was talk some time ago about putting explosive bolts in the mailbridges that would be triggered by destruct packets... That idea didn't get far though... The DDN only includes MILNET,ARPANET,SCINET,etc... Not the attached networks. If it did, you'd need to file a TSR to add a PC to your local cable. A TSR is a monstrous piece of paperwork that needs to be done anytime anything is changed on the DDN... Rick knows all about them don't you Rick? The whole network game is filled with acronyms! I gave up trying to write documents with full explainations in terms long ago... I have yet to see a short and concise (and correct) way of describing DDN X.25 Standard Service for example... That's probably one of the harder things about getting into networking these days. We won't even talk about Etherbunnies and Martians and other Millspeak... Milo '1822' Medin

6 years, 7 months

Magic numbers

by ron＠ronnatalie.com

The issue of a.out magic numbers came up. The a.out header was 16 bytes. The first two bytes was 0407 in the original code. This was followed by 16 bit quantities for text, data, and bss sizes. Then the size of the symbol tables. I'm pretty sure the rest of the fields were blank in V6. Later a start address (previously always assumed to be zero) was added. The number 407 was a neat kludge. It was a (relative) branch instruction on the PDP-11. 0400 was the base op code. 7 referred to jumping ahead 7 words which skipped you over the a.out header (the PC had already been incremented for the branch instruction itself). This allowed you to make a boot block without having to strip off the header. Boot blocks were just one 512 byte block loaded from block zero of the disk into low memory. Later executables used 410 for a write protected text segment and 411 for split-I/D executables. Later versions added more codes (413 was used in BSD to indicate aligned pages followed etc... Even later systems coded the hardware type into the magic number to distinguish between different architectures. Note that the fact that 410 and 411 were also PDP-11 branch instructions wasn't ever really used for anything.

6 years, 7 months

ARPAnrt, and the Unix epoch

by Dave Horsfall

According to my notes, the ARPAnet was converted from NCP to TCP on this day in 1983; except for a temporary dispensation for a few hosts, NCP support was switched off. And as every Unix geek knows, today in 1970 is Unix's time epoch. Trivia: I found a web site that thinks that that's my birthday! Not even close; try October 1952 instead... -- Dave

6 years, 7 months

Re: [TUHS] Deleted lib1 and lib2 in v6, recoverable?

by Norman Wilson

Warner Losh: But wasn't it tsort that did the heavy lifting to get things in order? ar c foo.a `tsort *.o` Ranlib just made it fast by adding an index.. ==== There's a little more than that to ranlib. Without ranlib, ld made a single pass through each library, loading the modules that resolved unresolved symbols. If a module itself had unresolved symbols (as many do) and some of those symbols were defined in a module ld had already passed, you were out of luck, unless you explicitly told ld to run a second pass, e.g. cc x.o y.o -la -la. Hence the importance of explicit ordering when building the library archive, and the usefulness of tsort. Ranlib makes a list of all the .o file in this archive and the global symbols defined or used by each module, and places the list first in the archive. If ld is (as it was) changed to recognize the index, it can then make a list of all the object files needed from this archive, even if needed only by some file it will load from the same archive, then collect all required modules in a single pass. Ld could all along have just made two passes through the library, one to assemble the same list ranlib did in advance, a second to load the files. (Or perhaps a first pass to load what it knows it needs and assemble the list, and a second only if necessary.) Presumably it didn't both to make ld simpler and because disk I/O was much slower back then (especially on a heavily-loaded time-sharing system, something far less common today). I suspect it would work fine just to do it that way today. Nowadays ranlib is no longer a separate program: ar recognizes object files and maintains an index if any are present. I never especially liked that; ar is in principle a general tool so why should it have a special case for one type of file? But in practice I don't know anyone who uses ar for anything except libraries any more (everyone uses tar for the general case, since it does a better job). Were I to wave flags over the matter I'd rather push to ditch ar entirely save for compatibility with the past, move to using tar rather than ar for object libraries, and let ld do two passes when necessary rather than requiring that libraries be specially prepared. As I say, I think modern systems are fast enough that that would work fine. Norman Wilson Toronto ON

6 years, 7 months

Idea of Small Curators Group for Unix Archive

by Warren Toomey

Happy New Year to you all. It's also the year we will celebrate the 50th anniversary of the Unix timesharing system. Just FYI, I hope to be in Los Angeles the week before the 2019 Usenix ATC, to go to the CHM. Then to Seattle before the ATC to visit the LCM+L, then the ATC. Hope to see some of you along the way. I'm feeling the need to get a few other people to help out curate and maintain the Unix Archive. Not that it changes very often, but it might help to have some fresh eyes (and opinions) look at it and add/improve it. So if there is any interest from a few of the long-time TUHS members, please e-mail me. I run Nextcloud on the server, so if you can run a client at your end and have about 4G spare disk space (or less if you are only interested in a specific section), that would be great. I'll be away for about 7 days but I'll try to read/respond to e-mails. Cheers, Warren

6 years, 7 months

NCC a K&R C compiler for the AMD 64

by Jason Stevens

I found this project online recently. For those who love K&R and the 64 bit world. https://github.com/gnuless/ncc It outputs to a custom a.out format so it's not immediately usable. It's a dual clause BSD license too!

6 years, 7 months

Upgrading from 11/40 to 11/45 in Unix v6

by Will Senn

Dear Unix Enthusiasts, We are seriously considering upgrading our PDP 11/40 clone (SIMH), to a PDP 11/45 (preferably another SIMH) for our Unix v6 installation. Our CEO was traveling and met a techie in first class (seriously, first class?) who told him that we needed one. I thought I had better ask some folks who have gone before about it before we jumped on the bandwagon. By way of background, Our install is pretty small with a few rk’s and 256K of ram along with a few standard peripherals, and some stuff our oldtimers refuse to part with (papertape, card punch, etc). It has fairly low utilization - a developer logs in and writes code every few days and the oldtimers hunt the wumpus and play this weird Brit game about cows. It could be considered a casual development and test environment and an occasional gaming console. Here is what I would like to know that I think y’all might be particularly equipped to answer: 1. Are there any v6 specific concerns about upgrading? 2. Why should we consider taking the leap to the 11/45? Everything seems to work fine now. 3. If we jump in and do the upgrade, how can we immediately recognize what has changed in the environment? I.e what are some things that we can now do that we couldn’t do before? 4. If we just insert our current diskpacks into the new system, will it just boot and work? Or what do we need to before/after booting to prepare/respond to the new system? 5. Is 256K enough memory or what configuration do y’all recommend? 6. Is there anything else we need to know about? Regards, Will Sent from my iPhone

6 years, 7 months

Re: [TUHS] building world using sh run in /usr/source in v6

by jnc＠mercury.lcs.mit.edu

> From: Larry McVoy > And cron is really 3246 bytes? And 2054 for init? Don't those seem too > small? Linux's cron is 44472 and that's with shared libs No, 3246 is the same as mine, and my init (which has a few changes from stock) is 2064. I'm not surprised the later one is 44KB - that's in part due to the denseness of PDP-11 binary (and the word-size is only 16 bits), but more broadly, I expect that it goes to my complaint about later Unixes - they've lost, IMO, the single most important thing about the PDP-11 Unixes, which is their bang/buck ratio. Noel

6 years, 7 months

Almost forgot: In Memoriam: Grace Hopper

by Dave Horsfall

We lost Rear Admiral "Amazing" Grace Hopper on this day in 1992; amongst other things she gave us COBOL and ADA, and was allegedly responsible for the term "debugging" when she removed a moth from a relay on the Harvard Mk I. -- Dave

6 years, 7 months

Re: [TUHS] Upgrading from 11/40 to 11/45 in Unix v6

by jnc＠mercury.lcs.mit.edu

> From: Will Senn > We are seriously considering upgrading our PDP 11/40 clone (SIMH), to a > PDP 11/45 (preferably another SIMH) Heh! When I saw the subject line, I thought you wanted to upgrade a _physical_ -11/40 to an -11/45. ('Step 1. Sell the -11/40. Step 2. Buy an -11/45.' :-) > for our Unix v6 installation. Why on earth would an organization have such a thing? :-) > Our CEO was traveling and met a techie in first class (seriously, > first class?) who told him that we needed one. Heh. If said techie knows about the two, he's probably pretty senior (i.e. eligible for Social Security :-), and thus elegible for first class... :-) > It has fairly low utilization - a developer logs in and writes code > every few days Who the *&%^&*(%& is still writing code under V6?! And how do you all get the bits in and out? (I run mine under Ersatz-11, which has this nice device which allows it to read files off the host file system; transfering stuff back and forth is a snap, I do all my editing with Epsilon on my Windoze box, 'cause I'm too lazy to bring up the V6 Emacs I have.) > 1. Are there any v6 specific concerns about upgrading? Not that I know of. > 2. Why should we consider taking the leap to the 11/45? Everything > seems to work fine now. You're asking _us_? Some larger applications will only run on an split-I-D machine, is about the only reason I can think of. Oh, also, the floating point instructions on the /45 are the only kind understood by V6; the C compiler doesn't emit the ones the /40 provides. Any floating point code run on the /40, the instructions are simulated by a trap handler (by way of the OS, which has to handle it and reflect it to the user process). I.e. very slow. > 3. If we jump in and do the upgrade, how can we immediately recognize > what has changed in the environment? I.e what are some things that we > can now do that we couldn't do before? See above. > 4. If we just insert our current diskpacks into the new system, will it > just boot and work? Or what do we need to before/after booting to > prepare/respond to the new system? Any V6 disk pack can be read/mounted on any V6 machine. Any binaries (the OS, or user commands) for the -11/40 will run on the -/45. (Which is why the V6 dist includes binaries for /40 versions of the OS only.) To make use of the /45, you need a different copy of the OS binary, built from a slightly different set of modules. (Replace m40.s with m45.s; and you will need to re-asssemble l.s, prepending it with data.s.) Both variants can live on the same pack, under different filenames; select the right one at boot time. > 5. Is 256K enough memory or what configuration do y'all recommend? 256KB is all you can have. Neither SIMH nor Ersatz-11 support the Able ENABLE: http://gunkies.org/wiki/Able_ENABLE which is what you need to have more than 256KB on a UNIBUS -11. > From: Clem Cole > You'll probably want to configure a kernel for the 45 class machine. > Look at the differences in the *.s files in the kernel. More importantly, look at the 'run' file in /usr/sys, which has commented out lines to build the OS image for /45-/70 class machines. > But either way you should configure the system to use the largest drive > v6 has. This is actually of limited utility, since a V6 file system is restricted to 65K blocks _max_. So a disk with 350K blocks (like an RP06), you'll have to split it into like 5 partitions to use it all. > From: Will Senn > Do you know of some commonly used at the time v6 programs that needed > that much space? Heh. Spun up my v6, and did "file * | grep separate" in /bin and /usr/bin, and then recalled that V6 was distributed in a form suitable for a /40. So, null set. Did the same thing on /bin from the MIT V6+ system, and got: a68: separate I&D executable not stripped a86: separate I&D executable not stripped bteco: separate I&D executable not stripped c86: separate I&D executable not stripped e: separate I&D executable not stripped emacs: separate I&D executable not stripped lisp: separate I&D executable not stripped mail: separate I&D executable not stripped ndd: separate I&D executable not stripped s: separate I&D executable not stripped send: separate I&D executable not stripped teco: separate I&D executable not stripped No idea what the difference is between 'teco' and 'bteco', what 's/send' do, etc. > Is there any material difference between doing it at install time vs > having run on 11/40 for a while and moving the disk over to the 11/45 > later? No; like I said, you can have two different OS binaries on the disk, and select which one you boot. > On a related note, how difficult is it to copy the system from rk to > hp? I know I can rebuild, but I'm sure there's a quicker/easier method... Build a system with both, and then copy the files? I'd use 'tar' (I have a V6 tar, but it uses a modified OS with the smdate() call added back in) to do the moving (which would retain the last-write dates); 'tp' or 'stp' would also work. The hack _I_ used on simulated systems was to expand the file that held the 'disk pack', mount it as a different kind of pack (RL or RP), and then go in and hand-patch the disk size in the root block with 'db', then 'icheck -s' to re-build the free list. Note: this won't give you more inodes, so you may run out, but the usual inode allocation is pretty generous. Noel PS: Speaking of the last write dates, I have versions of mv/mvall, cp/cpall, ln, chmod etc which retain them (using smdate()). If there's an actual community of people using V6, I should upload all the stuff I have. Although it might be good to establish some central location for exchange of V6 code. However, I don't and won't (don't even ask) use GitHub or any similar modern thing.

6 years, 7 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS