These are chat archives for IndySockets/Indy

24th
Oct 2016
marbles99
@marbles99
Oct 24 2016 08:43

@rlebeau Thanks Remy. I have seen Wireshark mentioned many times on forums and help sites. I will install that and see what kind of data I get back. If I know which cipher fails from that, does that then help? Do I include a list of 'good' ciphers in the cipher list? The library idea seem like a good plan and the way forward. I need to get this working asap in the short term, so need to look at some quick fix options which might mean using Synapse in the the interim (which in tests seems to work, but not as easy as Indy to implement). Once it is working again, I can visit the library idea.

On the subject of Indy 10, I have tried it in Seatlle and get the error I mentioned right at the start. Any idea what that could be? "Ordinal 4430 could not be found...."

marbles99
@marbles99
Oct 24 2016 08:57
@ByteJuggler I can't remembet the exact reason why we stuck with Indy 9 for the legacy stuff in D2007. I think it might have been that we have some software that communicates using TCP servers/clients. If my memory serves me correctly, I tried Indy 10 when I reinstalled D2007 on a new PC and it looked like it was going to take some work to convert some of the software to Indy 10. You know what it is like some times, it seemed a quicker option to install Indy 9 so the software would compile. But it is times like this and the problems I have now, that maybe that is false time economy. I probably still don't have the time to go down the Indy 10 on D2007 rout just yet. It would probably mean, for my own peace of mind, cloning my current disk so I have something workable to back to if I need to. Then I need to update and convert all the software. But my priority at the moment is to fix the broken web shop software that is not talking to the API as we are currently unable to automatically update prices and stock. But all these ideas I have taken on board and will return to once I have sorted this other issue. Thanks :)
Walter Prins
@ByteJuggler
Oct 24 2016 08:57
@marbles99 Something to do with the particular version of OpenSSL libraries getting pulled in I think. I seem to vaguely recall having had a similar problem in the past and that it boiled down to finding a suitable of SSL libraries. (As I recall not all the Windows libraries are built equal, sorry if this is very vague, it's been a while.) I think (rummaging around my bookmarks) I might've used the build from here eventually: http://slproweb.com/products/Win32OpenSSL.html I would suggest trying a build from there (assuming I'm right and not leading you down the garden path). It should be enough to put libeay32.dll and ssleay32.dll alongside your service/application executable, but to be sure you're not accidentally loading the wrong version you may want to search the machine and rename and/or disable any other versions of these files before testing. (Use "Everything" from voidtools to quickly find all copies of any named file.)
@marbles99 For what it's worth, I seem to remember that, back in the day we were faced with the upgrade from Indy9 to Indy10 it turned out to be slightly less hassle than initially anticipated -- it initially seemed like a lot of work because the breakages seemed bigger than they turned out to be in the end. (Again it's been a while, and obviously YMMV, I have no idea how complicated your dependencies are...)
Walter Prins
@ByteJuggler
Oct 24 2016 09:04
@marbles99 (Just to caveat about the SSL lib stuff -- memory's quite vague so I have a feeling I might be mixing this up with something else, perhaps some kind of libsvn thing from the past...)
marbles99
@marbles99
Oct 24 2016 09:07
@ByteJuggler Thanks for the quick replies. And for the link to the builds for the SSL libraries. I will take a look at that later today and see if I can see what we need. I am not sure if it will fix the Indy 9 issue as I have used the various versions available from Fulgan which appear to be the 'Indy versions' and there seems to be a point in the library version history where they no longer work with Indy 9 (won't load) but even the latest version there that will load won't connect to out web platform since they removed the cipher. And definitely a good idea to rename all the library DLLs ;) We use them quite extensively for communicating with carrier APIs, Amazon, Web shop platform etc and I wouldn't want to break something that isn't currently broken (except the web platform). I may clone my hard drive this evening and that will give me something easy to go back to. Haven't heard of voidtools, I will take a look. Thanks for your help - appreciated.
Walter Prins
@ByteJuggler
Oct 24 2016 09:08
Yes, just to be clear: I'm not suggesting that those builds will work with Indy9 -- Indy9 requires its own special build as it made changes to the libs. Indy10 should work without problems however.
marbles99
@marbles99
Oct 24 2016 09:09
Okay, thanks :) Hopefully, at least, it might cure that 'Ordinal not found' issue when I try to connect using SSL in Indy 10 in Seattle.
Walter Prins
@ByteJuggler
Oct 24 2016 09:10
Yes... fingers crossed I'm not spouting you know what.
Everything (voidtools): https://www.voidtools.com/ (Can't live without it ;) )
marbles99
@marbles99
Oct 24 2016 09:13
Thanks - I will download it now along with Wireshark. Always good to get recommendation for tools that others find useful. Many thanks.
Remy Lebeau
@rlebeau
Oct 24 2016 16:49
Indy does not import OpenSSL DLL functions by ordinal, it imports by name, and even then it imports dynamically at run-time, not statically and link-time. My guess is that you are using OpenSSL DLLs that are incompatible with each other, rather than with Indy. In any case, OpenSSL DLLs that are known to work with Indy 10 are available at http://indy.fulgan.com/SSL/ and the DLLs that are compatible with Indy 9 are at http://indy.fulgan.com/SSL/Archive/ (the ones prefixed with "indy_")