-----BEGIN PGP SIGNED MESSAGE-----


  On 11 September 1998, I wrote in
<199809111404.KAA15123@istari.sandelman.ottawa.on.ca> about problems I
was having with excessive TCP retransmits on my local LAN.
  Suggestions were made to increase NMBCLUSTERS to 1024 or 2048.
  This hasn't helped. At least, it hasn't helped noticeably.

  Maybe this is a cabling problem. If so, tell me. After:


istari-[~/Mail/netbsd] mcr 1015 %uptime
11:20AM  up 1 day,  2:55, 4 users, load averages: 0.14, 0.36, 0.53

I see:

ip:
        173808 packets sent from this host
        0 packets sent with fabricated ip header
        155450 output packets dropped due to no bufs, etc.

  I'm wondering what the "etc." is. "odropped" only appears in ip_output()
in response to ENOBUFS. Erik Fair told me awhile ago the de driver may
return ENOBUFS incorrectly to indicate other conditions. (Forgive me Erik,
I don't have that message around) However I don't see that the driver is
involved here. MGETHDR() is there.
  I note:
istari-[~/Mail/netbsd] mcr 1017 %netstat -m
35 mbufs in use:
        32 mbufs allocated to data
        2 mbufs allocated to packet headers
        1 mbufs allocated to socket names and addresses
0/0 mapped pages in use
4 Kbytes allocated to network (100% in use)
0 requests for memory denied
0 requests for memory delayed
0 calls to protocol drain routines

  I.e. Since the last three lines are 0, I don't see why MGETHDR() would
ever fail to allocate an mbuf, unless waiting for mbuf/mbuf clusters
frequently involves calls to blocking routines. I wish I had netstat-m
output when the system is slow. Of course, that never happens when
I'm trying to report things, and sometimes I can't even type stuff...

tcp:
        258 packets received
                36873 acks (for 0 bytes)
                2 duplicate acks
                0 acks for unsent data
                608 packets (135914 bytes) received in-sequence
                0 completely duplicate packets (0 bytes)
                13556698 old duplicate packets
                38851 packets with some dup. data (1501477 bytes duped)
                12 out-of-order packets (7400 bytes)
                496 packets (259444 bytes) of data after window
                0 window probes
                53330 window update packets
                0 packets received after close
                56495 discarded for bad checksums
                7608726 discarded for bad header offset fields
                0 discarded because packet too short

  First question: I assume a counter rolled over, because "258 packets"
is rediculous. The number of "old duplicate packets" and "discarded for
bad header offset fields" seems VERY VERY high.
  I am considering logging these packets. However, I'm somewhat scared 
that I'll simply crash the system with logging :-(
  I will try to do this soon. Suggestions and code fragments to 
intelligently log the packet are welcome.

  It looks like line 495 of tcp_input.c is the only place this is incremented.
The major data traffic is SSH traffic between my Xterm and this CPU server.
Do we have a bug somewhere in tcp_output?

  Am I being attacked? 

   :!mcr!:            |  Network and security consulting/contract programming
   Michael Richardson |         Firewalls, TCP/IP and Unix administration
 Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html
 Corporate: http://www.sandelman.ottawa.on.ca/SSW/
	ON HUMILITY: To err is human, to moo bovine.





-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQB1AwUBNgEsXdiXVu0RiA21AQFbtAMAs0aB560cbGIejAVHdd4KxF5h5x+leb+y
hfkQOtEqxTosOkvPb09t1BxvCxeAlCZH/JwPf9ccKg+jlYvA37fg6GRWDXVoGcyy
nBR4PHVxgX0HSqmSAbUpMOxaktjf35s4
=wnQk
-----END PGP SIGNATURE-----