Re: pf blocking active connections
On 2013-02-07, Martijn van Duren martijn...@gmail.com 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.
Re: pf blocking active connections
-- patrick keshishian pkesh...@gmail.com [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 martijn...@gmail.com 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 Fri, 2013-02-08 at 08:23 +, Stuart Henderson wrote: On 2013-02-07, Martijn van Duren martijn...@gmail.com 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: 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 nop,nop,timestamp 2916967890 1128121967 (DF)
15:34:48.117150 server.8000 client.49387: . 696058:697506(1448) ack
524 win 2172 nop,nop,timestamp 2916967890 1128121967 (DF)
15:34:48.117197 server.8000 client.49387: . 697506:698954(1448) ack
524 win 2172 nop,nop,timestamp 2916967890 1128121967 (DF)
15:34:48.117251 client.49387 server.8000: . ack 693026 win 83
nop,nop,timestamp 1128122687 2916967890 (DF)
15:34:48.117275 client.49387 server.8000: . ack 694474 win 82
nop,nop,timestamp 1128122687 2916967890 (DF)
15:34:48.117291 client.49387 server.8000: . ack 695922 win 80
nop,nop,timestamp 1128122687 2916967890 (DF)
15:34:48.117307 client.49387 server.8000: . ack 696058 win 80
nop,nop,timestamp 1128122687 2916967890 (DF)
15:34:48.117663 client.49387 server.8000: . ack 697506 win 83
nop,nop,timestamp 1128122687 2916967890 (DF)
15:34:48.117691 client.49387 server.8000: . ack 698954 win 82
nop,nop,timestamp 1128122687 2916967890 (DF)
15:34:48.117744 server.8000 client.49387: P 698954:700215(1261) ack
524 win 2172 nop,nop,timestamp 2916967890 1128122687 (DF)
15:34:48.118333 client.49387 server.8000: . ack 700215 win 83
nop,nop,timestamp 1128122688 2916967890 (DF)
*15:34:48.168128 server.8000 client.49387: F 700215:700215(0) ack
524 win 2172 nop,nop,timestamp 2916967890 1128122688 (DF)*
15:34:48.168467 client.49387 server.8000: F 524:524(0) ack 700216
win 83 nop,nop,timestamp 1128122738 2916967890 (DF)
15:34:48.168529 server.8000 client.49387: . ack 525 win 2172
nop,nop,timestamp 2916967890 1128122738 (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: 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 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: pf blocking active connections
On 2013-02-08, Martijn van Duren martijn...@gmail.com wrote: On Fri, 2013-02-08 at 08:23 +, Stuart Henderson wrote: On 2013-02-07, Martijn van Duren martijn...@gmail.com 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: 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-way D-cache, 512KB 64b/line 16-way L2 cache, 6MB 64b/line 48-way L3 cache cpu0: ITLB 32 4KB entries fully associative, 16 4MB entries fully
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 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 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: 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 facebookman...@gmail.com 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 ma1l1i...@yahoo.co.uk 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 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
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 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'.
Re: 5.2, i386, small kernel crash
On Fri, Feb 8, 2013 at 11:56 AM, Christian Groessler ch...@groessler.orgwrote: 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 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: 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 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 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: 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 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:
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: 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 2013-02-08, Paul de Weerd we...@weirdnet.nl 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 --- snip 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: 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: 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: 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
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: softraid RAID1 + CRYPTO error writing metadata
On Sat, 9 Feb 2013, Stuart Henderson wrote: On 2013-02-08, Paul de Weerd we...@weirdnet.nl 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 --- snip 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
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 skqu...@rushpost.com
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
