2.1.1p2 HP-UX 11 timing error

[Marquess, Steve Mr JMLFDC]

Kevin:

You are right about the patch, read() is indeed returning EWOULDBLOCK but HP
has a June 14, 2000 cumulative patch (s700_800 11.00 cumulative ARPA
Transport patch) that supposedly fixes the EWOULDBLOCK-instead-of-EAGAIN
problem (PHNE_21767, either obsoleting two earlier patches or "Not yet HP
recommended" depending on how you query).  I'll try it out on an in-house
system.  Unfortunately it will take us quite awhile to run this substantial
looking patch through our QA process and push it to our deployed systems
worldwide (auto-reboot in particular is a problem), so in the meantime I'll
still need to hack atomicio.c locally.  Good tip, though, thanks.

BTW I'm seeing the same General Commercial Security error you've reported
(HP-UX B.11.0, same pam.conf).

-Steve M.

-----Original Message-----
From: Kevin Steves [mailto:stevesk at sweden.hp.com]
Sent: Saturday, July 08, 2000 11:38 AM
To: Marquess, Steve Mr JMLFDC
Cc: openssh-unix-dev at mindrot.org
Subject: Re: 2.1.1p2 HP-UX 11 timing error


Hi,

On Thu, 6 Jul 2000, Marquess, Steve Mr JMLFDC wrote:
: FYI in order to get 2.1.1p2 to work on my HP-UX 11.0 systems I had to
patch
: atomicio.c for EWOULDBLOCK (HP read() does not give the POSIX return
code).
: The new atomicio() is a clean fix for this timing problem; all it needs
now
: is this one little tweak.
: 
	.
	.
	<<snip>>
	.
	.

Which problem(s) does this fix?  If read() is really returning
EWOULDBLOCK instead of EAGAIN for POSIX non-blocking IO we should file a
defect and get it fixed.  There was an old problem with send() returning
EWOULDBLOCK that was fixed over a year ago.  Which ARPA transport patch
do you have installed?  This was the defect information in the patch
README:

               ( SR number:   [5003446658/STARS-ACTIVE/English]  ; Defect:
JAGaa45906 )
        send() when called non-blocking returns EWOULDBLOCK
        rather than EAGAIN.

I have a test program and I don't see EWOULDBLOCK for sockets.