Custom Akamai stream target failing after WSE update

Wowza Streaming Engine
1

We have a server on which our custom Akamai stream target has stopped working after updating to WSE 4.7.2.02, and still has the problem after trying bumping that to 4.7.3.

Our custom targets seem to be set up properly and my stream is ingested and transcoded/transrated, etc. I can test the transcoded feeds on the server with the test player and they look/sound ok.

All of our stream targets eventually error out with a stream of messages in the error log like:

ERROR   server  comment 2017-11-25      00:44:36        -       -       -       -       -       58.586  -       -       -       -       -       -       -       -       HTTPSByteWriter.handleEndOfStream: This engine was forced to close inbound, without having received the proper SSL/TLS close notification message from the peer, due to end of stream : javax.net.ssl.SSLException: Inbound closed before receiving peer's close_notify: possible truncation attack?|at sun.security.ssl.Alerts.getSSLException(Alerts.java:208)|at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1666)|at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1634)|at sun.security.ssl.SSLEngineImpl.closeInbound(SSLEngineImpl.java:1561)|at com.wowza.io.HTTPSByteWriter.c(HTTPSByteWriter.java:664)|
WARN    server  comment 2017-11-25      00:44:39        -       -       -       -       -       61.524  -       -       -       -       -       -       -       -       HTTPSByteWriter.writeDirect[https://<url>.i.akamaientrypoint.net:443/<cpid>/stream_480p/91bb38es/00000000/media_1.ts] try 1 failed, 24 retries left;

The first server I updated never showed any problems like this, and is able to push through Akamai happily. I’m close to wiping out the installation entirely and starting over, but I’m afraid there’s something external I’m missing and the clean install won’t solve my problem.

I know this isn’t much to go on, info-wise, but I figured maybe somebody would have seen that error message before and be able to give some idea of that they found.

2

Of course right after I post here, on of my dev buddies points out we’d run into and solved this in another instance, just so long ago I forgot about it.

The issue for us was that resolv.conf looked like this:

ourdomain.com
nameserver 10.0.80.11
nameserver 10.0.80.12

Which seemed ok for any other purpose, but if I were to ping the akamai entry point from the trace above, I’d get:

ping p-ep254759.prestosports01.i.akamaientrypoint.net PING p-ep254759.prestosports01.i.akamaientrypoint.net.prestosports.c (67.228.165.35) 56(84) bytes of data. 64 bytes from prestosports.com (67.228.165.35): icmp_seq=1 ttl=59 time=0.959 ms

As you can see, it’s adding a “prestosports.com” at the end for some reason in name resolution.

I made it go away at the system level by changing resolv.conf to:

search .
nameserver 10.0.80.11
nameserver 10.0.80.12

Now the crazy entry point url (handled internally by Akamai) doesn’t resolve erroneously to our domain, and the push targets are working again.

I’m not 100% satisfied with the solution,

a) because it’s changing a system-level thing, so I don’t know for sure there’s not going to be some downstream blowback

b) I don’t know why the behavior for that would have changed from the Wowza releases.

That said, I’m at least up and running again in this test environment and we can work on getting the WSE update rolled out. Would love any community/Wowza feedback that might explain the change and/or a more elegant way to solve it.

For reference, the versions are now Wowza 4.7.3 and CentOS 6.6.