step 3 timing out/connection closed

[salvesen]

Not sure what is going on today. This has been working for weeks for me now and this morning I am just getting timeouts on step 1. I tried adding the optional hint, no change. Could this be due to the WAF? I do not have a fix for this in my code, but since https://auth.tesla.com/oauth2/v3/authorize is just timing out when trying to download data I have no idea how to bypass it. Any ideas?

Exception getLoginPageHTML: System.Net.WebException: The operation has timed out

[salvesen]

While testing I can see that I sometime manage to download step 1 but then it fails on step 2. Not sure what is going on here..

[corsair]

I am also now experiencing this issue on Teslascope and no accounts are able to authenticate. It appears to be failing regardless of the codebase (tried PHP and Python).

This seems troubling. Is this impacting the main repository? @timdorr

[nilathedragon]

It seems if you send no headers at all, it suddenly works. I now only send the User-Agent in my script and no additional headers.:

headers = { "User-Agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0.3 Safari/605.1.15" }

[salvesen]

Not sure what you mean here, step 1 does not require any headers?

[nilathedragon]

I was going from this script https://github.com/enode-engineering/tesla-oauth2 where there are headers being sent in every step... Thats what did the trick for me

[salvesen]

Still struggeling here, today step 1 & 2 looks to be ok. But on step 3 when getting the code the redirect message has changed. There is no more "code" in it.

redirect_uri=https://auth.tesla.com/void/callback&response_type=code&scope=openid%20email%20offline_access&state=123

what the fudge is going on..

[salvesen]

My bad, this was due to a missing header on my side when troubleshooting. But today, step 3 is timing out. Everything else before this is ok and is done as per https://tesla-api.timdorr.com/api-basics/authentication#refreshing-an-access-token
I also tested my "old" code before i started to work on this and the same issue. timeouts move to step 3.

Anyone have any idea on what is going on? @timdorr ?

[salvesen]

Exception exchangeAuthCode: System.Net.WebException: The underlying connection was closed: A connection that was expected to be kept alive was closed by the server. ---> System.IO.IOException: Unable to read data from the transport connection: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. ---> System.Net.Sockets.SocketException: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond

[tomhollander]

Yes this is what I'm seeing too. Very occasionally it works, which only serves to make me wonder what I did right, but then it goes right back to timing out again.

[chrm-software]

Same here. Step 3 just timed out. No error message, no answer at all.
I'm wondering, what kind of API are services like TeslaFi using? They seems to have a working solution.

[salvesen]

yeah this is def very wierd. Maybe it is due to all the traffic tesla is getting now as 3rd party apps have resolved their auth? I dont know, but it is really anyoing.

[fkhera]

I am timing out getting the access token now so appears Tesla changed something yesterday times out at at auth page login.
I have not removed headers yet hoping to avoid code changes to deploy :
https://github.com/fkhera/powerwallCloud/blob/master/powerwallBackup.py#L252

[fkhera]

I ended up just stripping headers, cause its 11pm Sunday night and tomorrow I have to ensure my powerwalls as well as others are programmed correctly. Really hoping this is the final fix. If they block no header requests, let us know, cause then I will have to re-update the code as well.

Latest commit to patch:
fkhera/powerwallCloud@393e1fc

[salvesen]

I just updated my library - I think it's working again.
It seems that most/all of the calls now expect:

Accept: application/json
Accept-Encoding: gzip, deflate, br
Connection: keep-alive

Just tested it and it is working! unfortunately for me my lib is not. Tried adding all of that to my "step1" and the html page that is returned is just jibberish. Parts of it:
▼ í]ÝoãHr⌂÷_ÑÇ♣▬▲s↕%Ù'g,%¶Ç³3;▼;·zÙÝìå ´É-H<▼Z6i?½↓ yI^♫ÈSroI?C'╬ yHz6⌂Jvƒä?ÿ!UÝMS▼²lJzÃb³?G">ÉÓp¿¥.mma·YPJ>å_¥^Ì↔↕ð"'"M♣¡¶xÉSÛe±àÉÐH" ↔↑¤]p"dN'ò|h∟EaÂÃ"¾┼¡↓ÄVgC#áo"▬♫ñaÎf§-/è>♥z¶♣s-x§~'ÑÓã!w¦ü¾íÆQÀ╬V?AÈ Á8÷øÅ<S"☻Í.ç$îÐáçzÍ©<¹O¼ÐK<æSa3▼ØÜ'☺{ë♣i°hH♣?å↓ƒ◄♀Û÷IÆTN¼dhGç<-·ö}/o'~ûCC$->↨.ç Þ?ùdh´D☻:Ø-[^Ö4J\▬ÐÓ(sTp®┼Þ?8àZ-♠ÍÉ♥P8¾ys┼ZÏ>Ó♂×♂" \rÒ­}aÇÞ<!"¶↨}ÏD˳♠!Lw& iÎ"1Úo©þ£"®Ê4u⌂4wmJgìo©Vƒ"QhCûî¤ÓéwºƒSnq>YÖiwÏ6Ð☺WI♥0♣"9Îñ9∟<÷♦~♠?·?GY¼Ð&û<b♫wOûd'┼vâEá6Ç®÷È×'!l>÷/▼±xö"r8ùðÃrÃö½╬[ºã9<Á?"S.È?|ý.¿2%b²?-çq4←Ì»-¤?∟↑d∟Gñ♂um;ëó3$úù}I♂Â`

