test-drb November 2001

test-drb@ccmp.vtda.org

247 participants
886 discussions

by pete＠dunnington.u-net.com

On Nov 2, 16:30, Douglas Quebbeman wrote: > > On Nov 2, 8:03, Douglas Quebbeman wrote: > Someone else pointed out IFCONFIG; sorry, not a *nix guru. > I tolerate *nix as Multics' poor deformed little brother. ;-) > > Don't forget to restore the original address with "ifconfig le0 111.0.0.1 > > broadcast 111.255.255.255 netmask 255.0.0.0 up" when you've finished :-) > > What does 'broadcast' do (other than the obvious)? It's just a way of explicitly stating what the broadcast address for that interface is. In every legitimate case I can think of, it should be redundant if you provide the netmask (or the netmask is redundant if you give the broadcast address). I'm not sure what happens if they don't match. Maybe that's allowed if you have multiple IP addresses (ip aliases) for the same physical interface, then perhaps you could use a "broader" broadcast address to listen to more than one subnet on the same interface. I don't know. > > It'll take a while to work through the class C range > Yes, I'd say he would benefit from some filtering if he > has to check all the class C range, but I was assuming > this could take a couple of months, worst-case... You were about right then, I think! I wasn't having a dig at you! Merely "thinking out loud" and pointing out (in case Arno, for example, didn't see the implications) that there are rather a lot of addresses :-) Even then, it might not work. The range of network addresses from 224.0.0.0 to 239.255.255.255 are used for multicast, and no ordinary IP software uses those for unicast (normal) or broadcast traffic. Above that, I don;t know of any allocated uses, and things aren't suposed to respond to them at all, which would be a problem if the setting are corrupt in such a way as to fall in that range. -- Pete Peter Turnbull Network Manager University of York

24 years

PDP 11 / 83

by Thomas.J.Lynch＠usa.xerox.com

Anyone interested in PDP11 /83? I've got a couple at auction, with a supplementary rack or two. Don't want 'em real bad, now. For shipping and a few dollars they might go your way, if you want 'em. They're in Rochester, NY area. Phone 716/671-7308 or email tomsir(a)rochester.rr.com Have a good day :=)

24 years

classiccmp-digest V1 #761

by ajp166＠bellatlantic.net

Ah yes but, the CMOS ram would cause one problem for the design... Common IO. The 74189/289 had seperate IO unless I've suffered a major brain cramp. Allison -----Original Message----- From: Richard Erlacher <edick(a)idcomm.com> To: classiccmp(a)classiccmp.org <classiccmp(a)classiccmp.org> Date: Friday, November 02, 2001 11:28 AM Subject: Re: classiccmp-digest V1 #761 >The '289's are inverting, though tristate, just like the '189's. TI made a '219 >which was a noninverting tristate version of this same sort and pinout. ISTR >that there was yet another part, albeit not of the normal 74xxx sort, that was a >non-inverting version as well, but I can't, for the life of me, rememberit >(senior moment). These days, it's both cheaper and easier (faster, too) to use >a CMOS ram of considerably larger size. > >Dick > >----- Original Message ----- >From: "Ben Franchuk" <bfranchuk(a)jetnet.ab.ca> >To: <classiccmp(a)classiccmp.org> >Sent: Thursday, November 01, 2001 5:17 PM >Subject: Re: classiccmp-digest V1 #761 > > >> ajp166 wrote: >> > >> > Those parts were never cheap! >> > >> > You can also use 74289s for the '189s. The '382s are an improved version >> > of the '182. A note, if you can tolerate a slower ALU you can omit the >> > '382s >> > and just use ripple carry. >> >> If the 74289's are the non inverting 16x4 rams I would use them. I plan >> to use 74ls382's (the ripple carry alu's). >> >> > A sub for 74189s is some of the byte wide cache rams from an old 386/486 >> > PC as the faster ones were faster than the TTL 74189! You dont have to use >> > the full space of the cache ram though having it would make afor an >interesting >> > register array. >> >> Can't do that for three reasons >> 1) I am use a 16 x 12 ram ( 3 chips ) on two boards for a 8 x 24 >> register array. >> 2) I am using the 486 cache chips as main memory in my FPGA prototype >> 32k x 12 bits.:) >> 3) This was a TTL design on paper of what a computer designed in the >> early 1980's >> could have been like. That rules out 2901 bit slices. >> >> > Allison >> As it stands today I have a FPGA ( pat pat pat ) that is configured to >> have a similar >> layout as the ttl design and this lets me play around with the >> configuration. Mind you a >> larger TTL CPU with lights and switches is more impressive. If you like >> lights >> and switches here is a neat link http://www.angelfire.com/scifi/B205/ >> 'to the Bat Cave' >> >> Ben Franchuk. >> -- >> Standard Disclaimer : 97% speculation 2% bad grammar 1% facts. >> "Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk >> Now with schematics. >> >> >

