home *** CD-ROM | disk | FTP | other *** search
/ ftp.pasteur.org/FAQ/ / ftp-pasteur-org-FAQ.zip / FAQ / internet / tcp-ip / raw-ip-faq < prev    next >
Encoding:
Internet Message Format  |  2001-11-13  |  24.4 KB

  1. Path: senator-bedfellow.mit.edu!dreaderd!not-for-mail
  2. Message-ID: <internet/tcp-ip/raw-ip-faq_1005562532@rtfm.mit.edu>
  3. Supersedes: <internet/tcp-ip/raw-ip-faq_1004179515@rtfm.mit.edu>
  4. Expires: 11 Dec 2001 10:55:32 GMT
  5. X-Last-Updated: 1999/11/12
  6. Organization: none
  7. From: shadows@whitefang.com (Thamer Al-Herbish)
  8. Newsgroups: comp.unix.programmer,comp.answers,news.answers
  9. Subject: Raw IP Networking FAQ
  10. Reply-To: shadows@whitefang.com
  11. Followup-To: poster
  12. Approved: news-answers-request@MIT.EDU
  13. Originator: faqserv@penguin-lust.MIT.EDU
  14. Date: 12 Nov 2001 10:57:09 GMT
  15. Lines: 569
  16. NNTP-Posting-Host: penguin-lust.mit.edu
  17. X-Trace: 1005562629 senator-bedfellow.mit.edu 3950 18.181.0.29
  18. Xref: senator-bedfellow.mit.edu comp.unix.programmer:130516 comp.answers:47784 news.answers:218873
  19.  
  20. Archive-name: internet/tcp-ip/raw-ip-faq
  21. Posting-Frequency: Every 15 days.
  22. URL: http://www.whitefang.com/rin/
  23.  
  24.                  Raw IP Networking FAQ 
  25.                  --------------------- 
  26.  
  27. Version 1.3 
  28.  
  29.   Last Modified on: Thu Nov 11 18:18:19 PST 1999 
  30.  
  31.   The master copy of this FAQ is currently kept at 
  32.  
  33.   http://www.whitefang.com/rin/ 
  34.  
  35.   The webpage also contains material that supplements this FAQ, along 
  36.   with a very spiffy html version. 
  37.  
  38.   If you wish to mirror it officially, please contact me for details. 
  39.  
  40. Copyright 
  41. --------- 
  42.  
  43. I, Thamer Al-Herbish reserve a collective copyright on this FAQ. 
  44. Individual contributions made to this FAQ are the intellectual 
  45. property of the contributor. 
  46.  
  47. I am responsible for the validity of all information found in this 
  48. FAQ. 
  49.  
  50. This FAQ may contain errors, or inaccurate material. Use it at your 
  51. own risk. Although an effort is made to keep all the material 
  52. presented here accurate, the contributors and maintainer of this FAQ 
  53. will not be held responsible for any damage -- direct or indirect -- 
  54. which may result from inaccuracies. 
  55.  
  56. You may redistribute this document as long as you keep it in its 
  57. current form, without any modifications. Please keep it updated if 
  58. you decide to place it on a publicly accessible server. 
  59.  
  60. Introduction 
  61. ------------ 
  62.  
  63. The following FAQ attempts to answer questions regarding raw IP or 
  64. low level IP networking, including raw sockets, and network 
  65. monitoring APIs such as BPF and DLPI. 
  66.  
  67. Additions and Contributions 
  68. --------------------------- 
  69.  
  70. If you find anything you can add, have some corrections for me or 
  71. would like a question answered, please send email to: 
  72.  
  73. Thamer Al-Herbish <shadows@whitefang.com> 
  74.  
  75. Please remember to include whether or not you want your email address 
  76. reproduced on the FAQ (if you're contributing). Also remember that 
  77. you may want to post your question to Usenet, instead of sending it 
  78. to me. If you get a response which is not found on this FAQ, and you 
  79. feel is relevant, mail me both copies and I'll attempt to include it. 
  80.  
  81. Also a word on raw socket bugs. I get approximately a couple of 
  82. emails a month about them, and sometimes I just can't verify if the 
  83. bug exists on a said system. Before mailing in the report, double 
  84. check with my example source code. If it looks like it's a definite 
  85. bug, then mail it in. 
  86.  
  87. Special thanks to John W. Temples <john@whitefang.com> for his 
  88. constant healthy criticism and editing of the FAQ. 
  89.  
  90. Credit is given to the contributor as his/her contribution appears in 
  91. the FAQ, along with a list of all contributors at the end of this 
  92. document. 
  93.  
  94. A final note, a Raw IP Networking mailing list is up. You can join by 
  95. sending an empty message to rawip-subscribe@whitefang.com 
  96.  
  97. Caveat 
  98. ------ 
  99.  
  100. This FAQ covers only information relevant to the UNIX environment. 
  101.  
  102. Table of Contents 
  103. ----------------- 
  104.  
  105.   1) General Questions: 
  106.  
  107.     1.1) What tools/sniffers can I use to monitor my network? 
  108.     1.2) What packet capturing facilities are available? 
  109.     1.3) Is there a portable API I can use to capture packets? 
  110.     1.4) How does a packet capturing facility work? 
  111.     1.5) How do I limit packet loss when sniffing a network? 
  112.     1.6) What is packet capturing usually used for? 
  113.     1.7) Will I have to replace any packets captured off the network? 
  114.     1.8) Is there a portable API to send raw packets into a network? 
  115.     1.9) Are there any high level language APIs (Not C) for raw IP 
  116.     access? 
  117.  
  118.   2) RAW socket questions: 
  119.  
  120.     2.1) What is a RAW socket? 
  121.     2.2) How do I use a raw socket? 
  122.  
  123.       2.2.1) How do I send a TCP/IP packet through a raw socket? 
  124.       2.2.2) How do I build a TCP/IP packet? 
  125.       2.2.3) How can I listen for packets with a raw socket? 
  126.  
  127.     2.3) What bugs should I look out for when using a raw socket? 
  128.  
  129.       2.3.1) IP header length/offset host/network byte order 
  130.       (feature/bug?) 
  131.       2.3.2) Unwanted packet processing on some systems. 
  132.     2.4) What are raw sockets commonly used for? 
  133.  
  134.   3) libpcap (A Portable Packet Capturing Library) 
  135.  
  136.     3.1) Why should I use libpcap, instead of using the native API on 
  137.     my operating system for packet capturing? 
  138.     3.2) Does libpcap have any disadvantages which I should be aware 
  139.     of? 
  140.     3.3) Where can I find example libpcap source code? 
  141.  
  142.   4) List of contributors 
  143.  
  144.     1) General Questions: 
  145.     --------------------- 
  146.  
  147.         1.1) What tools/sniffers can I use to monitor my network? 
  148.         --------------------------------------------------------- 
  149.  
  150.         Depending on your operating system, the following is an 
  151.         incomplete list of available tools: 
  152.  
  153.         tcpdump:     Found out-of-the-box on most BSD variants, and    
  154.                      also available separately from                    
  155.                      ftp://ftp.ee.lbl.gov/tcpdump.tar.Z along with     
  156.                      libpcap (see below) and various other tools. This 
  157.                      tool, in particular, has been ported to multiple  
  158.                      platforms thanks to libpcap.                      
  159.  
  160.         ipgrab       Compatible with many systems. ipgrab displays     
  161.                      link level, transport level, and network level    
  162.                      information on packets captured verbosely.        
  163.                      http://www.xnet.com/~cathmike/MSB/Software/       
  164.  
  165.         Ethereal     (GUI) A network packet analyzer (uses GTK+).      
  166.                      Supports many systems. Available at:              
  167.                      http://ethereal.zing.org/                         
  168.  
  169.         tcptrace:                                                      
  170.                      http://jarok.cs.ohiou.edu/software/tcptrace/tcptrace.html
  171.                      Not an actual sniffer, but can read from the logs 
  172.                      produced by many other well known sniffers to     
  173.                      produce output in different formats and in        
  174.                      adjustable details (includes diagnostics).        
  175.  
  176.         tcpflow                                                        
  177.                      http://www.circlemud.org/~jelson/software/tcpflow/
  178.                      tcpflow is a program that captures data           
  179.                      transmitted as part of TCP connections (flows),   
  180.                      and stores the data in a way that is convenient   
  181.                      for protocol analysis or debugging.               
  182.  
  183.         snoop:       Solaris, IRIX.                                    
  184.  
  185.         etherfind:   SunOS.                                            
  186.  
  187.         Packetman:   SunOS, DEC-MIPS, SGI, DEC-Alpha, and Solaris.     
  188.                      Available at                                      
  189.                      ftp://ftp.cs.curtin.edu.au:/pub/netman/           
  190.  
  191.         nettl/ntfmt: HP/UX                                             
  192.  
  193.  
  194.         1.2) What packet capturing facilities are available? 
  195.         ---------------------------------------------------- 
  196.  
  197.         Depending on your operating system (different versions may 
  198.         vary): 
  199.  
  200.         BPF:                Berkeley Packet Filter. Commonly found on BSD     
  201.                             variants.                                         
  202.  
  203.         DLPI:               Data Link Provider Interface. Solaris, HP-UX, SCO 
  204.                             Openserver.                                       
  205.  
  206.         NIT:                Network Interface Tap. SunOS 3.                   
  207.  
  208.         SNOOP:              (???). IRIX.                                      
  209.  
  210.         SNIT:               STREAMS Network Interface Tap. SunOS 4.           
  211.  
  212.         SOCK_PACKET:        Linux.                                            
  213.  
  214.         LSF:                Linux Socket Filter. Is available on Linux 2.1.75 
  215.                             onwards.                                          
  216.  
  217.         drain:              Used to snoop packets dropped by the OS. IRIX.    
  218.  
  219.  
  220.         1.3) Is there a portable API I can use to capture packets? 
  221.         ---------------------------------------------------------- 
  222.  
  223.         Yes. libpcap from ftp://ftp.ee.lbl.gov/libpcap.tar.Z attempts 
  224.         to provide a single API that interfaces with different 
  225.         OS-dependent packet capturing APIs. It's always best, of 
  226.         course, to learn the underlying APIs in case this library 
  227.         might hide some interesting features. It's important to warn 
  228.         the reader that I have seen different versions of libpcap 
  229.         break backward compatibility. 
  230.  
  231.         1.4) How does a packet capturing facility work? 
  232.         ----------------------------------------------- 
  233.  
  234.         The exact details are dependent on the operating system. 
  235.         However, the following will attempt to illustrate the usual 
  236.         technique used in various implementations: 
  237.  
  238.         The user process opens a device or issues a system call which 
  239.         gives it a descriptor with which it can read packets off the 
  240.         wire. The kernel then passes the packets straight to the 
  241.         process. 
  242.  
  243.         However, this wouldn't work too well on a busy network or a 
  244.         slow machine. The user process has to read the packets as 
  245.         fast as they appear on the network. That's where buffering 
  246.         and packet filtering come in. 
  247.  
  248.         The kernel will buffer up to X bytes of packet data, and pass 
  249.         the packets one by one at the user's request. If the amount 
  250.         exceeds a certain limit (resources are finite), the packets 
  251.         are dropped and are not placed in the buffer. 
  252.  
  253.         Packet filters allow a process to dictate which packets it's 
  254.         interested in. The usual way is to have a set of opcodes for 
  255.         routines to perform on the packet, reading values off it, and 
  256.         deciding whether or not it's wanted. These opcodes usually 
  257.         perform very simple operations, allowing powerful filters to 
  258.         be constructed. 
  259.  
  260.         BPF filters and then buffers; this is optimal since the 
  261.         buffer only contains packets that are interesting to the 
  262.         process. It's hoped that the filter cuts down the amount of 
  263.         packets buffered to stop overflowing the buffer, which leads 
  264.         to packet loss. 
  265.  
  266.         NIT, unfortunately, does not do this; it applies the filter 
  267.         after buffering, when the user process starts to read from 
  268.         the buffered data. 
  269.  
  270.         According to route <route@infonexus.com> Linux' SOCK_PACKET 
  271.         does not do any buffering and has no kernel filtering. 
  272.  
  273.         Your mileage may vary with other packet capturing facilities. 
  274.  
  275.         1.5) How do I limit packet loss when sniffing a network? 
  276.         -------------------------------------------------------- 
  277.  
  278.         If you're experiencing a lot of packet loss, you may want to 
  279.         limit the scope of the packets read by using filters. This 
  280.         will only work if the filtering is done before any buffering. 
  281.         If this still doesn't work because your packet capturing 
  282.         facility is broken like NIT, you'll have to read the packets 
  283.         faster in a user process and send them to another process -- 
  284.         basically attempt to do additional buffering in user space. 
  285.  
  286.         Another way of improving performance, is by using a larger 
  287.         buffer. On Irix using SNOOP, the man page recommends using 
  288.         SO_RCVBUF. On BSD with BPF one can use the BIOCSBLEN ioctl 
  289.         call to increase the buffer size. On Solaris bufmod and pfmod 
  290.         can be used for altering buffer size and filters 
  291.         respectively. 
  292.  
  293.         Remember, the longer your process is busy and not attending 
  294.         the incoming packets, the quicker they'll be dropped by the 
  295.         kernel. 
  296.  
  297.         1.6) What is packet capturing usually used for? 
  298.         ----------------------------------------------- 
  299.  
  300.         (Question suggested by Michael T. Stolarchuk <mts@rare.net> 
  301.         along with some suggestions for the answer.) 
  302.  
  303.             Network diagnostics such as the verification of a 
  304.             network's setup, examples are tools like arp, that report 
  305.             the ARP messages sent from hosts. 
  306.  
  307.             Reconstruction of end to end sessions. tcpshow attempts 
  308.             to do this, but more sophisticated examples are the array 
  309.             of security tools which try to keep tabs on network 
  310.             connections. 
  311.  
  312.             Monitoring network load. Probably one of the most 
  313.             practical uses, a lot of commercial products usually use 
  314.             specialized hardware to accomplish this. 
  315.  
  316.         1.7) Will I have to replace any packets captured off the 
  317.         network? 
  318.         
  319.         --------------------------------------------------------------
  320.         
  321.  
  322.         No, the packet capturing facilities mentioned make copies of 
  323.         the packets, and do not remove them from the system's TCP/IP 
  324.         stack. If you wish to prevent packets from reaching the 
  325.         TCP/IP stack you need to use a firewall, (which should be 
  326.         able to do packet filtering). Don't confuse the packet 
  327.         filtering done by packet capturing facilities with those done 
  328.         by firewalls. They serve different purposes. 
  329.  
  330.         1.8) Is there a portable API to send raw packets into a 
  331.         network? 
  332.         
  333.         --------------------------------------------------------------
  334.         
  335.  
  336.         Yes, route <route@infonexus.com> maintains Libnet, a library 
  337.         that provides an API for low level packet writing and 
  338.         handling. It serves as a good compliment for libpcap, if you 
  339.         wish to read and write packets. The project's webpage can be 
  340.         found at: 
  341.  
  342.         http://www.packetfactory.net/libnet/ 
  343.  
  344.         1.9) Are there any high level language APIs (Not C) for raw 
  345.         IP access? 
  346.         
  347.         --------------------------------------------------------------
  348.         
  349.  
  350.         A PERL module that gives access to raw sockets is available 
  351.         at: 
  352.  
  353.         http://quake.skif.net/RawIP/ 
  354.  
  355.         A Python library "py-libpap" can be found at: 
  356.  
  357.         ftp://ftp.python.org/pub/python/contrib/Network/ 
  358.  
  359.     2) RAW socket questions: 
  360.     ------------------------ 
  361.  
  362.         2.1) What is a RAW socket? 
  363.         -------------------------- 
  364.  
  365.         The BSD socket API allows one to open a raw socket and bypass 
  366.         layers in the TCP/IP stack. Be warned that if an OS doesn't 
  367.         support correct BSD semantics (correct is used loosely here), 
  368.         you're going to have a hard time making it work. Below, an 
  369.         attempt is made to address some of the bugs or surprises 
  370.         you're in store for. On almost all sane systems only root 
  371.         (superuser) can open a raw socket. 
  372.  
  373.         2.2) How do I use a raw socket? 
  374.         ------------------------------- 
  375.  
  376.             2.2.1) How do I send a TCP/IP packet through a raw 
  377.             socket? 
  378.             
  379.             ----------------------------------------------------------
  380.             
  381.  
  382.             Depending on what you want to send, you initially open a 
  383.             socket and give it its type. 
  384.  
  385.             sockd = socket(AF_INET,SOCK_RAW,<protocol>); 
  386.  
  387.             You can choose from any protocol including IPPROTO_RAW. 
  388.             The protocol number goes into the IP header verbatim. 
  389.             IPPROTO_RAW places 0 in the IP header. 
  390.  
  391.             Most systems have a socket option IP_HDRINCL which allows 
  392.             you to include your own IP header along with the rest of 
  393.             the packet. If your system doesn't have this option, you 
  394.             may or may not be able to include your own IP header. If 
  395.             it is available, you should use it as such: 
  396.  
  397.  
  398.             char on = 1; 
  399.             setsockopt(sockd,IPPROTO_IP,IP_HDRINCL,&on,sizeof(on)); 
  400.  
  401.             Of course, if you don't want to include an IP header, you 
  402.             can always specify a protocol in the creation of the 
  403.             socket and slip your transport level header under it. 
  404.  
  405.             You then build the packet and use a normal sendto(). 
  406.  
  407.             2.2.2) How do I build a TCP/IP packet? 
  408.             -------------------------------------- 
  409.  
  410.             Examples can be found at http://www.whitefang.com/rin/ 
  411.             which attempt to illustrate the details involved. They 
  412.             also illustrate some of the bugs mentioned below. 
  413.  
  414.             Briefly, you need to actually write the packet out in 
  415.             memory and hand it over to the socket where it will 
  416.             hopefully fire it away and await more packets. 
  417.  
  418.             2.2.3) How can I listen for packets with a raw socket? 
  419.             ------------------------------------------------------ 
  420.  
  421.             Traditionally the BSD socket API did not allow you to 
  422.             listen to just any incoming packet via a raw socket. 
  423.             Although Linux (2.0.30 was the last version I had a look 
  424.             at), did allow this, it has to do with their own 
  425.             implementation of the TCP/IP stack. Correct BSD semantics 
  426.             allow you to get some packets which match a certain 
  427.             category (see below). 
  428.  
  429.             There's a logical reason behind this; for example TCP 
  430.             packets are always handled by the kernel. If the port is 
  431.             open, send a SYN-ACK and establish the connection, or 
  432.             send back a RST. On the other hand, some types of ICMP (I 
  433.             compiled a small list below), the kernel can't handle. 
  434.             Like an ICMP echo reply, is passed to a matching raw 
  435.             socket, since it was meant for a user program to receive 
  436.             it. 
  437.  
  438.             The solution is to firewall that particular port if it 
  439.             was a UDP or TCP packet, and sniff it with a packet 
  440.             capturing API (a list is mentioned above). This prevents 
  441.             the TCP/IP stack from handling the packet, thus it will 
  442.             be ignored and you can handle it yourself without 
  443.             intervention. 
  444.  
  445.             If you don't firewall it, and reply yourself you'll wind 
  446.             up having additional responses from your operating 
  447.             system! 
  448.  
  449.             Here's a concise explanation of the semantics of a raw 
  450.             BSD socket, taken from a Usenet post by W. Richard 
  451.             Stevens 
  452.  
  453.             From <rstevens@kohala.com> (Sun Jul 6 12:07:07 1997) : 
  454.  
  455.             "The semantics of BSD raw sockets are: 
  456.  
  457.             -  TCP and UDP: no one other than the kernel gets these.            
  458.  
  459.             -  ICMP: a copy of each ICMP gets passed to each matching raw       
  460.                socket, except for a few that the kernel generates the reply     
  461.                for: ICMP echo request, timestamp request, and mask request.     
  462.  
  463.             -  IGMP: all of these get passed to all matching raw sockets.       
  464.  
  465.             -  all other protocols that the kernel doesn't deal with (OSPF,     
  466.                etc.): these all get passed to all matching raw sockets."        
  467.  
  468.             After looking at the icmp_input() routine from the 
  469.             4.4BSD's TCP/IP stack, it seems the following ICMP types 
  470.             will be passed to matching raw sockets: 
  471.  
  472.                 Echo Reply: (0) 
  473.  
  474.                 Router Advertisement (9) 
  475.  
  476.                 Time Stamp Reply (13) 
  477.  
  478.                 Mask Reply (18) 
  479.  
  480.  
  481.         2.3) What bugs should I look out for when using a raw socket? 
  482.         ------------------------------------------------------------- 
  483.  
  484.             2.3.1) IP header length/offset host/network byte 
  485.             (feature/bug?) 
  486.             
  487.             ----------------------------------------------------------
  488.             
  489.  
  490.             Systems derived from 4.4BSD have a bug in which the 
  491.             ip_len and ip_off members of the ip header have to be set 
  492.             in host byte order rather than network byte order. Some 
  493.             systems may have fixed this. I've confirmed this bug has 
  494.             been fixed on OpenBSD 2.1. 
  495.  
  496.             2.3.2) Unwanted packet processing on some systems. 
  497.             -------------------------------------------------- 
  498.  
  499.             Thanks to Michael Masino <mmasino@mitre.org> , Lamont 
  500.             Granquist <lamontg@hitl.washington.edu> , and route 
  501.             <route@infonexus.com> for the submission of bug reports. 
  502.  
  503.             Some systems will process some of the fields in the IP 
  504.             and transport headers. I've attempted to verify the 
  505.             reports I've received here's what I can verify for sure. 
  506.  
  507.             Solaris (at least 2.5/2.6) and changes the IP ID field, 
  508.             and adds a Do Not Fragment flag to the IP header (IP_DF). 
  509.             It also expects the checksum to contain the length of the 
  510.             transport level header, and the data. 
  511.  
  512.             Further reports which I cannot verify (can't reproduce), 
  513.             consist of claims that Solaris 2.x and Irix 6.x will 
  514.             change the sequence and acknowledgment numbers. Irix 6.x 
  515.             is also believed to have the problem mentioned in the 
  516.             previous paragraph. If you experience these problems, 
  517.             double check with the example source code. 
  518.  
  519.             You'll save yourself a lot of trouble by just getting 
  520.             Libnet http://www.packetfactory.net/libnet/ 
  521.  
  522.         2.4) What are raw sockets commonly used for? 
  523.         -------------------------------------------- 
  524.  
  525.         Various UNIX utilities use raw sockets, among them are: 
  526.         traceroute, ping, arp. Also, a lot of Internet security tools 
  527.         make use of raw sockets. However in the long run, raw sockets 
  528.         have proven bug ridden, unportable and limited in use. 
  529.  
  530.     3) libpcap (A Portable Packet Capturing Library) 
  531.     ------------------------------------------------ 
  532.  
  533.         3.1) Why should I use libpcap, instead of using the native 
  534.         API on my operating system for packet capturing? 
  535.         
  536.         --------------------------------------------------------------
  537.         
  538.  
  539.         libpcap was written so that applications could do packet 
  540.         capturing portably. Since it's system independent and 
  541.         supports numerous operating systems, your packet capturing 
  542.         application becomes more portable to various other systems. 
  543.  
  544.         3.2) Does libpcap have any disadvantages, which I should be 
  545.         aware of? 
  546.         
  547.         --------------------------------------------------------------
  548.         
  549.  
  550.         Yes, libpcap will only use in-kernel packet filtering when 
  551.         using BPF, which is found on BSD derived systems. This means 
  552.         any packet filters used on other operating systems which 
  553.         don't use BPF will be done in user space, thus losing out on 
  554.         a lot of speed and efficiency. This is not what you want, 
  555.         because packet loss can increase when sniffing a busy 
  556.         network. 
  557.  
  558.         DEC OSF/1 has an API which has been extended to support 
  559.         BPF-style filters; libpcap does utilize this. 
  560.  
  561.         In the future, libpcap may translate BPF style filters to 
  562.         other packet capturing facilities, but this has not been 
  563.         implemented yet as of version 0.3 
  564.  
  565.         Refer to question 1.4 to see how packet filters help in 
  566.         reliably monitoring your network. 
  567.  
  568.         3.3) Where can I find example libpcap source code? 
  569.         -------------------------------------------------- 
  570.  
  571.         A lot of the source code found at LBNL's ftp archive 
  572.         ftp://ftp.ee.lbl.gov/ uses libpcap. More specifically, 
  573.         ftp://ftp.ee.lbl.gov/tcpdump.tar.Z probably demonstrates 
  574.         libpcap to a large extent. 
  575.  
  576.     4) List of contributors. 
  577.     ------------------------ 
  578.  
  579.       Thamer Al-Herbish <shadows@whitefang.com> 
  580.       W. Richard Stevens <rstevens@kohala.com> 
  581.       John W. Temples (III) <john@whitefang.com> 
  582.       Michael Masino <mmasino@mitre.org> 
  583.       Lamont Granquist <lamontg@hitl.washington.edu> 
  584.       Michael T. Stolarchuk <mts@rare.net> 
  585.       Mike Borella <Mike_Borella@mw.3com.com> 
  586.       route <route@infonexus.com> 
  587.       Derrick J Brashear <shadow@dementia.org> 
  588.  
  589.