Re: PPP comression and extension info required...

Re: PPP comression and extension info required...

[James Carlson]

arun b wrote:
> HI,
> I wanted to know PPP -extension  support , compression ...
> does it available in the ppp-2.4.4. ?  if so how do we test it.?
> Any  info you know  to share would be appreciated..

Yes, it supports data compression, and it's enabled by default.  See the
pppd(1M) man page for details.  Note that compression schemes need to be
built into your kernel, so what's _actually_ supported depends on what
kernel modules you have.

The debug log messages will be helpful here as well, as they indicate
which compression algorithms are being negotiated.

I'm not sure what sort of testing you want to do with it, though, so
you'll need to be more specific.  For what it's worth, I find that
passing large amounts of highly-compressible data (such as the letter
"A" repeated a few million times in a file) is one good stress test, and
passing incompressible data (such as a large bzip2'd file) is another.
Each explores a different end in the usual string-based data compression
algorithm.  The Canterbury Corpus is another fairly well-known test, and
is probably a good middle-of-the-road test for passing compressible data.

But there are other forms of "testing" that are possible here, including
performance and interoperability, and those may require other sorts of
testing schemes and other considerations, so I'm not really sure what it
is you're after.

-- 
James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>

PPP comression and extension info required...

[arun b]

HI,
I wanted to know PPP -extension  support , compression ...
does it available in the ppp-2.4.4. ?  if so how do we test it.?
Any  info you know  to share would be appreciated..

Regards,
Arun

Re: PPP comression and extension info required...

[arun b]

Hi James.,

Thank you as usual to respond me quick..!
Well  I wanted to validate rfc-1662.
I see in ppp source  deflate, bsd, compression  are these covers
rfc-1662 if so please provide me further info on this

Regs,
Arun


On Wed, Jun 23, 2010 at 11:09 PM, James Carlson
<carlsonj@workingcode.com> wrote:
> arun b wrote:
>> HI,
>> I wanted to know PPP -extension  support , compression ...
>> does it available in the ppp-2.4.4. ?  if so how do we test it.?
>> Any  info you know  to share would be appreciated..
>
> Yes, it supports data compression, and it's enabled by default.  See the
> pppd(1M) man page for details.  Note that compression schemes need to be
> built into your kernel, so what's _actually_ supported depends on what
> kernel modules you have.
>
> The debug log messages will be helpful here as well, as they indicate
> which compression algorithms are being negotiated.
>
> I'm not sure what sort of testing you want to do with it, though, so
> you'll need to be more specific.  For what it's worth, I find that
> passing large amounts of highly-compressible data (such as the letter
> "A" repeated a few million times in a file) is one good stress test, and
> passing incompressible data (such as a large bzip2'd file) is another.
> Each explores a different end in the usual string-based data compression
> algorithm.  The Canterbury Corpus is another fairly well-known test, and
> is probably a good middle-of-the-road test for passing compressible data.
>
> But there are other forms of "testing" that are possible here, including
> performance and interoperability, and those may require other sorts of
> testing schemes and other considerations, so I'm not really sure what it
> is you're after.
>
> --
> James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>
>

Re: PPP comression and extension info required...

[James Carlson]

arun b wrote:
> Hi James.,
> 
> Thank you as usual to respond me quick..!
> Well  I wanted to validate rfc-1662.
> I see in ppp source  deflate, bsd, compression  are these covers
> rfc-1662 if so please provide me further info on this

I'm afraid I still don't really understand.

RFC 1662 describes AHDLC, which is the low-level framing on async lines,
as well as the other mappings of PPP to octet-synchronous HDLC (read:
SONET/SDH) and bit-stuffed HDLC (read: ISDN and other telecom).  It
doesn't really describe much about "compression" except a few header
compression bits.

Are you really asking about PPP header compression?  If so, why?  What
could you be testing that would require a specific test for this?

If you need such a low-level PPP-specific test, I strongly recommend
getting a protocol validation device or employing a service.  IXIA's
ixANVL tester can verify low-level details of protocol operation.
Another place to turn would be UNH's IOL.

If you actually have your own independent implementation (and wanting to
test this low-level detail on your own suggests that you do), then I
really recommend getting the right tools for the job.

If you don't want to do either of those, then you're probably on your
own.  You could perhaps make do by using the existing options described
in pppd(1M) along with either an external analyzer or (perhaps) using
either the pppdump(1M) tool or even kdebug 3.

But, again, this is just header compression, not data compression.  It's
really pretty boring stuff.

Did you mean RFC 1962 instead?  If so, then that's just what
_negotiates_ compression.  The actual compression takes place using the
compression algorithms, and these are controlled by the documented
pppd(1M) options and the kernel modules, as I mentioned in my first reply.

-- 
James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>

Re: PPP comression and extension info required...

[arun b]

Well I need to bring up the setup for both data and header compression..
Below are the logs, obtained I can see there is CCP-protocol
negotiation initiated and got rejected.

1) Not sure where is wrong ..... is client is up with CCP here?
2) Can we use PPPoE test  to do CCP negotiaoin successfully ?

