Subject: Re: problems with outgoing packets, no mbufs
To: None <email@example.com>
From: Michael C. Richardson <firstname.lastname@example.org>
Date: 09/17/1998 11:36:02
-----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
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.
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...
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
ON HUMILITY: To err is human, to moo bovine.
-----BEGIN PGP SIGNATURE-----
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
-----END PGP SIGNATURE-----