Hal Goodnight wrote:
Because the laptop I'll be using is fairly low end,
I'm going to capture using windump and write the
output to a file, like so:
windump -i 2 -w dump.txt
Will that capture all packets going toward that
interface?
Assuming none get dropped due to WinDump not being able to process
packets fast enough to write all of them to the file, it should capture
all packets going toward that interface. If you have a problem with
dropped packets (WinDump should report a count of dropped packets when
you interrupt it with ^C and it stops), try increasing the capture
buffer size with the "-B" flag.
Note, BTW, that the resulting file will *NOT* be a text file - it'll be
a binary file in libpcap format.
I read somewhere that windump by default
ignores packets larger than a set limit. Is that true?
No. It *truncates* packets larger than a set limit, discarding all
bytes of the packet past that limit. The limit will either be 68 or 96
bytes, depending on whether WinDump is built with IPv6 support or not
(96 if so, 68 if not).
The limit can be changed with the "-s" flag on the command line. A
value of 0 means 65535, i.e. "capture the entire packet".
When I examined the dumped file from my own LAN in
Ethereal to interpret the data, I noticed the numbers
don't quite match up in Protocol Heirarchy Statistics.
For instance, I captured 129666 TCP packets. Of those,
126620 packets were NetBIOS. 129666 - 126620 = 3,046
packets.
Note that if a NetBIOS-over-TCP packet requires multiple TCP segments
(e.g., a long write request or read reply), only the last of those will
be counted as a NetBIOS Session Service packet. The rest will just be
TCP packets.