If you are using a Workstation version of Windows as your server there are built in limitations to the number of TCP connections you can make from external IP addresses. I believe the figure is 10 - but someone else may be able to clarify the details.
The Windows "Server" editions do not have this limitation. Otherwise: 1. Did you run out of UniVerse licenses? Each session takes a license slot. 2. Are you running with Device Licensing and using incorrect session keys? (> 10 sessions with the same key) 3. Does this only happen if you telnet to 31438 regardless of the number of sessions? The answer to that one is don't telnet - you may be locking the port down by violating the protocol used for sessions. In which case it will wait and wait until it detects a fatal protocol violation and time out (timeout settings are configurable - you can reduce them down). Worth noting there have been at least three major generations of the client and server components since 10.0: 10.1.20+ server and 10.1a/10.1b clients. If you order the LATEST 10.1 you will automatically get the latest clients. 10.2.6 server and 10.2 clients. Whatever the case - upgrading may change this for you and is worthy of a check. The timing on initial handshake may have been tightened up. If not it's always worth asking. I can see why the timeout on an initial handshake failure might be different to an inactivity timeout. Hope this helps .... if your problem is (3) then the timeout and "don't do it" is probably the best I can offer if using the current generation of client and server components don't change the situation. If a hostile application tried to connect there would be authentication violations and protocol violations everywhere and it should disconnect pretty quickly. I suspect a Telnet just sits there as a "dead keyboard" until a timeout or you key something it objects to. In real life of course you would use firewalls to prevent a Denial of Service attack and you would have a rather pointed talk (at least) to anyone in-house trying to hack your systems with a DoS attack. Your server ports (all of them - not just 31438) would have firewall protection and would only be exposed in a limited fashion on an in-house intranet. If someone gets a virus or tries something detectable by your firewall then they would get shut down pretty quickly. If you are using UniObjects on an Internet connection then I am sure you would be behind an n-Tier architected DMZ so would not be exposed to a DoS attack from the outside. Any PC in-house tries it? Then take appropriate action. *** This is key - no server port in a "green zone" (your data and application residency) should ever be exposed to the "red zone" (potentially hostile users) without going through an "amber zone" (a middle-tier firewall and server). This applies to ALL ports and services - not just those used by UniVerse. To expose any host ports to the red zone is a very large security risk *** Background reading on n-Tier deployment is strongly recommended. Hope this helps Regards JayJay -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Augusto Alonso Sent: 19 September 2007 12:42 To: u2-users@listserver.u2ug.org Subject: [U2] Denial Of Service in UVRPC Universe 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/
