Thanks a lot, Herve.
This parameter has been the sollution to my customer issues.
Maybe, the virus or worm that was blocking unirpcd still exists, but now,
with a timeout of 15 seconds, my customer works without a problem.
I consider that is not really a Universe "bug", but a collateral effect of
the Universe way of licences control.
Could it be related with other issues we have?:
Only happens with uvcs remote sessions over internet or VPNs.
Telnet sessions and Terminal Server sessions does'nt drop, but uvcs sessions
drops on client side, meanwhile the server think that the session is still
active.
Regards,
______________________________
Augusto Alonso Alonso
IT Manager
Quiter Servicios Informaticos S.L.
Tel: +34 902 23 33 23
Fax: +34 902 23 42 80
[EMAIL PROTECTED]
www.quiter.com
______________________________
----- Original Message -----
From: "Herve Balestrieri" <[EMAIL PROTECTED]>
To: <u2-users@listserver.u2ug.org>
Sent: Thursday, September 20, 2007 11:46 AM
Subject: Re: [U2] Denial Of Service in UVRPC Universe
Augusto,
The UniRPC protocol hanging when contacted by other network protocols
working on the same TCP port is not exactly what we could name a "bug".
But, for the very true reasons you exposed, enhancements have been made in
UniRPC daemon ("unirpcd" executable) to handle smoothly the case of
unexpected packets causing the daemon to hang, as the UniRPC "applicative"
protocol doesn't know about any of the others high-level protocols such as
"telnet", "ftp", and so on.
A new "unirpcd" parameter = -timeout tt, with "tt" in seconds allows the
UniRPC daemon to handle smoothly this situation.
We recommend the timeout value to be the smallest as your network can
support, because for the duration of the timeout, the UniRPC daemon is
actually hanging, but in a controlled manner, and no more UniRPC
connections can be accepted.
A value of 15 seconds seems generally the largest acceptable value on most
sites, so it could be reduced on purpose.
Note that this parameter exists for UniVerse on Windows platform starting
at release 10.1.23 for releases 10.1.x and 10.2.3 for releases 10.2.x.
The procedure to get it enabled through Windows Services Manager is
documented in the "patchlist" file accessible on :
https://www-927.ibm.com/software/data/u2/support/u2techconnect/downloads/readme/UV-10.1.23.zip
Have to look at "Issue # 9074".
On UNIX platforms, the "-timeout" parameter was altready existing in the
early releases 10.0.x (and UniData 6.0.x), (and it's much easier to have
it
enabled at system command line !).
Hope this will help.
P.S: The answer here is one more reason to attend to U2U in IBM Bedfont
Lakes (Feltham) as my manager suggested !...
Regards,
Herve' Balestrieri
Hi all.
If you do a telnet against any Universe server on port 31438 (I have
tested
it on Universe 10.0.10 in Windows, Universe 10.0.20 in Linux and Universe
10.0.6 in HP-UX), you will have something very similar to a Denial Of
Service on this port 31438:
- all previous UVRPC established sessions keep on working without
problem, but
- any subsequent tries to start new UVRPC sessions, will timeout with
"Error returned from connect = 81015".
The problem desappears when the PC client closes the telnet session. (Or
you
can restart UniVerse or the whole server...)
Could someone tell me if is it a normal behaviour or is it a unirpcd bug?
Is there any way of detect or avoid this kind of sessions?
Could it be the same problem that some viruses (like Blaster) causes on
UVRPC of Universe Servers?
Any help will be apreciated.
Regards,
______________________________
Augusto Alonso Alonso
IT Manager
Quiter Servicios Informaticos S.L.
[EMAIL PROTECTED]
www.quiter.com
______________________________
-------
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
-------
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
