What does error: <EDAPHTP> failed to init R1SSL mean?

[Bonnie Barthel]

We followed instructions we have on installing a new certificate but are getting the following:

IEF188I PROBLEM PROGRAM ATTRIBUTES ASSIGNED        

(EDA13023) ALL INITIAL SERVERS STARTED.          

DM: error: sched_scan_id=WFRUSS1 is invalid, using default

error: <EDAPHTP> failed to init R1SSL.           

error: <EDAPHTP> cmrpht000001 not HTTP protocol.      

error: <EDAPHTP> cmrpht000003 not HTTP protocol.      

error: <EDAPHTP> cmrpht000005 not HTTP protocol.   

We've always gotten the "DM: error: sched_scan_id=WFRUSS1 is invalid, using default" error so that is not the problem but I've not had any luck finding any information about "error: <EDAPHTP> failed to init R1SSL." Is there a way to enable some debug that might help? Thanks for any assistance!!!

[Bonnie Barthel]

We figured it out... thanks!!!

[Toby Mills]

Hi Bonnie

I'm not an expert on this but I can get you some info that might let you answer your own question.

Basically what the error message seems to be telling you is that something is talking to your server over the port that is listening for HTTP traffic, the traffic coming in is not HTTP.

By default, the HTTP port number is 8121. TCP listens on 8120 (these can be customized of course).

So whatever is connecting to your server using port 8121 (unless you have a custom port which is a good idea), the traffic that comes over the wire doesn't look like HTTP. I notice the log isn't nice enough to tell you what protocol it sees, but likely it's TCP (maybe UDP).

Also, here's a clue I haven't seen documented, but I'll pass it along just from experience. Watch for this sort of string:

cmrpht000001

See that 'ht'? That means this is an HTTP connection. Typically for me, this means that I got on the Web Console using Chrome and I'm using HTTP to navigate around the http://machinename:8121.

That's not real exciting news, but it might help other separate the cmrpip (IP - likely a TCP/IP connection like from the Client talking to the reporting server) from the 'ht' where you as an admin might be poking around.

So where do you look to see your port assignments? That'll be in your odin.cfg under your server. Like if you were on windows, you'd look down here:

D:ibisrv82wfsetcodin.cfg

It's in the same location under the Unix world, just use your forward slashes. Make sure you're under the server and not the client folders (there's an odin.cfg in the clientwfcetc folder too).

You should see the HTTP and TCP listeners spelled out for you here:

;HTTP Listener

NODE = LST_HTTP

BEGIN

 PROTOCOL = HTTP

 PORT = 8121

 CLASS = AGENT

 END

I would not be surprised to find out that somebody using the HTTP port instead of the TCP port. The listener for that is typically 1 number lower than the HTTP port:

;TCP Listener

NODE = LST_TCP

BEGIN

 PROTOCOL = TCP

 PORT = 8120

 CLASS = AGENT

END

See if any of that helps you unravel what's hitting your box using the HTTP port and sending non-http traffic.

Also it's worth considering that this could be some virus scanner your corporate folks are running. They may just see an open port and try to send random things down that pipe.

Hope that helps!

[Toby Mills]

Good deal Bonnie!

Thanks!