Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

Sorry Guest, you are banned from posting and sending personal messages on this forum.

This ban is not set to expire.

[dingrite]

Platform: Old netbook running latest Kali 32bit live image.

I did read the documentation but it doesn't seem to have helped any.
It actually baffles me, sometimes packet loss is under 10%, sometimes its 50%! And it seems to be random.
I actually started using 2 cards, one is AWUS036NEH and the other is some sort of an old TPLINK I had lying around that is much weaker than the alpha and shares the same chipset (rt3070). Both are N cards.

TPLINK AP PWR is about -65 to -70
AWUS036NEH AP PWR is -55 to -60

The network is my WPA2 home network, it could be 40mhz enabled, would that matter?
Router is a NETGEAR in the basement, about 4-5 meters below now that I think about it, too close?
Client is my Android G3.

I observed that the TPLINK has less packet loss than the Alfa when I am close to the installation, the opposite is true when I'm on the other side of the house, due to convenience I didn't confirm that too much tbh. I just remember that w/e I do I get packet loss on both cards.


To determine packet loss I download a large file and then measure pcap size -> This probably has a nasty error margin but for now I don't care. I'm getting a pcap file smaller than the file downloaded so I know for sure something is lost.
I'm also assuming that distance to the client doesn't really matter in this instance, since I don't think airodump cares about acknowledgment. Am I wrong??? Most of my tests were with the client close to the installation since I established earlier distance didn't help any.

I have tried using iwconfig wlanXmon rate 1MB, sometimes it has no effect, sometimes it makes sure that the Alfa card captures virtually no data packets, though it seems to capture beacons just fine. The TPLINK captures more beacons than the Alfa as well.

iwconfig sens is not supported 


So now I decided to say fuck it, especially if none of you can help me here, I will use multiple cards for the same bssid in different orientations in the hope to minimize that packet loss.

So what would be the most efficient/correct way to merge pcap files that complement each other?

I was thinking of using mergecap and then editcap to remove the dupes. But I'm worried about those dupes. Because no matter which D value I use the dupe count keeps changing, though I did observe that the higher D is, the fewer additional packets are labeled as dupes. I'm worried that it may be considering 'legitimate dupes' as actual dupes. Would it be a problem if it does?
Should I use airedecap on the merged pcap first and sort out the dupes after?

My goal in merging them is so that one fills for the packets the other missed, what D value should I use for that?

Or maybe there is a better method altogether? wouldn't it be true that no matter which card the packets came to, wouldn't they have static labels of some sort? After all, RXQ somehow determines the packet loss ratio, some sort of counter? Can I use that somehow to merge with no dupes?

[misterx]

For checking interference, use a spectrum analyzer.

iwconfig is deprecated, use iw.

In order to measure packet loss, check the sequence numbers (in the frames; note that device has its own counter) and retransmit packets.

Use mergepcap in order to merge pcap files.

[dingrite]

In order to measure packet loss, check the sequence numbers (in the frames; note that device has its own counter) and retransmit packets.

Use mergepcap in order to merge pcap files.

That's a very high level way of looking at it. What about the low level details?
mergecap doesn't care about duplicate packets, should I just ignore the dupes? If not, how do I filter them out? editcap produces different results for different D values... Which makes me think that some dupes ought to be there?

What tool could I use to "check the sequence numbers"?

[misterx]

Check packets with Wireshark, then expand fields and find 'Sequence number'. It is a sequential number that goes up to 4095.

You might have to write your own tool.

[dingrite]

Check packets with Wireshark, then expand fields and find 'Sequence number'. It is a sequential number that goes up to 4095.

You might have to write your own tool.

editcap doesn't consider that sequence number when it looks for dupes?
Would -D 4095 work?

[misterx]

I have no idea what that '-D 4095' refer to. Also, if that wasn't obvious, when it reaches that value, it resets to 0.

I've never used editcap.

[dingrite]

I have no idea what that '-D 4095' refer to. Also, if that wasn't obvious, when it reaches that value, it resets to 0.

I've never used editcap.

editcap has a dupe filtering options. -D stands for the window in which to eliminate dupes in # of packets.

The problem I noticed is that if you use D values like 2,3,4,5,6,... you get a different count of dupes for each one. mergecap merges them all based on time right? so it begs the question of why even in the case of -D 15 and -D 20 it finds some 1% more dupes.

Is it normal for clients and APs to produce a lot of duplicate packets? Is their removal safe?

[misterx]

There should NEVER be any duplicate coming from a SINGLE card. If you are talking about retransmit, that's a different thing: packets not acked by receiver are retransmitted until the receiver ack them (unless there is a setting that says otherwise in the transmitting device.

[dingrite]

There should NEVER be any duplicate coming from a SINGLE card. If you are talking about retransmit, that's a different thing: packets not acked by receiver are retransmitted until the receiver ack them (unless there is a setting that says otherwise in the transmitting device.

editcap compares the md5 checksum of every packet to D=5 -1 previous packets when eliminating dupes.

Are you saying that when used on a pcap from a single card listening to encrypted traffic there should never be any dupes?

[misterx]

That's right.