On Wednesday, April 25, 2012 07:28:18 AM Janusz Dziedzic wrote: > W dniu 23 kwietnia 2012 19:45 użytkownik Christian Lamparter > <chunkeey@xxxxxxxxxxxxxx> napisał: > >> This is what I can see on STA1: > >> # iperf -c 192.168.254.1 -t 100 -i 5 > >> [ 3] 10.0-15.0 sec 20.4 MBytes 34.2 Mbits/sec > >> > >> =====> here I setup carl monitor on second PC, like this: > >> =====> iw dev wlan0 set type monitor > >> =====> iw dev wlan0 set freq 2437 > >> =====> ifconfig wlan0 up > >> > >> [ 3] 40.0-45.0 sec 2.38 MBytes 3.98 Mbits/sec > > Well, there's the "AR9170_MAC_RX_CTRL_ACK_IN_SNIFFER = bit (30)" > > in "AR9170_MAC_REG_RX_CONTROL = (0x1c3c40)". > I disabled this in code. > > - rx_ctrl |= AR9170_MAC_RX_CTRL_ACK_IN_SNIFFER; > +// rx_ctrl |= AR9170_MAC_RX_CTRL_ACK_IN_SNIFFER; > > After that I don't see any TP drop and can see all packets in > wireshark (as expected). > > Why carl try to ACK rx packets in monitor mode? > Is that a correct behaviour? Well, it depends. You see without the BIT set, the hardware won't sent any ACKs (Not even those which are directed at this interface - which of course is also bad, or even worse?) and with the BIT set (and if the HW is in Sniffer Mode) then the hardware acks every frames, even if they are for a different stations. So your fix might break someone else's setup. Regards, Chr -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
