Bakkie deal of the century
Book a test drive
http://www.testdrive-tata-xenon.co.za/?sourceID=1036amp;campaignID=51amp;coupon=doublecab
Winning Features:
2.2 Common rail Diesel.
103 KW /320 NM.
Winner of Total Economy Run (8.11 L/100km).
ABS Brakes.
5 year/90,000 km service plan.
3 Years/10,00,00 km warranty.
Book a test drive
http://www.testdrive-tata-xenon.co.za/?sourceID=1036amp;campaignID=51amp;coupon=doublecab
Terms and conditions apply. EOE. Price subject to change. Note. Offer subject
to financial approval
If you feel you received this communication by mistake, please select this
link {--unsubscribe--} to stop receiving any promotional offers or important
news. 147 Grant Avenue, Norwood. 2196
[demime 1.01d removed an attachment of type image/jpeg which had a name of
xeno-double-cab-mailer_09.jpg]
[demime 1.01d removed an attachment of type image/jpeg which had a name of
xeno-double-cab-mailer-2_06.jpg]
[demime 1.01d removed an attachment of type image/jpeg which had a name of
xeno-double-cab-mailer_01.jpg]
[demime 1.01d removed an attachment of type image/jpeg which had a name of
xeno-double-cab-mailer-2_07.jpg]
Xorg
Hello there, May someone help me with this: #Xorg -configure Xorg:/usr/X11R6/lib/modules/drivers/radeonhd_drv.so:/usr/X11R6/lib/modules/drivers/radeon_drv.so:WARNING: symbol (AtomBiosRequestList) size mismatch, relink your program (**) Using config file: /root/xorg.conf.new No idea how to do it. And it looks simple. Regards, Igor -- igor denisov.
Xorg
May someone help me with this: #Xorg -configure Xorg:/usr/X11R6/lib/modules/drivers/radeonhd_drv.so:/usr/X11R6/lib/modules/drivers/radeon_drv.so:WARNING: symbol (AtomBiosRequestList) size mismatch, relink your program (**) Using config file: /root/xorg.conf.new No idea how to do it. And it looks simple. Regards, Igor -- igor denisov.
Re: Xorg
On Thu, Aug 25, 2011 at 9:03 AM, igor denisov denisovigor1...@rambler.ru wrote: Hello there, May someone help me with this: #Xorg -configure Xorg:/usr/X11R6/lib/modules/drivers/radeonhd_drv.so:/usr/X11R6/lib/modules/drivers/radeon_drv.so:WARNING: symbol (AtomBiosRequestList) size mismatch, relink your program (**) Using config file: /root/xorg.conf.new No idea how to do it. And it looks simple. Which version of OpenBSD do you have? And dmesg? Regards, Igor -- igor denisov.
Re: Why am I not surprised?
On 08/25/11 06:30, Rod Whitworth wrote: I recently saw the Full Disclosure mailing list discussion of the Apache DoS vuln. (http://seclists.org/fulldisclosure/2011/Aug/175) So I did pkg_add p5-Parallel-ForkManager on a 4.9 release i386, and ran the perl script from killapache_pl.bin (on the FD mail list). It had absolutely no visible effect on our Apache 1.3 running on a 5.0 snapshot (Generic #16) It didn't run out of memory, the server didn't crash and the CPU load seen by systat was minimal (1%). As the title says Why am I not surprised? Same here. Running the perl script results in Host does not seem vulnerable. (OpenBSD 4.8 GENERIC.MP#359 i386) Cheers, Andreas
Using nat-to rules inside anchors in pf
Hi.
I'm trying to dynamically insert nat-to rules inside an anchor for
failover/load balancing purposes on OpenBSD 4.9. The rules get
evaluated but packet/byte/state count is zero. Can somebody please
tell me what I'm doing wrong?
Below are the two sets of rules I've tried, one without an anchor and
another with an anchor as well as sample evaluation, packet, byte, and
state counts for each nat-to rule.
### nat-to rules inside / ###
# Rules
table rfc1918 const { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 }
pass out on vlan2 inet from rfc1918 to ! rfc1918 nat-to vlan2
pass out on vlan3 inet from rfc1918 to ! rfc1918 nat-to vlan3
pass out on vlan2 inet from vlan3 route-to (vlan3 124.107.174.129)
pass out on vlan3 inet from vlan2 route-to (vlan2 116.50.188.1)
# Stats
pass out on vlan2 inet from rfc1918 to ! rfc1918 flags S/SA keep
state nat-to 116.50.188.8
[ Evaluations: 2816 Packets: 187 Bytes: 53419 States: 26]
[ Inserted: uid 0 pid 2 State Creations: 26]
pass out on vlan3 inet from rfc1918 to ! rfc1918 flags S/SA keep
state nat-to 124.107.174.137
[ Evaluations: 2610 Packets: 392 Bytes: 199902 States: 22]
[ Inserted: uid 0 pid 2 State Creations: 22]
### nat-to rules inside /WAN-NAT ###
# Rules
table rfc1918 const { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 }
anchor WAN-NAT {
pass out on vlan2 inet from rfc1918 to ! rfc1918 nat-to vlan2
pass out on vlan3 inet from rfc1918 to ! rfc1918 nat-to vlan3
}
pass out on vlan2 inet from vlan3 route-to (vlan3 124.107.174.129)
pass out on vlan3 inet from vlan2 route-to (vlan2 116.50.188.1)
# Stats
pass out on vlan2 inet from rfc1918 to ! rfc1918 flags S/SA keep
state nat-to 116.50.188.8
[ Evaluations: 3504 Packets: 0 Bytes: 0 States: 0 ]
[ Inserted: uid 0 pid 27150 State Creations: 0 ]
pass out on vlan3 inet from rfc1918 to ! rfc1918 flags S/SA keep
state nat-to 124.107.174.137
[ Evaluations: 3235 Packets: 0 Bytes: 0 States: 0 ]
[ Inserted: uid 0 pid 27150 State Creations: 0 ]
Thanks and regards,
--
Justin Jereza
Health Platform of Traditional Chinese Medicine
The original charm of traditional Chinese medicine lies in the following free and unique services: * 1 TCM Diagnosis Just a health list and a photo of the tongue coating needed, the expert of traditional Chinese medicine would make a professional diagnosis. Why not have a try? * 2 Health Plan A customized Health Plan is the guarantee of health. * 3 Disease Consultation Online professional health consultation of traditional Chinese medicine. Try This is an E-mail from TCM Discovery.com. Please don't reply. To drop your subscription, please click here.
linking
Hi there, I am confused about ln. I need to link /usr/X11R6/lib/modules/drivers/radeon_drv.so to /etc/xorg.conf and cannot understand how. May you help me? -- igor denisov.
[no subject]
Hello there, May someone help me with this: #Xorg -configure Xorg:/usr/X11R6/lib/modules/drivers/radeonhd_drv.so:/usr/X11R6/lib/modules/drivers/radeon_drv.so:WARNING: symbol (AtomBiosRequestList) size mismatch, relink your program (**) Using config file: /root/xorg.conf.new No idea how to do it. And it looks simple. Regards, Igor
[no subject]
Hello there, I am going to try to insert additional RAM TRUMP D1SC0816D DDR 1GB-333Mhz SO.DIMM the native RAM is 256MB, and I know for sure when the additional RAM inserted I have lot of kernel panics and all the time they are different and occur at different times when PC is ran. My question is how to get kernel panics dump to a file for further investigation? Regards, Igor
Re: linking
On 08/25/2011 12:56 PM, igor denisov wrote: Hi there, I am confused about ln. I need to link /usr/X11R6/lib/modules/drivers/radeon_drv.so to /etc/xorg.conf and cannot understand how. May you help me? no. Whatever you are trying to accomplish, I think you are going about it wrong. I presume this has to do with the other fragmentary and incomplete messages you have been spamming misc@ with (in the Monty Python defintion of spam, not the commercial email definition). Let's start completely over. What goal are you trying to accomplish? How did you try to accomplish that goal? What problem are you running into in the attempt to achieve that goal? What did you do to encounter that problem? and..tell us all about the hardware you are trying to accomplish this goal with...which is done by giving us the dmesg. Plan on spending a good half-hour (or a LOT more!) putting all your facts and story together. Spend MORE time asking your question carefully than you expect those of us who are providing you with free assistance to spend figuring out what you are trying to do. Nick.
Re:
On Thu, Aug 25, 2011 at 5:53 AM, igor denisov saufe...@gmail.com wrote: Hello there, I am going to try to insert additional RAM TRUMP D1SC0816D DDR 1GB-333Mhz SO.DIMM the native RAM is 256MB, and I know for sure when the additional RAM inserted I have lot of kernel panics and all the time they are different and occur at different times when PC is ran. My question is how to get kernel panics dump to a file for further investigation? http://www.openbsd.org/faq/faq2.html#Bugs PS: You still don't send dmesg of your machine as I asked privately so it's really hard to help you Regards, Igor
Re:
On 25 August 2011 03:53, igor denisov saufe...@gmail.com wrote: Hello there, May someone help me with this: #Xorg -configure Xorg:/usr/X11R6/lib/modules/drivers/radeonhd_drv.so:/usr/X11R6/lib/modules/drivers/radeon_drv.so:WARNING: symbol (AtomBiosRequestList) size mismatch, relink your program (**) Using config file: /root/xorg.conf.new No idea how to do it. And it looks simple. There was an addition to radeon_drv: http://marc.info/?l=openbsd-cvsm=131405479712726w=2 Try updating to the latest snapshot.
Re:
Will be useful for all. And I can see that you have drm enabled, so why do you need that linking? On Thu, Aug 25, 2011 at 7:54 PM, igor denisov saufe...@gmail.com wrote: $ dmesg OpenBSD 4.6 (GENERIC) #58: Thu Jul B 9 21:24:42 MDT 2009 B B dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel(R) Pentium(R) 4 Mobile CPU 1.60GHz (GenuineIntel 686-class) 1.60 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS, ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM real mem B = 266887168 (254MB) avail mem = 249245696 (237MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 04/01/02, BIOS32 rev. 0 @ 0xfd790, SMBIOS rev. 2.3 @ 0xe9860 (43 entries) bios0: vendor Phoenix/FUJITSU version Version 1.06 date 04/01/2002 bios0: FUJITSU FPC03052AK acpi0 at bios0: rev 0 acpi0: tables DSDT FACP BOOT acpi0: wakeup devices UAR1(S3) HUB_(S3) A97M(S3) LID_(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (AGP_) acpiprt2 at acpi0: bus 2 (HUB_) acpiec0 at acpi0 acpicpu0 at acpi0: C3, C2, FVS, 1600, 1200 MHz acpibtn0 at acpi0: PWRB acpibtn1 at acpi0: LID_ acpiac0 at acpi0: AC unit online acpibat0 at acpi0: CMB1 model CP097166-XX serial 1 type LION oem Fujitsu acpivideo0 at acpi0: VGA_ acpivout0 at acpivideo0: CRT_ acpivout1 at acpivideo0: LCD_ acpivout2 at acpivideo0: TV__ bios0: ROM list: 0xc/0xe000 0xce000/0x1000 cpu0 at mainbus0: (uniprocessor) pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 Intel 82845 Host rev 0x04 intelagp0 at pchb0 agp0 at intelagp0: aperture at 0xec00, size 0x400 ppb0 at pci0 dev 1 function 0 Intel 82845 AGP rev 0x04 pci1 at ppb0 bus 1 vga1 at pci1 dev 0 function 0 ATI Radeon Mobility M6 rev 0x00 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) radeondrm0 at vga1: irq 11 drm0 at radeondrm0 uhci0 at pci0 dev 29 function 0 Intel 82801CA/CAM USB rev 0x02: irq 11 uhci1 at pci0 dev 29 function 1 Intel 82801CA/CAM USB rev 0x02: irq 11 ppb1 at pci0 dev 30 function 0 Intel 82801BAM Hub-to-PCI rev 0x42 pci2 at ppb1 bus 2 cbb0 at pci2 dev 10 function 0 TI PCI1520 CardBus rev 0x01: irq 11 cbb1 at pci2 dev 10 function 1 TI PCI1520 CardBus rev 0x01: irq 11 rl0 at pci2 dev 12 function 0 Realtek 8139 rev 0x10: irq 11, address 00:e0:00:ac:6f:40 rlphy0 at rl0 phy 0: RTL internal PHY TI TSB43AB21 FireWire rev 0x00 at pci2 dev 14 function 0 not configured cardslot0 at cbb0 slot 0 flags 0 cardbus0 at cardslot0: bus 3 device 0 cacheline 0x8, lattimer 0x20 pcmcia0 at cardslot0 cardslot1 at cbb1 slot 1 flags 0 cardbus1 at cardslot1: bus 4 device 0 cacheline 0x8, lattimer 0x20 pcmcia1 at cardslot1 ichpcib0 at pci0 dev 31 function 0 Intel 82801CAM LPC rev 0x02 pciide0 at pci0 dev 31 function 1 Intel 82801CAM IDE rev 0x02: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility wd0 at pciide0 channel 0 drive 0: TOSHIBA MK3018GAP wd0: 16-sector PIO, LBA, 28615MB, 58605120 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5 atapiscsi0 at pciide0 channel 1 drive 0 scsibus0 at atapiscsi0: 2 targets cd0 at scsibus0 targ 0 lun 0: Optiarc, DVD RW AD-7540A, 1.01 ATAPI 5/cdrom removable cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2 ichiic0 at pci0 dev 31 function 3 Intel 82801CA/CAM SMBus rev 0x02: irq 11 iic0 at ichiic0 iic0: addr 0x19 00=00 01=00 02=00 03=00 04=00 05=00 06=00 07=00 08=00 09=00 0a=00 0b=00 0c=00 0d=00 0e=0f 0f=00 10=00 11=00 12=00 13=00 14=01 15=00 16=10 17=00 18=00 19=00 1a=00 1b=00 1c=00 1d=00 1e=00 1f=00 20=01 21=01 22=01 23=01 24=01 25=01 26=01 27=01 28=01 29=01 2a=01 2b=01 2c=01 2d=01 2e=01 2f=01 30=01 31=01 32=01 33=01 34=01 35=01 36=01 37=01 38=01 39=01 3a=01 3b=01 3c=01 3d=01 3e=01 3f=01 40=01 41=01 42=01 43=01 44=01 45=01 46=01 47=01 48=01 49=01 4a=01 4b=01 4c=01 4d=01 4e=01 4f=01 50=01 51=01 52=01 53=01 54=01 55=01 56=01 57=01 58=01 words 00= 01= 02= 03= 04= 05= 06= 07= auich0 at pci0 dev 31 function 5 Intel 82801CA/CAM AC97 rev 0x02: irq 11, ICH3 AC97 ac97: codec id 0x83847666 (SigmaTel STAC9766/67) ac97: codec features headphone, 20 bit DAC, 18 bit ADC, SigmaTel 3D audio0 at auich0 Intel 82801CA/CAM Modem rev 0x02 at pci0 dev 31 function 6 not configured usb0 at uhci0: USB revision 1.0 uhub0 at usb0 Intel UHCI root hub rev 1.00/1.00 addr 1 usb1 at uhci1: USB revision 1.0 uhub1 at usb1 Intel UHCI root hub rev 1.00/1.00 addr 1 isa0 at ichpcib0 isadma0 at isa0 pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard, using wsdisplay0 pmsi0 at pckbc0 (aux slot) pckbc0: using irq 12 for aux slot wsmouse0 at pmsi0 mux 0 pcppi0 at isa0 port 0x61 midi0 at pcppi0: PC speaker spkr0 at pcppi0 lpt0 at isa0 port 0x378/4 irq 7 npx0 at isa0 port 0xf0/16: reported by CPUID; using
Re: pflog shows 0.0.0.0.0 0.0.0.0.0
I thought that this might be a common occurrence and that it simply wasn't in the documentation (where I looked). Is no one else seeing this same behavior? By the way, this host is running as a virtual machine inside VMWare ESXi 4.1 (I chose FreeBSD as the guest OS when I initially created the VM). Matt On Mon, Aug 22, 2011 at 5:09 PM, Matt Van Mater matt.vanma...@gmail.comwrote: Hi All, See my configuration at the bottom of this email. I am looking into why my pflog has these ambiguous entries that show source and destination as all zeros e.g. 0.0.0.0.0 0.0.0.0.0. I saw that there was a related thread earlier this year asking questions that was unresolved/unconfirmed and I would like to get feedback from one of the developers (Daniel, Henning?) to confirm my suspicions. I believe that these lines are a result of the log (all) statement, which logs all subsequent packets in a stateful session (and not just the first packets matching the rules). If that is true, then IMO the log entries are not very intuitive or useful without the true source/destination IP Addresses included... I can't grep for src/dst any more, now I assume I would have to correlate the session information some other way (e.g. sequence numbers?) So to put my questions more succinctly: 1) Are logs with 0.0.0.0.0 0.0.0.0.0 a result of the pf.conf log (all) statement, and are therefore an indication of a continuing tcp session? 2) Are there any plans to update the logging to represent the actual src/dst of these packets? If not, what is your suggested method for correlating these stateful session log entries? By the way, I tried to post this to the pf mailing list but got bounced back on the SPAM filters when trying to subscribe. Same goes for when I tried to email Daniel directly to resolve the issue. Can someone get in touch with him and inform him of the issue? My configurations: # uname -rsvm OpenBSD 4.9 GENERIC#477 amd64 # pfctl -s rules pass all flags S/SA keep state pass in log (all) quick on em0 proto tcp from any to any port = https flags S/SA keep state pass in log (all) quick on em0 proto tcp from any to any port = ssh flags S/SA keep state block drop in log (all) on em0 all pass out log (all) on em0 all flags S/SA keep state block drop in on ! lo0 proto tcp from any to any port 6000:6010 # tcpdump -ne -ttt -r /var/log/pflog host 0.0.0.0 | head tcpdump: WARNING: snaplen raised from 116 to 160 Aug 17 16:00:30.673967 rule 2/(match) pass in on em0: 0.0.0.0.0 0.0.0.0.0: P 142855442:142855478(36) ack 49382696 win 256 (DF) Aug 17 16:00:30.867230 rule 2/(match) pass out on em0: 0.0.0.0.0 0.0.0.0.0: . ack 93472783 win 2190 (DF) [tos 0x10] Aug 17 16:01:30.988858 rule 2/(match) pass in on em0: 0.0.0.0.0 0.0.0.0.0: P 36:72(36) ack 1 win 256 (DF) Aug 17 16:01:31.179997 rule 2/(match) pass out on em0: 0.0.0.0.0 0.0.0.0.0: . ack 93472819 win 2190 (DF) [tos 0x10] Aug 17 16:02:15.903119 rule 3/(match) block in on em0: 0.0.0.0.68 255.255.255.255.67: xid:0x5d366a85 flags:0x8000 [|bootp] Aug 17 16:02:31.301720 rule 2/(match) pass in on em0: 0.0.0.0.0 0.0.0.0.0: P 72:108(36) ack 1 win 256 (DF) Aug 17 16:02:31.492758 rule 2/(match) pass out on em0: 0.0.0.0.0 0.0.0.0.0: . ack 93472855 win 2190 (DF) [tos 0x10] Aug 17 16:03:31.615561 rule 2/(match) pass in on em0: 0.0.0.0.0 0.0.0.0.0: P 108:144(36) ack 1 win 256 (DF) Aug 17 16:03:31.815571 rule 2/(match) pass out on em0: 0.0.0.0.0 0.0.0.0.0: . ack 93472891 win 2190 (DF) [tos 0x10] Aug 17 16:04:31.929505 rule 2/(match) pass in on em0: 0.0.0.0.0 0.0.0.0.0: P 144:180(36) ack 1 win 256 (DF) Thanks, Matt
Taller de Desarrollo de Manual Políticas y Procedimientos (Últimos Lugares,)
[IMAGE] Pms Capacitacisn Efectiva de Mixico presenta: Identificacisn de Procesos y Desarrollo de Manuales de Polmticas de Procedimientos. Exclusiva Presentacisn: 29 de Agosto en la Ciudad de Mixico con un horario de 09:00 a 08:00 pm. Lo estara acompaqado nuestro expositor Ing. Enrique Castro Traemos los mejores eventos para usted, conozca los beneficios de capacitarse con los mejores! Empresa Registrada ante la STPS Reg. COLG640205CP30005 Smguenos en Twitter@pmscapacitacion o bien en Facebook PMS de Mixico !Solicite Mayores Informes! Por favor responda este e-mail con los datos siguientes. Empresa: Nombre: Telifono: Email: Nzmero de Interesados: En breve recibira la informacisn completa de este inigualable evento. Comunmquese a los telifonos y con gusto uno de nuestros ejecutivos le atendera. Telifonos: (0133) 8851-2365, (0133) 8851-2741, (0133) 1568-4647. Copyright (C) 2011, 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 BAJAMANUAL Unsubscribe to this mailing list, reply a blank message with the subject UNSUBSCRIBE BAJAMANUAL 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/jpeg which had a name of imagem002.jpg]
Re: pflog shows 0.0.0.0.0 0.0.0.0.0
Yes these are from the log (all), looks like a bug to me. On 2011-08-25, Matt Van Mater matt.vanma...@gmail.com wrote: I thought that this might be a common occurrence and that it simply wasn't in the documentation (where I looked). Is no one else seeing this same behavior? By the way, this host is running as a virtual machine inside VMWare ESXi 4.1 (I chose FreeBSD as the guest OS when I initially created the VM). Matt On Mon, Aug 22, 2011 at 5:09 PM, Matt Van Mater matt.vanma...@gmail.comwrote: Hi All, See my configuration at the bottom of this email. I am looking into why my pflog has these ambiguous entries that show source and destination as all zeros e.g. 0.0.0.0.0 0.0.0.0.0. I saw that there was a related thread earlier this year asking questions that was unresolved/unconfirmed and I would like to get feedback from one of the developers (Daniel, Henning?) to confirm my suspicions. I believe that these lines are a result of the log (all) statement, which logs all subsequent packets in a stateful session (and not just the first packets matching the rules). If that is true, then IMO the log entries are not very intuitive or useful without the true source/destination IP Addresses included... I can't grep for src/dst any more, now I assume I would have to correlate the session information some other way (e.g. sequence numbers?) So to put my questions more succinctly: 1) Are logs with 0.0.0.0.0 0.0.0.0.0 a result of the pf.conf log (all) statement, and are therefore an indication of a continuing tcp session? 2) Are there any plans to update the logging to represent the actual src/dst of these packets? If not, what is your suggested method for correlating these stateful session log entries? By the way, I tried to post this to the pf mailing list but got bounced back on the SPAM filters when trying to subscribe. Same goes for when I tried to email Daniel directly to resolve the issue. Can someone get in touch with him and inform him of the issue? My configurations: # uname -rsvm OpenBSD 4.9 GENERIC#477 amd64 # pfctl -s rules pass all flags S/SA keep state pass in log (all) quick on em0 proto tcp from any to any port = https flags S/SA keep state pass in log (all) quick on em0 proto tcp from any to any port = ssh flags S/SA keep state block drop in log (all) on em0 all pass out log (all) on em0 all flags S/SA keep state block drop in on ! lo0 proto tcp from any to any port 6000:6010 # tcpdump -ne -ttt -r /var/log/pflog host 0.0.0.0 | head tcpdump: WARNING: snaplen raised from 116 to 160 Aug 17 16:00:30.673967 rule 2/(match) pass in on em0: 0.0.0.0.0 0.0.0.0.0: P 142855442:142855478(36) ack 49382696 win 256 (DF) Aug 17 16:00:30.867230 rule 2/(match) pass out on em0: 0.0.0.0.0 0.0.0.0.0: . ack 93472783 win 2190 (DF) [tos 0x10] Aug 17 16:01:30.988858 rule 2/(match) pass in on em0: 0.0.0.0.0 0.0.0.0.0: P 36:72(36) ack 1 win 256 (DF) Aug 17 16:01:31.179997 rule 2/(match) pass out on em0: 0.0.0.0.0 0.0.0.0.0: . ack 93472819 win 2190 (DF) [tos 0x10] Aug 17 16:02:15.903119 rule 3/(match) block in on em0: 0.0.0.0.68 255.255.255.255.67: xid:0x5d366a85 flags:0x8000 [|bootp] Aug 17 16:02:31.301720 rule 2/(match) pass in on em0: 0.0.0.0.0 0.0.0.0.0: P 72:108(36) ack 1 win 256 (DF) Aug 17 16:02:31.492758 rule 2/(match) pass out on em0: 0.0.0.0.0 0.0.0.0.0: . ack 93472855 win 2190 (DF) [tos 0x10] Aug 17 16:03:31.615561 rule 2/(match) pass in on em0: 0.0.0.0.0 0.0.0.0.0: P 108:144(36) ack 1 win 256 (DF) Aug 17 16:03:31.815571 rule 2/(match) pass out on em0: 0.0.0.0.0 0.0.0.0.0: . ack 93472891 win 2190 (DF) [tos 0x10] Aug 17 16:04:31.929505 rule 2/(match) pass in on em0: 0.0.0.0.0 0.0.0.0.0: P 144:180(36) ack 1 win 256 (DF) Thanks, Matt
Re: (unknown)
On 2011-08-25, igor denisov saufe...@gmail.com wrote: Hello there, I am going to try to insert additional RAM TRUMP D1SC0816D DDR 1GB-333Mhz SO.DIMM the native RAM is 256MB, and I know for sure when the additional RAM inserted I have lot of kernel panics and all the time they are different and occur at different times when PC is ran. Make sure the RAM is compatible with the machine and with the existing RAM (same speed/CAS latency etc.). Have you tried taking out the existing RAM and just using the new RAM? Have you tried different RAM slots? My question is how to get kernel panics dump to a file for further investigation? boot dump, see ddb(4). But it's unlikely to help you here.
Re: CDDL vs GPL and maybe some implications for BSD?
On Tue, Aug 23, 2011 at 10:17 PM, Theo de Raadt dera...@cvs.openbsd.org wrote: yeah, you gotta wonder about that. No, really, you don't. Those that tell you it is about Freedom are mostly full of shit. It's about it didn't cost me anything to most of them. We've got an entire operating system which is completely free as a base; besides that, a shrinking set of GPL2 components are used to help us build. Maybe in the future that will change. A variety of choices are slowly in play. And now, because of ZFS and dtrace, we should throw that entire Bostic-started effort out the window. Screw freedom, I need ZFS and dtrace. Don't be fooled. This request does not come from people who love ZFS or dtrace. It comes from people who apparently love btoh ZFS _and_ dtrace (otherwise, once in a while we'd get a mail from someone who only mentions ZFS, right?). Because, as you all know, everyone needs both ZFS and dtrace, or they are doomed and it is a certainly that Satan and Bill will consume their souls for eternity. Yes, I need dtrace. Today tomorrow and forever, or I will go to hell. dtrace or death. Yes, some of you will think I am silly, but if you do, please go check some mail archives and you will see that apparently most ZFS people don't care about ZFS, unless they post to *BSD mailing lists, and then suddenly pushing dtrace becomes a real pressure point. I don't know where these people come from but they seem like agents of Stallman or Company X or Company Y, at the very least some kind of divide and conquer or divide or conquer effort is in play. Don't even bother to respond to such people, unless your mail explains to others what is going on. The real key phrase to watch for here is that there are people who always mix ZFS and dtrace together. Everytime they are mixed together, the person posting it is of the type that has zero use for dtrace. They've been fooled by someone to equate those two as equal value. Who are these ZFS and dtrace people? Are they HFT programmers? I really don't know. Do they help the project? I can assure you that they do not. I bet they couldn't use dtrace to their advantage of their life depended on it. Yet ZFS and dtrace so often mentioned together... Don't be fooled. In fact, I urge our users to investigate every person who has mentioned ZFS and dtrace together in the past. Their agenda is not the one that you or I believe in. Their agenda is division. DTrace is really really really cool but it is totally inadvisable to integrate because of future problems. I don't think Free and Net learnt anything from the old Unix lawsuit, the whole unpleasantness of it.
Re: pflog shows 0.0.0.0.0 0.0.0.0.0
On Thu, 25 Aug 2011 20:10:12 + (UTC) Stuart Henderson s...@spacehopper.org wrote: Yes these are from the log (all), looks like a bug to me. I wondered if it was the result of one of the optimisations. The state making SYNs show the correct IP.
linking
The solution to the problem of linking radeon_drv.so and xorg.conf was quite a simple thing as to remove radeonhd_drv.so radeonhd_drv.la, start xorg -configure and that's all, no warnings anymore. Regards.
Re: CDDL vs GPL and maybe some implications for BSD?
I don't think Free and Net learnt anything from the old Unix lawsuit, the whole unpleasantness of it. Their group is largely American; and when not in location they are so in perspective. Why would they have learned anything? Shall I keep it short? They are simplistic retards, not because they choose to be, but because their paychecks tell them to be so. And I invite one of them on our mailing lists to stand up and call me on that.
