-
1
- #1
hi,
over the last year, since upgrading to eGate 4.5.3 (i'm at 4.5.3.4707 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
--sk
stuart kendrick
fhcrc
over the last year, since upgrading to eGate 4.5.3 (i'm at 4.5.3.4707 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
--sk
stuart kendrick
fhcrc
