Communication issue

[ben]

Just got an email from one of our customers some of you may be interested in:

I think I've found a workaround that should resolve my issues. I'm using socat now to act as an intermediate between the GEM and btmon.py:

socat -T15 tcp-listen:5000,reuseaddr,fork tcp:localhost:5001

GEM connects to socat listening on 5000, which in turn funnels the data to port 5001 where btmon.py is listening. If the GEM opens a TCP connection and doesn't send traffic for 15 seconds (it's supposed to send every 10 seconds), then socat will forcefully close the connection.
This allows btmon.py to clean up the connection and be prepared for the next connection.

[ben]

The above solution didn't work too well, so the customer patched btmon itself:





The problem was that whenever it detected incomplete data on the connection and decided to retry, it didn't call accept() again to get a new socket. So it went into an infinite loop trying to read from the old socket, which prevented it from getting new data.

[Grimshad]

I would try this, but I just moved from a linux server to a windows server because i needed to support windows services. I don't see a windows version unfortunately. I may have to throw up a VM just to run that which is not preferable.

I'll try netcat and see if it will work as intended without all the extra features of socat.

EDIT: To use netcat follow these instructions using example ports:

download ncat here: https://nmap.org/ncat/
setup the GEM to send packets to your server on port 5000
setup btmon or whatever script you're using to listen on 5001
run ncat "ncat -lvkw 1 -p 5000 -c "ncat 0.0.0.0 5001"


Simple as that. Here's a breakdown of the command
ncat runs netcat
-l tells it to listen
-v tells it to verbosely display connection information (use to confirm it's working and then you can remove the v after
-k tells it to continue to keep the session alive
-w tells it how long to keep the session alive (in this case 1 second)
-p tells it what port to listen on (in this case 5000, the same port your GEM is sending to)
-c tells it to run a command after it starts listening, the command we want to run is ncat [the ip of the server your script is running on, if it's the same box as you are running ncat then use 127.0.0.1 or localhost] and then [the port] your script is listening on

So the GEM will send the packet to ncat, ncat will then forward it to your script. With the switches in place ncat should continue listening forever and gracefully close connections. Because of this it doesn't matter if the GEM stops sending half way through or even at all, as soon as it fails ncat will either no longer receive packets or will just end the session and wait for another one. So as soon as the GEM is back up, it'll send another packet and ncat will accept it and forward it again with no hiccups.

Note: Still testing, should work though.