[Winpcap-users] winpcap sends packets double (or libpcap receives 'm double)

[Tiemen Schut]

Hi there mailinglist,

I'm currently working on some highspeed data acquisition stuff, and for an
experimental setup I am using a windows XP pc (with winpcap) as sender of
packets, and a slackware linux pc (with libpcap) as receiver.

The sender is creating packets of 1512 bytes long, in which the last 4 bytes
represent a counter. I put a 1000 of these packets in a pcap_queue thingie,
and send them out. After that I destroy the queue, and if a certain amount
of time has passed (I want to create an average of 43,75 MB/s) I refill the
queue and resend it (continuously incrementing the numbers of course).

So far so well, ksysguard tells me I receive about 43,75 MB/s of data, so
I'm happy. Now, on the receiving side, I sniff all the traffic using
libpcap's pcap_loop, and in my callback function I check the counters in the
packets. So, every next counter should be the last counter + 1.

At first I lost a huge amount of packets (> 25 %), but running the server
app with nice -n-20 (yes, the receiving pc is quite slow) this decreased
dramatically. I lose like 0.00x % of packets, so I'm quite happy about that.

Now, the problem. At first I didn't even think this could happen, but it
does. I receive packets twice! :o Not all packets, just like a few in say
100.000 or so. The question is, has anyone ever seen this before? Is it
likely a winpcap problem (sender, so the packets really are send twice) or a
libpcap problem (callback function called twice for same packet?) or even a
kernel issue?

I truly don't have a clue, would appreciate any comments :)

[Bryan Kadzban]

Post by Tiemen Schut
Now, the problem. At first I didn't even think this could happen, but
it does. I receive packets twice!

I am pretty sure Ethernet is not reliable -- i.e., your packets can be
either dropped *or duplicated* while on the wire or being processed in
the NIC. This would have nothing to do with WinPcap or libpcap or the
network driver on either end; it'd be a property of the medium.

I know IP and UDP are not reliable; both of them can drop or duplicate
packets. I believe 802.11 is *supposed* to be reliable, but since IP
and UDP don't care, and TCP explicitly corrects for dropped or doubled
packets, I doubt anyone relies on that. I'm not sure about 802.3 though.

In any case, it seems that requiring a protocol to be reliable that
explicitly claims not to be (i.e., IP or UDP) is a pretty bad idea.
Perhaps it would be better to use TCP to send and receive your data,
instead of winpcap and libpcap? Not sure on your requirements, though.

[Tiemen Schut]

Hmm, it could be that yes.

My application doesn't require a 100% reliability, and I can imagine packets
getting lost on the physical network layer every once in a while. On the
other hand, since the use of nice -n-20 dramatically decreased the packet
loss this probably had to do with the CPU not giving my app enough time, ie
a buffer overrun, probably on kernel level. Perhaps pcap_setbuff could have
helped (or still can) here.

What I can't quite imagine is packets being magically duplicated on the
physical layer. Note that I'm not talking high level packet, just plain raw
ethernet (mac addresses & data). What possible cause is there for a packet
to get duplicated on the wire? I believe none.

So, I didn't just post my problem here, I tried some stuff myself ;) And it
looks like the problem is solved by disabling as many protocols as possible
on the network interface. (In windows, right click the network adapter,
select properties, and turn off the checkboxes). My guess is that the TCP/IP
stack in windows does some funny things, maybe send keepalives or so?

My receiving app isn't prepared to receive any traffic but the one I send
myself, so I guess this is the answer.

Thanks anyway. Oh, and I know TCP uses error correction and stuff, but as
the final product I'm developing will receive it's data from specialistic
hardware, I can't quite ask these guys to build there own TCP/IP stack in an
FPGA ;) (let alone have them create a hardware buffer to buffer enough data
at a 350 mbit/s rate to enable retransmits ;))

Post by Bryan Kadzban

Post by Tiemen Schut
Now, the problem. At first I didn't even think this could happen, but
it does. I receive packets twice!

I am pretty sure Ethernet is not reliable -- i.e., your packets can be
either dropped *or duplicated* while on the wire or being processed in
the NIC. This would have nothing to do with WinPcap or libpcap or the
network driver on either end; it'd be a property of the medium.
I know IP and UDP are not reliable; both of them can drop or duplicate
packets. I believe 802.11 is *supposed* to be reliable, but since IP
and UDP don't care, and TCP explicitly corrects for dropped or doubled
packets, I doubt anyone relies on that. I'm not sure about 802.3 though.
In any case, it seems that requiring a protocol to be reliable that
explicitly claims not to be (i.e., IP or UDP) is a pretty bad idea.
Perhaps it would be better to use TCP to send and receive your data,
instead of winpcap and libpcap? Not sure on your requirements, though.
_______________________________________________
Winpcap-users mailing list
https://www.winpcap.org/mailman/listinfo/winpcap-users

[Bryan Kadzban]

Post by Tiemen Schut
What I can't quite imagine is packets being magically duplicated on the
physical layer. Note that I'm not talking high level packet, just plain raw
ethernet (mac addresses & data). What possible cause is there for a packet
to get duplicated on the wire? I believe none.

The fact that there is no cause does not imply that the 802.3 standard
requires implementations to be reliable, though. ;-) And if the
standard doesn't require cards to be reliable, you really can't rely
on never getting duplicates.

But there are still reasons for packets to be duplicated -- non-switched
networks see collisions fairly regularly, which cause the sending device
to back off and retransmit. If the collision (for some reason) did not
really affect the receiver, then the receiver will see the same frame at
least twice. I'm not sure if this is possible in practice (especially
on a switched network), but in theory it is.

Post by Tiemen Schut
Thanks anyway. Oh, and I know TCP uses error correction and stuff, but as
the final product I'm developing will receive it's data from specialistic
hardware,

Oh, never mind then. Sounds like you'll have to discard duplicates in
your user-mode code then. If the packets have unique identifiers, this
shouldn't be too difficult.