On Sun, Oct 01, 2000 at 08:57:02PM +0900, Richard Sharpe wrote:
> In carefully going through and fixing packet_bxxp.c so that it works as I
> expect it to, I am again reminded that capturing on the loopback interface
> under Linux is a bad thing.
>
> I am motivated to fix packet-tcp.c so that it can ignore duplicates segments.
> This will involve keeping state on a per segment basis and an association.
>
> However, I suspect that we should make this behaviour configurable with a
> default of on.
If you're on a real network, rather than a loopback interface, the
desired behavior is probably not to just completely ignore duplicate
segments, but instead to have TCP put into the protocol tree an
indication that they're duplicate segments, and not call the next
dissector on their payload, so that the user can see an indication that
a segment was probably lost and a retransmission was required.
Loopback-on-Linux captures are probably less common than captures on
regular interfaces, so the default should probably be to put in a
"duplicate segment" indication, not to completely ignore them.
However, putting a hack for loopback-on-Linux into TCP means that you
*still* get duplicate packets for UDP-based stuff going over the
loopback interface, so you'd really want to ignore duplicate IP
transmissions (i.e., two occurrences of the same packet, with the same
Identification, Length, and Fragment Offset values in the header).
And even that wouldn't keep you from seeing duplicate packets in the
packet list pane; given that they're going to show up in the packet list
anyway, you might as well *always* put the "duplicate segment"
indication (if you do it in TCP) or "duplicate IP datagram" indication
(if you do it in IP) into the protocol tree - and, probably, also put an
indication in the "Info" column that it's a duplicate.
The only way to fix it to *completely* avoid that problem is in libpcap,
which, in Linux (at least on 2.2 and later), is where the code can see
whether the packet was received or transmitted by the machine on which
the capture is being done and, if it's being transmitted, discard it if
the capture is being done on the loopback interface. (That information
isn't present in the capture file, so you can't fix it in Wiretap or in
the savefile-reading code in libpcap.)
That's in the "Known bugs" list in the comment at the top of
"pcap-linux.c" in the libpcap CVS tree:
/*
* Known bugs:
* - setting promiscuous on loopback gives every packet twice
*/
That suggests, by the way, that you might try turning promiscuous mode
off, to see if that helps (if it doesn't help, that comment should
probably be changed to say "capturing" rather than "settingn
promiscuous"); that doesn't help people with released versions of
Ethereal, as the stuff I put in to let you turn promiscuous mode off is
only in CVS, but putting in duplicate-segment or duplicate-IP-datagram
detection wouldn't help them, either, for the same reason.
I think I may look into fixing the bug in question as time permits
(hopefully it's simple and only a small amount of time is required).
