On Mon, 16 Sep 1996 19:38:18 EST 
 Fletcher Christian <Fletch2@ibm.net> wrote:

 > First up, I'd like to say that my post was not intended to be a 
 > flame, it may have  
 > come over more grouchy than I'd intended because I wrote it *Very* early
 > this morning after being up all night with stomach flu. So if anyone 
 > was offended
 > I'd like to appologise in advance.

No sweat ... I read it late in the evening after dealing with a slight 
emergency :-)

 > The problem is that to use the port as it stands you need.
 >      1)   An HP
 >      2)   A network card.
 >      3)   Another host to network off that supports NFS, TCPIP and BPF.
 > 
 > Really we should only need 1). I have 5 computers capable of networking
 > (in addition to the HP) running MacOS, tripos, OS/2 and Solaris if I can't do
 > it easily who can?

If you have a tape drive, and some way to write something onto the tape, 
you can do it with:

	a) an HP
	b) a network card
	c) another hosts that can be an NFS server

BPF is not needed if you don't boot SYS_INST from the network.

 > What is the story about this? I tried to get some information on BPF from a  
 > number of sources and the consensus seems to be that it is a tool for packet
 > monitoring on the network (ie used for debugging). If the rboot stuff is now
 > well understood why is BPF still needed.

BPF is more than just a tool for monitoring network traffic.  It provides 
a raw interface to the underlying network, that can be read from or 
written to.  rbootd watches for the RMP boot request to float by, and 
builds a reply, and sends it out the wire via BPF again.  This is the 
only way to do this, since RMP operates below the level of IP (everything 
is done at the Ethernet level).  This is also how NetBSD's rarpd works 
(watches for the rarp requests to float by, replies by writing a packet 
onto the wire via BPF).

BPF is really quite a useful tool :-)

Now, at one point, Scott Reynolds and I discussed converting rbootd to 
use LBL's pcap(3) interface (NetBSD ships with libpcap), since it 
provides a pretty good abstraction to the underlying "packet snooping" 
interface (e.g. NIT under SunOS, etc.).  This would make rbootd portable 
to any system which pcap(3) supports.  HOWEVER, libpcap doesn't support 
_writing_ to the wire, only capturing packets.  This isn't terribly 
useful, as there's no way to reply without using the underlying snooper 
directly.  "Yuck."  Scott and I discussed adding a pcap_inject() to the 
pcap(3) library, but when I chatted with Craig Leres about it at USENIX, 
he wasn't all that keen about adding it to the pcap libarary, which puts 
us back at square one... (Hmm, I'll have to bug him about that again in 
Anaheim... :-)

So, that's why rbootd still uses BPF.

 > My point was that the netload option only realy works if you are in a 
 > computer
 > rich environment. If you're not then you have problems. The fact that the  
 > installation method IS netbooting (as opposed to a media based boot) 
 > emphasises
 > that the originators of the port are in a computer rich environment.

Well, I'm not sure how that could have been avoided ... but I don't mean 
to _ignore_ non-network booting... *sigh* If only for the correct 
combination of time, documentation, and working hardware... :-)

 > What I would ask is this. Suppose you pulled a 380, 9144 and a 7958 
 > out of a skip
 > but had no access to any other computer, can you load the OS?

Well ... if you had no way to write the tape to boot from, you'd be out 
of luck even with a tape-based installer :-)

 > Is this flaky as in a bad unit or is this a unit design problem? Being in
 > Europe I can't help with a bad unit (other than point out a shop in Montreal
 > Canada with lots of 9144's) but analysis of the design of the tape drive
 > may be possible once I've sorted out my logic analyser.

Flaky as in "sometimes works, sometimes doesn't".

Can you give me more information on this particular shop in Montreal?  I 
know there are several NetBSD users in that part of Canada ... I may be 
able to get one of them to pick up a drive and tapes and ship it to me if I 
send him a cheque (spelling to appease the Canadians in the audience :-)

 > The same store in Canada has lots of SH tapes too. Better than that I 
 > know of a
 > place in England with boxes and boxes of NEW HP 1/4" tapes marked  
 > "Preformated for use on HP systems"  So far I haven't picked any up 
 > because
 > it doesn't say WHICH systems. If you can send me the HP part numbers 
 > for the  
 > useable tapes I will send you some new ones if they are ok and it 
 > helps the effort.

If it says "for HP systems", it will work on the HP-IB cartridge tape 
drives.  If you could send some my way, it would _really_ help me work on 
supporting tape installs... if you can do this, please contact me 
privately to arrange the details...

 > About the HP tapes. Does anyone know what the story is?? Are the mechanisms
 > the same as standard QIC02 1/4" drives (ie are they only formated 
 > diferently) or  
 > are ther actual hardware differences? Does anyone know if it's 
 > possible to format
 > standard 1/4" cartridges to allow them to work in place of the rare HP ones?

This has been answered in a previous mail; I'm going to try and get this 
stuff on the WWW pages.

 > Thanks I'll look into this.

Cool ... let me know how it goes...

 > I'm serious, but to be honest I was more intent on an HP hardware FAQ
 > than a NetBSD one. The reason is that a HW FAQ is principly a compilation
 > and editing effort since no one person can have access to all the available
 > hardware anyway. Software FAQ's realy need the author to know a lot about
 > the software because he WILL receive questions about it. In a lot of 
 > peoples minds  
 > the FAQ editor IS the expert on that subject. Until I have more familiarity
 > with NetBSD I wouldn't realy feel comfortable as FAQ editor.
 > 
 > HOWEVER I would be willing to do the donkey work of compiling and  
 > maintaining a HP300/NetBSD FAQ if someone with more experience
 > proof read and co authored it.

You all saw it!  He volunteered!  :-)

All joking aside, I'd appreciate the help, and will be contacting you 
privately to coordinate this... I'm too busy at the moment to think about 
it... prolly in a couple of days..

 -- save the ancient forests - http://www.bayarea.net/~thorpej/forest/ -- 
Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                               Home: 408.866.1912
NAS: M/S 258-6                                          Work: 415.604.0935
Moffett Field, CA 94035                                Pager: 415.428.6939