Hey, I'm testing the following setup with the svn backfire (18/04/2011 rev 26713). I have an access point (192.168.1.253) configured with hostapd using the following configuration:
interface=wlan0 bridge=br0 driver=nl80211 auth_algs=3 debug=0 logger_syslog=-1 logger_syslog_level=2 logger_stdout=-1 logger_stdout_level=2 dump_file=/tmp/hostapd.dump beacon_int=100 max_num_sta=255 hw_mode=a ieee80211n=1 wmm_enabled=1 ieee80211n=1 wmm_enabled=1 ht_capab=[TX-STBC][RX-STBC12][DELAYED-BA][MAX-AMSDU-7935] channel=48 rts_threshold=2347 fragm_threshold=2346 ssid=ntest ctrl_interface=/var/run/hostapd ctrl_interface_group=0 ignore_broadcast_ssid=0 With another device (192.168.1.100) I connect to this access point. Both devices are ubiquitity routerstation pros with a R52n-M wireless card (AR9220). Once connected it will negotiate over the block acks which ends successfully. Yet when I preform a ping from the client to the access point, the request is sent only once but the reply is sent multiple times. All of the replies are acked with normal acks yet the access point appears to ignore the normal acks and sends out a block ack request. Is this the normal behaviour or should this be reported as a bug? The full trace can be found at https://euterpe.cmi.ua.ac.be/~javonts/tmp/duplicateDump.pcap . Note that a bridge is used with the mac address 00:00:00:00:00:01, yet this doesn't influence the results. Related to the block ack request: if ((info->flags & IEEE80211_TX_STAT_AMPDU_NO_BACK) && (ieee80211_is_data_qos(fc))) { u16 tid, ssn; u8 *qc; qc = ieee80211_get_qos_ctl(hdr); tid = qc[0] & 0xf; ssn = ((le16_to_cpu(hdr->seq_ctrl) + 0x10) & IEEE80211_SCTL_SEQ); ieee80211_send_bar(sta->sdata, hdr->addr1, tid, ssn); } This is the part where a BAR (Block Ack Request) is sent. Why is the ssn added with 1? Should the request not include the current ssn? In case of one packet, the response is a all zero ack bitmap because a block ack of a ssn which is not even been used, is requested. Regards Jeroen _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
