openssh bugs - Dec 2004 - [Bug 953] openssh session hanging - prngd[671]: write() in socket_write() failed: Broken pipe

http://bugzilla.mindrot.org/show_bug.cgi?id=953





------- Additional Comments From stanislaw.walczak at sympatico.ca  2004-12-17
09:16 -------
I run it only for 10 minutes "openssl rand -base64
20480" - did not hang or abort.
Security group said no for prngd 0.9.25 upgrade.
Could you please tell me more about prngd bug ? what the symptoms are ?



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=953





------- Additional Comments From djm at mindrot.org  2004-12-17 11:04 -------
Why don't you ask the prngd developers?



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=953





------- Additional Comments From binder at arago.de  2004-12-17 23:58
-------
>From the ChangeLog:
-- snip --
  When lots of processes query entropy at the same time, the
"fairness"
  change introduced in 0.9.25 could lead to clients being only served with
  a delay.
  Reason: in serverloop.c the next client to serv is "i1" as
determined from
    i1 = (prev_location + i) % max_query_old;
  The client that actually was served however was "i" instead of
"i1".
  If the connection of "i" was not yet ready for "write"
state set after
  getting the entropy, it might block.
  This problem has not been reported by any other user, though it might also
  have occured at other sites.
  Depending on the internal sorting of sockets by fd/slot (number increasing
  in the sequence of accepted connections, closed connections are
  removed from the list), connections might appear locked.
  The entropy served was not provided in the sequence intended. The
  entropy bytes returned via internal buffer however were consistent
  with the connection served (buffer[i]) was filled correctly for
  connection[i]. The problem therefore has no impact on the quality
  of seeding.
-- snap --



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=953





------- Additional Comments From dtucker at zip.com.au  2005-01-06 10:31 -------
Going back to comment #3, when the connection freezes, does netstat show
anything in the send or receive queues for the frozen connection?  (on either
client or server?)



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.