TUHS

tuhs@tuhs.org

31 participants
6541 discussions

Re: [TUHS] V6 networking & alarm syscall

by Paul Ruizendaal

> / uses the system sleep call rather than the standard C library > / sleep (sleep (III)) because there is a critical race in the > / C library implementation which could result in the process > / pausing forever. This is a horrible bug in the UNIX process > / control mechanism. > > Quoted without comment from me! Intriguing comment. I think your v6+ system probably has a lot of PWB stuff in there. The libc source for sleep() in stock V6 is: .globl _sleep sleep = 35. _sleep: mov r5,-(sp) mov sp,r5 mov 4(r5),r0 sys sleep mov (sp)+,r5 rts pc The PWB version uses something alarm/pause based, but apparently gets it wrong: .globl _sleep alarm = 27. pause = 29. rti = 2 _sleep: mov r5,-(sp) mov sp,r5 sys signal; 14.; 1f mov 4(r5),r0 sys alarm sys pause clr r0 sys alarm mov (sp)+,r5 rts pc 1: rti I think the race occurs when an interrupt arrives between the sys alarm and the sys pause lines, and the handler calls sleep again. sleep() in the V7 libc is a much more elaborate C routine. When I first read the race condition comment, I thought the issue would be like that of write: _write: mov r5,-(sp) mov sp,r5 mov 4(r5),r0 mov 6(r5),0f mov 8(r5),0f+2 sys 0; 9f bec 1f jmp cerror 1: mov (sp)+,r5 rts pc .data 9: sys write; 0:..; .. This pattern appears in several V6 sys call routines, and would not be safe when used in a context with signal based multi- threading.

6 years, 6 months

Re: [TUHS] V6 networking & alarm syscall

by jnc＠mercury.lcs.mit.edu

> From: Dave Horsfall > As I dimly recall ... it returns the number of characters in the input > queue (at that time) Well, remember, this is the MIT V6 PDP-11 system, which had a tty driver which had been completely re-written at MIT years before, so you'd really have to check the MIT V6 sources to see exactly what it did. I suspect they borrowed the name, and basic semantics, from Berkeley, but everything else - who knows. This user telnet is from 1982 (originally), but I was looking at the final version, which is from 1984; the use of the ioctl was apparently a later addition. I haven't checked to see what it did originally for reading from the user's terminal (although the earlier version also used the 'tasking' package). Noel

6 years, 6 months

Re: [TUHS] V6 networking & alarm syscall

by jnc＠mercury.lcs.mit.edu

