Re: softraid RAID1 + CRYPTO error writing metadata
On Sat, 9 Feb 2013, Scott McEachern wrote: > On 02/08/13 11:26, Joel Sing wrote: > > On Sat, 9 Feb 2013, Jiri B wrote: > >> On Sat, Feb 09, 2013 at 02:56:47AM +1100, Joel Sing wrote: > >>> While stacked softraid volumes generally work, they are not officially > >>> supported (for a variety of reasons). The problem that you mention > >>> above is due to the way that softraid volumes are shutdown - the > >>> shutdown order is approximately the same as the order they are created. > >>> In your case this means that sd3 gets shutdown before sd4, hence sd4 is > >>> unable to write metadata to sd3. For the time being, in order to avoid > >>> the issue you should disassemble the CRYPTO volume (sd4) before the > >>> RAID 1 volume (sd3). > > Shit, I forgot to mention that I already gave that a whirl by putting: > > umount -f /st3 <-- the mount point of the crypto volume > > in /etc/rc.shutdown. It makes no difference; I still get that > warning/error. > > I also tried: > > umount -f 6c6e53ab843ef6c8.a <-- the DUID of the crypto volume umount via DUID does not work currently - this will be fixed shortly after the next release freeze has ended. > and, curiously, it says that it's not currently mounted. (Yet that's > exactly how I mount it with bioctl in rc.securelevel, where it prompts > me for the password.) I've also tried doing it by hand (vs. > rc.shutdown) and it still doesn't matter. > > Any other suggestions? > > Also, as I said I haven't lost any data thus far and other than seeing > that message it works just fine. Am I 1) just "lucky" so far (and will > eventually not be so lucky), 2) is it just cleaning up after itself on > reboot (my rc.securelevel script runs an fsck -p on the volume before > mounting it), or 3) is it actually working but just not very pretty? Mostly (3) - if you are unmounting the file system then the actual chance of data loss is low (file systems should unmount on shutdown before the softraid volumes are torn down). On shutdown of a volume the metadata is updated and this is what is failing. > >> Would stackable softraid volumes work in near future or is it big > >> problem as how softraid was designed? > > > > Generally speaking they already "work" - there are just some caveats, > > primarily relating to assembly and shutdown. Most of the issues are > > fairly easily fixed or are at least solvable (the shutdown ordering > > should be simple - I just need to move it up the priority list). That > > said, longer term I would rather have disciplines such as RAID1C and > > RAID10 that handle the stacking internally and allow for better operation > > and management. > > With that approach (RAID1C) would that also work when the entire volume > isn't encrypted, like in my case where only one partition of the HDD is > crypto? Since softraid works with partitions and not disks, you could turn sd0a/sd1a into a RAID1C volume and sd0d/sd1d into a pure RAID1 volume (rather than splitting up the RAID1 volume). The only real downside to this is that a physical disk failure then requires two separate rebuilds. > Either way, it sounds fantastic and having "smooth" RAID (esp. crypto) > operations, l think, would be a huge feather in OpenBSD's cap. I > haven't tried full disk encryption yet, maybe on a test box one day, > because I just don't need that overhead for every disk access. -- "Reason is not automatic. Those who deny it cannot be conquered by it. Do not count on them. Leave them alone." -- Ayn Rand
Re: usb hub as kvm switch
On Sat, 2013-02-09 at 05:54 +0100, Zoran Kolic wrote: > I have two nodes side by side. KVM switches for just > usb are almost imposible to find in my area. I plan > to use usb keyboard and usb mouse only, since my mo- > nitor has two adapters for both boxen. > Is it possible to use plain usb hub to do the job? > One of the nodes would be openbsd 5.2 amd64. I don't see how a plain hub could possibly work as a KVM switch, unless I am missing something. A workaround you may consider would be a PS/2 KVM switch where the KVM switch's PS/2 exit cables go into PS/2-USB adapters. (Or are those adapters just as rare in your area?) -- Shawn K. Quinn
Re: softraid RAID1 + CRYPTO error writing metadata
On Sat, 9 Feb 2013, Stuart Henderson wrote: > On 2013-02-08, Paul de Weerd wrote: > > On Fri, Feb 08, 2013 at 01:54:27PM -0500, Scott McEachern wrote: > >| What kind of hardware do you have powering those machines? Besides, > >| I don't use the crypto partition too often and I really should make > >| it smaller (it's only at 17% capacity out of 1.4TB). > > > > Admittedly, these are pretty powerful machines. And Antoine was > > right, it's amd64 (I don't have i386 in real day-to-day use anymore). > > But here are the dmesgs for my office workstation and my laptop: > > > > --- office workstation --- > > > > > cpu0: > > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,C > >FLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS- > >CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT, > >DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,E > >RMS > > Seeing "AES" in this line is useful for a system using softraid crypto. No, it is not currently - aesni(4) does not yet have support for AES XTS, so a CPU with AES instructions will not help any. This should change soon :) -- "Reason is not automatic. Those who deny it cannot be conquered by it. Do not count on them. Leave them alone." -- Ayn Rand
usb hub as kvm switch
I have two nodes side by side. KVM switches for just usb are almost imposible to find in my area. I plan to use usb keyboard and usb mouse only, since my mo- nitor has two adapters for both boxen. Is it possible to use plain usb hub to do the job? One of the nodes would be openbsd 5.2 amd64. Best regards Zoran
Re: bge(4) Broadcom 5720/Dell R320 support backout
Rodolfo Gouveia [rgouv...@cosmico.net] wrote: > Hi all, > It seems that the support for 5720 was backout because > it broke another chipset. [1] > The thing is that the newer Dell R320 has this chipset and > I'm currently evaluating the its support. > So I would like to know if the support would indeed work > if I applied the patch again. I mean was the only reason > to backout the break in other chipset? Yes
Re: pppx interface group
Robert Blacquiere [open...@blacquiere.nl] wrote: > Hi, > > I've seen on the tech mailing list a patch for implementing a pppx > interface group (just one line code addition). Is this going to be in > 5.3 release? It would make PF filtering much nicer with many dynamic > ipsec/l2tp connections. > Yes
Re: openbsd and vmware
On Thu Feb 7 2013 17:50, Jan Lambertz wrote: > I also tried the socket trick in different setups but couldn't make it > work. You *do* boot bsd.mp, right? Because bsd.rd never recognised a such configured VM as being SMP-capable in my case, and installed bsd.sp by default, instead. > I tried a smp 4,threads 1 cores 1 sockets 4. Sysctl tells cpus are > found but not used. Did you pass any special cpu information to qemu ? Sorry, I can't tell. I used RHEV 3.1 and by increasing the number of sockets, it linearly increased the number of cores, too. So, did you try 4 cores and 4 sockets, then?
Re: softraid RAID1 + CRYPTO error writing metadata
On 2013-02-08, Paul de Weerd wrote: > On Fri, Feb 08, 2013 at 01:54:27PM -0500, Scott McEachern wrote: >| What kind of hardware do you have powering those machines? Besides, >| I don't use the crypto partition too often and I really should make >| it smaller (it's only at 17% capacity out of 1.4TB). > > Admittedly, these are pretty powerful machines. And Antoine was > right, it's amd64 (I don't have i386 in real day-to-day use anymore). > But here are the dmesgs for my office workstation and my laptop: > > --- office workstation --- > 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,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS Seeing "AES" in this line is useful for a system using softraid crypto.
Re: 5.2, i386, small kernel crash
On 08.02.13 20:34, Mike Larkin wrote: Kernels other than GENERIC/GENERIC.MP and RAMDISK aren't supported by devs. Ok, sorry for the noise. That being said, we should probably clean up the do_real_mode_post business at some point. I think it's outlived its usefulness. I found the problem. I had removed the line vga0 at isa? in my config. And the assignment to do_real_mode_post only happens if sc->sc_dev.dv_unit == 0. But this also means, that the assignment is normally never executed and superfluous. Like you said, there seem to be cleanups appropriate... regards, chris
Re: softraid RAID1 + CRYPTO error writing metadata
On 02/08/13 15:19, Paul de Weerd wrote: Admittedly, these are pretty powerful machines. And Antoine was right, it's amd64 (I don't have i386 in real day-to-day use anymore). I have a couple of P4s (no HT) running i386 (firewall, and my web/db server), but otherwise everything is amd64. But here are the dmesgs for my office workstation and my laptop: --- office workstation --- OpenBSD 5.3-beta (GENERIC.MP) #27: Sun Feb 3 18:03:44 MST 2013 t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8541622272 (8145MB) avail mem = 8291753984 (7907MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xec1b0 (83 entries) bios0: vendor Dell Inc. version "A08" date 09/19/2012 bios0: Dell Inc. OptiPlex 9010 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT SSDT SSDT DMAR ASF! SLIC acpi0: wakeup devices PS2K(S3) PS2M(S3) UAR1(S3) P0P1(S4) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3) USB6(S3) USB7(S3) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) PXSX(S4) RP08(S4) PEGP(S4) PEG0(S4) PEG1(S4) PEG2(S4) PEG3(S4) GLAN(S4) EHC1(S0) EHC2(S0) XHC_(S0) HDEF(S4) PWRB(S3) 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) Core(TM) i7-3770 CPU @ 3.40GHz, 3392.85 MHz Geez, that looks familiar... :) My workhorse (not workstation since X doesn't work): OpenBSD 5.3-beta (GENERIC.MP) #29: Thu Feb 7 19:31:06 MST 2013 t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 16851365888 (16070MB) avail mem = 16380297216 (15621MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb410 (112 entries) bios0: vendor American Megatrends Inc. version "0408" date 06/05/2012 bios0: ASUSTeK COMPUTER INC. P8Z77-V PREMIUM acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT SSDT SSDT MSDM BGRT acpi0: wakeup devices PS2K(S4) PS2M(S4) P0P1(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) RP08(S4) PEGP(S4) PEG0(S4) PEG1(S4) PEG2(S4) PEG3(S4) RP07(S4) GLAN(S4) EHC1(S4) EHC2(S4) XHC_(S4) HDEF(S4) PWRB(S4) 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) Core(TM) i7-3770K CPU @ 3.50GHz, 3606.12 MHz So if your 3770 can handle it fine, mine probably can too. :) I should also mention that I have three boot SSDs (various OSes, runs OpenBSD 90% of the time) plus the two big RAID volumes for data, so going FDE isn't entirely useful. My workstation isn't too shabby either: OpenBSD 5.2-current (GENERIC.MP) #20: Mon Jan 21 17:23:23 MST 2013 t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 12613910528 (12029MB) avail mem = 12255641600 (11687MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.5 @ 0x9f400 (68 entries) bios0: vendor American Megatrends Inc. version "2105" date 07/23/2010 bios0: ASUSTeK Computer INC. M4A785TD-V EVO acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S3 S4 S5 acpi0: tables DSDT FACP APIC MCFG OEMB SRAT HPET SSDT acpi0: wakeup devices PCE2(S4) PCE3(S4) PCE4(S4) PCE5(S4) PCE6(S4) PCE7(S4) PCE9(S4) PCEA(S4) PCEB(S4) PCEC(S4) SBAZ(S4) PS2M(S4) PS2K(S4) UAR1(S4) P0PC(S4) UHC1(S4) UHC2(S4) UHC3(S4) USB4(S4) UHC5(S4) UHC6(S4) UHC7(S4) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Phenom(tm) II X6 1100T Processor, 3315.25 MHz but again, the big volumes are just for storage and the OS/boot is also from an SSD. I have a 3.2GHz P4 (with HT, so it's amd64) as a general server and it has a crypto volume. I don't think FDE would fly quite so well on it... I'd love for the web/database server to be FDE, but a 2.8GHz i386 P4 would probably cry in pain. The bottom line is that for the machines that are capable of FDE, I run an SSD/HDD split for the OS/data. Not a lot of point in encrypting the OS for the sake of it, at least in my case. -- Scott McEachern https://www.blackstaff.ca
Re: softraid RAID1 + CRYPTO error writing metadata
On Fri, Feb 08, 2013 at 01:54:27PM -0500, Scott McEachern wrote: | What kind of hardware do you have powering those machines? Besides, | I don't use the crypto partition too often and I really should make | it smaller (it's only at 17% capacity out of 1.4TB). Admittedly, these are pretty powerful machines. And Antoine was right, it's amd64 (I don't have i386 in real day-to-day use anymore). But here are the dmesgs for my office workstation and my laptop: --- office workstation --- OpenBSD 5.3-beta (GENERIC.MP) #27: Sun Feb 3 18:03:44 MST 2013 t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8541622272 (8145MB) avail mem = 8291753984 (7907MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xec1b0 (83 entries) bios0: vendor Dell Inc. version "A08" date 09/19/2012 bios0: Dell Inc. OptiPlex 9010 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT SSDT SSDT DMAR ASF! SLIC acpi0: wakeup devices PS2K(S3) PS2M(S3) UAR1(S3) P0P1(S4) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3) USB6(S3) USB7(S3) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) PXSX(S4) RP08(S4) PEGP(S4) PEG0(S4) PEG1(S4) PEG2(S4) PEG3(S4) GLAN(S4) EHC1(S0) EHC2(S0) XHC_(S0) HDEF(S4) PWRB(S3) 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) Core(TM) i7-3770 CPU @ 3.40GHz, 3392.85 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,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu0: 256KB 64b/line 8-way L2 cache cpu0: apic clock running at 99MHz cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz, 3392.30 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,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu1: 256KB 64b/line 8-way L2 cache cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz, 3392.30 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,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu2: 256KB 64b/line 8-way L2 cache cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz, 3392.30 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,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu3: 256KB 64b/line 8-way L2 cache cpu4 at mainbus0: apid 1 (application processor) cpu4: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz, 3392.30 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,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu4: 256KB 64b/line 8-way L2 cache cpu5 at mainbus0: apid 3 (application processor) cpu5: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz, 3392.30 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,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu5: 256KB 64b/line 8-way L2 cache cpu6 at mainbus0: apid 5 (application processor) cpu6: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz, 3392.30 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,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu6: 256KB 64b/line 8-way L2 cache cpu7 at mainbus0: apid 7 (application processor) cpu7: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz, 3392.30 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,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,
Re: 5.2, i386, small kernel crash
On Fri, Feb 08, 2013 at 06:56:08PM +0100, Christian Groessler wrote: > Hi, > > I've tried to make a kernel config which only includes what I need. It's > attached. > > The resulting kernel crashes in vga_pci_attach() when it writes to > do_real_mode_post. > do_real_mode_post is in the text section, so should be readonly, > therefore the crash makes sense. > > But when I build GENERIC the crash doesn't happen, do_real_mode_post > still in text section. > How does this work? > > And, what is wrong with my config? In the meanwhile I'm avoiding the > crash by patching > vga_pci.c. The machine won't got to sleep (it's a server), so it's ok > for now. > Kernels other than GENERIC/GENERIC.MP and RAMDISK aren't supported by devs. That being said, we should probably clean up the do_real_mode_post business at some point. I think it's outlived its usefulness. -ml
Re: softraid RAID1 + CRYPTO error writing metadata
On 02/08/13 13:32, Paul de Weerd wrote: On Fri, Feb 08, 2013 at 12:52:00PM -0500, Scott McEachern wrote: | Either way, it sounds fantastic and having "smooth" RAID (esp. | crypto) operations, l think, would be a huge feather in OpenBSD's | cap. I haven't tried full disk encryption yet, maybe on a test box | one day, because I just don't need that overhead for every disk | access. Full disk encryption works fine for me on the two systems where I run it on. I found that most disk IO is to the FS I want crypted anyway, so I thought "let's not optimize the infrequent path" and just went FDE. The only real downside is that it's currently lacking installer integration, but doing those few steps by hand isn't exactly rocket science anyway, so FDE is definitely my preferred aproach for my (future) installs. Paul 'WEiRD' de Weerd What kind of hardware do you have powering those machines? Besides, I don't use the crypto partition too often and I really should make it smaller (it's only at 17% capacity out of 1.4TB). I should also run some simple benchmarks here to get a vague idea of what kind of overhead is actually involved on my own hardware. -- Scott McEachern https://www.blackstaff.ca
Re: softraid RAID1 + CRYPTO error writing metadata
On Fri, Feb 08, 2013 at 07:32:49PM +0100, Paul de Weerd wrote: > On Fri, Feb 08, 2013 at 12:52:00PM -0500, Scott McEachern wrote: > | Either way, it sounds fantastic and having "smooth" RAID (esp. > | crypto) operations, l think, would be a huge feather in OpenBSD's > | cap. I haven't tried full disk encryption yet, maybe on a test box > | one day, because I just don't need that overhead for every disk > | access. > > Full disk encryption works fine for me on the two systems where I run > it on. I found that most disk IO is to the FS I want crypted anyway, > so I thought "let's not optimize the infrequent path" and just went > FDE. The only real downside is that it's currently lacking installer > integration, but doing those few steps by hand isn't exactly rocket > science anyway, so FDE is definitely my preferred aproach for my > (future) installs. As long as you run i386|amd64... -- Antoine
Re: softraid RAID1 + CRYPTO error writing metadata
On Fri, Feb 08, 2013 at 12:52:00PM -0500, Scott McEachern wrote: | Either way, it sounds fantastic and having "smooth" RAID (esp. | crypto) operations, l think, would be a huge feather in OpenBSD's | cap. I haven't tried full disk encryption yet, maybe on a test box | one day, because I just don't need that overhead for every disk | access. Full disk encryption works fine for me on the two systems where I run it on. I found that most disk IO is to the FS I want crypted anyway, so I thought "let's not optimize the infrequent path" and just went FDE. The only real downside is that it's currently lacking installer integration, but doing those few steps by hand isn't exactly rocket science anyway, so FDE is definitely my preferred aproach for my (future) installs. Paul 'WEiRD' de Weerd -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: softraid RAID1 + CRYPTO error writing metadata
On 02/08/13 13:00, Stefan Sperling wrote: On Fri, Feb 08, 2013 at 12:52:00PM -0500, Scott McEachern wrote: Shit, I forgot to mention that I already gave that a whirl by putting: umount -f /st3 <-- the mount point of the crypto volume in /etc/rc.shutdown. It makes no difference; I still get that warning/error. I also tried: umount -f 6c6e53ab843ef6c8.a <-- the DUID of the crypto volume and, curiously, it says that it's not currently mounted. (Yet that's exactly how I mount it with bioctl in rc.securelevel, where it prompts me for the password.) I've also tried doing it by hand (vs. rc.shutdown) and it still doesn't matter. Any other suggestions? You have to destroy the softraid volume, too, in addition to unmounting the filesystem. Running 'bioctl -d sd4' should do the trick. You want to see 'sd4 detached' in dmesg before 'sd3 detached'. Aha! I gave that a shot and everything works *perfectly*. No more "ugly" messages and I feel much better about the integrity of my data. Thanks very much Joel and Stefan, your work and help has been invaluable! Now, the fun begins: I have two 3TB RAID1 volumes, with no encryption, on another machine (acting like an OpenBSD NAS box, really) at 65% and 40% capacity (do the math..) Because I was unsure of the crypto volume's integrity on this machine, stuff is rsynced to that machine. Now that I know to destroy the crypto volumes I get to do some juggling in order to create crypto partitions on those volumes. This is gonna take a while. *laughs* -- Scott McEachern https://www.blackstaff.ca
Re: 5.2, i386, small kernel crash
On Fri, Feb 8, 2013 at 11:56 AM, Christian Groessler wrote: > Hi, > > I've tried to make a kernel config which only includes what I need. It's > attached. > > The resulting kernel crashes in vga_pci_attach() when it writes to > do_real_mode_post. > do_real_mode_post is in the text section, so should be readonly, > therefore the crash makes sense. > > But when I build GENERIC the crash doesn't happen, do_real_mode_post > still in text section. > How does this work? > > Aahhh, I must grab some popcorn for this one. Friday fun, whee...
Re: softraid RAID1 + CRYPTO error writing metadata
On Fri, Feb 08, 2013 at 12:52:00PM -0500, Scott McEachern wrote: > Shit, I forgot to mention that I already gave that a whirl by putting: > > umount -f /st3 <-- the mount point of the crypto volume > > in /etc/rc.shutdown. It makes no difference; I still get that > warning/error. > > I also tried: > > umount -f 6c6e53ab843ef6c8.a <-- the DUID of the crypto volume > > and, curiously, it says that it's not currently mounted. (Yet > that's exactly how I mount it with bioctl in rc.securelevel, where > it prompts me for the password.) I've also tried doing it by hand > (vs. rc.shutdown) and it still doesn't matter. > > Any other suggestions? You have to destroy the softraid volume, too, in addition to unmounting the filesystem. Running 'bioctl -d sd4' should do the trick. You want to see 'sd4 detached' in dmesg before 'sd3 detached'.
5.2, i386, small kernel crash
Hi, I've tried to make a kernel config which only includes what I need. It's attached. The resulting kernel crashes in vga_pci_attach() when it writes to do_real_mode_post. do_real_mode_post is in the text section, so should be readonly, therefore the crash makes sense. But when I build GENERIC the crash doesn't happen, do_real_mode_post still in text section. How does this work? And, what is wrong with my config? In the meanwhile I'm avoiding the crash by patching vga_pci.c. The machine won't got to sleep (it's a server), so it's ok for now. RCS file: /nfs/soft/OpenBSD/openbsd-rsync/src/sys/dev/pci/vga_pci.c,v retrieving revision 1.67 diff -u -r1.67 vga_pci.c --- vga_pci.c 14 Apr 2011 21:04:29 - 1.67 +++ vga_pci.c 8 Feb 2013 17:55:53 - @@ -281,7 +281,7 @@ (subprod & vga_devs[i].rmask[3]) == vga_devs[i].rval[3]) { vga_pci_do_post = vga_devs[i].vga_pci_post; if (sc->sc_dev.dv_unit == 0)/* main screen only */ - do_real_mode_post = vga_devs[i].real_mode_post; + ; //do_real_mode_post = vga_devs[i].real_mode_post; break; } #endif And, yes, the subject line said it already, I'm running 5.2 on an i386. regards, chris # $OpenBSD: GENERIC,v 1.736 2012/07/12 09:45:56 mlarkin Exp $ # # For further information on compiling OpenBSD kernels, see the config(8) # man page. # # For further information on hardware support for this architecture, see # the intro(4) man page. For further information about kernel options # for this architecture, see the options(4) man page. For an explanation # of each device driver in this file see the section 4 man page for the # device. machine i386 option MULTIPROCESSOR # Multiple processor support #cpu* at mainbus? #option INSECURE# default to secure #option DDB # in-kernel debugger #option DDB_SAFE_CONSOLE # allow break into ddb during boot #makeoptionsDEBUG="-g" # compile full symbol table #makeoptionsPROF="-pg" # build profiled kernel #option GPROF # kernel profiling, kgmon(8) option DIAGNOSTIC # internal consistency checks option KTRACE # system call tracing, a la ktrace(1) #option ACCOUNTING # acct(2) process accounting #option KMEMSTATS # collect malloc(9) statistics option PTRACE # ptrace(2) system call #option KVA_GUARDPAGES # slow virtual address recycling (+ guarding) #option POOL_DEBUG # pool corruption detection #option VFSLCKDEBUG # VFS locking checks option CRYPTO # Cryptographic framework option SYSVMSG # System V-like message queues option SYSVSEM # System V-like semaphores option SYSVSHM # System V-like memory sharing #option UVM_SWAP_ENCRYPT# support encryption of pages going to swap option COMPAT_43 # Kernel compatibility with 4.3BSD option COMPAT_O48 # Kernel compatibility with OpenBSD 4.8 #option COMPAT_O51 # Kernel compatibility with OpenBSD 5.1 #option LKM # loadable kernel modules option FFS # UFS option FFS2# UFS2 option FFS_SOFTUPDATES # Soft updates option UFS_DIRHASH # hash large directories #option QUOTA # UFS quotas #option EXT2FS # Second Extended Filesystem option MFS # memory file system #option NNPFS # NNPFS filesystem #option NFSCLIENT # Network File System client #option NFSSERVER # Network File System server option CD9660 # ISO 9660 + Rock Ridge file system #option UDF # UDF (DVD) file system #option MSDOSFS # MS-DOS file system option FIFO# FIFOs; RECOMMENDED option SOCKET_SPLICE # Socket Splicing for TCP option TCP_SACK# Selective Acknowledgements for TCP option TCP_ECN # Explicit Congestion Notification for TCP #option TCP_SIGNATURE # TCP MD5 Signatures, for BGP routing sessions option TCP_FACK# Forward Acknowledgements for TCP option INET# IP + ICMP + TCP + UDP option ALTQ# ALTQ base #option INET6 # IPv6 (needs INET) option IPSEC # IPsec option KEY # PF_KEY (implied by IPSEC) #option PPP_BSDCOMP # PPP BSD compression #option PPP_DEFLATE #option PIPEX # Pppac IP EXtension, for npppd #option MROUTING# Multicast router #option PIM # Protocol Independent Multicast #option MPLS
Re: softraid RAID1 + CRYPTO error writing metadata
On 02/08/13 11:26, Joel Sing wrote: On Sat, 9 Feb 2013, Jiri B wrote: On Sat, Feb 09, 2013 at 02:56:47AM +1100, Joel Sing wrote: While stacked softraid volumes generally work, they are not officially supported (for a variety of reasons). The problem that you mention above is due to the way that softraid volumes are shutdown - the shutdown order is approximately the same as the order they are created. In your case this means that sd3 gets shutdown before sd4, hence sd4 is unable to write metadata to sd3. For the time being, in order to avoid the issue you should disassemble the CRYPTO volume (sd4) before the RAID 1 volume (sd3). Shit, I forgot to mention that I already gave that a whirl by putting: umount -f /st3 <-- the mount point of the crypto volume in /etc/rc.shutdown. It makes no difference; I still get that warning/error. I also tried: umount -f 6c6e53ab843ef6c8.a <-- the DUID of the crypto volume and, curiously, it says that it's not currently mounted. (Yet that's exactly how I mount it with bioctl in rc.securelevel, where it prompts me for the password.) I've also tried doing it by hand (vs. rc.shutdown) and it still doesn't matter. Any other suggestions? Also, as I said I haven't lost any data thus far and other than seeing that message it works just fine. Am I 1) just "lucky" so far (and will eventually not be so lucky), 2) is it just cleaning up after itself on reboot (my rc.securelevel script runs an fsck -p on the volume before mounting it), or 3) is it actually working but just not very pretty? Would stackable softraid volumes work in near future or is it big problem as how softraid was designed? Generally speaking they already "work" - there are just some caveats, primarily relating to assembly and shutdown. Most of the issues are fairly easily fixed or are at least solvable (the shutdown ordering should be simple - I just need to move it up the priority list). That said, longer term I would rather have disciplines such as RAID1C and RAID10 that handle the stacking internally and allow for better operation and management. With that approach (RAID1C) would that also work when the entire volume isn't encrypted, like in my case where only one partition of the HDD is crypto? Either way, it sounds fantastic and having "smooth" RAID (esp. crypto) operations, l think, would be a huge feather in OpenBSD's cap. I haven't tried full disk encryption yet, maybe on a test box one day, because I just don't need that overhead for every disk access. -- Scott McEachern https://www.blackstaff.ca
Re: Safe bruteforce rule for mobile-friendly website
So is there any point in having bruteforce for httpd? Especially now that "mobile is the future"? Mikkel 2013/2/7 Mikkel Bang > > I forget if mobiles do more prefetching on dns and/or tcp on mobiles but > > perhaps that's worth considering as a culprit. > > My God Kevin, that's gotta be it! > > > Does the page have more than 15 links? > > Yep, like 16-17 or so :) > > Mikkel > > > 2013/2/7 Kevin Chadwick > >> > I had to disable it as soon as I found out so the relevant logs are >> > probably too far up the buffer, but I'll set up a test server ASAP and >> > study the tcpdump in detail. >> >> I forget if mobiles do more prefetching on dns and/or tcp on mobiles but >> perhaps that's worth considering as a culprit. >> >> Does the page have more than 15 links? >> >> -- >> ___ >> >> 'Write programs that do one thing and do it well. Write programs to work >> together. Write programs to handle text streams, because that is a >> universal interface' >> >> (Doug McIlroy) >> ___
Re: softraid RAID1 + CRYPTO error writing metadata
On Sat, Feb 09, 2013 at 03:26:33AM +1100, Joel Sing wrote: > > Would stackable softraid volumes work in near future or is it big > > problem as how softraid was designed? > > Generally speaking they already "work" - there are just some caveats, > primarily relating to assembly and shutdown. Most of the issues are fairly > easily fixed or are at least solvable (the shutdown ordering should be > simple - I just need to move it up the priority list). That said, longer term > I would rather have disciplines such as RAID1C and RAID10 that handle the > stacking internally and allow for better operation and management. Thank you for reply, my question (and I suppose of many others) was mostly motivated by RAIDx & crypto stackable designs. jirib
Re: softraid RAID1 + CRYPTO error writing metadata
On Sat, 9 Feb 2013, Jiri B wrote: > On Sat, Feb 09, 2013 at 02:56:47AM +1100, Joel Sing wrote: > > While stacked softraid volumes generally work, they are not officially > > supported (for a variety of reasons). The problem that you mention above > > is due to the way that softraid volumes are shutdown - the shutdown order > > is approximately the same as the order they are created. In your case > > this means that sd3 gets shutdown before sd4, hence sd4 is unable to > > write metadata to sd3. For the time being, in order to avoid the issue > > you should disassemble the CRYPTO volume (sd4) before the RAID 1 volume > > (sd3). > > Would stackable softraid volumes work in near future or is it big > problem as how softraid was designed? Generally speaking they already "work" - there are just some caveats, primarily relating to assembly and shutdown. Most of the issues are fairly easily fixed or are at least solvable (the shutdown ordering should be simple - I just need to move it up the priority list). That said, longer term I would rather have disciplines such as RAID1C and RAID10 that handle the stacking internally and allow for better operation and management. -- "Reason is not automatic. Those who deny it cannot be conquered by it. Do not count on them. Leave them alone." -- Ayn Rand
Re: softraid RAID1 + CRYPTO error writing metadata
On Sat, Feb 09, 2013 at 02:56:47AM +1100, Joel Sing wrote: > While stacked softraid volumes generally work, they are not officially > supported (for a variety of reasons). The problem that you mention above is > due to the way that softraid volumes are shutdown - the shutdown order is > approximately the same as the order they are created. In your case this means > that sd3 gets shutdown before sd4, hence sd4 is unable to write metadata to > sd3. For the time being, in order to avoid the issue you should disassemble > the CRYPTO volume (sd4) before the RAID 1 volume (sd3). Would stackable softraid volumes work in near future or is it big problem as how softraid was designed? jirib
Re: softraid RAID1 + CRYPTO error writing metadata
On Fri, 8 Feb 2013, Scott McEachern wrote: > I get a rather curious error when shutting down a machine with a RAID 1 > setup that contains a crypto partition and a "normal" partition: > > syncing disks... done > sd3 detached > softraid0: I/O error 5 on dev 0x433 at block 16 > softraid0: could not write metadata to sd3d > sd4 detached > rebooting... > > When the machine starts up again, I see: > softraid0: sd4 was not shutdown properly (twice) > > The funny thing is that everything works just fine. No problems > whatsoever. > > That said, the error message is more than a little unsettling and I'm > worried that one day I'm going to access files on the crypto volume only > to find the data isn't available. > > Any hints on what I did wrong when setting this up? While stacked softraid volumes generally work, they are not officially supported (for a variety of reasons). The problem that you mention above is due to the way that softraid volumes are shutdown - the shutdown order is approximately the same as the order they are created. In your case this means that sd3 gets shutdown before sd4, hence sd4 is unable to write metadata to sd3. For the time being, in order to avoid the issue you should disassemble the CRYPTO volume (sd4) before the RAID 1 volume (sd3). > Details: > > The RAID volume, sd3, is made up from two 3TB as sd0 and sd1: > > # disklabel -pg sd0 > # /dev/rsd0c: > type: SCSI > disk: SCSI disk > label: ST3000DM001-1CH1 > duid: ec7586498efe98b8 > flags: > bytes/sector: 512 > sectors/track: 63 > tracks/cylinder: 255 > sectors/cylinder: 16065 > cylinders: 364801 > total sectors: 5860533168 # total bytes: 2794.5G > boundstart: 64 > boundend: 4294961685 > drivedata: 0 > > 16 partitions: > #size offset fstype [fsize bsize cpg] >a: 2794.5G 64RAID >c: 2794.5G0 unused > > # disklabel -pg sd1 > # /dev/rsd1c: > type: SCSI > disk: SCSI disk > label: ST3000DM001-1CH1 > duid: 0372b77b79b2e168 > flags: > bytes/sector: 512 > sectors/track: 63 > tracks/cylinder: 255 > sectors/cylinder: 16065 > cylinders: 364801 > total sectors: 5860533168 # total bytes: 2794.5G > boundstart: 64 > boundend: 4294961685 > drivedata: 0 > > 16 partitions: > #size offset fstype [fsize bsize cpg] >a: 2794.5G 64RAID >c: 2794.5G0 unused > > Those two drives then become sd3: (sd2 is an SSD boot drive) > > # disklabel -pg sd3 > # /dev/rsd3c: > type: SCSI > disk: SCSI disk > label: SR RAID 1 > duid: 6ca0888211d57886 > flags: > bytes/sector: 512 > sectors/track: 255 > tracks/cylinder: 511 > sectors/cylinder: 130305 > cylinders: 44975 > total sectors: 5860532576 # total bytes: 2794.5G > boundstart: 0 > boundend: 5860532576 > drivedata: 0 > > 16 partitions: > #size offset fstype [fsize bsize cpg] >a: 1397.3G0 4.2BSD 8192 655361 # /st2 >c: 2794.5G0 unused >d: 1397.3G 2930266240RAID > > from which a crypto volume was created, becoming sd4: > > # disklabel -pg sd4 > # /dev/rsd4c: > type: SCSI > disk: SCSI disk > label: SR CRYPTO > duid: 6c6e53ab843ef6c8 > flags: > bytes/sector: 512 > sectors/track: 63 > tracks/cylinder: 255 > sectors/cylinder: 16065 > cylinders: 182400 > total sectors: 2930265808 # total bytes: 1397.3G > boundstart: 0 > boundend: 2930265808 > drivedata: 0 > > 16 partitions: > #size offset fstype [fsize bsize cpg] >a: 1397.3G0 4.2BSD 8192 655361 >c: 1397.3G0 unused > > > I'm running a snapshot from Jan 21. Full dmesg: > > OpenBSD 5.2-current (GENERIC.MP) #20: Mon Jan 21 17:23:23 MST 2013 > t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 12613910528 (12029MB) > avail mem = 12255641600 (11687MB) > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.5 @ 0x9f400 (68 entries) > bios0: vendor American Megatrends Inc. version "2105" date 07/23/2010 > bios0: ASUSTeK Computer INC. M4A785TD-V EVO > acpi0 at bios0: rev 2 > acpi0: sleep states S0 S1 S3 S4 S5 > acpi0: tables DSDT FACP APIC MCFG OEMB SRAT HPET SSDT > acpi0: wakeup devices PCE2(S4) PCE3(S4) PCE4(S4) PCE5(S4) PCE6(S4) > PCE7(S4) PCE9(S4) PCEA(S4) PCEB(S4) PCEC(S4) SBAZ(S4) PS2M(S4) PS2K(S4) > UAR1(S4) P0PC(S4) UHC1(S4) UHC2(S4) UHC3(S4) USB4(S4) UHC5(S4) UHC6(S4) > UHC7(S4) > acpitimer0 at acpi0: 3579545 Hz, 32 bits > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: AMD Phenom(tm) II X6 1100T Processor, 3300.74 MHz > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFL >USH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2, >3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,I >TSC cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-wa
Re: pf blocking active connections
On 2013-02-08, Martijn van Duren wrote: > On Fri, 2013-02-08 at 08:23 +, Stuart Henderson wrote: >> On 2013-02-07, Martijn van Duren wrote: >> > Thanks for all the quick responses, but if I understand you all >> > correctly there is no way to cut off an established connection by adding >> > an ip address to a blocked table, so I'm still left with my two stage >> > drop off the connection (both adding the the ip to the table and killing >> > the connection manually). >> >> Correct because the state table is checked *before* packets run through the >> firewall ruleset. >> > > Correct me if I'm wrong, but isn't that still somewhat dangerous? Say > the next situation: > I have a rule in my firewall that limits ssh connections to 3 every 30 > seconds, if you exceed it your ip address is added to a table that has a > drop quick on it. Now at the same time that same ip-adress is brute > forcing on my ftp-port without building up a new connection between > retries. > When this ip address is automatically added to the blocked table he is > qualified as bad traffic and I'd expect that other traffic to my server > is cut short by then. > > Of course this is only an example of how an ip address could be > automatically added to a table and I don't expect that every method is > capable of also (easily,) automatically destroying an active connection. Read the part of pf.conf(5) which describes the stateful tracking options that you are using and you can see if this applies to the way you are using them.
Re: relayd and icecast
On 08/02/13 15:34, Sebastian Benoit wrote: Kapetanakis Giannis(bil...@edu.physics.uoc.gr) on 2013.02.08 14:32:21 +0200: On 07/02/13 15:50, Kapetanakis Giannis wrote: [snip] which version of OpenBSD are you using? I've been using 5.2 release, but yesterday I've installed latest snapshot (amd64). No change in behavior. G ps. so far I was able to debug back to bufferevent_new() which sets EVBUFFER_TIMEOUT
Re: relayd and icecast
Kapetanakis Giannis(bil...@edu.physics.uoc.gr) on 2013.02.08 14:32:21 +0200: > On 07/02/13 15:50, Kapetanakis Giannis wrote: [snip] which version of OpenBSD are you using?
Re: relayd and icecast
On 07/02/13 15:50, Kapetanakis Giannis wrote: Hi, I'm trying to use an OB server as an icecast streaming server. I'm also trying to use relayd as a relay between the client and icecast server to limit access to admin pages of icecast. I have a problem with relayd closing connections. I believe it does that because of the session timeout. Here are some details: # relayctl show sessions session 0:4 client_IP:49387 -> 127.0.0.1:8002 RUNNING age 00:00:38, idle 00:00:38, relay 1, pid 9275 relayd thinks it is idle although there are syn/ack packets going both directions. relayd debug: relay icecastproxy, session 4 (1 active), 0, client_IP -> 127.0.0.1:8002, hard timeout tcpdump: 15:34:48.116939 server.8000 > client.49387: P 695922:696058(136) ack 524 win 2172 (DF) 15:34:48.117150 server.8000 > client.49387: . 696058:697506(1448) ack 524 win 2172 (DF) 15:34:48.117197 server.8000 > client.49387: . 697506:698954(1448) ack 524 win 2172 (DF) 15:34:48.117251 client.49387 > server.8000: . ack 693026 win 83 (DF) 15:34:48.117275 client.49387 > server.8000: . ack 694474 win 82 (DF) 15:34:48.117291 client.49387 > server.8000: . ack 695922 win 80 (DF) 15:34:48.117307 client.49387 > server.8000: . ack 696058 win 80 (DF) 15:34:48.117663 client.49387 > server.8000: . ack 697506 win 83 (DF) 15:34:48.117691 client.49387 > server.8000: . ack 698954 win 82 (DF) 15:34:48.117744 server.8000 > client.49387: P 698954:700215(1261) ack 524 win 2172 (DF) 15:34:48.118333 client.49387 > server.8000: . ack 700215 win 83 (DF) *15:34:48.168128 server.8000 > client.49387: F 700215:700215(0) ack 524 win 2172 (DF)* 15:34:48.168467 client.49387 > server.8000: F 524:524(0) ack 700216 win 83 (DF) 15:34:48.168529 server.8000 > client.49387: . ack 525 win 2172 (DF) The server sends the FIN packet and closes the connection. my relayd.conf looks like this: relay icecastproxy { listen on $ext_addr port $ext_port # protocol adminfilter # limit access to admin pages forward to $icecast_host port $icecast_port session timeout 10 # seconds } pf is simple: anchor "relayd/*" all pass in quick all flags S/SA pass out all flags S/SA If I increase the session timeout to a BIG value then I have no problem. However I don't think this is the right approach. Shouldn't relayd treat the connection as NOT idle thus not close it? regards, Giannis I've managed to reproduce this with ssh and the example from relayd.conf protocol sshtcp { tcp nodelay } relay sshgw { listen on $ext_addr port protocol sshtcp session timeout 10 # seconds forward to $sshhost1 port 22 } If I type on terminal (press enter all the time) the connection stays open. Nevertheless relayctl show sessions shows idle==age no mater if I type or not. The connection is closed if I don't type anything in the terminal for 10 seconds. Even if the remote server sends me data (watch -n 1 date) the connection still closes. This takes more than 10 seconds... ssh root@relay -p # ksh # while [[ 1 ]] ; do ; date ; sleep 1; done Fri Feb 8 14:22:12 EET 2013 Fri Feb 8 14:22:13 EET 2013 ... Fri Feb 8 14:22:39 EET 2013 Fri Feb 8 14:22:40 EET 2013 Connection to relay closed by remote host. Giannis ps. Sometimes the connection is closed even if I type on the terminal: [sshhost1~]# date Fri Feb 8 14:26:39 EET 2013 [sshhost1~]# date Fri Feb 8 14:26:40 EET 2013 ... [sshhost1~]# date Fri Feb 8 14:27:38 EET 2013 [sshhost1~]# date Fri Feb 8 14:27:39 EET 2013 [sshhost1~]# Connection to relay closed by remote host. Connection to rs closed. [client ~] > date Fri Feb 8 14:27:43 EET 2013 clocks are synced
Re: pf blocking active connections
On Fri, 2013-02-08 at 08:23 +, Stuart Henderson wrote: > On 2013-02-07, Martijn van Duren wrote: > > Thanks for all the quick responses, but if I understand you all > > correctly there is no way to cut off an established connection by adding > > an ip address to a blocked table, so I'm still left with my two stage > > drop off the connection (both adding the the ip to the table and killing > > the connection manually). > > Correct because the state table is checked *before* packets run through the > firewall ruleset. > Correct me if I'm wrong, but isn't that still somewhat dangerous? Say the next situation: I have a rule in my firewall that limits ssh connections to 3 every 30 seconds, if you exceed it your ip address is added to a table that has a drop quick on it. Now at the same time that same ip-adress is brute forcing on my ftp-port without building up a new connection between retries. When this ip address is automatically added to the blocked table he is qualified as bad traffic and I'd expect that other traffic to my server is cut short by then. Of course this is only an example of how an ip address could be automatically added to a table and I don't expect that every method is capable of also (easily,) automatically destroying an active connection. Martijn
Re: pf blocking active connections
--> patrick keshishian [2013-02-07 12:16:40 -0800]: > look in 'man pfctl' and search for killing active sessions. > > > On Thu, Feb 7, 2013 at 12:13 PM, Martijn van Duren > wrote: > > Hello misc, > > > > Today I watch the current connections on my small home server and I > > noticed an unfamiliar ftp-connection. Upon inspecting the connection I > > noticed it was a brute force attack, so I fired up my pfctl-utility and > > tried to block the attack by adding the ip to my quick drop table. > > After adding the ip to the table I noticed that the connection was still > > happily active and even reloading my entire ruleset with pfctl > > -f /etc/pf.conf didn't help, so I resorted to tcpdrop. > > > > My question is, is it possible to destroy an active connection by > > something like adding an ip to a drop quick table (did I miss a certain > > flag?) or do I, in an event that something like this happens again, > > always have to perform a two stage drop? > > > > Sincerely, > > > > Martijn If you have block drop quick rules in an anchor, I believe you do not need to reload the rules - the rule in the anchor becomes effective immediately, is that right? I use an anchor to block incoming smtp connections that way. Would you still need to use pfctl -k ... to kill the connection when using anchors? Jamie -- Primary Key: 4096R/1D31DC38 2011-12-03 Key Fingerprint: A4B9 E875 A18C 6E11 F46D B788 BEE6 1251 1D31 DC38
Re: pf blocking active connections
On 2013-02-07, Martijn van Duren wrote: > Thanks for all the quick responses, but if I understand you all > correctly there is no way to cut off an established connection by adding > an ip address to a blocked table, so I'm still left with my two stage > drop off the connection (both adding the the ip to the table and killing > the connection manually). Correct because the state table is checked *before* packets run through the firewall ruleset.