Re: need help setting an encrypted root FS on dual boot system
On Wed, Nov 05, 2014 at 08:38:25PM -0800, Chris Cappuccio wrote: Matthieu Herrb [matth...@herrb.eu] wrote: Hi, I've a laptop with Ubuntu 14.04/OpenBSD-current dual boot. I'm trying to convert the OpenBSD FS to softraid(4) encryption with passphrase. I'm booting from an USB drive to access the disk to shuffle data on it. After backing up my data, changing the OpenBSD disklabel in sd0 to have one RAID partition and one swap partition, running bioctl to setup an encrypted sd2 softraid and restoring my data, I'm stuck with bootblocks. What is the correct installboot incantation to setup bootblocks so that Ubuuntu's grub which chainloads the OpenBSD part of the disk loads a softraid-aware biosboot ? Doesn't installboot load the first-stage at the beginning of the OpenBSD partition according to disklabel? Grub is just replacing the MBR. I don't understand how crypto would make grub-first-stage step any different. (for that matter, I also don't understand how the first-stage can even load the second-stage /boot from an encrypted partition!!) biosboot(8) reads a plaintext boot(8) located in the softraid meta data area. boot(8) reads and decrypts /bsd from the root paritition of the crypto volume. If installboot codes the right boot(8) offset into biosboot, i.e. the offset on the disk within softraid meta data, it should just work whether or not biosboot itself is loaded from an MBR or chainloaded. However, I faintly remember trying to set up a dual-boot Linux/OpenBSD system with softraid crypto some time last year and couldn't figure out how to make it work at the time. But I don't recall what issues I ran into. If you look at the output of 'installboot -n -v sd2' you should be able to tell in which sector installboot is going to put biosboot and whether that position collides with grub. Perhaps that will help you get going.
Re: rtentry leak
On 05/11/14(Wed) 19:53, Chris Cappuccio wrote:
Martin Pieuchot [mpieuc...@nolizard.org] wrote:
@@ -653,12 +653,12 @@ ifa_ifwithroute(int flags, struct sockad
struct rtentry *rt = rtalloc(gateway, 0, rtableid);
if (rt == NULL)
return (NULL);
- rt-rt_refcnt--;
/* The gateway must be local if the same address family. */
if ((rt-rt_flags RTF_GATEWAY)
rt_key(rt)-sa_family == dst-sa_family)
return (NULL);
And
if ((rt-rt_flags RTF_GATEWAY)
rt_key(rt)-sa_family == dst-sa_family) {
+ rtfree(rt);
return (NULL);
}
ifa = rt-rt_ifa;
+ rtfree(rt);
if (ifa == NULL || ifa-ifa_ifp == NULL)
return (NULL);
Indeed! And the ifa might also be freed so this chunk is completely
wrong. Here's a version of the diff without it, ok?
Index: net/route.c
===
RCS file: /home/ncvs/src/sys/net/route.c,v
retrieving revision 1.189
diff -u -p -r1.189 route.c
--- net/route.c 4 Nov 2014 15:24:40 - 1.189
+++ net/route.c 6 Nov 2014 10:24:02 -
@@ -215,7 +215,7 @@ route_init(void)
{
struct domain*dom;
- pool_init(rtentry_pool, sizeof(struct rtentry), 0, 0, 0, rtent,
+ pool_init(rtentry_pool, sizeof(struct rtentry), 0, 0, 0, rtentry,
NULL);
rn_init(); /* initialize all zeroes, all ones, mask table */
@@ -1220,7 +1220,7 @@ rt_ifa_addloop(struct ifaddr *ifa)
if (rt == NULL || !ISSET(rt-rt_flags, flags));
rt_ifa_add(ifa, RTF_UP | flags, ifa-ifa_addr);
if (rt)
- rt-rt_refcnt--;
+ rtfree(rt);
}
/*
@@ -1267,7 +1267,7 @@ rt_ifa_delloop(struct ifaddr *ifa)
if (rt != NULL ISSET(rt-rt_flags, flags))
rt_ifa_del(ifa, flags, ifa-ifa_addr);
if (rt)
- rt-rt_refcnt--;
+ rtfree(rt);
}
/*
Re: LibreSSL: GOST ciphers implementation
Chris Cappuccio chris at nmedia.net writes: So, you're saying, he's really dmitry at svr.gov.ru, the source of Russian backdoors into technology worldwide!!! I guess the open-source ecosystem has been thoroughly poisoned! Putin is going to take us over. OpenBSD and Linux are ruined! Fuck, I'm switching to Windows 8. Not enough played with RSA government backdoors, you just said you trust another GOST (which stands for 'GOvernment STandard').
Re: Soekris net6501 GPIO LED support
I can confirm it working on net6501-70 at least for the LED-part on 5.6-stable.
It works as expected.
# dmesg | grep gpio
gpio0 at soekris0: 16 pins
gpio1 at soekris0: 2 pins
However there is some irregularity in reporting of pin-number too:
# gpioctl gpio0
/dev/gpio0: 0 pins
# gpioctl gpio1
/dev/gpio1: 2 pins
I would also like to ask, if there are any plans on reviewing and committing
this code into base?
wbr,
Dima
Apologies if I missed something but to me it looks like this was neither
commited nor declined.
This is about
src/sys/dev/isa/soekris.c (nonexistent)
and not
src/sys/arch/amd64/amd64/bios.c Revision 1.23
Fake 'SMBIOS detection' for the Soekris boxes, by Matt Dainty
References:
http://marc.info/?l=openbsd-techm=136317575910043
http://marc.info/?l=openbsd-techm=137130692221862
Bye, Marcus
m...@bodgit-n-scarper.com (Matt Dainty), 2013.03.13 (Wed) 12:55 (CET):
* Matt Dainty m...@bodgit-n-scarper.com [2013-01-14 11:13:59]:
Attached is a patch that adds soekris(4) which provides access to the
GPIO and LEDs as implemented by the onboard Xilinx FPGA on the Soekris
net6501. The driver provides two GPIO buses; one for the 16 real GPIO
pins exposed on the board, and another which has the LEDs coerced into
the GPIO framework as output-only pins.
I kept them separate to prevent confusion and make the code slightly
simpler, if it's preferred to have just one GPIO bus let me know.
It's enabled in the kernel config with:
soekris0 at isa? port 0x680
gpio*at soekris?
The driver cannot be enabled by default as there's no reliable way to
detect the hardware, it's just a handful of I/O ports at a known
address, (GPIO isn't enabled by default in GENERIC so a kernel compile
is required regardless).
This is what is shown at boot:
soekris0 at isa0 port 0x680/32
gpio0 at soekris0: 16 pins
gpio1 at soekris0: 2 pins
I then have the following in /etc/rc.securelevel:
gpioctl -q gpio1 0 set out error_led
gpioctl -q gpio1 1 set out ready_led
If this driver is acceptable I can send a further patch with man pages.
Tested on a Soekris net6501 running amd64, LEDs work and I've put
simple LED and pushbutton circuits on the GPIO pins.
Here's an updated patch for the driver, the only change is in the
*_match() function that is now simplified and much more reliable thanks
to the committed Soekris comBIOS patch to bios(4).
I've still left the GENERIC config unchanged as there's no other gpio(4)
drivers enabled, I'm guessing as general policy.
I'll send a separate patch with the various man page changes.
Matt
--- /dev/null Wed Mar 13 10:27:40 2013
+++ sys/dev/isa/soekris.c Tue Feb 19 08:31:10 2013
@@ -0,0 +1,239 @@
+/* $OpenBSD$ */
+
+/*
+ * Copyright (c) 2013 Matt Dainty m...@bodgit-n-scarper.com
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF MIND, USE, DATA OR PROFITS, WHETHER IN
+ * AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT
+ * OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+/*
+ * Soekris net6501 GPIO and LEDs as implemented by the onboard Xilinx FPGA
+ */
+
+#include sys/param.h
+#include sys/systm.h
+#include sys/device.h
+#include sys/gpio.h
+
+#include machine/bus.h
+#include machine/intr.h
+
+#include dev/isa/isavar.h
+
+#include dev/gpio/gpiovar.h
+
+#defineSOEKRIS_BASE0x680 /* Base address of FPGA I/O */
+#defineSOEKRIS_IOSIZE 32 /* I/O region size */
+
+#defineSOEKRIS_NPINS 16 /* Number of Pins */
+#defineSOEKRIS_GPIO_INPUT 0x000 /* Current state of pins */
+#defineSOEKRIS_GPIO_OUTPUT 0x004 /* Set state of output pins */
+#defineSOEKRIS_GPIO_RESET 0x008 /* Reset output pins */
+#defineSOEKRIS_GPIO_SET0x00c /* Set output pins */
+#defineSOEKRIS_GPIO_DIR0x010 /* Direction, set for output */
+
+#defineSOEKRIS_NLEDS 2 /* Number of LEDs */
+#defineSOEKRIS_LED_ERROR 0x01c /* Offset to error LED */
+#defineSOEKRIS_LED_READY 0x01d /* Offset to ready LED */
+
+extern char *hw_vendor, *hw_prod;
+
+const u_int soekris_led_offset[SOEKRIS_NLEDS] = {
+ SOEKRIS_LED_ERROR,
Re: LibreSSL: GOST ciphers implementation
2014-11-06 15:44 GMT+03:00 Alexey Suslikov alexey.susli...@gmail.com: Chris Cappuccio chris at nmedia.net writes: So, you're saying, he's really dmitry at svr.gov.ru, the source of Russian backdoors into technology worldwide!!! I guess the open-source ecosystem has been thoroughly poisoned! Putin is going to take us over. OpenBSD and Linux are ruined! Fuck, I'm switching to Windows 8. Not enough played with RSA government backdoors, you just said you trust another GOST (which stands for 'GOvernment STandard'). Wait. AES, SHA* are also government standards. Oh, my... Let's drop everything, leaving just Serpent and ChaCha+Poly1305? Oh, and ECDH/ECDSA are also standards. So let's have only Curve25519. Let us live in a secure safe with no external connectivity. -- With best wishes Dmitry
FAQ Part 1 typos
Hi, Some typos on http://www.openbsd.org/faq/faq1.html Section 1.2 - On what systems does OpenBSD run?. ...has helped produced a higher-quality code base... should read helped produce (or maybe helped to produce). Section 1.8 - What is included with OpenBSD?. Note: this will be removed for 5.6 in farvor of NSD and Unbound should read in favor (or did you mean will be removed, in fervor, with NSD and Unbound? ;)). And, by the way, isn't it the version 5.6 FAQ? Is BIND removed or not? Section 1.11 - Why is/isn't ProductX included?. ...project wishes to devote the resources needed to maintaining it... should read needed to maintain it (or maybe needed for maintaining it, but it sounds weird). Impact on slower platforms, such as hp300 or VAX would be unacceptable - I think it needs a comma after VAX. Best regards, Nick Permyakov
Re: LibreSSL: GOST ciphers implementation
We have and will continue to publicly state that we will welcome implementations of government-mandated ciphers as long as the implementations are clean and they are appropriately licensed, and everyone does *not* need to use them. This is the reason, for example, that we include the french government mandated elliptic curves, and will welcome a cleaned up GOST, and appropriately licensed Camiella. I personally would never use GOST myself. But if you are doing business in Russia you may have no choice. We would rather such people could use the same API as everything else and not have to be a special case, introducing more bugs into software just to comply with government requirements. Two simple rules: 1) It can't mess up the code base for everyone. 2) Everyone should not need to eat the dog food At that point it's your call if you use it or not. On Thu, Nov 6, 2014 at 5:44 AM, Alexey Suslikov alexey.susli...@gmail.com wrote: Chris Cappuccio chris at nmedia.net writes: So, you're saying, he's really dmitry at svr.gov.ru, the source of Russian backdoors into technology worldwide!!! I guess the open-source ecosystem has been thoroughly poisoned! Putin is going to take us over. OpenBSD and Linux are ruined! Fuck, I'm switching to Windows 8. Not enough played with RSA government backdoors, you just said you trust another GOST (which stands for 'GOvernment STandard').
Re: FAQ Part 1 typos
On Thu, Nov 6, 2014 at 9:36 AM, Nick Permyakov stick...@mail.ru wrote: Hi, Some typos on http://www.openbsd.org/faq/faq1.html Section 1.2 - On what systems does OpenBSD run?. ...has helped produced a higher-quality code base... should read helped produce (or maybe helped to produce). Section 1.8 - What is included with OpenBSD?. Note: this will be removed for 5.6 in farvor of NSD and Unbound should read in favor (or did you mean will be removed, in fervor, with NSD and Unbound? ;)). And, by the way, isn't it the version 5.6 FAQ? Is BIND removed or not Should really be favour Section 1.11 - Why is/isn't ProductX included?. ...project wishes to devote the resources needed to maintaining it... should read needed to maintain it (or maybe needed for maintaining it, but it sounds weird). Impact on slower platforms, such as hp300 or VAX would be unacceptable - I think it needs a comma after VAX. Best regards, Nick Permyakov
Re: use siphash for in_pcb hash key lookups
On Tue, 4 Nov 2014 14:50:49 +1000
David Gwynne da...@gwynne.id.au wrote:
this uses siphash to protect the in_pcb hashes. this is pretty much
a textbook example of what siphash should be used for.
tests? ok?
Giving inpcb_hash() to LIST_* macros via INPCB*HASH() caused calling
inpcb_hash() multiple times unintentionally. Fixed. Diff is as
follows.
Otherwise ok yasuoka. test yasuoka.
Index: netinet/in_pcb.c
===
RCS file: /cvs/src/sys/netinet/in_pcb.c,v
retrieving revision 1.161
diff -u -p -r1.161 in_pcb.c
--- netinet/in_pcb.c28 Oct 2014 11:02:38 - 1.161
+++ netinet/in_pcb.c6 Nov 2014 16:18:14 -
@@ -91,6 +91,7 @@
#include netinet/ip_var.h
#include dev/rndvar.h
+
#include sys/mount.h
#include nfs/nfsproto.h
@@ -121,17 +122,68 @@ int in_pcbresize (struct inpcbtable *, i
#defineINPCBHASH_LOADFACTOR(_x)(((_x) * 3) / 4)
+struct inpcbhead *in_pcbhash(struct inpcbtable *, int,
+const struct in_addr *, u_short, const struct in_addr *, u_short);
+struct inpcbhead *in6_pcbhash(struct inpcbtable *, int,
+const struct in6_addr *, u_short, const struct in6_addr *, u_short);
+struct inpcbhead *in_pcblhash(struct inpcbtable *, int, u_short);
+
+struct inpcbhead *
+in_pcbhash(struct inpcbtable *table, int rdom,
+const struct in_addr *faddr, u_short fport,
+const struct in_addr *laddr, u_short lport)
+{
+ SIPHASH_CTX ctx;
+ u_int32_t nrdom = htonl(rdom);
+
+ SipHash24_Init(ctx, table-inpt_key);
+ SipHash24_Update(ctx, nrdom, sizeof(nrdom));
+ SipHash24_Update(ctx, faddr, sizeof(*faddr));
+ SipHash24_Update(ctx, fport, sizeof(fport));
+ SipHash24_Update(ctx, laddr, sizeof(*laddr));
+ SipHash24_Update(ctx, lport, sizeof(lport));
+
+ return (table-inpt_hashtbl[SipHash24_End(ctx) table-inpt_hash]);
+}
+
#defineINPCBHASH(table, faddr, fport, laddr, lport, rdom) \
- (table)-inpt_hashtbl[(ntohl((faddr)-s_addr) + \
- ntohs((fport)) + ntohs((lport)) + (rdom)) (table-inpt_hash)]
+ in_pcbhash(table, rdom, faddr, fport, laddr, lport)
+
+struct inpcbhead *
+in6_pcbhash(struct inpcbtable *table, int rdom,
+const struct in6_addr *faddr, u_short fport,
+const struct in6_addr *laddr, u_short lport)
+{
+ SIPHASH_CTX ctx;
+ u_int32_t nrdom = htonl(rdom);
+
+ SipHash24_Init(ctx, table-inpt_key);
+ SipHash24_Update(ctx, nrdom, sizeof(nrdom));
+ SipHash24_Update(ctx, faddr, sizeof(*faddr));
+ SipHash24_Update(ctx, fport, sizeof(fport));
+ SipHash24_Update(ctx, laddr, sizeof(*laddr));
+ SipHash24_Update(ctx, lport, sizeof(lport));
+
+ return (table-inpt_hashtbl[SipHash24_End(ctx) table-inpt_hash]);
+}
#defineIN6PCBHASH(table, faddr, fport, laddr, lport, rdom) \
- (table)-inpt_hashtbl[(ntohl((faddr)-s6_addr32[0] ^ \
- (faddr)-s6_addr32[3]) + ntohs((fport)) + ntohs((lport)) + (rdom)) \
- (table-inpt_hash)]
+ in6_pcbhash(table, rdom, faddr, fport, laddr, lport)
+
+struct inpcbhead *
+in_pcblhash(struct inpcbtable *table, int rdom, u_short lport)
+{
+ SIPHASH_CTX ctx;
+ u_int32_t nrdom = htonl(rdom);
-#defineINPCBLHASH(table, lport, rdom) \
- (table)-inpt_lhashtbl[(ntohs((lport)) + (rdom)) table-inpt_lhash]
+ SipHash24_Init(ctx, table-inpt_key);
+ SipHash24_Update(ctx, nrdom, sizeof(nrdom));
+ SipHash24_Update(ctx, lport, sizeof(lport));
+
+ return (table-inpt_lhashtbl[SipHash24_End(ctx) table-inpt_lhash]);
+}
+
+#defineINPCBLHASH(table, lport, rdom) in_pcblhash(table, rdom, lport)
void
in_pcbinit(struct inpcbtable *table, int hashsize)
@@ -148,6 +200,7 @@ in_pcbinit(struct inpcbtable *table, int
panic(in_pcbinit: hashinit failed for lport);
table-inpt_lastport = 0;
table-inpt_count = 0;
+ arc4random_buf(table-inpt_key, sizeof(table-inpt_key));
}
/*
@@ -176,6 +229,7 @@ in_pcballoc(struct socket *so, struct in
{
struct inpcb *inp;
int s;
+ struct inpcbhead *head;
splsoftassert(IPL_SOFTNET);
@@ -199,11 +253,11 @@ in_pcballoc(struct socket *so, struct in
table-inpt_count++ INPCBHASH_LOADFACTOR(table-inpt_hash))
(void)in_pcbresize(table, (table-inpt_hash + 1) * 2);
TAILQ_INSERT_HEAD(table-inpt_queue, inp, inp_queue);
- LIST_INSERT_HEAD(INPCBLHASH(table, inp-inp_lport,
- inp-inp_rtableid), inp, inp_lhash);
- LIST_INSERT_HEAD(INPCBHASH(table, inp-inp_faddr, inp-inp_fport,
- inp-inp_laddr, inp-inp_lport, rtable_l2(inp-inp_rtableid)),
- inp, inp_hash);
+ head = INPCBLHASH(table, inp-inp_lport, inp-inp_rtableid);
+ LIST_INSERT_HEAD(head, inp, inp_lhash);
+ head = INPCBHASH(table, inp-inp_faddr, inp-inp_fport,
+ inp-inp_laddr, inp-inp_lport, rtable_l2(inp-inp_rtableid));
+
Re: use siphash for in_pcb hash key lookups
On Fri, 07 Nov 2014 01:19:45 +0900 (JST)
YASUOKA Masahiko yasu...@openbsd.org wrote:
On Tue, 4 Nov 2014 14:50:49 +1000
David Gwynne da...@gwynne.id.au wrote:
this uses siphash to protect the in_pcb hashes. this is pretty much
a textbook example of what siphash should be used for.
tests? ok?
Giving inpcb_hash() to LIST_* macros via INPCB*HASH() caused calling
inpcb_hash() multiple times unintentionally. Fixed. Diff is as
follows.
Otherwise ok yasuoka. test yasuoka.
I put kernel gprof results on
http://yasuoka.net/~yasuoka/oldhash-gprof.txt.gz
http://yasuoka.net/~yasuoka/siphash-gprof.txt.gz
tested on
- load: 4,000 HTTP connections / sec by IxLoad
- 1 HTTP transaction / connection
- HTTP response body size = 1 byte
- relayd(8) relays them with below config
http protocol http {
tcp backlog 32
}
relay HTTP_relay {
listen on 127.0.0.1 port 80
protocol http
forward to destination
}
- pf.conf
pass in quick inet proto tcp to port 80 divert-to localhost port 80
- profiling is enabled 10 seconds
- OpenBSD 5.6 (amd64) + diff
- Intel Xeon E3-1220 v3 @ 3.10GHz (4 CPUs)
short result
compare to pf_test(), it was 57%
% egrep '^\[(62|45)]' siphash-gprof.txt
[45] 1.00.030.37 682175 pf_test [45]
[62] 0.50.000.21 501212 in_pcbhash [62]
%
Re: rtentry leak
Martin Pieuchot [mpieuc...@nolizard.org] wrote:
Indeed! And the ifa might also be freed so this chunk is completely
wrong. Here's a version of the diff without it, ok?
This looks ok to me
Index: net/route.c
===
RCS file: /home/ncvs/src/sys/net/route.c,v
retrieving revision 1.189
diff -u -p -r1.189 route.c
--- net/route.c 4 Nov 2014 15:24:40 - 1.189
+++ net/route.c 6 Nov 2014 10:24:02 -
@@ -215,7 +215,7 @@ route_init(void)
{
struct domain*dom;
- pool_init(rtentry_pool, sizeof(struct rtentry), 0, 0, 0, rtent,
+ pool_init(rtentry_pool, sizeof(struct rtentry), 0, 0, 0, rtentry,
NULL);
rn_init(); /* initialize all zeroes, all ones, mask table */
@@ -1220,7 +1220,7 @@ rt_ifa_addloop(struct ifaddr *ifa)
if (rt == NULL || !ISSET(rt-rt_flags, flags));
rt_ifa_add(ifa, RTF_UP | flags, ifa-ifa_addr);
if (rt)
- rt-rt_refcnt--;
+ rtfree(rt);
}
/*
@@ -1267,7 +1267,7 @@ rt_ifa_delloop(struct ifaddr *ifa)
if (rt != NULL ISSET(rt-rt_flags, flags))
rt_ifa_del(ifa, flags, ifa-ifa_addr);
if (rt)
- rt-rt_refcnt--;
+ rtfree(rt);
}
/*
--
The bums will always lose
Re: LibreSSL: GOST ciphers implementation
Bob Beck beck at openbsd.org writes: 1) It can't mess up the code base for everyone. 2) Everyone should not need to eat the dog food 3) I try to convince myself that our grant means a half of a cruise missile doesn't get built (c)
Re: LibreSSL: GOST ciphers implementation
And that has nothing do to with what I said Alexey. Go troll somewhere else.. On Thu, Nov 6, 2014 at 2:05 PM, Alexey Suslikov alexey.susli...@gmail.com wrote: Bob Beck beck at openbsd.org writes: 1) It can't mess up the code base for everyone. 2) Everyone should not need to eat the dog food 3) I try to convince myself that our grant means a half of a cruise missile doesn't get built (c)
Re: FAQ Part 1 typos
On 11/06/14 09:35, Nick Permyakov wrote: Hi, Some typos on http://www.openbsd.org/faq/faq1.html Section 1.2 - On what systems does OpenBSD run?. ...has helped produced a higher-quality code base... should read helped produce (or maybe helped to produce). Section 1.8 - What is included with OpenBSD?. Note: this will be removed for 5.6 in farvor of NSD and Unbound should read in favor (or did you mean will be removed, in fervor, with NSD and Unbound? ;)). And, by the way, isn't it the version 5.6 FAQ? Is BIND removed or not? Section 1.11 - Why is/isn't ProductX included?. ...project wishes to devote the resources needed to maintaining it... should read needed to maintain it (or maybe needed for maintaining it, but it sounds weird). Impact on slower platforms, such as hp300 or VAX would be unacceptable - I think it needs a comma after VAX. Best regards, Nick Permyakov fixed, but please keep www/ issues off tech@ tech@ is for code with diffs. Nick.
