as far as I can see the response is returned from the receiver. It’s a valid soap response with result -2 (which then gets correctly parsed and displayed).
make sure that the receiver is powered on (to simplify the test case)
search for “# Subscribe to Pairing events”
and insert the line
Now I also had the time to run some first tests. The behaviour in my environment is exactly the same.
I am using a Raspberry Pi with Raspian and a wifi connection. Therefore I changed the script in order to retrieve the mac address of the WLAN adapter.
I also had to change the log output to /dev/stdout because the configured log path does not exist in my environment.
My receiver ist powered on and I tried at first the command statusand this is the result:
root@raspi3:~# ./entertain_control.sh log status
Telekom Entertain Control
TMP-Dir=/root/tmp
:49154 -> 192.168.2.104:49152; local MAC=B8:27:EB:BD:3F:9B
/dev/stdout
terminalID='AE0ED9A19F15D65C4C3022EEB9AA0C48'
Receiver is powered ON
ON
Then I tried to power it off with the off command.And this is the result:
root@raspi3:~# ./entertain_control.sh log off
Telekom Entertain Control
TMP-Dir=/root/tmp
:49154 -> 192.168.2.104:49152; local MAC=B8:27:EB:BD:3F:9B
/dev/stdout
terminalID='AE0ED9A19F15D65C4C3022EEB9AA0C48'
Listening on [0.0.0.0] (family 0, port 49154)
Send pairing request (pairingDeviceID='AE0ED9A19F15D65C4C3022EEB9AA0C48', friendlyName='oh-pi', userID='5903A68E8E31CF7EFC9718C635FC037D')
Result=-2
Pairing request failed: -2
Press Power/result>
Send key '0x0100'
Result=
OFF
hmm, the only thing which is static is the user id. I need to play here.
maybe also a setting of the receiver could have an effect? (are there any security related settings). It’s hard to guess what -2 means without any documentation.
thought about the user id topic. So far as I know the receiver has no concepts of users, but is in some way related to your Telekom line, so maybe this is a hash of your Telekom user id?
I can’t remember if I need to enter user credentials while configuring the receiver, the App defiantly requires to login when started first time.
Entering the userID from above into your script, I get
entertain_control.sh log on
Telekom Entertain Control
192.168.0.112:49154 -> 192.168.0.55:49152; local MAC=B8:AE:ED:70:16:25
nc: Address already in use
Send pairing request (pairingDeviceID='ADA7A411BB1FD7A406F0AACE1C840A7E', friendlyName='oh-pi', userID='48089EBF652F2F622E36914997DF03B6')
Result=0
Waiting for Pairing Code...
Unable to get pairingCode!
OFF
The failure is not related to
nc: Address already in use
cause also tried on a different machine without any UPnP services active, so got
Telekom Entertain Control
192.168.0.48:49154 -> 192.168.0.55:49152; local MAC=B8:27:EB:EF:57:43
Listening on [0.0.0.0] (family 0, port 49154)
Send pairing request (pairingDeviceID='E521AD6DD8DF7868FED921B5BF396041', friendlyName='oh-pi', userID='48089EBF652F2F622E36914997DF03B6')
Result=0
Waiting for Pairing Code...
Unable to get pairingCode!
OFF
ok, that‘s a step forward - so we know the app computes the user id from local data. I suppose it‘s a MD5 of the user id you enter to login.
Please post soap_subscribe.xml
all files from the same machine
Do you see the SUBSCRIBE response in the wireshark dump? It supplies the PairingCode - this will be send back asynchronously on a 2nd http channel (local port 49154). That‘s the critical part of the connection setup
produces the same UserID as you discovered in the wireshark trace.
b) When you hard code the userID and pairingCode in the script with thos you find in the wireshark trace. Maybe they are static values. This would not be the nicest setup, but for a one time shot good enough So we would have a running sample and could then work on proper network detection (I already found platform independent code), computing of the userID hash (it’s an MD5) and fixing the SUBSCRIBE for the pairingCode. That was one for the reason to go for a binding and make it more stable.
The nc hack worked for me, but it starts with the fact that you can’t terminate the listener (at least on my Raspberry) even it should by possible. This leaves the nc listener in an undefined state. I could imagine that this is not the best basis to catch the pairingCode returned in that session (returning this in the soap response would be too easy…)