ath(4) sends duplicate multicast frames with AR5212 chipset
I am running the following ath(4) card in hostap mode with WPA:
ath0 at pci0 dev 12 function 0 Atheros AR5212 (IBM MiniPCI) rev 0x01: irq 9
ath0: AR5213A 5.9 phy 4.3 rf5112a 3.6, WOR01W, address 00:0e:9b:d7:36:f8
STAs can connect fine. However, multicast frames cause a lot of RX errors
at the STA side. The tkip replays counter in netstat -W keeps increasing.
This results in occasional stutter in the wireless connection.
It is small, but noticable when typing into an ssh session to the STA.
Note that I have a carp setup running in this network which creates a lot
of multicast frames. With few multicast frames the problem is probably not
noticable. (TKIP is used for multicast frames, other traffic is using CCMP.)
This only happens with ath(4).
A ral(4) card I have doesn't show this problem at all.
Modyfing the code on the STA side as follows shows the problem:
Index: ieee80211_crypto_tkip.c
===
RCS file: /cvs/src/sys/net80211/ieee80211_crypto_tkip.c,v
retrieving revision 1.19
diff -u -p -r1.19 ieee80211_crypto_tkip.c
--- ieee80211_crypto_tkip.c 5 Apr 2011 11:48:28 - 1.19
+++ ieee80211_crypto_tkip.c 1 Oct 2011 21:51:46 -
@@ -362,7 +362,10 @@ ieee80211_tkip_decrypt(struct ieee80211c
/* replayed frame, discard */
ic-ic_stats.is_tkip_replays++;
m_freem(m0);
+ printf(TKIP: replayed frame (tsc=%llu = *prsc=%llu\n, tsc,
*prsc);
return NULL;
+ } else {
+ printf(TKIP: non-replayed frame (tsc=%llu *prsc=%llu\n,
tsc, *prsc);
}
MGET(n0, M_DONTWAIT, m0-m_type);
Oct 1 19:11:40 jack /bsd: TKIP: non-replayed frame (tsc=4375 *prsc=4222)
Oct 1 19:11:40 jack /bsd: TKIP: replayed frame (tsc=4375 = *prsc=4375)
Oct 1 19:11:40 jack /bsd: TKIP: replayed frame (tsc=4375 = *prsc=4375)
Oct 1 19:11:40 jack /bsd: TKIP: replayed frame (tsc=4375 = *prsc=4375)
Oct 1 19:11:40 jack /bsd: TKIP: replayed frame (tsc=4375 = *prsc=4375)
Oct 1 19:11:40 jack /bsd: TKIP: replayed frame (tsc=4375 = *prsc=4375)
Oct 1 19:11:40 jack /bsd: TKIP: replayed frame (tsc=4375 = *prsc=4375)
Oct 1 19:11:40 jack /bsd: TKIP: replayed frame (tsc=4375 = *prsc=4375)
Oct 1 19:11:40 jack /bsd: TKIP: replayed frame (tsc=4375 = *prsc=4375)
Oct 1 19:11:40 jack /bsd: TKIP: non-replayed frame (tsc=4376 *prsc=4375)
Oct 1 19:11:40 jack /bsd: TKIP: replayed frame (tsc=4376 = *prsc=4376)
Oct 1 19:11:40 jack /bsd: TKIP: replayed frame (tsc=4376 = *prsc=4376)
Oct 1 19:11:40 jack /bsd: TKIP: replayed frame (tsc=4376 = *prsc=4376)
Oct 1 19:11:40 jack /bsd: TKIP: replayed frame (tsc=4376 = *prsc=4376)
Oct 1 19:11:40 jack /bsd: TKIP: replayed frame (tsc=4376 = *prsc=4376)
Oct 1 19:11:40 jack /bsd: TKIP: replayed frame (tsc=4376 = *prsc=4376)
Oct 1 19:11:40 jack /bsd: TKIP: replayed frame (tsc=4376 = *prsc=4376)
Oct 1 19:11:40 jack /bsd: TKIP: replayed frame (tsc=4376 = *prsc=4376)
At the AP side the net80211 stack injects the multicast frame once.
But the card ends up sending the frame multiple times.
A similar problem as been reported in the past with an AR5213 chipset
in hostap mode with WPA on OpenBSD and an STA running Linux, see
http://old.nabble.com/Wireless-host-ap-wpa-problems-td19473573.html
(the dropped-connection symptoms described there are probably a different
problem which may have been fixed since).
Comparing our AR5212 code to the FreeBSD driver I found that we're
using different values telling the card how many TX retries to do.
FreeBSD re-transmits multicast data frames only once.
See ath_tx_start() in
http://svnweb.freebsd.org/base/head/sys/dev/ath/if_ath_tx.c?revision=220098view=markup
where try0 is set to 1 in case of sending a data frame to a multicast address.
The HAL does not modify this value, see ar5212SetupTxDesc() in
http://svnweb.freebsd.org/base/head/sys/dev/ath/ath_hal/ar5212/ar5212_xmit.c?revision=225820view=markup
Our AR5212 code retries 15 times, whether or not the frame is multicast.
The tx retries value passed to the HAL is 11 and the HAL always adds 4
(not sure what's the point -- only the AR5212 HAL changes the value
passed in, the other HALs don't).
The following patch sets the amount of TX attempts for multicast frames
to 1 which fixes the problem for me. ssh to the STA stays responsive and
no replays are reported.
Is this right?
(AR5K_TUNE_HWTXTRIES isn't used anywhere else so I removed it.)
Index: ar5212.c
===
RCS file: /cvs/src/sys/dev/ic/ar5212.c,v
retrieving revision 1.51
diff -u -p -r1.51 ar5212.c
--- ar5212.c2 Jun 2009 12:39:02 - 1.51
+++ ar5212.c1 Oct 2011 21:41:47 -
@@ -1353,8 +1353,7 @@ ar5k_ar5212_setup_tx_desc(struct ath_hal
tx_desc-tx_control_1 =
AR5K_REG_SM(type, AR5K_AR5212_DESC_TX_CTL1_FRAME_TYPE);
tx_desc-tx_control_2 =
- AR5K_REG_SM(tx_tries0 + AR5K_TUNE_HWTXTRIES,
-
Re: ath(4) sends duplicate multicast frames with AR5212 chipset
On Sun, Oct 02, 2011 at 01:03:33AM +0200, Stefan Sperling wrote: Our AR5212 code retries 15 times, whether or not the frame is multicast. The tx retries value passed to the HAL is 11 and the HAL always adds 4 (not sure what's the point -- only the AR5212 HAL changes the value passed in, the other HALs don't). The following patch sets the amount of TX attempts for multicast frames to 1 which fixes the problem for me. ssh to the STA stays responsive and no replays are reported. Is this right? To clarify: Since the tx retry counter is passsed from outside the HAL, the diff affects every ath(4) chipset, not just the AR5212 (sorry, it's been a long night). I don't have other ath(4) cards to test, though.
Re: fix a seg and minor improvements to config(8)
Makes sense to me, ok.
Later we should fix the include orderning and change the warning
printfs to stderr.
Can we get another ok ?
On Wed, Sep 28, 2011 at 02:37:34AM +0100, Edd Barrett wrote:
Evening,
When using `config -e`:
* Don't print a NULL pointer if binary loaded is not a kernel.
* Don't segfault of binary loaded is not a kernel.
* Report non-existent kernel via a preliminary stat().
* Make a warning look like the rest.
OK?
Index: exec.c
===
RCS file: /cvs/src/usr.sbin/config/exec.c,v
retrieving revision 1.7
diff -u -r1.7 exec.c
--- exec.c27 Oct 2009 23:59:51 - 1.7
+++ exec.c28 Sep 2011 01:19:49 -
@@ -26,6 +26,8 @@
#include err.h
#include sys/types.h
+#include sys/stat.h
+#include fcntl.h
#include stdio.h
#ifdef AOUT_SUPPORT
@@ -109,6 +111,11 @@
void
loadkernel(char *file)
{
+ struct stat st;
+
+ if (stat(file, st) == -1)
+ err(1, cannot stat '%s', file);
+
current_exec = -1;
#ifdef AOUT_SUPPORT
Index: ukc.c
===
RCS file: /cvs/src/usr.sbin/config/ukc.c,v
retrieving revision 1.16
diff -u -r1.16 ukc.c
--- ukc.c 10 Dec 2009 22:07:19 - 1.16
+++ ukc.c 28 Sep 2011 01:19:49 -
@@ -114,10 +114,8 @@
}
}
- printf(%s, adjust((caddr_t)nl[P_VERSION].n_value));
-
if (force == 0 outfile == NULL)
- printf(warning: no output file specified\n);
+ printf(WARNING no output file specified\n);
if (nl[IA_EXTRALOC].n_type == 0 || nl[I_NEXTRALOC].n_type == 0 ||
nl[I_UEXTRALOC].n_type == 0 || nl[I_HISTLEN].n_type == 0 ||
@@ -155,6 +153,8 @@
process_history(histlen, history);
}
+ printf(%s, adjust((caddr_t)nl[P_VERSION].n_value));
+
if (config()) {
if (force == 0 outfile == NULL) {
fprintf(stderr, not forced\n);
@@ -184,7 +184,9 @@
struct winsize w;
#endif
- cd = get_cfdata(0); /* get first item */
+ if ((cd = get_cfdata(0)) == NULL) /* get first item */
+ errx(1, failed to get first cfdata);
+
while (cd-cf_attach != 0) {
maxdev = i;
totdev = i;
--
Best Regards
Edd Barrett
Adelántese al DIA DE LA MADRE con Rincón de Luz Arte
[IMAGE] Newsletter 7 - Aqo I - Octubre 2011 - noveda...@rincondeluzarte.com.ar [IMAGE]Sintoniza con la fuerza de la vida : EL CHI Todos somos capaces de desarrollar una mayor sensibilidad hacia la energma, el espmritu de carga divina que nos da vida a nosotros y a nuestros hogares. Aquello que moldea nuestras emociones, define nuestros estados de animo, sustenta nuestra fuerza y alimenta nuestro ser es una fuerza de vida intangible. Cuando nacemos, nuestro espmritu es puro y nuevo, pero a medida que crecemos y nos hacemos adultos y mayores, va adquiriendo tonalidades derivadas de nuestras experiencias en la vida. Algunos de estos colores expanden nuestros horizontes: otros, nos debilitan. nota completa [IMAGE]?Qui provoca el debilitamiento de la energma?. La acumulacisn de objetos ( fmsicos, emocionales y espirituales) es la principal culpable del deterioro de los espacios y de las personas. Los trastos nos acechan como un monstruo invisible, arrastrandose silenciosamente por nuestras casas y consumiendo su energma. Cuando por fin nos damos cuenta de su presencia, nuestras energmas estan tan dibiles que a menudo ya no nos queda motivacisn para librarnos de ellos. nota completa [IMAGE]Disuelve la mala energma en la puerta de entrada. No hay nada mas daqino para el hogar que una puerta principal agrietada o quebrada, o cuya pintura se esti levantando. Si tu puerta tiene una grieta o si las bisagras chirrman, es muy importante que la cambies o que la arregles. A veces, debido a las condiciones meteorolsgicas, las puertas de madera se expanden y raspan el suelo. Debes arreglar eso de inmediato, ya que augura accidentes para los ocupantes de la casa. Tambiin hace que la puerta quede atascada, lo que, a su vez, hace que tu vida tambiin se obstruya. nota completa [IMAGE]La energma de las plantas verdes. Las plantas son verdaderos reservorios de energma. Mediante la funcisn clorofiliana Atrapan los rayos del sol y lo convierten en alimentos para ellas mismas, y los demas almacenando grandes reservas energiticas. Las plantas en cualquier recinto cerrado no solamente embellecen y refrescan el lugar sino contribuyen poderosamente a lograr un flujo adecuado de la energma chi. Ademas, las plantas pueden ofrecer soluciones practicas para dividir espacios y crear rincones agradables. nota completa [IMAGE]?Qui son los cristales?. Podrma decirse que cristal es sinsnimo de belleza, de transparencia, de reflejos de luz. Por lo general la palabra cristal se la confunde con vidrio, o bien con una variedad mas refinada del vidrio, mas costosa o de mejor calidad. En realidad el cristal es el producto de un proceso natural, es un mineral en estado lmquido que luego de enfriarse a determinada temperatura se cristaliza y en su estructura interna las moliculas adoptan una ordenacisn perfecta. nota completa [IMAGE] [IMAGE] Productos Fuentes Feng-Shui con Luz Fuentes Feng-Shui sin Luz Fuentes Feng-Shui VeladoresSahumerios Importados de la India Sahumerios Nacionles Hornillos elictricos Artmculos Feng-Shu iPiedras Semipreciosas Roladas Dijes de piedras semipreciosas RoladasPiedras semipreciosas en bruto Llaveros de piedra semipreciosa Packs de 10 piedras semipreciosas Accesorios varios Musica Feng Shui para el alma [IMAGE] Seguinos en:Seguinos!!! [IMAGE] [IMAGE] Rincsn de Luz Artesanmas - Fabrica de fuentes de agua Feng Shui - Artesanmas Ayacucho N: 3239 entre Intendente Alvear e Intendente Ballester. San Andres - Prov. de Buenos Aires. HORARIOS: lunes a viernes de 9 A 15.30 hs TEL: (011) 4768-3054 - CEL: 153693-3067 email: i...@rincondeluzarte.com.ar - website: www.rincondeluzarte.com.ar ENVIOS A TODO EL PAIS