24 years

Picture books of old computers

by LFessen106＠aol.com

In a message dated 11/02/2001 16:25:11, you wrote: >We have a bunch of computer museum people on this list, I am curious if any >of their related organizations plan on doing a coffee table picture book of >old computers? It would be nice if something REALLY comprehensive was >available. Does anyone even have a "list" of all the computers ever made? >That might be a pretty good start, an all text web page with every computer >and model in a long list, then make it links to more data, etc. etc. Now *that* would be cool!

24 years

Redactron WP

by mhstein＠usa.net

Redactron dual mag card WP (with one card), schematic, no printer. Can I assume there's no interest and I can finally toss something without feeling guilty? mike

24 years

Thick Ethernet/Sun networking problems

by pete＠dunnington.u-net.com

On Nov 2, 10:13, Arno Kletzander wrote: > OK Pete (and everybody else, of course), I admit that was a *long* break > since I brought that up last time - but now I think I have collected enough > information for a new chapter...So, where did we get stuck? > OK, as the IP Adress of the SUN 1+ is 111.0.0.14 and the Subnet Mask > ff:00:00:00 (says so at boot): Which is correct for a Class A network... > ping -s 111.255.255.255 > (if everything on the network is powered up and the PC is configured for > TCP/IP transfer) gets answers from: > hombre (111.0.0.14);the sending machine itself > papa (111.0.0.23);the SUN SPARCstation 2 on the next desk > ? (111.0.0.83);a PC I've finally set up for sniffing > > Nothing however from the printer. :-( > No idea whether that helps, but if both the SUN 1+ and the printer are > powered up, an arp -a shows: > pa3 111.1.0.1 at (incomplete) Is "pa3" the printer name? What that means is that the Sun's Ethernet software "knows" that "pa3" means IP address 111.1.0.1, but nothing has responded to any attempt to communicate with that IP address, so it doesn't know its hardware address. On an Ethernet, as you probably know, the data packet is wrapped in several layers of what you might think of as envelopes. The outermost one contains the MAC addresses of sender and intended recipient, and is what is always used for the delivery of the packet to the next (which may be the final) destination en route. So for "hombre" to know how to send a packet to "pa3", it first looks up pa3's IP address (in etc/hosts, or using DNS), and then broadcasts an ARP (Address Resolution Protocol) packet (sender: hombre's MAC address; destination: Ethernet broadcast address, FF:FF:FF:FF:FF:FF) containing that IP address as data. Whoever owns that IP address is supposed to respond with an ARP reply (same packet type, different flags inside, with sender: pa3's MAC address; destination: hombre's MAC address). Thus hombre learns pa3's MAC address, which it stores in it's ARP table, and uses to send a packet (the one it originally wanted to send) to pa3's MAC address. > and out of 25 packets I sniffed (Man, am I high now ;-)), 20 were ETHER type > 0806 (ARP), the remaining 5 were type 0800. Without knowing what was in the packet headers, I can't say what they were. But probably the ARP packets were hombre repeatedly broadcasting an ARP request to get pa3's MAC address. > OK, as I didn't finde snoop on the Suns (and didn't want to fiddle with > compiling programs by myself at this stage...), snoop is only available as a binary, from Sun themselves (or from SGI, for the IRIX version). tcpdump and other similar programs are available as freeware with source. tcpdump needs a library called libpcap, whicxh is also used by other decoders/analysers, such as Ethereal. > I set up a PC with a network > card, packet drivers and EtherLoad 2.00. Connected this to the idle transceiver, > started with -r (record traffic), powered up one SUN and recorded the first > 10 packets from it, then powered up the printer and recorded until I had 25 > (the printer had then finished its warmup cycle and was displaying "READY"). > Got only packets sent by the SUN (MAC: 08.00.20.09.BC.D7) destined for > FF.FF.FF.FF.FF.FF (everybody?). Probably ARP requests. FF.FF.FF.FF.FF.FF is the broadcast address (destination, in this case). The next layer in the packet would tell you what IP address it was ARPing for. BTW, Ethernet addresses are normally represented with colons (':') separating the octets, not spaces or periods. > The sniffer's HEX output file decodes to a lot of unreadable characters if > interpreted as ASCII; only in the second packet that appears after switching > the SUN on, the host name 'hombre' is readable. > Decoding the whole data to decimal numbers show up the SUN's IP adress in > all packets, the address the printer should have in the eighth and every > following packet. Yes, they won't mean much in that form. The format of an ARP packet is: hardware type code (2 octets), protocol type code (2 octets), hex 06 (the hardware address length, assuming Ethernet), hex 04 (the IP address length, assuming Ethernet), opcode flags (16 bits giving the type of request/reply) source MAC (6 octets), source IP (4 octets, all zeros if this is a reverse-ARP), destination MAC (6 octets), destination IP (4 octets, may be FFFFFFFF for a broadcast). hombre's IP address appears because it's the sender address of the packets; the name appearing in the second packet suggests it might be a NIS packet of some sort. > Is there a DOS based sniffer out there which will produce output as > understandable as snoop? There's an old version of LANdecoder that runs under DOS, I think. It's not free, though, and I've no idea where to get a copy. > >On most of the Ethernet-enabled printers I've come across (mostly HPs, > Lexmarks, and Xeroxes) you >can do the setup from the front panel -- sometimes > tedious, but usually not too hard to understand. Some of the HP deskjets with JetDirect cards can only be setup/accessed by telnet or RARP/BOOTP/DHCP. > However, with us there is no sys admin - so how can we 'accomplish these > tasks'? You are your own sysadmin :-) > CalComp Internal Ethernet Adapter > Revision 4.11, Datecode 12/20 1994 10:20 > Burnin Value = 0 SRAM = 256K bytes, Novram = 128 bytes > Ethernet address 00 C0 E2 00 0C 8E That's the address you need for /etc/ethers on a RARP server (or /etc/bootp.conf on a BOOTP or DHCP server for clients that talk something more sophisticated than just RARP). > Netware options: > !!! Netware DISABLED (use 'N' menu to re-enable) !!! Leave it this way unless you need Novell -- it's very broadcasty and wasteful of bandwidth (a few machines won't be a bother, but a hundred on a segment could) > Auto sense ethernet type between Ethernet II and 802.3 > Apple EtherTalk options: > EtherTalk DISABLED !!! (use 'N' menu to re-enable ) > Printer name: CalComp CCL600ES > Internally stored zone name: * > Ethertalk Phase 2 Leave this off too unless you need it. > LPD ( remote printer queues ) options: > LPD enabled LPD refers to the use of the Berkeley 'lpr' line printer protocol, commonly used by UNIX systems. This is the one your Suns want. > But no idea on how to get this printed again to verify the settings haven't > changed (e.g. due to bitrot in the Novram)... Some more experimentation is needed to be sure what all the symptoms really mean. However, obviously the printer isn't responding to an ARP request for what should be its own IP address. Therefore either it is using some other IP address, or it has lost it's configuration and needs to be supplied an IP address (by RARP or otherwise), or the interface is broken/dormant. I expect that this printer, which is quite old, can only use RARP (which is an old and simple protocol, but still in use), not BOOTP or DHCP, to get an IP address. If it were actually trying to do so, you ought to see some ARP packets emanating from the printer, with the printer's MAC address as the source, and the Ethernet broadcast address as the destination. Since you're not seeing that, I assume the card is either completely faulty (no link light etc?) or is so badly misconfigured (possibly the setup has been corrupted by age, or suffers from flat battery if there is one) that it needs reset to factory defaults before it will operate. -- Pete Peter Turnbull Network Manager University of York

