Vea un poco más abajo para mis consultas, pero estaría muy interesado en escuchar lo que ve con este monitor en funcionamiento. ¿Estamos todos recibiendo tantos errores?
¿Realmente estoy teniendo un 65% de errores de UDP o simplemente malinterpretando el resultado de netstat?
Tengo un monitor que recoge los cambios en los errores netstat -s.
Aquí es un bloque típico, se muestra
protocolo: # paquetes anterior_contidad > 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
.
El. En la lista anterior se muestra la interrupción entre cada iteración, una ejecución por minuto. He estado funcionando durante algunos días y he hecho un poco de cambio de canales, enrutador, ubicación, reinicio, etc. y parece muy constante. Después del reinicio, el "descarte debido a los buffers de socket completos" estaba de vuelta antes de que yo llegara a la terminal, aunque los contadores se habían reiniciado mucho más bajo.
Mi red es de modo 5Ghz, por lo que nadie parece estar en esto, mi relación s / n es bastante buena y estoy obteniendo una buena velocidad (hasta mi límite de banda ancha de 60Mb). Hay pocas computadoras alrededor que están encendidas y mi teléfono (que he apagado sin un cambio en el patrón observado).
También tengo un MB Air aquí en la misma red que ve algunos de estos (demasiado grande, multidifusión desconocida, tamaño de datos > longitud de datos, protocolo no compatible desconocido) tan regular pero NUNCA cualquier dropped due to full socket buffers y mi tasa para ellos es bastante 20k de estas gotas caen en paquetes de 377 k tcp, aproximadamente el 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
Eso es bastante similar a lo que está en el MB Air, pero tiene OSX 10.10.5 y un chip wifi supuestamente diferente. Ambos ejecutamos Dropbox, solo tengo LittleSnitch en MBPro. No hay firewalls. Ambas máquinas 90% + inactivo casi no hay tráfico de red de nosotros. El último firmware de Virgin media Superhub: sé que esto no es bueno, pero ...
Lo que he estado tratando de descubrir es:
¿Son estos errores 'normales' / qué tan preocupado debería estar?
¿Cómo puedo saber de dónde son / causados por?
¿Dónde están sucediendo exactamente estos "buffers de socket completos" - en chip, kernel, etc, etc., y cómo interpretarlos?
¿Qué tan cerca puedo estar de ver este tipo de datos (TCPDUMP, etc.)? ¿Ya no está ahí en ese momento?)
¿Qué debo hacer a continuación y qué herramientas usar?
Simplemente he estado funcionando sin wifi, pero con Bluetooth para mi teléfono a 3G, aún obteniendo los mismos patrones (¡bastante asombrosamente!)
Mi script mon es (aunque me gustaría mejorarlo):
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
Mejoras:
ip: 23000 (+23) 6.7% de paquetes perdidos
Además, la línea netstat -s después del indicador de protocolo (ip: etc) suele ser útil, pero no en todos los casos, para escalar el volumen de tráfico; mira kctl: sección