On Dec 15, 2011, at 2:39 PM, Rick Jones wrote: >> This may be of help. >> http://www.tcptrace.org/faq_ans.html#FAQ%2021 > > Given the behaviour seems to be (at least for the foreseeable future) a > "feature" is there someplace in tcptrace/tcpdump to mention this? The > tcptrace FAQ seems to have stopped growing sometime in 2003 - I could I > suppose mention this behaviour to the Debian maintainer for tcptrace, but is > there a writeup to be enhanced for tcpdump?
The item Vijay Subramanian points to appears to be about capturing on a network segment where a host is sending to another host and either doesn't realize that the receiving host is on the same network segment or chooses, for some reason, to send packets to that host through a router on the same network segment rather than directly to that host. As it says, that's probably a network misconfiguration: > ... Most likely, it means that those packets are > crossing > the local network twice, as in: > > Router Sender Receiver > | | | > ========================================================== > pkt1: ^---------------------< > pkt2: >-----------------------------------------------^ > > once from the sender to a router (or hub), and then again from the > router to > the receiver. Tcptrace flags the situation because otherwise those > packets would > be seen as retransmissions when they really aren't. If you're seeing a > lot of > these (well, probably any at all), then there's a bad setup on your > network. i.e. the problem is that Sender doesn't realize that it should send packets directly to Receiver (assuming the line of equal signs is a network segment), would usually show up only in a situation such as that, and could probably be fixed by giving Sender a clue. The issue most other messages are discussing, as described by Eric Dumazet's first message (which was the second one delivered to my mailbox), appears to be a quirk of the Linux networking stack that causes packets to be sent to taps before being sent to the network driver, "rejected" by the network driver with a "transmitter busy" indication, requeued, and then later sent to the driver again *and* sent again to the taps, so it's handed to the driver only once but sent to the taps multiple times. That one won't be fixed by a network reconfiguration unless that change means that the drivers don't end up "rejecting" the packets. Both of those scenarios might be worth discussing in one or more FAQs; at this point I wish there were a "network packet capture FAQ" to which various programs that capture packets, and their documentation/websites, could point, so that this doesn't have to be discussed in the tcptrace FAQ and the tcpdump FAQ and the Wireshark FAQ and....- This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