24 years

Ecomstation.org (was Re: An Organization (was: Do we have a V AXorganization?))

by dhquebbeman＠theestopinalgroup.com

> >This flame war has been done before. I'm only participating here because > >I was individually lambasted. Methinks IHBT... > > IHBT? I Had Better T<something>... -dq

24 years

Picture books of old computers

by dhquebbeman＠theestopinalgroup.com

Sellam sayeth: > On Fri, 2 Nov 2001, Mike Ford wrote: > > > We have a bunch of computer museum people on this list, I am curious > > if any of their related organizations plan on doing a coffee table > > picture book of old computers? It would be nice if something REALLY > > comprehensive was available. Does anyone even have a "list" of all the > > computers ever made? That might be a pretty good start, an all text > > web page with every computer and model in a long list, then make it > > links to more data, etc. etc. > > Hans Pufal used to have the Comprehensive Computer Catalogue but that > doesn't seem to be up anymore :( > > There was also another one called The Old Computers List but it seems to > be gone too. here are a few (mostly variants of the same list): http://www.comp.nus.edu.sg/~johnm/cs3220/Computer_index.htm http://www.op.net/docs/Computer-Folklore/Computer_list http://www.cs.unr.edu/~han/DClist.html and many links to more such resources at: http://ed-thelen.org/comp-hist/links.html -dq

