morphyno wrote:
> sudo /usr/sbin/tcpdump -s 0 -nei eth9 -w /mnt/tmpfs/eth9_rx.pcap -B
> 200 From "free -k", I see about 2G allocated on Ubuntu
> Before:
> free -k total used free shared buffers cached Mem: 65928188 1337008
> 64591180 1164 26556 68596 -/+ buffers/cache: 1
I find myself looking at the likes of ethtool -S output on a Linux
system, for a multi-queue NIC, and seeing drops reported for a specific
receive queue. I thus find myself wishing I could know which
packets/flows were arriving on that receive queue so I could,
presumably, figure-out who the "
Some of the other cases where a bug my changes introduced into print-udp.c; I
checked in a fix for that.
The one remaining check failure is with the RADIUS-RFC5176.pcap capture - and,
at least as I read RFC 768, the packets in that capture are, in fact, malformed:
> Length is the length in oc
On Oct 20, 2014, at 6:43 AM, Michael Richardson wrote:
> print-x test case:
>
> 16c16
> < IP 127.0.0.1.55920 > 127.0.0.1.80: Flags [P.], seq 1:203, ack 1, win 8192,
> options [nop,nop,TS val 1306300951 ecr 1306300950], length 202
> ---
>> IP 127.0.0.1.55920 > 127.0.0.1.80: Flags [P.], seq 1:20
print-x test case:
16c16
< IP 127.0.0.1.55920 > 127.0.0.1.80: Flags [P.], seq 1:203, ack 1, win 8192,
options [nop,nop,TS val 1306300951 ecr 1306300950], length 202
---
> IP 127.0.0.1.55920 > 127.0.0.1.80: Flags [P.], seq 1:203, ack 1, win 8192,
> options [nop,nop,TS val 1306300951 ecr 13063009
