Re: pf set prio
* Михаил Швецов mishve...@rambler.ru [2013-06-13 16:54]: Does (pf set prio) work on Openbsd 5.3 x64 or i386? of course. Please can you write simple config for set prio in pf.conf? match set prio 5
routing to IPsec VPN with dummy lo1 broken
Hi, My IPsec roadwarrior setup on my laptop broke with one of the latest snapshots because some outgoing connections are routed wrongly with a source ip of 127.0.0.1. On the roadwarrior laptop I use a dummy lo1 interface to which I assign the internal VPN IP of the laptop. wlan has the 172.26.153.40/28 subnet, VPN has the 172.26.153.49/28 subnet: iwn0: flags=28843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,NOINET6 mtu 1500 lladdr 00:21:6b:a3:70:7a priority: 4 groups: wlan status: active inet 172.26.153.40 netmask 0xfff0 broadcast 172.26.153.47 enc0: flags=0 priority: 0 groups: enc status: active lo1: flags=8149UP,LOOPBACK,RUNNING,PROMISC,MULTICAST mtu 33144 priority: 0 groups: lo egress inet 172.26.153.49 netmask 0xfff0 inet6 fe80::1%lo1 prefixlen 64 scopeid 0x5 inet6 2001:4dd0:fbdf:8::49 prefixlen 48 Routing tables default route goes to the VPN. Because the IPsec flow matches on source ip, all VPN packets are routed via lo1 to assign the right source ip: Internet: DestinationGatewayFlags Refs Use Mtu Prio Iface default172.26.153.49 US 1 62 33144 9 lo1 127/8 127.0.0.1 UGRS 00 33144 8 lo0 127.0.0.1 127.0.0.1 UH 2 36 33144 4 lo0 172.26.153.32/28 link#2 UC 10 - 4 iwn0 172.26.153.33 00:1b:b1:f2:f4:6d UHLc 10 - 4 iwn0 172.26.153.40 127.0.0.1 UGS00 33144 8 lo0 172.26.153.49 172.26.153.49 UH 0 120 33144 4 lo1 217.190.94.19 172.26.153.33 UGHS 2 215 -12 iwn0 224/4 127.0.0.1 URS00 33144 8 lo0 And route get seems to do the right thing: $ route get 172.26.153.1 route to: alix destination: default mask: default interface: lo1 if address: mortimer-ipsec (= 172.26.153.49) priority: 9 () flags: UP,DONE,STATIC use mtuexpire 68 33144 0 In the following tests I run two tcpdumps in the background: tcpdump: listening on pflog0, link-type PFLOG tcpdump: listening on enc0, link-type ENC ICMP echo requests get assigned the correct source ip and are redirected to IPsec: $ ping -c1 172.26.153.1 PING 172.26.153.1 (172.26.153.1): 56 data bytes 64 bytes from 172.26.153.1: icmp_seq=0 ttl=255 time=2.635 ms --- 172.26.153.1 ping statistics --- 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 2.635/2.635/2.635/0.000 ms (authentic,confidential): SPI 0x754c6616: 172.26.153.49 172.26.153.1: icmp: echo request (encap) (authentic,confidential): SPI 0x9464175d: 172.26.153.1 172.26.153.49: icmp: echo reply (encap) But udp/tcp packets get assigned the localhost(!) address and are blocked by pf, because I disallow any traffic on lo1: $ nc -u 172.26.153.1 53 /dev/zero rule 3/(match) block out on lo1: 127.0.0.1.3621 172.26.153.1.53: 0 [0q] (2048) [demime 1.01d removed an attachment of type application/pgp-signature]
Re: routing to IPsec VPN with dummy lo1 broken
On Tue, 2 Jul 2013 10:26:40 +0200 Christopher Zimmermann chr...@openbsd.org wrote: Hi, My IPsec roadwarrior setup on my laptop broke with one of the latest snapshots because some outgoing connections are routed wrongly with a source ip of 127.0.0.1. I was wrong in assuming a recent change to the kernel is causing this. I can reproduce this behaviour with a kernel from 13-05-01 and I'm pretty sure it did work just fine back then. Still this looks like a bug to me. ICMP messages being routed with the correct source ip just fine, but udp and tcp getting a source ip of 127.0.0.1 while leaving on interface lo1 which only has the 172.26.153.49 ip assigned. Christopherd
Re: Any other ThinkPad W500 users out there?
On Sun, Jun 30, 2013 at 02:43:28AM -0400, STeve Andre' wrote: If so, I'd like to know if you are running a recent 5.3-current. Mail me off list so we don't pollute misc@. Steve, My opinion (if it costs anything) is that this info won't polute. No central directory is found on OpenBSD laptop compatibility and misc@ is only source. If you would buy one, please keep list (or me) informed. :) Thanks... --STeve Andre'
Re: routing to IPsec VPN with dummy lo1 broken
On Tue, 2 Jul 2013 10:26:40 +0200
Christopher Zimmermann chr...@openbsd.org wrote:
Hi,
My IPsec roadwarrior setup on my laptop broke with one of the latest
snapshots because some outgoing connections are routed wrongly with a
source ip of 127.0.0.1.
I found the according line in the source:
netinet/in_pcb.c:836
/*
* If we found a route, use the address
* corresponding to the outgoing interface
* unless it is the loopback (in case a route
* to our address on another net goes to loopback).
*/
if (ro-ro_rt ro-ro_rt-rt_ifp
!(ro-ro_rt-rt_ifp-if_flags IFF_LOOPBACK)) /* XXX Don't use address of
any loopback interface */
ia = ifatoia(ro-ro_rt-rt_ifa);
if (ia == 0) {
u_int16_t fport = sin-sin_port;
sin-sin_port = 0;
ia = ifatoia(ifa_ifwithdstaddr(sintosa(sin), rtableid));
if (ia == 0)
ia = ifatoia(ifa_ifwithnet(sintosa(sin), rtableid));
sin-sin_port = fport;
if (ia == 0)
ia = TAILQ_FIRST(in_ifaddr); /* XXX Now use the address of the
FIRST loopback interface anyways ?!? */
if (ia == 0) {
*errorp = EADDRNOTAVAIL;
return NULL;
}
}
Is this reasonable not to use address of loopback interfaces?
Also this codepath only affects udp/tcp, but NOT icmp.
The icmp codepath will use the address of loopback interfaces.
Christopher
RTL8111EVL +VLAN
Hi all The other day I got a Jetway JBC-373 for router/gateway purposes. The plan is to run several vlans on the internal interface. Traffic runs normal on the interface, but when I configure vlan interfaces on it I get nothing. Yes, vlan and vlandev are set correct and the switchports are also tagged with the appropriate vlan(s). I checked re(4) for reference, and it claims All re NICs support [...] VLAN tag insertion and stripping. I googled the NICs (RTL8111EVL) and they do support vlan. However, I also found an old thread in misc that says [...] use the Realtek RTL8111EVL, which doesn't appear to be OpenBSD-friendly. The machine is running 5.3-stable, and I have not tried -current. Has anyone successfully run vlan on the RTL8111EVL? Mats
Re: RTL8111EVL +VLAN
The other day I got a Jetway JBC-373 for router/gateway purposes. The plan is to run several vlans on the internal interface. Traffic runs normal on the interface, but when I configure vlan interfaces on it I get nothing. Yes, vlan and vlandev are set correct and the switchports are also tagged with the appropriate vlan(s). I checked re(4) for reference, and it claims All re NICs support [...] VLAN tag insertion and stripping. I googled the NICs (RTL8111EVL) and they do support vlan. However, I also found an old thread in misc that says [...] use the Realtek RTL8111EVL, which doesn't appear to be OpenBSD-friendly. The machine is running 5.3-stable, and I have not tried -current. Has anyone successfully run vlan on the RTL8111EVL? This kind of question comes up all the time. I don't understand why. You've got the hardware. Things change. You can test it right now, and tell us if things have changed. If they are still broken, you can add value to the old thread. If they now work, you can add value to the thread. Asking such a question is, to use perhaps a bit strong of a term, poisonous.
Re: Performance limits with OpenBSD, ToE, offloading, Intel ET2 cards
Thank you, this clarification is important to know that it is nothing I am doing that is damaging performance. Bigger hardware it is then :) Andy. On Fri 28 Jun 2013 07:55:21 BST, Peter Hessler wrote: On 2013 Jun 26 (Wed) at 17:06:09 +0100 (+0100), Andy wrote: :Someone did previously (and very helpfully) indicate that the :~400,000pps we are getting on our HP DL160 G6's is pretty good. Because Yes, and that is pretty much the best you will get until you start making the kernel MP-safe. :I like OBSD so much I have managed to convince my manager to invest in :faster hardware with the fastest single CPU speeds I can get my hands :on, but I believe this is a poor approach to the problem (for the long :term anyway). This is your only real solution to the problem *right now*. Work is being done to make OpenBSD faster for networking, but it is not ready for prime time.
Re: npppd, L2TP to Iphone, eap?
Hi, On Sun, 30 Jun 2013 15:03:58 + Brad Brad braddeic...@hotmail.com wrote: Hi, setting up npppd I get the following in the logs when connecting from Iphone 5 Jun 30 22:23:43 fire53 npppd[17905]: ppp id=0 layer=lcp No authentication protocols are agreeable. peer's auth proto=eap If you just want to connect from iPhone 5, I think you could use other authentication methods. MS-CHAP-V2, for example. I saw a message saying eap was removed and will be re-added later, and Iphone isn't particularly configurable. Can I suggest a different proto from the server side or just keep an eye out for eap? (or run 5.2) Are you talking about EAP with RADIUS? Supporting it will not so far. --yasuoka
Re: OpenBSD Doesn't Support 64-Bit Intel
More wrong? Maybe so. My point was that both are and either way it's inconsistent. On Mon, Jul 1, 2013 at 8:08 AM, Nick Holland n...@holland-consulting.netwrote: On 07/01/2013 09:27 AM, noah pugsley wrote: ... At first I thought this was a wonderful troll. Guy's got a point though. Look at the i386 page. http://www.openbsd.org/i386.**html http://www.openbsd.org/i386.html: Supported hardware: The list of supported hardware is relevant to OpenBSD-current. It will differ slightly from the support provided in the latest release version. Processors All CPU chips compatible with the Intel 80386 (i386) architecture, except for the 80386 itself, are supported: 80486 (DX/DX2/DX4) ...[snip painful, incomplete list]... Transmeta TM3200, TM5400, TM5600, TM5800 Regular floating-point coprocessors (80487SX) are required when not built into the processor. really, I think that's more wrong. Trying to itemize the list when various manufacturers are constantly cranking out new and reusing old names is misleading in the other direction. I think it could be reduced to just: Everything that is a clone of the 486 or up should work fine. maybe adding a blurb about how a standard hardware FPU is required, as someone out there might still have some 486SX systems laying around. This is easier than amd64... just about everything works, and if it doesn't, it is not likely a processor issue. amd64...well, some of the Intel chips, you just need (or it is easier) to test to find out if you got the right bit of magic. Nick.
Re: pf set prio
Does (pf set prio) work on Openbsd 5.3 x64 or i386? of course. How can i see that it works? tcpdump or others progs? Please can you write simple config for set prio in pf.conf? match set prio 5 this rule set prio 5 only the out traffic from server and in when he out (state)?
Re: OpenBSD Doesn't Support 64-Bit Intel
On 07/02/2013 11:44 AM, noah pugsley wrote: More wrong? Maybe so. My point was that both are and either way it's inconsistent. not anymore. new text, as of last night: Processors All CPUs compatible with the Intel 80486 or better, with Intel-compatible hardware floating point support should work. Nick.
Re: OpenBSD Doesn't Support 64-Bit Intel
I mean OBSD it does support 64 intel dude! Date: Mon, 1 Jul 2013 09:12:15 -0700 Subject: Re: OpenBSD Doesn't Support 64-Bit Intel From: matt...@dempsky.org To: genesi...@hotmail.com CC: jash.seffer...@gmail.com; misc@openbsd.org; s...@openbsd.org On Mon, Jul 1, 2013 at 7:48 AM, carlos albino garcia grijalba genesi...@hotmail.com wrote: IA64 its the name of the arch for the processor created originali by AMD and INTEL copied so support for AMD64 mean INTEL64 too! No, IA-64 refers to the Itanium architecture, which is very different from AMD64/Intel 64.
Re: OpenBSD Doesn't Support 64-Bit Intel
Le 2 juil. 2013 17:58, carlos albino garcia grijalba genesi...@hotmail.com a écrit : IA64 its the name of the arch for the processor created originali by AMD and INTEL copied so support for AMD64 mean INTEL64 too! dont complain if u really dont read all of the info (i understand now why my questions are not answered LOL) No ia64 is *not* the 64bits x86 arch. ia64 is the arch for itanium processors a completely different architecture. amd64 (and the Intel clone emt64) are an extension of the ia32 arch, sometimes called x86-64, it was first introduced by amd, which explain why most OS, like openbsd, brand their support as amd64. -- Marwan Burelle LSE - Système et Sécurité - EPITA
Re: OpenBSD Doesn't Support 64-Bit Intel
Le 2 juil. 2013 17:58, carlos albino garcia grijalba genesi...@hotmail.com a écrit : IA64 its the name of the arch for the processor created originali by AMD and INTEL copied so support for AMD64 mean INTEL64 too! dont complain if u really dont read all of the info (i understand now why my questions are not answered LOL) No ia64 is *not* the 64bits x86 arch. ia64 is the arch for itanium processors a completely different architecture. amd64 (and the Intel clone emt64) are an extension of the ia32 arch, sometimes called x86-64, it was first introduced by amd, which explain why most OS, like openbsd, brand their support as amd64. No, kidding. Carlos, if you can't even type ia64 into a search engine and find yourself on pages about Itanium, then you can't be taken seriously. God bless the people who employ you, they need the blessing.
Re: OpenBSD Doesn't Support 64-Bit Intel
ok i got the message and yes i need the blessing and yes im a dummy with work, maybe i dont have the correct english or tech writing for trying to defend this project that i really like i mainly try to just implement OpenBSD and trying really hard to know more about processor arch's and all of that but what i feel it is really bad sorry guys REALLY bad it is that when i just post a normal or simple or advanced question or any question nobody i men NOBODY ok maybe some folks some times answer but usually no answer and now i have a lot of answers but just to tell me that i need blessing LOL YES! for the first time i GOT an answer BY THEO!! to kick my ass but great thanks and congrats for the OBSD! nice day all of u that enlighten this silly mind From: dera...@cvs.openbsd.org To: slash...@gmail.com CC: genesi...@hotmail.com; s...@openbsd.org; jash.seffer...@gmail.com; misc@openbsd.org Subject: Re: OpenBSD Doesn't Support 64-Bit Intel Date: Tue, 2 Jul 2013 11:04:25 -0600 Le 2 juil. 2013 17:58, carlos albino garcia grijalba genesi...@hotmail.com a écrit : IA64 its the name of the arch for the processor created originali by AMD and INTEL copied so support for AMD64 mean INTEL64 too! dont complain if u really dont read all of the info (i understand now why my questions are not answered LOL) No ia64 is *not* the 64bits x86 arch. ia64 is the arch for itanium processors a completely different architecture. amd64 (and the Intel clone emt64) are an extension of the ia32 arch, sometimes called x86-64, it was first introduced by amd, which explain why most OS, like openbsd, brand their support as amd64. No, kidding. Carlos, if you can't even type ia64 into a search engine and find yourself on pages about Itanium, then you can't be taken seriously. God bless the people who employ you, they need the blessing.
PF sync doesn't not work very well
Hi all I have a strange issue (or i haven't read pfsync correctly but i don't think this is the problem :D) I'm using 2 OpenBSD as BGP+OSPF routers at the border of one site. Those BGP routers are secure with strong PF in stateful mode, and the stateful is working very well on each router. Because of my full mesh BGP configuration, the outgoing layer 7 sessions can leave my network by one router and responses can income by the other. To resolve this issue, i have created a dedidated VLAN for the pfsync traffic and attached pfsync to this VLAN. Here is a sample output of ifconfig on my first router: vlan995: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr a0:36:9f:10:4a:a6 priority: 0 vlan: 995 parent interface: trunk1 groups: vlan status: active inet6 fe80::a236:9fff:fe10:4aa6%vlan995 prefixlen 64 scopeid 0x10 inet 10.117.1.129 netmask 0xfff8 broadcast 10.117.1.135 pfsync0: flags=41UP,RUNNING mtu 1500 priority: 0 pfsync: syncdev: vlan995 maxupd: 255 defer: off groups: carp pfsync And here on my second router: vlan995: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr a0:36:9f:17:e2:1e priority: 0 vlan: 995 parent interface: trunk1 groups: vlan status: active inet6 fe80::a236:9fff:fe17:e21e%vlan995 prefixlen 64 scopeid 0x10 inet 10.117.1.130 netmask 0xfff8 broadcast 10.117.1.135 pfsync0: flags=41UP,RUNNING mtu 1500 priority: 0 pfsync: syncdev: vlan995 maxupd: 255 defer: off groups: carp pfsync As you see in next tcpdump capture, there is some discussions between the two routers: # tcpdump -nni vlan995 tcpdump: listening on vlan995, link-type EN10MB tcpdump: WARNING: compensating for unaligned libpcap packets 23:41:13.699617 10.117.1.130: PFSYNCv6 len 108 act UPD ST COMP count 1 ... (DF) [tos 0x10] 23:41:14.158500 10.117.1.129: PFSYNCv6 len 108 act UPD ST COMP count 1 ... (DF) [tos 0x10] 23:41:14.941396 SSTP STP config root=83e3.0:a:b8:7b:27:80 rootcost=3 bridge=c3e3.0:17:e:2e:f:80 port=142 ifcost=130 age=1/0 max=20/0 hello=2/0 fwdelay=15/0 pvid=995 23:41:14.949617 10.117.1.130: PFSYNCv6 len 108 act UPD ST COMP count 1 ... (DF) [tos 0x10] 23:41:15.237655 10.117.1.129: PFSYNCv6 len 640 act UPD ST COMP count 1 ... (DF) [tos 0x10] 23:41:15.949617 10.117.1.130: PFSYNCv6 len 124 act UPD ST COMP count 1 ... (DF) [tos 0x10] 23:41:16.255230 10.117.1.129: PFSYNCv6 len 36 act DEL ST COMP count 1 id: 51d16a356c33 creatorid: a10bbd21 (DF) [tos 0x10] 23:41:16.946454 SSTP STP config root=83e3.0:a:b8:7b:27:80 rootcost=3 bridge=c3e3.0:17:e:2e:f:80 port=142 ifcost=130 age=1/0 max=20/0 hello=2/0 fwdelay=15/0 pvid=995 23:41:16.949619 10.117.1.130: PFSYNCv6 len 1116 act UPD ST COMP count 13 ... (DF) [tos 0x10] The problem is simple, when i initiate a stateful connection from one server, the return (by second router) is blocked by PF (i see the return with pflog0) To be precise here is an example (and tested path): OBSD NTP - OBSD router 1 - WAN...ftp.fr.openbsd.org...WAN - OBSD router 2 || blocked PF allow in/out routing traffic from this server but incoming from WAN is blocked by default Can you confirm to me that pfsync may add a state for outgoing tcp connection in the second router when the first router add it ? Have you got any idea on this issue ? -- Best regards, Loïc BLOT, UNIX systems, security and network expert http://www.unix-experience.fr [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: OpenBSD Doesn't Support 64-Bit Intel
jash as u have seen i have really being kicked even theo kick my ass so i was totally wrong im the guy who needs to read i was totally confused since im a dummy i tought that amd64 mean all 64 bits arch either by AMD or INTEL but NO it seems that i was the guy who need to read and dig on it sorry dude i sure not and never answer nothing until i really REALLY know all of it! have a nice day. From: genesi...@hotmail.com To: jash.seffer...@gmail.com; misc@openbsd.org; s...@openbsd.org Subject: Re: OpenBSD Doesn't Support 64-Bit Intel Date: Mon, 1 Jul 2013 14:48:10 + IA64 its the name of the arch for the processor created originali by AMD and INTEL copied so support for AMD64 mean INTEL64 too! dont complain if u really dont read all of the info (i understand now why my questions are not answered LOL) Date: Mon, 1 Jul 2013 00:06:05 -0400 Subject: OpenBSD Doesn't Support 64-Bit Intel From: jash.seffer...@gmail.com To: misc@openbsd.org; s...@openbsd.org Hi guys. Im a civil engineer by day and use OpenBSD at night, but Im trying to do high-end CAD on my home PC and OpenBSD doesnt support 64-bit Intel chips. Don't believe me? It says very clearly at the OpenBSD/amd64 page: All versions of the AMD Athlon 64 processors and their clones are supported. But does not mention or list any Intel chips. Not one. Wtf? I can do CAD on my i7-980X under Windows 7 SP 1, but Id rather use something secure and responsibly coded like OpenBSD. Except that I can't. Why for the life of this platform are we not on the only future direction for the platform? And I mean that literally. Neither AMD nor Intel sells 32-bit chips anymore. If OpenBSD remains stuck at 32 bits, people will stop using and developing for it. Who makes the decision to keep OpenBSD off of 64-bit Intel? And why the hell are they doing so? -jash
Re: OpenBSD Doesn't Support 64-Bit Intel
On Tue, Jul 2, 2013 at 1:11 PM, carlos albino garcia grijalba genesi...@hotmail.com wrote: jash as u have seen i have really being kicked even theo kick my ass so i was totally wrong im the guy who needs to read i was totally confused since im a dummy i tought that amd64 mean all 64 bits arch either by AMD or INTEL but NO it seems that i was the guy who need to read and dig on it sorry dude i sure not and never answer nothing until i really REALLY know all of it! have a nice day. Relax. You gave an incorrect answer, and you were corrected. Learn from it and move on.
Re: softraid: adding volumes, CPU requirements, RAID5
Le 20/05/2013 13:46, Nick Holland a écrit : On 05/20/13 00:52, Hugo Osvaldo Barrera wrote: Hi, I'm building myself an openbsd-based fileserver, which will initially have three disks with softraid in RAID5 mode. I've three questions regarding softraid: 1) I intend on using a single-core 1.8Ghz Atom processor I have lying around. Would that limit my performance too much? I'll be using this fileserver mostly for media (movies/series/music) and some ocassional backups. Can anyone share what CPU they've used and their experience? (I'm clarifying my intended usage for the fileserver since I think it's quite relevant to say if the CPU is or isn't enough). Wrong question, I think. More than processor is memory (caching) and disk interface (ahci rocks), network interface, etc. 2) How do I add additional volumes to an already created softraid volume? I intend on adding additional disks as necessary. Is it possible? Not in the way you are likely thinking. Besides, your Atom board probably has a rather finite amount of expandability. 3) The man pages report RAID5 as experimental. I'm curious, why is this so? Is it just not-very-thoroughly tested, or is there some missing feature? I read on a 2010 presentation that rebuild was not implemented yet, is this still so? That's really a question you will need to find out though experimentation before you implement (i.e., you MUST practice this recovery stuff before going into production), but yes, RAID5 rebuild is still not there, so I would NOT recommend going this route. However, a nice little RAID1 system to start, hopefully leaving you two SATA ports for the next generation/upgrade disks. Nick. RAID5 rebuild is still not there Can you please make it more clear what actual state of soft raid can and what it cannot do under RAID 5 ... I'm not so sure to get it, thank you. J.-F.
Still unable to compile binaries :(
Hi, it is 2nd day and building binaries fails at the same point. No idea what is wrong, I was started to think that something wrong has been committed into sources tree, but looks like I'm alone here with my issue. Someone in irc suggested that it might be the issue with my custom kernel, so I loaded default bsd.mp kernel and tried to do the same, still no joy. I'm running out of ideas guys, please suggest something to make the build successful. Thanks, cat /usr/src/CVS/Tag TOPENBSD_5_3 I have extracted sources from src and sys archives, updated them using* cvs -d anon...@ftp5.eu.openbsd.org:/cvs -q up -rOPENBSD_5_3 -Pd* then I followed instructions here: http://www.openbsd.org/stable.html#building This last build was from GENERIC kernel which I got compiled on my own, I haven't edited almost nothing, just pointed that I got SMP machine, nothing else. The build command was issued with *make -j8 build* sh /usr/src/sys/arch/amd64/stand/fdboot/../../../../kern/genassym.sh cc -DFDBOOT -Os -Wall -Werror -fno-stack-protector -DFDBOOT -m32 -D_STANDALONE -nostdinc -fno-builtin -fpack-struct -D__INTERNAL_LIBSA_CREAD -fno-pie -I/usr/src/sys/arch/amd64/stand/fdboot/../../../.. -I/usr/src/sys/arch/amd64/stand/fdboot/../libsa -I. -I/usr/src/sys/arch/amd64/stand/fdboot -DSOFTRAID -DBOOTMAGIC=0xc001d00d -DLINKADDR=0x40120 -DSLOW -DSMALL -DNOBYFOUR -DNO_GZIP -DDYNAMIC_CRC_TABLE -DHEAP_LIMIT=0x9 -I/usr/src/sys/arch/amd64/stand/fdboot/../../../../stand/boot /usr/src/sys/arch/amd64/stand/fdboot/../etc/genassym.cf assym.h.tmp mv -f assym.h.tmp assym.h mkdep -a -DFDBOOT -DFDBOOT -D_STANDALONE -D__INTERNAL_LIBSA_CREAD -I/usr/src/sys/arch/amd64/stand/fdboot/../../../.. -I/usr/src/sys/arch/amd64/stand/fdboot/../libsa -I. -I/usr/src/sys/arch/amd64/stand/fdboot -DSOFTRAID -DBOOTMAGIC=0xc001d00d -DLINKADDR=0x40120 -DSLOW -DSMALL -DNOBYFOUR -DNO_GZIP -DDYNAMIC_CRC_TABLE -DHEAP_LIMIT=0x9 -I/usr/src/sys/arch/amd64/stand/fdboot/../../../../stand/boot /usr/src/sys/arch/amd64/stand/fdboot/../boot/srt0.S /usr/src/sys/arch/amd64/stand/fdboot/../libsa/alloca.S /usr/src/sys/arch/amd64/stand/fdboot/../libsa/gidt.S mkdep -a -DFDBOOT -DFDBOOT -D_STANDALONE -D__INTERNAL_LIBSA_CREAD -I/usr/src/sys/arch/amd64/stand/fdboot/../../../.. -I/usr/src/sys/arch/amd64/stand/fdboot/../libsa -I. -I/usr/src/sys/arch/amd64/stand/fdboot -DSOFTRAID -DBOOTMAGIC=0xc001d00d -DLINKADDR=0x40120 -DSLOW -DSMALL -DNOBYFOUR -DNO_GZIP -DDYNAMIC_CRC_TABLE -DHEAP_LIMIT=0x9 -I/usr/src/sys/arch/amd64/stand/fdboot/../../../../stand/boot /usr/src/sys/arch/amd64/stand/fdboot/../boot/conf.c /usr/src/sys/arch/amd64/stand/fdboot/../libsa/cmd_i386.c /usr/src/sys/arch/amd64/stand/fdboot/../libsa/dev_i386.c /usr/src/sys/arch/amd64/stand/fdboot/../libsa/exec_i386.c /usr/src/sys/arch/amd64/stand/fdboot/../libsa/gateA20.c /usr/src/sys/arch/amd64/stand/fdboot/../libsa/machdep.c /usr/src/sys/arch/amd64/stand/fdboot/../libsa/bioscons.c /usr/src/sys/arch/amd64/stand/fdboot/../libsa/biosdev.c /usr/src/sys/arch/amd64/stand/fdboot/../libsa/diskprobe.c /usr/src/sys/arch/amd64/stand/fdboot/../libsa/memprobe.c /usr/src/sys/arch/amd64/stand/fdboot/../libsa/time.c /usr/src/sys/arch/amd64/stand/fdboot/../libsa/softraid.c /usr/src/sys/arch/amd64/stand/fdboot/../../../../stand/boot/boot.c /usr/src/sys/arch/amd64/stand/fdboot/../../../../stand/boot/bootarg.c /usr/src/sys/arch/amd64/stand/fdboot/../../../../stand/boot/cmd.c /usr/src/sys/arch/amd64/stand/fdboot/../../../../stand/boot/vars.c /usr/src/sys/arch/amd64/stand/fdboot/../../../../lib/libsa/alloc.c /usr/src/sys/arch/amd64/stand/fdboot/../../../../lib/libsa/ctime.c /usr/src/sys/arch/amd64/stand/fdboot/../../../../lib/libsa/exit.c /usr/src/sys/arch/amd64/stand/fdboot/../../../../lib/libsa/getfile.c /usr/src/sys/arch/amd64/stand/fdboot/../../../../lib/libsa/gets.c /usr/src/sys/arch/amd64/stand/fdboot/../../../../lib/libsa/globals.c /usr/src/sys/arch/amd64/stand/fdboot/../../../../lib/libsa/memcmp.c /usr/src/sys/arch/amd64/stand/fdboot/../../../../lib/libsa/memcpy.c /usr/src/sys/arch/amd64/stand/fdboot/../../../../lib/libsa/memset.c /usr/src/sys/arch/amd64/stand/fdboot/../../../../lib/libsa/printf.c /usr/src/sys/arch/amd64/stand/fdboot/../../../../lib/libsa/snprintf.c /usr/src/sys/arch/amd64/stand/fdboot/../../../../lib/libsa/strcmp.c /usr/src/sys/arch/amd64/stand/fdboot/../../../../lib/libsa/strerror.c /usr/src/sys/arch/amd64/stand/fdboot/../../../../lib/libkern/strlcat.c /usr/src/sys/arch/amd64/stand/fdboot/../../../../lib/libkern/strlcpy.c /usr/src/sys/arch/amd64/stand/fdboot/../../../../lib/libsa/strlen.c /usr/src/sys/arch/amd64/stand/fdboot/../../../../lib/libsa/strncmp.c /usr/src/sys/arch/amd64/stand/fdboot/../../../../lib/libsa/strncpy.c /usr/src/sys/arch/amd64/stand/fdboot/../../../../lib/libsa/strtol.c /usr/src/sys/arch/amd64/stand/fdboot/../../../../lib/libsa/strtoll.c /usr/src/sys/arch/amd64/stand/fdboot/../../../../lib/libsa/close.c
Re: Still unable to compile binaries :(
On Tue, Jul 2, 2013 at 2:19 PM, jV j...@dodec.lt wrote: ... then I followed instructions here: http://www.openbsd.org/stable.html#building ... The build command was issued with *make -j8 build* Not quite: that webpage doesn't suggest using -j8. Indeed, there have been many fixes to the Makefiles to have them work with parallel make, but it looks to me like the Makefile in that kerberosV subdir never got the required dependencies to be reliable with parallel make. A close look shows that it appears to have tried to compile slc-lex.c before yacc finished writing y.tab.h: === kerberosV/usr.sbin/kadmin yacc -d /usr/src/kerberosV/usr.sbin/kadmin/../../src/lib/sl/slc-gram.y lex /usr/src/kerberosV/usr.sbin/kadmin/../../src/lib/sl/slc-lex.l cc -O2 -pipe -DHAVE_CONFIG_H -DBINDIR=\/usr/bin\ -DSBINDIR=\/usr/sbin\ -DLIBEXECDIR=\/usr/libexec\ -DSYSCONFDIR=\/etc/kerberosV\ -I/usr/include/kerberosV -I/usr/src/ker usr.sbin/kadmin/../../src/lib/roken -I/usr/src/kerberosV/usr.sbin/kadmin/../../src/include -I/usr/src/kerberosV/usr.sbin/kadmin/../../src/lib/sl -I/usr/src/kerberosV/usr.sbin/ka berosV/usr.sbin/kadmin/../../src/lib/krb5 -I/usr/src/kerberosV/usr.sbin/kadmin/../../src/lib/kadm5 -I. -c -o slc-lex.o lex.yy.c /usr/src/kerberosV/usr.sbin/kadmin/../../src/lib/sl/slc-lex.l: In function 'yylex': /usr/src/kerberosV/usr.sbin/kadmin/../../src/lib/sl/slc-lex.l:57: error: 'yylval' undeclared (first use in this function) /usr/src/kerberosV/usr.sbin/kadmin/../../src/lib/sl/slc-lex.l:57: error: (Each undeclared identifier is reported only once /usr/src/kerberosV/usr.sbin/kadmin/../../src/lib/sl/slc-lex.l:57: error: for each function it appears in.) /usr/src/kerberosV/usr.sbin/kadmin/../../src/lib/sl/slc-lex.l:58: error: 'LITERAL' undeclared (first use in this function) /usr/src/kerberosV/usr.sbin/kadmin/../../src/lib/sl/slc-lex.l:60: error: 'STRING' undeclared (first use in this function) These are defined in y.tab.h, which is created by yacc -d This might have been fixed in -current by the import of the newer version of heimdal, but I don't have time to check right now. I suggest you stop using parallel make unless you know the build works with it. Philip Guenther
Re: softraid: adding volumes, CPU requirements, RAID5
On 07/02/13 17:07, Jean-Francois Simon wrote: Le 20/05/2013 13:46, Nick Holland a écrit : On 05/20/13 00:52, Hugo Osvaldo Barrera wrote: ... 3) The man pages report RAID5 as experimental. I'm curious, why is this so? Is it just not-very-thoroughly tested, or is there some missing feature? I read on a 2010 presentation that rebuild was not implemented yet, is this still so? That's really a question you will need to find out though experimentation before you implement (i.e., you MUST practice this recovery stuff before going into production), but yes, RAID5 rebuild is still not there, so I would NOT recommend going this route. However, a nice little RAID1 system to start, hopefully leaving you two SATA ports for the next generation/upgrade disks. Nick. RAID5 rebuild is still not there Can you please make it more clear what actual state of soft raid can and what it cannot do under RAID 5 ... I'm not so sure to get it, thank you. J.-F. RAID5 rebuild is still not there - there's no RAID5 rebuild. I'm not sure how to make it more clear... Ok, let's try this... Today, you take four 1TB disks, and make a 3TB RAID5 volume. You can do that. Works great. Now, a lot of people might call this Job Done. Not me. The point of RAID isn't to build complicated systems, but to have the system keep your butt out of the fire when things go wrong. Next month, one of those drive fail. That's ok, RAID5 is designed to keep your data usable with one drive down. THAT is the point of RAID. You pat yourself on the back and say, I'm glad I am using RAID5. You replace the failed drive and... ... um... now what? You have a three drive degraded RAID5 system with no remaining redundancy...and a new drive that is currently unused. You have no ability to rebuild the function of the failed drive into the new drive...because the RAID5 rebuild is not there. Oh, poo. Your options? Well, * you can build a NEW array on other disks (hope you have enough ports to plug them into), copy the data from the old one to the new one * you can hope your backup system is perfect, and rebuild the entire array and reload from backup * you can hope a second drive doesn't fail in your array... for the life of the system. Not much else I can think of. If you want to play with softraid and raid5, hey, have a blast. You want to put critical data on it? I'd not suggest that. A job ago, I had some relatively large chunks of data to hash through to find some needles of data in and no disks handy that could do it in one chunk...but I had some big disk array boxes, and a lot of smallish SCSI disks I could stick in them (and the office space was really cold, so a bit of heat under my desk was not unappreciated). I think I did them as softraid RAID0, but I could have done it as RAID5 with this system -- the data is there just for analysis, not storage. RAID5 might give me a few minutes to pull data off that I realized was important only after the drive failed, but otherwise the loss of data on this array would not have been catastrophic at all. Now, anyone who drops important data on any kind of RAID system without figuring out how to deal with disk (and controller) failures deserves what they get. So if I was a nice guy, I'd have said Go try it out on some spare hardware and unimportant data and answer your own question, but being the evil bastard that I am, I'm denying you a very important learning experience. Nick.
Another improvement patch to CWM
Hi,
here is another patch to CWM thats:
a) implement cyclegroup and rcyclegroup in mousefunc.c
b) set as default the mouse wheel to cycle group ( up = reverse, down =
normal)
I can`t set mousebind on root screen using the cwmrc, so I setted as
default
Att,
Mosconi
Index: calmwm.h
===
RCS file: /cvs/xenocara/app/cwm/calmwm.h,v
retrieving revision 1.213
diff -p -r1.213 calmwm.h
*** calmwm.h17 Jun 2013 17:11:10 - 1.213
--- calmwm.h2 Jul 2013 23:06:55 -
*** void mousefunc_window_lower(struct cl
*** 433,438
--- 433,440
void mousefunc_window_move(struct client_ctx *, void *);
void mousefunc_window_raise(struct client_ctx *, void
*);
void mousefunc_window_resize(struct client_ctx *, void
*);
+ void mousefunc_client_cyclegroup(struct client_ctx *,
void *);
+ void mousefunc_client_rcyclegroup(struct client_ctx *,
void *);
struct menu *menu_filter(struct screen_ctx *, struct menu_q *,
char *, char *, int,
Index: conf.c
===
RCS file: /cvs/xenocara/app/cwm/conf.c,v
retrieving revision 1.137
diff -p -r1.137 conf.c
*** conf.c 23 Jun 2013 17:57:50 - 1.137
--- conf.c 2 Jul 2013 23:06:56 -
*** m_binds[] = {
*** 207,212
--- 207,214
{ 1, menu_unhide },
{ 2, menu_group },
{ 3, menu_cmd },
+ { 4, rcyclegroup },
+ { 5, cyclegroup },
{ M-1,window_move },
{ CM-1, window_grouptoggle },
{ M-2,window_resize },
*** static struct {
*** 541,546
--- 543,550
{ menu_group, mousefunc_menu_group, MOUSEBIND_CTX_ROOT },
{ menu_unhide, mousefunc_menu_unhide, MOUSEBIND_CTX_ROOT },
{ menu_cmd, mousefunc_menu_cmd, MOUSEBIND_CTX_ROOT },
+ { cyclegroup, mousefunc_client_cyclegroup, MOUSEBIND_CTX_ROOT },
+ { rcyclegroup, mousefunc_client_rcyclegroup, MOUSEBIND_CTX_ROOT },
};
static unsigned int mouse_btns[] = {
Index: mousefunc.c
===
RCS file: /cvs/xenocara/app/cwm/mousefunc.c,v
retrieving revision 1.53
diff -p -r1.53 mousefunc.c
*** mousefunc.c 17 Jun 2013 17:11:10 - 1.53
--- mousefunc.c 2 Jul 2013 23:06:56 -
*** mousefunc_menu_group(struct client_ctx *
*** 208,213
--- 208,225
}
void
+ mousefunc_client_cyclegroup(struct client_ctx *cc, void *arg)
+ {
+ group_cycle(cc-sc, CWM_CYCLE );
+ }
+
+ void
+ mousefunc_client_rcyclegroup(struct client_ctx *cc, void *arg)
+ {
+ group_cycle(cc-sc, CWM_RCYCLE );
+ }
+
+ void
mousefunc_menu_unhide(struct client_ctx *cc, void *arg)
{
struct screen_ctx *sc = cc-sc;
Re: PF sync doesn't not work very well
pfsync(4) explains this: … The pfsync interface will attempt to collapse multiple state updates into a single packet where possible. The maximum number of times a single state can be updated before a pfsync packet will be sent out is controlled by the maxupd parameter … and … Where more than one firewall might actively handle packets, e.g. with certain ospfd(8), bgpd(8) or carp(4) configurations, it is beneficial to defer transmission of the initial packet of a connection. The pfsync state insert message is sent immediately; the packet is queued until either this message is acknowledged by another system, or a timeout has expired. This behaviour is enabled with the defer parameter to ifconfig(8). … Eg. defer: on, yours is off. //mxb On 2 jul 2013, at 21:54, Loïc BLOT loic.b...@unix-experience.fr wrote: Hi all I have a strange issue (or i haven't read pfsync correctly but i don't think this is the problem :D) I'm using 2 OpenBSD as BGP+OSPF routers at the border of one site. Those BGP routers are secure with strong PF in stateful mode, and the stateful is working very well on each router. Because of my full mesh BGP configuration, the outgoing layer 7 sessions can leave my network by one router and responses can income by the other. To resolve this issue, i have created a dedidated VLAN for the pfsync traffic and attached pfsync to this VLAN. Here is a sample output of ifconfig on my first router: vlan995: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr a0:36:9f:10:4a:a6 priority: 0 vlan: 995 parent interface: trunk1 groups: vlan status: active inet6 fe80::a236:9fff:fe10:4aa6%vlan995 prefixlen 64 scopeid 0x10 inet 10.117.1.129 netmask 0xfff8 broadcast 10.117.1.135 pfsync0: flags=41UP,RUNNING mtu 1500 priority: 0 pfsync: syncdev: vlan995 maxupd: 255 defer: off groups: carp pfsync And here on my second router: vlan995: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr a0:36:9f:17:e2:1e priority: 0 vlan: 995 parent interface: trunk1 groups: vlan status: active inet6 fe80::a236:9fff:fe17:e21e%vlan995 prefixlen 64 scopeid 0x10 inet 10.117.1.130 netmask 0xfff8 broadcast 10.117.1.135 pfsync0: flags=41UP,RUNNING mtu 1500 priority: 0 pfsync: syncdev: vlan995 maxupd: 255 defer: off groups: carp pfsync As you see in next tcpdump capture, there is some discussions between the two routers: # tcpdump -nni vlan995 tcpdump: listening on vlan995, link-type EN10MB tcpdump: WARNING: compensating for unaligned libpcap packets 23:41:13.699617 10.117.1.130: PFSYNCv6 len 108 act UPD ST COMP count 1 ... (DF) [tos 0x10] 23:41:14.158500 10.117.1.129: PFSYNCv6 len 108 act UPD ST COMP count 1 ... (DF) [tos 0x10] 23:41:14.941396 SSTP STP config root=83e3.0:a:b8:7b:27:80 rootcost=3 bridge=c3e3.0:17:e:2e:f:80 port=142 ifcost=130 age=1/0 max=20/0 hello=2/0 fwdelay=15/0 pvid=995 23:41:14.949617 10.117.1.130: PFSYNCv6 len 108 act UPD ST COMP count 1 ... (DF) [tos 0x10] 23:41:15.237655 10.117.1.129: PFSYNCv6 len 640 act UPD ST COMP count 1 ... (DF) [tos 0x10] 23:41:15.949617 10.117.1.130: PFSYNCv6 len 124 act UPD ST COMP count 1 ... (DF) [tos 0x10] 23:41:16.255230 10.117.1.129: PFSYNCv6 len 36 act DEL ST COMP count 1 id: 51d16a356c33 creatorid: a10bbd21 (DF) [tos 0x10] 23:41:16.946454 SSTP STP config root=83e3.0:a:b8:7b:27:80 rootcost=3 bridge=c3e3.0:17:e:2e:f:80 port=142 ifcost=130 age=1/0 max=20/0 hello=2/0 fwdelay=15/0 pvid=995 23:41:16.949619 10.117.1.130: PFSYNCv6 len 1116 act UPD ST COMP count 13 ... (DF) [tos 0x10] The problem is simple, when i initiate a stateful connection from one server, the return (by second router) is blocked by PF (i see the return with pflog0) To be precise here is an example (and tested path): OBSD NTP - OBSD router 1 - WAN...ftp.fr.openbsd.org...WAN - OBSD router 2 || blocked PF allow in/out routing traffic from this server but incoming from WAN is blocked by default Can you confirm to me that pfsync may add a state for outgoing tcp connection in the second router when the first router add it ? Have you got any idea on this issue ? -- Best regards, Loïc BLOT, UNIX systems, security and network expert http://www.unix-experience.fr [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Compiling and debugging custom ralink driver for 5.3 GENERIC (release)
I purchased an Edimax EW-7128Gn that contains a ralink RT3060 chip and it's unrecognized. dmesg: vendor Ralink, unknown product 0x3060 (class network subclass miscellaneous, rev 0x00) at pci4 dev 0 function 0 not configured The documentation says a/g/n but this is a b/g/n. Ralink's drivers use the same firmware across what is supported and the 3060. The linux drivers are grouped in the 2860/3062 (which is supported). Plus the official drivers are open source! So my plan was to force the 3062 (later the 2860) onto the 3060 and see if it worked. Otherwise compare the linux drivers between 2860/3060/3062/3090 and compare the OpenBSD ralink between 2561/2561S/2661/2860 (per sys/dev/pci/if_ral_pci.c) and make the required changes (EEPROM? microcode?) Here's my problem, upon updating /sys/dev/pci/pcidevs (also changed pcidevs.h and pcidevs_data.h, unsure how they are auto-generated) I then updated sys/dev/pci/if_ral_pci.c (and associated cardbus) for pci_matchid ral_pci_devices so that the 3060 is matched by the ralink driver (and by default switch case the rt2860 is used) I still get unknown product 0x3060...not configured in dmesg. pcidevs entry: (and correct changes in .h and _data.h) product RALINK RT30600x3060RT3060 and for completeness, I'm successfully building and installing a GENERIC kernal *and* userland. First, how do I correctly compile and associate a not configured product to a specific driver, and second, how do I debug such an association?
Re: softdep issue in 5.3-current ?
I made a new build of current and the problem with tar performance seems to be resolved now. before: # time tar -xzpf /usr/releasedir/comp53.tgz 3m17.81s real 0m2.14s user 0m2.22s system # time tar -xzpf /usr/releasedir/base53.tgz 3m39.33s real 0m2.23s user 0m2.23s system after: # dmesg|head -n2 OpenBSD 5.3-current (GENERIC.MP) #0: Tue Jul 2 22:44:07 CEST 2013 root@test:/usr/src/sys/arch/amd64/compile/GENERIC.MP # time tar -xzpf /usr/releasedir/comp53.tgz 0m8.92s real 0m1.80s user 0m1.07s system # time tar -xzpf /usr/releasedir/base53.tgz 0m11.29s real 0m2.21s user 0m1.17s system Best Regards Andreas
Re: Still unable to compile binaries :(
On Tue, Jul 02, 2013 at 02:50:08PM -0700, Philip Guenther wrote: These are defined in y.tab.h, which is created by yacc -d This might have been fixed in -current by the import of the newer version of heimdal, but I don't have time to check right now. I suggest you stop using parallel make unless you know the build works with it. It may even have been fixed after 5.3 prior the import of new heimdal... bad luck. Carefully check the commits to the Makefile in that directory, you should be able to pick the wee little part you need.
Re: softraid: adding volumes, CPU requirements, RAID5
Le 03/07/2013 00:53, Nick Holland a écrit : On 07/02/13 17:07, Jean-Francois Simon wrote: Le 20/05/2013 13:46, Nick Holland a écrit : On 05/20/13 00:52, Hugo Osvaldo Barrera wrote: ... 3) The man pages report RAID5 as experimental. I'm curious, why is this so? Is it just not-very-thoroughly tested, or is there some missing feature? I read on a 2010 presentation that rebuild was not implemented yet, is this still so? That's really a question you will need to find out though experimentation before you implement (i.e., you MUST practice this recovery stuff before going into production), but yes, RAID5 rebuild is still not there, so I would NOT recommend going this route. However, a nice little RAID1 system to start, hopefully leaving you two SATA ports for the next generation/upgrade disks. Nick. RAID5 rebuild is still not there Can you please make it more clear what actual state of soft raid can and what it cannot do under RAID 5 ... I'm not so sure to get it, thank you. J.-F. RAID5 rebuild is still not there - there's no RAID5 rebuild. I'm not sure how to make it more clear... Ok, let's try this... Today, you take four 1TB disks, and make a 3TB RAID5 volume. You can do that. Works great. Now, a lot of people might call this Job Done. Not me. The point of RAID isn't to build complicated systems, but to have the system keep your butt out of the fire when things go wrong. Next month, one of those drive fail. That's ok, RAID5 is designed to keep your data usable with one drive down. THAT is the point of RAID. You pat yourself on the back and say, I'm glad I am using RAID5. You replace the failed drive and... ... um... now what? You have a three drive degraded RAID5 system with no remaining redundancy...and a new drive that is currently unused. You have no ability to rebuild the function of the failed drive into the new drive...because the RAID5 rebuild is not there. Oh, poo. Your options? Well, * you can build a NEW array on other disks (hope you have enough ports to plug them into), copy the data from the old one to the new one * you can hope your backup system is perfect, and rebuild the entire array and reload from backup * you can hope a second drive doesn't fail in your array... for the life of the system. Not much else I can think of. If you want to play with softraid and raid5, hey, have a blast. You want to put critical data on it? I'd not suggest that. A job ago, I had some relatively large chunks of data to hash through to find some needles of data in and no disks handy that could do it in one chunk...but I had some big disk array boxes, and a lot of smallish SCSI disks I could stick in them (and the office space was really cold, so a bit of heat under my desk was not unappreciated). I think I did them as softraid RAID0, but I could have done it as RAID5 with this system -- the data is there just for analysis, not storage. RAID5 might give me a few minutes to pull data off that I realized was important only after the drive failed, but otherwise the loss of data on this array would not have been catastrophic at all. Now, anyone who drops important data on any kind of RAID system without figuring out how to deal with disk (and controller) failures deserves what they get. So if I was a nice guy, I'd have said Go try it out on some spare hardware and unimportant data and answer your own question, but being the evil bastard that I am, I'm denying you a very important learning experience. Nick. Great, I did not find this information in the manual in fact ... except considered experimental if that covers this fact. Thanks again, not a bad guy explanation to me, for sure. Regards JF
