INFO-VAX Sat, 30 Aug 2008 Volume 2008 : Issue 475 Contents: Re: Advanced Server 7.3B & VISTA Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: Remote access vulnerability in VMS Re: Remote access vulnerability in VMS Re: Remote access vulnerability in VMS Re: Remote access vulnerability in VMS Re: rx2600s on eBay Re: switch vs. hub for hobbyist cluster Re: switch vs. hub for hobbyist cluster ---------------------------------------------------------------------- Date: Sat, 30 Aug 2008 06:25:24 -0700 (PDT) From: Bobby Subject: Re: Advanced Server 7.3B & VISTA Message-ID: To finish this thread off, the final answer (see http://forums12.itrc.hp.com/service/forums/questionanswer.do?threadId=1263217) was that passwords were being entered on the Advanced Server side, directly on the command line, and AS converts passwords to uppercase when you do this. Example: mod user /pass=password stores the password as PASSWORD. Entering the password in quotes, e.g., mod user/ pass="password", stores the password in lowercase. I'm still not sure why the XP machines were connecting correctly with lowercase passwords, but I'm not going to try to figure it out either. ------------------------------ Date: Sat, 30 Aug 2008 02:48:32 -0700 (PDT) From: johnwallace4@yahoo.co.uk Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <3cde3b31-285e-4be0-98e1-287219571280@l42g2000hsc.googlegroups.com> On Aug 29, 9:41 pm, JF Mezei wrote: > re: memory protection. > > Can anyone explain to me why I was under the impression that under VMS, > you could not branch to data because data blocks were marked no-execute > (or whatever) ? > > Was this ever the case ? > > This argument had been brought up, (perhaps in my dreams) to show how > VMS was far mroe immune to buffer overflows than other operating > systems. (with the corrolary that you could not write to execute > sections and overwrite code). > > Recent discussions seem to have completely shattered these > misconceptions I had, but i am really puzzled as to why I would have had > them to begin with. I'd be interested in that too. For now, I'm thinking that I've assumed that since the capability existed on PDPs (in hardware and in compilers and in linker and OS), and that the same capability existed in "bigger, better" VMS (at least in VMS compilers and linker (?)), there's been an assumption on my part that the hardware and OS did the sensible thing. As I mentioned earlier in a post which refers to the I +DS manual, the PTE on VMS does seem to have a "fault on execute" bit, which also supports my (apparently incorrect) assumption that data sections are capable of being non-executable. But a definitive answer would be better than my assumptions. ------------------------------ Date: Sat, 30 Aug 2008 14:03:13 +0200 From: Johnny Billquist Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: Bill Gunshannon skrev: > In article , > Johnny Billquist writes: >> Bob Koehler skrev: >>> In article , Johnny Billquist writes: >>>> No, the 11/23 don't have I/D space support. The 11/23+ atleast supports 4 megs >>>> of memory, but still without I/D space. >>>> Off my head, the processors supporting I/D space are: >>>> 11/44, 11/45, 11/50, 11/53, 11/55, 11/70, 11/73, 11/74, 11/83, 11/84, 11/93 and >>>> 11/94. >>> Of course, the siugnificant point is that unless the hardware has >>> some mechanism, the OS kernel can't do anything about executing stack >>> space. >> True. >> > > I cut most of this as it isn't relevant to what I have to say but just > left enough to tie it all together. I expect someone like Johnny can > answer this. > > I remember back in my Univac-1100 days it, too, had the equivalent of > I&D space. But, because all the memory was basicly in a flat address > space it was possible to write outside of "D" space using undetected > out-of-bounds array subscripts (this caused numerous problems I had > to troubleshoot in both COBOL and Fortran programs. Luckily there > was noone actively trying to exploit this flaw in those days.) > > What does this have to do with the PDP-11? If the system basicly has > 4Meg of memory, what is to stop me from accessing a block of memory in > I space and writing malicious code there that I later force a branch to? > Ift his is impossible, what is the mechanism of the CPU that would > prevent it? Simple. If you write at virtual address 4711, you're write would go to the D-space mapping of the virtual address, which might, lets's say, go to physical address 14711. If you then jump to virtual address 4711, you'd be fetching instructions from I space, which maps according to the I-space page table, which might map virtual address 4711 to physical address 24711, which you obviously didn't write to. In fact, the physical addresses that your I-space map to might not even exist in your virtual D-space address space. So, there is no way for your program to write or read from the physical addresses from which your instruction fetches are done. Definitely execute only. :-) > Just trying to expand my knowledge of the PDP-11 even after all these > years of using it. :-) More knowledge is always good. :-) Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol ------------------------------ Date: Sat, 30 Aug 2008 14:11:57 +0200 From: Johnny Billquist Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: Bob Koehler skrev: > In article <6hqa98FngtrnU1@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes: >> What does this have to do with the PDP-11? If the system basicly has >> 4Meg of memory, what is to stop me from accessing a block of memory in >> I space and writing malicious code there that I later force a branch to? >> Ift his is impossible, what is the mechanism of the CPU that would >> prevent it? > > 4MB of RAM is 22 bits of address space. Being a 16 bit system > nothing a PDP-11 instruction can do will address outside of a 16 bit > address space, only 64KB. The rest of RAM is reached via base > address registers which the kernel controls. That would be equally true if the physical address space was only 16 bits as well. The point is that your virtual addresses always goes through an address translation, which both tells where the virtual address maps to in the physical address space, and can also declare that some addresses aren't even valid. > So if I space and D space are separated by more than 64K, you can't > write to I space in user mode. No, that's incorrect. You haven't really understood how this works. :-) In addition to the page relocation information, the MMU page table also tells how much of a page is actually valid. Even if you assume you only have a 16 bit physical address, things would still work just fine. You could set up page 0 of I-space to map to physical address 0, and page 1 to 7 of I-space could be invalid. And page 0 of D-space could map to physical address 8192 (the size of one page on a PDP-11), and D-space page 1 to 7 would be illegal. With this setup, the I- and D-space would be totally separated from each other, even though they are only 8K apart in physical space. Heck, I can do one better. Let's assume you have D-space virtual address 0 mapped to physical address 0. The D-space page 0 is set to be just 64 bytes of valid addresses (yes, you can do that). Page 1 to 7 are marked as totally invalid. You can then setup I-space page 0 to map to physical address 64, and beyond, and you'd still be totally safe. In theory, virtual address 64 in D-space is the same as virtual address 0 in I-space, but since the page length information for page 0 in D-space limits you, you'll get an invalid address fault if you try to access address 64 in D-space. Mission complete. I- and D-space are protected from each other, even though they are actually only separated by 64 bytes of physical address space. Note that the granularity of offsets and page lengths are 64 on a PDP-11, so less than that can't be accomplished (and the clever person will realize that 16 bit address space, times 64, equals 4 meg of address space, which is the physical limit of memory on a PDP-11, telling you that the page relocation register in the page table is also 16 bits... Surprise! :-) ) Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol ------------------------------ Date: Sat, 30 Aug 2008 14:16:45 +0200 From: Johnny Billquist Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: Bill Gunshannon skrev: > In article , > koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: >> In article <6hqa98FngtrnU1@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes: >>> What does this have to do with the PDP-11? If the system basicly has >>> 4Meg of memory, what is to stop me from accessing a block of memory in >>> I space and writing malicious code there that I later force a branch to? >>> Ift his is impossible, what is the mechanism of the CPU that would >>> prevent it? >> 4MB of RAM is 22 bits of address space. Being a 16 bit system >> nothing a PDP-11 instruction can do will address outside of a 16 bit >> address space, only 64KB. The rest of RAM is reached via base >> address registers which the kernel controls. >> >> So if I space and D space are separated by more than 64K, you can't >> write to I space in user mode. > > So, there is no way a user can fudge with the map registers outside of the > OS using Macro or whatever? Well, that is assuming the OS don't allow the program to do that. Since the page tables lives in I/O space, it requires that the user program have access to the I/O page in order to manipulate this by itself. Normal, timesharing OSes don't allow user programs to have access to the I/O page, so correct, no program have the ability to change it's mapping like that. > I never really looked, in depth, at how the > map boards on things like my 11/24 and 11/44 worked. I remember seeing > info in various places explaining how to program it. I was just curious > if it was possible for a user to do that on a running system. For RSX, you can indirectly modify your page table through system calls, but of course, that means the OS checks that it's done in a way that don't break anything. > Can I assume things like the VAX and Alpha are strictly flat address space > with all memory visible? Well, not really, no. They work sort of the same way. You have a virtual address, which goes through an address translation using a translation table, just like on the PDP-11. The difference is that the page table is way much larger. But it also maps virtual addresses to other physical addresses, on a page by page basis. So you definitely don't have all physical memory mapped in your virtual address space. That would be very weird and unhelpful. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol ------------------------------ Date: Sat, 30 Aug 2008 14:25:52 +0200 From: Johnny Billquist Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: Bob Koehler skrev: > In article <6hqir5Fnmq7fU1@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes: >> So, there is no way a user can fudge with the map registers outside of the >> OS using Macro or whatever? I never really looked, in depth, at how the >> map boards on things like my 11/24 and 11/44 worked. I remember seeing >> info in various places explaining how to program it. I was just curious >> if it was possible for a user to do that on a running system. > > IIRC, the registers are accessable only when the procesor is in > kernel mode. That's a protection provided by the hardware, just like > the privileged registers inside VAX CPUs. No. The page tables are in the I/O page. All that is required is that the I/O page is mapped in somewhere in your virtual address space. (Heck, it don't even have to be page 7, it can be any page just as well.) However, no sane OS would map the I/O page to a user program. And no sane OS would map away the I/O page from kernel mode, since that's a one way street. :-) >> Can I assume things like the VAX and Alpha are strictly flat address space >> with all memory visible? > > VAX and Alpha have flat 32 bit or 64 bit virtual address spaces > mapped to flat same size or smaller RAM addresses. The hardware > checks the page accessability on every memory read or write. So > a program is limitted to those physical addresses that are currently > mapped to that process (you can't touch another process's private > pages). And those pages that are mapped may be protected against > access, which is checked by the hardware for every memory read and > write. IIRC I64 also uses flat spaces, but I'm not sure, there may > be holes in I64 spaces. Not really true. The page table sits in between and do address translations. Your flat, linear, virtual address space can be scattered all over the physical address space, and parts of your virtual address space might not exist at all in the physical address space, causing a page fault if you try to access it. > For VMS (and most OS), all processes map all system space to the same > physical addresses all the time, but user mode code can't write to > kernel-only data structures. That's actually forced by VMS atleast. You have a per-process page table for P0 and P1 space, but the S0 page table is actually shared by all processes. Speaking of which, the VAX actually can have more physical memory than virtual, just like a PDP-11, I just remembered. In the VAX, the two high bits of a virtual address tells which space it goes to. P0, P1, S0 and S1. Of these, S1 is reserved, and has always been. So, basically, you can't have more than 3 gig of virtual address space. The last few VAXen however, extended the physical address space to the full 32 bits if I remember correctly (minus some smaller space for special stuff like buses and other fun things). Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol ------------------------------ Date: Sat, 30 Aug 2008 14:28:29 +0200 From: Johnny Billquist Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: Roger Ivie skrev: > On 2008-08-29, Bob Koehler wrote: >> VAX and Alpha have flat 32 bit or 64 bit virtual address spaces >> mapped to flat same size or smaller RAM addresses. > > More recent VAX models can handle up to (IIRC) 35 physical address bits. > They took over the "reserved for software use" bits in the PTE and used > them to extend the page-frame number. Hmm, I don't think they actually extended the physical address bits beyond 32, but there were limits in the design that previously limited physical address to less than 32 bits. Something in the back of my head says 27, but that might be totally wrong. Anyway, if we really want to know, I can read up on this. But you're right in that some of the last VAX models had more physical memory than the virtual address space of one process could address. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol ------------------------------ Date: Sat, 30 Aug 2008 14:34:47 +0200 From: Johnny Billquist Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: Bob Koehler skrev: > In article <52d8b2bd-0f07-4a2c-b30d-eaaca4f5ab10@l42g2000hsc.googlegroups.com>, DaveG writes: > >> While this trip down editor and I&D memory lane is interesting, and >> maybe I missed something, but what do these subjects have to do with >> the (almost) recent OpenVMS security findings? > > The I & D concept could potentially block the buffer overrun which > at least one of those findings seems to have exploited. Maybe, maybe not. It sounded to me more like they were able to get data on the stack, which was then used as the new PC. So it would not really execute anything on the stack. But on the other hand, if you can't manipulate the PC to get anywhere near some malicious code that you manage to stuff in a logical variable (which should be in D-space) then maybe you are right anyway. You could still crash programs, but the chances of finding any way to exploit this would diminish greatly. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol ------------------------------ Date: Sat, 30 Aug 2008 14:40:12 +0200 From: Johnny Billquist Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: Bob Koehler skrev: > In article , Johnny Billquist writes: >> As you yourself realize, the missing bit is that the page protection don't have >> an execute bit. >> The size of the address spaces are irrelevant. I space and D space have the same >> addresses, but could (would) map to different physical addresses. Why do you see >> a problem with that? >> > > I'm thinking implementation. The PDP-11 didn't have an address map. Your memory have bit faults. :-) Yes, the PDP-11 have an address map. > It had what were essentiall base address registers, 18 or 22 bit > addresses where the 16 bit address started. As long as I space and > D space start more than 16 bits apart in physical address space then > you can't access one from the other. Sorry, but no. The PDP-11 have a page table, where each page has it's own relocation information. Now, if the above is what you thought the PDP-11 had, then I can understand a whole bunch of other comments you've made, which just looked non-sensical. :-) > If you separate I space and D space via separate address maps, then > yes, you could make sure that they don't map to the same physical > addresses. And that is what the PDP-11 do. > I haven't seen that implemented. It does require hardware support, > but shouldn't be that difficult in concept since internally most > modern processors are Harvard architecures. See above. :-) > And in any case, both separating I space and D space or providing > a no-execute bit addresses only one type of security flaw (as Hoff > just reminded me). A flaw that could be addresses via good > programming and proper choice of tools. The interest is that it's > an all too common flaw. Yeah. It don't protect you from malicious smashing of the stack, which in turn leads to data being loaded into the PC. However, it also help protecting you from loads of possible ways of actually getting malicious code into your program through various paths such as logical names, filenames, and god knows what else. So it don't prevent your program from being exposed to crashing though stack manipulation, but it goes a long way from preventing malicious code from being eligible to be executed. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol ------------------------------ Date: Sat, 30 Aug 2008 14:47:47 +0200 From: Johnny Billquist Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: Johnny Billquist skrev: > Bob Koehler skrev: >> For VMS (and most OS), all processes map all system space to the same >> physical addresses all the time, but user mode code can't write to >> kernel-only data structures. > > That's actually forced by VMS atleast. You have a per-process page table > for P0 and P1 space, but the S0 page table is actually shared by all > processes. Argh! Forced by VAX, I meant. :-) Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol ------------------------------ Date: 30 Aug 2008 15:29:38 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <6ht7b2Fnfs86U2@mid.individual.net> In article <3cde3b31-285e-4be0-98e1-287219571280@l42g2000hsc.googlegroups.com>, johnwallace4@yahoo.co.uk writes: > On Aug 29, 9:41 pm, JF Mezei wrote: >> re: memory protection. >> >> Can anyone explain to me why I was under the impression that under VMS, >> you could not branch to data because data blocks were marked no-execute >> (or whatever) ? >> >> Was this ever the case ? >> >> This argument had been brought up, (perhaps in my dreams) to show how >> VMS was far mroe immune to buffer overflows than other operating >> systems. (with the corrolary that you could not write to execute >> sections and overwrite code). >> >> Recent discussions seem to have completely shattered these >> misconceptions I had, but i am really puzzled as to why I would have had >> them to begin with. > > I'd be interested in that too. For now, I'm thinking that I've assumed > that since the capability existed on PDPs (in hardware and in > compilers and in linker and OS), and that the same capability existed > in "bigger, better" VMS (at least in VMS compilers and linker (?)), > there's been an assumption on my part that the hardware and OS did the > sensible thing. As I mentioned earlier in a post which refers to the I > +DS manual, the PTE on VMS does seem to have a "fault on execute" bit, > which also supports my (apparently incorrect) assumption that data > sections are capable of being non-executable. > > But a definitive answer would be better than my assumptions. Well, that's part of the reason I brought this up. Itg seemed to me that older processors offered better protection from this kind of behavior than newer processors. Almost like someone devised the protection and then the industry said, "Nice, but we will never need that." And then, like so much of our research, it just went away only to be needed two decades later. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves billg999@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: Sat, 30 Aug 2008 08:07:15 -0700 (PDT) From: Jerry Eckert Subject: Re: Remote access vulnerability in VMS Message-ID: <5ecfe13e-db6d-40d3-91b7-c94313cc0e58@m3g2000hsc.googlegroups.com> On Aug 29, 3:36=A0pm, JF Mezei wrote: > Simon Clubley wrote: > > Hoff is reporting at > > > =A0 =A0http://64.223.189.234/node/1021 > > > that a remote access exploit against VMS has been discovered and verifi= ed. > > Woopty doo ! Since his announcement is devoid of *ANY* information, it > is absolutely meaningless. Sorry Hoff but it has to be said. > I disagree. People who are aware of the vulnerability, even without details, can exert pressure on HP to expedite release of a fix. > So far, I have found many vulnerabilities over the years, including XDM, > POP and IMAP, but they have yet to be fixed. Did you *report* them? And follow up when there was no resolution? Jerry ------------------------------ Date: 30 Aug 2008 15:12:34 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: Remote access vulnerability in VMS Message-ID: <6ht6b2Fnfs86U1@mid.individual.net> In article <48b85dd9$0$9629$c3e8da3@news.astraweb.com>, JF Mezei writes: > Simon Clubley wrote: >> Hoff is reporting at >> >> http://64.223.189.234/node/1021 >> >> that a remote access exploit against VMS has been discovered and verified. > > > Woopty doo ! Since his announcement is devoid of *ANY* information, it > is absolutely meaningless. Sorry Hoff but it has to be said. > > So far, I have found many vulnerabilities over the years, including XDM, > POP and IMAP, but they have yet to be fixed. Or reported to CERT. :-) bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves billg999@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: Sat, 30 Aug 2008 09:44:49 -0700 (PDT) From: Jerry Eckert Subject: Re: Remote access vulnerability in VMS Message-ID: On Aug 29, 11:46=A0pm, JF Mezei wrote: > Malcolm Dunnett wrote: > > =A0 =A0Let's cut Hoff some slack here. It's classic Digital culture to = not > > speak of an exploit (at least not until the fix is widely available). > > What is the point of announcing a vulnerability without giving *ANY* > details ? > > Might as well have just kept quiet and let HP issue a patch in its onw > due time (or have a fix in the next release of VMS). > > If you're going to keep details away, you would be better off to wait > for the patch to be issued and then make a public announcement (HP sure > won't) about availability of that patch that fixes a vulnerability. > > But if you want the patch to come out fast, you then provide enough > details to the public to force HP to escalate the issue and assign > resources ASAP to fix them. The public can exert pressure on HP without knowing the details. With the sketchy information that has been released, it might help to at least have an internal tracking number that can be referenced. As a system administrator, I too would like to have more information so that I can take proactive measures to reduce my exposure to the vulnerability -- or at least to know for certain there is nothing I can do. The risk of releasing the information, as Malcolm noted, is that you are also making it easier for the bad guys to exploit the vulnerability. Anyone in Hoff's position must also be careful not to jeopardize their association with the company or their internal network within the company by giving the appearance of being indiscreet in public forums. Hoff is both sensible and technically competent. I suspect he decided how much information to release based on a complete evaluation of the situation, including the risk of compromise at this time. He has given a great deal to the OpenVMS community over the years -- do you really think he'd leave us hanging now? ------------------------------ Date: Sat, 30 Aug 2008 10:30:05 -0700 (PDT) From: Jerry Eckert Subject: Re: Remote access vulnerability in VMS Message-ID: On Aug 29, 9:05=A0pm, "Richard Maher" wrote: > > I hope I'm wrong, but there was another recent post here indicating that > some were fortunate enough to enjoy the patronage of the Andy Goldsteins = of > this world, and were getting direct updates on the availability of patche= s > for other vulnerabilities while, presumably, fee-generating customers lik= e > NasdaqOMX are told to piss-off and just wait in line like everybody else? > This is common in almost any business context. While it may not seem fair to those on the outside, there is some benefit to the rest of us. These back-door channels serve as an unofficial level of pre- release testing: I wonder how many times over the years they have identified problems that were corrected before customers were impacted by them? > So how do you get in with this in-crowd? Who do you have to sleep with (o= r > threaten to sleep with :-) Is there a Clique-Membership upgrade-option on > the license/warranty agreement that one can tick? A school-tie? A > secret-handshake? A political/sexual/religious orientation that always > helps? Just whose arse(s) do you have to kiss? > He earned the trust and respect of his colleagues by demonstrating he was worthy of such. He got a break the rest of us didn't and he made good use of it. Life isn't always fair: get used to it and do the best with what you have. Jealousy rarely leads to a good end. Nor does biting the hand that feeds you (even if it's not always exactly what you want or when you want it). ------------------------------ Date: Sat, 30 Aug 2008 09:09:18 -0400 From: "David Turner" Subject: Re: rx2600s on eBay Message-ID: Fair enough I personally don't buy things (not speaking for the company) without warranty I have been burned - though it was not DEC based gear. As for the RX2600's - I agree and will probably purchase a bunch of them before HP goes in to buy them all to scrap DT "Malcolm Dunnett" wrote in message news:edVtk.19802$Rs1.10534@newsfe08.iad... > David Turner wrote: >> Hang on a second... >> I am not bad mouthing them. >> I talked to them this morning because I am interested myself. >> I was just curious of the mentality of people that buy things like this >> on Ebay. > > What do you mean by "the mentality of the people..."? > > I suppose my "mentality" is that it is my job to provide the necessary > computing services with the least impact on the corporate bottom line. > Whether I do that by purchasing via eBay, IslandCo or directly from HP is > irrelevant - each approach has its own strengths and weaknesses. > > Please don't take offense, but your comment is somewhat reminiscent of the > FUD that I used to get from DEC salesmen over the idea of buying > third-party enhancements for VAXen (or indeed for considering used > equipment from any source other than the official "DEC refurbished" > channel). > >> Some companies allow their IT people to buy on Ebay and many don't. Many >> IT pros have to justify their purchases. >> > > I don't find that hard to do. I've often purchased new or near-new HP gear > on eBay for pennies on the dollar compared to the list price. Most > beancounters have no problem seeing the value in that approach. > > Sure it doesn't come with a warranty, but, as anyone who's taken an > elementary stats class knows, a warranty is only a statistical evaluation > of claim rates combined with a price boost sufficient to cover the > estimated warranty repair costs (+ a profit margin on the warranty > itself). Just because I buy a system with a warranty there's no reason to > expect that system will be less likely to fail over the coming year. > Granted if it does fail I have a "no cost" way to get it working again, > but the warranty doesn't cover any of the lost productivity I will > experience while the system is being repaired/replaced. Alternatives to a > warranty are to put the hardware on an HP maintenance agreement (expensive > but with a guaranteed quick MTTR) or to purchase extra parts or entire > systems as spares. The benefit of the latter route is that one can > configure hot spares and have the potential for very short downtimes or > one can use the spares as test-bench systems. > > Speaking from personal experience I can say that I've never been burned on > any HP/Compaq/Digital gear I've purchased on eBay. I once bought an rx2600 > "as-is" for a really low price which turned out to have a dead motherboard > in it, but it was still worth it for the other parts I could salvage. Many > eBay vendors will offer a 30-day warranty on the stuff they sell or at > least a "non-DOA" warranty. > > If you do your homework - read the listing carefully, read the comments in > the seller's feedback and realize that sometimes a deal really is > "too good to be true" - there's no reason an IT professional shouldn't buy > on eBay. > > ps eBay has recently taken the long-overdue step of not allowing sellers > to leave negative feedback for buyers. Previously buyers were often > punished for leaving honest, but negative feedback, for a seller because > the seller would retaliate by bad-mouthing the buyer. ------------------------------ Date: Sat, 30 Aug 2008 04:02:55 -0700 (PDT) From: johnwallace4@yahoo.co.uk Subject: Re: switch vs. hub for hobbyist cluster Message-ID: <57afea74-34da-4671-aa7b-b5db8e35ee6c@56g2000hsm.googlegroups.com> On Aug 29, 9:48 pm, JF Mezei wrote: > You're not going to see magical improvements to your network by going to > a swicth. But logically, you will have improvements. > > For one thing, if you have 2 machines capable of 100, then they will > finally eb able to talk to each other at normal speed and not let the > slower vax slow them down. > > On the other hand, a switch is a "store and forward" device which > introduces some latency, especially at 10mbps. (swicth receives packet > fully, then moves it to each of the designated destination port queues > where the packets are sent out. So to send 1500 bytes, it will take > twice the transmission time (time for switch to receive packet, and time > to send it). > > On a hub, the signals are being duplicvated, so the ports receive the > bits at the same time as they are being sent. > > One big improovement a switch provides is ability to have some nodes at > full duplex even those older nodes are not. > > So your alpha1 could be receiving data from alpha2 while it is sending > data to vax1. And it doesn't have to worry about vax1 being busy because > the swicth wuill accept the packet and deliver it to vax1 whenever vax1 > is ready to listen (since vax are half duplex). JF, are you aware of "cut through" switching? Once you have the packet header for an incoming packet you can start the work. You identify the outgoing port, and if the speeds match you can start forwarding the data. You risk forwarding packets with bad checksums, but in return you improve the latency a bit. The opposite of "cut through" is "store and forward", which means the whole incoming packet is processed (including checksum) before being forwarded (or, if the checksum is wrong, it'll be ignored). Some switches can only do one mode, some do both. Even some dirt cheap stuff claims to be able to adaptively switch between the two depending on traffic (eg http://investor.netgear.com/ReleaseDetail.cfm?ReleaseID=3D11= 8752 - note the hilarious prices at the end, an FS508 introduced at $1600 is these days probably under $50, if available - I paid =A330 or so for mine a couple of years back). Something else to think about is whether the ability to set up a port to see "all" the network traffic is required; sometimes it's helpful for techies to be able to do that kind of thing, most folks wouldn't care. Typical SoHo switches don't do that, whereas it's an inherent part of basic "hub" (I hate that word, it's too ambiguous) functionality. That being said, for Philip's stated current requirements, his existing hub would seem to be more than adequate for *most* aspects. The main machines are all 10Mb max, and the chances of them being able to see a performance benefit from full duplex 100Mb switching seem small, as the NICs are constrained to 10Mb and I'd *assume* (!) there's not much benefit in two parallel sets of 10Mb connections. Only the AS1200 and the PC can get the full 16Mb of the DSL connection, and they aren't the core machines. I don't remember any mention of cables in Philip's post. Current switches are likely to be twisted pair, so if the existing kit doesn't have them, converters will be required and may not be cheap. If no adapters are required, or they already exist, then for the cost of a current equivalent of something like an FS508, it might be worth just buying one and trying it. If nothing else it could be used as a spare for the hub (unless one already exists). ------------------------------ Date: Sat, 30 Aug 2008 15:59:31 +0200 From: "H Vlems" Subject: Re: switch vs. hub for hobbyist cluster Message-ID: <48b95243$0$11691$bf4948fe@news.tele2.nl> "Phillip Helbig---remove CLOTHES to reply" schreef in bericht news:g98i28$3nu$1@online.de... > In my hobbyist cluster I have 2 VAXes and 1 ALPHA as full-time members. > A big ALPHAserver 1200 boots as a satellite when I need the computing > power to run CSWB. The VAXes are definitely 10 Mb/s, the 1200 can do > 100 I believe and I am not sure about the DEC 3000/600 (the older > ALPHA). Occasionally other VMS machines are connected up for test > purposes, and on the same LAN there is a PC which boots quickly which I > occasionally use (dons flame-proof suit) when I need really quick > internet access with a modern browser (as the 1200 takes a while to > boot). > > Now, everything goes through a 10 Mb/s hub. How much better would > performance be with a 10/100 switch instead? In particular, I am > thinking of quickly loading complicated web pages and full shadow copies > (when they unfortunately have to be done). The shadow sets consist of > disks directly connected to the same node for system disks and to two > different nodes for other disks. In particular, the biggest one, at 9 > GB, is connected to the 2 VAXes. The DSL connection to the internet is > 16 Mb/s coming in and 2048 kb/s going out. > > A 16-port 10/100 switch costs about EUR 80. Will I see an improvement > in performance worth my money? > > Note: there is no connection between the nodes other than the LAN. > There are also no dual-ported disks; each physical disk has a direct > connection to only one node. All disks are mounted on all nodes. > Philip, things may be somewhat more complex... The easy part is matching speeds. The PC and the 1200 can run at 100 Mb/s, full duplex. The VAXes and early Alpha's like the 3000-600 operate at 10 Mb/s, half duplex. Perhaps the 3000-600 can handle full duplex but since it also supports an AUI and 10base2 interface I really doubt that. A hub is just an amplifier and all ports carry the same signal. A switch builds a table of mac addresses that it has detected at each port. So it forwards packets with a destination address that it recognizes only to the appropriate port. Packets with an unknown address are sent to all ports except the one on which it was received. This only applies to unicast packets of course. Broadcast messages like LAT service packets are always transmitted to all ports (minus one). Things I noticed at home are: - Alpha 1200 to Alpha 1200 (5305's actually): DECnet runs much faster with ethernet interfaces (DE500's) set to half duplex instead of full duplex. IP (DEC's TCPIP stack) seems not or less affected. I never measured the IP transfer rate differences between HD and FD settings but tend to run the Alpha's in HD mode. - put 10 Mb/s gear on a separate 10/100 switch and 100 Mb/s systems on another. That way the link between the two switches will operate at 100 Mb/s FD. On a 10/100 switch, one or more ports may run at 10 Mb/s and this does not affect transfers between systems capable of doing 100 Mb/s. But transferring data at 10 Mb/s does take longer complete. - a 3COM or HP switch meant for use at home are no match for even the simplest Cisco switches. Two Alpha 1200's or two pc's may run as fast as 40 Mb/s, but peaks only. On a Cisco the Alphas can nearly run at full bandwidth, as fast as the switch will allow. Prices: an 8 port 3COM switch (3C-16791 Office Connect Switch) is ?45, the 16 port 3C-16792 costs ?65 (see www.aragorn.nl and this is a regular shop with good to excellent service so prices are not rockbottom). Sometimes a Cisco 10/100 is sold on eBay. Nearly always a US auction and I'm wary of importing gear designed for 110V/60 Hz I know, modern equipment recognizes input voltage and frequency but most eBay listings don't mention this capability and most vendors have no idea. Hans PS Am I correct in assuming that the 1200 started life as a 5305 ? ------------------------------ End of INFO-VAX 2008.475 ************************