+18
−0
Loading
Gitlab 现已全面支持 git over ssh 与 git over https。通过 HTTPS 访问请配置带有 read_repository / write_repository 权限的 Personal access token。通过 SSH 端口访问请使用 22 端口或 13389 端口。如果使用CAS注册了账户但不知道密码,可以自行至设置中更改;如有其他问题,请发邮件至 service@cra.moe 寻求协助。
As described at [1] some STAs (i.e. Intel 5100 Windows) can end up correctly BlockAcking incoming frames without delivering them to user space if a AMPDU subframe got lost and we don't flush the receipients reorder buffer with a BlockAckReq. This in turn results in stuck connections. According to 802.11n-2009 it is not necessary to send a BAR to flush the recepients RX reorder buffer but we still do that to be polite. However, assume the following frame exchange: AP -> STA, AMPDU (failed) AP -> STA, BAR (failed) The client in question then ends up in the same situation and won't deliver frames to userspace anymore since we weren't able to flush its reorder buffer. This is not a hypothetical situation but I was able to observe this exact behavior during a stress test between a rt2800pci AP and a Intel 5100 Windows client. In order to work around this issue just tear down the BA session as soon as a BAR failed to be TX'ed. [1] http://comments.gmane.org/gmane.linux.kernel.wireless.general/66867 Signed-off-by:Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
CRA Git | Maintained and supported by SUSTech CRA and CCSE