> From: Paul Ruizendaal > It would not seem terribly complex to add non-blocking i/o capability to > V6. ... Adding a 'capacity' field to the sgtty interface would not > have been a big leap either. ... > Maybe in the 1975-1980 time frame this was not felt to be 'how Unix does > it'? This point interested me, so I went and had a look at how the MIT V6+/PWB TCP/IP did it. I looked at user TELNET, which should be pretty simple (server would probably be more complicated, due to PTY stuff). It's totally different - although that's in part because in the MIT system, TCP is in the user process, along with the application. In the user process, there's a common non-premptive 'tasking' package which both the TCP and TELNET code use. When there are no tasks ready to run, the process uses the sleep() system call to wait for a fixed, limited quantum (interrupts, i.e. signals, will usually wake it before the quantum runs out); note this comment: / uses the system sleep call rather than the standard C library / sleep (sleep (III)) because there is a critical race in the / C library implementation which could result in the process / pausing forever. This is a horrible bug in the UNIX process / control mechanism. Quoted without comment from me! There are 3 TCP tasks - send, receive and timer. The process receives an 'asynchronous I/O complete' signal when a packet arrives, and that wakes up the process, and then one of the tasks therein, to do packet processing (incoming data, acks, etc). There appears to be a single TELNET task, which reads from the user's keyboard, and sends data to the network. (It looks like processing of incoming data is handled in the context of one of the TCP tasks.) Its main loop starts with this: ioctl (0, FIONREAD, &nch); if (nch == 0) { tk_yield (); continue; } } if ((c = getchar()) == EOF) { so that ioctl() must look to see if there is any data waiting in the terminal input buffer (I'm too lazy to go see what FIONREAD does, right at the moment). Noel

6 years, 6 months

V6 networking & alarm syscall

by Paul Ruizendaal

Clem, Ron, Thanks for the explanations! Some comments below. >> 1. First of all: I understand that early Unix version numbers and dates >> mostly refer to the manual editions, and that core users had more >> frequent snapshots of a constantly evolving code base. > > Eh? They primarily refer to the distributions (Research V6, V7, PWB, the > various BSD tapes). > I'm not sure what "core users" are referring to. Most of us had many > versions as we hacked and merged the stock releasesx. I was too brief. I was referring just to the pre-V7 versions, and I had the implicit assumption that alarm() originated at the labs. My understanding was that the labels 5th, 6th and 7th edition had little meaning inside the labs, as there just was a continuously developing code base. Maybe this is a mis-understanding. > "alarm was introduced as part of Unix/TS" "PWB [..] had both sleep() and alarm() as system calls" Thanks for those pointers! I'm not sure I fully grasp the lineage of Unix/TS and PWB, but the TUHS wiki has a page about it: https://wiki.tuhs.org/doku.php?id=misc:snippets:mert1 From that, and from the TUHS Unix Tree web page I get that PWB1.0 from mid 1977 was probably the root source of alarm() for people outside AT&T. As PWB apparently got started much before that, it is possible that alarm() goes back much further as well. > A bigger networking issue was select() (or the like). It used to be an > interesting kludge of running two processes inorder to do simoultaneous > read/write before that. Yes: the NCP Unix team (Grossman/Holmgren/Bunch) also mentioned that as the big issue/annoyance that they ran into in 1975. As discussed in this list before, 3 years elapsed before Jack Haverty came up with await() for V6. I was told that there was a lot of discussion in the 4.1x/4.2 BSD steering group in 1981/2 whether this functionality should be stateful (like await) or stateless (like select). Looking at the implementations for both, I can see why stateless carried the day. > Right and select(2) was created by Sam and wnj during the 4.2 development. I've forgotten which sub-version (it was in 4.1c, but it might have been in b or a before that). There was a lot of arguing at the time about it's need; the multiple process solution was considered more 'Unix-like.' That is an interesting point, and it got me wondering about another related feature that could have been in Unix in the 1975-1980 time frame, being both useful and practical even on a 11/40 class machine, but for some reason wasn't: It would not seem terribly complex to add non-blocking i/o capability to V6. It could have been implemented as a TTY flag and it is not a big conceptual leap from EINTR to EAGAIN. Adding a 'capacity' field to the sgtty interface would not have been a big leap either. This would have allowed user processes to scan a number of tty lines e.g. once a second in a loop and do processing as needed. In NCP Unix this would not have been hard to extend to network pipes. The NCP Unix / Arpanet crowd certainly had a need for it, it would have been very useful for Spider/Datakit connections and probably for uucp as well. And from there it is not a million miles to replace the timed user loop with something like select(). Yet non-blocking I/O and select() only appear in 1982. Maybe in the 1975-1980 time frame this was not felt to be 'how Unix does it'?

6 years, 6 months

AT&T / Teletype DMD 5620 Emulator

by Seth J. Morabito

Hello folks, I realized I should mention this here on TUHS, since it is likely of interest to at least some of you! I recently wrote a DMD 5620 emulator, currently available on Linux and Macintosh, with Windows support coming soon. Here's a brief demo of the Mac version: https://www.youtube.com/watch?v=tcSWqBmAMeY I wrote it because DMD 5620s are becoming incredibly rare, and showing them off in person is quite difficult nowadays. This emulator is using ROM version 2.0 (8;7;5) dumped from my personal 5620. If anyone out there has a DMD 5620 with an older ROM, I would be incredibly grateful if you could dump the ROMs. I'd like to find versions of 1.x (8;7;3 or earlier); so far I've had no luck. The main reason I'm interested in older ROMs, besides pure preservation reasons, is that the 'mux' and 'muxterm' system on Research UNIX V8/V9 is hard-coded for the 1.1 ROMs. It doesn't work with the emulator without significant tweaking of the source. It DOES work perfectly well with the DMD Core Utilities package for the AT&T 3B2, however. All the best! -Seth -- Seth Morabito Poulsbo, WA, USA web(a)loomcom.com

6 years, 6 months

Re: [TUHS] Happy birthday, C.A.R. Hoare!

by Paul McJones

In the June 1966 CACM [1], Wirth and Hoare published "A contribution to the development of ALGOL”, which describes a language very similar to Algol W. In Wirth’s Turing Award lecture (published in the Feb 1985 CACM [2]) "From programming language design to computer construction”, he noted: “The Working Group assumed the task of proposing a successor and soon split into two camps. On one side were the ambitious who wanted to erect another milestone in language design, and, on the other, those who felt that time was pressing and that an adequately extended ALGOL 60 would be a productive endeavor. I belonged to this second party and submitted a proposal that lost the election. Thereafter, the proposal was improved with contributions from Tony Hoare (a member of the same group) and implemented on Stanford University's first IBM 360. The language later became known as ALGOL W and was used in several universities for teaching purposes.” In particular, Hoare’s work on “Record Handling” (see [3]) had a strong impact on Algol W and Wirth’s later languages. [1] http://doi.acm.org/10.1145/365696.3657022 [2] http://doi.acm.org/10.1145/2786.2789 [3] http://www.softwarepreservation.org/projects/ALGOL/standards/. > On Jan 10, 2019, at 7:06 PM, clemc(a)ccc.com wrote: > > From: Clem cole <clemc(a)ccc.com <mailto:clemc@ccc.com>> > To: Dave Horsfall <dave(a)horsfall.org <mailto:dave@horsfall.org>> > Cc: The Eunuchs Hysterical Society <tuhs(a)tuhs.org <mailto:tuhs@tuhs.org>> > > Dave. The w in Algolw was Wirth. He was at Stanford at the time. It was written in PL/360 btw. The sources are googlable. FWIW Pascal was done a couple of years later with lessons learned from Algolw and reaction to Algol68. > > Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > >> On Jan 10, 2019, at 6:52 PM, Dave Horsfall <dave(a)horsfall.org <mailto:dave@horsfall.org>> wrote: >> >> [Not sure whether this is more appropriate for COFF instead, so it's here; advice (apart from STFU) gratefully accepted.) >> >> Sir Charles Antony Richard Hoare FRS FREng was born on this day in 1934; a computer pioneer (one of the greats) he gave us things like the quicksort algorithm (which became qsort() in Unix) and ALGOLW (a neat language). >> >> -- Dave >

6 years, 6 months

Happy birthday, C.A.R. Hoare!

by Dave Horsfall

[Not sure whether this is more appropriate for COFF instead, so it's here; advice (apart from STFU) gratefully accepted.) Sir Charles Antony Richard Hoare FRS FREng was born on this day in 1934; a computer pioneer (one of the greats) he gave us things like the quicksort algorithm (which became qsort() in Unix) and ALGOLW (a neat language). -- Dave

6 years, 6 months

Origin of the name 'strategy'

by Warner Losh

So what's the origin of the name 'strategy' for the I/O routine in Unix that drivers provide? Everything I've found in the early papers just says that's what the routine is called. Is there a story behind why it was chosen? My own theory is that it's in the sense of 'coping strategy' when the driver needs to service more I/O for the upper layers, but that's just a WAG. Warner

6 years, 6 months

Re: [TUHS] Origin of the name 'strategy'

by Dave Horsfall

On Tue, 8 Jan 2019, Warner Losh wrote: > The name seems obvious because I've seen it for the last 30 years. But > I've not seen it used elsewhere, nor have I seen it documented except in > relationship to Unix. It could have been called blkio or bufio or bio or > even just work or morework and still been as meaningful. VMS uses the > FDT table to process the IRPs sent down. RT-11 has a series of entry > points that have boring names. Other systems have a start routine > (though more often that is a common routine used by both the queue me > and isr functions). There is a wide diversity here... I must admit that this is an interesting thread, just as long as it wasn't called XXoptimize() unless you wanted a backlash from British English speakers :-) In hindsight I suppose that XXstrategy() is obvious, but back then, as you ask? Dunno, but Ken might (if he's reading this thread). One of my favo[u]rites is sched(); some pronounce it as "shed" and others as "sked". Another American/British thing, I think... Wasn't it Mark Twain who said "Two nations divided by a common language"? I no longer have my Lions books on me, sadly enough (lost in a house move) but there certainly were some peculiar names in the kernel... ObGripe: Could anyone replying to the digest version please take the trouble to update the Subject: line accordingly? I've now put the original back as a courtesy to others, but I shouldn't have to; it's as bad as top-posting. -- Dave

6 years, 6 months

Re: [TUHS] TUHS Digest, Vol 38, Issue 10

by Steve Simon

re disk stagey i understood that this implemented the elevator algorithm, and possible rotational latency compensation. re non-gcc compilers there was a time in the early 2000s when some people tried release plan9’s (ken’s) c compiler for use in BSD bsd, sadly (for plan9) this didn't happen. pcc was reanimated instead.

6 years, 6 months

National Inventors Hall of Fame honors creators of Unix

by Warren Toomey

https://www.engadget.com/2019/01/08/national-inventors-hall-of-fame-class-o… The National Inventors Hall of Fame (NIHF) joined Engadget on stage today at CES to announce its 2019 class of inductees. [ including ] ... Dennis Ritchie (Posthumous) and Ken Thompson: UNIX Operating System ------------------------------------------------------------------- Thompson and Ritchie's creation of the UNIX operating system and the C programming language were pivotal developments in the progress of computer science. Today, 50 years after its beginnings, UNIX and UNIX-like systems continue to run machinery from supercomputers to smartphones. The UNIX operating system remains the basis of much of the world's computing infrastructure, and C language -- written to simplify the development of UNIX -- is one of the most widely used languages today. Cheers, Warren

6 years, 6 months

QED archive now available

by Arnold Robbins

Hi All. Back in October I started a discussion about QED sources. A number of people were kind enough to send me tarballs and zip files as well as pointers to other archives. I have finally cobbled it all together and made it available on GitHub: https://github.com/arnoldrobbins/qed-archive I have tried to acknowledge everyone who contributed. Thanks again to all who did send me stuff and email me. Enjoy, Arnold

6 years, 6 months

off topic - capatob - saratov2 computer Russsian pdp8? HELP

by Dr Iain Maoileoin

Off topic, but looking for help and wisdom. If you visit https://www.scotnet.co.uk/iain/ <https://www.scotnet.co.uk/iain/>saratov you will see some photos of work that I have started on the front panel of a Capatob2. I plan to get the switches and lights running on a blinkenbone board with a PDP8 emulation behind it. (I already have an PDP11/70 front-panel running on the same infrastructure) I have been struggling for over a year to get much info about this saratov computer (circuit diagrams etc). So I have started the reverse engineering on the panel. Does anybody know anything about this computer? online or offline it would be much appreciated. Iain

6 years, 6 months

Gentle reminder: TUHS is for Unix

by Warren Toomey

Hi all, back from a few days holiday. Just a reminder that the TUHS list is for things related to Unix. I don't mind a bit of topic drift, but if the topic goes completely away from Unix then the conversation should migrate to the COFF (Computer Old Farts Forum) list, coff(a)tuhs.org. I'll mark the "Isaacson" thread as closed on TUHS, but feel free to continue it over on COFF. Thanks, Warren

6 years, 6 months

Re: [TUHS] Isaacson v Unix [really RMS bashing]

by Jon Steinhart

Been wanting to wade into this for a few days but needed to think about how. I think that we're all aware that RMS has atrocious personal habits. But I don't think that this mailing list is the place to discuss them unless it's somehow in the context of UNIX. Many seem to excuse RMS's revisionist view of the history of technology on the grounds that RMS claims that his memory isn't very good. I think that if he knows that he doesn't remember things then he should refrain from talking about them as if he does. As others have said, I don't conflate coding prowess with the ability to design. I've had many an argument with John Gilmore (one of the people who doesn't mind footing the cleaning and repair bill after allowing RMS to stay at his place) where he begins with "When I wrote GNU tar..." I've always responded by saying that writing tar is no big deal; the specification was the hard part. One place where I completely disagree with RMS that I think is in context for this list is his claim that Linux should be called GNU/Linux. I've written tons of software in my life, and I don't preface the name of each one with the parts list. Even if one believed that such an attribution scheme made sense, I would claim that it should be called internet/Linux. I would argue that Linux would not have happened without the internet making it possible for folks around the world to participate. And I think that there's a good chance that the tools would have been created anyway. Of course, I acknowledge that the GNU tools have been ported to Linux. Big deal. I haven't seen RMS arguing for GNU/Windows now that Microsoft has seen the light. Like many of you, Linux is not where I first started using GNU tools; I started using them on my Sun machines after Sun started charging extra for the compiler and included a licensing system that was broken and often interfered with getting work done. Jon

6 years, 6 months

Re: [TUHS] Isaacson v Unix [really RMS bashing]

by Larry McVoy

I think the RMS stuff should go away. It's not because I love the guy, I don't. It's because we have people like Ken and Rob and other heavy hitters and my hunch is they have little patience for this sort of thing (they might correct me if I'm wrong). I'd love to call out RMS on his BS but this isn't the place. This is the place for people who actually did real work on Unix to share those stories. Or so I think, it's up to Warren, not me.

6 years, 6 months

Isaacson v Unix

by Doug McIlroy

I was given a copy of Walter Isaacson's "The Innovators: How a Group of Hackers, Geniuses, and Geeks Created the Digital Revolution". It devotes ten pages to Stallman and Gnu, Torvalds and Linux, even Tannebaum and Minix, but never mentions Thompson and Ritchie. Unix is identified only as a product from Bell Labs from which the others learned something--he doesn't say what. I have heard also that Isaacson's "Idea Factory" (about Bell Labs) barely mentions Unix. Is Isaacson blind, biased, or merely brainwashed? In the case of Steve Jobs, Isaacson tells not just that the Alto system from Xerox inspired him, but also who its star creators were: Lampson, Thacker and Kay. But then he stomps on them: "Once again, the greatest innovation would come not from the people who created the breakthroughs, but from the people who applied them usefully." While he very describes innovation as a continuum from invention through engineering to marketing, he seems to be more impressed by the later stages. Or maybe he just likes to tell stories, and didn't pick up all the good ones about Ken. Isaacson describes spacewar, arguably the first stage of computer-game innovation, at great length. At the same time, all he has to say about early-stage operating systems is a single sentence that credits John McCarthy with leading a time-sharing effort at MIT. (In my recollection, McCarthy proseletized; Corbato led.) He tells how ARPANET, which he says was mainly developed by BB&N, connected time-shared computers, but breathes not a word about Berkeley's work, without which ARPANET would have been an open circuit. "Innovators" won general critical praise. A couple of reviews predicted it would become the standard of the field. However, an evidently knowledgeable review in IEEE Annals of the History of Computing faulted it for peddling familiar potted legends without really digging for deeper insight. Regarding Thompson and Ritchie, it looks more like overt suppression. Doug

6 years, 6 months

Re: [TUHS] Isaacson v Unix

by Paul McJones

> On Jan 5, 2019,Paul Winalski <paul.winalski(a)gmail.com> wrote: > > ... After Lampson > left Xerox PARC he set up a similar outfit at Digital'--the Western > Research Lab (WRL). Actually, WRL was started by Forest Baskett, formerly of Stanford University. Butler Lampson joined DEC's Systems Research Center (SRC) shortly after it was formed by former PARC manager Bob Taylor. > ... I was working in the software tools > engineering group at the time, and we would have loved to take WRL's > work and to incorporate it in our products. But we couldn't. Why? > Because they wrote everything in Modula 3, and we were using BLISS. SRC used Modula-3, and before that a similar language called Modula-2+. Originally, WRL used Modula-2, and then I think switched to C. Perhaps DEC’s engineering groups should also have switched from Bliss to C. > Yes, PARC invented the modern windows-based GUI, but, as with so many > PARC innovations, Xerox did nothing with it. Based on how the PARC > alumni at WRL behaved at DEC,I would argue that this was the fault of > PARC as much as of Xerox management. Xerox built its Star office automation system based on PARC technology and with lots of support from PARC. Star was of course not a big success. PARC also invented laser printers, and Xerox made quite a bit of money from them. Paul McJones (former Xerox SDD and DEC SRC member — I have been on both sides of the fence)

6 years, 6 months

Re: [TUHS] Isaacson v Unix

by Doug McIlroy

>>I have heard also that Isaacson's "Idea Factory" (about Bell Labs) > Did you mean the work of this title by Jon Gertner? Indeed. If should fact-check myself if I'm going to challenge some one else's choice of facts. Thanks for the catch, Doug

6 years, 6 months

Re: [TUHS] Isaacson v Unix

by jnc＠mercury.lcs.mit.edu

>> From: Doug McIlroy >> I have heard also that Isaacson's "Idea Factory" (about Bell Labs) > Did you mean the work of this title by Jon Gertner? (I have yet to pull > down my copy to see what it says about Unix I looked, and it too says next to nothing about Unix (which it describes as a "programming language" - pg. 346). Oh well. This is really a pretty serious omission, given that the vast majority of mobile devices now run Android, which is a Unix derivative (Linux). So just about everyone has a Unix-derived thing in their pocket. Noel

6 years, 6 months

face mail icon for ACSnet

by Nigel Williams

Long ago when we were running ACSnet (https://en.wikipedia.org/wiki/MHSnet) we lacked graphical workstations so we never saw the Bell Labs face mail (https://en.wikipedia.org/wiki/Vismon) mechanism in action. I think colleagues who later had Sun workstations might have briefly had X-face in operation. I see on Luca Cardelli's homepage that there was an icon for ACSnet email, of course it is Kangaroo... http://lucacardelli.name/indexArtifacts.html scroll down Original 48x48 bitmaps for "face mail" at Bell Labs.

6 years, 6 months

Re: [TUHS] Isaacson v Unix

by jnc＠mercury.lcs.mit.edu

From: Doug McIlroy > I have heard also that Isaacson's "Idea Factory" (about Bell Labs) I was unable to find a book of this title by Isaacson? Did you mean the work of this title by Jon Gertner? (I have yet to pull down my copy to see what it says about Unix - it's in another room, and I'm lazy... :-) > (In my recollection, McCarthy proseletized; Corbato led.) I think that's an accurate 1-sentence summary. > breathes not a word about Berkeley's work, without which ARPANET would > have been an open circuit. Can you elaborate on this point a bit - I'm not sure what it is you're referring to? > A couple of reviews predicted it would become the standard of the > field. Among people who spell 'Internet' with a lower-case 'i', perhaps it will (sadly). Noel

6 years, 6 months

Jordan Hubbard's rwall of infamy

by Don Hopkins

From: jkh(a)violet.Berkeley.EDU (Jordan K. Hubbard) Subject: My Broadcast Date: 2 April 1987 at 21:45:46 CEST To: hackers_guild(a)ucbvax.Berkeley.EDU, tcp-ip(a)sri-nic.arpa By now, many of you have heard of (or seen) the broadcast message I sent to the net two days ago. I have since received 743 messages and have replied to every one (either with a form letter, or more personally when questions were asked). The intention behind this effort was to show that I wasn't interested in doing what I did maliciously or in hiding out afterwards and avoiding the repercussions. One of the people who received my message was Dennis Perry, the Inspector General of the ARPAnet (in the Pentagon), and he wasn't exactly pleased. (I hear his Interleaf windows got scribbled on) So now everyone is asking: "Who is this Jordan Hubbard, and why is he on my screen??" I will attempt to explain. I head a small group here at Berkeley called the "Distributed Unix Group". What that essentially means is that I come up with Unix distribution software for workstations on campus. Part of this job entails seeing where some of the novice administrators we're creating will hang themselves, and hopefully prevent them from doing so. Yesterday, I finally got around to looking at the "broadcast" group in /etc/netgroup which was set to "(,,)". It was obvious that this was set up for rwall to use, so I read the documentation on "netgroup" and "rwall". A section of the netgroup man page said: ... Any of three fields can be empty, in which case it signifies a wild card. Thus universal (,,) defines a group to which everyone belongs. Field names that ... ... Now "everyone" here is pretty ambiguous. Reading a bit further down, one sees discussion on yellow-pages domains and might be led to believe that "everyone" was everyone in your domain. I know that rwall uses point-to-point RPC connections, so I didn't feel that this was what they meant, just that it seemed to be the implication. Reading the rwall man page turned up nothing about "broadcasts". It doesn't even specify the communications method used. One might infer that rwall did indeed use actual broadcast packets. Failing to find anything that might suggest that rwall would do anything nasty beyond the bounds of the current domain (or at least up to the IMP), I tried it. I knew that rwall takes awhile to do its stuff, so I left it running and went back to my office. I assumed that anyone who got my message would let me know.. Boy, was I right about that! After the first few mail messages arrived from Purdue and Utexas, I begin to understand what was really going on and killed the rwall. I mean, how often do you expect to run something on your machine and have people from Wisconsin start getting the results of it on their screens? All of this has raised some interesting points and problems. 1. Rwall will walk through your entire hosts file and blare at anyone and everyone if you use the (,,) wildcard group. Whether this is a bug or a feature, I don't know. 2. Since rwall is an RPC service, and RPC doesn't seem to give a damn who you are as long as you're root (which is trivial to be, on a work- station), I have to wonder what other RPC services are open holes. We've managed to do some interesting, unauthorized, things with the YP service here at Berkeley, I wonder what the implications of this are. 3. Having a group called "broadcast" in your netgroup file (which is how it comes from sun) is just begging for some novice admin (or operator with root) to use it in the mistaken belief that he/she is getting to all the users. I am really surprised (as are many others) that this has taken this long to happen. 4. Killing rwall is not going to solve the problem. Any fool can write rwall, and just about any fool can get root priviledge on a Sun workstation. It seems that the place to fix the problem is on the receiving ends. The only other alternative would be to tighten up all the IMP gateways to forward packets only from "trusted" hosts. I don't like that at all, from a standpoint of reduced convenience and productivity. Also, since many places are adding hosts at a phenominal rate (ourselves especially), it would be hard to keep such a database up to date. Many perfectly well- behaved people would suffer for the potential sins of a few. I certainly don't intend to do this again, but I'm very curious as to what will happen as a result. A lot of people got wall'd, and I would think that they would be annoyed that their machine would let someone from the opposite side of the continent do such a thing! Jordan Hubbard jkh(a)violet.berkeley.edu (ucbvax!jkh) Computer Facilities & Communications. U.C. Berkeley

6 years, 6 months

Re: [TUHS] NSA MILNET IMP 57 & Explosive Bolts

by Don Hopkins

On 4 Jan 2019, at 21:46, Clem Cole <clemc(a)ccc.com> wrote: >From where did that wonderful clip come? It's clearly a sequence from something else. I've never seen it before. >Thanks, >Clem They were from my email archives of Hackers_Guild and the umd cs department staff mailing list. Does anybody else have any h_g archives sitting around? Here’s some more funny stuff about the NSA! Gotta love how Brian Reid and Rick Adams weigh in. ;) -Don From: yee(a)dali.berkeley.edu (Peter E. Yee) Subject: For those who missed 997@lll-crg, here it is Date: 19 November 1985 at 15:58:08 CET To: hackers_guild(a)ucbvax.berkeley.edu Relay-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site lll-crg.ARpA Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site lll-crg.ARpA Path: lll-crg!bandy From: bandy(a)lll-crg.ARpA (Andrew Scott Beals) Newsgroups: net.net-people Subject: oh YES the NSA is on the net! Message-ID: <997(a)lll-crg.ARpA> Date: 19 Nov 85 07:11:36 GMT Date-Received: 19 Nov 85 07:11:36 GMT References: <324(a)ucdavis.UUCP> <2253(a)umcp-cs.UUCP> Reply-To: bandy(a)lll-crg.UUCP (Andrew Scott Beals) Distribution: net Organization: Computation Research Group, Lawrence Livermore Labs Lines: 94 Summary: (let's say) unintentional dis-information corrected In article <2253(a)umcp-cs.UUCP> tlr(a)umcp-cs.UUCP (Terry L. Ridder) writes: I can almost guarantee that the National Security Agency is not on USENET or ARPANET. I can further almost guarantee that very few employees of NSA are even aware that USENET exist. Signed Terry L. Ridder UUCP: seismo!(mimsy.umd.edu|neurad)!bilbo!wiretap!(root|tlr) ^^^^^^^ PHONE: 301-490-2248 (home) 301-859-6642 (work) Right. There used to be a host called "TYCHO" (nickname "NSA") at host zero on imp fifty-seven. (26.0.0.57) (information taken from the old NIC (Network Information Center for Internet) host tables) Now there is a machine called "DOCKMASTER" on that same imp port (TYCHO was an old PDP-11 running version 6 unix (which rumors had flown for quite some time that someone actually proved was secure)). Here is what the NIC has to say about DOCKMASTER: The National Computer Security Center (DOCKMASTER) 820 Elkridge Landing Road Room A1127, Building FANX-II Linthicum, MD 21090 NetAddress: 26.0.0.57 Nicknames: NCSC-MULTICS Host Administrator and Liaison: Aliff, Stephen W. (SWA1) Aliff.DODCSC@MIT-MULTICS (301) 850-5888 Multics, if I remember correctly, was just given some level of certification by the government that it was secure. Interesting, no? Unfortunately, I'm not nearly as much of a Packrat as some might like to think so I don't have a Maryland phone book (I do have my silly putty though), so I can't tell you where this exchange is located (nor where Terry's work number is located). However, looking up Linthicum MD (I was born and raised just north of DC) shows that it's just north of BWI (airport). There is a NASA center right near there and next to that is an un-marked (of course) NSA center. All of this points that imp 57 is still NSA's imp. NIC has this to say about host 1 on imp 57: National Security Agency (COINS-GATEWAY) COINS Network Control Center Fort George G. Meade, MD 20755 NetAddress: 26.1.0.57 Nicknames: COINS Host Administrator and Liaison: Smith, Ronald L. (RLS6) COINS@USC-ISI (301) 688-6375 The NIC generally likes to give a machine the name "-GATEWAY" when that machine is a gateway into another part of the internet. (the machine type of COINS is a Plurbus, which is a multiprocessor gateway machine manufactured by BBN (the folks who do the ARPANET and MILNET hardware). In any case, it seems that Mr Ridder is un-(or mis-?)informed. Side note: at the last (Portland) USENIX, I happened across a gentlemen (very cleancut) whose badge listed him as working for the "Department of Defense, Fort Meade Maryland". I said "Oh, you're one of those NSA guys!" To which he replied "How did you know?!"... "Everyone else in DOD says /which/ part of DOD they work for..." andrew scott beals lawrence livermore national laboratory/university of california Pooh-bah for LLL-CRG.ARPA (415) 423-1948 (work) (533-1948 (FTS)) ps. In case anyone is wondering and before you go giving my name to people that I don't want to talk to (like the Kind Folks at the NSA (but I'm sure they've heard of me or will before I finish up with my current round of paperwork with the DOE/OPM/FBI)), I obtained all of this information through public channels. -- There once was a thing called a V-2, To pilot which you did not need to-- You just pushed a button, And it would leave nuttin' But stiffs and big holes and debris, too. andy beals - bandy(a)lll-crg.arpa - {seismo,ihnp4!sun,dual}!lll-crg!bandy From: jordan(a)ucbarpa.berkeley.edu (Jordan Hayes) Subject: Re: ``dockmaster'' Date: 19 November 1985 at 16:27:34 CET To: hackers_guild(a)ucbvax.berkeley.edu for those so inclined, they should look at what is on port 2 of that imp ... hmmm ... sorta like putting the CIA on port 4 of imp 78 ... /jordan From: Andrew Scott Beals <bandy(a)lll-crg.ARPA> Subject: Re: ``dockmaster'' Date: 19 November 1985 at 18:27:27 CET To: hackers_guild(a)ucbvax.berkeley.edu, jordan(a)ucbarpa.berkeley.edu Maryland lets NSA people use mimsy. The NSA is interested in the supercomputer designs that they're working on there... (which is why they have an imp connection) In any case, I just got a long note from Mr Ridder. I'll forward it to you when I'm done reading my mail... andy From: Andrew Scott Beals <bandy(a)lll-crg.ARPA> Subject: message from Mr. Ridder Date: 19 November 1985 at 18:31:44 CET To: hackers_guild(a)lll-crg.ARPA From tlr(a)mimsy.umd.edu Tue Nov 19 06:13:44 1985 Date: Tue, 19 Nov 85 09:12:54 EST From: Terry L. Ridder <tlr(a)mimsy.umd.edu> Subject: Your posting Mr. Andrew Scott Beals I am writing to inform you of at least two facts: The computer named "wiretap" belongs to my children, age 9, age 7, age 2. Jennifer, the 7 year old, named the computer. Sarah, the 9 year old, named the other computer "bilbo". Bilbo and wiretap are both private machines. The are owned by my family and I. They are in no way shape or form associated with the NSA. Concerning your posting, I am concerned that you have no regard for the safety of federal employees. Your posting is marked for distribution "net", if you would look at the two previous posting they are marked for distribution 'usa'. Therefore, you probably have just told most of the world the location of what you believe to be an NSA facility. This probably has made the location a target for any of a number of terrorist groups. What if you are wrong? You have place in danger the lifes of innocent people. Just because you may think you know something does not mean that you tell most of the world. I would hope that in the future that you would take the time to think about all the ramifications before making a posting, similiar in nature to the one in question. I would hope that you will send out a cancel message on your posting, before it gets to far. I sincerely hope that you restrict your speculations about my family's association with any federal agency. I hope also that you are mature enough to post an apology for inferring that my computers were associated with the NSA. I do not want to think of what the implications are from that speculation on your part. You may have damaged my family's reputation and my own reputation. Please be a little more responsible in the future. Engage brain before fingers. Signed Terry L. Ridder for the Terry L. Ridder family --------------------- From: fair(a)ucbarpa.berkeley.edu (Erik E. Fair) Subject: Re: message from Mr. Ridder Date: 19 November 1985 at 18:42:34 CET To: bandy(a)lll-crg.ARPA Cc: Hackers_Guild(a)ucbvax.berkeley.edu I wonder if this bozoid has ever read `The Puzzle Palace'? It identifies several `secret' NSA installations, including one out in the wilds of Sonoma, just over the border from Marin County, along the road from Tomales to Petaluma. All from public sources and Freedom Of Information Act suits. Erik E. Fair ucbvax!fair fair(a)ucbarpa.berkeley.edu P.S. Be sure to waive hello in your Email to the folks at the Maryland Procurement Office... From: Andrew Scott Beals <bandy(a)lll-crg.ARPA> Subject: Re: message from Mr. Ridder Date: 19 November 1985 at 19:11:36 CET To: fair(a)ucbarpa.berkeley.edu Cc: Hackers_Guild(a)ucbvax.berkeley.edu [mimsy.umd.edu] Login name: tlr In real life: Terry L. Ridder Office: Laurel MD 20707 Office phone: 859-6642 Home phone: 490-2248 Arpanet Sponsor Directory: /u/tlr Shell: /bin/csh Last login Tue Nov 19 09:17 on tty04 Project: To find a new job, raise three children, and have time for the wife. Plan: To move overseas. ---------------------- Well, this is what it has to say about him. Arpanet sponsor, eh? andy From: fair(a)ucbarpa.berkeley.edu (Erik E. Fair) Subject: Re: message from Mr. Ridder Date: 19 November 1985 at 19:48:41 CET To: bandy(a)lll-crg.ARPA Cc: Hackers_Guild(a)ucbvax.berkeley.edu Ask Chris Torek what an `Arpanet Sponsor' is... Erik From: Andrew Scott Beals <bandy(a)lll-crg.ARPA> Subject: more follies, dt if uninterested Date: 20 November 1985 at 02:10:30 CET To: hackers_guild(a)lll-crg.ARPA Seems that the gentleman doesn't read his fucking news before going off at the handle. I sent him an "Excuse me, but if you look at article ..." note. LLL General consul? Snicker snicker. Maybe Postmaster or root or usenet will get a nice note from him telling me what a Bad Boy I've been... :-) andy ----------------------- Date: Tue, 19 Nov 85 18:46:28 EST From: Terry L. Ridder <tlr(a)mimsy.umd.edu> Subject: apology is inorder Mr. Andrew Scott Beals I again ask that you act in a mature manner and post an apology concerning your inferring that my private computers are associated with the NSA. If you choose not to, would you be kind enough to inform me what the phone number is for LLL general consul is? Signed Terry L. Ridder From: jordan(a)ucbarpa.berkeley.edu (Jordan Hayes) Subject: Re: ridder me this ... Date: 20 November 1985 at 02:59:22 CET To: hackers_guild(a)ucbvax.berkeley.edu Methinks either the man is an idiot or he's not really a force to be reckoned with. If his main mail machine is mimsy, that means he's on the same imp ... since NSA people have accounts at umd, maybe he's FROM the NSA ... hmmm ... /jordan From: Milo S. Medin (NASA ARC Code ED) <medin(a)orion.ARPA> Subject: Re: message from Mr. Ridder Date: 20 November 1985 at 03:03:55 CET To: Andrew Scott Beals <bandy(a)lll-crg.ARPA> Cc: fair(a)ucbarpa.berkeley.edu, Hackers_Guild(a)ucbvax.berkeley.edu LLL general counsel? uh oh..... That means lawyers.... Milo From: Andrew Scott Beals <bandy(a)lll-crg.ARPA> Subject: ridder me this Date: 20 November 1985 at 03:14:56 CET To: hackers_guild(a)lll-crg.ARPA One of my sources tells me that Mr Ridder is indeed an NSA person. Chris Torek told me that an "Arpanet Sponsor" in their terminology means that he's one of the people who helped them get on the network. andy From: Andrew Scott Beals <bandy(a)lll-crg.ARPA> Subject: Re: Ridder me this (qualification) Date: 20 November 1985 at 03:31:22 CET To: bandy(a)ll-crg.ARPA, deboor%buddy(a)ucbvax.berkeley.edu Cc: hackers_guild(a)ucbvax.berkeley.edu Oh, I already sent him an apology. Here it is: Relay-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site lll-crg.ARpA Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site lll-crg.ARpA Path: lll-crg!bandy From: bandy(a)lll-crg.ARpA (Andrew Scott Beals) Newsgroups: net.net-people Subject: Apology to Terry Ridder Message-ID: <998(a)lll-crg.ARpA> Date: 19 Nov 85 17:37:12 GMT Date-Received: 19 Nov 85 17:37:12 GMT References: <324(a)ucdavis.UUCP> <2253(a)umcp-cs.UUCP> <997(a)lll-crg.ARpA> Reply-To: bandy(a)lll-crg.UUCP (Andrew Scott Beals) Distribution: net Organization: Computation Research Group, Lawrence Livermore Labs Lines: 15 I would like to take this opportunity to formally extend my apologies to Terry L. Ridder (tlr(a)mimsy.umd.edu) and his family for insinuating that their home machines (bilbo and wiretap) and any association with any Federal agency (the NSA in this case). andrew scott beals uc/llnl -- There once was a thing called a V-2, To pilot which you did not need to-- You just pushed a button, And it would leave nuttin' But stiffs and big holes and debris, too. andy beals - bandy(a)lll-crg.arpa - {seismo,ihnp4!sun,dual}!lll-crg!bandy --------------------- What was interesting was that the file was ~news/net/net-people/666 ... Tee hee hee. andy From: Andrew Scott Beals <bandy(a)lll-crg.ARPA> Subject: calling LLL {lawyers,diplomats} Date: 20 November 1985 at 03:38:35 CET To: hackers_guild(a)lll-crg.ARPA Of course, they'll tell him that "Anything that our employees say is their own opinion unless they are a member of the LLNL Public Information group and are speaking in an official capacity." "Pin-heads. Pin-heads. Roly-poly pin-heads. Pin-heads. Pin-heads. Watch them lose. Yow!" andy From: Andrew Scott Beals <bandy(a)lll-crg.ARPA> Subject: teehee Date: 20 November 1985 at 17:18:25 CET To: hackers_guild(a)ucbvax.berkeley.edu From reid@glacier Wed Nov 20 06:59:01 1985 Date: Wed, 20 Nov 85 06:57:35 pst From: Brian Reid <reid@glacier> Subject: Re: Apology to Terry Ridder Newsgroups: net.net-people Organization: Stanford University, Computer Systems Lab Terry Ridder is one of the biggest assholes on earth, and I can't fathom anybody owing him an apology about anything. Oh well. -- Brian Reid decwrl!glacier!reid Stanford reid(a)SU-Glacier.ARPA From: Andrew Scott Beals <bandy(a)lll-crg.ARPA> Subject: philngai on tlr Date: 21 November 1985 at 07:21:35 CET To: hackers_guild(a)lll-crg.ARPA From amdcad!phil Wed Nov 20 20:41:58 1985 Date: Wed, 20 Nov 85 20:08:04 pst From: amdcad!phil (Phil Ngai) Subject: Re: message from Mr. Ridder what kind of asshole names a computer wiretap and then complains when others make seemingly reasonable assumptions about it? who should engage their brain, that's what i want to know. -- Raise snails for fun and profit! Race them for amusement! Then eat the losers! Phil Ngai +1 408 749-5720 UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil ARPA: amdcad!phil(a)decwrl.dec.com From: cuuxb!jab(a)lll-crg.ARPA Subject: Re: message from Mr. Ridder Date: 24 November 1985 at 02:25:13 CET To: lll-crg!sdcsvax.arpa!hutch(a)lll-crg.ARPA Cc: lll-crg!hackers_guild(a)ucbvax.berkeley.edu The Ridder guy is a jerk. I would wonder why the ARPANET knows about his private machines, anyhow: sounds like a misuse of government funding. Jeff Bowles Lisle, IL From: Donnalyn Frey <donnalyn(a)seismo.css.gov> Subject: Re: private machines on internet Date: 24 November 1985 at 06:08:34 CET To: cuuxb!jab(a)lll-crg.ARPA, deboor%buddy(a)ucbvax.berkeley.edu Cc: hackers_guild(a)ucbvax.berkeley.edu Ridders machines are NOT on the arpanet. They have uucp links to Uof Maryland. Ridder himself has an account on mimsy.umd.edu. Ridders two machines were named by his children. ONe had just finished reading teh Hobbit (hence bilbo, despite the 2 other known bilbos [not to be confused with certain dildos being discussed]) and the other had finished some spy book, hence wiretap. He is quite pompous and seems to think the world revolves around him. We asked him to rename "bilbo" to not conflict. He replied that the other machines should change because he had already named his machine. By the way, we're talking about toys here (maybe somthing as expensive as an IBM-PC) not the "real" machines you might be led to believe. He is best ignored. ---rick

6 years, 6 months

NSA MILNET IMP 57 & Explosive Bolts

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, 6 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