From owner-cvs-usrsbin  Mon Nov 18 14:08:25 1996
Return-Path: owner-cvs-usrsbin
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id OAA16023
          for cvs-usrsbin-outgoing; Mon, 18 Nov 1996 14:08:25 -0800 (PST)
Received: (from wpaul@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id OAA15958;
          Mon, 18 Nov 1996 14:07:47 -0800 (PST)
Date: Mon, 18 Nov 1996 14:07:47 -0800 (PST)
From: Bill Paul <wpaul>
Message-Id: <199611182207.OAA15958@freefall.freebsd.org>
To: CVS-committers, cvs-all, cvs-usrsbin
Subject: cvs commit:  src/usr.sbin/rarpd Makefile rarpd.c arptab.c etherent.c
Sender: owner-cvs-usrsbin@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

wpaul       96/11/18 14:07:45

  Modified:    usr.sbin/rarpd  Makefile rarpd.c
  Removed:     usr.sbin/rarpd  arptab.c etherent.c
  Log:
  Fix up new rarpd.
  
  This includes the following changes:
  
  - Support for poking ARP entries into the local table is now built
    in, so the arptab.c module I hacked together is no longer needed.
  
  - rarp_process() and rarp_reply() now accept a len argument which is
    passed down from rarp_loop() which tells rarp_reply() exactly how
    long the original RARP frame was. (Usually, it's 60 bytes, which is
    the minimum.) Previously, the length was calculated using the sum
    of sizeof(struct ether_header) + sizeof(struct ether_arp) (plus the
    ethernet frame header, I think). The result was a total packet
    length of 42 bytes. Now, rarp_reply() sends out packets that are
    the same size as those it recieves (60 bytes). This agrees with the
    behavior of rarpd on SunOS (as observed with tcpdump). The unused
    extra bytes are zeroed.
  
  Revision  Changes    Path
  1.4       +3 -2      src/usr.sbin/rarpd/Makefile
  1.8       +532 -279  src/usr.sbin/rarpd/rarpd.c