On May 21, 2009, at 11:50 AM, Dale Moore wrote:
Hi Graham,
I believe that I've figured out this problem
with syswrite returning 1 instead of the number of
bytes actually written.
The problem appears to be with Authen::SASL::Cyrus .
Unfortunately there are 2 different Authen::SASL::Cyrus
modules :-(, but I think you are using the one by Patrick Boettcher
As Patrick does not own the namespace his module is not easily found.
However, with his permission, I have created a rename of that module
and it is available on github at
http://github.com/gbarr/perl-authen-sasl-xs/tree
In that module, they supply their own WRITE function
in Authen::SASL::Cyrus::Security . This WRITE function
is called when syswrite is called with an LDAP connection
that has been authenticated with Cyrus SASL.
This WRITE function does not implement the standard
syswrite semantics. It's implementation is
sub WRITE {
my($ref,$string,$len) = @_;
my($fh, $clearbuf, $cryptbuf);
$fh = $ref->{fh};
$clearbuf = substr($string, 0, $len);
$cryptbuf = $ref->{conn}->encode($clearbuf);
print $fh $cryptbuf;
}
Yes that looks the same as
http://github.com/gbarr/perl-authen-sasl-xs/blob/91fb5bf011d3e6a345c6996141af71f563982040/lib/Authen/SASL/XS/Security.pm#L74
Authen::SASL needs to be modified to look for ::XS by default, but you
can make it find it with
use Authen::SASL qw(XS Perl);
Any patches to Authen::SASL::XS would be welcome.
Graham.
It does not handle offsets, and print returns
TRUE on success (what I was seeing), and not the
number of bytes. This is a bug in Authen::SASL::Cyrus .
If I avoid Cyrus Sasl, and use Perl SASL all is well
and the problem does not persist.
I appreciate your help in resolving this problem.
Dale Moore
-----Original Message-----
From: Graham Barr [mailto:gb...@pobox.com]
Sent: Tuesday, May 19, 2009 4:27 PM
To: dale.mo...@cs.cmu.edu
Cc: perl-ldap@perl.org
Subject: Re: Perl syswrite and IO/SSL
On May 19, 2009, at 2:31 PM, Dale Moore wrote:
I am having a problem with LDAP.pm and wondering
if any other folks are experiencing similar problems.
The problems are the result of code that was modified
in this patch
http://git.goingon.net/?p=perl-ldap.git;a=commitdiff;h=8c6c9cfcb78adf229437507f2e8ffe86d15e712d
There are some style issues that I don’t like about this patch.
- We do a length() call on each time through the loop rather than
once
- We do a substr call each time through the loop, which isnt
necessary
if we would instead use the offset parameter to syswrite
- No reference in where the number 15000 came from.
But the patch appears to basically sound, even if it does offend my
sense
of asthetics.
Patches welcome.
The only problem I am having is that after a successful
bind and several passes through this code, it starts to misbehave.
The calls to syswrite return the value 1 instead of the number of
bytes
in the buffer as I might have expected.
The problem is
- The call to syswrite() of a buffer of several hundred bytes
always returns 1
and not the number of the several hundred bytes as expected.
This causes the syswrite to be retried with a slightly smaller
buffer.
The remote server appears to receive the original request, and
responds
but subsequent writes of the smaller buffer confuse it and it
drops the connection.
- A system call trace of perl process reveals that it is calling
write()
with several hundred bytes, and it is succeeding in writing all
of the bytes,
NOT just 1 or a smaller number of bytes...
Do you have the latest Net::SSLeay and IO::Socket::SSL installed ?
When using SSL, the syswrite is effectively a call to
Net::SSLeay::write_partial
I've tried judicious use of 'use bytes;' and a few other common
tricks.
use bytes would not make a difference here.
If you'll look at the previous version, before this patch, you'll
see where
we only looked to see if syswrite returned zero or non-zero. Not
the actual
number of bytes.
Which was a bug as syswrite does not guarantee to send all the data
Graham.
If I tweak my private copy of LDAP.pm to assume that
syswrite returned what I was expecting, it works as expected, and
the client
and server successfully communicate for as long as expected.
I've seen this problem with Perl 5.8.8 on Solaris 9, 10, and 32Bit
i386 Redhat Fc5.
If you've seen this problem, or similar problems, or have a strong
clue
as to what might be wrong, I'd appreciate your comments.
Comments welcome,
