Re: OpenOSPF6d does not send LSAs for passive interfaces
On Mon, Jan 3, 2011 at 5:27 PM, Jan Johansson janj+open...@wenf.org wrote:
If an CARP interface is in BACKUP state the route is still
advertised which leads to assymetric routing.
Ok, the following should fix this. It's a little more involved; here's
what's new:
- Avoid sending LSAs if the link state is down (to avoid
double-advertising CARP interfaces). OSPFd does this a little more
elegantly using metrics[1], but I wasn't able to get that to work,
perhaps I'm not understanding the protocol. Suggestions appreciated.
- Don't send LSAs if the interface is down (ifconfig carp1 down),
because that's silly
- Make the OSPF engine update the RDE about interface changes even
when the interface state does not change, so the RDE is informed when
a passive interface's link state changes (so we can then make a
decision using that data)
- Resend intra-area LSAs in the RDE when interface flags change, not
just interface state (avoids a race condition where LSAs get sent
before the OSPF engine updates the RDE with new linkstate data)
Cheers,
Patrick
[1] See ospfe.c:851 through ospfe.c:883 in ospfd.
--
http://www.labyrinthdata.net.au - WA Backup, Web and VPS Hosting
http://patrick.ld.net.au/ospf6d-fix-passive-interfaces-mk2.patch
Index: interface.c
===
RCS file: /cvs/src/usr.sbin/ospf6d/interface.c,v
retrieving revision 1.15
diff -u -p -r1.15 interface.c
--- interface.c 20 Sep 2009 20:45:06 - 1.15
+++ interface.c 4 Jan 2011 08:44:10 -
@@ -145,11 +145,15 @@ if_fsm(struct iface *iface, enum iface_e
if (iface-state != old_state) {
orig_rtr_lsa(iface);
orig_link_lsa(iface);
-
- /* state change inform RDE */
- ospfe_imsg_compose_rde(IMSG_IFINFO,
- iface-self-peerid, 0, iface, sizeof(struct iface));
}
+
+ /*
+* Send interface update to RDE regardless of whether state changes - a
+* passive interface will remain in the DOWN state but may need to have
+* prefix LSAs sent regardless.
+*/
+ ospfe_imsg_compose_rde(IMSG_IFINFO,
+ iface-self-peerid, 0, iface, sizeof(struct iface));
if (old_state (IF_STA_MULTI | IF_STA_POINTTOPOINT)
(iface-state (IF_STA_MULTI | IF_STA_POINTTOPOINT)) == 0)
Index: rde.c
===
RCS file: /cvs/src/usr.sbin/ospf6d/rde.c,v
retrieving revision 1.50
diff -u -p -r1.50 rde.c
--- rde.c 22 Aug 2010 20:55:10 - 1.50
+++ rde.c 4 Jan 2011 08:44:11 -
@@ -22,6 +22,7 @@
#include sys/socket.h
#include sys/queue.h
#include sys/param.h
+#include net/if_types.h
#include netinet/in.h
#include arpa/inet.h
#include err.h
@@ -587,11 +588,17 @@ rde_dispatch_imsg(int fd, short event, v
iface = if_find(ifp-ifindex);
if (iface == NULL)
fatalx(interface lost in rde);
- iface-flags = ifp-flags;
- iface-linkstate = ifp-linkstate;
iface-nh_reachable = ifp-nh_reachable;
- if (iface-state != ifp-state) {
+
+ /* Resend LSAs if interface flags change */
+ if ((iface-state != ifp-state) ||
+ (iface-linkstate != ifp-linkstate) ||
+ (iface-flags != ifp-flags)) {
+
iface-state = ifp-state;
+ iface-flags = ifp-flags;
+ iface-linkstate = ifp-linkstate;
+
area = area_find(rdeconf, iface-area_id);
if (!area)
fatalx(interface lost area);
@@ -1459,8 +1466,27 @@ orig_intra_lsa_rtr(struct area *area, st
numprefix = 0;
LIST_FOREACH(iface, area-iface_list, entry) {
- if (iface-state IF_STA_DOWN)
+ /*
+* do not send a LSA for interfaces that:
+* - have a link state that is not up, or
+* - are down (kernel flags), or
+* - are in the down state, and are not [carp or marked as passive], or
+* - are unknown and are carp
+*
+* This will not advertise backup carp interfaces (which have a link
+* state of down).
+*/
+ if (!(LINK_STATE_IS_UP(iface-linkstate)) ||
+ !(iface-flags IFF_UP) ||
+ ((iface-state IF_STA_DOWN)
+ !((iface-media_type == IFT_CARP) ||
+ (iface-cflags F_IFACE_PASSIVE))) ||
+ ((iface-linkstate == LINK_STATE_UNKNOWN)
+ (iface-media_type == IFT_CARP))) {
+ log_debug(orig_intra_lsa_rtr: area %s, interface %s: not including
+in LSA, inet_ntoa(area-id), iface-name);
continue;
+ }
/* Broadcast links with adjacencies are handled
* by orig_intra_lsa_net(), ignore. */
Re: OpenOSPF6d does not send LSAs for passive interfaces
Patrick Coleman blin...@gmail.com wrote: Ok, the following should fix this. It's a little more involved; here's what's new: - Avoid sending LSAs if the link state is down (to avoid double-advertising CARP interfaces). OSPFd does this a little more elegantly using metrics[1], but I wasn't able to get that to work, perhaps I'm not understanding the protocol. Suggestions appreciated. - Don't send LSAs if the interface is down (ifconfig carp1 down), because that's silly - Make the OSPF engine update the RDE about interface changes even when the interface state does not change, so the RDE is informed when a passive interface's link state changes (so we can then make a decision using that data) - Resend intra-area LSAs in the RDE when interface flags change, not just interface state (avoids a race condition where LSAs get sent before the OSPF engine updates the RDE with new linkstate data) Initial testing looks good. With your first patch: Cisco# show ipv6 route 2001:dead:5:7357::13 IPv6 Routing Table - 23 entries Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP U - Per-user Static route I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2 ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2 O 2001:DEAD:5:7357::/64 [110/10] via FE80::214:22FF:FE73:466B, GigabitEthernet2/1 via FE80::214:22FF:FE73:44A3, GigabitEthernet2/1 Now: Cisco# show ipv6 route 2001:dead:5:7357::13 IPv6 Routing Table - 23 entries Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP U - Per-user Static route I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2 ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2 O 2001:DEAD:5:7357::/64 [110/10] via FE80::214:22FF:FE73:466B, GigabitEthernet2/1 And then lets shift the CARP: Cisco# show ipv6 route 2001:dead:5:7357::13 IPv6 Routing Table - 23 entries Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP U - Per-user Static route I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2 ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2 O 2001:DEAD:5:7357::/64 [110/10] via FE80::214:22FF:FE73:44A3, GigabitEthernet2/1 I will do some more testing.
Re: allow ugen(4) to attach to unused interfaces
On 01/04/11 00:13, Yojiro UO wrote: as the ugen(4) is too flexible (and unsafe) than other usb device drivers, i don't like this work to extend ugen(4)'s area. I know many userland applications which supports multiple platform using ugen type interface (because they usually use libusb or ugen apis), but it is no reason to support them without considerations. Here is one very strong consideration: Inasmuch as this change makes at least some MFC devices just work with CUPS and xsane, for normal users, without having to e.g., build a custom kernel, I am in favor of it, unless there is a *specific* risk to other drivers.
ls(1) multibyte support
Hi,
I wonder if there any plans on adding multibyte support for ls(1)?
Or maybe there's a reason why it's not a great idea (which I am not
aware of)?
Anyway, here's a patch I have. It's based on DragonFlyBSD's ls.
diff -u ls/ls.c ls/ls.c
--- ls/ls.c Wed Nov 24 17:39:05 2010
+++ ls/ls.c Tue Jan 4 19:44:35 2011
@@ -42,6 +42,7 @@
#include errno.h
#include fts.h
#include grp.h
+#include locale.h
#include pwd.h
#include stdio.h
#include stdlib.h
@@ -101,6 +102,8 @@
int ch, fts_options, notused;
int kflag = 0;
char *p;
+
+ setlocale(LC_ALL, );
/* Terminal defaults to -Cq, non-terminal defaults to -1. */
if (isatty(STDOUT_FILENO)) {
diff -u ls/util.c ls/util.c
--- ls/util.c Wed Nov 24 17:39:05 2010
+++ ls/util.c Tue Jan 4 21:04:22 2011
@@ -35,12 +35,14 @@
#include sys/types.h
#include sys/stat.h
+#include sys/limits.h
#include ctype.h
#include fts.h
#include stdio.h
#include stdlib.h
#include string.h
+#include wchar.h
#include ls.h
#include extern.h
@@ -48,11 +50,44 @@
int
putname(char *name)
{
- int len;
+ mbstate_t mbs;
+ wchar_t wc;
+ int i, len;
+ size_t clen;
- for (len = 0; *name; len++, name++)
- putchar((!isprint(*name) f_nonprint) ? '?' : *name);
- return len;
+ memset(mbs, 0, sizeof(mbs));
+ len = 0;
+ while ((clen = mbrtowc(wc, name, MB_LEN_MAX, mbs)) != 0) {
+ if (clen == (size_t)-1) {
+ if (f_nonprint)
+ putchar('?');
+ else
+ putchar((unsigned char)*name);
+ name++;
+ len++;
+ memset(mbs, 0, sizeof(mbs));
+ continue;
+ }
+ if (clen == (size_t)-2) {
+ if (f_nonprint) {
+ putchar('?');
+ len++;
+ } else
+ len += printf(%s, name);
+ break;
+ }
+ if (f_nonprint !iswprint(wc)) {
+ putchar('?');
+ name += clen;
+ len++;
+ continue;
+ }
+ for (i = 0; i (int)clen; i++)
+ putchar((unsigned char)name[i]);
+ name += clen;
+ len += wcwidth(wc);
+ }
+ return (len);
}
void
Re: ls(1) multibyte support
On Tue, Jan 04, 2011 at 09:14:51PM +0300, Alexander Polakov wrote:
Hi,
I wonder if there any plans on adding multibyte support for ls(1)?
Or maybe there's a reason why it's not a great idea (which I am not
aware of)?
Anyway, here's a patch I have. It's based on DragonFlyBSD's ls.
Any locale stuff added to applications that are used on the ramdisk
(bsd.rd) must be inside #ifndef SMALL.
The ls binary is linked statically so we need to prevent it from wasting
space by pulling citrus stuff onto the ramdisk.
More importantly, there is an alleged bug in our wcwidth() implementation.
I haven't had time to investigate, but it has been pointed out on separate
occasions, by Jordi Beltran Creix and by n...@.
Test program (from Jordi):
#include stdio.h
#include locale.h
main ()
{
setlocale(LC_ALL, );
printf(%d %d %d %d\n, wcwidth(0x53DA), wcwidth('A'),
wcwidth(0x200B), wcwidth(0x1F));
return 0;
}
Output is 2, 1, 1, 0, should be 2, 1, 0, -1 (according to Jordi).
We should make sure that wcwidth() is working properly before changing
applications to use it. We also need a wcwidth() man page.
FWIW, below is a diff that Jordi sent me some time ago to fix ls(1).
It also depends on wcwidth().
Index: ls.c
===
RCS file: /cvs/src/bin/ls/ls.c,v
retrieving revision 1.35
diff -u -p -r1.35 ls.c
--- ls.c27 Oct 2009 23:59:21 - 1.35
+++ ls.c7 Aug 2010 09:16:03 -
@@ -48,6 +48,8 @@
#include string.h
#include unistd.h
#include util.h
+#include locale.h
+#include wchar.h
#include ls.h
#include extern.h
@@ -102,6 +104,10 @@ ls_main(int argc, char *argv[])
int kflag = 0;
char *p;
+#ifndef SMALL
+ setlocale(LC_ALL, );
+
+#endif
/* Terminal defaults to -Cq, non-terminal defaults to -1. */
if (isatty(STDOUT_FILENO)) {
if ((p = getenv(COLUMNS)) != NULL)
@@ -396,6 +402,32 @@ traverse(int argc, char *argv[], int opt
err(1, fts_read);
}
+#ifndef SMALL
+static int
+mbswidth(const char *s)
+{
+ wchar_t wc;
+ size_t wclen;
+ mbstate_t mbs;
+ int width = 0;
+
+ bzero(mbs, sizeof(mbs));
+
+ while (*s) {
+ wclen = mbrtowc(wc, s, MB_CUR_MAX, mbs);
+ if (wclen 0 || !iswprint(wc)) {
+ if (wclen 0)
+ wclen = 1;
+ width++;
+ } else {
+ width += wcwidth(wc);
+ }
+ s += wclen;
+ }
+ return width;
+}
+#endif
+
/*
* Display() takes a linked list of FTSENT structures and passes the list
* along with any other necessary information to the print function. P
@@ -458,8 +490,13 @@ display(FTSENT *p, FTSENT *list)
continue;
}
}
+#ifndef SMALL
+ if (mbswidth(cur-fts_name) maxlen)
+ maxlen = mbswidth(cur-fts_name);
+#else
if (cur-fts_namelen maxlen)
maxlen = cur-fts_namelen;
+#endif
if (needstats) {
sp = cur-fts_statp;
if (sp-st_blocks maxblock)
Index: util.c
===
RCS file: /cvs/src/bin/ls/util.c,v
retrieving revision 1.14
diff -u -p -r1.14 util.c
--- util.c 27 Oct 2009 23:59:21 - 1.14
+++ util.c 7 Aug 2010 09:16:03 -
@@ -41,6 +41,7 @@
#include stdio.h
#include stdlib.h
#include string.h
+#include wchar.h
#include ls.h
#include extern.h
@@ -49,9 +50,26 @@ int
putname(char *name)
{
int len;
-
+#ifndef SMALL
+ size_t wclen;
+ wchar_t wc;
+ mbstate_t mbs;
+
+ bzero(mbs, sizeof(mbs));
+ for (len = 0; *name; len += wcwidth(wc), name += wclen) {
+ wclen=mbrtowc(wc, name, MB_CUR_MAX, mbs);
+ if (wclen 0) {
+ wclen = 1;
+ wc = '?';
+ } else {
+ wc = (!iswprint(wc) f_nonprint) ? '?' : wc;
+ }
+ putwchar(wc);
+ }
+#else
for (len = 0; *name; len++, name++)
putchar((!isprint(*name) f_nonprint) ? '?' : *name);
+#endif
return len;
}
Re: ls(1) multibyte support
* Stefan Sperling s...@stsp.name [110104 23:12]:
On Tue, Jan 04, 2011 at 09:14:51PM +0300, Alexander Polakov wrote:
Hi,
I wonder if there any plans on adding multibyte support for ls(1)?
Or maybe there's a reason why it's not a great idea (which I am not
aware of)?
Anyway, here's a patch I have. It's based on DragonFlyBSD's ls.
Any locale stuff added to applications that are used on the ramdisk
(bsd.rd) must be inside #ifndef SMALL.
The ls binary is linked statically so we need to prevent it from wasting
space by pulling citrus stuff onto the ramdisk.
Sure.
More importantly, there is an alleged bug in our wcwidth() implementation.
I haven't had time to investigate, but it has been pointed out on separate
occasions, by Jordi Beltran Creix and by n...@.
Test program (from Jordi):
#include stdio.h
#include locale.h
main ()
{
setlocale(LC_ALL, );
printf(%d %d %d %d\n, wcwidth(0x53DA), wcwidth('A'),
wcwidth(0x200B), wcwidth(0x1F));
return 0;
}
Output is 2, 1, 1, 0, should be 2, 1, 0, -1 (according to Jordi).
We should make sure that wcwidth() is working properly before changing
applications to use it. We also need a wcwidth() man page.
I think there're 2 separate bugs and I have 2 fixes (neither one
tested).
1) wcwidth(0x200B)
This if from http://unicode.org/Public/UNIDATA/ :
200B;ZERO WIDTH SPACE;Cf;0;BN;N;
200C;ZERO WIDTH NON-JOINER;Cf;0;BN;N;
200D;ZERO WIDTH JOINER;Cf;0;BN;N;
--- share/locale/ctype/en_US.UTF-8.src.orig Tue Jan 4 22:49:22 2011
+++ share/locale/ctype/en_US.UTF-8.src Tue Jan 4 22:50:55 2011
@@ -1672,7 +1672,8 @@
BLANK 0x2000 - 0x200b 0x202f 0x205f
PRINT 0x2000 - 0x200b 0x2010 - 0x2029 0x202f - 0x2052 0x2057
PRINT 0x205f
-SWIDTH1 0x2000 - 0x200b 0x2010 - 0x2029 0x202f - 0x2052 0x2057
+SWIDTH1 0x2000 - 0x200c 0x2010 - 0x2029 0x202f - 0x2052 0x2057
+SWIDTH0 0x200b - 0x200d
SWIDTH1 0x205f
2) wcwidth(0x1f)
DragonFly's man page for wcwidth(3) says that function returns -1 if
character is not printable. _RUNETYPE_R is the flag to check.
--- lib/libc/locale/iswctype.c.orig Tue Jan 4 23:12:23 2011
+++ lib/libc/locale/iswctype.c Tue Jan 4 23:02:37 2011
@@ -170,7 +170,11 @@
int
wcwidth(wchar_t c)
{
-return (((unsigned)__runetype_w(c) _CTYPE_SWM) _CTYPE_SWS);
+ _RuneType r;
+ r = __runetype_w(c);
+ if (r _RUNETYPE_R)
+ return (((unsigned)r _CTYPE_SWM) _CTYPE_SWS);
+ return -1;
}
wctrans_t
Again, I don't have hardware at hand to build libc so this is completely
untested.
Cursos Enero 2011 - Segunda semana
Cursos Enero 2011 - Segunda semana * Introduccion a la programacion (C#) - Martes y jueves de 18:30 a 21.30hs. 4/01/2011. Costo Total: $400. Detalle: Este curso constituye la base necesaria para construir programas de computadora con fines practicos en diversos lenguajes y ambientes. El asistente que complete este curso y sus practicas asociadas, sera capaz de resolver diversos problemas comunes en el ambiente empresarial utilizando un programa de computadora. Mas Informacion. * Introduccion al Lenguaje JAVA - Martes de 20 a 22hs. 4/01/2011. Costo Total: GRATIS. Detalle: Que es JAVA - Herramientas necesarias. - Introduccion a la POO - Concepto de herencia, polimorfismo y encapsulamiento. - Clases y objetos. Conceptos. - Atributos y metodos. - Analizando una aplicacion de ejemplo. Mas Informacion. * JQuery y Ajax para programadores ASP.NET: Lunes y miercoles de 14 a 18 h s 10/01/2011. Costo Total: $200. Detalle: Durante el curso se veran los conceptos basicos del desarrollo Web con JQuery, integracion con ASP.NET y Controles Ajax toolkit. Mas Informacion. * Programacion de paginas WEB dinamicas desde cero con PHP: Lunes a viernes de 14 a18hs. 10/01/2011. Costo Total: $1200. Detalle: Aprender las principales posibilidades que ofrece la programacion Web a traves del lenguaje PHP. Mas Informacion. * Programando en C Sharp (C#): Lunes 20 a 11 hs. 10/01/2011. Costo Total: $400. Detalle: Este curso ensena los principios del lenguaje C# y la programacion orientada a objetos, a partir de su ultima y mas potente version, se orienta a construir aplicaciones comerciales e incluye los principios del manejo de datos desde este lenguaje. Se requiere conocer los principios base de programacion. Mas Informacion. * NHibernate para programadores .NET (C#): Miercoles y Viernes de 9 a 18 hs. 12/01/2011. Costo Total: $400. Detalle: Al finalizar el curso, el alumno debera ser capaz de programar aplicaciones con NHibernate en menor tiempo que utilizando metodos tradicionales mediante SQL. Mas Informacion. * JAVA paso a paso: Lunes a viernes de 14 a 18hs. 17/01/2001. Costo Total: $1200. Detalle: Brindar las herramientas necesarias para utilizar la tecnologia Java en el dia a dia. Al finalizar el curso, el alumno debera ser capaz de construir aplicaciones en Java. Mas Informacion. * Aprendiendo a programar con Python: Lunes y miercoles de 18:30 a 21.30hs. 17/01/2011. Costo Total: $720. Detalle: El curso esta orientado al aprendizaje de los conceptos basicos de programacion y a adquirir habilidades practicas en Python. El asistente aprendera las bases de programacion que le serviran para aplicar en cualquier lenguaje. Mas Informacion. Club de Programadores: TEL: 4381-2171 / 4383-2056 | Correo: clubdeprogramado...@fibertel.com.ar www.clubdeprogramadores.com
Server Dedicado para Email
This is a message in multipart MIME format. Your mail client should not be displaying this. Consider upgrading your mail client to view this message correctly.
Re: ls(1) multibyte support
2011/1/5 Alexander Polakov polac...@gmail.com: 1) wcwidth(0x200B) This if from http://unicode.org/Public/UNIDATA/ : 200B;ZERO WIDTH SPACE;Cf;0;BN;N; 200C;ZERO WIDTH NON-JOINER;Cf;0;BN;N; 200D;ZERO WIDTH JOINER;Cf;0;BN;N; --- share/locale/ctype/en_US.UTF-8.src.orig B B Tue Jan B 4 22:49:22 2011 +++ share/locale/ctype/en_US.UTF-8.src B Tue Jan B 4 22:50:55 2011 @@ -1672,7 +1672,8 @@ B BLANK B B 0x2000 - 0x200b B 0x202f B 0x205f B PRINT B B 0x2000 - 0x200b B 0x2010 - 0x2029 B 0x202f - 0x2052 B 0x2057 B PRINT B B 0x205f -SWIDTH1 B 0x2000 - 0x200b B 0x2010 - 0x2029 B 0x202f - 0x2052 B 0x2057 +SWIDTH1 B 0x2000 - 0x200c B 0x2010 - 0x2029 B 0x202f - 0x2052 B 0x2057 +SWIDTH0 B 0x200b - 0x200d B SWIDTH1 B 0x205f That only solves the test case. All combining characters(diacritic marks), including 0x300, should be 0 width as well. Accepted interpretation of Unicode rules appears to be that Cf, Me and Mf categories +- a few characters are to be 0-spaced, see the comments in: http://www.cl.cam.ac.uk/~mgk25/ucs/wcwidth.c That file also happens to be in xenocara/app/xterm/wcwidth.c so that was the behavior in xterm until(I assume) it started using the system version. The database file in OpenBSD is just too old, the same problem file was fixed in FreeBSD in 2006, see: http://code.bsd64.org/cvsweb/freebsd/src/share/mklocale/UTF-8.src
