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
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
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: 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
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.
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
