W dniu 25 kwietnia 2012 19:28 użytkownik Christian Lamparter <chunkeey@xxxxxxxxxxxxxx> napisał: > 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. > As I understand, some time ago we had wpa_supplicant AP (GO) mode as a two interfaces: AP + MONITOR. But now MONITOR is not used. Do you know other setup? So, maybe firmware should ACK frames with correct destination address only (if AR9170_MAC_RX_CTRL_ACK_IN_SNIFFER)? Or that is not possible because of HW limitation? BR Janusz -- 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
