1

See a bit further down for my queries, but I'd be very interested to hear what you see with this monitor running. Are we all getting this many errors?
Am I really having 65% UDP errors or just misunderstanding netstat output?

I have a monitor picking up changes in netstat -s errors.
Here is a typical block, it shows
protocol:#packets previous_count > now_count error_message:

Mon 30 May 2016 12:04:32 BST
udp:81339        59930 > 59949 dropped due to full socket buffers
ip:843492        36814 > 36816 with data size > data length
ip:843492      9995 > 9996 packets for unknown/unsupported protocol
ip:843492        37390 > 37399 packets received for unknown multicast group
.
tcp:555120         1082 > 1085 times recovered from bad retransmission using DSACK
udp:81359        59949 > 59964 dropped due to full socket buffers
ip:843710        36816 > 36846 with data size > data length
ip:843710      9996 > 9998 packets for unknown/unsupported protocol
ip:843710        37399 > 37406 packets received for unknown multicast group
ip6:24635      12993 > 12999 message too big failures
.
tcp:555389         1085 > 1087 times recovered from bad retransmission using DSACK
udp:81458        59964 > 60059 dropped due to full socket buffers
ip:844048        36846 > 36854 with data size > data length
ip:844048        37406 > 37412 packets received for unknown multicast group
ip6:24647      12999 > 13070 message too big failures
.
tcp:555490       951 > 952 connections dropped by rexmit timeout
tcp:555490         1087 > 1088 times recovered from bad retransmission using DSACK
udp:81473        60059 > 60069 dropped due to full socket buffers
ip:844147        36854 > 36872 with data size > data length
ip:844147      9998 > 10002 packets for unknown/unsupported protocol
ip:844147        37412 > 37420 packets received for unknown multicast group
ip6:24651      13070 > 13072 message too big failures
.

The . in the list above shows the break between each iteration, one run per minute. I have has this running for some days and done a fair bit of switching channels, router, location, reboot etc and it seems very constant. After the reboot the "dropped due to full socket buffers" was back before I even got into terminal although counters had restarted much lower.

My network is 5Ghz mode, so no one around seems to be on this, my s/n ratio is quite good and I am getting good speed (unto my 60Mb broadband limit). There are few computers around that are on, and my phone (which I have switched off with no observed change to pattern).
I also have a MB Air here on the same network which sees some of these (too big, unknown multicast, data size > data length, unknown unsupported protocol) just as regular but NEVER any dropped due to full socket buffers and my rate for them is quite high 20k of these drops in 377k tcp packets, about 6%.

On my MBPro 11,5:  netstat -m
620/1327 mbufs in use:
    339 mbufs allocated to data
    13 mbufs allocated to socket names and addresses
    268 mbufs allocated to packet tags
    707 mbufs allocated to caches
302/682 mbuf 2KB clusters in use
0/637 mbuf 4KB clusters in use
0/12 mbuf 16KB clusters in use
4566 KB allocated to network (16.7% in use)
0 KB returned to the system
0 requests for memory denied
0 requests for memory delayed
0 calls to drain routines

That is pretty similar to what is on the MB Air, but that has OSX 10.10.5 and presumably different wifi chip. We both run Dropbox, I have LittleSnitch on the MBPro only. No firewalls. Both machines 90%+ idle almost no network traffic from us. Virgin media Superhub latest firmware - I know this is not great but...

What I have been trying to find out is:
Are these 'normal' errors/how worried should I be?
How can I find out where they are from/caused by?
Where exactly are these "full socket buffers" happening - in chip, kernel, etc etc and how to interpret this?

How close can I get to seeing this sort of data (TCPDUMP etc or is it already not there by that time?)
What should I do next, and what tools to use?

Have just been running with no wifi but Bluetooth to my phone to 3G, still getting much the same patterns (rather amazingly!)

My mon script is (though I'd like to improve it):

echo showing changes in detected network issues
while [ 0 ]
do
cp IPEnow IPElast
netstat -s | awk '/error|length|bad|overflow|failure|dropped|loss|unknown|detect/ { if ($1+0 > 0) { $1 = pre " "  $1; print} }; {if (NF==1) { pre = $1 ;getline ;  print pre $1}}' >IPEnow
#get changes, just list new changed values
diff --suppress-common-lines  -y IPElast IPEnow | awk '{if (NF==3) {pre = $3} else {was = $2; for (i=1;$i!="|";i++) {$i = ""};  $i=was;i++;$i=">";print pre $0}}'
echo .
sleep 60
done

Improvements:
ip: 23000 (+23) 6.7% dropped packets
Also netstat -s line after protocol flag (ip: etc) is usually but not in all cases useful to scale the volume of traffic; look at kctl: section

  • What's the monitoring app/script? Please add a link (if possible)! – klanomath May 28 '16 at 14:56
  • Check the MTU of everything on your network. They should all be the same to avoid weird problems. – Jamie Cox May 30 '16 at 7:39
  • All 1500 and I have no suspicion of error on that as I get 60Mb consistent data through which is 100% of the fibre offering I have at present. Just sometimes I lock out but very irregular that, not for 5 days now, but I know this was associated with MTU in older OSX. Also the MBP Air is fine and same 1500 MTU there. – colin May 30 '16 at 17:55

You must log in to answer this question.

Browse other questions tagged .