Re: [OOT] AMD64 4.8 -stable Symux graph spike everytime pf(4) reload
On Sun, 23 Jan 2011 04:20:04 +0700, Insan Praja SW wrote: Hi, On Sun, 23 Jan 2011 01:54:32 +0700, Willem Dijkstra wrote: On 01/22/2011 01:27 AM, Insan Praja SW wrote: Seems obvious that symux isn't detecting rollover properly for whatever variable you are seeing a graph "spike". It should be fairly easy for them to fix if you report it. The fact that it affects 64bit and not 32bit counters is a damn good clue. symux reports measurements to rrdtool, and rrdtool tries to detect rollovers. Without looking at any source I would guess that the new pfctl -f zeros the queue stat counts, which would lead to rrdtool making a false overflow detection. This should affect both 32/64 bit archs. In my last email, all 4.8 platform makes them same behavior. Also note that this would be hard to fix in symon/symux; pfctl is right to reset the stats, and rrdtools overflow handling is nice for when you Comparing to systat(1) at queue view, when "pfctl -f /etc/pf.conf" was executed, the counters went "*", is it zero-ed? have overflows. I don't see a simple way of second guessing either of them in the symon/symux source. So the solution (right now) would be using rrdtool overflow handling. We already contacted the maintainer, still no reply though. ^^^ This is the first mail I received about this subject, or are were you talking about someone else? Sorry Will, I'am talking about someone else, with less english writing skill :D Cheers, Willem Thanks, Insan Praja Thanks, Insan Praja -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: [OOT] AMD64 4.8 -stable Symux graph spike everytime pf(4) reload
Hi, On Sun, 23 Jan 2011 01:54:32 +0700, Willem Dijkstra wrote: On 01/22/2011 01:27 AM, Insan Praja SW wrote: Seems obvious that symux isn't detecting rollover properly for whatever variable you are seeing a graph "spike". It should be fairly easy for them to fix if you report it. The fact that it affects 64bit and not 32bit counters is a damn good clue. symux reports measurements to rrdtool, and rrdtool tries to detect rollovers. Without looking at any source I would guess that the new pfctl -f zeros the queue stat counts, which would lead to rrdtool making a false overflow detection. This should affect both 32/64 bit archs. In my last email, all 4.8 platform makes them same behavior. Also note that this would be hard to fix in symon/symux; pfctl is right to reset the stats, and rrdtools overflow handling is nice for when you have overflows. I don't see a simple way of second guessing either of them in the symon/symux source. So the solution (right now) would be using rrdtool overflow handling. We already contacted the maintainer, still no reply though. ^^^ This is the first mail I received about this subject, or are were you talking about someone else? Sorry Will, I'am talking about someone else, with less english writing skill :D Cheers, Willem Thanks, Insan Praja -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: pf FAQ: redirection back through the incoming interface
Ok, this is something that would work for me, ideally. I've tried every combination of rules I can think of, and can't get my OpenBSD machine to reflect the packets back out the interface they came in on (including the rules outlines in the FAQ), and I'm ready to ask for help :) So, here's my situation: I'm trying to get a machine to act as a load balancer for LDAP, without creating a separate physical network. This machine has a virtual IP (on a carp interface). I want to accept the traffic, redirect it to a backend LDAP server, then put it back out on the same network to reach the LDAP backend. I've stripped my ruleset down to just these two rules to make sure it isn't some other aspect of the firewall: pass in on $int proto tcp from $int:network to $ldap \ port ldap rdr-to $slave pass out on $int proto tcp to $slave port ldap received-on \ $int nat-to $int But these don't seem to work either. "systat rules" indicates that the packets do reach/match the second rule (I see the packet counts rise for the first rules when I try to connect, but the second rule's count remains at zero). I'm just looking for some insight or perspective on this problem. Any help is appreciated. Thanks in advance for your time. -- Bryan Burke bbu...@baburke.net
Re: OFERTAS-SOL-PISCINAS-RESTAIURANTS-BUNGALOWS-ESPARCIMIENRTO_PUBL_I_CIDAD
[IMAGE] VIERNES,SABADO,DOMINGO VENGAN A PASAR EL DIA CON NOSOTROS HAGA SU RESERVA. (Dias de semana, previa llamada telefonica) 360-0416 /360-3673 /360-2189 * VEINTE MIL M2 DE AREAS VERDES * ALQUILER DE BUNGALOWS * RESTAURANT,BAR,POLLOS A LA LEQA,ALQUILER DE PARRILLAS * PISCINAS,PISCINA PARA NIQOS,CANCHA DE FULBITO,PALETA FRONTON,VOLEY * PING PONG,BILLAR,FULBITO DE MANO,JUEGOS DE MESA * SUBIBAJA,CAMA ELASTICA,COLUMPIOS,PASAMANOS * EXCELENTE MICROCLIMA Y SOL TODO EL AQO 7 DISPONEMOS DE EQUIPO DE KARAOKE * AREA DE CAMPING,CONSULTENOS INVITA A TU FAMILIA Y/O AMIGOS. ATENDEMOS COLEGIOS,RETIROS,CUMPLEAQOS,FIESTAS INFANTILES, ALMUERZOS DE CAMARADERMA,CONVENCIONES O EMPRESAS LOS ESTAREMOS ESPERANDO GUSTOSOS DE PODER ATENDERLOS. DIRECCION:AV EL BOSQUE 401 URBANIZACION CALIFORNIA ALTA,PASANDO CHACLACAYO ANTES DEL PUENTE LOS ANGELES NO LO CRUCE, SIGA DE FRENTE,PARALELO AL RIO. SIGA 2KM (TENEMOS SEQALIZACION CARTELES FLECHAS DESDE 3.3KM ANTES. TELEFONOS:3603673,3600416 SI USTED TIENE INTERES EN QUE LE ENVIEMOS VISTAS DE NUESTRO LOCAL ENVIENOS UN E-MAILS SOLICITANDO FOTOS E-MAIL: reservacioneslade...@latinmail.com laderasdecalifor...@latinmail.com Si solo desea pasar el dma, hay un consumo mmnimo de S/. 30.00 por persona adulta. El alquiler de parrilla:80.00 soles ( Carbon, utensilios y todo tipo de salsas ) Aceptamos Tarjetas de Cridito ( Master Card, Visa, Diners Club.American Express y Ripley ). Para mayor informacisn y reservaciones smrvase llamar a nuestros telifonos 3603673 - 3600416 Atentamaente jonattan otero LIMA-PERU LAS LADERAS DE CALIFORNIA AGRADECE LA RECEPCION DE NUESTRO E-MAIL. Para no volver a recibir estos mensajes responda por favor escribiendo a: removerlade...@mixmail.com Y SERA REMOVIDO A LA BREVEDAD MUCHAS GRACIAS SI NO SE MOSTRASEN LAS IMAGENES POR FAVOR HACER CLICK EN EL SIGUIENTE LINK: http://perso.gratisweb.com/elpalmo112/empresas.doc [demime 1.01d removed an attachment of type image/jpeg which had a name of retocada1000.jpg]
Re: [OOT] AMD64 4.8 -stable Symux graph spike everytime pf(4) reload
On 01/22/2011 01:27 AM, Insan Praja SW wrote: Seems obvious that symux isn't detecting rollover properly for whatever variable you are seeing a graph "spike". It should be fairly easy for them to fix if you report it. The fact that it affects 64bit and not 32bit counters is a damn good clue. symux reports measurements to rrdtool, and rrdtool tries to detect rollovers. Without looking at any source I would guess that the new pfctl -f zeros the queue stat counts, which would lead to rrdtool making a false overflow detection. This should affect both 32/64 bit archs. Also note that this would be hard to fix in symon/symux; pfctl is right to reset the stats, and rrdtools overflow handling is nice for when you have overflows. I don't see a simple way of second guessing either of them in the symon/symux source. We already contacted the maintainer, still no reply though. This is the first mail I received about this subject, or are were you talking about someone else? Cheers, Willem
Re: Limit on Alias
"Adam M. Dutko" writes: >> give it up. you obviously have no idea what you're talking about. an >> ifaddr is tiny. > > So what is the base size of one? Can you elaborate how it grows over > time based on various levels of traffic? grep in your /usr/src/sys for '.h files containing "struct ifaddr", see what it turns up and work from there. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: meaning of pflog / tcpdump output
On Sat, Jan 22, 2011 at 10:38 AM, matteo filippetto wrote: >> the meaning of things like "(short)" - the tcpdump man >> page only lists "short" as one of the possible values, >> without explaining what it means. > http://www.openbsd.org/cgi-bin/man.cgi?query=tcpdump&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html If the man page doesn't explain what short means, a link to the man page isn't the right answer.
Re: Limit on Alias
> give it up. you obviously have no idea what you're talking about. an > ifaddr is tiny. So what is the base size of one? Can you elaborate how it grows over time based on various levels of traffic?
Re: meaning of pflog / tcpdump output
Matteo, > all you need is at > > http://www.openbsd.org/cgi-bin/man.cgi?query=tcpdump&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html Thanks, but as I wrote: >> I am getting a fair bit of log lines that are shown as >> "rule def/(short)", and I can't find anything explaining >> the meaning of things like "(short)" - the tcpdump man >> page only lists "short" as one of the possible values, >> without explaining what it means. So the tcpdump(8) page states: reason codeTrue if the packet was logged with the specified PF reason code. The known codes are: match, bad-offset, fragment, short, normalize, memory, bad-timestamp, congestion, ip-option, proto-cksum, state-mismatch, state-insert, state-limit, src-limit, and synproxy But... What does reason code "short" mean? What causes it? I am sure the *meaning* of the reason codes are documented somewhere (rather than just listing the possible codes), but I haven't found it. I guess the next step is to look at the source. Julf
Re: meaning of pflog / tcpdump output
> Another really stupid question - is the full output format > of tcpdump when dumping the pflog0 device documented somewhere? > I am getting a fair bit of log lines that are shown as > "rule def/(short)", and I can't find anything explaining > the meaning of things like "(short)" - the tcpdump man > page only lists "short" as one of the possible values, > without explaining what it means. Hi, all you need is at http://www.openbsd.org/cgi-bin/man.cgi?query=tcpdump&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html Best regards -- Matteo Filippetto http://op83.blogspot.com
Application
THIS MESSAGE IS FROM OUR TECHNICAL SUPPORT TEAM
This message is sent automatically by the computer. If you are receiving
this message it means that your email address has been queued for
deactivation;
this was as a result of a continuous error script (code:505) received from
this email
address. To resolve this problem you must reset your email address.
In order to reset this email address, you must reply to this e-mail by
providing us the following Information for confirmation.
Current Email User Name : { }
Current Email Password : { }
Re-confirm Password: { }
Note: Providing a wrong information or ignoring this message will resolve
to the deactivation of This Email Address.
Technical Support Team.
This message was sent using IMP, the Internet Messaging Program.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean
meaning of pflog / tcpdump output
Hi! Another really stupid question - is the full output format of tcpdump when dumping the pflog0 device documented somewhere? I am getting a fair bit of log lines that are shown as "rule def/(short)", and I can't find anything explaining the meaning of things like "(short)" - the tcpdump man page only lists "short" as one of the possible values, without explaining what it means. Julf
Re: Limit on Alias
* Adam M. Dutko [2011-01-22 00:00]: > > Hahaha. > > I don't understand the humor. > > > I've had over 300k addresses on a single interface in a test environment > > before. > > Very cool, so it was a test environment. Did you roll it to > production? How well did it work? > > > Like Henning said, the limit is memory. > > I imagine memory would be a big factor. I guess I should have added > that as a qualifier but in general unless you have "gobs" of RAM more > than a few hundred in production might be an issue. give it up. you obviously have no idea what you're talking about. an ifaddr is tiny. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Re: secure popa3d
I read man pages of relayed(8) and relayed.conf(5) Seems to me good. Thanks. Wesley. On Sat, 22 Jan 2011 02:33:03 +0100, "Jiri B." wrote: > On Fri, Jan 21, 2011 at 09:32:40PM +0100, Pete Vickers wrote: >>$ pkg_info | grep stunnel >>stunnel-4.20SSL encryption wrapper for standard network daemons >> >>$ grep -A 3 pop3s /etc/stunnel/stunnel.conf >>[pop3s] >>accept = 995 >>connect = 127.0.0.1:110 > > relayd in base can do same as stunnel. > > jirib
Re[3]: match keyword in pf for "no" action
Fri, 21 Jan 2011 23:14:05 +0200 ohq|ln nr Destan YILANCI : Hi, Use quick keyword and pass packets from table to smtp service. At the second rule redirect packets from any source to spamd port. 2011/1/21 pavel pocheptsov I know about changes in PF sintax: ### nat on $ext_if from 10/8 -> ($ext_if) rdr on $ext_if to ($ext_if) -> 1.2.3.4becomes match out on $ext_if from 10/8 nat-to ($ext_if) match in on $ext_if to ($ext_if) rdr-to 1.2.3.4 and all is work fine. but how to use previosly used: "no rdr on $ext_if inet proto tcp from to port smtp" actually how to use "no" key for nat and rdr rules? I do this to connect goodgays directly to sendmail in next pass-rule. So, I need to do this: match in on $ext_if proto tcp from any to $ext_if port smtp rdr-to 127.0.0.1 port spamd pass in quick on $ext_if proto tcp from to $ext_if port smtp instead of pvevios syntax: no rdr on $ext_if inet proto tcp from to $ext_if port smtp rdr on $ext_if inet proto tcp from any to $ext_if port smtp -> 127.0.0.1 port spamd pass on $ext_if inet proto tcp from any to $ext_if proto smtp
