Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

abandoning inactive established connection

abandoning inactive established connection

abandoning inactive established connection


over the last year, since upgrading to eGate 4.5.3 (i'm at right now), i've increasingly seen my eGate applications disconnecting from their partners.  when this happens, the partners call back again shortly thereafter and re-establishes the connections ... but then ... seconds or minutes or hours later ... the process repeats itself.

here's what i see in one of my logs.  "Chrmc" is the name of the partner.  the 'disconnect' event starts at 9:22

<from file ewFromChrmcAdt.log>

09:14:36.836 EWY  D 7912 (logging_compat.c:215): About to write [114] bytes of data to external

09:14:36.868 EWY  D 7912 (logging_compat.c:215): Successfully wrote data to external

09:14:36.899 MSG  D 7912 (eventmngr.cxx:215): DGE_I_LocalSelect(): Local select call emulating a blocking system select().

09:22:12.586 EWY  I 7912 (logging_compat.c:131): Attempting to accept external connection on port: [7001]

09:22:12.618 EWY  I 7912 (logging_compat.c:131): Abandoning inactive established connection & accepted new external connection on port: [7001]

09:22:12.649 EWY  I 7912 (logging_compat.c:131): Setting up external port for nonblocking I/O

09:22:12.696 MSG  D 7912 (eventmngr.cxx:215): DGE_I_LocalSelect(): Local select call emulating a blocking system select().

09:22:12.727 EWY  D 7912 (logging_compat.c:215): Processing read request from external connection

09:22:12.758 EWY  W 7912 (logging_compat.c:131): Find STX char (<0x0b> <>)unsuccessful!

09:22:12.790 EWY  W 7912 (logging_compat.c:131): Error encountered during recv(). Check previous log messages.

09:22:12.821 EWY  W 7912 (logging_compat.c:131): Error detected during recv().

i've tracked down at least one stimulus for this behavior:  port-scanning.  when i use a port-scanner (nmap) to send TCP RSTs to port 7001 (which is the port on which this copy of eGate is listening), i can see (packet analyzer) the host do two things:  (a) send a FIN ACK to the IP address of the machine which sent the TCP RST, and (b) send a FIN ACK to the IP address of Chrmc (my eGate partner).  "/usr/bin/nmap -O foo" (where 'foo' is the name of the box hosting eGate)

[RST is TCP's way of saying "go away, i don't know who you are".  FIN ACK is TCP's way of saying "i've enjoyed our conversation, but i'm saying good bye now" ... they both accomplish the same thing, though the implications are a little different]

i have a suspicion that at least one of the popular Microsoft worms does port-scanning ... and the fairly frequent infections we experience here may be contributing to these errors i'm seeing, as infected machines scan my eGate boxes, sending packets to the eGate ports, whereupon eGate abandons the legitimate connection and tries to service this bogus one.

as i analyze this packet trace, i'm drawing the following conclusions:

-eGate can only handle one conversation per TCP port.  this is normal, for TCP applications.

-if eGate receives a packet ... any packet ... on that TCP port from *anywhere else*, it disconnects the current connection and attempts to establish a connection with this new source.  [kind of like folks who love the 'call waiting' feature on their phone ... except, instead of putting you on hold to talk to the incoming caller, they hang up on you.]  in the dozen years since i first learned how to use a packet analyzer, i've never seen an application do this ... there may be a function for eGate's behavior, of course, but i'm just saying i've never seen an app behave this way.

-as far as i can see, eGate doesn't challenge for authentication, when a connection comes in.  nor does it let me lock down my partners by IP address.  that means ... anyone who can speak the right upper-layer protocol ... HL7 in my case ... can suck data out of my eGate application ...

-everything i've seen so far is clear-text ... no encryption whatsover ... all my precious data ... flying around across the wire in the clear  :(

anyway, this is what i think i'm seeing ... and i'm wanting a sanity check:

*has anyone else seen these 'abandoning inactive connection' msgs in their logs?

*does anyone know of a way to restrict eGate communications to specified partners, either via password or certificate or IP address?

*does anyone know of a way to encrypt eGate's communications?

i have a case open with eGate ... thus far, the tech hasn't been impressed, says that all this behavior is normal and 'by design'.  i have a conference call coming up next week, with second tier support, but in the meantime, i figured i would compare notes with other folks.

insights appreciated


stuart kendrick

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close