ISO Host Emulation with unsuccessful response

[kahwooi]

In test mode, without bank host, all response code is successful.

Is there anyway to make some unsuccessful response?

[juks]

There is testRealLife parameter. If set to one then echo server will randomly close connection abruptly or send "garbage" responses. Made some refactoring changes: there were different levels before, but now there is only one left, so please pull.

[kahwooi]

You mean start it like this:

node socketQueue.js --upstreamHost=localhost --upstreamPort=5000 --listenPort=8080 --testRealLife=1 --vv --echoServerPort=5000

[juks]

For the sake of ease you can run two instances of SQ: one as an echo-server, second to run the test clients.

Server: node socketQueue.js --upstreamHost=localhost --upstreamPort=5555 --listenPort=2014 --vv --echoServerPort=5555 --testRealLife

Clients: node ./socketQueue.js --testClients=5 --testTargetHost=localhost --testTargetPort=2014 --vv

Since there is testRealLife parameter, the server will randomly perform the following cases:

• Sometimes it will close upstream connection with no response
• Sometimes it will send repeating extra messages that make no sense, as client closes connection after it got the first response

So the server side will report like this:

2016-09-16 10:35:39 - info: Echo server random abrupt connection close test 2016-09-16 10:35:39 - info: Upstream <end> 2016-09-16 10:35:39 - info: Upstream <close> 2016-09-16 10:35:39 - info: Dropping all active clients 2016-09-16 10:35:39 - info: Connecting to upstream server localhost:5555

On the client side:

2016-09-16 10:35:38 - info: Test client 4 got correct response 2016-09-16 10:35:39 - info: Test failed. Connection closed with no response. 2016-09-16 10:35:41 - info: Test client 1 got correct response

[juks]

Notice, I made the testRealLife parameter to be boolean, so please update your code again.

[kahwooi]

The testRealLife is to close the response from SocketQueue to the POS HTTP client:

[Bank POS ISO HOST] ------> | SocketQueue | ---xx--> POS HTTP client

I saw it will do an auto reversal after connection closed.

What you have done is very useful, but i think I ask it wrongly, what I meant is bank response for purchase other then 0210.

[juks]

Not sure I got your idea entirely, but the test clients themselves are meant as functional test for the application before new release gets published.

The testRealLife makes tests more realistic and deep: once upon the development process in real production mode there were cases of some events leading this single-thread application to get into stall state: it just stopped to react, and that was a disaster.

It happened exactly after some bank VPN faults, when the remote host just disconnected. So this test mode helps eliminating this sort of application logic problems.

[juks]

Also, some security scanners (e.g. http://www.openvas.org/) that provide the PCI-DSS reports are quite aggressive: they look for open ports then try do detect the type of system behind, then perform some TCP attacks or payload injection. This is why this sort of tests is also important.

SocketQueue is stable in production, being security scanned at the same time. The one who once executed the automated security scans on his network is familiar with the potential headache it may bring for casual services: network applications databases and so on.

[kahwooi]

Thanks for those recommendation. What I wanted is some negative response code. Now all sales response is 0210, I may want to have some other response code.

[juks]

Now I get it. The thing is this part of is quite poor now. Probably need some configuration options and more flexible logic.

[juks]

By the way. The method that handles the purchase operation response is named reply200 and it is located here here https://github.com/juks/SocketQueue/blob/master/lib/testSuite/lib/socketBank.js.