packet loss in larger packets
Hi, I'm using OpenBSD 5.1 and an Intel 10GbE SR (82598AF) ethernet card as a router/firewall and it's working almost perfect. It is routing around 2 gbps of traffic. On the ix0 interface there are several vlans configured with an MTU of 1500. When I'm pinging a switch connected to the system (with 10 gbps) there is no packet loss while sending packets of 1472 bytes. From 1473 bytes and more there is somewhere between 15 to 40% loss. I first thought the switch was busy, but from another (Linux) system, connected with 10 gbps and the same network interface there is no loss on larger packets. Does someone have an idea on how to solve this? Regards, Erwin
End of life for Apache Tomcat 5.5.x
Tomcat 5.5.x is about to being deprecated. I'd like to remove it from our ports tree on 1st October 2012. So, if you're still using it, please update to Tomcat6 or Tomcat7. Cheers! David
Re: OpenBGP lost session
Am 2012-09-18 16:34, schrieb Stuart Henderson: On 2012-09-18, Bernd be...@kroenchenstadt.de wrote: Hi list, I've got two OpenBSD (5.1-STABLE, amd64) machines running OpenBGPd. Both of them are connected to two upstream providers each, furthermore there are (older) Ciscos, also connecteed to the same (!) upstream routers. Recently, both OpenBSD machines lost their BGP session to one of the upstream providers. On both machines the same upstream router was affected. Logs show this: Sep 17 17:25:35 hostname bgpd[1638]: neighbor 12.23.34.45 (Upstream1): sending notification: HoldTimer expired, unknown subcode 0 Sep 17 17:25:35 hostname bgpd[1638]: neighbor 12.23.34.45 (Upstream1): state change Established - Idle, reason: HoldTimer expired Sep 17 17:25:43 hostname ospfd[5366]: desync; scheduling fib reload Sep 17 17:25:43 hostname ospfd[5366]: reloading interface list and routing table Sep 17 17:25:48 hostname bgpd[15513]: nexthop 12.23.34.45 now valid: directly connected Sep 17 17:26:05 hostname bgpd[1638]: neighbor 12.23.34.45 (Upstream1): state change Idle - Connect, reason: Start Sep 17 17:26:05 hostname bgpd[1638]: neighbor 12.23.34.45 (Upstream1): state change Connect - OpenSent, reason: Connection opened Sep 17 17:26:05 hostname bgpd[1638]: neighbor 12.23.34.45 (Upstream1): state change OpenSent - OpenConfirm, reason: OPEN message received Sep 17 17:26:05 hostname bgpd[1638]: neighbor 12.23.34.45 (Upstream1): state change OpenConfirm - Established, reason: KEEPALIVE message received Sep 17 17:26:20 hostname bgpd[15513]: nexthop 12.23.34.45 now valid: directly connected The Ciscos didn't see anything like this, their sessions didn't drop. Any clue what was going on? Thanks, Bernd Can't tell from this. Are you running the same hold times on your openbgp boxes as your ciscos? Hi, yes, it's 90 sec on the Ciscos as well as for BGPd (default is 90 sec). Best, Bernd
Re: packet loss in larger packets
On Fri, 21 Sep 2012, Erwin Lubbers wrote: I'm using OpenBSD 5.1 and an Intel 10GbE SR (82598AF) ethernet card as a router/firewall and it's working almost perfect. It is routing around 2 gbps of traffic. On the ix0 interface there are several vlans configured with an MTU of 1500. When I'm pinging a switch connected to the system (with 10 gbps) there is no packet loss while sending packets of 1472 bytes. From 1473 bytes and more there is somewhere between 15 to 40% loss. I first thought the switch was busy, but from another (Linux) system, connected with 10 gbps and the same network interface there is no loss on larger packets. Does someone have an idea on how to solve this? Can you show from both systems with tcpdump what the packets look like? You are using normal (no flood) ping and the systems and switch are not loaded with other traffic?
Re: packet loss in larger packets
Op 21 sep. 2012, om 09:43 heeft Camiel Dobbelaar c...@sentia.nl het volgende geschreven: Can you show from both systems with tcpdump what the packets look like? You are using normal (no flood) ping and the systems and switch are not loaded with other traffic? No flooding ping, just normal ping packets. I will create a tcpdump later. But the output of a 1472 and 1473 ping packet looks like this. And even if I disable PF the problem stays the same. Switch is handling around 350 mbps of traffic at the moment of doing this pings. # ping -s 1472 -c 20 10.0.1.239 PING 10.0.1.239 (10.0.1.239): 1472 data bytes 1480 bytes from 10.0.1.239: icmp_seq=0 ttl=255 time=1.782 ms 1480 bytes from 10.0.1.239: icmp_seq=1 ttl=255 time=1.499 ms 1480 bytes from 10.0.1.239: icmp_seq=2 ttl=255 time=1.244 ms 1480 bytes from 10.0.1.239: icmp_seq=3 ttl=255 time=1.339 ms 1480 bytes from 10.0.1.239: icmp_seq=4 ttl=255 time=1.453 ms 1480 bytes from 10.0.1.239: icmp_seq=5 ttl=255 time=1.486 ms 1480 bytes from 10.0.1.239: icmp_seq=6 ttl=255 time=1.627 ms 1480 bytes from 10.0.1.239: icmp_seq=7 ttl=255 time=2.323 ms 1480 bytes from 10.0.1.239: icmp_seq=8 ttl=255 time=1.386 ms 1480 bytes from 10.0.1.239: icmp_seq=9 ttl=255 time=1.511 ms 1480 bytes from 10.0.1.239: icmp_seq=10 ttl=255 time=1.578 ms 1480 bytes from 10.0.1.239: icmp_seq=11 ttl=255 time=1.552 ms 1480 bytes from 10.0.1.239: icmp_seq=12 ttl=255 time=1.732 ms 1480 bytes from 10.0.1.239: icmp_seq=13 ttl=255 time=1.279 ms 1480 bytes from 10.0.1.239: icmp_seq=14 ttl=255 time=1.369 ms 1480 bytes from 10.0.1.239: icmp_seq=15 ttl=255 time=1.399 ms 1480 bytes from 10.0.1.239: icmp_seq=16 ttl=255 time=1.513 ms 1480 bytes from 10.0.1.239: icmp_seq=17 ttl=255 time=1.546 ms 1480 bytes from 10.0.1.239: icmp_seq=18 ttl=255 time=1.551 ms 1480 bytes from 10.0.1.239: icmp_seq=19 ttl=255 time=1.483 ms --- 10.0.1.239 ping statistics --- 20 packets transmitted, 20 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 1.244/1.532/2.323/0.227 ms # ping -s 1473 -c 20 10.0.1.239 PING 10.0.1.239 (10.0.1.239): 1473 data bytes 1481 bytes from 10.0.1.239: icmp_seq=1 ttl=255 time=2.107 ms 1481 bytes from 10.0.1.239: icmp_seq=2 ttl=255 time=2.035 ms 1481 bytes from 10.0.1.239: icmp_seq=3 ttl=255 time=2.045 ms 1481 bytes from 10.0.1.239: icmp_seq=4 ttl=255 time=2.048 ms 1481 bytes from 10.0.1.239: icmp_seq=6 ttl=255 time=2.708 ms 1481 bytes from 10.0.1.239: icmp_seq=7 ttl=255 time=1.768 ms 1481 bytes from 10.0.1.239: icmp_seq=8 ttl=255 time=2.274 ms 1481 bytes from 10.0.1.239: icmp_seq=9 ttl=255 time=1.775 ms 1481 bytes from 10.0.1.239: icmp_seq=11 ttl=255 time=3.969 ms 1481 bytes from 10.0.1.239: icmp_seq=13 ttl=255 time=5.679 ms 1481 bytes from 10.0.1.239: icmp_seq=14 ttl=255 time=2.012 ms 1481 bytes from 10.0.1.239: icmp_seq=15 ttl=255 time=2.148 ms 1481 bytes from 10.0.1.239: icmp_seq=17 ttl=255 time=2.179 ms 1481 bytes from 10.0.1.239: icmp_seq=18 ttl=255 time=1.796 ms 1481 bytes from 10.0.1.239: icmp_seq=19 ttl=255 time=3.433 ms --- 10.0.1.239 ping statistics --- 20 packets transmitted, 15 packets received, 25.0% packet loss round-trip min/avg/max/std-dev = 1.768/2.531/5.679/1.035 ms
Re: Question about security bug fixes for in-tree NSD
On 2012-09-20, Mathieu Simon mathieu@gmail.com wrote: G'day This is my first post to this list - so bear with me... OpenBSD has not yet replaced BIND with NSD + Unbound, but NSD 3.2.9 is enabled in 5.1 builds. This version has at least 2 known CVE's that have been fixed with upstream releases: 3.2.12: Fix for VU#624931 CVE-2012-2978: NSD denial of service vulnerability from non-standard DNS packet from any host on the internet. 3.2.13: Bugfix #461 (VU#517036 CVE-2012-2979): NSD denial of service vulnerability from DNS packet when using --enable-zone-stats. As of changelog, 5.2 will come with 3.2.12, closing CVE-2012-2978. Only -current has 3.2.13, closing CVE-2012-2979. CVE-2012-2979 isn't relevant as it's a non-standard build option that we don't use. I have not found a patch for in 5.1 erratas so far. I've just committed a fix for CVE-2012-2978 to 5.1-stable, but I don't have time to handle issuing errata at the moment.
Re: Question about security bug fixes for in-tree NSD
Am 21.09.2012 14:51, schrieb Stuart Henderson: CVE-2012-2979 isn't relevant as it's a non-standard build option that we don't use. Good to know, thanks. I have not found a patch for in 5.1 erratas so far. I've just committed a fix for CVE-2012-2978 to 5.1-stable, but I don't have time to handle issuing errata at the moment. Yes, I just ran across your change, thank you Stuart to putting this in -stable. Let's hope the errata makes it to the page a little later - one can still follow CVS by now. :-) -- Mat
Habilidades Gerenciales de Alto Impacto
Curso Ejecutivo Internacional Habilidades Gerenciales de Alto ImPACTO Panama 10-12 de Octubre de 2012 Sheraton Panama Hotel Convention Center QUALITY TRAINING, presenta un extraordinario seminario que se llevará a cabo en la ciudad de Panamá ¡No se pierda uno de los eventos más interesantes en el mundo gerencial actual! El éxito de su organización descansa sobre sus hombros... - Cómo responder a la presión abrumadora y a los problemas aparentemente insuperables con confianza y serenidad. - Deje de preocuparse sobre qué camino de acción seguir Tome las decisiones del negocio de manera más rápida y efectiva. - Dirija con la confianza, el valor y la convicción que inspira a sus colaboradores a dar su mayor esfuerzo. - Identifique y elimine las barreras de la productividad. - Cómo reconocer los puntoso débiles en su personal y saber con seguridad cuándo dejar que las personas se vayan. - Reenfoque las prioridades sobre los asuntos que son más importantes y cambie direcciones rápidamente si es necesario. - ¡Aprenda a negociar para GANAR! - Cómo hacer de su empresa una organización donde el cambio, el aprendizaje y la evolución del individuo sean las bases de una organización virtuosa. - Desarrolle habilidades para comunicarse con dinamismo y poder. - Comuníquese con tacto, profesionalismo y diplomacia hasta en los más desafiantes momentos. ¡¡ Un encuentro único que usted no puede dejar pasar!! Adquiera la información completa y sin compromiso, solo responda este correo con asunto -Deseo Folleto Gerentes o Comuníquese al (507) 279-1083 / 279-0258 / 279-0887 - y a la brevedad lo recibirá! ESTE CORREO NO PUEDE SER CONSIDERADO INTRUSIVO YA QUE CUMPLE CON LAS POLÍTICAS ANTISPAM INTERNACIONALES Y LOCALES: Responda este correo con el Asunto borrar y automáticamente quedará fuera de nuestras listas. Este correo ha sido enviado a: misc@openbsd.org
How to stress (performance?) test my PF rules?
Does anyone have any suggestions on how to best test the performance of my PF ruleset? Maybe iperf? I'm just diving into learning PF and as I make changes to my ruleset, it would be great if there's a good way of testing the traffic flow through my OBSD box. Suggestions? Thank you, Ed
Nueva fecha para el curso de El Arte de Saber Servir al Cliente
Apreciable Ejecutivo: TIEM de México Empresa Líder en Capacitación y Actualización de Capital Humano Debido a la gran demanda abrimos una nueva fecha para el curso de: El Arte de Saber Servir al Cliente Está Programado para el: 02 de Octubre en la Ciudad de México Inscríbase 5 días antes de la fecha del Curso y obtenga un descuento del 15% con Inversión Inmediata Además por cada dos participantes inscritos en tarifa de Inversión normal, el tercero es completamente gratis No deje pasar esta oportunidad e Invierta en su Desarrollo Personal y Profesional Una de las grandes preocupaciones de las empresas, es Contactar, Atender, Vender y Retener a más clientes; para lo cual invierten cantidades muy significativas en instalaciones, capacitación y tecnología actualizada. Lo que no es suficiente, porque existen otros factores importantes: Imagen Personal e Imagen Institucional, (formas y métodos de atención, cultura de servicio, así como imagen de la empresa o marca). Todos la construimos o destruimos. Beneficios de este Curso: Conocerán objetivamente los beneficios de la comunicación persuasiva. Cómo entender a los clientes o usuarios de los servicios empatía- Cómo y porque ofrecer servicios de calidad. Cómo ser un hábil negociador. Cómo entender las preocupaciones de los clientes Y/O contentarlos. Cómo ir más allá del servicio al cliente. Del Costo, Vs. Beneficio Que gano y que puedo perder Objetivo Principal: Sensibilizar a los participantes, sobre la importancia y conveniencia de otorgar servicios y atención de alta calidad a los clientes Y/O usuarios de los servicios de su empresa o dependencia, mediante acciones concretas de apoyo y ayuda en sus requerimientos, Mejorando y reforzando sus habilidades de comunicación, persuasión y de Servicio. Para mayor información, favor de responder este correo con los siguientes datos: Empresa: Nombre: Ciudad: Teléfono: O si lo prefiere comuníquese a los teléfonos: Del DF al 5611-0969 con 10 líneas Interior del País Lada sin Costo 01 800 900 TIEM (8436) Aceptamos todas las TDC y Débito. **Promoción: 3 meses sin Intereses pagando con American Express **Aplica solo con Inversión Normal ®Todos los Derechos Reservados ©2011 TIEM Talento e Innovación Empresarial de México Este Mensaje le ha sido enviado como usuario de TIEM de México o bien un usuario le refirió para recibir este boletín. Como usuario de TIEM de México, en este acto autoriza de manera expresa que TIEM de México le puede contactar vía correo electrónico u otros medios. Si usted ha recibido este mensaje por error, haga caso omiso de él y reporte su cuenta respondiendo este correo con el subject BAJABD Unsubscribe to this mailing list, reply a blank message with the subject UNSUBSCRIBE BAJABD Tenga en cuenta que la gestión de nuestras bases de datos es de suma importancia y no es intención de la empresa la inconformidad del receptor.
Re: dovecot
On Fri, Sep 21, 2012, at 09:46 AM, Stuart Henderson wrote: On 2012/09/21 12:25, Kevin Chadwick wrote: On Fri, 21 Sep 2012 12:54:46 +0300 Artturi Alm wrote: Not sure if this is the right spot for this post. I am after a more current version of dovecot than dovecot-2.0.13p5 to run on 5.0 release. Does anyone have a package or port available ? It's easy enough to build. Yet one should not build it from newer ports on 5.0 release. Yep the newer port is not directly usable as there have been changes to the system (sqlite3 added to base) but tweaking it should not be hard, just don't expect too much help for doing a non-standard thing when you could just update. OpenBSD 5.1 has Dovecot 2.0.17 in binary packages (and 2.0.20 in -stable ports which is very easy to update to if you're using 5.1). OpenBSD 5.2 will have 2.1.8, or -current usually tracks upstream releases fairly promptly. True, probably should have been clearer. Just check out the ports patches adapt them and build outside of ports and test. Easier than using ports if you are not on current and want a newer version. That way you're likely to end up with files sprinkled over /usr rather than /usr/local which might cause exciting problems later. Adapting the newer port is a safer suggestion, and also likely to be easier. Though just upgrading is almost always the simplest option. And because you are running 5.0 you are on the cusp of running an unsupported release.
