Has something about the cancel pairing command changed?

[ConnorTroy]

PUTs to /pairing/cancel with the device id/name do not cancel pairing and instead return "INVALID_PARAMETER". Has something changed in the api recently?

[exiva]

What model/firmware?

[ConnorTroy]

P65Q9-H1

FW: 5.10.15.11-1

[exiva]

Hm. That's newer firmware than I'm able to upgrade to. Does /pairing/start give a different response than the docs have? Maybe it's expecting something from that. 🤔

[ConnorTroy]

Nope, everything else is the same from what I've seen so far. I've tried adding the stuff /pairing/start returns in different orders, with and without device id/name to no avail.

[exiva]

Someone with a newer model & firmware may have to sniff out the traffic with charlesproxy. Unfortunately I only have a older set at this point.

[ConnorTroy]

Gotcha gotcha, I think I'll give it a shot. It's looking like the endpoints for the settings have also changed.

[exiva]

There must be some backwards compat because the app still works on the pre-new UI update on the SmartCast only TVs.

[michaelmaston]

+2 on this issue. I have two Vizio's I'm working with, M657-G0 and D32F-G4. Both bought in the last year or two. If I use the curl examples on the page for pairing start and cancel (fixing them up for IP address, fix the DEVICE_ID and DEVICE_NAME params to be identical for both start and cancel, ...) I get a success as expected on the start pairing. If I then just change the URL to be the cancel URL (all else on the curl line remains identical), I get an invalid parameter response back. Here's the JSON that comes back:

{"STATUS": {"RESULT": "INVALID_PARAMETER", "DETAIL": "Invalid parameter"}}

This happens consistently with both models. I have tried just sending one or the other of DEVICE_ID and DEVICE_NAME to see if I could narrow it down but I get the same response either way. As I'm using curl and just updating the address I'm confident in the formatting, ... and since others are seeing the same...

I do use Charles now and then so I will see if I can track down what the apps use when a bad PIN is entered. I assume when they get a failure on the pairing they'll send a cancel pair command.

By the way, many thanks and kudos to you guys for documenting all this info. Works great and has enormously sped up my dev work.

One question I have beyond the pairing cancellation issue is whether the interface that runs on port 9000 works the same as 7345. All my TVs are using 7345 and I don't want to assume if I add the capability to use port 9000 that it will all "just work". How similar are the two?

Mahalo for any help and info!

[exiva]

I do use Charles now and then so I will see if I can track down what the apps use when a bad PIN is entered. I assume when they get a failure on the pairing they'll send a cancel pair command.

Let me know what you find, or open a PR with updated info.

One question I have beyond the pairing cancellation issue is whether the interface that runs on port 9000 works the same as 7345. All my TVs are using 7345 and I don't want to assume if I add the capability to use port 9000 that it will all "just work". How similar are the two?

The port was changed in a software update. The older models with just Chromecast built in still use 9000, the new ones with the menu interface and whatnot use 7345. As far as I know, 9000 isn't open on these models.

[michaelmaston]

So far no success with Charles. When Charles is active, the Smartcast app from Vizio won't find anything on the LAN to connect to. If I try to turn Charles on when I'm already in the app and about to try a pair, I don't see the traffic for the pairing steps. I did try an unofficial app from the iPhone store but it is doing the same cancel operation (and getting a failure response I saw in Charles for invalid parameter). I'm not an expert with Charles so if there is a way for me to get it going before the app starts but allow it to discover the TVs, that would be great.

For the 7345/9000 question, thanks for the info. Where I was going with that is if I connect to a TV using port 9000, is it following all the commands listed here? If it's just a port change and nothing functional. I can try both ports (like the Smartcast app seems to) to support more models.

[ConnorTroy]

I'm also having issues using Charles. It seems like the app doesn't like when the CA isn't the Vizio CA and refuses to send commands after the initial handshake. I could be wrong though since I'm also not too well versed in Charles.

[exiva]

@ConnorTroy have you installed the root CA on your phone & enabled it (if on iOS, im not sure how you'd do it on Android)

[ConnorTroy]

Yeah, I did. And I also tried using the Charles app which confirmed that the certificate was installed correctly but the Smartcast app still refused to connect.

structure just fills up with these empty packets and nothing more

[michaelmaston]

Same here. I've mostly used Charles on my iPhone and have the cert installed, ... Have used it for several snooping expeditions into various app's network traffic. I've seen a few apps like this that are smart enough (or perhaps badly written enough) to have issues when Charles is in the mix. When Charles is on, you just never see devices get enumerated so there is no traffic generated to pair with them.

[exiva]

Maybe I had to disable cert pinning. I vaguely recall using an Android app to do it, but I'm not sure which app I was reversing at the time. I also recall the 's in Charles.🤔 Wish I doc'd that better 😩

[ConnorTroy]

PUT /pairing/cancel

{
  "DEVICE_ID": String,
  "CHALLENGE_TYPE": Integer,
  "RESPONSE_VALUE": "1111",
  "PAIRING_REQ_TOKEN": Integer  
}

Same format as Submit Challenge but with pin "1111"

[michaelmaston]

Excellent! I verified this in my code. I entered the wrong PIN and when I got a failure response from pairing my cancel pairing routine got called with these params and got back a success response now (a successful cancel that is).

I'm pretty sure you can't call cancel if the pairing start call fails as you need the pairing request token to call cancel and that comes from a successful start call response. Pretty sure if you get "BLOCKED" or something similar on the pairing start call you won't get the token and therefore can't cancel. Sending an empty token to cancel in this scenario got me a bad request response so I'm pretty sure this is the way it behaves. The blocked state goes away after a little time so not a big deal.

[ConnorTroy]

@exiva Would you mind checking this works on your device? I didn't see anything to suggest this wouldn't work on older firmware although I didn't really look too hard.

[exiva]

@ConnorTroy response_value in /pairing/cancel is the same pin from submit challenge, or hard coded to 1111 all the time?

[ConnorTroy]

response_value is hard coded to 1111. The rest of the data comes from /pairing/start/

[exiva]

Copy that. It works fine on older smartcast chromecast only firmware. If you want to make a PR changing the docs to the new format, and leaving it for all FW versions I think that's fine.

[exiva]

Thank you @ConnorTroy for finding the issue