Here i provide the logs i got in the test...
Regs,
Arun

LOGS:

                Plugin pppoatm.so loaded.
                using channel 1
                Using interface ppp0
                Connect: ppp0 <--> 8.48
                sent [LCP ConfReq id=0x1 <magic 0x9197cda1>]

                rcvd [LCP ConfAck id=0x1 <magic 0x9197cda1>] 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 ...

                rcvd [LCP ConfReq id=0x9 <auth chap MD5> <magic
0xffe16db>] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 ...

                sent [LCP ConfAck id=0x9 <auth chap MD5> <magic 0xffe16db>]

                sent [LCP EchoReq id=0x0 magic=0x9197cda1]

                rcvd [CHAP Challenge id=0x1
<0ca36321bddd80756467d9f49a764ad3>, name = "ASAMRouter"] 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

                Warning - secret file /etc/ppp/chap-secrets has world
and/or group access

                sent [CHAP Response id=0x1
<31dc4c7b43023d4691446131a9248418>, name = "test"]

                rcvd [LCP EchoRep id=0x0 magic=0xffe16db] 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 ...

                rcvd [CHAP Success id=0x1 ""] 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 ...

                CHAP authentication succeeded

                CHAP authentication succeeded

                kernel does not support PPP filtering

                sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#)
15> <bsd v1 15>]

                sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 0.0.0.0>]

                rcvd [IPCP ConfReq id=0x1 <addr 19.0.0.1>] 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 ...

                sent [IPCP ConfAck id=0x1 <addr 19.0.0.1>]

                rcvd [LCP ProtRej id=0xa 80 fd 01 01 00 0f 1a 04 78 00
18 04 78 00 15 03 2f] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ...

                Protocol-Reject for 'Compression Control Protocol'
(0x80fd) received

                rcvd [IPCP ConfRej id=0x1 <compress VJ 0f 01>] 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 ...

                sent [IPCP ConfReq id=0x2 <addr 0.0.0.0>]

                rcvd [IPCP ConfNak id=0x2 <addr 13.0.0.20>] 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 ...

                sent [IPCP ConfReq id=0x3 <addr 13.0.0.20>]

                rcvd [IPCP ConfAck id=0x3 <addr 13.0.0.20>] 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 ...

                local  IP address 13.0.0.20

                remote IP address 19.0.0.1

                Script /etc/ppp/ip-up started (pid 780)

                Script /etc/ppp/ip-up finished (pid 780), status = 0x1


