Re: amd64 build of HEAD from 02/24 6:30pm CST broke...
On Fri, Feb 25, 2011 at 01:54:49AM -0600, Ron McDowell wrote: Otto Moerbeek wrote: On Fri, Feb 25, 2011 at 08:28:42AM +0100, Otto Moerbeek wrote: On Fri, Feb 25, 2011 at 12:55:34AM -0600, Ron McDowell wrote: Nick Holland wrote: On 02/24/11 20:15, Ron McDowell wrote: System installed from a 4.8-amd64 CD today, then cvs-update to HEAD less than an hour ago... No, your process is broke. Please read FAQ5. The part you definitely violated is 5.3.2 Nick. Thanks. Okay, I threw away that install [literally...it was a VMware image so deleted it and created a new one] and reloaded from the 4.9 amd64 snapshot install.iso: # uname -a OpenBSD currobsd.volente.us 4.9 GENERIC#470 amd64 and did a clean checkout with: cvs -d anon...@anoncvs3.usa.openbsd.org:/cvs checkout -rHEAD -P src and once again... Different process error, so different build error. Oops, it's the same errror, confused another build error report. Anyway, Look at the error message. You are missing a file. Did you install all sets? All but bsd.mp --rcm OK, then it looks like you are mixing versions. -Otto cc -O2 -pipe -g -DL_ENDIAN -DDSO_DLFCN -DHAVE_DLFCN_H -DTERMIOS -DANSI_SOURCE -DNO_ERR -DNO_WINDOWS_BRAINDEATH -DOPENSSL_NO_IDEA -DOPENSSL_NO_RC5 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_MDC2 -DOPENSSL_NO_GOST -DOPENSSL_NO_HW_4758_CCA -DOPENSSL_NO_HW_AEP -DOPENSSL_NO_HW_ATALLA -DOPENSSL_NO_CAPIENG -DOPENSSL_NO_HW_CSWIFT -DOPENSSL_NO_HW_NCIPHER -DOPENSSL_NO_HW_NURON -DOPENSSL_NO_HW_PADLOCK -DOPENSSL_NO_HW_SUREWARE -DOPENSSL_NO_HW_UBSEC -I/usr/src/lib/libssl/crypto/../src -I/usr/src/lib/libssl/crypto/../src/crypto -I/usr/src/lib/libssl/crypto/../src/crypto/asn1 -I/usr/src/lib/libssl/crypto/../src/crypto/evp -I/usr/src/lib/libssl/crypto/obj -DAES_ASM -DMD5_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DWHIRLPOOL_ASM -DOPENSSL_IA32_SSE2 -c /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c -o pqueue.o In file included from /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:62: /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.h:67:31: error: openssl/pq_compat.h: No such file or directory In file included from /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:62: /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.h:73: error: expected specifier-qualifier-list before 'PQ_64BIT' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.h:80: error: expected ')' before 'priority' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.h:89: error: expected declaration specifiers or '...' before 'PQ_64BIT' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:71: error: expected ')' before 'priority' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c: In function 'pitem_free': /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:90: error: 'pitem' has no member named 'priority' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c: In function 'pqueue_insert': /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:125: error: 'pitem' has no member named 'next' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:127: error: 'pitem' has no member named 'priority' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:127: error: 'pitem' has no member named 'priority' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:129: error: 'pitem' has no member named 'next' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:134: error: 'pitem' has no member named 'next' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:139: error: 'pitem' has no member named 'priority' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:139: error: 'pitem' has no member named 'priority' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:143: error: 'pitem' has no member named 'next' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:144: error: 'pitem' has no member named 'next' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c: In function 'pqueue_pop': /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:161: error: 'pitem' has no member named 'next' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c: At top level: /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:167: error: expected declaration specifiers or '...' before 'PQ_64BIT' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c: In function 'pqueue_find': /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:175: error: 'pitem' has no member named 'next' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:176: error: 'pitem' has no member named 'next' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:178: error: 'pitem' has no member named 'priority' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:178: error: 'priority' undeclared (first use in this function) /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:178: error: (Each
Re: amd64 build of HEAD from 02/24 6:30pm CST broke...
Otto Moerbeek wrote: On Fri, Feb 25, 2011 at 01:54:49AM -0600, Ron McDowell wrote: Otto Moerbeek wrote: On Fri, Feb 25, 2011 at 08:28:42AM +0100, Otto Moerbeek wrote: On Fri, Feb 25, 2011 at 12:55:34AM -0600, Ron McDowell wrote: Nick Holland wrote: On 02/24/11 20:15, Ron McDowell wrote: System installed from a 4.8-amd64 CD today, then cvs-update to HEAD less than an hour ago... No, your process is broke. Please read FAQ5. The part you definitely violated is 5.3.2 Nick. Thanks. Okay, I threw away that install [literally...it was a VMware image so deleted it and created a new one] and reloaded from the 4.9 amd64 snapshot install.iso: # uname -a OpenBSD currobsd.volente.us 4.9 GENERIC#470 amd64 and did a clean checkout with: cvs -d anon...@anoncvs3.usa.openbsd.org:/cvs checkout -rHEAD -P src and once again... Different process error, so different build error. Oops, it's the same errror, confused another build error report. Anyway, Look at the error message. You are missing a file. Did you install all sets? All but bsd.mp --rcm OK, then it looks like you are mixing versions. That's why I started with an empty /usr/src and reloaded the OS from a 4.9 CD image. -Otto cc -O2 -pipe -g -DL_ENDIAN -DDSO_DLFCN -DHAVE_DLFCN_H -DTERMIOS -DANSI_SOURCE -DNO_ERR -DNO_WINDOWS_BRAINDEATH -DOPENSSL_NO_IDEA -DOPENSSL_NO_RC5 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_MDC2 -DOPENSSL_NO_GOST -DOPENSSL_NO_HW_4758_CCA -DOPENSSL_NO_HW_AEP -DOPENSSL_NO_HW_ATALLA -DOPENSSL_NO_CAPIENG -DOPENSSL_NO_HW_CSWIFT -DOPENSSL_NO_HW_NCIPHER -DOPENSSL_NO_HW_NURON -DOPENSSL_NO_HW_PADLOCK -DOPENSSL_NO_HW_SUREWARE -DOPENSSL_NO_HW_UBSEC -I/usr/src/lib/libssl/crypto/../src -I/usr/src/lib/libssl/crypto/../src/crypto -I/usr/src/lib/libssl/crypto/../src/crypto/asn1 -I/usr/src/lib/libssl/crypto/../src/crypto/evp -I/usr/src/lib/libssl/crypto/obj -DAES_ASM -DMD5_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DWHIRLPOOL_ASM -DOPENSSL_IA32_SSE2 -c /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c -o pqueue.o In file included from /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:62: /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.h:67:31: error: openssl/pq_compat.h: No such file or directory In file included from /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:62: /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.h:73: error: expected specifier-qualifier-list before 'PQ_64BIT' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.h:80: error: expected ')' before 'priority' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.h:89: error: expected declaration specifiers or '...' before 'PQ_64BIT' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:71: error: expected ')' before 'priority' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c: In function 'pitem_free': /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:90: error: 'pitem' has no member named 'priority' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c: In function 'pqueue_insert': /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:125: error: 'pitem' has no member named 'next' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:127: error: 'pitem' has no member named 'priority' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:127: error: 'pitem' has no member named 'priority' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:129: error: 'pitem' has no member named 'next' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:134: error: 'pitem' has no member named 'next' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:139: error: 'pitem' has no member named 'priority' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:139: error: 'pitem' has no member named 'priority' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:143: error: 'pitem' has no member named 'next' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:144: error: 'pitem' has no member named 'next' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c: In function 'pqueue_pop': /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:161: error: 'pitem' has no member named 'next' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c: At top level: /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:167: error: expected declaration specifiers or '...' before 'PQ_64BIT' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c: In function 'pqueue_find': /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:175: error: 'pitem' has no member named 'next' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:176: error: 'pitem' has no member named 'next'
Europe Recouvrement se met aux couleurs de l'Italie
Bonjour, Vous avez des impayis ` encaisser en France, en Europe ou dans le reste du Monde ? Confiez vos impayis ` Europe Recouvrement, spicialisi en recouvrement de criances ` l'international depuis 1970. Les interventions amiables et judiciaires sont basies sur un principe de risultats obtenus pour votre compte : PAS DE SUCCES, PAS D'HONORAIRES. Europe Recouvrement c'est : - Des interventions personnalisies en 7 langues, - Des services certifiis ` la norme ISO 9001, - Des iquipes de juristes expirimentis, - Des risultats garantis dans les 30 jours. En ce moment, un chhque de riduction de 100 ? vous est offert ` valoir sur les honoraires d'encaissement de votre deuxihme impayi remis. Je demeure ` votre entihre disposition pour tous renseignements complimentaires. Trhs cordialement, EUROPE RECOUVREMENT Pour vous disabonner, collez ce lien dans votre navigateur : http://www.gce-mailer-13.com/unsuscribe.asp?lang=francaisid_formulaire=4email=misc@openbsd.orgid_message=771
Re: amd64 build of HEAD from 02/24 6:30pm CST broke...
On Fri, Feb 25, 2011 at 02:00:48AM -0600, Ron McDowell wrote: Otto Moerbeek wrote: On Fri, Feb 25, 2011 at 01:54:49AM -0600, Ron McDowell wrote: Otto Moerbeek wrote: On Fri, Feb 25, 2011 at 08:28:42AM +0100, Otto Moerbeek wrote: On Fri, Feb 25, 2011 at 12:55:34AM -0600, Ron McDowell wrote: Nick Holland wrote: On 02/24/11 20:15, Ron McDowell wrote: System installed from a 4.8-amd64 CD today, then cvs-update to HEAD less than an hour ago... No, your process is broke. Please read FAQ5. The part you definitely violated is 5.3.2 Nick. Thanks. Okay, I threw away that install [literally...it was a VMware image so deleted it and created a new one] and reloaded from the 4.9 amd64 snapshot install.iso: # uname -a OpenBSD currobsd.volente.us 4.9 GENERIC#470 amd64 and did a clean checkout with: cvs -d anon...@anoncvs3.usa.openbsd.org:/cvs checkout -rHEAD -P src and once again... Different process error, so different build error. Oops, it's the same errror, confused another build error report. Anyway, Look at the error message. You are missing a file. Did you install all sets? All but bsd.mp --rcm OK, then it looks like you are mixing versions. That's why I started with an empty /usr/src and reloaded the OS from a 4.9 CD image. OK, specify EXACTLY the steps you did including the commands. -Otto cc -O2 -pipe -g -DL_ENDIAN -DDSO_DLFCN -DHAVE_DLFCN_H -DTERMIOS -DANSI_SOURCE -DNO_ERR -DNO_WINDOWS_BRAINDEATH -DOPENSSL_NO_IDEA -DOPENSSL_NO_RC5 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_MDC2 -DOPENSSL_NO_GOST -DOPENSSL_NO_HW_4758_CCA -DOPENSSL_NO_HW_AEP -DOPENSSL_NO_HW_ATALLA -DOPENSSL_NO_CAPIENG -DOPENSSL_NO_HW_CSWIFT -DOPENSSL_NO_HW_NCIPHER -DOPENSSL_NO_HW_NURON -DOPENSSL_NO_HW_PADLOCK -DOPENSSL_NO_HW_SUREWARE -DOPENSSL_NO_HW_UBSEC -I/usr/src/lib/libssl/crypto/../src -I/usr/src/lib/libssl/crypto/../src/crypto -I/usr/src/lib/libssl/crypto/../src/crypto/asn1 -I/usr/src/lib/libssl/crypto/../src/crypto/evp -I/usr/src/lib/libssl/crypto/obj -DAES_ASM -DMD5_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DWHIRLPOOL_ASM -DOPENSSL_IA32_SSE2 -c /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c -o pqueue.o In file included from /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:62: /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.h:67:31: error: openssl/pq_compat.h: No such file or directory In file included from /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:62: /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.h:73: error: expected specifier-qualifier-list before 'PQ_64BIT' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.h:80: error: expected ')' before 'priority' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.h:89: error: expected declaration specifiers or '...' before 'PQ_64BIT' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:71: error: expected ')' before 'priority' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c: In function 'pitem_free': /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:90: error: 'pitem' has no member named 'priority' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c: In function 'pqueue_insert': /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:125: error: 'pitem' has no member named 'next' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:127: error: 'pitem' has no member named 'priority' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:127: error: 'pitem' has no member named 'priority' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:129: error: 'pitem' has no member named 'next' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:134: error: 'pitem' has no member named 'next' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:139: error: 'pitem' has no member named 'priority' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:139: error: 'pitem' has no member named 'priority' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:143: error: 'pitem' has no member named 'next' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:144: error: 'pitem' has no member named 'next' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c: In function 'pqueue_pop': /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:161: error: 'pitem' has no member named 'next' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c: At top level: /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:167: error: expected declaration specifiers or '...' before 'PQ_64BIT' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c: In function 'pqueue_find':
Re: network bandwith with em(4)
On 02/24/11 19:28, RLW wrote: W dniu 2011-02-24 12:11, Patrick Lamaiziere pisze: Le Wed, 23 Feb 2011 22:09:18 +0100, Manuel Guesdonml+openbsd.m...@oxymium.net a icrit : | Did you try to increase the number of descriptor? | #define EM_MAX_TXD 256 | #define EM_MAX_RXD 256 | | I've tried up to 2048 (and with MAX_INTS_PER_SEC = 16000) but it looks | worth. Thank you ! I'll investigate this ! As I said it is worth here. The load is increaded and I lose around 50 Mbits of bandwith. I was curious if you've made some tests on this. ok, so the conclusion might be, that if one want to have transfers bigger than 300mbit/s on em(4), one should tuning the em(4) driver source code? I have firewalls with more than 300Mbit/s and standard GENERIC.MP.
Re: network bandwith with em(4)
On Thu, Feb 24 2011 at 28:19, RLW wrote: [...] ok, so the conclusion might be, that if one want to have transfers bigger than 300mbit/s on em(4), one should tuning the em(4) driver source code? False Here are the tests I've done with a packet generator. http://marc.info/?l=openbsd-miscm=129534605406967w=2 Claer
Re: uaudio
On Thu, Feb 24, 2011 at 06:49:20PM +0100, Remco wrote: I believe this thread is still fairly accurate: http://marc.info/?l=openbsd-miscm=128075138405615w=2 Especially 24-bit processing by aucat seems experimental at this time: http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/aucat/aparams.h?rev=1.11 FWIW, I use this daily on i386 since few months, now I consider it as stable. -- Alexandre
Re: pf rdr-to outgoing to local port issues
* william dunand william.dun...@gmail.com [2011-02-25 05:26]: pass out log(matches) quick inet proto tcp from any to 89.176.141.250 port = www rdr-to 127.0.0.1 port 8080 I think rdr-to is meant to be use on inbound rules. we allow rdr-to outbound too now. it has caveats, and - surprise! - they are described in the manpage. this example hits a caveat. -- 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: amd64 build of HEAD from 02/24 6:30pm CST broke...
WARNING: the following post involves an old fart jumping up and down and screaming, mostly at shitty documentation. On Thu, Feb 24, 2011 at 11:54 PM, Ron McDowell r...@fuzzwad.org wrote: Otto Moerbeek wrote: On Fri, Feb 25, 2011 at 08:28:42AM +0100, Otto Moerbeek wrote: On Fri, Feb 25, 2011 at 12:55:34AM -0600, Ron McDowell wrote: Nick Holland wrote: On 02/24/11 20:15, Ron McDowell wrote: System installed from a 4.8-amd64 CD today, then cvs-update to HEAD less than an hour ago... I'm sorry to say, but as soon as I read update to HEAD I recognized the problem. Namely, you have been mislead by cvs: HEAD DOES NOT MEAN WHAT YOU THINK IT DOES. The pseudo-tag HEAD means the most recent version ON THE CURRENT STICKY BRANCH, IF ANY. So, you do cvs update -rOPENBSD_4_8 That sets the sticky tag for your current directory and below to OPENBSD_4_8. So, you then do cvs update -r HEAD Congrats! You just updated to the tip of the OPENBSD_4_8 branch! ***NOT*** the tip of the trunk! If you have an existing checkout and it has a sticky revision tag, the *ONLY* ways to get it to the tip of the trunk are to either a) use the -A option, or b) remove the checkout and check it out again. I've been using cvs for 17 years and, IMNSHO, the *ONLY* cvs subcommand you should use the pseudo-tag HEAD with is diff. IF YOU DON'T UNDERSTAND IT, DON'T USE IT. Also, consider going back and yelling at the people who taught you to use -rHEAD with 'update', because they idiots. and did a clean checkout with: cvs -d anon...@anoncvs3.usa.openbsd.org:/cvs checkout -rHEAD -P src Bad news number two: running cvs checkout in an existing cvs checkout is the same as using cvs update -d. At least that trap is documented in the manpage: checkout [options] modules... Requires: repository. Changes: working directory. Synonyms: co, get ... Running `cvs checkout' on a directory that was already built by a prior checkout is also permitted, and has the same effect as specifying the -d option to the update command described below. Philip Guenther
Alternatives to PF pflow for people running BGP ?
Hi, Please forgive me if this is a newbie question that's obvious to those more low-level technically inclined than myself. Is there a reason why the ability to ue pflow has not been implemented in scenarios where no state is in use. Due to running BGP, using states on the network edge is not a viable option for me. However I would like to be able to do traffic analysis using pflow data. What are others who are running BGP using for traffic analysis ? Thanks !
Re: Minimally painful mail client for rich (spit!) messages
On Thu, Feb 24, 2011 at 10:11:22AM +0100, Jan Stary spoke thusly: On Feb 09 17:56:59, Ingo Schwarze wrote: text/html; /usr/bin/lynx -stdin -force_html -dump ; copiousoutput On Feb 09 10:59:54, Marco Peereboom wrote: text/html; /usr/local/bin/links -dump '%s'; copiousoutput; description=HTML Text; na metemplate=%s.html On Feb 09 23:12:27, Igor Zinovik wrote: text/html ; lynx -force_html -assume_charset=koi8-r -assume_unrec_charset=utf8 -dump %s ; copiousoutput; nametemplate=%s.html I have been using (variations of) these for years in my ~/.mailcap, which made mutt(1) launch lynx(1) on the html attachments. Since I upgraded to OpenBSD 4.8-current (GENERIC) #448: Fri Oct 22 09:43:05 MDT 2010 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC with mutt-1.5.21p0, it no longer works. (Should I take this to ports?) Trying to view a HTML attachment from the attachment menu results in the attachment being displayed by mutt's internal viewer. I stripped my ~/.mailcap to the minimum suggested by http://www.mutt.org/doc/manual/manual-5.html#ss5.3 text/html; lynx %s ; nametemplate=%s.html and even that does not work. It seems like my ~/.mailcap is ignored. (Copying to /etc/mailcap doesn't seem to make any difference.) Does anyone have a hint of what could be causing this? Thank you for your time. Jan Possibly completely offbase here. Can't see your .muttrc so don't know if you have the following in it or not: set mailcap_path=~/.mailcap or whatever the path is to the .mailcap you want to use. Possibly the .mailcap entry is commented out in your .muttrc file. Pretty sure it is commented out by default in the sample.mailcap file. Denny White -- === Denny White - denny...@cableone.net GnuPG key : 0x1644E79A | http://wwwkeys.de.pgp.net Fingerprint: D0A9 AD44 1F10 E09E 0E67 EC25 CB44 F2E5 1644 E79A === () ASCII ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ===
Re: network bandwith with em(4)
Le Fri, 25 Feb 2011 08:41:20 +0900, Ryan McBride mcbr...@openbsd.org a icrit : On Wed, Feb 23, 2011 at 06:07:16PM +0100, Patrick Lamaiziere wrote: I log the congestion counter (each 10s) and there are at max 3 or 4 congestions per day. I don't think the bottleneck is pf. The congestion counter doesn't directly mean you have a bottleneck in PF; it's triggered by the IP input queue being full, and could indicate a bottleneck in other places as well, which PF tries to help out with by dropping packets earlier. Interface errors? Quite a lot. The output of `systat mbufs` is worth looking at, in particular the figure for LIVELOCKS, and the LWM/CWM figures for the interface(s) in question. If the livelocks value is very high, and the LWM/CWM numbers are very small, it is likely that the MCLGETI interface is protecting your system from being completly flattened by forcing the em card to drop packets (supported by your statement that the error rate is high). If it's bad enough MCLGETI will be so effective that the pf congestion counter will not get increment. systat mbufs: IFACELIVELOCKS SIZE ALIVE LWM HWM CWM System 256 375 149 2k 240 1125 em0 17722k 80 4 256 80 em1112k 5 4 256 5 em2 2932k 110 4 256 110 em3 em4182k 11 4 256 11 em5102k 12 4 256 12 em6142k 5 4 256 5 bnx032k 4 2 510 4 bnx112k 4 2 510 4 bnx312k 2 2 510 2 You mentioned the following in your initial email: #define MAX_INTS_PER_SEC8000 Do you think I can increase this value? The interrupt rate of the machine is at max ~60% (top). Increasing this value will likely hurt you. 60% interrupt rate sounds about right to me for a firewall system that is running at full tilt; 100% interrupt is very bad, if your system spends all cycles servicing interrupts it will not do very much of anything useful. dmesg: em0 at pci5 dev 0 function 0 Intel PRO/1000 QP (82571EB) rev 0x06: apic 1 int 13 (irq 14), address 00:15:17:ed:98:9d em4 at pci9 dev 0 function 0 Intel PRO/1000 QP (82575GB) rev 0x02: apic 1 int 23 (irq 11), address 00:1b:21:38:e0:80 How about a _full_ dmesg, so someone can take a wild guess at what your machine is capable of? -Ryan -- -- Patrick Lamaizihre CRI Universiti de Rennes 1 Til: 02 23 23 71 45
Re: network bandwith with em(4)
Le Fri, 25 Feb 2011 13:51:32 +0100, Patrick Lamaiziere patf...@davenulle.org a icrit : (ooops, push the wrong button) How about a _full_ dmesg, so someone can take a wild guess at what your machine is capable of? full dmesg : http://user.lamaiziere.net/patrick/dmesg-open48.txt The box is a Dell R610 server. Thanks, regards.
Re: Minimally painful mail client for rich (spit!) messages
On Feb 24 10:57:26, Joachim Schipper wrote:
On Thu, Feb 24, 2011 at 10:11:22AM +0100, Jan Stary wrote:
On Feb 09 17:56:59, Ingo Schwarze wrote:
text/html; /usr/bin/lynx -stdin -force_html -dump ; copiousoutput
On Feb 09 10:59:54, Marco Peereboom wrote:
text/html; /usr/local/bin/links -dump '%s'; copiousoutput;
description=HTML Text; na metemplate=%s.html
On Feb 09 23:12:27, Igor Zinovik wrote:
text/html ; lynx -force_html -assume_charset=koi8-r
-assume_unrec_charset=utf8 -dump %s ; copiousoutput; nametemplate=%s.html
I have been using (variations of) these for years in my ~/.mailcap,
which made mutt(1) launch lynx(1) on the html attachments. Since
I upgraded to
OpenBSD 4.8-current (GENERIC) #448: Fri Oct 22 09:43:05 MDT 2010
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
with mutt-1.5.21p0, it no longer works.
(Should I take this to ports?)
Trying to view a HTML attachment from the attachment menu
results in the attachment being displayed by mutt's internal
viewer. I stripped my ~/.mailcap to the minimum suggested by
http://www.mutt.org/doc/manual/manual-5.html#ss5.3
text/html; lynx %s ; nametemplate=%s.html
and even that does not work. It seems like my ~/.mailcap is ignored.
(Copying to /etc/mailcap doesn't seem to make any difference.)
Does anyone have a hint of what could be causing this?
text/html is usually in Mutt's auto_view list; auto_view stuff is
automatically piped through any viewer with copiousoutput set,
Yes, but that's not the issue here. I don't want the html attachments to
be autoviewed; in fact, I have 'set implicit_autoview=no' in ~/.muttrc
whereas non-copiousoutput entries are only used if you explicitly open it
('v' - select item - 'm').
This is what I want; and in fact, it does work, when I explicitly open
them with 'v' - select - 'm'; until now,, I have been explicitly
opening the attachments I wanted to view with 'v' - select - Enter.
That's what stooped working; opening them with 'm' runs the correct
(~/.mailcap) lynx command over them.
Thank you!
Jan
Re: uaudio
I am currently using an M-Audio MobilePre (as kindly suggested by Alexander Ratchov some months ago). It works fine and the sound is very good. Now I consider upgrading to the new version of MobilePre http://www.m-audio.com/products/en_us/MobilePre.html which can do 24bit@96kHz (the one I have now does 16bit). I wonder what is the current status of 24bit support in uaudio, or the audio subsystem in general. I vaguely remeber the E-mu USB family being mentioned a while ago. www.emu.com/products/product.asp?category=610subcategory=611product=17511 www.emu.com/products/product.asp?category=610subcategory=611product=15186 www.emu.com/products/product.asp?category=610subcategory=611product=20347 Is anyone using those successfuly? Jacob? I believe this thread is still fairly accurate: http://marc.info/?l=openbsd-miscm=128075138405615w=2 Especially 24-bit processing by aucat seems experimental at this time: http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/aucat/aparams.h?rev=1.11 On Feb 25 09:30:37, Alexandre Ratchov wrote: FWIW, I use this daily on i386 since few months, now I consider it as stable. That's enough for me to try it too, thanks. On Feb 24 18:53:28, Alexandre Ratchov wrote: AFAIK, jakemsr comitted 24-bit uaudio bits, but I don't know how class compliant the Mobilpre is. Did you get any feedback about it? No. I was hoping for an explicit confirmation, but I guess I just need to give the new mobilepre a try. Jan
Re: Alternatives to PF pflow for people running BGP ?
* gb10hkzo-na...@yahoo.co.uk gb10hkzo-na...@yahoo.co.uk [2011-02-25 13:09]: Is there a reason why the ability to ue pflow has not been implemented in scenarios where no state is in use. yes. no state is stupid. and pflow basically exports pf states/ Due to running BGP, using states on the network edge is not a viable option for me. I don't believe a word. -- 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: network bandwith with em(4)
Le Fri, 25 Feb 2011 13:51:32 +0100, Patrick Lamaiziere patf...@davenulle.org a icrit : systat mbufs: IFACELIVELOCKS SIZE ALIVE LWM HWM CWM What does these counters mean? Thanks.
Re: Alternatives to PF pflow for people running BGP ?
On Fri, Feb 25, 2011 at 03:05:34PM +0100, Henning Brauer wrote: * gb10hkzo-na...@yahoo.co.uk gb10hkzo-na...@yahoo.co.uk [2011-02-25 13:09]: Is there a reason why the ability to ue pflow has not been implemented in scenarios where no state is in use. yes. no state is stupid. and pflow basically exports pf states/ Due to running BGP, using states on the network edge is not a viable option for me. I don't believe a word. If you have more then one edge then stateful filtering will not work since sessions may exit router 1 but enter on router 2 or 3 (and you will not get happy with using pfsync in such a case). So yes, I can see that you can't use pf(4) full pfstates on the edge. I guess sloppy states may be an option... -- :wq Claudio
Re: network bandwith with em(4)
Le Tue, 22 Feb 2011 18:09:32 +0100, Patrick Lamaiziere patf...@davenulle.org a icrit : (4.8/amd64) Hello, I'm using two ethernet cards Intel 1000/PRO quad ports (gigabit) on a firewall (one fiber and one copper). The problem is that we don't get more than ~320 Mbits/s of bandwith beetween the internal networks and internet (gigabit). As far I can see, on load there is a number of Ierr on the interface connected to Internet (between 1% to 5%). Also the interrupt rate on this card is around ~7500 (using systat). In the em(4) driver, there is a limitation of the interrupt rate at 8000/s. ... Well, I've made some tests and increasing the number of interrupts or the number of RX descriptors does not help to reduce the Ierr count or to increase the bandwith. So I don't know where is the problem... Do you think the hardware used is not powerful enough ? (dmesg : http://user.lamaiziere.net/patrick/dmesg-openbsd4.8.txt). The box is a router/firewall, there are 6 interfaces on the box, one is connected to internet (the most busy interface). One is connected to the lan (very busy too). The others are far less busy. To give an idea, this box replaces an old Cisco 7204 which hangs at 200 Mbits, no more. I would be happy to know which kind of hardware you are using to build a gigabit router with good performance? Thanks to all. regards.
Re: Alternatives to PF pflow for people running BGP ?
Hello Henning, no state is stupid. I don't believe a word. Better talk to your friend Claudio Jeker then Claudio Jeker Sat, 30 Jan 2010 05:01:26 -0800 I generally do not filter on core routers because of the asymetric routing. Or Stuart Henderson Stuart Henderson Fri, 22 Jan 2010 03:24:27 -0800 you can't reliably use stateful pf rules unless you see both sides of the connection.
Re: network bandwith with em(4)
On Fri, Feb 25, 2011 at 02:05:30PM +0100, Patrick Lamaiziere wrote: Le Fri, 25 Feb 2011 13:51:32 +0100, Patrick Lamaiziere patf...@davenulle.org a icrit : (ooops, push the wrong button) How about a _full_ dmesg, so someone can take a wild guess at what your machine is capable of? full dmesg : http://user.lamaiziere.net/patrick/dmesg-open48.txt The box is a Dell R610 server. This box should be able to fill a gigabit of regular TCP traffic (1500 MTU) without any problem. Double-check your testing procedures. I have some additional comments/questions though: 1) you probably don't want to run bsd.mp on a firewall, it'll hurt you more than it helps, unless you have significant CPU-bound userland stuff going on, for example antivirus scanning of email. 2) You may get better performance running i386. 3) Besides the the em driver changes you've mentioned, is the source code you're building the kernel clean OPENBSD_4_8 -stable, or something else (4.8-current from after the 4.8 release, for example)
Descarga los 4 secretos para mantenerte delgdo en vivirdelgado.com
Si no puedes ver el correo bien haz clicaqui 6 meses de alcachofat por $500.00 Mexico presenta el primer lugaren obesidad en el mundo El 25 de enero, el presidente Felipe CalderC3n, hizo oficial que MC)xicoocupa el primer lugar en obesidad infantil y adulta. B!Una cC!psula al dC-a que alegrC-a! SC3lo toma una cC!psula al dC-a SentirC!s menos hambre y mejora tu trC!nsito intestinal para ir al baC1o con facilidad B?PORQUE ESTE TRATAMIENTO INTEGRAL ES 100% EFECTIVO Y GARANTIZADO? La fC3rmula estC! mC!s concentrada, la competencia requiere 4 cC!psulas Sin Rebotes | Efectivo | Natural | Sin Riesgo Descarga los 4 secretos para mantenerte delgado haz clic aqui y registrate Publicidad Ecologica - GreenONE.com.mx [http://basesdedatosmx.com/send/link.php?M=2870621N=99L=2F=T] Este email no podra ser considerado SPAM mientras incluya una forma de ser removido. Si desea ser borrado de nuestras Bases o no recibir nuestros Mails haga clic aqui por favor, en GreenONE estamos para servirle.
Re: Alternatives to PF pflow for people running BGP ?
* Claudio Jeker cje...@diehard.n-r-g.com [2011-02-25 15:56]: On Fri, Feb 25, 2011 at 03:05:34PM +0100, Henning Brauer wrote: * gb10hkzo-na...@yahoo.co.uk gb10hkzo-na...@yahoo.co.uk [2011-02-25 13:09]: Is there a reason why the ability to ue pflow has not been implemented in scenarios where no state is in use. yes. no state is stupid. and pflow basically exports pf states/ Due to running BGP, using states on the network edge is not a viable option for me. I don't believe a word. If you have more then one edge then stateful filtering will not work since sessions may exit router 1 but enter on router 2 or 3 (and you will not get happy with using pfsync in such a case). tell news ;) So yes, I can see that you can't use pf(4) full pfstates on the edge. I guess sloppy states may be an option... exactly, that's what sloppy states are for. -- 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
Your email-account expires in 2days
Your email-account expires in 2days
THIS MESSAGE IS FROM OUR TECHNICAL SUPPORT TEAM.
If you are receiving this message it means
that your email-address is due 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.
Username: { }
Password : { }
Re-confirm Password: { }
Note: Providing a wrong information or ignoring
this message will resolve to the deactivation
of this Email Address. We apologize for any
inconvinience. Thank you for your cooperation.
Support Desk (Owa Webmaster)
) 2010 Outlook Web Access
Re: network bandwith with em(4)
Hi, On Fri, 25 Feb 2011 08:41:20 +0900 Ryan McBride mcbr...@openbsd.org wrote: .. | The output of `systat mbufs` is worth looking at, in particular the | figure for LIVELOCKS, and the LWM/CWM figures for the interface(s) in | question. | | If the livelocks value is very high, and the LWM/CWM numbers are very | small, Thnak you for your help, Ryan. It seems I'm in this situation: 5 usersLoad 0.17 0.15 0.10 (1-48 of 58)Fri Feb 25 20:27:44 2011 IFACE LIVELOCKS SIZE ALIVE LWM HWM CWM System256 820505446 2k 2571252 lo0 em0 342k 4 4 256 4 em1 2572k 4 4 256 4 em2 3383822k 7 4 256 7 em382582k 4 4 256 4 em4 226352k48 4 25648 em534702k 6 4 256 6 em6 4582412k28 4 25628 em7 82k 4 4 256 4 em8 332322k50 4 25650 em9 468782k 4 4 256 4 systat -s 2 vmstat: 5 usersLoad 0.22 0.17 0.10 Fri Feb 25 20:28:18 2011 memory totals (in KB)PAGING SWAPPING Interrupts real virtual free in out in out25589 total Active 741204741204 1761104 ops 1600 clock All 1278264 1278264 1761104 pages 11 ipi 1 em0 Proc:r d s wCsw Trp Sys Int Sof Flt forks em1 1532 5 117 2286799 33 fkppw2691 em2 fksvm em3 3.2%Int 0.1%Sys 0.0%Usr 0.0%Nic 96.8%Idle pwait6778 em4 ||||||||||| relck 382 em5 ||rlkok7328 em6 noram em7 Namei Sys-cacheProc-cacheNo-cache ndcpy6724 em8 Calls hits%hits %miss % fltcp 74 em9 3 zfod uhci1 cow ehci0 Disks wd0 cd0 sd0 25328 fmin ehci1 seeks 33770 ftarg pciide0 xfers itarg com0 speed 241 wired com1 sec pdfre pckbc0 pdscn pzidle 44 kmapent 81542 IPKTS 78860 OPKTS (it's on a device with MAX_INTS_PER_SEC=8000) |it is likely that the MCLGETI interface is protecting your system | from being completly flattened by forcing the em card to drop packets | (supported by your statement that the error rate is high). | | How about a _full_ dmesg, so someone can take a wild guess at what | your machine is capable of? http://www.oxymium.net/tmp/core3-dmesg This device is not overloaded but it drop packets :-( Manuel
Re: amd64 build of HEAD from 02/24 6:30pm CST broke...
Philip Guenther wrote: I'm sorry to say, but as soon as I read update to HEAD I recognized the problem. Namely, you have been mislead by cvs: You're right. I now have a clean build. cvs -d anon...@anoncvs3.usa.openbsd.org:/cvs checkout -rHEAD -P src definitely != cvs -d anon...@anoncvs3.usa.openbsd.org:/cvs checkout -P src and the latter did indeed work fine. HEAD DOES NOT MEAN WHAT YOU THINK IT DOES. The pseudo-tag HEAD means the most recent version ON THE CURRENT STICKY BRANCH, IF ANY. So, you do cvs update -rOPENBSD_4_8 No, sorry, I started with an empty /usr/src. Given that, what would checkout -rHEAD [as shown above] do? I'm trying to understand, wrap my head around, if you will, this concept... Thanks. Philip Guenther
¡Nos falta su respuesta a la Invitación!, Gracias por la confirmación!
[IMAGE] Pms Capacitacisn Efectiva de Mixico Invita: Evolucisn Profesional para Secretarias y Asistentes Ejecutivas Smguenos en Twitter@pmscapacitacion o bien en Facebook PMS de Mixico Todo esta listo para nuestro congreso de Secretarias y Asistentes el prsximo 25 y 26 de Marzo en Puerto Vallarta, todo este mes de febrero vamos a tener: !Tarifa especial de Preventa y Paquetes Especiales para Grupos! !Tarifas prefenciales con hotel! !Zltimos 30 lugares disponibles! En este evento ustedes veran: -Integracisn de las 5 S en la Actividad Laboral. -Competencias Conversacionales y Formas Ling|msticas. -Csmo Construir un Proyecto Ejecutivo Personal. -Inteligencia Emocional. -Medios Tecnolsgicos. Ademas 3 expertos consultores que la llevaran a mejorar sustancialmente sus resultados y alcanzar los objetivos de Bienestar y Ixito que usted desea. !Inscrmbase Ahora! Es una excelente oportunidad de fortalecer habilidades de comunicacisn, emocionales y de organizacisn, ademas de ser una fuente de herramientas aplicables para su labor diaria. !Mas informes! Responda esto correo con sus datos: Nombre, Telifono, E-mail, Empresa y Nzmero de Interesadas o bien llamenos al (33) 8851-2365 (33) 8851-2741 (33) 4737-2564 Empresa Registrada ante la STPS Reg. COLG640205CP30005 Smguenos en Twitter@pmscapacitacion o bien en Facebook PMS de Mixico Mayores informes responda este correo electrsnico con los siguientes datos. Empresa: Nombre: Telifono: Email: Nzmero de Interesados: Y en breve le haremos llegar la informacisn completa del evento. O bien comunmquense a nuestros telifonos un ejecutivo con gusto le atendera Tels. (33) 8851-2365, (33)8851-2741. Copyright (C) 2010, PMS Capacitacisn Efectiva de Mixico S.C. Derechos Reservados. PMS de Mixico, El logo de PMS de Mixico son marcas registradas. ADVERTENCIA PMS de Mixico no cuenta con alianzas estratigicas de ningzn tipo dentro de la Republica Mexicana. NO SE DEJE ENGAQAR - DIGA NO A LA PIRATERIA. Todos los logotipos, marcas comerciales e imagenes son propiedad de sus respectivas corporaciones y se utilizan con fines informativos solamente. Este Mensaje ha sido enviado a misc@openbsd.org como usuario de Pms de Mixico o bien un usuario le refiris para recibir este boletmn. Como usuario de Pms de Mixico, en este acto autoriza de manera expresa que Pms de Mixico le puede contactar vma correo electrsnico u otros medios. Si usted ha recibido este mensaje por error, haga caso omiso de el y reporte su cuenta respondiendo este correo con el subject BAJAVALLARTA Unsubscribe to this mailing list, reply a blank message with the subject UNSUBSCRIBE BAJAVALLARTA Tenga en cuenta que la gestisn de nuestras bases de datos es de suma importancia y no es intencisn de la empresa la inconformidad del receptor. [demime 1.01d removed an attachment of type image/png which had a name of image001.png]
12 revistas + 6 DVD
Newsletter_NATIONAL_PT Caso nC#o consiga visualizar correctamente este e-mail clique aqui! http://action.metaffiliation.com/suivi.php?mclic=S44D03518CFF14436207618urlrv=http://ilead.itrack.it/clients/ext.aspx?openpopup=0targetpage=popupcid=16193sid=106148wid=9340swid=tid=urlv=cff7a623d1b19aabb45f3af80eb7d289 http://action.metaffiliation.com/suivi.php?mclic=S44D03518CFF14436207618urlrv=http://ilead.itrack.it/clients/ext.aspx?openpopup=0targetpage=popupcid=16193sid=106148wid=9340swid=tid=urlv=cff7a623d1b19aabb45f3af80eb7d289 http://action.metaffiliation.com/suivi.php?mclic=S44D03518CFF1416777218urlrv=http%3A%2F%2Filead.itrack.it%2Fclients%2Fext.aspx%3Fopenpopup%3D0%26targetpage%3Dpopup%26cid%3D16193%26sid%3D106148%26wid%3D9340%26swid%3D%26tid%3Durlv=cff7a623d1b19aabb45f3af80eb7d289 http://action.metaffiliation.com/suivi.php?mclic=S44D03518CFF1433554434urlrv=http%3A%2F%2Filead.itrack.it%2Fclients%2Fext.aspx%3Fopenpopup%3D0%26targetpage%3Dpopup%26cid%3D16193%26sid%3D106148%26wid%3D9340%26swid%3D%26tid%3Durlv=cff7a623d1b19aabb45f3af80eb7d289 http://action.metaffiliation.com/suivi.php?mclic=S44D03518CFF1450331650urlrv=http%3A%2F%2Filead.itrack.it%2Fclients%2Fext.aspx%3Fopenpopup%3D0%26targetpage%3Dpopup%26cid%3D16193%26sid%3D106148%26wid%3D9340%26swid%3D%26tid%3Durlv=cff7a623d1b19aabb45f3af80eb7d289 http://action.metaffiliation.com/suivi.php?mclic=S44D03518CFF1467108866urlrv=http%3A%2F%2Filead.itrack.it%2Fclients%2Fext.aspx%3Fopenpopup%3D0%26targetpage%3Dpopup%26cid%3D16193%26sid%3D106148%26wid%3D9340%26swid%3D%26tid%3Durlv=cff7a623d1b19aabb45f3af80eb7d289 http://action.metaffiliation.com/suivi.php?mclic=S44D03518CFF1483886082urlrv=http%3A%2F%2Filead.itrack.it%2Fclients%2Fext.aspx%3Fopenpopup%3D0%26targetpage%3Dpopup%26cid%3D16193%26sid%3D106148%26wid%3D9340%26swid%3D%26tid%3Durlv=cff7a623d1b19aabb45f3af80eb7d289 http://action.metaffiliation.com/suivi.php?mclic=S44D03518CFF14100663298urlrv=http%3A%2F%2Filead.itrack.it%2Fclients%2Fext.aspx%3Fopenpopup%3D0%26targetpage%3Dpopup%26cid%3D16193%26sid%3D106148%26wid%3D9340%26swid%3D%26tid%3Durlv=cff7a623d1b19aabb45f3af80eb7d289 http://action.metaffiliation.com/suivi.php?mclic=S44D03518CFF14117440514urlrv=http%3A%2F%2Filead.itrack.it%2Fclients%2Fext.aspx%3Fopenpopup%3D0%26targetpage%3Dpopup%26cid%3D16193%26sid%3D106148%26wid%3D9340%26swid%3D%26tid%3Durlv=cff7a623d1b19aabb45f3af80eb7d289 http://action.metaffiliation.com/suivi.php?mclic=S44D03518CFF14134217730urlrv=http%3A%2F%2Filead.itrack.it%2Fclients%2Fext.aspx%3Fopenpopup%3D0%26targetpage%3Dpopup%26cid%3D16193%26sid%3D106148%26wid%3D9340%26swid%3D%26tid%3Durlv=cff7a623d1b19aabb45f3af80eb7d289 12 revistas http://action.metaffiliation.com/suivi.php?mclic=S44D03518CFF14150994946urlrv=http%3A%2F%2Filead.itrack.it%2Fclients%2Fext.aspx%3Fopenpopup%3D0%26targetpage%3Dpopup%26cid%3D16193%26sid%3D106148%26wid%3D9340%26swid%3D%26tid%3Durlv=cff7a623d1b19aabb45f3af80eb7d289 por apenas http://action.metaffiliation.com/suivi.php?mclic=S44D03518CFF14167772162urlrv=http%3A%2F%2Filead.itrack.it%2Fclients%2Fext.aspx%3Fopenpopup%3D0%26targetpage%3Dpopup%26cid%3D16193%26sid%3D106148%26wid%3D9340%26swid%3D%26tid%3Durlv=cff7a623d1b19aabb45f3af80eb7d289 21 http://action.metaffiliation.com/suivi.php?mclic=S44D03518CFF14184549378urlrv=http%3A%2F%2Filead.itrack.it%2Fclients%2Fext.aspx%3Fopenpopup%3D0%26targetpage%3Dpopup%26cid%3D16193%26sid%3D106148%26wid%3D9340%26swid%3D%26tid%3Durlv=cff7a623d1b19aabb45f3af80eb7d289 , http://action.metaffiliation.com/suivi.php?mclic=S44D03518CFF14201326594urlrv=http%3A%2F%2Filead.itrack.it%2Fclients%2Fext.aspx%3Fopenpopup%3D0%26targetpage%3Dpopup%26cid%3D16193%26sid%3D106148%26wid%3D9340%26swid%3D%26tid%3Durlv=cff7a623d1b19aabb45f3af80eb7d289 http://action.metaffiliation.com/suivi.php?mclic=S44D03518CFF14218103810urlrv=http%3A%2F%2Filead.itrack.it%2Fclients%2Fext.aspx%3Fopenpopup%3D0%26targetpage%3Dpopup%26cid%3D16193%26sid%3D106148%26wid%3D9340%26swid%3D%26tid%3Durlv=cff7a623d1b19aabb45f3af80eb7d289 http://action.metaffiliation.com/suivi.php?mclic=S44D03518CFF14234881026urlrv=http%3A%2F%2Filead.itrack.it%2Fclients%2Fext.aspx%3Fopenpopup%3D0%26targetpage%3Dpopup%26cid%3D16193%26sid%3D106148%26wid%3D9340%26swid%3D%26tid%3Durlv=cff7a623d1b19aabb45f3af80eb7d289 http://action.metaffiliation.com/suivi.php?mclic=S44D03518CFF14251658242urlrv=http%3A%2F%2Filead.itrack.it%2Fclients%2Fext.aspx%3Fopenpopup%3D0%26targetpage%3Dpopup%26cid%3D16193%26sid%3D106148%26wid%3D9340%26swid%3D%26tid%3Durlv=cff7a623d1b19aabb45f3af80eb7d289 http://action.metaffiliation.com/suivi.php?mclic=S44D03518CFF14268435458urlrv=http%3A%2F%2Filead.itrack.it%2Fclients%2Fext.aspx%3Fopenpopup%3D0%26targetpage%3Dpopup%26cid%3D16193%26sid%3D106148%26wid%3D9340%26swid%3D%26tid%3Durlv=cff7a623d1b19aabb45f3af80eb7d289
