On Mon, Sep 11, 2000 at 12:51:56AM +0900, Richard Sharpe wrote:
> Damn captures on the loopback driver, which gives me two copies of each
> packet, causes real problems with my latest BXXP code ...
Well, one way to fix this would be to download and install software from
one of the following sites:
http://www.freebsd.org/
http://www.netbsd.org/
http://www.openbsd.org/
:-)
Another might be to apply the following patch (at least with 2.2[.x]
kernels) to "net/core/dev.c":
*** dev.c.dist Wed May 3 17:16:53 2000
--- dev.c Sun Sep 10 23:17:49 2000
***************
*** 519,527 ****
{
/* Never send packets back to the socket
* they originated from - MvS (miquels@xxxxxxxxxxxxxx)
*/
if ((ptype->dev == dev || !ptype->dev) &&
! ((struct sock *)ptype->data != skb->sk))
{
struct sk_buff *skb2;
if ((skb2 = skb_clone(skb, GFP_ATOMIC)) == NULL)
--- 519,531 ----
{
/* Never send packets back to the socket
* they originated from - MvS (miquels@xxxxxxxxxxxxxx)
+ *
+ * Also, don't send them back if this is a loopback device,
+ * as they'll be seen again when received.
*/
if ((ptype->dev == dev || !ptype->dev) &&
! ((struct sock *)ptype->data != skb->sk) &&
! dev->type != ARPHRD_LOOPBACK)
{
struct sk_buff *skb2;
if ((skb2 = skb_clone(skb, GFP_ATOMIC)) == NULL)
although I've not actually tested that to see if it keeps packets sent
to the loopback device from being handed to network taps when sent *and*
when received (which I suspect is the source of the problem).
There's a comment in the top-of-CVS-tree "pcap-linux.c" at tcpdump.org
that says
* Known bugs:
* - setting promiscuous on loopback gives every packet twice
but I'm not certain that promiscuous mode has anything to do with it, as
I see nothing obvious in the code path that would check for it (I'll
have to try tcpdump, with promiscuous mode off, on a 2.2[.x]-kernel
machine at work; I just have vanilla Debian 2.1, with a 2.0[.x] kernel,
on the Linux partition on my home machine).
In a capture program such as Ethereal, one could, I guess, check for
duplicate IP packet retransmissions (same source and destination IP
addresses, same IP ID, same length, same fragment offset) and just
display them as duplicates rather than handing them to the next
protocol; this might be useful in any case (when we do fragment
reassembly we'll have to keep track of that information for IP
fragments, at least), and would, at least, make the display of Linux
loopback traffic less confusing (you'd only see bogus duplicate IP
packets, not other bogosity).