On Wed, Jun 23, 2010 at 11:47 PM, James Carlson
<carlsonj@workingcode.com> wrote:
>
> arun b wrote:
> > Hi James.,
> >
> > Thank you as usual to respond me quick..!
> > Well  I wanted to validate rfc-1662.
> > I see in ppp source  deflate, bsd, compression  are these covers
> > rfc-1662 if so please provide me further info on this
>
> I'm afraid I still don't really understand.
>
> RFC 1662 describes AHDLC, which is the low-level framing on async lines,
> as well as the other mappings of PPP to octet-synchronous HDLC (read:
> SONET/SDH) and bit-stuffed HDLC (read: ISDN and other telecom).  It
> doesn't really describe much about "compression" except a few header
> compression bits.
>
> Are you really asking about PPP header compression?  If so, why?  What
> could you be testing that would require a specific test for this?
>
> If you need such a low-level PPP-specific test, I strongly recommend
> getting a protocol validation device or employing a service.  IXIA's
> ixANVL tester can verify low-level details of protocol operation.
> Another place to turn would be UNH's IOL.
>
> If you actually have your own independent implementation (and wanting to
> test this low-level detail on your own suggests that you do), then I
> really recommend getting the right tools for the job.
>
> If you don't want to do either of those, then you're probably on your
> own.  You could perhaps make do by using the existing options described
> in pppd(1M) along with either an external analyzer or (perhaps) using
> either the pppdump(1M) tool or even kdebug 3.
>
> But, again, this is just header compression, not data compression.  It's
> really pretty boring stuff.
>
> Did you mean RFC 1962 instead?  If so, then that's just what
> _negotiates_ compression.  The actual compression takes place using the
> compression algorithms, and these are controlled by the documented
> pppd(1M) options and the kernel modules, as I mentioned in my first reply.
>
> --
> James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>

Re: PPP comression and extension info required...

[James Cameron]

On Thu, Jun 24, 2010 at 10:31:27AM +0530, arun b wrote:
> Below are the logs, obtained I can see there is CCP-protocol
> negotiation initiated and got rejected.

Yes, according to your log, the peer (not the host) rejected CCP.  That
probably means the peer is not capable of processing CCP.

To prevent the host from trying CCP, add the noccp option to the host
pppd configuration.

According to manual page for pppd, noccp means "Disable CCP (Compression
Control Protocol) negotiation.  This option should only be required if
the peer is buggy and gets confused by requests from pppd for CCP
negotiation."

> Well I need to bring up the setup for both data and header
> compression..

You will need to fix the peer then.  On the evidence provided, it does
not support this.

-- 
James Cameron
http://quozl.linux.org.au/

Re: PPP comression and extension info required...

[arun b]

HI,
Ok thanks, To agree it is a peer-issue (server ).
few things to know..
1) In the logs it shows deflate , bsd   is that mean is PPPD tries for
multiple types of encryption and fails?
2)can we run this test for PPPoE?
3) what is shlc ?

Regards,
Arun

On Thu, Jun 24, 2010 at 12:53 PM, James Cameron <quozl@laptop.org> wrote:
> On Thu, Jun 24, 2010 at 10:31:27AM +0530, arun b wrote:
>> Below are the logs, obtained I can see there is CCP-protocol
>> negotiation initiated and got rejected.
>
> Yes, according to your log, the peer (not the host) rejected CCP.  That
> probably means the peer is not capable of processing CCP.
>
> To prevent the host from trying CCP, add the noccp option to the host
> pppd configuration.
>
> According to manual page for pppd, noccp means "Disable CCP (Compression
> Control Protocol) negotiation.  This option should only be required if
> the peer is buggy and gets confused by requests from pppd for CCP
> negotiation."
>
>> Well I need to bring up the setup for both data and header
>> compression..
>
> You will need to fix the peer then.  On the evidence provided, it does
> not support this.
>
> --
> James Cameron
> http://quozl.linux.org.au/
>

Re: PPP comression and extension info required...

[arun b]

HI,
Ok thanks, To agree it is a peer-issue (server ).
few things to know..
1) In the logs it shows deflate , bsd   is that mean is PPPD tries for
multiple types of encryption and fails?
2)can we run this test for PPPoE?
3) what is shlc ?

Regards,
Arun

