From owner-freebsd-hackers Sun Jun 11 14:06:17 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id OAA18853 for hackers-outgoing; Sun, 11 Jun 1995 14:06:17 -0700 Received: from relay4.jaring.my (relay4.jaring.my [192.228.128.14]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id OAA18846 for ; Sun, 11 Jun 1995 14:06:15 -0700 Received: from tom (j14.ktk1.jaring.my [161.142.7.236]) by relay4.jaring.my (8.6.5/8.6.12) with SMTP id FAA17480 for ; Mon, 12 Jun 1995 05:06:08 +0800 Message-Id: <199506112106.FAA17480@relay4.jaring.my> X-Sender: brian@pop4.jaring.my Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 12 Jun 1995 05:07:01 +0800 To: freebsd-hackers@freebsd.org From: brian@pop.jaring.my (Brian O'Connor) Subject: Miscellaneous questions. X-Mailer: Sender: hackers-owner@freebsd.org Precedence: bulk The attached posting to comp.unix.bsd.freebsd.misc did not get any answers. Is there someone here that can help, please? Kind regards, Brian P.S. As I am not a frequent news group reader or on the reflector, please direct replies to my Email address. Newsgroups: comp.unix.bsd.freebsd.misc From: brian@pop.jaring.my (Brian O'Connor) Subject: Miscellaneous Questions, and a big Thank You. I have been using FreeBSD 2.0 (straight off the Walnut Creek CD-ROM) for about 3 months as both DNS and BOOTP servers on our network in the office. Several points have come to light during this time, as described below. However, I still think FreeBSD is great value for money, and a good way to learn about UNIX. 1. The 3c509 ethernet driver sometimes gives out kernel: ep0: Status: 2002 messages (card reset?). Is this due to network overload, or overlong ethernet packets? One of our Sun workstations sometimes complains about overlong ethernet packets, and this seems to roughly coincide with the 2002s. Our backbone regularly hits 2k packets/sec during the busy hour. The predictive interrupt code is most interesting. 2. The kernel routing table and ARP cache timeout code is apparently incomplete/soft (refer line 634 of if_ether.c). This has caused some interesting bootp server problems ("bootpd [#pid]: sendto: Host is down" log messages) with PCs not booting, which I have had to work around with shell scripts. Appears that the use count in the routing table is not being set correctly. I find the linkage between the ARP cache and the routing table very difficult to work with. Has this been module been completed/fixed yet? 3. The xlock program (in the version on the CD) does not handle the long strings produced by the password encryption algorithm. I believe a later version of xlock addresses this. 4. The load average figures printed out in response to the w and uptime commands go to zero after a prolonged period (10 -14 days). 5. Using an SMC combi card, the kernel hangs on boot up if the card (thin wire) is not connected to the network. Reconnect the coax, reboot, and all is well. Probably has something to do with the card start up checking routines. 6. The bootp server sometimes gets confused about the server IP address it puts into the bootps replies. The layer 3 address is OK, but the server sometimes puts random address into the bootps packet, straight after the "your ip address" field, and before the "gateway ip address" field. 7. An incorrect /etc/resolv.conf causes startup to hang. Both /etc/myname and /etc/resolv.conf must agree on domain name. 8. The secondary master DNS server has recently started giving out a new kernel log message during a zone transfer, as follows: named [#pid]: Ready to answer queries. <- normal log message named-xfer[#pid]: recv(len=2): n=0 && !errno <- new log message This coincides with failure to complete the zone transfer of the normal lookup DNS data file. The inverse lookup data file transfers correctly. From what I can understand of the code, this is probably caused by a zone data transfer timeout. However, the primary master server is on the same ethernet segment!! What would happen if it was over a low speed serial link? Interestingly, for the Sun DNS implementation it appears that the code will permit multiple update timeouts before a log message is generated. From memory the man pages say something about this message not being critical, and that it will only be logged the first time a timeout happens. Subsequent zone transfer attempts are supposed to overcome the failure to transfer at the first attempt. Does the timeout have something to do with the size of the DNS data files? I think at about 2000 entries for each of the forward and inverse files, and over an ethernet link, timeouts should not be a problem. Does anybody else have any experience with this, please? 9. The memory stats for the ps -aux command never move off zero percent. Any help with these matters greatly appreciated. Finally, a great big thank you to the FreeBSD team for a great piece of work. I find the neatness and integration of the FreeBSD release much to my liking, after the slightly haphazard Linux packages I have used. Brian O'Connor