Date: Mon, 12 Jun 1995 05:07:01 +0800 From: brian@pop.jaring.my (Brian O'Connor) To: freebsd-hackers@freebsd.org Subject: Miscellaneous questions. Message-ID: <199506112106.FAA17480@relay4.jaring.my>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199506112106.FAA17480>