How can we keep up with this, its so unstable.

[tomhollander]

@salvesen That'll be the gzipped response. It's not enough to add the headers; you also need to decode the payload. Hopefully your chosen platform can do this for you if you choose the right options.

[chrm-software]

For me it works with "Accept-Encoding: deflate, br" too. So no need to accept gzipped response.

[salvesen]

@salvesen That'll be the gzipped response. It's not enough to add the headers; you also need to decode the payload. Hopefully your chosen platform can do this for you if you choose the right options.

ah that makes sense! Got it decompressed now and looks good. But still stuck on step 3. Ill have a look there again :)

[salvesen]

back up and running thanks to @tomhollander tips! Thanks again!

[fkhera]

So far the stripped headers is still working, I guess we keep with it for a while

[dewoodruff]

Thanks for sharing your experience. I wrote an app in nodejs and have also been getting timeouts the last few days. I'm finding that I'm able to auth once, then I get a timeout. If I change ANY header value, even just the UA to a different UA, I'm able to immediately authenticate again. Maybe they're rate limiting auth requests base on fixed header values.

[fkhera]

MAke sure to remove usage agent from headers

…

On Fri, Feb 26, 2021 at 12:39 PM salvesen ***@***.***> wrote: Same for me again... Worked fine for four days but now: 400 Bad Request at this step or timeout with empty headers. yeah timing out again here to. Now on step1 again. Also tried the @tomhollander <https://github.com/tomhollander> example. and it is also failing :/ — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#320 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABU4JYA2RZZDR5BJWKIL5XLTA72I3ANCNFSM4X5TJ3OA> .

[fkhera]

So far do we thinking removing the headers is best way to fix this issue ? I have to fix 2 customers devices cause they do not give remote access rasberry pi

[tomhollander]

Not so much removing headers, but having (only) the expected headers.

[pgalbavy]

Long time listener, first time caller... :-)

I have been hitting a timeout on the .../token call since doing this. I have had problems sometimes when the JSON body is wrong, but other times even sending no body and it just times out. Looks like the WAF is expecting very specific things. I have tried all the above header adds and removes suggested, no consistent behaviour. I have also tried two different source IPs but only have my own account to test with (which works fine on web and real app).

Is there any reliance on earlier stages (session cookie etc.) working or is it purely the code and code_verifier?

Last replies here over a week ago, so just wondering if it's still working for others properly?

Update: On a hunch I tried forcing TLS1.3 and got a different response. Going to now try reworking my real test
Update 2: Actually, it seems to be something else, but at least now I'm getting an "invalid code_verifier" error
Update 3: Datapoint, explicitly setting the SNI to auth.tesla.com seems to do something, not relying on the underlying API (I'm using node-red)

[pgalbavy]

OK, I rewrote my impression of the code based on @timdorr docs in golang and it worked without issues. Must be somethinig Node Red is doing inside it's http request nodes.

[pgalbavy]

... and then today, while trying to clear up my hacky test code it seems they now need user-agent headers. Works yesterday, 403 Forbidden today. Sigh.

[salvesen]

@pgalbavy just tested mine and previously mentioned lib. Working as it should, no user-agent headers.

[dewoodruff]

My hypothesis is requests with the same exact headers from the same source IP are rate limited. Oauth isn't supposed to be used to reauthenticate every single request for data. You're supposed to auth, grab the access keys once, and then reuse them for a long time. I suspect they're rate limiting to prevent people following bad authentication practices.

When you get an error, try changing any header value, like user agent. Does it immediately start working again?

[pgalbavy]

You are probably right. I have not yet started cacheing the bearer token etc. as I am still cleaning the code - but I guess adding some randomisation to the user-agent header may help if your theory proves right.

[PatrickSchmidtSE]

"Last replies here over a week ago, so just wondering if it's still working for others properly?"
It worked over 1 week with me, but now since 2 hours everything is back to not working again :/ frustrating!!

[salvesen]

Just tested mine now, works fine for now.

[salvesen]

Also tested @tomhollander liberary now, works also. Maybe this can help you out? https://github.com/tomhollander/TeslaAuth

[PatrickSchmidtSE]

Yeah was a one time error, sorry to make trouble :)

[salvesen]

@SearchForTheCode glad to hear it:)