Closed stepen closed 4 years ago
The answer is 'yes'... valid packets including re-transmissions are delivered through libtins (as suspected). The network hardware/driver will discard garbled frames/acks, but re-transmissions will be passed through.... as it should come to think about it. This is what I was experiencing. case closed.
I'm running Linux on RaspberryPi4B / 4GB, OS ver 'buster', libtins v/4.3, using a AWUS036ACH antenna. It seems that the library sometimes delivers duplicate packets from sniffing. Packets that are not seen on the wire.
When I run the following simple code (very simple example-code for a WPA2 decryptor) I OCASSIONALLY see duplicates.
I have included a sample run, where I am sending 4 pings (ICMP) on a test-net (11.11.11.xx, Ch7, 2.4GhZ) from a PC-client (.101) to a RaspberryPI (.106). The sniffer runs on separate RaspberryPI. Mind you, I have to do this many times before I catch a duplicate-scenario, but it usually happens within 20 tries.
The Ping-command looks like (8 packets. 4 requests and 4 replies):
The output from the small program above, gives: (MAC addresses have been obscured a little and I've added a REQUEST/REPLY label. Packet # 173 is a duplicate delivered (wrongfully) by the decryptor.
A parallel capture on wireshark (on .101) shows the following - i.e. NO douplicates. (I've added the IP-idents and REQ/REPLY labels):
I have no idea why this happens with this simple code (maybe I'm overlooking something ?). It perhaps could be a RF (layer 2) re-transmission? Are RF re-transmissions propagated through libtins ? If anyone has any ideas, please share ...
Thanks in advance stepen