On Thu, Jun 24, 2010 at 12:53 PM, James Cameron <quozl@laptop.org> wrote:
> On Thu, Jun 24, 2010 at 10:31:27AM +0530, arun b wrote:
>> Below are the logs, obtained I can see there is CCP-protocol
>> negotiation initiated and got rejected.
>
> Yes, according to your log, the peer (not the host) rejected CCP.  That
> probably means the peer is not capable of processing CCP.
>
> To prevent the host from trying CCP, add the noccp option to the host
> pppd configuration.
>
> According to manual page for pppd, noccp means "Disable CCP (Compression
> Control Protocol) negotiation.  This option should only be required if
> the peer is buggy and gets confused by requests from pppd for CCP
> negotiation."
>
>> Well I need to bring up the setup for both data and header
>> compression..
>
> You will need to fix the peer then.  On the evidence provided, it does
> not support this.
>
> --
> James Cameron
> http://quozl.linux.org.au/
>

Re: PPP comression and extension info required...

[James Carlson]

arun b wrote:
> HI,
> Ok thanks, To agree it is a peer-issue (server ).
> few things to know..
> 1) In the logs it shows deflate , bsd   is that mean is PPPD tries for
> multiple types of encryption and fails?

Those are some of the supported data compression algorithms that can be
negotiated by pppd using CCP.  On a good day, it'll try to negotiate all
of them and use whatever is in common between the peers.  You can see it
offering all that it supports at once here:

sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]

RFC 1962 specifies that if you ask for multiple types, and if the peer
agrees to the list, then what you actually use is the first one on the
list ("deflate 15" above).  Thus, asking for them all at once is the
most reasonable thing to do.

However, if the peer refuses CCP, then it doesn't matter what types of
algorithms pppd implements.  Refusing CCP is the peer's way of saying "I
don't want to talk about data compression at all."  It likely means that
the peer doesn't implement any sort of data compression, because if it
implemented other methods, it would more likely offer some with a
Configure-Nak rather than a flat-out rejection.  You can see the peer
refusing to negotiate data compression here:

rcvd [LCP ProtRej id=0xa 80 fd 01 01 00 0f 1a 04 78 00
18 04 78 00 15 03 2f] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ...

Protocol-Reject for 'Compression Control Protocol' (0x80fd) received

In PPP, you can refuse to negotiate any protocol or mechanism you want.
 If it's refused, there's really nothing pppd can do about it, but
either decide to plow ahead without the requested feature (as is done
for CCP) or terminate the link (as might be done for something like CHAP).

Nit: those aren't encryption mechanisms.  They're data compression only.

> 2)can we run this test for PPPoE?

Sure.  PPPoE is merely a low-level transport and tunneling mechanism.
It has nothing much to do with the PPP options and protocols.

> 3) what is shlc ?

I see nothing called "shlc" in any of your logs, nor do I know of
anything by that name.  If you have a question about a particular log
message or feature, I recommend quoting the actual message or
documentation you're reading in order to be clear.

-- 
James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>

Re: PPP comression and extension info required...

[James Carlson]

arun b wrote:
> 3) what is shlc ?

Is it possible you're asking about "slhc?"

If so, then that's the name of the kernel module on Linux that
implements VJ header compression.  That's yet another header compression
mechanism, and is specific to IPv4 TCP.  It was basically designed to
make the usual 40 byte highly-predictable TCP header squeeze down to two
or three bytes, so that interactive data (think: "telnet" or "rlogin")
is usable over a slow serial link (think: "modems").

Again, pppd(1M) is your friend.  It documents the options for turning VJ
header compression on and off and adjusting the number of slots available.

Header compression does not compress the data itself, and is not in any
way related to CCP.  Instead, VJ header compression is negotiated by IPCP.

