Skip to content

Latest commit

 

History

History
111 lines (79 loc) · 4.17 KB

TROUBLESHOOTING.md

File metadata and controls

111 lines (79 loc) · 4.17 KB

Troubleshooting

Using the diagnostic tool

From your squeezealexa directory,

bin/local_test.py

This assumes you have Python. You can run this more explicitly (e.g. on Windows):

python bin/local_test.py

Note, you may need to specify python3 on systems with both Python 2 and 3 installed.

local_test.py can now diagnose some common connection problems 😄

This should connect with your settings as per settings.py. The latest diagnostics can help you find the root cause of many common connection / certificate problems (but not 100% accurate). Some examples of how this can happen are included in the tests.

The skill is installed, but erroring when invoked

Spoken errors

🆕 Note that in versions 1.2+, squeeze-alexa will attempt to get Alexa to respond in semi-English text / cards. A bit HAL-9000, but it's quicker than checking Cloudwatch logs 😄

You can disable this by changing USE_SPOKEN_ERRORS to False in your settings.

Log-based errors

If everything is installed and the connectivity working, but your Echo is saying "there was a problem with your skill" or similar, try checking the Cloudwatch logs (note there's a delay in getting the latest logs). The squeeze-alexa logs are designed to be quite readable, and should help track down the problem.

If you think it's the speech, try using the test input page on the Amazon dev account portal.

If all else fails, raise an issue here...

Strange IOErrors

If you're getting permission denied IOErrors reported in the logs, make sure you cert file has world read (i.e. run chmod 644 squeeze-alexa.pem)

Checking certificate problems

Examine your local certificate

openssl x509 -in squeeze-alexa.pem -text -noout

If you just want to check the expiry date:

openssl x509 -in squeeze-alexa.pem -enddate -noout

Debugging SSL connection problems

For $MY_HOSTNAME and $MY_PORT you can substitute your home IP / domain name (as used above). It also assumes your client cert is called squeeze-alexa.pem:

openssl s_client -connect $MY_HOSTNAME:$MY_PORT -cert squeeze-alexa.pem | openssl x509

Type Ctrld to exit. If successful, this should give you a PEM-style certificate block with some info about your cert).

That didn't work

OK let's try seeing the problem:

openssl s_client -connect $MY_HOSTNAME:$MY_PORT -cert squeeze-alexa.pem

Note especially towards the end, the Verify return code. This is very helpful getting to the bottom of connection problems.

Connecting

For more debugging:

openssl s_client -connect $MY_HOSTNAME:$MY_PORT -quiet -cert squeeze-alexa.pem

Type status, and if a successful end-to-end connection is made you should see some gibberish that looks a bit like: ...status player_name%3AUpstairs...player_connected%3A1 player_ip%3A192.168.1...

Checking your LMS CLI is actually working

Remotely

Assuming your LMS IP restrictions allow it (check the LMS GUI security settings), and that you are using the standard 9090 CLI port, you can normally telnet from your computer:

    telnet $LMS 9090

where LMS is the address of your Squeezebox server - usually this will be the same as $MY_HOSTNAME (though you might use the local name). Then type status, or some other command, and see if you get an encoded response. If not, you need to fix this first.

From your server

You can also try it directly on the LMS box if you think there's some networking problem. Use netcat (e.g. opkg install netcat) if you have it:

    echo "status" | netcat $LMS 9090

(and try localhost if that's not working. If still no joy, your DNS setup might be confused).

Resilience / performance testing the SSL connection

For the hardcore amongst you, you can check performance (and that there are no TLS bugs / obvious holes):

openssl s_time -bugs -connect $MY_HOSTNAME:$MY_PORT -cert squeeze-alexa.pem -verify 4