Re: OpenBSD 4.4
Hello misc, I've appreciated all answers. the kernel is GENERIC. My complex setup is many networks, pf rules , Vans and a route to all. ( route add ) If I execute: - nmap -sV -T4 -O -F 10.20.0/16 ( I'm at 10.20.76 ) the follow error ocurs: http://img41.imageshack.us/img41/9500/20120123213213394.jpg After read all comments, I only am writing to show the error and share the information. As soon as possible, I will upgrade. Thank's to all Em 24 de janeiro de 2012 20:46, Peter N. M. Hansteen pe...@bsdly.netescreveu: R0me0 *** knight@gmail.com writes: I'm running a full patched OpenBSD 4.4 with very complex setup, and I'm planning an upgrade to 5.0. That's a seriously long jump, but then again, that upgrade may very well be a blessing in disguise -- an opportunity to identify what parts of your complex setup are actually just cascades of accidents that followed quasi-logically from other earlier accidents (no worries, this should sound familiar to most of the people who've been around for a while) and what actually matters and needs to be that way for a reason. Do take the time for proper preparations, though: at the very least read through the upgrade steps for each of the versions, starting from http://www.openbsd.org/faq/upgrade45.html and proceeding through http://www.openbsd.org/faq/upgrade50.html. The only *supported* method is to go through all of those upgrade steps, but you might find it easier to back up your data and config, do a clean install, restore data and then introduce those configuration elements that are in fact essential or at least useful for your particular environment. At this moment, if I execute nmap 10.20.0/16, I have a dbg . I've limited the number of max connections and connections per seconds, that solved the problem. When dbg occurs, I cannot do a trace because it completely hangs. Others have offered as useful input as can be had on those. Good luck with the upgrade! All the best, Peter -- 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: OpenBSD 4.4
On Tue, Jan 24, 2012 at 03:48:49PM -0200, R0me0 *** wrote: Hello misc :) I'm running a full patched OpenBSD 4.4 with very complex setup, and I'm planning an upgrade to 5.0. At this moment, if I execute nmap 10.20.0/16, I have a dbg . I've limited the number of max connections and connections per seconds, that solved the problem. When dbg occurs, I cannot do a trace because it completely hangs. Following is a dmesg, any directions will be appreciated OpenBSD 4.4 (TENMA.MP) #3: Tue Jan 24 00:46:50 BRST 2012 r...@ns1.mycompany.com:/home/src/sys/arch/amd64/compile/TENMA.MP You're running an ancient version with a non-GENERIC kernel. Go read the FAQ, then come back. -ml real mem = 2132389888 (2033MB) avail mem = 2070573056 (1974MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xee000 (68 entries) bios0: vendor HP version P58 date 08/03/2008 bios0: HP ProLiant DL360 G5 acpi0 at bios0: rev 2 acpi0: tables DSDT FACP SPCR MCFG HPET SPMI ERST APIC BERT HEST SSDT acpi0: wakeup devices PCI0(S5) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E5440 @ 2.83GHz, 2833.79 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,CX16,xTPR,LONG cpu0: 6MB 64b/line 16-way L2 cache cpu0: apic clock running at 333MHz cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) CPU E5440 @ 2.83GHz, 2833.44 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,CX16,xTPR,LONG cpu1: 6MB 64b/line 16-way L2 cache cpu2 at mainbus0: apid 1 (application processor) cpu2: Intel(R) Xeon(R) CPU E5440 @ 2.83GHz, 2833.44 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,CX16,xTPR,LONG cpu2: 6MB 64b/line 16-way L2 cache cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Xeon(R) CPU E5440 @ 2.83GHz, 2833.44 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,CX16,xTPR,LONG cpu3: 6MB 64b/line 16-way L2 cache ioapic0 at mainbus0 apid 8 pa 0xfec0, version 20, 24 pins ioapic1 at mainbus0 apid 9 pa 0xfec8, version 20, 24 pins acpiprt0 at acpi0: bus 1 (IP2P) acpiprt1 at acpi0: bus 11 (IPE1) acpiprt2 at acpi0: bus 10 (IPE4) acpiprt3 at acpi0: bus 17 (P2P2) acpiprt4 at acpi0: bus 9 (PT02) acpiprt5 at acpi0: bus 6 (PT03) acpiprt6 at acpi0: bus 20 (PT04) acpiprt7 at acpi0: bus 3 (NB01) acpiprt8 at acpi0: bus 5 (NB02) acpiprt9 at acpi0: bus 0 (PCI0) acpicpu0 at acpi0: C3 acpicpu1 at acpi0: C3 acpicpu2 at acpi0: C3 acpicpu3 at acpi0: C3 acpitz0 at acpi0: critical temperature 31 degC ipmi at mainbus0 not configured cpu0: unknown i686 model 7, can't get bus clockcpu0: EST: unknown system bus clock pci0 at mainbus0 bus 0: configuration mode 1 pchb0 at pci0 dev 0 function 0 Intel 5000P Host rev 0xb1 ppb0 at pci0 dev 2 function 0 Intel 5000 PCIE rev 0xb1 pci1 at ppb0 bus 9 ppb1 at pci1 dev 0 function 0 Intel 6321ESB PCIE rev 0x01 pci2 at ppb1 bus 10 ppb2 at pci2 dev 0 function 0 Intel 6321ESB PCIE rev 0x01 pci3 at ppb2 bus 11 ppb3 at pci3 dev 0 function 0 vendor IDT, unknown product 0x8018 rev 0x0e pci4 at ppb3 bus 12 ppb4 at pci4 dev 2 function 0 vendor IDT, unknown product 0x8018 rev 0x0e pci5 at ppb4 bus 13 em0 at pci5 dev 0 function 0 Intel PRO/1000 QP (82571EB) rev 0x06: apic 8 int 19 (irq 10), address 00:1f:29:5f:fe:b5 em1 at pci5 dev 0 function 1 Intel PRO/1000 QP (82571EB) rev 0x06: apic 8 int 18 (irq 10), address 00:1f:29:5f:fe:b4 ppb5 at pci4 dev 4 function 0 vendor IDT, unknown product 0x8018 rev 0x0e pci6 at ppb5 bus 14 em2 at pci6 dev 0 function 0 Intel PRO/1000 QP (82571EB) rev 0x06: apic 8 int 17 (irq 7), address 00:1f:29:5f:fe:b7 em3 at pci6 dev 0 function 1 Intel PRO/1000 QP (82571EB) rev 0x06: apic 8 int 16 (irq 5), address 00:1f:29:5f:fe:b6 ppb6 at pci2 dev 1 function 0 Intel 6321ESB PCIE rev 0x01 pci7 at ppb6 bus 15 ppb7 at pci2 dev 2 function 0 Intel 6321ESB PCIE rev 0x01 pci8 at ppb7 bus 16 ppb8 at pci1 dev 0 function 3 Intel 6321ESB PCIE-PCIX rev 0x01 pci9 at ppb8 bus 17 ppb9 at pci0 dev 3 function 0 Intel 5000 PCIE rev 0xb1 pci10 at ppb9 bus 6 ciss0 at pci10 dev 0 function 0 Hewlett-Packard Smart Array rev 0x04: apic 8 int 16 (irq 5) ciss0: 1 LD, HW rev 4, FW 4.12/4.12 scsibus0 at ciss0: 1 targets, initiator 1 sd0 at scsibus0 targ 0 lun 0: HP, LOGICAL VOLUME, 4.12 SCSI3 0/direct fixed sd0: 139979MB, 17844 cyl, 255 head, 63 sec, 512 bytes/sec, 286677120 sec total ppb10 at pci0 dev 4 function 0 Intel 5000 PCIE x8 rev 0xb1
Re: OpenBSD 4.4
On 01/24/2012 07:48 PM, R0me0 *** wrote: Hello misc :) I'm running a full patched OpenBSD 4.4 with very complex setup, and I'm planning an upgrade to 5.0. At this moment, if I execute nmap 10.20.0/16, I have a dbg . I've limited the number of max connections and connections per seconds, that solved the problem. When dbg occurs, I cannot do a trace because it completely hangs. Following is a dmesg, any directions will be appreciated OpenBSD 4.4 (TENMA.MP) #3: Tue Jan 24 00:46:50 BRST 2012 r...@ns1.mycompany.com:/home/src/sys/arch/amd64/compile/TENMA.MP real mem = 2132389888 (2033MB) avail mem = 2070573056 (1974MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xee000 (68 entries) bios0: vendor HP version P58 date 08/03/2008 bios0: HP ProLiant DL360 G5 acpi0 at bios0: rev 2 acpi0: tables DSDT FACP SPCR MCFG HPET SPMI ERST APIC BERT HEST SSDT acpi0: wakeup devices PCI0(S5) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E5440 @ 2.83GHz, 2833.79 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,CX16,xTPR,LONG cpu0: 6MB 64b/line 16-way L2 cache cpu0: apic clock running at 333MHz cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) CPU E5440 @ 2.83GHz, 2833.44 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,CX16,xTPR,LONG cpu1: 6MB 64b/line 16-way L2 cache cpu2 at mainbus0: apid 1 (application processor) cpu2: Intel(R) Xeon(R) CPU E5440 @ 2.83GHz, 2833.44 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,CX16,xTPR,LONG cpu2: 6MB 64b/line 16-way L2 cache cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Xeon(R) CPU E5440 @ 2.83GHz, 2833.44 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,CX16,xTPR,LONG cpu3: 6MB 64b/line 16-way L2 cache ioapic0 at mainbus0 apid 8 pa 0xfec0, version 20, 24 pins ioapic1 at mainbus0 apid 9 pa 0xfec8, version 20, 24 pins acpiprt0 at acpi0: bus 1 (IP2P) acpiprt1 at acpi0: bus 11 (IPE1) acpiprt2 at acpi0: bus 10 (IPE4) acpiprt3 at acpi0: bus 17 (P2P2) acpiprt4 at acpi0: bus 9 (PT02) acpiprt5 at acpi0: bus 6 (PT03) acpiprt6 at acpi0: bus 20 (PT04) acpiprt7 at acpi0: bus 3 (NB01) acpiprt8 at acpi0: bus 5 (NB02) acpiprt9 at acpi0: bus 0 (PCI0) acpicpu0 at acpi0: C3 acpicpu1 at acpi0: C3 acpicpu2 at acpi0: C3 acpicpu3 at acpi0: C3 acpitz0 at acpi0: critical temperature 31 degC ipmi at mainbus0 not configured cpu0: unknown i686 model 7, can't get bus clockcpu0: EST: unknown system bus clock pci0 at mainbus0 bus 0: configuration mode 1 pchb0 at pci0 dev 0 function 0 Intel 5000P Host rev 0xb1 ppb0 at pci0 dev 2 function 0 Intel 5000 PCIE rev 0xb1 pci1 at ppb0 bus 9 ppb1 at pci1 dev 0 function 0 Intel 6321ESB PCIE rev 0x01 pci2 at ppb1 bus 10 ppb2 at pci2 dev 0 function 0 Intel 6321ESB PCIE rev 0x01 pci3 at ppb2 bus 11 ppb3 at pci3 dev 0 function 0 vendor IDT, unknown product 0x8018 rev 0x0e pci4 at ppb3 bus 12 ppb4 at pci4 dev 2 function 0 vendor IDT, unknown product 0x8018 rev 0x0e pci5 at ppb4 bus 13 em0 at pci5 dev 0 function 0 Intel PRO/1000 QP (82571EB) rev 0x06: apic 8 int 19 (irq 10), address 00:1f:29:5f:fe:b5 em1 at pci5 dev 0 function 1 Intel PRO/1000 QP (82571EB) rev 0x06: apic 8 int 18 (irq 10), address 00:1f:29:5f:fe:b4 ppb5 at pci4 dev 4 function 0 vendor IDT, unknown product 0x8018 rev 0x0e pci6 at ppb5 bus 14 em2 at pci6 dev 0 function 0 Intel PRO/1000 QP (82571EB) rev 0x06: apic 8 int 17 (irq 7), address 00:1f:29:5f:fe:b7 em3 at pci6 dev 0 function 1 Intel PRO/1000 QP (82571EB) rev 0x06: apic 8 int 16 (irq 5), address 00:1f:29:5f:fe:b6 ppb6 at pci2 dev 1 function 0 Intel 6321ESB PCIE rev 0x01 pci7 at ppb6 bus 15 ppb7 at pci2 dev 2 function 0 Intel 6321ESB PCIE rev 0x01 pci8 at ppb7 bus 16 ppb8 at pci1 dev 0 function 3 Intel 6321ESB PCIE-PCIX rev 0x01 pci9 at ppb8 bus 17 ppb9 at pci0 dev 3 function 0 Intel 5000 PCIE rev 0xb1 pci10 at ppb9 bus 6 ciss0 at pci10 dev 0 function 0 Hewlett-Packard Smart Array rev 0x04: apic 8 int 16 (irq 5) ciss0: 1 LD, HW rev 4, FW 4.12/4.12 scsibus0 at ciss0: 1 targets, initiator 1 sd0 at scsibus0 targ 0 lun 0:HP, LOGICAL VOLUME, 4.12 SCSI3 0/direct fixed sd0: 139979MB, 17844 cyl, 255 head, 63 sec, 512 bytes/sec, 286677120 sec total ppb10 at pci0 dev 4 function 0 Intel 5000 PCIE x8 rev 0xb1 pci11 at ppb10 bus 20 ppb11 at pci11 dev 0 function 0 vendor IDT, unknown product 0x8018 rev 0x0e pci12 at ppb11 bus 21 ppb12 at pci12 dev 2 function 0 vendor IDT, unknown product 0x8018 rev 0x0e pci13 at ppb12 bus 22 em4 at
Re: OpenBSD 4.4
It is a GENERIC kernel, the name is only copy of GENERIC.MP :) . As I said, it is a complex setup and I'm planning an upgrade. Cheers, Em 24 de janeiro de 2012 16:10, Rares Aioanei bsdlis...@gmail.comescreveu: On 01/24/2012 07:48 PM, R0me0 *** wrote: Hello misc :) I'm running a full patched OpenBSD 4.4 with very complex setup, and I'm planning an upgrade to 5.0. At this moment, if I execute nmap 10.20.0/16, I have a dbg . I've limited the number of max connections and connections per seconds, that solved the problem. When dbg occurs, I cannot do a trace because it completely hangs. Following is a dmesg, any directions will be appreciated OpenBSD 4.4 (TENMA.MP) #3: Tue Jan 24 00:46:50 BRST 2012 r...@ns1.mycompany.com:/home/**src/sys/arch/amd64/compile/TEN**MA.MPhttp://TENMA.MP real mem = 2132389888 (2033MB) avail mem = 2070573056 (1974MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xee000 (68 entries) bios0: vendor HP version P58 date 08/03/2008 bios0: HP ProLiant DL360 G5 acpi0 at bios0: rev 2 acpi0: tables DSDT FACP SPCR MCFG HPET SPMI ERST APIC BERT HEST SSDT acpi0: wakeup devices PCI0(S5) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E5440 @ 2.83GHz, 2833.79 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,**MCE,CX8,APIC,SEP,MTRR,PGE,MCA,** CMOV,PAT,PSE36,CFLUSH,DS,ACPI,**MMX,FXSR,SSE,SSE2,SS,HTT,TM,** SBF,SSE3,MWAIT,DS-CPL,VMX,EST,**TM2,CX16,xTPR,LONG cpu0: 6MB 64b/line 16-way L2 cache cpu0: apic clock running at 333MHz cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) CPU E5440 @ 2.83GHz, 2833.44 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,**MCE,CX8,APIC,SEP,MTRR,PGE,MCA,** CMOV,PAT,PSE36,CFLUSH,DS,ACPI,**MMX,FXSR,SSE,SSE2,SS,HTT,TM,** SBF,SSE3,MWAIT,DS-CPL,VMX,EST,**TM2,CX16,xTPR,LONG cpu1: 6MB 64b/line 16-way L2 cache cpu2 at mainbus0: apid 1 (application processor) cpu2: Intel(R) Xeon(R) CPU E5440 @ 2.83GHz, 2833.44 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,**MCE,CX8,APIC,SEP,MTRR,PGE,MCA,** CMOV,PAT,PSE36,CFLUSH,DS,ACPI,**MMX,FXSR,SSE,SSE2,SS,HTT,TM,** SBF,SSE3,MWAIT,DS-CPL,VMX,EST,**TM2,CX16,xTPR,LONG cpu2: 6MB 64b/line 16-way L2 cache cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Xeon(R) CPU E5440 @ 2.83GHz, 2833.44 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,**MCE,CX8,APIC,SEP,MTRR,PGE,MCA,** CMOV,PAT,PSE36,CFLUSH,DS,ACPI,**MMX,FXSR,SSE,SSE2,SS,HTT,TM,** SBF,SSE3,MWAIT,DS-CPL,VMX,EST,**TM2,CX16,xTPR,LONG cpu3: 6MB 64b/line 16-way L2 cache ioapic0 at mainbus0 apid 8 pa 0xfec0, version 20, 24 pins ioapic1 at mainbus0 apid 9 pa 0xfec8, version 20, 24 pins acpiprt0 at acpi0: bus 1 (IP2P) acpiprt1 at acpi0: bus 11 (IPE1) acpiprt2 at acpi0: bus 10 (IPE4) acpiprt3 at acpi0: bus 17 (P2P2) acpiprt4 at acpi0: bus 9 (PT02) acpiprt5 at acpi0: bus 6 (PT03) acpiprt6 at acpi0: bus 20 (PT04) acpiprt7 at acpi0: bus 3 (NB01) acpiprt8 at acpi0: bus 5 (NB02) acpiprt9 at acpi0: bus 0 (PCI0) acpicpu0 at acpi0: C3 acpicpu1 at acpi0: C3 acpicpu2 at acpi0: C3 acpicpu3 at acpi0: C3 acpitz0 at acpi0: critical temperature 31 degC ipmi at mainbus0 not configured cpu0: unknown i686 model 7, can't get bus clockcpu0: EST: unknown system bus clock pci0 at mainbus0 bus 0: configuration mode 1 pchb0 at pci0 dev 0 function 0 Intel 5000P Host rev 0xb1 ppb0 at pci0 dev 2 function 0 Intel 5000 PCIE rev 0xb1 pci1 at ppb0 bus 9 ppb1 at pci1 dev 0 function 0 Intel 6321ESB PCIE rev 0x01 pci2 at ppb1 bus 10 ppb2 at pci2 dev 0 function 0 Intel 6321ESB PCIE rev 0x01 pci3 at ppb2 bus 11 ppb3 at pci3 dev 0 function 0 vendor IDT, unknown product 0x8018 rev 0x0e pci4 at ppb3 bus 12 ppb4 at pci4 dev 2 function 0 vendor IDT, unknown product 0x8018 rev 0x0e pci5 at ppb4 bus 13 em0 at pci5 dev 0 function 0 Intel PRO/1000 QP (82571EB) rev 0x06: apic 8 int 19 (irq 10), address 00:1f:29:5f:fe:b5 em1 at pci5 dev 0 function 1 Intel PRO/1000 QP (82571EB) rev 0x06: apic 8 int 18 (irq 10), address 00:1f:29:5f:fe:b4 ppb5 at pci4 dev 4 function 0 vendor IDT, unknown product 0x8018 rev 0x0e pci6 at ppb5 bus 14 em2 at pci6 dev 0 function 0 Intel PRO/1000 QP (82571EB) rev 0x06: apic 8 int 17 (irq 7), address 00:1f:29:5f:fe:b7 em3 at pci6 dev 0 function 1 Intel PRO/1000 QP (82571EB) rev 0x06: apic 8 int 16 (irq 5), address 00:1f:29:5f:fe:b6 ppb6 at pci2 dev 1 function 0 Intel 6321ESB PCIE rev 0x01 pci7 at ppb6 bus 15 ppb7 at pci2 dev 2 function 0 Intel 6321ESB PCIE rev 0x01 pci8 at ppb7 bus 16 ppb8 at pci1 dev 0 function 3 Intel 6321ESB PCIE-PCIX rev 0x01 pci9 at ppb8 bus 17 ppb9 at pci0 dev 3 function 0 Intel 5000 PCIE rev 0xb1 pci10 at ppb9 bus 6 ciss0 at pci10 dev 0 function 0 Hewlett-Packard Smart Array rev 0x04: apic 8 int 16 (irq 5) ciss0: 1 LD, HW rev 4, FW 4.12/4.12 scsibus0 at ciss0: 1 targets, initiator 1 sd0 at scsibus0 targ 0 lun 0:HP, LOGICAL
Re: OpenBSD 4.4
R0me0 *** knight.neo at gmail.com writes: It is a GENERIC kernel, the name is only copy of GENERIC.MP :) . As I said, it is a complex setup and I'm planning an upgrade. OpenBSD 4.4 (TENMA.MP) #3: Tue Jan 24 00:46:50 BRST 2012 root at ns1.mycompany.com:/home/**src/sys/arch/amd64/compile/TEN**MA.MPhttp://TENMA.MP While that may be true, R0me0, you are getting push back for three reasons: 1) Support for your release ended 18 October 2009. 2) Your dmesg is for a kernel built in 2012. Custom or not, the 4.4-release kernels were built for the project in August of 2008. 3) You have not articulated your complex situation. While your kernel may not be custom, it appears to be. And note what FAQ 5 says of custom kernels: * You will not get any support from developers. * You will be expected to reproduce any problem with a GENERIC kernel before developers take any problem report seriously. * Users and developers will laugh at you when you break your system. Upgrading to eliminate, or to receive support for your problem has already been recommended. Perhaps if you outlined your situation, instead of stating it is only complex, you might get more directly useful advice. Or, if you were to recreate your problem with a true 4.4-release GENERIC.MP -- you can find one at http://mirror.planetunix.net/pub/OpenBSD/4.4/amd64/bsd.mp if you no longer have one -- there may not be any direct support, but it would at least eliminate the questions over your TEMNA.MP kernel.
Re: OpenBSD 4.4
On Tue, Jan 24, 2012 at 10:35 AM, R0me0 *** knight@gmail.com wrote: It is a GENERIC kernel, the name is only copy of GENERIC.MP :) . As I said, it is a complex setup and I'm planning an upgrade. Well, you're doing the right thing. There have been *MANY* fixes to the network stack since 4.4, so updating to 5.0 as you plan is very very likely to resolve it. I'm not sure, though, if you're looking for something besides encouragement in doing that. With no information from the crash, there's no way anyone can say oh yeah, that was fixed in version 4.x, and even with that information it would just serve to confirm that you should do what you're already planning on doing and should do for other reasons. Even if it was a completely new bug and the crash trace proved it, the volume of changes in the code between 4.4 and current is such that reproducing it on a -current setup would be the first step... So, are you looking for something else? Philip Guenther
Re: OpenBSD 4.4
Doc, It hurts when I do that... Sent from my iPhone On Jan 24, 2012, at 1:27 PM, Philip Guenther guent...@gmail.com wrote: On Tue, Jan 24, 2012 at 10:35 AM, R0me0 *** knight@gmail.com wrote: It is a GENERIC kernel, the name is only copy of GENERIC.MP :) . As I said, it is a complex setup and I'm planning an upgrade. Well, you're doing the right thing. There have been *MANY* fixes to the network stack since 4.4, so updating to 5.0 as you plan is very very likely to resolve it. I'm not sure, though, if you're looking for something besides encouragement in doing that. With no information from the crash, there's no way anyone can say oh yeah, that was fixed in version 4.x, and even with that information it would just serve to confirm that you should do what you're already planning on doing and should do for other reasons. Even if it was a completely new bug and the crash trace proved it, the volume of changes in the code between 4.4 and current is such that reproducing it on a -current setup would be the first step... So, are you looking for something else? Philip Guenther
Re: OpenBSD 4.4
I'm not trying to help you not upgrade but my 4.9 box says Starting Nmap 5.21 ( http://nmap.org ) at 2012-01-24 15:13 CST Failed to resolve given hostname/IP: 10.20.0. Note that you can't use '/mask' AND '1-4,7,100-' style IP ranges WARNING: No targets were specified, so 0 hosts scanned. Nmap done: 0 IP addresses (0 hosts up) scanned in 0.13 seconds I'm pretty sure what you're giving nmap is invalid in your old version too, so unless this is an excercise in interesting ways to crash old software, I'd check my nmap input, in addition to upgrading my box. On Tue, Jan 24, 2012 at 2:32 PM, goodb0fh goodb...@gmail.com wrote: Doc, It hurts when I do that... Sent from my iPhone On Jan 24, 2012, at 1:27 PM, Philip Guenther guent...@gmail.com wrote: On Tue, Jan 24, 2012 at 10:35 AM, R0me0 *** knight@gmail.com wrote: It is a GENERIC kernel, the name is only copy of GENERIC.MP :) . As I said, it is a complex setup and I'm planning an upgrade. Well, you're doing the right thing. There have been *MANY* fixes to the network stack since 4.4, so updating to 5.0 as you plan is very very likely to resolve it. I'm not sure, though, if you're looking for something besides encouragement in doing that. With no information from the crash, there's no way anyone can say oh yeah, that was fixed in version 4.x, and even with that information it would just serve to confirm that you should do what you're already planning on doing and should do for other reasons. Even if it was a completely new bug and the crash trace proved it, the volume of changes in the code between 4.4 and current is such that reproducing it on a -current setup would be the first step... So, are you looking for something else? Philip Guenther
Re: OpenBSD 4.4
If you disable ddb it should print out a stack trace and attempt to dump to disk. Either of these might give information that could help track it down, though it might not do you any good, the areas you're most likely to run into problems have had *huge* changes since 4.4. On 2012-01-24, R0me0 *** knight@gmail.com wrote: Hello misc :) I'm running a full patched OpenBSD 4.4 with very complex setup, and I'm planning an upgrade to 5.0. At this moment, if I execute nmap 10.20.0/16, I have a dbg . I've limited the number of max connections and connections per seconds, that solved the problem. When dbg occurs, I cannot do a trace because it completely hangs. Following is a dmesg, any directions will be appreciated OpenBSD 4.4 (TENMA.MP) #3: Tue Jan 24 00:46:50 BRST 2012 r...@ns1.mycompany.com:/home/src/sys/arch/amd64/compile/TENMA.MP real mem = 2132389888 (2033MB) avail mem = 2070573056 (1974MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xee000 (68 entries) bios0: vendor HP version P58 date 08/03/2008 bios0: HP ProLiant DL360 G5 acpi0 at bios0: rev 2 acpi0: tables DSDT FACP SPCR MCFG HPET SPMI ERST APIC BERT HEST SSDT acpi0: wakeup devices PCI0(S5) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E5440 @ 2.83GHz, 2833.79 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,CX16,xTPR,LONG cpu0: 6MB 64b/line 16-way L2 cache cpu0: apic clock running at 333MHz cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) CPU E5440 @ 2.83GHz, 2833.44 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,CX16,xTPR,LONG cpu1: 6MB 64b/line 16-way L2 cache cpu2 at mainbus0: apid 1 (application processor) cpu2: Intel(R) Xeon(R) CPU E5440 @ 2.83GHz, 2833.44 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,CX16,xTPR,LONG cpu2: 6MB 64b/line 16-way L2 cache cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Xeon(R) CPU E5440 @ 2.83GHz, 2833.44 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,CX16,xTPR,LONG cpu3: 6MB 64b/line 16-way L2 cache ioapic0 at mainbus0 apid 8 pa 0xfec0, version 20, 24 pins ioapic1 at mainbus0 apid 9 pa 0xfec8, version 20, 24 pins acpiprt0 at acpi0: bus 1 (IP2P) acpiprt1 at acpi0: bus 11 (IPE1) acpiprt2 at acpi0: bus 10 (IPE4) acpiprt3 at acpi0: bus 17 (P2P2) acpiprt4 at acpi0: bus 9 (PT02) acpiprt5 at acpi0: bus 6 (PT03) acpiprt6 at acpi0: bus 20 (PT04) acpiprt7 at acpi0: bus 3 (NB01) acpiprt8 at acpi0: bus 5 (NB02) acpiprt9 at acpi0: bus 0 (PCI0) acpicpu0 at acpi0: C3 acpicpu1 at acpi0: C3 acpicpu2 at acpi0: C3 acpicpu3 at acpi0: C3 acpitz0 at acpi0: critical temperature 31 degC ipmi at mainbus0 not configured cpu0: unknown i686 model 7, can't get bus clockcpu0: EST: unknown system bus clock pci0 at mainbus0 bus 0: configuration mode 1 pchb0 at pci0 dev 0 function 0 Intel 5000P Host rev 0xb1 ppb0 at pci0 dev 2 function 0 Intel 5000 PCIE rev 0xb1 pci1 at ppb0 bus 9 ppb1 at pci1 dev 0 function 0 Intel 6321ESB PCIE rev 0x01 pci2 at ppb1 bus 10 ppb2 at pci2 dev 0 function 0 Intel 6321ESB PCIE rev 0x01 pci3 at ppb2 bus 11 ppb3 at pci3 dev 0 function 0 vendor IDT, unknown product 0x8018 rev 0x0e pci4 at ppb3 bus 12 ppb4 at pci4 dev 2 function 0 vendor IDT, unknown product 0x8018 rev 0x0e pci5 at ppb4 bus 13 em0 at pci5 dev 0 function 0 Intel PRO/1000 QP (82571EB) rev 0x06: apic 8 int 19 (irq 10), address 00:1f:29:5f:fe:b5 em1 at pci5 dev 0 function 1 Intel PRO/1000 QP (82571EB) rev 0x06: apic 8 int 18 (irq 10), address 00:1f:29:5f:fe:b4 ppb5 at pci4 dev 4 function 0 vendor IDT, unknown product 0x8018 rev 0x0e pci6 at ppb5 bus 14 em2 at pci6 dev 0 function 0 Intel PRO/1000 QP (82571EB) rev 0x06: apic 8 int 17 (irq 7), address 00:1f:29:5f:fe:b7 em3 at pci6 dev 0 function 1 Intel PRO/1000 QP (82571EB) rev 0x06: apic 8 int 16 (irq 5), address 00:1f:29:5f:fe:b6 ppb6 at pci2 dev 1 function 0 Intel 6321ESB PCIE rev 0x01 pci7 at ppb6 bus 15 ppb7 at pci2 dev 2 function 0 Intel 6321ESB PCIE rev 0x01 pci8 at ppb7 bus 16 ppb8 at pci1 dev 0 function 3 Intel 6321ESB PCIE-PCIX rev 0x01 pci9 at ppb8 bus 17 ppb9 at pci0 dev 3 function 0 Intel 5000 PCIE rev 0xb1 pci10 at ppb9 bus 6 ciss0 at pci10 dev 0 function 0 Hewlett-Packard Smart Array rev 0x04: apic 8 int 16 (irq 5) ciss0: 1 LD, HW rev 4, FW 4.12/4.12 scsibus0 at ciss0: 1 targets, initiator 1 sd0 at scsibus0 targ 0 lun 0: HP, LOGICAL VOLUME, 4.12
Re: OpenBSD 4.4
On 2012-01-24, R0me0 *** knight@gmail.com wrote: I'm running a full patched OpenBSD 4.4 with very complex setup I recommend simplifying the setup.
Re: OpenBSD 4.4
On 24/01/12 16:35 -0200, R0me0 *** wrote: It is a GENERIC kernel, the name is only copy of GENERIC.MP :) . As I said, it is a complex setup and I'm planning an upgrade. Cheers, Why on earth would you rename GENERIC?! Especially given the official amount of support for OpenBSD running kernels other than GENERIC (ie, None). Secondly, just upgrade. That's how to solve the problem. If you said your car wasn't running well but you're picking up a new Ferrari on Monday, I'd tell you to get the bus till Monday. -- richo || Today's excuse: Someone's tie is caught in the printer, and if anything else gets printed, he'll be in it too. http://blog.psych0tik.net [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: OpenBSD 4.4
R0me0 *** knight@gmail.com writes: I'm running a full patched OpenBSD 4.4 with very complex setup, and I'm planning an upgrade to 5.0. That's a seriously long jump, but then again, that upgrade may very well be a blessing in disguise -- an opportunity to identify what parts of your complex setup are actually just cascades of accidents that followed quasi-logically from other earlier accidents (no worries, this should sound familiar to most of the people who've been around for a while) and what actually matters and needs to be that way for a reason. Do take the time for proper preparations, though: at the very least read through the upgrade steps for each of the versions, starting from http://www.openbsd.org/faq/upgrade45.html and proceeding through http://www.openbsd.org/faq/upgrade50.html. The only *supported* method is to go through all of those upgrade steps, but you might find it easier to back up your data and config, do a clean install, restore data and then introduce those configuration elements that are in fact essential or at least useful for your particular environment. At this moment, if I execute nmap 10.20.0/16, I have a dbg . I've limited the number of max connections and connections per seconds, that solved the problem. When dbg occurs, I cannot do a trace because it completely hangs. Others have offered as useful input as can be had on those. Good luck with the upgrade! All the best, Peter -- 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: OpenBSD 4.4 : snmp for monitoring interfaces
From http://www.openbsd.org/security.html : OpenBSD 4.5 and earlier releases are not supported anymore. The following paragraphs only list advisories issued while they were maintained; these releases are likely to be affected by the advisories for more recent releases. On Fri, Jun 18, 2010 at 4:31 PM, Rioux, Christophe cri...@viseo.net wrote: Hi We tried to implemant a monitoring on a OpenBSD 4.4; I get an error message: index not found (monitoring via Cacti, means net-snmp). My Cacti server is hosted on another server. I check the OID per snmp: .1.3.6.1.2.1.2.2.1.1 (this OID search the interface, and go down to the values) * In the 4.3 version, I get a result * in the 4.4 version, there is an error = that's why cacti doesn't work and find any values. The other possibility is to build my own querries to build my graphs, so I check per snmpwalk the differences between a 4.3 version and 4.4 version. No big differences. As result I got following informations: SNMPv2-SMI::enterprises.64512.1.8.128.1.2.1 = STRING: all SNMPv2-SMI::enterprises.64512.1.8.128.1.2.2 = STRING: bge0 SNMPv2-SMI::enterprises.64512.1.8.128.1.2.3 = STRING: bge1 SNMPv2-SMI::enterprises.64512.1.8.128.1.6.1 = Counter64: 0 SNMPv2-SMI::enterprises.64512.1.8.128.1.6.2 = Counter64: 43789127 SNMPv2-SMI::enterprises.64512.1.8.128.1.6.3 = Counter64: 21828412 SNMPv2-SMI::enterprises.64512.1.8.128.1.6.4 = Counter64: 0 SNMPv2-SMI::enterprises.64512.1.8.128.1.6.5 = Counter64: 0 SNMPv2-SMI::enterprises.64512.1.8.128.1.6.6 = Counter64: 10085339 SNMPv2-SMI::enterprises.64512.1.8.128.1.6.7 = Counter64: 340191 SNMPv2-SMI::enterprises.64512.1.8.128.1.6.8 = Counter64: 22794680 SNMPv2-SMI::enterprises.64512.1.8.128.1.6.9 = Counter64: 0 SNMPv2-SMI::enterprises.64512.1.8.128.1.6.10 = Counter64: 0 SNMPv2-SMI::enterprises.64512.1.8.128.1.6.11 = Counter64: 0 SNMPv2-SMI::enterprises.64512.1.8.128.1.6.12 = Counter64: 1921 SNMPv2-SMI::enterprises.64512.1.8.128.1.6.13 = Counter64: 0 SNMPv2-SMI::enterprises.64512.1.8.128.1.6.14 = Counter64: 0 In the snmp result, how can I know which are the right values ? I know there is somewhere the download and upload dataflow, but where ? Maybe somebody does this work before and can help me ? Thanks for feedback Christophe
Re: OpenBSD 4.4 : snmp for monitoring interfaces
I saw on internet, there are the same issue on 4.6 and 4.7, but nowhere the answer how to -Message d'origine- From http://www.openbsd.org/security.html : OpenBSD 4.5 and earlier releases are not supported anymore. The following paragraphs only list advisories issued while they were maintained; these releases are likely to be affected by the advisories for more recent releases. On Fri, Jun 18, 2010 at 4:31 PM, Rioux, Christophe cri...@viseo.net wrote: Hi We tried to implemant a monitoring on a OpenBSD 4.4; I get an error message: index not found (monitoring via Cacti, means net-snmp). My Cacti server is hosted on another server. I check the OID per snmp: .1.3.6.1.2.1.2.2.1.1 (this OID search the interface, and go down to the values) * In the 4.3 version, I get a result * in the 4.4 version, there is an error = that's why cacti doesn't work and find any values. The other possibility is to build my own querries to build my graphs, so I check per snmpwalk the differences between a 4.3 version and 4.4 version. No big differences. As result I got following informations: SNMPv2-SMI::enterprises.64512.1.8.128.1.2.1 = STRING: all SNMPv2-SMI::enterprises.64512.1.8.128.1.2.2 = STRING: bge0 SNMPv2-SMI::enterprises.64512.1.8.128.1.2.3 = STRING: bge1 SNMPv2-SMI::enterprises.64512.1.8.128.1.6.1 = Counter64: 0 SNMPv2-SMI::enterprises.64512.1.8.128.1.6.2 = Counter64: 43789127 SNMPv2-SMI::enterprises.64512.1.8.128.1.6.3 = Counter64: 21828412 SNMPv2-SMI::enterprises.64512.1.8.128.1.6.4 = Counter64: 0 SNMPv2-SMI::enterprises.64512.1.8.128.1.6.5 = Counter64: 0 SNMPv2-SMI::enterprises.64512.1.8.128.1.6.6 = Counter64: 10085339 SNMPv2-SMI::enterprises.64512.1.8.128.1.6.7 = Counter64: 340191 SNMPv2-SMI::enterprises.64512.1.8.128.1.6.8 = Counter64: 22794680 SNMPv2-SMI::enterprises.64512.1.8.128.1.6.9 = Counter64: 0 SNMPv2-SMI::enterprises.64512.1.8.128.1.6.10 = Counter64: 0 SNMPv2-SMI::enterprises.64512.1.8.128.1.6.11 = Counter64: 0 SNMPv2-SMI::enterprises.64512.1.8.128.1.6.12 = Counter64: 1921 SNMPv2-SMI::enterprises.64512.1.8.128.1.6.13 = Counter64: 0 SNMPv2-SMI::enterprises.64512.1.8.128.1.6.14 = Counter64: 0 In the snmp result, how can I know which are the right values ? I know there is somewhere the download and upload dataflow, but where ? Maybe somebody does this work before and can help me ? Thanks for feedback Christophe
Re: OpenBSD 4.4 : snmp for monitoring interfaces
2010/6/18, Rioux, Christophe cri...@viseo.net: Hi We tried to implemant a monitoring on a OpenBSD 4.4; I get an error message: index not found (monitoring via Cacti, means net-snmp). My Cacti server is hosted on another server. So do we, our cacti is 0.8.7e, from some redhat repository quite some time ago. The monitored server runs 4.7-release with some minor patches. Oh, and the OpenBSD snmpd. Everything works out of the box. In the snmp result, how can I know which are the right values ? I know there is somewhere the download and upload dataflow, but where ? You don't need that. Push New Graph, then Create New Host, Generic SNMP-enabled host, SNMPv1 and properly set up community name. New Graph again, choose the host and your interfaces should be listed down there, ready to make graphs on. As simple as that. Please make sure you run the latest versions of all the software (or at least those that work for me). And finally don't forget to block snmp from those you don't expect the access from. Also, listen-on option in snmpd.conf is quite picky - even if you have multiple address on one interface, you need to specify the correct one. What snmp server do you run, at least? -- Martin Pelikan
Re: OpenBSD 4.4: dnsbl just for port 25 (not msa 587)
On Mon, Jun 22, 2009 at 9:59 PM, Dan Harnettdan...@harnett.name wrote: On Mon, Jun 22, 2009 at 07:19:09PM -0600, Alvaro Mantilla Gimenez wrote: According to the /usr/share/sendmail/README file, it is necessary to add the a modifier to the line that define the MSA: Additionally, by using the M=a modifier you can require authentication before messages are accepted by the MSA Actually, 'a' will only advertise that SMTP AUTH is available, it does not require it. You want to use 'l' to enforce it. DAEMON_OPTIONS(`Family=inet, Address=0.0.0.0, Port=587, Name=MSA, M=El')dnl This won't even allow mail to local recipients without authentication first. Hmm, this seems to not match the documentation in /usr/share/doc/smm/08.sendmailop: the meaning you give for the 'a' and 'l' flags are correct for the srv_features ruleset, but not for the DaemonPortOptions option. ... Authenticated users will skip the DNSBL checks if you use FEATURE(`delay_checks') in your .mc file. This is the easiest way to accomplish the original poster's goal, yes. Philip Guenther
Re: OpenBSD 4.4: dnsbl just for port 25 (not msa 587)
On Tue, Jun 23, 2009 at 07:33:15AM -0700, Philip Guenther wrote: Hmm, this seems to not match the documentation in /usr/share/doc/smm/08.sendmailop: the meaning you give for the 'a' and 'l' flags are correct for the srv_features ruleset, but not for the DaemonPortOptions option. My mistake. You're absolutely right.
Re: OpenBSD 4.4: dnsbl just for port 25 (not msa 587)
Hi, I added the FEATURE(`delay_checks') in the .mc file, keep it the line DAEMON_OPTIONS(`Family=inet, Address=0.0.0.0, Port=587, Name=MSA M=Ea')dnl and it seems everything is so far so good. I take note about the file on /usr/share/doc/smm/08.sendmailop too. Thanks so much both of you. Alvaro On Tue, 23 Jun 2009 07:33:15 -0700, Philip Guenther guent...@gmail.com wrote: On Mon, Jun 22, 2009 at 9:59 PM, Dan Harnettdan...@harnett.name wrote: On Mon, Jun 22, 2009 at 07:19:09PM -0600, Alvaro Mantilla Gimenez wrote: According to the /usr/share/sendmail/README file, it is necessary to add the a modifier to the line that define the MSA: Additionally, by using the M=a modifier you can require authentication before messages are accepted by the MSA Actually, 'a' will only advertise that SMTP AUTH is available, it does not require it. You want to use 'l' to enforce it. DAEMON_OPTIONS(`Family=inet, Address=0.0.0.0, Port=587, Name=MSA, M=El')dnl This won't even allow mail to local recipients without authentication first. Hmm, this seems to not match the documentation in /usr/share/doc/smm/08.sendmailop: the meaning you give for the 'a' and 'l' flags are correct for the srv_features ruleset, but not for the DaemonPortOptions option. ... Authenticated users will skip the DNSBL checks if you use FEATURE(`delay_checks') in your .mc file. This is the easiest way to accomplish the original poster's goal, yes. Philip Guenther
Re: OpenBSD 4.4: dnsbl just for port 25 (not msa 587)
Hi, The openbsd-proto.mc file has these lines: FEATURE(`no_default_msa')dnl DAEMON_OPTIONS(`Family=inet, Address=0.0.0.0, Name=MTA')dnl DAEMON_OPTIONS(`Family=inet6, Address=::, Name=MTA6, M=O')dnl DAEMON_OPTIONS(`Family=inet, Address=0.0.0.0, Port=587, Name=MSA, M=E')dnl DAEMON_OPTIONS(`Family=inet6, Address=::, Port=587, Name=MSA6, M=O, M=E')dnl According to the /usr/share/sendmail/README file, it is necessary to add the a modifier to the line that define the MSA: Additionally, by using the M=a modifier you can require authentication before messages are accepted by the MSA If I understood well the line: DAEMON_OPTIONS(`Family=inet, Address=0.0.0.0, Port=587, Name=MSA, M=E')dnl would be: DAEMON_OPTIONS(`Family=inet, Address=0.0.0.0, Port=587, Name=MSA, M=Ea')dnl and then the smtp auth must work on port 587. Why the original line (without the a modifier) port 587 requires authentication as well?. Is it implicit in other place? I already checked several times the send process with/without the a modifier and I needed the authentication in both cases all the times to be able to send an email trough the 587 port. My question is because, as I said in my previous email, I want to separate the dnsbl verification just for port 25 and let the clients to authenticate and send the email on port 587 without pass trough the dnsbl lists verifications (as is defined by the line FEATURE(`dnsbl', `zen.spamhaus.org' that I added to openbsd-proto.mc). I just add the a modifier and I noticed a little delay when the client software (thunderbird on this case) do the authentication process for send the email. My problem is that I have users that connect to the server with dynamic IP addresses and they are rejected after the authentication process because the IP is on the PBL list with this message: This IP range has been identified by Spamhaus as not meeting our policy for IPs which should deliver 'direct-to-mx' mail to PBL users. Spamhouse said that the only thing I need to avoid that error is to have SMTP AUTH enable on the server on port 587 (which I already have as my previous question about the lines on openbsd-proto.mc). Can I assume that the MSA configuration (with the a modifier) will authenticate the user and let him send the email without pass trough the PBL verification, just doing the authentication process? In case my assumption is not correct...is there any way to separate that without to run another sendmail process (with a separate configuration) on port 587? Sadly I can test it myself because my IP does not appear on PBL lists and my users will connect during my sleep time (I am 8 hours behind). Some light here will be appreciate. Regards Alvaro Alvaro Mantilla Gimenez wrote: Hello, Is there any way to apply dnsbl feature just on port 25 on the default openbsd sendmail configuration and do not apply that on port 587 (just auth smtp)? I googled it looking for answers but it seems people disabled dnsbl feature on sendmail and used it with spamassasin (which is not an option for me). Any advice? Thanks, Alvaro
Re: OpenBSD 4.4: dnsbl just for port 25 (not msa 587)
On Mon, Jun 22, 2009 at 07:19:09PM -0600, Alvaro Mantilla Gimenez wrote: According to the /usr/share/sendmail/README file, it is necessary to add the a modifier to the line that define the MSA: Additionally, by using the M=a modifier you can require authentication before messages are accepted by the MSA Actually, 'a' will only advertise that SMTP AUTH is available, it does not require it. You want to use 'l' to enforce it. DAEMON_OPTIONS(`Family=inet, Address=0.0.0.0, Port=587, Name=MSA, M=El')dnl This won't even allow mail to local recipients without authentication first. Why the original line (without the a modifier) port 587 requires authentication as well?. Is it implicit in other place? I already checked several times the send process with/without the a modifier and I needed the authentication in both cases all the times to be able to send an email trough the 587 port. How did you test this? Do you have any Srv_Features listed in your access map? Authentication is not required in the default config. In fact, it's not even available. Some clients (like Thunderbird, IIRC) will always try to authenticate if the mail server announces SMTP AUTH as a feature during the EHLO/HELO state. Are you sure you're not confusing an annoying client feature with enforcing authentication? Spamhouse said that the only thing I need to avoid that error is to have SMTP AUTH enable on the server on port 587 (which I already have as my previous question about the lines on openbsd-proto.mc). Authenticated users will skip the DNSBL checks if you use FEATURE(`delay_checks') in your .mc file. 587? Sadly I can test it myself because my IP does not appear on PBL lists and my users will connect during my sleep time (I am 8 hours behind). You can always setup your own test DNSBL that lists just your IP address.
Re: OpenBSD 4.4 amd64 bsd.mp can't detect 16GB memory
* Thomas Pfaff tpf...@tp76.info [2009-03-10 20:00]: OpenBSD does not currently support 4GB of RAM. that is not true. OpenBSD does not currently support more than 4GB of RAM on amd64, that is true. -- 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 - Hamburg Amsterdam
Re: OpenBSD 4.4 amd64 bsd.mp can't detect 16GB memory
Why are you asking question again? I googled your original question... damn it
Re: OpenBSD 4.4 amd64 bsd.mp can't detect 16GB memory
http://n2.nabble.com/OpenBSD-4.4-amd64-bsd.mp-can%27t-detect-16GB-memory-td24 57053.html Took me less time find it than it took for you to e-mail... On Tue, Mar 17, 2009 at 13:13, Prakshep Dineshchandra Patel ppate...@stevens.edu wrote: Hi all i check again and i installed openbsd 4.4 amd 64. I compiled kernel again and i got dmsg. (i thing those are same) what i did, set 'int bigmem = 1;' in 'arch/amd64/amd64/machdep.c' (Though it already set to 1 i just check it) - compile the kernel B except for the last step (make install) I compiled B GENERIC.MP .. and try to boot with that but it will give me same msg... can you take a look at this, OpenBSD 4.4 (GENERIC.MP) #1812: Tue Aug 12 17:22:53 MDT 2008 B B dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 3202969600 (3054MB) avail mem = 3106160640 (2962MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xbfb9c000 (67 entries) bios0: vendor Dell Inc. version 2.3.1 date 04/29/2008 bios0: Dell Inc. PowerEdge 1950 acpi0 at bios0: rev 2 acpi0: tables DSDT FACP APIC SPCR HPET MCFG WD__ SLIC ERST HEST BERT EINJ TCPA acpi0: wakeup devices PCI0(S5) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E5450 @ 3.00GHz, 2992.90 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36, CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST ,TM2,CX16,xTPR,NXE,LONG cpu0: 6MB 64b/line 16-way L2 cache cpu0: apic clock running at 332MHz cpu1 at mainbus0: apid 4 (application processor) cpu1: Intel(R) Xeon(R) CPU E5450 @ 3.00GHz, 2992.50 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36, CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST ,TM2,CX16,xTPR,NXE,LONG cpu1: 6MB 64b/line 16-way L2 cache cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Xeon(R) CPU E5450 @ 3.00GHz, 2992.50 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36, CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST ,TM2,CX16,xTPR,NXE,LONG cpu2: 6MB 64b/line 16-way L2 cache cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Xeon(R) CPU E5450 @ 3.00GHz, 2992.50 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36, CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST ,TM2,CX16,xTPR,NXE,LONG cpu3: 6MB 64b/line 16-way L2 cache cpu4 at mainbus0: apid 1 (application processor) cpu4: Intel(R) Xeon(R) CPU E5450 @ 3.00GHz, 2992.50 MHz cpu4: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36, CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST ,TM2,CX16,xTPR,NXE,LONG cpu4: 6MB 64b/line 16-way L2 cache cpu5 at mainbus0: apid 5 (application processor) cpu5: Intel(R) Xeon(R) CPU E5450 @ 3.00GHz, 2992.50 MHz cpu5: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36, CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST ,TM2,CX16,xTPR,NXE,LONG cpu5: 6MB 64b/line 16-way L2 cache cpu6 at mainbus0: apid 3 (application processor) cpu6: Intel(R) Xeon(R) CPU E5450 @ 3.00GHz, 2992.50 MHz cpu6: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36, CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST ,TM2,CX16,xTPR,NXE,LONG cpu6: 6MB 64b/line 16-way L2 cache cpu7 at mainbus0: apid 7 (application processor) cpu7: Intel(R) Xeon(R) CPU E5450 @ 3.00GHz, 2992.50 MHz cpu7: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36, CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST ,TM2,CX16,xTPR,NXE,LONG cpu7: 6MB 64b/line 16-way L2 cache ioapic0 at mainbus0 apid 8 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 0, remapped to apid 8 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 4 (PEX2) acpiprt2 at acpi0: bus 5 (UPST) acpiprt3 at acpi0: bus 6 (DWN1) acpiprt4 at acpi0: bus 8 (DWN2) acpiprt5 at acpi0: bus 1 (PEX3) acpiprt6 at acpi0: bus 0 (PE2P) acpiprt6: no apic found for irq 64 acpiprt6: no apic found for irq 65 acpiprt6: no apic found for irq 78 acpiprt7 at acpi0: bus 10 (PEX4) acpiprt8 at acpi0: bus 13 (PEX6) acpiprt9 at acpi0: bus 2 (SBEX) acpiprt10 at acpi0: bus 15 (COMP) acpicpu0 at acpi0: C3 acpicpu1 at acpi0: C3 acpicpu2 at acpi0: C3 acpicpu3 at acpi0: C3 acpicpu4 at acpi0: C3 acpicpu5 at acpi0: C3 acpicpu6 at acpi0: C3 acpicpu7 at acpi0: C3 ipmi at mainbus0 not configured cpu0: unknown i686 model 7, can't get bus clockcpu0: EST: unknown system bus clock pci0 at mainbus0 bus 0: configuration mode 1 pchb0 at pci0 dev 0 function 0 Intel 5000X Host rev 0x12 ppb0 at pci0 dev 2 function 0 Intel 5000 PCIE rev 0x12 pci1 at ppb0 bus 4 ppb1 at
Re: OpenBSD 4.4 amd64 bsd.mp can't detect 16GB memory
I just forgot to mention that, When i run the custom kernel (e.g. bsd44.bigmem) the output is similar to the stock kernel. Prakshep Dineshchandra Patel wrote: Hi all i check again and i installed openbsd 4.4 amd 64. I compiled kernel again and i got dmsg. (i thing those are same) what i did, set 'int bigmem = 1;' in 'arch/amd64/amd64/machdep.c' (Though it already set to 1 i just check it) - compile the kernel except for the last step (make install) I compiled GENERIC.MP .. and try to boot with that but it will give me same msg... can you take a look at this, OpenBSD 4.4 (GENERIC.MP) #1812: Tue Aug 12 17:22:53 MDT 2008 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 3202969600 (3054MB) avail mem = 3106160640 (2962MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xbfb9c000 (67 entries) bios0: vendor Dell Inc. version 2.3.1 date 04/29/2008 bios0: Dell Inc. PowerEdge 1950 acpi0 at bios0: rev 2 acpi0: tables DSDT FACP APIC SPCR HPET MCFG WD__ SLIC ERST HEST BERT EINJ TCPA acpi0: wakeup devices PCI0(S5) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E5450 @ 3.00GHz, 2992.90 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36, CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST ,TM2,CX16,xTPR,NXE,LONG cpu0: 6MB 64b/line 16-way L2 cache cpu0: apic clock running at 332MHz cpu1 at mainbus0: apid 4 (application processor) cpu1: Intel(R) Xeon(R) CPU E5450 @ 3.00GHz, 2992.50 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36, CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST ,TM2,CX16,xTPR,NXE,LONG cpu1: 6MB 64b/line 16-way L2 cache cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Xeon(R) CPU E5450 @ 3.00GHz, 2992.50 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36, CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST ,TM2,CX16,xTPR,NXE,LONG cpu2: 6MB 64b/line 16-way L2 cache cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Xeon(R) CPU E5450 @ 3.00GHz, 2992.50 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36, CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST ,TM2,CX16,xTPR,NXE,LONG cpu3: 6MB 64b/line 16-way L2 cache cpu4 at mainbus0: apid 1 (application processor) cpu4: Intel(R) Xeon(R) CPU E5450 @ 3.00GHz, 2992.50 MHz cpu4: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36, CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST ,TM2,CX16,xTPR,NXE,LONG cpu4: 6MB 64b/line 16-way L2 cache cpu5 at mainbus0: apid 5 (application processor) cpu5: Intel(R) Xeon(R) CPU E5450 @ 3.00GHz, 2992.50 MHz cpu5: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36, CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST ,TM2,CX16,xTPR,NXE,LONG cpu5: 6MB 64b/line 16-way L2 cache cpu6 at mainbus0: apid 3 (application processor) cpu6: Intel(R) Xeon(R) CPU E5450 @ 3.00GHz, 2992.50 MHz cpu6: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36, CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST ,TM2,CX16,xTPR,NXE,LONG cpu6: 6MB 64b/line 16-way L2 cache cpu7 at mainbus0: apid 7 (application processor) cpu7: Intel(R) Xeon(R) CPU E5450 @ 3.00GHz, 2992.50 MHz cpu7: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36, CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST ,TM2,CX16,xTPR,NXE,LONG cpu7: 6MB 64b/line 16-way L2 cache ioapic0 at mainbus0 apid 8 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 0, remapped to apid 8 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 4 (PEX2) acpiprt2 at acpi0: bus 5 (UPST) acpiprt3 at acpi0: bus 6 (DWN1) acpiprt4 at acpi0: bus 8 (DWN2) acpiprt5 at acpi0: bus 1 (PEX3) acpiprt6 at acpi0: bus 0 (PE2P) acpiprt6: no apic found for irq 64 acpiprt6: no apic found for irq 65 acpiprt6: no apic found for irq 78 acpiprt7 at acpi0: bus 10 (PEX4) acpiprt8 at acpi0: bus 13 (PEX6) acpiprt9 at acpi0: bus 2 (SBEX) acpiprt10 at acpi0: bus 15 (COMP) acpicpu0 at acpi0: C3 acpicpu1 at acpi0: C3 acpicpu2 at acpi0: C3 acpicpu3 at acpi0: C3 acpicpu4 at acpi0: C3 acpicpu5 at acpi0: C3 acpicpu6 at acpi0: C3 acpicpu7 at acpi0: C3 ipmi at mainbus0 not configured cpu0: unknown i686 model 7, can't get bus clockcpu0: EST: unknown system bus clock pci0 at mainbus0 bus 0: configuration mode 1 pchb0 at pci0 dev 0 function 0 Intel 5000X Host rev 0x12 ppb0 at pci0 dev 2 function 0 Intel 5000 PCIE rev 0x12 pci1 at ppb0 bus 4 ppb1 at pci1 dev 0 function 0 Intel 6321ESB PCIE rev 0x01 pci2 at ppb1 bus 5 ppb2 at pci2 dev 0 function 0 Intel 6321ESB PCIE rev 0x01 pci3 at ppb2 bus 6 ppb3 at pci3 dev 0 function 0
Re: OpenBSD 4.4 amd64 bsd.mp can't detect 16GB memory
On 2009-03-17, Prakshep Dineshchandra Patel ppate...@stevens.edu wrote: Hi all i check again and i installed openbsd 4.4 amd 64. I compiled kernel again and i got dmsg. (i thing those are same) what i did, set 'int bigmem = 1;' in 'arch/amd64/amd64/machdep.c' (Though it already set to 1 i just check it) - compile the kernel except for the last step (make install) I compiled GENERIC.MP .. and try to boot with that but it will give me same msg... can you take a look at this, OpenBSD 4.4 (GENERIC.MP) #1812: Tue Aug 12 17:22:53 MDT 2008 It doesn't seem you're running the self-compiled kernel you think you are.
Re: OpenBSD 4.4 amd64 bsd.mp can't detect 16GB memory
Prakshep Dineshchandra Patel wrote: Hi every one, I have installed OpenBSD 4.4 amd64 on Dell PowerEdge 1950 which contain 16GB of ram. As in that kernel 'BigMem' is already set to 1. But during boot time I can see 4GB instead of 16GB ram. When I use 'Top' command it will shows around 8GB ram. Any suggestions from any one how to solve this problem? I'm afraid I can't solve your problem but the following information might be useful: - the actual data of things you see You make some claims on things you see, but you don't show the actual data. - output of the boot loader's 'probing' line The boot loader prints something like: Loading... probing: pc0 com0 ... mem[... a20=on] If I'm not mistaken the mem[... a20=on] part shows the sizes of the memory blocks detected by querying the BIOS. Adding up these sizes should give an idea of how much memory is reported to the OS by the BIOS. - output of 'dmesg |grep mem' Something like: real mem = ??? (???MB) avail mem = ??? (???MB) spdmem0 at iic0 addr 0x50: ??? This should give an idea of how much memory the OS is actually using. It may also print spdmem entries giving an idea of what memory is physically installed/detected.
Re: OpenBSD 4.4 amd64 bsd.mp can't detect 16GB memory
On Tue, 10 Mar 2009 14:07:55 -0400 (EDT) Prakshep Dineshchandra Patel ppate...@stevens.edu wrote: Hi every one, I have installed OpenBSD 4.4 amd64 on Dell PowerEdge 1950 which contain 16GB of ram. As in that kernel 'BigMem' is already set to 1. But during boot time I can see 4GB instead of 16GB ram. When I use 'Top' command it will shows around 8GB ram. Any suggestions from any one how to solve this problem? OpenBSD does not currently support 4GB of RAM. Check the archives (http://marc.info) for various war stories.
Re: Openbsd 4.4 and openbgp current problems
On Tue, 10 Feb 2009 17:39:50 +0700, Esa Kuusisto esa.kuusi...@gmail.com wrote: Hi I have samekind of panic problems with two different openbgp routers. All I get panic: rtfree 2 before dump. I was searching if someone else have samekind of problem via google and you're only one. My only question is that did you get any solution for the problem? Best Regards -Esa Kuusisto Hi, I already send my PR, I haven't found any solution for this problem. On S3200 it panicked, on S3000AH it went freeze. Thanks, -- insandotpraja(at)gmaildotcom
Re: OpenBSD 4.4-release; Lockup after enabling 2nd NIC; both are Linksys EG1032
Yes. Sorry for the self-contradiction. It's been a long day. Just to be sure, I re-installed Ubuntu, and I'm currently doing a system software upgrade with one NIC, and am logged in over the other NIC and running top. (Plus it sees the onboard NIC, but I don't have anything plugged into that.) John On Sun, Feb 8, 2009 at 5:07 PM, patrick keshishian pkesh...@gmail.com wrote: On Sun, Feb 8, 2009 at 4:51 PM, John Mark Schofield r...@sudosu.net wrote: This is looking to me like a bad slot on the motherboard. Which stinks, as this machine is out of warranty. Anyone have any further troubleshooting suggestions? Didn't you state earlier that you had tried the system with Ubuntu and the two NICs worked flawlessly? On Sat, Feb 7, 2009 at 8:02 PM, John Schofield jschofi...@gmail.com wrote: To further attempt to rule out bad hardware, I installed Linux (Ubuntu 8.10). Both NICs operated flawlessly. (I realize that this is not conclusive, as different OS's can exercise hardware in different ways.) -- --- Got root? http://blog.sudosu.net
Re: OpenBSD 4.4-release; Lockup after enabling 2nd NIC; both are Linksys EG1032
John Schofield schrieb: I'm new to OpenBSD, so I may be doing something stupid. But Google, the FAQ, and other resources have not shed any light. I'm attempting to set up an IBM ThinkCentre desktop PC as a router/firewall for my home network. OpenBSD did not recognize the onboard NIC, and it did not appear on the supported hardware list as far as I could tell, so I purchased two Linksys Gigabit NICs that were listed. (EG1032, probably V3, as they show up as re0 and re1.) I also disabled the onboard NIC in BIOS. When doing the install from the CD (OpenBSD 4.4-release), if I configure re0 ONLY, everything works fine. If I also give re1 an IP, the system locks up with no error message printed. I was able to install successfully by only configuring re0. Once installed and booted from the internal HD, I attempted to enable re1. I got the same symptom -- system freeze with no error message upon attempting to activate the card. This was the same whether I activated the card via sh /etc/netstart or whether I rebooted. I swapped cards and cabling, thinking that I had a bad card. The behavior continued unchanged. The re0 (which had been re1) card worked, and activating the re1 card (which used to be re0) locked the system. For the record, my /etc/hostname.re0 currently in use is: inet 192.168.1.20 255.255.255.0 NONE The hostname.re1 (currently in my /root directory) is: inet 10.10.10.1 255.255.255.0 NONE To further attempt to rule out bad hardware, I installed Linux (Ubuntu 8.10). Both NICs operated flawlessly. (I realize that this is not conclusive, as different OS's can exercise hardware in different ways.) After reinstalling OpenBSD and replicating the issue, I was unable to find any further troubleshooting information or logs which indicated what the problem was. I'm attaching dmesg output (dmesg.txt), /var/run/dmesg.boot, and my /var/log/messages. I welcome suggestions as to solutions or further troubleshooting steps. (All of the above logs were gathered after booting to single-user mode, moving /etc/hostname.re1 to the /root directory, and rebooting.) John Schofield OpenBSD 4.4 (GENERIC) #1021: Tue Aug 12 17:16:55 MDT 2008 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel(R) Pentium(R) 4 CPU 2.93GHz (GenuineIntel 686-class) 2.93 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,TM2,CNXT-ID,xTPR real mem = 795373568 (758MB) avail mem = 760115200 (724MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 05/25/05, BIOS32 rev. 0 @ 0xfd6ec, SMBIOS rev. 2.34 @ 0xefb60 (49 entries) bios0: vendor IBM version 2FKT15AUS date 05/25/2005 bios0: IBM 813116U acpi0 at bios0: rev 0 acpi0: tables DSDT FACP TCPA APIC BOOT MCFG acpi0: wakeup devices EXP0(S5) EXP1(S5) EXP2(S5) EXP3(S5) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USBE(S3) SLOT(S5) KBC_(S3) PSM_(S3) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG_) acpiprt2 at acpi0: bus 2 (EXP0) acpiprt3 at acpi0: bus -1 (EXP1) acpiprt4 at acpi0: bus -1 (EXP2) acpiprt5 at acpi0: bus -1 (EXP3) acpiprt6 at acpi0: bus 10 (SLOT) acpicpu0 at acpi0 acpitz0 at acpi0: critical temperature 255 degC acpibtn0 at acpi0: PWRB bios0: ROM list: 0xc/0xaa00! 0xe/0x1! cpu0 at mainbus0 pci0 at mainbus0 bus 0: configuration mode 1 (no bios) pchb0 at pci0 dev 0 function 0 Intel 82915G Host rev 0x04 vga1 at pci0 dev 2 function 0 Intel 82915G Video rev 0x04 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) agp0 at vga1: aperture at 0xc000, size 0x1000 drm at vga1 unsupported ppb0 at pci0 dev 28 function 0 Intel 82801FB PCIE rev 0x03: irq 3 pci1 at ppb0 bus 2 bge0 at pci1 dev 0 function 0 Broadcom BCM5751 rev 0x11: can't find mem space uhci0 at pci0 dev 29 function 0 Intel 82801FB USB rev 0x03: irq 11 uhci1 at pci0 dev 29 function 1 Intel 82801FB USB rev 0x03: irq 9 uhci2 at pci0 dev 29 function 2 Intel 82801FB USB rev 0x03: irq 10 ehci0 at pci0 dev 29 function 7 Intel 82801FB USB rev 0x03: irq 11 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 ppb1 at pci0 dev 30 function 0 Intel 82801BA Hub-to-PCI rev 0xd3 pci2 at ppb1 bus 10 re0 at pci2 dev 0 function 0 Linksys EG1032 rev 0x10: RTL8169S (0x0400), irq 12, address 00:1e:e5:d7:4e:0b rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 0 re1 at pci2 dev 1 function 0 Linksys EG1032 rev 0x10: RTL8169S (0x0400), irq 10, address 00:1e:e5:d7:4e:3b rgephy1 at re1 phy 7: RTL8169S/8110S PHY, rev. 0 auich0 at pci0 dev 30 function 2 Intel 82801FB AC97 rev 0x03: irq 3, ICH6 AC97 ac97: codec id 0x41445368 (Analog Devices AD1888) ac97: codec features headphone, 20 bit DAC, No 3D Stereo audio0 at auich0 ichpcib0 at pci0 dev 31 function 0 Intel 82801FB LPC rev 0x03: PM disabled pciide0 at pci0 dev 31 function 2 Intel 82801FB SATA rev 0x03: DMA, channel 0
Re: OpenBSD 4.4-release; Lockup after enabling 2nd NIC; both are Linksys EG1032
Thanks very much, Dorian, Stijn, and Stuart: I upgraded to 4.4-Current dated February 6. No change in symptoms. It occurred to me that I had eliminated hardware problems with the cards, but not with the PCI slots. So I moved /etc/hostname.re0 to /root, and booted with re1 enabled. Freeze. Next I removed re0, to see whether I actually have a bad slot. But of course, with only one NIC (in the bottom PCI slot) it showed up as re0 instead of re1. And the system froze while attempting to enable it. So it's not having two NICs enabled that's a problem, it's having a nic enabled in the bottom slot that's a problem. I could not see a way in the BIOS (Damn Lenovo crippled BIOS) to set IRQs directly for cards. I did turn on PNP OS, which did not seem to make a difference. I next disabled all USB support through BIOS. (I'm able to do this with no consequences because I'm using a PS/2 keyboard and no mouse.) But the symptoms were unchanged; freeze after starting network at boot. I next tried to deactivate ACPI, but found only controls for selecting S1 or S3 states, and which IRQ ACPI should use. (Currently set to IRQ 9.) Just for the hell of it, I also disabled onboard sound and the parallel port. No change in symptoms. I re-enabled the onboard NIC, but the snapshot doesn't recognize it either. (At least, ifconfig doesn't show it.) I then put in a known-good (previously used in this system under OpenBSD) wireless NIC in the bottom slot. Same symptoms once I copied /root/hostname.re1 to /etc/hostname.ath0. This is looking to me like a bad slot on the motherboard. Which stinks, as this machine is out of warranty. Anyone have any further troubleshooting suggestions? John On Sun, Feb 8, 2009 at 3:02 PM, Dorian B|ttner dorian.buett...@gmx.de wrote: John Schofield schrieb: I'm new to OpenBSD, so I may be doing something stupid. But Google, the FAQ, and other resources have not shed any light. I'm attempting to set up an IBM ThinkCentre desktop PC as a router/firewall for my home network. OpenBSD did not recognize the onboard NIC, and it did not appear on the supported hardware list as far as I could tell, so I purchased two Linksys Gigabit NICs that were listed. (EG1032, probably V3, as they show up as re0 and re1.) I also disabled the onboard NIC in BIOS. When doing the install from the CD (OpenBSD 4.4-release), if I configure re0 ONLY, everything works fine. If I also give re1 an IP, the system locks up with no error message printed. I was able to install successfully by only configuring re0. Once installed and booted from the internal HD, I attempted to enable re1. I got the same symptom -- system freeze with no error message upon attempting to activate the card. This was the same whether I activated the card via sh /etc/netstart or whether I rebooted. I swapped cards and cabling, thinking that I had a bad card. The behavior continued unchanged. The re0 (which had been re1) card worked, and activating the re1 card (which used to be re0) locked the system. For the record, my /etc/hostname.re0 currently in use is: inet 192.168.1.20 255.255.255.0 NONE The hostname.re1 (currently in my /root directory) is: inet 10.10.10.1 255.255.255.0 NONE To further attempt to rule out bad hardware, I installed Linux (Ubuntu 8.10). Both NICs operated flawlessly. (I realize that this is not conclusive, as different OS's can exercise hardware in different ways.) After reinstalling OpenBSD and replicating the issue, I was unable to find any further troubleshooting information or logs which indicated what the problem was. I'm attaching dmesg output (dmesg.txt), /var/run/dmesg.boot, and my /var/log/messages. I welcome suggestions as to solutions or further troubleshooting steps. (All of the above logs were gathered after booting to single-user mode, moving /etc/hostname.re1 to the /root directory, and rebooting.) John Schofield OpenBSD 4.4 (GENERIC) #1021: Tue Aug 12 17:16:55 MDT 2008 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel(R) Pentium(R) 4 CPU 2.93GHz (GenuineIntel 686-class) 2.93 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,TM2,CNXT-ID,xTPR real mem = 795373568 (758MB) avail mem = 760115200 (724MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 05/25/05, BIOS32 rev. 0 @ 0xfd6ec, SMBIOS rev. 2.34 @ 0xefb60 (49 entries) bios0: vendor IBM version 2FKT15AUS date 05/25/2005 bios0: IBM 813116U acpi0 at bios0: rev 0 acpi0: tables DSDT FACP TCPA APIC BOOT MCFG acpi0: wakeup devices EXP0(S5) EXP1(S5) EXP2(S5) EXP3(S5) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USBE(S3) SLOT(S5) KBC_(S3) PSM_(S3) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG_) acpiprt2 at acpi0: bus 2 (EXP0) acpiprt3 at acpi0: bus -1 (EXP1) acpiprt4 at acpi0: bus -1 (EXP2) acpiprt5 at acpi0: bus -1
Re: OpenBSD 4.4-release; Lockup after enabling 2nd NIC; both are Linksys EG1032
On Sun, Feb 8, 2009 at 4:51 PM, John Mark Schofield r...@sudosu.net wrote: This is looking to me like a bad slot on the motherboard. Which stinks, as this machine is out of warranty. Anyone have any further troubleshooting suggestions? Didn't you state earlier that you had tried the system with Ubuntu and the two NICs worked flawlessly? On Sat, Feb 7, 2009 at 8:02 PM, John Schofield jschofi...@gmail.com wrote: To further attempt to rule out bad hardware, I installed Linux (Ubuntu 8.10). Both NICs operated flawlessly. (I realize that this is not conclusive, as different OS's can exercise hardware in different ways.)
Re: OpenBSD 4.4 pf+vlan+bridge problem
Hi! Wouldn't it be better to not use the bridge and use (multicast-)routing and pf to solve your problem? Multicast routing with dvrmpd is tested with pf, does not work. the same thing happens, if streamX is allowed to pass out on vlanX and streamY is allowed to pass out on vlanY, result is pretty similar: vlanX outputs both streams (streamX, streamY) and the same thing with vlanY. pf is not 100% percent multicast compat.? Since these days i tried out anyway how multicast routing is and decided to set up also similar configuration as described in the beginning of this thread assuming for pf multicast traffic is no different from any other 'ordinary' traffic. I believe the reason why with a rule like this pass out quick on vlan1101 proto udp from any to 239.16.1.1 you see the same traffic on every interface which is set up to multicast is because how pf decides to pass packets. Default state-policy is floating and it means that decision to pass traffic is based on packet's direction and src and dst ip and ports and not on what interface packet leaves (or enters). Normally this is ok and as i understand this approach for example saves memory not to keep information which excact interface is used for passing. But problem arises with multicast traffic as src ja dst addresses and ports are the same. I tried and adding 'keep state (if-bound)' seems to solve the problem. Imre Actually i experimented with tags, something like this .. pass in quick on $if_onelan inet to 239.x.x.x keep state (if-bound) tag MC pass out quick on $if_otherlan keep state (if-bound) tagged MC ...
Re: OpenBSD 4.4 load balance outgoing
Am Tue, 20 Jan 2009 21:57:59 + (UTC) schrieb Stuart Henderson s...@spacehopper.org: On 2009-01-20, u...@o3si.de u...@o3si.de wrote: as the FAQ http://www.openbsd.org/faq/faq6.html#Multipath states: It's worth noting that if an interface used by a multipath route goes down (i.e., loses carrier), the kernel will still try to forward packets using the route that points to that interface. the FAQ refers to 4.4 (i.e. the last released version), but I'm pretty sure this particular thing (link down resulting in blackhole) is not a problem in -current. Oh, I hope this. The same behaviour I already noticed like Ricardo so I give -current a try. you may still have a need for some other way to kill the route if the link stays up but the nexthop is down, though. I'll prefer ifstated but relayd for monitoring may bee a solution too. So use ifstated to check the link of the interface and populate the routing table accordingly. as an alternative to ifstated, you could take default routes from OSPF if your environment allows. (ospfd is ECMP capable). Thanks @Claudio and @Stuart for Your advice! Regards Uwe
Re: OpenBSD 4.4 pf+vlan+bridge problem
Key Aavoja schrieb: Hello, Hello, first thing: I do not have any experience with multicast traffic. But what you have build seems very strange to me. First you use vlan to separate the networks an then you put them alltogether with a bridge. I do not see the use of the vlans. Wouldn't it be better to not use the bridge and use (multicast-)routing and pf to solve your problem? As I said, I have no experience with multicast traffic, but that is how I would start digging. guido I have a problem with pf+bridge+vlan (multicast traffic) and I googled a lot, read the manuals and so on - no help. Finally I posted on wrong place :( sorry. Hopefully this time I'm writing to right place. Following setup is made for multicast traffic separation from one lan to multiple vlans. Setup: Two physical interfaces bnx0 bnx1 interfaces bnx0 and bnx1 has vlans: bnx0 vlan1100 bnx1 vlan1101 vlan1102 vlan1103 vlan1104 vlan1105 vlan1106 vlan1107 vlan1108 Bridge setup: bridge0 has all vlans as bridge members (vlan1100, vlan1101 ... vlan1108) PF config: block out on bnx1 all block out on vlan1100 all block out on vlan1101 all block out on vlan1102 all block out on vlan1103 all block out on vlan1104 all block out on vlan1105 all block out on vlan1106 all block out on vlan1107 all block out on vlan1108 all pass out quick on vlan1101 proto udp from any to 239.16.1.1 pass out quick on vlan1102 proto udp from any to 239.16.1.2 pass out quick on vlan1103 proto udp from any to 239.16.1.3 Wishful thinking, what the result should be: All multicast streams are available on vlan1100 and recieved via bnx0/vlan1100. Bridge should stream the multicast packets to what ever vlan - its the place where pf should help. Stream: 239.16.1.1 should be available only on vlan1101, and 239.16.1.2 avialable on vlan1102 and so on. . Real Result: Stream 239.16.1.1 is available on all three vlans: 11101,1102,1103 - same thing happens with other two streams (239.16.1.2, 239.16.1.3) It's really weird what's going on or did I understood something wrong and configuration is not correct? Thank you. -
Re: OpenBSD 4.4 pf+vlan+bridge problem
On 2009-01-20, Guido Tschakert guido.tschak...@src-gmbh.de wrote: first thing: I do not have any experience with multicast traffic. But what you have build seems very strange to me. First you use vlan to separate the networks an then you put them alltogether with a bridge. I do not see the use of the vlans. It can indeed be useful to do this, even without multicast traffic in the equation. You might want to filter traffic between machines in the same subnet, and this is a way you can do it. Key Aavoja schrieb: PF config: block out on bnx1 all block out on vlan1100 all block out on vlan1101 all block out on vlan1102 all block out on vlan1103 all block out on vlan1104 all block out on vlan1105 all block out on vlan1106 all block out on vlan1107 all block out on vlan1108 all pass out quick on vlan1101 proto udp from any to 239.16.1.1 pass out quick on vlan1102 proto udp from any to 239.16.1.2 pass out quick on vlan1103 proto udp from any to 239.16.1.3 Wishful thinking, what the result should be: All multicast streams are available on vlan1100 and recieved via bnx0/vlan1100. Bridge should stream the multicast packets to what ever vlan - its the place where pf should help. Stream: 239.16.1.1 should be available only on vlan1101, and 239.16.1.2 avialable on vlan1102 and so on. . Real Result: Stream 239.16.1.1 is available on all three vlans: 11101,1102,1103 - same thing happens with other two streams (239.16.1.2, 239.16.1.3) It's really weird what's going on or did I understood something wrong and configuration is not correct? you should check the simple things first. - is PF enabled? pfctl -si - is the ruleset loaded correctly? pfctl -sr - does it correctly block ordinary non-multicast traffic between the vlans? if you did indeed include your whole PF config in your email, only that particular multicast traffic should pass between the vlans, everything else should be blocked. you might have already done this, but if you did, you should have mentioned in your email what you checked. with a routed (not bridged) environment, PF is able to control multicast traffic in either direction (I just tried). from my reading of if_bridge.c, on a bridge, pf filtering for multicast frames only happens _inbound_. multicast frames sent _out_ through a bridge are not subject to the outbound PF filter rules. bridge MAC filter rules _are_ applied outbound for multicast frames, I haven't tested but I think that will give you a way you can restrict this traffic.
Re: OpenBSD 4.4 load balance outgoing
On Tue, Jan 20, 2009 at 03:04:36PM -0200, Ricardo Augusto de Souza wrote: Hi, I need a help to configure an openBSD server to load balance and failover internet connection. I have 2 connections to the internet. I followed http://www.openbsd.org/faq/pf/pools.html#outgoing but i didn4t get it working. I added both routes with: route add -mpath default 200.162.41.33 route add -mpath default 189.57.43.1 There was a nasty bug in the multipath code that got fixed a few weeks ago. If possible try -current. -- :wq Claudio
Re: OpenBSD 4.4 load balance outgoing
Hi,
I need a help to configure an openBSD server to load balance and
failover internet connection.
I have 2 connections to the internet.
I followed http://www.openbsd.org/faq/pf/pools.html#outgoing but i
didn4t get it working.
I added both routes with:
route add -mpath default 200.162.41.33
route add -mpath default 189.57.43.1
My confs are:
# cat sysctl.conf |grep inet
net.inet.ip.forwarding=1# 1=Permit forwarding (routing) of
IPv4 packets
net.inet.ip.mforwarding=1 # 1=Permit forwarding (routing) of
IPv4 multicast packets
net.inet.ip.multipath=1 # 1=Enable IP multipath routing
#net.inet6.ip6.forwarding=1 # 1=Permit forwarding (routing) of
IPv6 packets
#net.inet6.ip6.mforwarding=1# 1=Permit forwarding (routing) of
IPv6 multicast packets
#net.inet6.ip6.multipath=1 # 1=Enable IPv6 multipath routing
#net.inet6.ip6.accept_rtadv=1 # 1=Permit IPv6 autoconf (forwarding
must be 0)
#net.inet.tcp.rfc1323=0 # 0=Disable TCP RFC1323 extensions
(for if tcp is slow)
#net.inet.tcp.rfc3390=0 # 0=Disable RFC3390 for TCP window
increasing #net.inet.esp.enable=0 # 0=Disable the ESP IPsec
protocol #net.inet.ah.enable=0 # 0=Disable the AH IPsec
protocol #net.inet.esp.udpencap=0# 0=Disable ESP-in-UDP
encapsulation #net.inet.ipcomp.enable=1 # 1=Enable the IPCOMP
protocol #net.inet.etherip.allow=1 # 1=Enable the
Ethernet-over-IP protocol #net.inet.tcp.ecn=1 # 1=Enable
the TCP ECN extension net.inet.carp.preempt=1 # 1=Enable carp(4)
preemption net.inet.carp.log=1 # 1=Enable logging of
carp(4) packets #net.inet.ip.mtudisc=0 # 0=Disable tcp mtu
discovery #
# cat /etc/mygate
#
# cat /etc/pf.conf
lan_net = 10.10.20.0/24
int_if = vic0
ext_if1 = vic2
ext_if2 = vic3
ext_gw1 = 189.57.43.1
ext_gw2 = 200.162.41.33
# nat outgoing connections on each internet interface
nat on $ext_if1 from $lan_net to any - ($ext_if1)
nat on $ext_if2 from $lan_net to any - ($ext_if2)
# default deny
#block in from any to any
#block out from any to any
# pass all outgoing packets on internal interface
pass out on $int_if from any to $lan_net
# pass in quick any packets destined for the gateway itself
pass in quick on $int_if from $lan_net to $int_if
# load balance outgoing tcp traffic from internal network.
pass in on $int_if route-to \
{ ($ext_if1 $ext_gw1), ($ext_if2 $ext_gw2) } round-robin \
proto tcp from $lan_net to any flags S/SA modulate state
# load balance outgoing udp and icmp traffic from internal network
pass in on $int_if route-to \
{ ($ext_if1 $ext_gw1), ($ext_if2 $ext_gw2) } round-robin \
proto { udp, icmp } from $lan_net to any keep state
# general pass out rules for external interfaces
pass out on $ext_if1 proto tcp from any to any flags S/SA modulate
state pass out on $ext_if1 proto { udp, icmp } from any to any keep
state pass out on $ext_if2 proto tcp from any to any flags S/SA
modulate state pass out on $ext_if2 proto { udp, icmp } from any to
any keep state
# route packets from any IPs on $ext_if1 to $ext_gw1 and the same for
# $ext_if2 and $ext_gw2
pass out on $ext_if1 route-to ($ext_if2 $ext_gw2) from $ext_if2 to any
pass out on $ext_if2 route-to ($ext_if1 $ext_gw1) from $ext_if1 to any
#
I am able to surf at internet from my 10.10.20.0/24 machines, but
when i turn off vic3 my users lost connection.
It seems it4s using as default route the route i added first.
Help me plz.
Hi,
as the FAQ http://www.openbsd.org/faq/faq6.html#Multipath states:
It's worth noting that if an interface used by a multipath route goes
down (i.e., loses carrier), the kernel will still try to forward
packets using the route that points to that interface. This traffic
will of course be blackholed and end up going nowhere. It's highly
recommended to use ifstated(8) to check for unavailable interfaces and
adjust the routing table accordingly.
So use ifstated to check the link of the interface and populate the
routing table accordingly.
Regards Uwe
Re: OpenBSD 4.4 pf+vlan+bridge problem
Quoting Guido Tschakert guido.tschak...@src-gmbh.de: Key Aavoja schrieb: Hello, Hello, first thing: I do not have any experience with multicast traffic. But what you have build seems very strange to me. First you use vlan to separate the networks an then you put them alltogether with a bridge. I do not see the use of the vlans. Its needed because all those streams are already on one vlan, but its really needed to extract address based. Its the best way to put different streams on different vlans (using cisco switch is not a very good idea for this task, because some limitations, but its out of current topic). Wouldn't it be better to not use the bridge and use (multicast-)routing and pf to solve your problem? Multicast routing with dvrmpd is tested with pf, does not work. the same thing happens, if streamX is allowed to pass out on vlanX and streamY is allowed to pass out on vlanY, result is pretty similar: vlanX outputs both streams (streamX, streamY) and the same thing with vlanY. pf is not 100% percent multicast compat.? As I said, I have no experience with multicast traffic, but that is how I would start digging. guido I have a problem with pf+bridge+vlan (multicast traffic) and I googled a lot, read the manuals and so on - no help. Finally I posted on wrong place :( sorry. Hopefully this time I'm writing to right place. Following setup is made for multicast traffic separation from one lan to multiple vlans. Setup: Two physical interfaces bnx0 bnx1 interfaces bnx0 and bnx1 has vlans: bnx0 vlan1100 bnx1 vlan1101 vlan1102 vlan1103 vlan1104 vlan1105 vlan1106 vlan1107 vlan1108 Bridge setup: bridge0 has all vlans as bridge members (vlan1100, vlan1101 ... vlan1108) PF config: block out on bnx1 all block out on vlan1100 all block out on vlan1101 all block out on vlan1102 all block out on vlan1103 all block out on vlan1104 all block out on vlan1105 all block out on vlan1106 all block out on vlan1107 all block out on vlan1108 all pass out quick on vlan1101 proto udp from any to 239.16.1.1 pass out quick on vlan1102 proto udp from any to 239.16.1.2 pass out quick on vlan1103 proto udp from any to 239.16.1.3 Wishful thinking, what the result should be: All multicast streams are available on vlan1100 and recieved via bnx0/vlan1100. Bridge should stream the multicast packets to what ever vlan - its the place where pf should help. Stream: 239.16.1.1 should be available only on vlan1101, and 239.16.1.2 avialable on vlan1102 and so on. . Real Result: Stream 239.16.1.1 is available on all three vlans: 11101,1102,1103 - same thing happens with other two streams (239.16.1.2, 239.16.1.3) It's really weird what's going on or did I understood something wrong and configuration is not correct? Thank you. -
Re: OpenBSD 4.4 pf+vlan+bridge problem
Quoting Stuart Henderson s...@spacehopper.org: On 2009-01-20, Guido Tschakert guido.tschak...@src-gmbh.de wrote: first thing: I do not have any experience with multicast traffic. But what you have build seems very strange to me. First you use vlan to separate the networks an then you put them alltogether with a bridge. I do not see the use of the vlans. It can indeed be useful to do this, even without multicast traffic in the equation. You might want to filter traffic between machines in the same subnet, and this is a way you can do it. Key Aavoja schrieb: PF config: block out on bnx1 all block out on vlan1100 all block out on vlan1101 all block out on vlan1102 all block out on vlan1103 all block out on vlan1104 all block out on vlan1105 all block out on vlan1106 all block out on vlan1107 all block out on vlan1108 all pass out quick on vlan1101 proto udp from any to 239.16.1.1 pass out quick on vlan1102 proto udp from any to 239.16.1.2 pass out quick on vlan1103 proto udp from any to 239.16.1.3 Wishful thinking, what the result should be: All multicast streams are available on vlan1100 and recieved via bnx0/vlan1100. Bridge should stream the multicast packets to what ever vlan - its the place where pf should help. Stream: 239.16.1.1 should be available only on vlan1101, and 239.16.1.2 avialable on vlan1102 and so on. . Real Result: Stream 239.16.1.1 is available on all three vlans: 11101,1102,1103 - same thing happens with other two streams (239.16.1.2, 239.16.1.3) It's really weird what's going on or did I understood something wrong and configuration is not correct? you should check the simple things first. - is PF enabled? pfctl -si PF is enabled, btw removing the last three rules the whole mcast traffic is diabled - for testing I have 10 streams as input but trying to allow only three. - is the ruleset loaded correctly? pfctl -sr yes this command shows that all rules are loaded - does it correctly block ordinary non-multicast traffic between the vlans? if you did indeed include your whole PF config in your email, only that particular multicast traffic should pass between the vlans, everything else should be blocked. I pasted here 100% of pf config, this non-multicast traffic needs to be tested, tomorrow I will do that. you might have already done this, but if you did, you should have mentioned in your email what you checked. with a routed (not bridged) environment, PF is able to control multicast traffic in either direction (I just tried). from my reading of if_bridge.c, on a bridge, pf filtering for multicast frames only happens _inbound_. multicast frames sent _out_ through a bridge are not subject to the outbound PF filter rules. bridge MAC filter rules _are_ applied outbound for multicast frames, I haven't tested but I think that will give you a way you can restrict this traffic.
Re: OpenBSD 4.4 pf+vlan+bridge problem
On 2009-01-20, Key Aavoja k...@neoon.com wrote: Wouldn't it be better to not use the bridge and use (multicast-)routing and pf to solve your problem? Multicast routing with dvrmpd is tested with pf, does not work. the same thing happens, if streamX is allowed to pass out on vlanX and streamY is allowed to pass out on vlanY, result is pretty similar: vlanX outputs both streams (streamX, streamY) and the same thing with vlanY. if you get rid of the bridge and change it for a routed setup with igmpproxy (it's in packages), does that do what you're looking for? pf is not 100% percent multicast compat.? see the last couple of paragraphs of my earlier post about that - fine when it's routed, some limitations as a bridge.
Re: OpenBSD 4.4 load balance outgoing
On 2009-01-20, u...@o3si.de u...@o3si.de wrote: as the FAQ http://www.openbsd.org/faq/faq6.html#Multipath states: It's worth noting that if an interface used by a multipath route goes down (i.e., loses carrier), the kernel will still try to forward packets using the route that points to that interface. the FAQ refers to 4.4 (i.e. the last released version), but I'm pretty sure this particular thing (link down resulting in blackhole) is not a problem in -current. you may still have a need for some other way to kill the route if the link stays up but the nexthop is down, though. So use ifstated to check the link of the interface and populate the routing table accordingly. as an alternative to ifstated, you could take default routes from OSPF if your environment allows. (ospfd is ECMP capable).
Re: OpenBSD 4.4 pf+vlan+bridge problem
Quoting Stuart Henderson s...@spacehopper.org: On 2009-01-20, Key Aavoja k...@neoon.com wrote: Wouldn't it be better to not use the bridge and use (multicast-)routing and pf to solve your problem? Multicast routing with dvrmpd is tested with pf, does not work. the same thing happens, if streamX is allowed to pass out on vlanX and streamY is allowed to pass out on vlanY, result is pretty similar: vlanX outputs both streams (streamX, streamY) and the same thing with vlanY. if you get rid of the bridge and change it for a routed setup with igmpproxy (it's in packages), does that do what you're looking for? pf is not 100% percent multicast compat.? see the last couple of paragraphs of my earlier post about that - fine when it's routed, some limitations as a bridge. Thanks, I read and now I understand completely. Btw. test with dvrmpd was without a bridge, but pf filtering on out @ vlans had same results as with bridge. Using a igmpproxy in my setup is not a option because equipments expecting a stream are sometimes far away in network topology and cannot be sure, that igmp-join is always received. Anyway for others who are googling multicast bridge topics: I found a workaround. Use Linux 2.6 kernel + vlan + bridge + ebtables. Net setup will be the same, all what you need to add on your own script is: #!/bin/bash #default policy to drop everything (no matter which protocol). ebtables -P FORWARD DROP #flush existing rules. ebtables -F #now the exceptions ebtables -A FORWARD -i eth0.1100 -o eth1.1101 -p IPv4 --ip-dst 239.16.1.1 -j ACCEPT ebtables -A FORWARD -i eth0.1100 -o eth1.1102 -p IPv4 --ip-dst 239.16.1.2 -j ACCEPT ebtables -A FORWARD -i eth0.1100 -o eth1.1103 -p IPv4 --ip-dst 239.16.1.3 -j ACCEPT /etc/init.d/ebtables save echo ebtables: rules updated! Thats all what you need to do! Machine with two broadcom interfaces (not so good as intel) , 2GHz xeon (dual core) has acceptable performance: load: 0.00, cpu:0%, interrupts:eth0=6800; eth1=4300 90Mbit/s is the traffic on eth1 and pkt/s=8000 * This setup is giving a gaurantee, that no SpanningTree and other messages does not travel between interfaces, and vlans are staying still separated Key
Re: OpenBSD 4.4 amd64 bsd.mp can't detect 4GB memory
Owain Ainsworth wrote: Enabling bigmem=1: Also, from sys/arch/amd64/amd64/machdep.c: /* Tweakable by config(8) */ How? That diff was never commited. Config needs to know about it before it can change it. I did a similar config(8) patch for when PAE was in the same situation, so if someone desperately wants to make his/her config bigmem-aware and wants a hint on how to turn a random int on from config(8): http://people.su.se/~jj/obsd/config-pae.diff
Re: : : OpenBSD 4.4 amd64 bsd.mp can't detect 4GB memory
On Wed, Dec 17, 2008 at 07:34:07PM +0100, Markus Hennecke wrote:
Raimo Niskanen schrieb:
[config description]
But how to find a bigmem parameter I do not know, I have
no amd64 system. Try 'help' in the config editor.
And, as pointed out before:
If you search the archives, you'll find the clue you need to enable it
on your own system.
See also:
config(8)
options(4)
boot_config(8)
boot_i386(8)
boot(8)
So I read all that before and now I have to out me as plain stupid. I
still have no clue how to set bigmem to 1 using config(8). And as you
can see in this thread, it looks like I am not alone. Either I read over
it on more than one occasion, or there is no documentation describing it.
Sorry about that. I could only give you some pointers on how to use
UCK(config(8)) and have no amd64 system myself, so I deemed it probably
futile for me to try to find the bigmem parameter.
Then I assumed the rest of the clues _would_ be in the archives
but did not search myself. They still might be in the archives
but a later post in this thread suggests you can not do this with
config(8). You probably will have to compile a kernel.
I have searched the 4.4 kernel source tree and found:
$ find sys -type f | xargs grep -i bigmem
sys/arch/amd64/amd64/machdep.c:int bigmem = 1;
sys/arch/amd64/amd64/machdep.c: if (bigmem)
sys/arch/amd64/amd64/machdep.c: printf(Bigmem = %d\n, bigmem);
sys/arch/amd64/amd64/machdep.c: if (!bigmem (e1 = (1UL32))) {
sys/arch/amd64/amd64/machdep.c: } else if (bigmem (e1 = (1UL32)))
{
The revision of the file is 1.81 so that was just
before the release. In the cvsweb
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/arch/amd64/amd64/machdep.c
it says bigmem was set to 0 for the release of 4.4, and it still is
(revision 1.85).
I can also not find a documented way to tweak it from config(8)
as it is stated on the comment line before int bigmem = 0;.
It is probably daft simple or untrue. But changing the line to
int bigmem = 1; in the source code will certainly do the trick.
Kind regards,
Markus
--
/ Raimo Niskanen, Erlang/OTP, Ericsson AB
Re: OpenBSD 4.4 amd64 bsd.mp can't detect 4GB memory
On Thu, Dec 18, 2008 at 2:01 AM, Stephan A. Rickauer stephan.ricka...@ini.phys.ethz.ch wrote: On Wed, 2008-12-17 at 14:52 -0500, Ted Unangst wrote: On Tue, Dec 16, 2008 at 7:43 AM, C. Soragan Ong sora...@guox.net wrote: so let say put set bigmem=1 into /etc/boot.conf will activate the bigmem? correct me if i am wrong, i am new with openbsd :) the only permanent way to set that is to change the source and recompile. Is there a non-permanent way? boot -d, then change it in ddb before continuing.
Re: : OpenBSD 4.4 amd64 bsd.mp can't detect 4GB memory
On Thu, Dec 18, 2008 at 09:32:57AM -0500, Ted Unangst wrote: On Thu, Dec 18, 2008 at 2:01 AM, Stephan A. Rickauer stephan.ricka...@ini.phys.ethz.ch wrote: On Wed, 2008-12-17 at 14:52 -0500, Ted Unangst wrote: On Tue, Dec 16, 2008 at 7:43 AM, C. Soragan Ong sora...@guox.net wrote: so let say put set bigmem=1 into /etc/boot.conf will activate the bigmem? correct me if i am wrong, i am new with openbsd :) the only permanent way to set that is to change the source and recompile. Is there a non-permanent way? boot -d, then change it in ddb before continuing. Right then, to conclude... It seems the comment /* Tweakable by config(8) */ in sys/arch/amd64/amd64/machdep.c is in error. The variable can not be changed from config(8), neither before kernel compilation nor on a compiled kernel. And it can also not be changed from UKC via boot -c. But it can certainly be changed by editing the line in sys/arch/amd64/amd64/machdep.c to int bigmem = 1; and then compiling a kernel. And it can be temporarily changed via boot -d as stated above by Ted. Objections, anyone? -- / Raimo Niskanen, Erlang/OTP, Ericsson AB
Re: OpenBSD 4.4 amd64 bsd.mp can't detect 4GB memory
On Thu, Dec 18, 2008 at 08:30:48PM +0900, Jordi Beltran Creix wrote: Enabling bigmem=1: -real mem = 3734757376 (3561MB) -avail mem = 3624775680 (3456MB) +real mem = 4271632384 (4073MB) +avail mem = 4148350976 (3956MB) Also, from sys/arch/amd64/amd64/machdep.c: /* Tweakable by config(8) */ How? That diff was never commited. Config needs to know about it before it can change it. -0- -- There is a green, multi-legged creature crawling on your shoulder.
Re: : OpenBSD 4.4 amd64 bsd.mp can't detect 4GB memory
On Tue, Dec 16, 2008 at 08:43:46PM +0800, C. Soragan Ong wrote: so let say put set bigmem=1 into /etc/boot.conf will activate the bigmem? correct me if i am wrong, i am new with openbsd :) Ok. No, you run something like config -e /bsd -o /bsd.new. This will put you in an interactive editor that takes the kernel /bsd, enables you to modify parameters in it, and writes a new kernel /bsd.new with modified parameters. Then you use that new kernel instead. You can also invoke config (or rather UKC) when booting and try modifying some parameters temporarily for that boot. But how to find a bigmem parameter I do not know, I have no amd64 system. Try 'help' in the config editor. And, as pointed out before: If you search the archives, you'll find the clue you need to enable it on your own system. See also: config(8) options(4) boot_config(8) boot_i386(8) boot(8) Regards, Soragan On Tue, Dec 16, 2008 at 5:49 PM, Stephan A. Rickauer stephan.ricka...@ini.phys.ethz.ch wrote: On Mon, 2008-12-15 at 07:39 -0800, Chris Kuethe wrote: no. the config program can do this without a recompile. I also would like to learn how to do that since we have a couple of 'big' amd64 machines I could test on. Cheers, -- Stephan A. Rickauer --- Institute of Neuroinformatics Tel +41 44 635 30 50 University / ETH Zurich Sec +41 44 635 30 52 Winterthurerstrasse 190 Fax +41 44 635 30 53 CH-8057 ZurichWebwww.ini.uzh.ch -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- / Raimo Niskanen, Erlang/OTP, Ericsson AB
Re: : OpenBSD 4.4 amd64 bsd.mp can't detect 4GB memory
Raimo Niskanen schrieb: [config description] But how to find a bigmem parameter I do not know, I have no amd64 system. Try 'help' in the config editor. And, as pointed out before: If you search the archives, you'll find the clue you need to enable it on your own system. See also: config(8) options(4) boot_config(8) boot_i386(8) boot(8) So I read all that before and now I have to out me as plain stupid. I still have no clue how to set bigmem to 1 using config(8). And as you can see in this thread, it looks like I am not alone. Either I read over it on more than one occasion, or there is no documentation describing it. Kind regards, Markus
Re: OpenBSD 4.4 amd64 bsd.mp can't detect 4GB memory
On Tue, Dec 16, 2008 at 7:43 AM, C. Soragan Ong sora...@guox.net wrote: so let say put set bigmem=1 into /etc/boot.conf will activate the bigmem? correct me if i am wrong, i am new with openbsd :) the only permanent way to set that is to change the source and recompile.
Re: : OpenBSD 4.4 amd64 bsd.mp can't detect 4GB memory
On Wed, Dec 17, 2008 at 1:34 PM, Markus Hennecke markus-henne...@markus-hennecke.de wrote: So I read all that before and now I have to out me as plain stupid. I still have no clue how to set bigmem to 1 using config(8). And as you can see in this thread, it looks like I am not alone. Either I read over it on more than one occasion, or there is no documentation describing it. You can't set random variables using config.
Re: : OpenBSD 4.4 amd64 bsd.mp can't detect 4GB memory
yeah, that was my mistake. i could've sworn i've set bigmem that way to avoid a recompile... i'll shut up now. On Wed, Dec 17, 2008 at 11:50 AM, Ted Unangst ted.unan...@gmail.com wrote: On Wed, Dec 17, 2008 at 1:34 PM, Markus Hennecke markus-henne...@markus-hennecke.de wrote: So I read all that before and now I have to out me as plain stupid. I still have no clue how to set bigmem to 1 using config(8). And as you can see in this thread, it looks like I am not alone. Either I read over it on more than one occasion, or there is no documentation describing it. You can't set random variables using config. -- GDB has a 'break' feature; why doesn't it have 'fix' too?
Re: OpenBSD 4.4 amd64 bsd.mp can't detect 4GB memory
On Wed, 2008-12-17 at 14:52 -0500, Ted Unangst wrote: On Tue, Dec 16, 2008 at 7:43 AM, C. Soragan Ong sora...@guox.net wrote: so let say put set bigmem=1 into /etc/boot.conf will activate the bigmem? correct me if i am wrong, i am new with openbsd :) the only permanent way to set that is to change the source and recompile. Is there a non-permanent way?
Re: OpenBSD 4.4 amd64 bsd.mp can't detect 4GB memory
On Mon, 2008-12-15 at 07:39 -0800, Chris Kuethe wrote: no. the config program can do this without a recompile. I also would like to learn how to do that since we have a couple of 'big' amd64 machines I could test on. Cheers, -- Stephan A. Rickauer --- Institute of Neuroinformatics Tel +41 44 635 30 50 University / ETH Zurich Sec +41 44 635 30 52 Winterthurerstrasse 190 Fax +41 44 635 30 53 CH-8057 ZurichWebwww.ini.uzh.ch
Re: OpenBSD 4.4 amd64 bsd.mp can't detect 4GB memory
so let say put set bigmem=1 into /etc/boot.conf will activate the bigmem? correct me if i am wrong, i am new with openbsd :) Regards, Soragan On Tue, Dec 16, 2008 at 5:49 PM, Stephan A. Rickauer stephan.ricka...@ini.phys.ethz.ch wrote: On Mon, 2008-12-15 at 07:39 -0800, Chris Kuethe wrote: no. the config program can do this without a recompile. I also would like to learn how to do that since we have a couple of 'big' amd64 machines I could test on. Cheers, -- Stephan A. Rickauer --- Institute of Neuroinformatics Tel +41 44 635 30 50 University / ETH Zurich Sec +41 44 635 30 52 Winterthurerstrasse 190 Fax +41 44 635 30 53 CH-8057 ZurichWebwww.ini.uzh.ch -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: OpenBSD 4.4 amd64 bsd.mp can't detect 4GB memory
On Mon, Dec 15, 2008 at 10:40:44PM +0800, C. Soragan Ong wrote: | Hi All, | | I am using OpenBSD 4.4 and is having problem detecting 4GB ram. Below is the | dmesg Well, all memory is found (see the spdmem entries in your dmesg), but not all of it is supported by the default kernel. You'll have to enable bigmem and compile a new kernel yourself. Note that this was disabled shortly before 4.4 was tagged in cvs because of some problems. If you search the archives, you'll find the clue you need to enable it on your own system. Cheers, Paul 'WEiRD' de WEerd | OpenBSD 4.4 (GENERIC.MP) #1812: Tue Aug 12 17:22:53 MDT 2008 | dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP | real mem = 3073273856 (2930MB) | avail mem = 2979676160 (2841MB) | mainbus0 at root | bios0 at mainbus0: SMBIOS rev. 2.5 @ 0x9f400 (68 entries) | bios0: vendor American Megatrends Inc. version 0702 date 05/07/2008 | bios0: ASUSTeK Computer INC. M2N-VM HDMI | acpi0 at bios0: rev 0 | acpi0: tables DSDT FACP APIC MCFG OEMB HPET NVHD | acpi0: wakeup devices PS2K(S4) PS2M(S4) UAR1(S4) NSMB(S4) USB0(S4) USB2(S3) | US15(S4) US12(S3) NMAC(S5) P0P1(S4) HDAC(S4) BR10( | S4) BR11(S4) SLPB(S4) | acpitimer0 at acpi0: 3579545 Hz, 24 bits | acpimadt0 at acpi0 addr 0xfee0: PC-AT compat | cpu0 at mainbus0: apid 0 (boot processor) | cpu0: AMD Athlon(tm) 64 X2 Dual Core Processor 6000+, 3000.77 MHz | cpu0: | FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,NXE,MMXX, | FFXSR,LONG,3DNOW2,3DNOW | cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB 64b/line | 16-way L2 cache | cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative | cpu0: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative | cpu0: apic clock running at 200MHz | cpu1 at mainbus0: apid 1 (application processor) | cpu1: AMD Athlon(tm) 64 X2 Dual Core Processor 6000+, 3000.28 MHz | cpu1: | FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,NXE,MMXX, | FFXSR,LONG,3DNOW2,3DNOW | cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB 64b/line | 16-way L2 cache | cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative | cpu1: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative | ioapic0 at mainbus0 apid 2 pa 0xfec0, version 11, 24 pins | acpihpet0 at acpi0: 2500 Hz | acpiprt0 at acpi0: bus 0 (PCI0) | acpiprt1 at acpi0: bus 1 (P0P1) | acpiprt2 at acpi0: bus 2 (BR10) | acpiprt3 at acpi0: bus 3 (BR11) | acpicpu0 at acpi0 | acpicpu1 at acpi0 | acpibtn0 at acpi0: SLPB | acpibtn1 at acpi0: PWRB | cpu0: PowerNow! K8 3000 MHz: speeds: 3000 2800 2600 2400 2200 2000 1800 1000 | MHz | pci0 at mainbus0 bus 0: configuration mode 1 | NVIDIA MCP67 Memory rev 0xa2 at pci0 dev 0 function 0 not configured | pcib0 at pci0 dev 1 function 0 NVIDIA MCP67 Host rev 0xa2 | nviic0 at pci0 dev 1 function 1 NVIDIA MCP67 SMBus rev 0xa2 | iic0 at nviic0 | spdmem0 at iic0 addr 0x50: 2GB DDR2 SDRAM non-parity PC2-6400CL5 | spdmem1 at iic0 addr 0x51: 2GB DDR2 SDRAM non-parity PC2-6400CL5 | iic1 at nviic0 | ohci0 at pci0 dev 2 function 0 NVIDIA MCP67 USB rev 0xa2: apic 2 int 11 | (irq 11), version 1.0, legacy support | ehci0 at pci0 dev 2 function 1 NVIDIA MCP67 USB rev 0xa2: apic 2 int 10 | (irq 10) | usb0 at ehci0: USB revision 2.0 | uhub0 at usb0 NVIDIA EHCI root hub rev 2.00/1.00 addr 1 | ohci1 at pci0 dev 4 function 0 NVIDIA MCP67 USB rev 0xa2: apic 2 int 11 | (irq 11), version 1.0, legacy support | ehci1 at pci0 dev 4 function 1 NVIDIA MCP67 USB rev 0xa2: apic 2 int 11 | (irq 11) | usb1 at ehci1: USB revision 2.0 | uhub1 at usb1 NVIDIA EHCI root hub rev 2.00/1.00 addr 1 | pciide0 at pci0 dev 6 function 0 NVIDIA MCP67 IDE rev 0xa1: DMA, channel 0 | configured to compatibility, channel 1 configured | to compatibility | wd0 at pciide0 channel 0 drive 0: Maxtor 90422D2 | wd0: 16-sector PIO, LBA, 4028MB, 8249472 sectors | wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 | pciide0: channel 1 ignored (disabled) | azalia0 at pci0 dev 7 function 0 NVIDIA MCP67 HD Audio rev 0xa1: apic 2 | int 11 (irq 11) | azalia0: /usr/src/sys/dev/pci/azalia.c/1348 invalid PCM format: 0x | azalia0: codec[s]: Realtek ALC883, NVIDIA/0x0067, using Realtek ALC883 | audio0 at azalia0 | ppb0 at pci0 dev 8 function 0 NVIDIA MCP67 PCI rev 0xa2 | pci1 at ppb0 bus 1 | re0 at pci1 dev 6 function 0 Realtek 8169 rev 0x10: RTL8169/8110SB | (0x1000), apic 2 int 11 (irq 11), address 00:06:4f:63:93: | 3a | rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 3 | re1 at pci1 dev 7 function 0 Realtek 8169 rev 0x10: RTL8169/8110SB | (0x1000), apic 2 int 11 (irq 11), address 00:06:4f:63:93: | 35 | rgephy1 at re1 phy 7: RTL8169S/8110S PHY, rev. 3 | pciide1 at pci0 dev 9 function 0 NVIDIA MCP67 SATA rev 0xa2: DMA | pciide1: using apic 2 int 15 (irq 15) for native-PCI interrupt | nfe0 at pci0 dev 10
Re: OpenBSD 4.4 amd64 bsd.mp can't detect 4GB memory
Chris Kuethe schrieb: On Mon, Dec 15, 2008 at 6:47 AM, Paul de Weerd we...@weirdnet.nl wrote: You'll have to enable bigmem yes. and compile a new kernel yourself. no. the config program can do this without a recompile. I have seen the comment in machdep.c, but it looks like I am to stupid to figure out how to do it that way. This seems to be an excellent occasion to enlighten me, could you tell me how to change it with config? Kind regards, Markus
Re: OpenBSD 4.4 amd64 bsd.mp can't detect 4GB memory
On Mon, Dec 15, 2008 at 6:47 AM, Paul de Weerd we...@weirdnet.nl wrote: You'll have to enable bigmem yes. and compile a new kernel yourself. no. the config program can do this without a recompile. -- GDB has a 'break' feature; why doesn't it have 'fix' too?
Re: OpenBSD 4.4 amd64 bsd.mp can't detect 4GB memory
Hello, On Mon, 15.12.2008 at 15:47:06 +0100, Paul de Weerd we...@weirdnet.nl wrote: On Mon, Dec 15, 2008 at 10:40:44PM +0800, C. Soragan Ong wrote: | I am using OpenBSD 4.4 and is having problem detecting 4GB ram. Below is the | dmesg Well, all memory is found (see the spdmem entries in your dmesg), but these messages suggest that he has 4GB of RAM installed in his machine, right? not all of it is supported by the default kernel. You'll have to enable bigmem and compile a new kernel yourself. I thought that 4GB of RAM *are* supported in the default kernel? But apart from that, I'm having a quite similar problem with a completely different machine. It turns out that very much RAM is eaten, depending on various BIOS settings. I haven't figured out how to tune it, but currently I'm losing some 700+MB this way (really AWFUL!). I have found out that enabling PXE eats some 20MB per NIC on which it is enabled, though. Kind regards, --Toni++
Re: OpenBSD 4.4 amd64 bsd.mp can't detect 4GB memory
On Mon, 15 Dec 2008 22:40:44 +0800 C. Soragan Ong sora...@guox.net wrote: Hi All, I am using OpenBSD 4.4 and is having problem detecting 4GB ram. Below is the dmesg OpenBSD 4.4 (GENERIC.MP) #1812: Tue Aug 12 17:22:53 MDT 2008 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 3073273856 (2930MB) avail mem = 2979676160 (2841MB) [...] Here http://marc.info/?l=openbsd-miscm=122349979023721w=2 are my bigmem test results a little while ago. If you decide to try it out, it might be useful to the developers if you report your results.
Re: OpenBSD 4.4 Console Will Not Clear
Greets Denny Thanks for pointing out I had not CC'ed the misc list. So here is the full reply with the solution I found for 7.3 - How do I clear the console each time a user logs out? problem. See the second to last post for my solution. The FAQ just needs to be updated. Bret Denny White wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Denny White wrote: On Mon, Dec 08, 2008 at 03:56:21PM -0700, Bret spoke thusly: Greetings I have been running OpenBSD as a firewall/router since 2.5 and have never had any problem with Clearing the console each time a user logs out. I have just installed 4.4 on a system that was running 4.0. I did a complete install from the install CD off the ftp site(s). I then edited /etc/gettytab the same way I have done many times before, following the FAQ instructions. The console will not clear after logging out. I have even rebooted and the same results. I thought I might have screwed the file up editing it so I even did another clean install and ONLY installed pico to edit /etc/gettytab just in case I somehow messed it up using vi... still no go. Looked out on the net and found no reference to this. Any Ideas? Bret I'm assuming you're referring to http://www.openbsd.org/faq/faq7.html#ConsoleClear i.e., To do this you must add a line in /etc/gettytab(5). Change the current section: P|Pc|Pc console:\ :np:sp#9600: adding the line :cl=\E[H\E[2J: at the end, so that it ends up looking like this: P|Pc|Pc console:\ :np:sp#9600:\ :cl=\E[H\E[2J: Now try changing default:\ :np:im=\r\n%s/%m (%h) (%t)\r\n\r\n:sp#1200: to default:\ :np:im=\r\n%s/%m (%h) (%t)\r\n\r\n:sp#1200:cl=\E[H\E[2J: Denny White On Mon, Dec 08, 2008 at 09:20:24PM -0700, Bret spoke thusly: Greets I found that the ttys file now has: ttyC0 /usr/libexec/getty std,9600 where it used to be: ttyC0 /usr/libexec/getty Pc so I changed the the following in /etc/gettytab: 2|std.9600|9600-baud:\ :sp#9600: To: 2|std.9600|9600-baud:\ :sp#9600:\ :cl=\E[H\E[2J: and the console now clears every time. Bret You're absolutely right. Never noticed that. I ran into the same problem as you when upgrading to 4.4 used the way I sent you. Nice to know another way another way to look at it. Thanks. You really ought to post that to [EMAIL PROTECTED] I noticed you didn't cc the list. Be nice to have it in the archives for others. Thanks again, Bret. Denny White - -- /\ASCII Ribbon Campaign \ /Respect for low technology. X Keep e-mail messages readable by any computer system. / \Keep it ASCII. === GnuPG key : 0x1644E79A | http://wwwkeys.nl.pgp.net Fingerprint: D0A9 AD44 1F10 E09E 0E67 EC25 CB44 F2E5 1644 E79A === -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (OpenBSD) iEYEARECAAYFAkk+DIIACgkQy0Ty5RZE55q+3wCfVQ9ZCY/72ZMnvtrguyF9DiRm 2f8AoMf8rPSz5nzGRDWoSxDPbcLyNeaV =xf5j -END PGP SIGNATURE-
Re: OpenBSD 4.4 Console Will Not Clear
On Mon, Dec 08, 2008 at 03:56:21PM -0700, Bret spoke thusly: Greetings I have been running OpenBSD as a firewall/router since 2.5 and have never had any problem with Clearing the console each time a user logs out. I have just installed 4.4 on a system that was running 4.0. I did a complete install from the install CD off the ftp site(s). I then edited /etc/gettytab the same way I have done many times before, following the FAQ instructions. The console will not clear after logging out. I have even rebooted and the same results. I thought I might have screwed the file up editing it so I even did another clean install and ONLY installed pico to edit /etc/gettytab just in case I somehow messed it up using vi... still no go. Looked out on the net and found no reference to this. Any Ideas? Bret I'm assuming you're referring to http://www.openbsd.org/faq/faq7.html#ConsoleClear i.e., To do this you must add a line in /etc/gettytab(5). Change the current section: P|Pc|Pc console:\ :np:sp#9600: adding the line :cl=\E[H\E[2J: at the end, so that it ends up looking like this: P|Pc|Pc console:\ :np:sp#9600:\ :cl=\E[H\E[2J: Now try changing default:\ :np:im=\r\n%s/%m (%h) (%t)\r\n\r\n:sp#1200: to default:\ :np:im=\r\n%s/%m (%h) (%t)\r\n\r\n:sp#1200:cl=\E[H\E[2J: Denny White -- /\ASCII Ribbon Campaign \ /Respect for low technology. X Keep e-mail messages readable by any computer system. / \Keep it ASCII. === GnuPG key : 0x1644E79A | http://wwwkeys.nl.pgp.net Fingerprint: D0A9 AD44 1F10 E09E 0E67 EC25 CB44 F2E5 1644 E79A ===
Re: OpenBSD 4.4 Console Will Not Clear
Greets: I have found where the FAQ was needed to be updated ;D I looked in ttys and found that it was using the getty std,9600 instead of the getty Pc. Sorry for the trouble, Bret Bret wrote: Greetings I have been running OpenBSD as a firewall/router since 2.5 and have never had any problem with Clearing the console each time a user logs out. I have just installed 4.4 on a system that was running 4.0. I did a complete install from the install CD off the ftp site(s). I then edited /etc/gettytab the same way I have done many times before, following the FAQ instructions. The console will not clear after logging out. I have even rebooted and the same results. I thought I might have screwed the file up editing it so I even did another clean install and ONLY installed pico to edit /etc/gettytab just in case I somehow messed it up using vi... still no go. Looked out on the net and found no reference to this. Any Ideas? Bret
Re: OpenBSD 4.4-release installation hangs on large disk (x86)
On Mon, Dec 1, 2008 at 12:19 AM, Richard Toohey [EMAIL PROTECTED] wrote: I've got a couple of Dell SC440s with the same sort of set-up, and no problems here. Two 500Gb drives, wd0 and wd1: I have resolved this issue. I tried the installation again and this time selected fdisk before selecting disk label. Under fdisk I could see 4 partitions 0, 1, 2 and 3 (#3 is where OpenBSD was installed); 0, 1 and 2 were labeled as unused. I flagged 0, 1 and 2 as disable and the installation went smoothly.
Re: OpenBSD 4.4-release installation hangs on large disk (x86)
2) in an earlier message you indicated that there was some kind of RAID on this system, I think it is safe to say that it is a BIOS-assisted software RAID, which COULD be causing you problems if it is still configured in the BIOS. And even if it isn't causing this problem, it WILL bite you in the future when the BIOS decides top copy something from one drive to the other... Sorry about my previous post but there is no RAID. So, start by disabling the BIOS RAID do-hickey thing and unplug the second drive. I suspect you will have no problems then. I have tried pulling the plug on the second disk (wd1) with no luck. Once you convince yourself the size of the drive is not directly an issue, I'd suggest starting over with a more sane partitioning plan. Just because you have a cheap 500G disk doesn't mean you need to allocate all or most of it. For one, the bigger the disk, the longer it takes to fsck after you trip over the power cord. I actually have two cheap 500GB; so that makes it 1 terabyte. I don't mind fsck doing its thing when I trip over the cable. But I really do need a large /data1 partition to rsync stuff over from other places. Here's the last disk partition I tried (and it didn't work): / 10g, swap 3g, /tmp 20g, /home 100g, /var/ 50g, /usr/ 50g. It was sitting there for 30 minutes after the last file set was installed (xserv44.tgz) and then I turned it off. Thanks for any further help.
Re: OpenBSD 4.4-release installation hangs on large disk (x86)
Just because you have a cheap 500G disk doesn't mean you need to allocate all or most of it. For one, the bigger the disk, the longer it takes to fsck after you trip over the power cord. Wait for fsck? So OpenBSD doesn't have background fsck? :-(
Re: OpenBSD 4.4-release installation hangs on large disk (x86)
On 1/12/2008, at 9:24 AM, Chris wrote: 2) in an earlier message you indicated that there was some kind of RAID on this system, I think it is safe to say that it is a BIOS- assisted software RAID, which COULD be causing you problems if it is still configured in the BIOS. And even if it isn't causing this problem, it WILL bite you in the future when the BIOS decides top copy something from one drive to the other... Sorry about my previous post but there is no RAID. So, start by disabling the BIOS RAID do-hickey thing and unplug the second drive. I suspect you will have no problems then. I have tried pulling the plug on the second disk (wd1) with no luck. Once you convince yourself the size of the drive is not directly an issue, I'd suggest starting over with a more sane partitioning plan. Just because you have a cheap 500G disk doesn't mean you need to allocate all or most of it. For one, the bigger the disk, the longer it takes to fsck after you trip over the power cord. I actually have two cheap 500GB; so that makes it 1 terabyte. I don't mind fsck doing its thing when I trip over the cable. But I really do need a large /data1 partition to rsync stuff over from other places. Here's the last disk partition I tried (and it didn't work): / 10g, swap 3g, /tmp 20g, /home 100g, /var/ 50g, /usr/ 50g. It was sitting there for 30 minutes after the last file set was installed (xserv44.tgz) and then I turned it off. Thanks for any further help. I've got a couple of Dell SC440s with the same sort of set-up, and no problems here. Two 500Gb drives, wd0 and wd1: # df -h Filesystem SizeUsed Avail Capacity Mounted on /dev/wd0a 84.4M 36.6M 43.6M46%/ /dev/wd0h 1008M2.7M955M 0%/home /dev/wd0i 436G121G294G29%/public /dev/wd1a 458G116G320G27%/public2 /dev/wd0d 1008M2.0K958M 0%/tmp /dev/wd0g 9.8G1.9G7.4G21%/usr /dev/wd0e 9.8G 31.2M9.3G 0%/var I wanted one large dumping ground on wd0, and another on wd1, and had no trouble creating them (I cannot recall any lengthy delay; not the same as saying there wasn't one, but I don't remember it.) And yes, fsck does take a long time. Thanks. dmesg (sd0 is an 8Gb USB memstick): OpenBSD 4.4 (GENERIC) #0: Tue Nov 11 10:18:14 NZDT 2008 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel(R) Pentium(R) D CPU 3.00GHz (GenuineIntel 686-class) 3 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36, CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS- CPL,EST,CNXT-ID,CX16,xTPR real mem = 1071722496 (1022MB) avail mem = 1027870720 (980MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 07/03/07, BIOS32 rev. 0 @ 0xffe90, SMBIOS rev. 2.3 @ 0xf0450 (63 entries) bios0: vendor Dell Inc. version 1.4.1 date 07/03/2007 bios0: Dell Inc. PowerEdge SC440 apm0 at bios0: Power Management spec V1.2 apm0: AC on, battery charge unknown acpi at bios0 function 0x0 not configured pcibios0 at bios0: rev 2.1 @ 0xf/0x1 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfed10/256 (14 entries) pcibios0: PCI Interrupt Router at 000:31:0 (Intel 82801GH LPC rev 0x00) pcibios0: PCI bus #5 is the last bus bios0: ROM list: 0xc/0x9000 0xc9000/0x2000! 0xcb000/0x1000 cpu0 at mainbus0 cpu0: Enhanced SpeedStep disabled by BIOS pci0 at mainbus0 bus 0: configuration mode 1 (no bios) pchb0 at pci0 dev 0 function 0 Intel E7230 Host rev 0x00 ppb0 at pci0 dev 1 function 0 Intel E7230 PCIE rev 0x00: irq 11 pci1 at ppb0 bus 1 ppb1 at pci0 dev 28 function 0 Intel 82801GB PCIE rev 0x01: irq 11 pci2 at ppb1 bus 2 ppb2 at pci0 dev 28 function 4 Intel 82801G PCIE rev 0x01: irq 11 pci3 at ppb2 bus 3 em0 at pci3 dev 0 function 0 Intel PRO/1000 PT (82572EI) rev 0x06: irq 11, address 00:15:17:3d:38:11 ppb3 at pci0 dev 28 function 5 Intel 82801G PCIE rev 0x01: irq 10 pci4 at ppb3 bus 4 bge0 at pci4 dev 0 function 0 Broadcom BCM5754 rev 0x02, BCM5754/5787 A2 (0xb002): irq 10, address 00:1d:09:09:94:17 brgphy0 at bge0 phy 1: BCM5787 10/100/1000baseT PHY, rev. 0 uhci0 at pci0 dev 29 function 0 Intel 82801GB USB rev 0x01: irq 9 uhci1 at pci0 dev 29 function 1 Intel 82801GB USB rev 0x01: irq 5 uhci2 at pci0 dev 29 function 2 Intel 82801GB USB rev 0x01: irq 3 uhci3 at pci0 dev 29 function 3 Intel 82801GB USB rev 0x01: irq 10 ehci0 at pci0 dev 29 function 7 Intel 82801GB USB rev 0x01: irq 9 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 ppb4 at pci0 dev 30 function 0 Intel 82801BA Hub-to-PCI rev 0xe1 pci5 at ppb4 bus 5 vga1 at pci5 dev 7 function 0 ATI ES1000 rev 0x02 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) drm at vga1 unsupported ichpcib0 at pci0 dev 31 function 0 Intel 82801GB LPC rev 0x01: PM disabled pciide0 at pci0 dev 31 function 1 Intel 82801GB IDE rev 0x01: DMA, channel
Re: OpenBSD 4.4-release installation hangs on large disk (x86)
Chris wrote: I'm trying to install OBSD 4.4-release on this desktop which has two hard disks of around 465 GB each. If I install on wd0 with only one partition (/) of 10GB, the installation goes smoothly. But if I try to allocate /tmp (20g), /home (100g), / (50g), /var (50g), /usr (50g), swap (3g), the installation hangs after the last file set is installed (xserv44.tgz): it just sits there and I cannot use my keyboard anymore. I have waited for about 2 hours for the installation to proceed to the next step but nothing. Here's my dmesg; Thanks for any help. 1) Having installed OpenBSD on a lot of 500G disks, I think I can say with confidence the size of the disk is not your problem. 2) in an earlier message you indicated that there was some kind of RAID on this system, I think it is safe to say that it is a BIOS-assisted software RAID, which COULD be causing you problems if it is still configured in the BIOS. And even if it isn't causing this problem, it WILL bite you in the future when the BIOS decides top copy something from one drive to the other... So, start by disabling the BIOS RAID do-hickey thing and unplug the second drive. I suspect you will have no problems then. Once you convince yourself the size of the drive is not directly an issue, I'd suggest starting over with a more sane partitioning plan. Just because you have a cheap 500G disk doesn't mean you need to allocate all or most of it. For one, the bigger the disk, the longer it takes to fsck after you trip over the power cord. Nick.
Re: OpenBSD 4.4 panics when using AICCU
On Fri, Nov 14, 2008 at 12:00 AM, Felipe Alfaro Solana [EMAIL PROTECTED] wrote: Hi misc, Are any of you using AICCU on OpenBSD 4.4 patched to 005? Have you experienced panics? Since I upgraded to OpenBSD 4.4, whenever I take AICCU down, then up, after a while the system panics. I can reproduce this reliably, although the timing is not always the same: sometimes the system panics in a few seconds, sometimes it takes longer. Have you experienced this? I've been trying to chase down what is causing the panic. Apparently, it's related to IPSec/IPv6: when I reboot the system with no IPSec/IPv6 tunnels enabled (no sasync, no isakmpd) the system doesn't panic when I take aiccu down and then up. The system panics here: uvm_fault(0xd623f758, 0x0, 0, 1) - e kernel: page fault trap, code=0 Stopped at in6_selecthlim+0x29:movzbl 0x1c(%eax),%eax Thanks in advance. PS: I have crash dumps for each panic. -- http://www.felipe-alfaro.org/blog/disclaimer/ -- http://www.felipe-alfaro.org/blog/disclaimer/
Re: OpenBSD 4.4 panics when using AICCU
On Fri, Nov 14, 2008 at 12:58 AM, Felipe Alfaro Solana [EMAIL PROTECTED] wrote: On Fri, Nov 14, 2008 at 12:00 AM, Felipe Alfaro Solana [EMAIL PROTECTED] wrote: Hi misc, Are any of you using AICCU on OpenBSD 4.4 patched to 005? Have you experienced panics? Since I upgraded to OpenBSD 4.4, whenever I take AICCU down, then up, after a while the system panics. I can reproduce this reliably, although the timing is not always the same: sometimes the system panics in a few seconds, sometimes it takes longer. Have you experienced this? I've been trying to chase down what is causing the panic. Apparently, it's related to IPSec/IPv6: when I reboot the system with no IPSec/IPv6 tunnels enabled (no sasync, no isakmpd) the system doesn't panic when I take aiccu down and then up. The system panics here: uvm_fault(0xd623f758, 0x0, 0, 1) - e kernel: page fault trap, code=0 Stopped at in6_selecthlim+0x29:movzbl 0x1c(%eax),%eax Looks to me that the IPSec/IPv6 code is holding a reference to a in6pcb structure (that represents or is associated the aiccu tun0 interface) that gets destroyed when I take aiccu down. When I start aiccu again, the in6_selecthlim ends up being called with an old reference to tun0 interface that does not exist anymore (was freed) and that causes the trap. Thanks in advance. PS: I have crash dumps for each panic. -- http://www.felipe-alfaro.org/blog/disclaimer/ -- http://www.felipe-alfaro.org/blog/disclaimer/ -- http://www.felipe-alfaro.org/blog/disclaimer/
Re: OpenBSD 4.4 panics when using AICCU
On Fri, Nov 14, 2008 at 12:58 AM, Felipe Alfaro Solana [EMAIL PROTECTED] wrote: On Fri, Nov 14, 2008 at 12:00 AM, Felipe Alfaro Solana [EMAIL PROTECTED] wrote: Hi misc, Are any of you using AICCU on OpenBSD 4.4 patched to 005? Have you experienced panics? Since I upgraded to OpenBSD 4.4, whenever I take AICCU down, then up, after a while the system panics. I can reproduce this reliably, although the timing is not always the same: sometimes the system panics in a few seconds, sometimes it takes longer. Have you experienced this? I've been trying to chase down what is causing the panic. Apparently, it's related to IPSec/IPv6: when I reboot the system with no IPSec/IPv6 tunnels enabled (no sasync, no isakmpd) the system doesn't panic when I take aiccu down and then up. The system panics here: uvm_fault(0xd623f758, 0x0, 0, 1) - e kernel: page fault trap, code=0 Stopped at in6_selecthlim+0x29:movzbl 0x1c(%eax),%eax Another datapoint: When bringing aiccu down, the kernel logs the following message: in6_purgeaddr: failed to remove a route to the p2p destination: 2001::::2 on tun0, errno=3. This looks very suspicious to me, and wrong, by the way, since tun0 interface is using 2001::::2 as the local IPv6 address, while 2001::::1 is the remote end point. Hence, there is no route in the routing table that is bound to tun0 and has 2001::::2 as the destination (there is one but is bound to lo0). It leads me to think that some data structures are not properly freed/referenced counted which leads eventually to the panic. Any ideas? Thanks in advance. PS: I have crash dumps for each panic. -- http://www.felipe-alfaro.org/blog/disclaimer/ -- http://www.felipe-alfaro.org/blog/disclaimer/ -- http://www.felipe-alfaro.org/blog/disclaimer/
Re: OpenBSD 4.4 panics when using AICCU
On Thu, Nov 13, 2008 at 7:18 PM, Felipe Alfaro Solana [EMAIL PROTECTED] wrote: On Fri, Nov 14, 2008 at 12:58 AM, Felipe Alfaro Solana [EMAIL PROTECTED] wrote: On Fri, Nov 14, 2008 at 12:00 AM, Felipe Alfaro Solana [EMAIL PROTECTED] wrote: Are any of you using AICCU on OpenBSD 4.4 patched to 005? Have you experienced panics? Since I upgraded to OpenBSD 4.4, whenever I take AICCU down, then up, after a while the system panics. I can reproduce this reliably, although the timing is not always the same: sometimes the system panics in a few seconds, sometimes it takes longer. Have you experienced this? I've been trying to chase down what is causing the panic. Apparently, it's related to IPSec/IPv6: when I reboot the system with no IPSec/IPv6 tunnels enabled (no sasync, no isakmpd) the system doesn't panic when I take aiccu down and then up. The system panics here: uvm_fault(0xd623f758, 0x0, 0, 1) - e kernel: page fault trap, code=0 Stopped at in6_selecthlim+0x29:movzbl 0x1c(%eax),%eax Another datapoint: When bringing aiccu down, the kernel logs the following message: in6_purgeaddr: failed to remove a route to the p2p destination: 2001::::2 on tun0, errno=3. This looks very suspicious to me, and wrong, by the way, since tun0 interface is using 2001::::2 as the local IPv6 address, while 2001::::1 is the remote end point. Hence, there is no route in the routing table that is bound to tun0 and has 2001::::2 as the destination (there is one but is bound to lo0). It leads me to think that some data structures are not properly freed/referenced counted which leads eventually to the panic. Any ideas? Haven't looked at it in detail, but brad@ just updated 4.4 stable's if.c to address an apparently similar IPv6-related panic that might help.
Re: OpenBSD 4.4 released, Nov 1. Enjoy!
2008/11/2 James R. Campbell [EMAIL PROTECTED]: Thanks for all of your hard work! I really enjoyed the song in this release also. Haha, may the source be with you!! -- This e-mail may be confidential. You may not copy, forward or use any part. All disclaimers on the Internet are of zero legal effectiveness however. http://www.goldmark.org/jeff/stupid-disclaimers/
Re: OpenBSD 4.4 released, Nov 1. Enjoy!
David Schulz-5 wrote: yes, its awesome this time ! That's like telling your wife, You look beautiful... today. It's better to leave off the last part. It's awesome will suffice. -- View this message in context: http://www.nabble.com/OpenBSD-4.4-released%2C-Nov-1.--Enjoy%21-tp20269800p20448423.html Sent from the openbsd user - misc mailing list archive at Nabble.com.
Re: OpenBSD 4.4 released, Nov 1. Enjoy!
On Wed, Nov 12, 2008 at 6:26 AM, new_guy [EMAIL PROTECTED] wrote: David Schulz-5 wrote: yes, its awesome this time ! That's like telling your wife, You look beautiful... today. It's better to leave off the last part. It's awesome will suffice. I _think_ the reference was to the song. I have listened to all of the release songs (fairly recently). They all rock. I strongly recommend a listen if one hasn't done so already. If you are a Pink Floyd fan, you might appreciate The Wizard of OS. Hari
Re: OpenBSD 4.4 httpd reverse proxy
There is a problem in installation install: /usr/src/usr.sbin/httpd/obj/src/modules/proxy/libproxy.so: No such file or directory But I can't find any problem with compilation... Any idea ? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pc Nicolas Sent: mercredi 5 novembre 2008 16:14 To: misc@openbsd.org Subject: OpenBSD 4.4 httpd reverse proxy Hi I try to reconfigure httpd on OpenBSD 4.4 to do reverse proxy as I did for years following this documentation : http://undeadly.org/cgi?action=article http://undeadly.org/cgi?action=articlesid=20040118105719 sid=20040118105719 I can't get it done. The only relevant message is in /var/www/logs/error_log (13)Permission denied: proxy: error creating cache file /var/www/proxy/tmpzjzsP11224 The permissions are the same as OpenBSD 4.3. I try chroot and no chroot (httpd -u). Any idea ? Thanks
Re: OpenBSD 4.4 httpd reverse proxy
Yes I'm sure ! It is a weird problem... In fact httpd does not proxy anything even with a successful compilation. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of disintx Sent: jeudi 6 novembre 2008 03:05 To: misc@openbsd.org Subject: Re: OpenBSD 4.4 httpd reverse proxy Are you certain that /var/www/proxy/ is writeable by the server? i.e. what is the owner/group of the directory and what are the permissions? Pc Nicolas wrote: Hi I try to reconfigure httpd on OpenBSD 4.4 to do reverse proxy as I did for years following this documentation : http://undeadly.org/cgi?action=article http://undeadly.org/cgi?action=articlesid=20040118105719 sid=20040118105719 I can't get it done. The only relevant message is in /var/www/logs/error_log (13)Permission denied: proxy: error creating cache file /var/www/proxy/tmpzjzsP11224 The permissions are the same as OpenBSD 4.3. I try chroot and no chroot (httpd -u). Any idea ? Thanks
Re: OpenBSD 4.4 - fdisk issue
On Tue, Nov 04, 2008 at 01:03:37PM -0500, William Boshuck wrote: On Tue, Nov 04, 2008 at 12:59:29PM -0500, William Boshuck wrote: On Tue, Nov 04, 2008 at 05:39:46PM +0100, Christophe Rioux wrote: On Tue, Nov 04, 2008 at 04:31:57PM +0100, [EMAIL PROTECTED] wrote: I just try to install OpenBSD 4.4 on a serveur (HP DL120 G5) to test the functionality of the raid (seens it works again .). I configure the first disk without any issue, and then try following commands: disklabel wd0 disklabel.wd1 fdisk -i wd1 disklabel -R -r wd1 disklabel.wd1 newfs /dev/wd1a Error: newfs: /dev/wd1a: block device Second section of the newfs(8) manpage. Great ... This worked in 4.3 without any thing else; Likely not just as typed above. Sorry, this does seem ok in 4.3. (An example in the FAQ uses a relative path, and that's what I've always done.) It only seems ok in 4.3 *if you ignore the warning from newfs*. I repeat: running newfs on a block device is not good. Use the raw device. 4.4 enforces that, but if you are running newfs on an older system, this holds too. Background: writing to a block device is not order-preserving: newfs writes multiple times to the same block. So you can end up with a filesystem that is inconsitent from the beginning. -Otto
Re: OpenBSD 4.4 - fdisk issue
Hi I just try to install OpenBSD 4.4 on a serveur (HP DL120 G5) to test the functionality of the raid (seens it works again .). I configure the first disk without any issue, and then try following commands: disklabel wd0 disklabel.wd1 fdisk -i wd1 disklabel -R -r wd1 disklabel.wd1 newfs /dev/wd1a Error: newfs: /dev/wd1a: block device Same message when I try a mount. Not a problem I continue and made a new installation on wd1 (with the CD) Then I build my raid0 configuration (by compiling the kernel) and try to create the new disk: fdisk -i raid0 disklabel -E -raid0 newfs /dev/raid0a = same error by newfs and mount What do I wrong ? Regards Thanks for all the answer. The answer should be disklabel wd0 disklabel.wd1 fdisk -i wd1 disklabel -R -r wd1 disklabel.wd1 newfs /dev/rwd1a instead of newfs /dev/wd1a mount /dev/wd1a /mnt And fdisk -i raid0 disklabel -E -raid0 newfs /dev/rraid0a instead of newfs /dev/raid0a mount /dev/raid0a /mnt
Re: OpenBSD 4.4 - fdisk issue
On Wed, Nov 05, 2008 at 09:57:31AM +0100, Otto Moerbeek wrote: On Tue, Nov 04, 2008 at 01:03:37PM -0500, William Boshuck wrote: Sorry, this does seem ok in 4.3. (An example in the FAQ uses a relative path, and that's what I've always done.) It only seems ok in 4.3 *if you ignore the warning from newfs*. I repeat: running newfs on a block device is not good. Use the raw device. 4.4 enforces that, but if you are running newfs on an older system, this holds too. Ok, thanks, and sorry if I seem to have suggested otherwise. The man page says that if I use a relative path then newfs will do the right thing (use the corresponding raw device), and that's the form of the command in Section 14.3 of the FAQ. What I read in the FAQ (and in the EXAMPLES sections of man pages) I am inclined to take as recommended usage. Is that the case here, too? cheers, (and thanks for the background info) -wb
Re: OpenBSD 4.4 - fdisk issue
On Wed, Nov 5, 2008 at 8:10 AM, William Boshuck [EMAIL PROTECTED] wrote: Ok, thanks, and sorry if I seem to have suggested otherwise. The man page says that if I use a relative path then newfs will do the right thing (use the corresponding raw device), and that's the form of the command in Section 14.3 of the FAQ. What I read in the FAQ (and in the EXAMPLES sections of man pages) I am inclined to take as recommended usage. Is that the case here, too? Yes, the FAQ is right. You should do it that way.
Re: OpenBSD 4.4 httpd reverse proxy
Are you certain that /var/www/proxy/ is writeable by the server? i.e. what is the owner/group of the directory and what are the permissions? Pc Nicolas wrote: Hi I try to reconfigure httpd on OpenBSD 4.4 to do reverse proxy as I did for years following this documentation : http://undeadly.org/cgi?action=article http://undeadly.org/cgi?action=articlesid=20040118105719 sid=20040118105719 I can't get it done. The only relevant message is in /var/www/logs/error_log (13)Permission denied: proxy: error creating cache file /var/www/proxy/tmpzjzsP11224 The permissions are the same as OpenBSD 4.3. I try chroot and no chroot (httpd -u). Any idea ? Thanks
Re: OpenBSD 4.4 released, Nov 1. Enjoy!
yes, its awesome this time ! James R. Campbell wrote: Thanks for all of your hard work! I really enjoyed the song in this release also. --James
Re: OpenBSD 4.4 released, Nov 1. Enjoy!
Congrats, Mr. de Raadt
2008/10/31 Theo de Raadt [EMAIL PROTECTED]
Nov 1, 2008.
We are pleased to announce the official release of OpenBSD 4.4.
This is our 24th release on CD-ROM (and 25th via FTP). We remain
proud of OpenBSD's record of more than ten years with only two remote
holes in the default install.
As in our previous releases, 4.4 provides significant improvements,
including new features, in nearly all areas of the system:
- New/extended platforms:
o OpenBSD/sparc64.
Fujitsu's SPARC64-V, SPARC64-VI and SPARC64-VII processors are
supported
now, which means that many of the PRIMEPOWER machines and the SPARC
Enterprise M4000/M5000/M8000/M9000 work now.
Sun's UltraSPARC VI processors are supported now. Many of Sun's
mid-range and high-end servers with these processors or UltraSPARC III
and UltraSPARC III+ processors work now.
Sun's UltraSPARC T1 and UltraSPARC T2 processors are supported now,
which means the sun4v architecture is now supported and machines like
the SPARC Enterprise T1000 and SPARC Enterprise T5220 work now.
o OpenBSD/socppc.
For machines based on the Freescale MPC8349E
System-on-Chip (SoC) platform that use Das U-Boot as a boot loader.
o OpenBSD/landisk: added shared libraries support.
- Improved hardware support, including:
o Several new/improved drivers for sensors: fins(4), andl(4), it(4),
kate(4), sdtemp(4), lmtemp(4), adt(4), km(4).
o Support for Intel G33 and G35 chipsets in agp(4).
o New lii(4) driver for Attansic L2 10/100 Ethernet devices.
o Preliminary support for UVC USB webcams: uvideo(4) and video(4).
o WPA/WPA2-PSK support for several models of wireless cards.
o Openchrome(4) and geode(4) video card drivers for X.Org.
o New vmt(4) driver, implements VMware Tools.
o New auglx(4) driver for AMD Geode LX CS5536 integrated AC'97 audio.
o New ix(4) driver for Intel 82598 PCI Express 10Gb Ethernet.
o New acpithinkpad(4) driver provides additional ACPI support for
IBM/Lenovo ThinkPad laptops.
o New acpiasus(4) driver provides additional ACPI support for ASUS
laptops including the EeePC.
o New gecko(4) driver supporting the GeckoBOA BC GSC+ port found on
some hppa systems.
o New tsec(4) driver supporting the Freescale Triple Speed Ethernet
Controller..
o The re(4) driver now supports RTL8102E and RTL8168 devices.
o The cas(4) driver now supports National Semiconductor Saturn devices.
o The pccom(4) driver has been removed; all platforms use com(4) now.
o cardbus(4) and pcmcia(4) now work on most sparc64 machines.
o The udcf(4) driver now supports mouseCLOCK USB II devices.
o The msk(4) driver now supports 88E8040T devices.
o The ath(4) now now supports many more Atheros wireless devices.
o The ciss(4) driver now supports HP Smart Array P212, P410, P411, P411i
and P812 devices.
o The uftdi(4) driver now supports ELV Elektronik and FTDI 2232L
devices.
o The umsm(4) driver now supports Option GlobeTrotter 3G+, Huawei E220
and more HSDPA MSM devices.
o The ubsa(4) driver now supports ZTE CMDMA MSM devices.
o The axe(4) driver now supports Apple USB A1277 devices.
o The puc(4) driver now supports more Netmos devices.
o The mgx(4) driver now supports 2D acceleration on selected boards.
o The isp(4) driver firmware for some controllers has been updated.
o The isp(4) driver no longer hangs during probe on some machines.
o The bge(4) driver has better support for BCM5704 chipsets in fiber
mode which helps with some blade servers.
o The bge(4) driver has better support for the BCM5906 chipset on
some systems.
o The bge(4) driver has much better support for PCI Express chipsets
resulting in much faster transmit performance.
o The bge(4) driver has support for the BCM5714/5715/5780 chipsets
using fiber interfaces.
o The bnx(4) driver has support for the BCM5706/5708 chipsets using
fiber interfaces.
o The ral(4) driver now supports Ralink Technology RT2700 devices.
o Serial ports other than com0 can now be used for console on amd64.
o The serial console on i386 and amd64 has improved compatibility
with server management cards.
- New tools:
o rpc.statd(8), the host status monitoring daemon for use with the NFS
file locking daemon.
o Initial import of ypldap(8), a drop-in replacement for ypserv
to glue in an LDAP directory for get{pw,gr}ent family of functions.
o Deprecated slattach(8) and nmeaattach(8) in favor of ldattach(8).
o Import of tcpbench(1), a small TCP benchmarking tool.
- New functionality:
o aucat(1) is now able to play and record audio in fullduplex, it
can mix unlimited number of streams, handles up to 16 channels, can
resample streams on
Re: OpenBSD 4.4 installation error: write failed; file system full
Ross Cameron wrote: On Tue, Nov 4, 2008 at 12:32 PM, Chris [EMAIL PROTECTED] wrote: I've download and burned the 4.4 ISO from a local mirror and trying to upgrade from 4.3 to 4.4 on i386. After the installer does the fsck -fp, I get the following error: uid 0 on /: file system full /: write failed; file system full cp: /tmp/hosts: No space left on device I've also tried the 4.3 base CD and I get the same error. This has never happened before. Is there something I'm doing wrong? Yes! Here's my df -h output: /dev/rd0a 1.7M 1.7M 38.5k 98% / Here's you're problem,... you're trying to install a whole OS onto a 1,7MB partition. I doubt he's trying to install stuff to the ramdisk...
Re: OpenBSD 4.4 - fdisk issue
On Tue, Nov 04, 2008 at 04:31:57PM +0100, [EMAIL PROTECTED] wrote: I just try to install OpenBSD 4.4 on a serveur (HP DL120 G5) to test the functionality of the raid (seens it works again .). I configure the first disk without any issue, and then try following commands: disklabel wd0 disklabel.wd1 fdisk -i wd1 disklabel -R -r wd1 disklabel.wd1 newfs /dev/wd1a Error: newfs: /dev/wd1a: block device Second section of the newfs(8) manpage. -- Olivier Cherrier mailto:[EMAIL PROTECTED]
Re: OpenBSD 4.4 - fdisk issue
On Tue, Nov 04, 2008 at 04:31:57PM +0100, [EMAIL PROTECTED] wrote: I just try to install OpenBSD 4.4 on a serveur (HP DL120 G5) to test the functionality of the raid (seens it works again .). I configure the first disk without any issue, and then try following commands: disklabel wd0 disklabel.wd1 fdisk -i wd1 disklabel -R -r wd1 disklabel.wd1 newfs /dev/wd1a Error: newfs: /dev/wd1a: block device Second section of the newfs(8) manpage. Great ... This worked in 4.3 without any thing else; I didn't find anything in this section. http://www.openbsd.org/cgi-bin/man.cgi?query=newfsapropos=0sektion=0manpa th=OpenBSD+4.4arch=i386format=html What should I search for ?
Re: OpenBSD 4.4 - fdisk issue
On Tue, Nov 04, 2008 at 05:39:46PM +0100, Christophe Rioux wrote: On Tue, Nov 04, 2008 at 04:31:57PM +0100, [EMAIL PROTECTED] wrote: I just try to install OpenBSD 4.4 on a serveur (HP DL120 G5) to test the functionality of the raid (seens it works again .). I configure the first disk without any issue, and then try following commands: disklabel wd0 disklabel.wd1 fdisk -i wd1 disklabel -R -r wd1 disklabel.wd1 newfs /dev/wd1a Error: newfs: /dev/wd1a: block device Second section of the newfs(8) manpage. Great ... This worked in 4.3 without any thing else; Likely not just as typed above. What should I search for ? The second paragraph under DESCRIPTION in http://www.openbsd.org/cgi-bin/man.cgi?query=newfs seems pretty clear, and pretty clearly relevant. cheers, -wb
Re: OpenBSD 4.4 - fdisk issue
On Tue, Nov 04, 2008 at 12:59:29PM -0500, William Boshuck wrote: On Tue, Nov 04, 2008 at 05:39:46PM +0100, Christophe Rioux wrote: On Tue, Nov 04, 2008 at 04:31:57PM +0100, [EMAIL PROTECTED] wrote: I just try to install OpenBSD 4.4 on a serveur (HP DL120 G5) to test the functionality of the raid (seens it works again .). I configure the first disk without any issue, and then try following commands: disklabel wd0 disklabel.wd1 fdisk -i wd1 disklabel -R -r wd1 disklabel.wd1 newfs /dev/wd1a Error: newfs: /dev/wd1a: block device Second section of the newfs(8) manpage. Great ... This worked in 4.3 without any thing else; Likely not just as typed above. Sorry, this does seem ok in 4.3. (An example in the FAQ uses a relative path, and that's what I've always done.) cheers, -wb
Re: OpenBSD 4.4 installation error: write failed; file system full
On Tue, Nov 4, 2008 at 12:32 PM, Chris [EMAIL PROTECTED] wrote: I've download and burned the 4.4 ISO from a local mirror and trying to upgrade from 4.3 to 4.4 on i386. After the installer does the fsck -fp, I get the following error: uid 0 on /: file system full /: write failed; file system full cp: /tmp/hosts: No space left on device I've also tried the 4.3 base CD and I get the same error. This has never happened before. Is there something I'm doing wrong? Yes! Here's my df -h output: /dev/rd0a 1.7M 1.7M 38.5k 98% / Here's you're problem,... you're trying to install a whole OS onto a 1,7MB partition.
Re: OpenBSD 4.4 - fdisk issue
On Tue, Nov 04, 2008 at 05:39:46PM +0100, Christophe Rioux wrote: On Tue, Nov 04, 2008 at 04:31:57PM +0100, [EMAIL PROTECTED] wrote: I just try to install OpenBSD 4.4 on a serveur (HP DL120 G5) to test the functionality of the raid (seens it works again .). I configure the first disk without any issue, and then try following commands: disklabel wd0 disklabel.wd1 fdisk -i wd1 disklabel -R -r wd1 disklabel.wd1 newfs /dev/wd1a Error: newfs: /dev/wd1a: block device Second section of the newfs(8) manpage. Great ... This worked in 4.3 without any thing else; I didn't find anything in this section. http://www.openbsd.org/cgi-bin/man.cgi?query=newfsapropos=0sektion=0manpa th=OpenBSD+4.4arch=i386format=html What should I search for ? Use the raw device (/dev/rwd1a). Running newfs on a block device (/dev/wd1a) can lead to subtle and hard to diagnose problems. That's why it has been disabled in 4.4. -Otto
Re: OpenBSD 4.4 installation error: write failed; file system full
On Tue, Nov 4, 2008 at 4:51 AM, Alexander Hall [EMAIL PROTECTED] wrote: I doubt he's trying to install stuff to the ramdisk... Thanks all for your help. My current OpenBSD 4.3 installation is sitting on / (/var, /home, /root and everything else is under /) - only one partition. And I have about 34.7g free in there. So my / is not small and has gigs of space free available. Also, my /etc/hosts file is 666K. Thanks for any further help.
Re: OpenBSD 4.4 installation error: write failed; file system full
On Tue, Nov 04, 2008 at 02:37:40PM -0800, Chris wrote: On Tue, Nov 4, 2008 at 4:51 AM, Alexander Hall [EMAIL PROTECTED] wrote: I doubt he's trying to install stuff to the ramdisk... Thanks all for your help. My current OpenBSD 4.3 installation is sitting on / (/var, /home, /root and everything else is under /) - only one partition. And I have about 34.7g free in there. So my / is not small and has gigs of space free available. Also, my /etc/hosts file is 666K. Thanks for any further help. The upgrade.sh script will copy the hosts file onto the ramdisk. A 666K hosts file is enough to be problematic I suspect. Ken
Re: OpenBSD 4.4 - fdisk issue
On Tue, Nov 04, 2008 at 04:31:57PM +0100, Christophe Rioux wrote: Hi I just try to install OpenBSD 4.4 on a serveur (HP DL120 G5) to test the functionality of the raid (seens it works again .). I configure the first disk without any issue, and then try following commands: disklabel wd0 disklabel.wd1 fdisk -i wd1 disklabel -R -r wd1 disklabel.wd1 newfs /dev/wd1a Error: newfs: /dev/wd1a: block device Same message when I try a mount. Not a problem I continue and made a new installation on wd1 (with the CD) Then I build my raid0 configuration (by compiling the kernel) and try to create the new disk: fdisk -i raid0 disklabel -E -raid0 newfs /dev/raid0a = same error by newfs and mount What do I wrong ? Regards It shouldn't affect your problem, but '-r' doesn't do anything anymore. Ken
Re: OpenBSD 4.4 installation error: write failed; file system full
On Wed, Nov 5, 2008 at 10:38 AM, Kenneth R Westerback [EMAIL PROTECTED] wrote: On Tue, Nov 04, 2008 at 02:37:40PM -0800, Chris wrote: On Tue, Nov 4, 2008 at 4:51 AM, Alexander Hall [EMAIL PROTECTED] wrote: I doubt he's trying to install stuff to the ramdisk... Thanks all for your help. My current OpenBSD 4.3 installation is sitting on / (/var, /home, /root and everything else is under /) - only one partition. And I have about 34.7g free in there. So my / is not small and has gigs of space free available. Also, my /etc/hosts file is 666K. Thanks for any further help. The upgrade.sh script will copy the hosts file onto the ramdisk. A 666K hosts file is enough to be problematic I suspect. Yes, you are right. It was the /etc/hosts file. The installation went smoothly after removing lots of entries from there. Most of the entries of my /etc/hosts file actually come from http://www.mvps.org/winhelp2002/hosts.htm - it basically blackholes unwanted sites. Is there any way I can get around the upgrade issue without having to remove entries from my /etc/hosts file? Thanks.
Re: OpenBSD 4.4 installation error: write failed; file system full
Cheap easy fast way is to move /etc/hosts somewhere else prior to upgrade. Not sure if things like sysmerge will help On 11/4/08, Chris [EMAIL PROTECTED] wrote: On Wed, Nov 5, 2008 at 10:38 AM, Kenneth R Westerback [EMAIL PROTECTED] wrote: On Tue, Nov 04, 2008 at 02:37:40PM -0800, Chris wrote: On Tue, Nov 4, 2008 at 4:51 AM, Alexander Hall [EMAIL PROTECTED] wrote: I doubt he's trying to install stuff to the ramdisk... Thanks all for your help. My current OpenBSD 4.3 installation is sitting on / (/var, /home, /root and everything else is under /) - only one partition. And I have about 34.7g free in there. So my / is not small and has gigs of space free available. Also, my /etc/hosts file is 666K. Thanks for any further help. The upgrade.sh script will copy the hosts file onto the ramdisk. A 666K hosts file is enough to be problematic I suspect. Yes, you are right. It was the /etc/hosts file. The installation went smoothly after removing lots of entries from there. Most of the entries of my /etc/hosts file actually come from http://www.mvps.org/winhelp2002/hosts.htm - it basically blackholes unwanted sites. Is there any way I can get around the upgrade issue without having to remove entries from my /etc/hosts file? Thanks. -- http://www.glumbert.com/media/shift http://www.youtube.com/watch?v=tGvHNNOLnCk This officer's men seem to follow him merely out of idle curiosity. -- Sandhurst officer cadet evaluation. Securing an environment of Windows platforms from abuse - external or internal - is akin to trying to install sprinklers in a fireworks factory where smoking on the job is permitted. -- Gene Spafford learn french: http://www.youtube.com/watch?v=j1G-3laJJP0feature=related
Re: OpenBSD 4.4 installation error: write failed; file system full
On Tue, Nov 4, 2008 at 7:23 PM, Chris [EMAIL PROTECTED] wrote: Most of the entries of my /etc/hosts file actually come from http://www.mvps.org/winhelp2002/hosts.htm - it basically blackholes unwanted sites. Is there any way I can get around the upgrade issue without having to remove entries from my /etc/hosts file? Thanks. adblock in the browser is far more flexible, faster, and just plain works better. If you really feel that giant lists of banned addresses are the way to go, run a nameserver and do it there.
Re: OpenBSD 4.4 installation error: write failed; file system full
On Wed, Nov 05, 2008 at 11:23:20AM +1100, Chris wrote: On Wed, Nov 5, 2008 at 10:38 AM, Kenneth R Westerback [EMAIL PROTECTED] wrote: On Tue, Nov 04, 2008 at 02:37:40PM -0800, Chris wrote: On Tue, Nov 4, 2008 at 4:51 AM, Alexander Hall [EMAIL PROTECTED] wrote: I doubt he's trying to install stuff to the ramdisk... Thanks all for your help. My current OpenBSD 4.3 installation is sitting on / (/var, /home, /root and everything else is under /) - only one partition. And I have about 34.7g free in there. So my / is not small and has gigs of space free available. Also, my /etc/hosts file is 666K. Thanks for any further help. The upgrade.sh script will copy the hosts file onto the ramdisk. A 666K hosts file is enough to be problematic I suspect. Yes, you are right. It was the /etc/hosts file. The installation went smoothly after removing lots of entries from there. Most of the entries of my /etc/hosts file actually come from http://www.mvps.org/winhelp2002/hosts.htm - it basically blackholes unwanted sites. Is there any way I can get around the upgrade issue without having to remove entries from my /etc/hosts file? Thanks. I don't know off the top of my head, but now that you've identified the issue I'll put it on my list to look into. Ken
Re: OpenBSD 4.4 installation error: write failed; file system full
On Tue, Nov 04, 2008 at 08:13:08PM -0500, Ted Unangst wrote: | On Tue, Nov 4, 2008 at 7:23 PM, Chris [EMAIL PROTECTED] wrote: | Most of the entries of my /etc/hosts file actually come from | http://www.mvps.org/winhelp2002/hosts.htm - it basically blackholes | unwanted sites. Is there any way I can get around the upgrade issue | without having to remove entries from my /etc/hosts file? Thanks. | | adblock in the browser is far more flexible, faster, and just plain | works better. If you really feel that giant lists of banned addresses | are the way to go, run a nameserver and do it there. Which gives you the added benefit of being able to share these results with other computers in your network by configuring them to use said nameserver. Saves you from distributing this hosts file to a couple of machines. (I second Ted on the suggestion to use adblockers in your browser though). Cheers, Paul 'WEiRD' de Weerd -- [++-]+++.+++[---].+++[+ +++-].++[-]+.--.[-] http://www.weirdnet.nl/