(The "slhc" module is Linux-specific, and isn't a generic PPP term.  On
other OSes, you'll see VJ compression implemented in other ways.)

-- 
James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>

Re: PPP comression and extension info required...

[arun b]

Ok,
as you said i can verify all compression types on PPPoE test...
So i have pppoe-server available at my pc,  if you have come across
related server configuration for this .... pls do know me.
and running PPPoA - test running is not just easy to me as
unavailability of the device.


Regs,
Arun



On Thu, Jun 24, 2010 at 4:54 PM, James Carlson <carlsonj@workingcode.com> wrote:
> arun b wrote:
>> 3) what is shlc ?
>
> Is it possible you're asking about "slhc?"
>
> If so, then that's the name of the kernel module on Linux that
> implements VJ header compression.  That's yet another header compression
> mechanism, and is specific to IPv4 TCP.  It was basically designed to
> make the usual 40 byte highly-predictable TCP header squeeze down to two
> or three bytes, so that interactive data (think: "telnet" or "rlogin")
> is usable over a slow serial link (think: "modems").
>
> Again, pppd(1M) is your friend.  It documents the options for turning VJ
> header compression on and off and adjusting the number of slots available.
>
> Header compression does not compress the data itself, and is not in any
> way related to CCP.  Instead, VJ header compression is negotiated by IPCP.
>
> (The "slhc" module is Linux-specific, and isn't a generic PPP term.  On
> other OSes, you'll see VJ compression implemented in other ways.)
>
> --
> James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>
>

Re: PPP comression and extension info required...

[James Carlson]

arun b wrote:
> Ok,
> as you said i can verify all compression types on PPPoE test...
> So i have pppoe-server available at my pc,  if you have come across
> related server configuration for this .... pls do know me.
> and running PPPoA - test running is not just easy to me as
> unavailability of the device.

I don't know what you're asking about, but pppd generally enables all
available compression modes by default (regardless of the underlying
communication mechanism), and will disable a compression mode either if
the peer disagrees with the request or if you specify one of the
documented options to turn off that mode (or to turn off compression
completely).

In other words, if your "server" is actually pppd, then there's nothing
that you need to do to enable compression.  If it's something other than
pppd, then this might not be the right mailing list.  You should consult
your server's documentation to find out what features it offers.

As for selectively turning off available compression types in pppd, I
still urge you to read the pppd man page.  It's pretty important.  For
data compression options, you'll find the following:

  noccp, bsdcomp, nobsdcomp, deflate, nodeflate, predictor1,
  nopredictor1

For header compression (again, _not_ data compression), you'll find:

  noaccomp, novj, novjccomp, vj-max-slots

There are also two that are sort of special -- mpshortseq and
nompshortseq -- that have to do with header compression when using MP.
You haven't mentioned MP yet, so I'll assume you're not using it.

The really short answer is this: PPP negotiates for everything.  If both
sides support something, then, great, it'll be enabled.  If either or
both sides don't support something, then it won't be enabled.  That's
pretty much the whole story.

-- 
James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>

Re: PPP comression and extension info required...

[arun b]

Ok ,
let me explore on the server side ....!

Could you please guide me thru ppp-extension support ....!

Regs,
Arun

On Thu, Jun 24, 2010 at 7:49 PM, James Carlson <carlsonj@workingcode.com> wrote:
> arun b wrote:
>> Ok,
>> as you said i can verify all compression types on PPPoE test...
>> So i have pppoe-server available at my pc,  if you have come across
>> related server configuration for this .... pls do know me.
>> and running PPPoA - test running is not just easy to me as
>> unavailability of the device.
>
> I don't know what you're asking about, but pppd generally enables all
> available compression modes by default (regardless of the underlying
> communication mechanism), and will disable a compression mode either if
> the peer disagrees with the request or if you specify one of the
> documented options to turn off that mode (or to turn off compression
> completely).
>
> In other words, if your "server" is actually pppd, then there's nothing
> that you need to do to enable compression.  If it's something other than
> pppd, then this might not be the right mailing list.  You should consult
> your server's documentation to find out what features it offers.
>
> As for selectively turning off available compression types in pppd, I
> still urge you to read the pppd man page.  It's pretty important.  For
> data compression options, you'll find the following:
>
>  noccp, bsdcomp, nobsdcomp, deflate, nodeflate, predictor1,
>  nopredictor1
>
> For header compression (again, _not_ data compression), you'll find:
>
>  noaccomp, novj, novjccomp, vj-max-slots
>
> There are also two that are sort of special -- mpshortseq and
> nompshortseq -- that have to do with header compression when using MP.
> You haven't mentioned MP yet, so I'll assume you're not using it.
>
> The really short answer is this: PPP negotiates for everything.  If both
> sides support something, then, great, it'll be enabled.  If either or
> both sides don't support something, then it won't be enabled.  That's
> pretty much the whole story.
>
> --
> James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>
>

Re: PPP comression and extension info required...

[James Carlson]

arun b wrote:
> Ok ,
> let me explore on the server side ....!
> 
> Could you please guide me thru ppp-extension support ....!

Only if you can be more specific in what sort of guidance you need, and
if you've already read through the existing documentation and still have
questions.  Otherwise, and no offense really intended, it's likely not
to be a useful way for either of us to spend time.

What "ppp-extension" are you talking about?  Are you talking about the
configuration options?  The various basic PPP control features?  The
system-specific kernel modules and features?  The possible add-on
features?  Or something else?

As with other questions, and as I mentioned before, if you have a
question about the documentation or about some error or debug message
you're seeing, __please__ include a copy of that source material with
your question.  Providing more context would help.

Based on the messages you've posted to the list so far, and my
experience in the area, I suspect you need a different kind of
assistance than I think you'll find available for free on mailing lists.
 I strongly recommend (as I did in a previous message) searching out
organizations and products that can simplify your job.  Surely, your
time is worth something to you, and spending it on a reinvention of
someone else's wheel can't be a good thing.

The UNH IOL has both interoperability and conformance tests available
for vendors at a very reasonable rate.  I highly recommend them, and I
know some of the folks there if you need pointers.  In addition to the
IOL, there are also commercial devices available that will do validation
tests, such as IxANVL.  They're by no means "simple" to operate and
interpret, but they're much simpler and more effective than attempting
to roll your own tests.

-- 
James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>

Re: PPP comression and extension info required...

[arun b]

HI James...
Let me understand on extensions.. and revert you...

I just found the features ppp-extension and as you have explained
there were multiple concepts in it...!
Thanks,
Arun



On Thu, Jun 24, 2010 at 11:19 PM, James Carlson
<carlsonj@workingcode.com> wrote:
> arun b wrote:
>> Ok ,
>> let me explore on the server side ....!
>>
>> Could you please guide me thru ppp-extension support ....!
>
> Only if you can be more specific in what sort of guidance you need, and
> if you've already read through the existing documentation and still have
> questions.  Otherwise, and no offense really intended, it's likely not
> to be a useful way for either of us to spend time.
>
> What "ppp-extension" are you talking about?  Are you talking about the
> configuration options?  The various basic PPP control features?  The
> system-specific kernel modules and features?  The possible add-on
> features?  Or something else?
>
> As with other questions, and as I mentioned before, if you have a
> question about the documentation or about some error or debug message
> you're seeing, __please__ include a copy of that source material with
> your question.  Providing more context would help.
>
> Based on the messages you've posted to the list so far, and my
> experience in the area, I suspect you need a different kind of
> assistance than I think you'll find available for free on mailing lists.
>  I strongly recommend (as I did in a previous message) searching out
> organizations and products that can simplify your job.  Surely, your
> time is worth something to you, and spending it on a reinvention of
> someone else's wheel can't be a good thing.
>
> The UNH IOL has both interoperability and conformance tests available
> for vendors at a very reasonable rate.  I highly recommend them, and I
> know some of the folks there if you need pointers.  In addition to the
> IOL, there are also commercial devices available that will do validation
> tests, such as IxANVL.  They're by no means "simple" to operate and
> interpret, but they're much simpler and more effective than attempting
> to roll your own tests.
>
> --
> James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>
>