Hash match failure; but transmission "succeeds"

You are here

Hash match failure; but transmission "succeeds"

6 posts / 0 new
Last post
jllawler
jllawler's picture
Hash match failure; but transmission "succeeds"

Hi, I've been using the Mendelson OFTP2 product for several years now and am largely satisfied with it.

Recently, however, with a partner we've been exchanging data with for some time (but *have* been having repeated interrupted transmissions with [I may post on that issue later]), have noticed that several transactions have gone through where my Mendelson (they also are using Mendelson OFTP2, I think the most recent community version) thinks the file has transmitted successfully, but when they reply w/ their EERP, I see this message in the detail log:

[Sep 18, 2016 4:47:31 PM] [Session 147423524838915] The computed hash value of the transmitted data differs from the received hash value of the received acknowledgement (EERP/NERP). Generated hash value: [e7 97 58 69 3d eb 85 8a 43 50 16 46 40 fd 85 ad e3 9d 22 8a], received hash value: [26 14 4b 52 91 d6 c8 92 ec a9 74 6c ad 14 48 0f 1d df 41 20]

This is critical! In fact, what I know happened on this last one on Sep 18th is that they received a significantly truncated version of the file, with maybe only 60-80% of the total.

My first main question is, why is my Mendelson treating this transmission as successfully completed when the hashes don't match? Is there a setting I can change to affect this?

If not, I'd submit that this is a bug that I've somehow stumbled onto and should be reviewed ASAP, such that Mendelson properly marks (and runs the 'Command on msg receipt (error)' script, if any) the transmission as failed, as it already does for me in other situations where the transmission is for some reason detected as having been interrupted.

I'll attempt to provide any further data if needed, but was wondering if a developer knew the answer to this problem already, or could take a quick glance at the code to see if there was an oversight that allowed this particular error to slip through without triggering a failure of the whole transmission.

Thanks,

jl

service
service's picture

jllawler,

Thank you for the report. Anyway we don't know so far what the RFC says to this. Did you look at the RFC, is there a hint how to react in this case? We will have a look at the problem.

Meanwhile as workaround: Do you sign and encrypt the data before the transmission? This should prevent any data corruption..

Regards

jllawler
jllawler's picture

Thanks for the reply. I have not examined the RFC, but I can't believe that a failure to match on the hash would not be a serious issue that Mendelson should flag as a failure.

I'm having some stability issues with this partner, as I mentioned, the source of which I have not tracked down, but in the meantime, this additional wrinkle is causing me some extra trouble (and I would assume the same would be true of any other user encountering the same behavior).

service
service's picture

jllawler,

we checked this in the RFC. There is no way defined that the other side could be informed if the EERP hash or the EERP signature do not match - that is why we just display a warning in the log.
If the transaction would be set to "red" on the data sender side it would be still "green" on the EERP sender side which would not be helpful - having two different states of a single transaction is the worst case that could happen. Sending any ESID (e.g. ESID 99) would no help, too as this would just inform the session partner that something happened (it is not even possible to assign it to a transaction as it is finished with a received EERP) and not the transmission partner.

Means this is mainly a protocol related problem. Please use data encryption and this should be no problem - there seems to be no solution for your problem in the OFTP2 protocol.

Regards

jllawler
jllawler's picture

Thanks for looking into the RFC, and the formal method of possibly relaying this issue to the *receiver* of the transaction in this case.

I still can't see what the problem is with just marking it as "red" on the sender side (and also, very importantly, triggering the send error event script, if one is defined) when the sender side *definitively knows* that something seriously wrong happened!

You say that "having two different states of a single transaction is the worst case that could happen" -- I completely disagree with that statement.

The way it is now, we have Mendelson completing a transaction that one side *knows* failed, and just because the protocol may not have any method defined by which the sender can communicate this back to the receiver, why should the sending Mendelson sit there and behave as if everything went okay?

I understand your implication that if I encrypt the data, Mendelson for some reason will not leave the sending transaction green, but for those of us who sometimes want to send unencrypted data, the above scenario is a big problem, I think, and one which would have a pretty simple fix the next time you're making fixes to the product.

Thanks for your time, and I hope you reconsider your position.

John Lawler

service
service's picture

John,

well this is not our position, it is simply not defined in the OFTP2 protocol what should happen if the message receipt signal contains a problem. Same to AS2 and AS4 (ENTSOG, e-SENS - ebMS could deal with this) - the only protocol that could deal with this seems to be RosettaNet.

It makes no sense if one side of the transmission thinks the transmission was ok and the other side thinks it failed. The only relyable workaround is using encryption in OFTP2 to prevent this. If encrypting the data is a problem for you we have no idea how to help you out at this point at the moment.

Regards