HSM Gateway - Software caused connection abort: recv failed

[luo...@peacesoft.net]

    Hi jPOS team, 

First of all, thanks for the great work, jPOS is wonderful when dealing with ISO8583 :x 

Second, I am building a HSM  Gateway using jPOS.

Client -----> HSM-REST-API  ----->   HSM-GATEWAY ----->   HSM

- HSM-GATEWAY is configured as a QServer to listen on a specific port, using MuxPool to forward command to selected HSM.

- We used HSM BP-Tools to send command to the port and successfully got response. 

- HSM-REST-API uses FSDChannel to send HSM command to HSM-GATEWAY 

- HSM-REST-API successfully sent commands to HSM IP/PORT

- But when sending the same to HSM-GATEWAY,  we faced "Software caused connection abort: recv failed" when initiating request from HSM-REST-API to HSM-GATEWAY

Here are the logs:

HSM-REST-API

<log realm="com.xxx.resthsm.jpos.HThalesAdaptor" at="2021-11-15T11:03:49.067">
<warn>
channel-sender-hthales-api-send
Software caused connection abort: recv failed
</warn>
</log>
<log realm="com.xxx.resthsm.jpos.HThalesAdaptor" at="2021-11-15T11:03:50.072">
<warn>
checkConnection HThalesAdaptor 2
</warn>
</log>

HSM-GATEWAY

<log realm="server-8001.server.session/127.0.0.1:58602" at="2021-11-15T11:03:50.073">
<session-start>
access granted, ip=127.0.0.1
</session-start>
</log>
<log realm="channel/127.0.0.1:58602" at="2021-11-15T11:04:00.088" lifespan="10013ms">
<receive>
<io-timeout/>
</receive>
</log>

I resume the situation, those folow are OK: - Client -----> HSM-REST-API  ----->   HSM

- BP Tools HSM  ----->   HSM-GATEWAY ----->   HSM

Got "Software caused connection abort: recv failed" when doing::

- Client -----> HSM-REST-API  ----->   HSM-GATEWAY ----->   HSM

- HSM-REST-API caused a connection abort just after trying to send command to HSM-GATEWAY.

- HSM-GATEWAY somewhat grants access for HSM-REST-API, but it seems nothing happened, so it raise io-timeout after 10s (configured value)

Anyone in the group having the same Software caused connection abort: recv failed" issue?

Or is there any tools (debug filter) so we can investigate on socket level of JPOS to troubleshoot the root cause?

Any help is appreciated :x

[Mark Salter]

Sounds like you need to check you are complying with all rules of the gateway 'product', network format, request structure and termination etc.

Start there at least, until you know you need help in jPOS itself to use your target, likely no one here can help.

--
Mark



-------- Original Message --------

--
--
jPOS is licensed under AGPL - free for community usage for your open-source project. Licenses are also available for commercial usage. Please support jPOS, contact: sa...@jpos.org
---
You received this message because you are subscribed to the Google Groups "jPOS Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jpos-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/1dbaa8cb-e47d-40b0-94d3-3ec6d56a322an%40googlegroups.com.

[murtuza chhil]

It looks like you receive a response and the length of your message is more than what you have calculated leaving a few extra bytes in the buffer that treats it as the next message and then you are off forever leading to a point where jpos is waiting to fill up the expected length it thinks and never receives those bytes leading to a timeout.

Make sure your length headers and any headers/trailers are properly accounted for.

-chhil

[murtuza chhil]

Additionally, https://jpos.org/blog/2014/04/you-want-a-timeout/

Our channel that connects to the HSM looks like

```

<?xml version="1.0" ?>

<channel-adaptor name='thales-adaptor-channel'

class="org.jpos.q2.iso.ChannelAdaptor" logger="Q2">

<channel class="org.jpos.iso.channel.ThalesFSDChannel" logger="Q2" realm="thales-adaptor-channel"

packager="org.jpos.iso.packager.FSDPackager">

<property name="schema" value="file:cfg/keyblock/hsm-resp-" />

<property name="host" value="@thales.host@" />

<property name="port" value="@thales.port@" />

<property name="timeout" value="1000000" />

<property name="keep-alive" value="true" />

</channel>

<ignore-iso-exceptions>yes</ignore-iso-exceptions>

<in>thales-send</in>

<out>thales-receive</out>

<reconnect-delay>10000</reconnect-delay>

</channel-adaptor>

```

Our messages uses a header (configured on the HSM too) for key matching in the mux.

We send the NC command as a network level message at regular intervals (less than the timeout value) to keep the line alive.

For debugging we either use a tcp sniffer or extend the channel to hexdump raw data received for length issues. 

-chhil