Re: *** warning: ethereal does not capture all packets that go onto the wire ?! ***
Ethereal added to my list of junk programs.
"Jay C. James" <firstname.lastname@example.org> wrote in message
> "Vernon Schryver" <email@example.com> wrote in message
>> In article <firstname.lastname@example.org>,
>> Rick Jones <email@example.com> wrote:
>> >> So I gather from the loose consensus on this topic, that regardless
>> >> of the application, packets will be dropped, and the count is not
>> >> all that accurate.
>> >I think that would be the best way to operate until one had
>> >platform-specific knowledge to the contrary.[/color]
>> Without very strong statements about the hardware, one must assume
>> that packets will be lost and not counted as lost. It may be reasonable
>> to hope that the MAC hardware counts packets dropped because it was
>> not provided enough buffers soon enough, but what about packets missed
>> because the MAC hardware got behind for some reason? Unless you really
>> know how the MAC hardware works and so really know there are no cases
>> where it can get too busy chatting with the host, chasing buffer
>> pointers, dealing with FDDI beaconing, or whatever, you must assume
>> the lost packet count is inaccurate.
>> Then there are the losses between the sender and your snooping MAC.
>> Besides buffers in switches/routers/bridges/whatever that can be overrun
>> or suffer bit rot, there is bit rot on the wire that can clobber whatever
>> indicates the start of a packet on whatever wire, fiber, or ether you're
>> trying to monitor. You might hope that your MAC could count many of
>> those, but on most media it can't count all of them. Consider bit rot
>> that merges two or more packets into what looks like one broken packet.
>> Any notion of ethereal, tcpdump, or any packet snooper capturing all
>> packets except those that it counts as not captured is as bogus as the
>> notion of any other perfectly precise measurement of the real world.
>> Every real measurement has error bounds. Every tcpdump, ethereal, or
>> other packet monitor will lose some packets that it fails to count as
>> lost. The only questions are how often, which packets are most likely
>> to be lost, and whether they are relevant to the reason you have for
>> snooping on the wire.
>> >> So what we have here is a failure to communicate.
>> Are you sure? This is all obvious except perhaps to the old troll that
>> re-re-re-...restarted this thread, and it doesn't care about mere facts
>> in this newsgroup or the others it infests except whether it gets a
>> response. Why can't people fix their computerized killfiles if they
>> lack willpower? If they would, it would go elsewhere, and those of us
>> who use killfiles wouldn't see the leakage and have our willpower[/color]
>> Vernon Schryver [email]firstname.lastname@example.org[/email][/color]
> Vernon, apologies.
> Killfile updated.