24 years

Price guide for vintage computers

by dhquebbeman＠theestopinalgroup.com

> That sound like my interpretation of the Claus Buckholtz 256k Atari800xl > 'dead bug' upgrade. Dead bug because the ic's were upside down, legs > splayed.... Kind of off-the-subject, but the upside-chip-epoxied-on is a fairly common field-engineering trick... done it more than once myself. -dq

24 years

Thick Ethernet/Sun networking problems

by dhquebbeman＠theestopinalgroup.com

> On Nov 2, 8:03, Douglas Quebbeman wrote: [..snip..] > > If that doesn't work, this next idea will take some time and preparation. > > Get a Windows 2000 or Windows XP machine. They allow you to change the > > machine's network address on the fly (can Linux do this?) > > MOST systems other than Windows can do this :-) > > It's not a good idea if you need to go through all the networks numbers > (see end of this post for the reason, if you've not realised yet). Someone else pointed out IFCONFIG; sorry, not a *nix guru. I tolerate *nix as Multics' poor deformed little brother. A useful tool, tho, no disputing that, and no Multics in sight to brag about any more. :( And as to the other thing you're alluding to, I never have professed to be an expert on TCP/IP... I was assuming he'd work with one class of networks at a time, tho... [..snip..] > Don't forget to restore the original address with "ifconfig le0 111.0.0.1 > broadcast 111.255.255.255 netmask 255.0.0.0 up" when you've finished :-) What does 'broadcast' do (other than the obvious)? > It'll take a while to work through the class C range, because ping will > take a while to time out on each network number :-) Say two seconds per > network, thats (224-192) * 256 * 256 * 2 seconds, about 4 million seconds, > or just over 48 days. Oh, and you'll probably want to refine my shell > script to eliminate the unneccesary lines generated by ping recording > responses from the Sun itself, and the headers. You don't need 12 million > extra lines in the output :-) Yes, I'd say he would benefit from some filtering if he has to check all the class C range, but I was assuming this could take a couple of months, worst-case... -dq

24 years

← Newer
1
...
82
83
84
85
86
87
88
89
Older →

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

test-drb November 2001