Darren Reed wrote:
On 24/08/09 09:46 PM, Dan Mick wrote:
Darren Reed wrote:
On 24/08/09 07:39 PM, Dan Mick wrote:
Snoop issues a pile of warnings when run on an LSO-enabled NIC:
(warning) packet length greater than MTU in buffer offset 7384:
length=3000
As I understand it, these are hard to avoid. It is, however, not
hard to make snoop not whinge about them.
Is this behavior useful enough that it should be kept, perhaps under
-V or -v, or is nuking it acceptable?
(and, yes, snoop's unmaintainable, etc., etc., but we're talking
about a small relief fix)
A proper fix for this would involve snoop querying the device
driver, before it opens it for sniffing packets and finding out
what capabilities it has enabled. It should also receive metadata
with the packet from the device about whether or not any given
packet is marked up for such a capability and only then ignore
problems such as you're describing.
Otherwise there is no way to distinguish a well formed packet
from a badly formed one.
Yes. I guess I'm asking if that warning is useful enough to be
warranted, even in non-verbose mode, when it's clear that many of our
NICs will cause it to be issued willy-nilly right now, polluting the
actual desired output.
I agree that a more-proper fix would be better, but I'm told that
wireshark is imminent, and so "perfect is the enemy of the good" may
apply.
wireshark is not going to magically make the problem go away,
Didn't suspect that it would, but it probably means that maintenance of snoop
goes to zero.
nor will wireshark using bpf be able to make it go away. A similar
problem is seen with tcpdump on BSD boxes that make use of hardware
checksum and there too they have the same problem as here: it isn't
possible to know if the captured packet for transmit is intended to
have its checksums calculated by the hardware.
Darren
_______________________________________________
networking-discuss mailing list
[email protected]
