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=220098&view=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=225820&view=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(t
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 > #include > +#include > +#include > #include > > #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
Re: terminal emulators using /usr/local/share/terminfo and a bug in perl's Term::Cap
This seems fine to me, but I'm not a perl guru. Have you talked to upstream? Cheers On Thu, Sep 29, 2011 at 10:49:36AM +0200, David Coppa wrote: > Hi, > > The patch to ncurses nicm@ commited some days ago, exposes a bug > in perl's cpan/Term-Cap/Cap.pm. So, when you use rxvt-unicode on > a recent -current, you will hit this bug with pkg_* tools: > > # pkg_delete -v xclip > failed termcap lookup on rxvt-unicode-256color at > /usr/libdata/perl5/OpenBSD/ProgressMeter/Term.pm line 125 > > If you use a terminal emulator that has a terminfo entry but not > a termcap one (just like x11/rxvt-unicode or x11/st), you should > fall back to the case where perl uses infocmp to fake up a > termcap entry from terminfo, but this never happens because the > logic is flawed. > > Here's a diff: > > Index: cpan/Term-Cap/Cap.pm > === > RCS file: /cvs/src/gnu/usr.bin/perl/cpan/Term-Cap/Cap.pm,v > retrieving revision 1.1.1.1 > diff -u -p -r1.1.1.1 Cap.pm > --- cpan/Term-Cap/Cap.pm 24 Sep 2010 14:49:05 - 1.1.1.1 > +++ cpan/Term-Cap/Cap.pm 29 Sep 2011 08:14:46 - > @@ -273,7 +273,7 @@ sub Tgetent > > my @termcap_path = termcap_path(); > > -unless ( @termcap_path || $entry ) > +if ( !@termcap_path || !$entry ) > { > > # last resort--fake up a termcap from terminfo > > > --- > cheers, > David
Re: fix a seg and minor improvements to config(8)
Hi All but the stat bit looks fine. How do you reproduce the problems? It seems to fail just fine without it. $ config -f /x config: cannot read /x: No such file or directory Also maybe use access(2) instead? 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 > #include > +#include > +#include > #include > > #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