Getting auth error with firmware 3.3.6

[roel-v]

I recently updated to firmware 3.3.6 (had to, the real Daikin app wouldn't let me use it otherwise) and now all requests to the URL's documented here give me a 403 error. Had anyone figured out how to authenticate rest calls?

[fredrike]

Which adapter / unit do you have? Do you get auth error even for the "read state" commands?

[roel-v]

Emura unit with 'Wi-Fi Online Controller Daikin BRP069A41' controller unit. I'm getting it on

/aircon/get_control_info /common/basic_info /aircon/get_model_info

So I guess all others are the same, too.

When I try the same url's via https , it times out, so I presume even the new firmware uses just http; . I'm not sure what they're trying to achieve with authentication as I can most likely get the username/pw from the headers easily. But it's a bit of a pita to set up a sniffer in my network configuration so I was hoping someone else has looked into this and that there would be an easy solution.

[JetDot]

Hi, I can confirm that mine is working ok via api commands after the new firmware update (3.3.6) so it maybe related to your specific network setup (my unit is FTXM with the same controller). I don't believe the unit has anything to do with the app and/or the API as all the communication is done via the controller which we have the same.

[roel-v]

OK after further investigation, it seems that it works when you use the IP address in the URL, but not when you use a hostname (this used to work). I have my network set up with DNS so that I don't have to worry about IP addresses changing (my DHCP assigns the same IP address to the same MAC each time, but I find using DNS cleaner). So with this firmware update, you get the 403 when you use a hostname it doesn't know about, but using the IP address works like it always did.

Thanks for checking.

[DrUdoZucker]

Allow me to ask for additional help on this issue. I have successfully used both GET and POSt before upgrading to 3.3.6.

All GET commands are still working, but POST requests fail on some units, see details below.

There are two installations at two different locations. One using 192.168.1.xxx, the other 192.168.2.xxx to access several Daikin A/C. The unist working are FTXG25 from 2014, the units not working are equally FTXG25, but from 2015, 2016 and 2017

Adapters used BRP069A41

For the following tests I have used Google REST ARC

POST http://192.168.1.xxx/aircon/set_control_info with xxx = IP[3] of A/C unit Body pow=0&mode=1&stemp=26&shum=0&f_rate=B&f_dir=3

On those units from 2014 everything works as before, whilst on those using 192.168.1.xxx, I consistently get:

ret=PARAM NG, adv=

P.S.: Power cycling the A/C and their adapters did not help. P.P.S I also tried different POST Bodies without success

PARAM NG indicates, as far as I understand, a wrong or incomplete message, but unfortunately, I have no idea how to find the missing piece.

Do you have any suggestions?

Thanks

READOUTS (for me both look identical, ignoring the different settings and unit specific details)

From A/Cs working

basic info: ret=OK,type=aircon,reg=eu,dst=1,ver=3_3_6,pow=0,err=0,location=0,name=42%c3%bc72%6f, icon=0,method=polling,port=30050,id=Name1,pw=password1,lpw_flag=0,adp_kind=2,pv=2, cpv=2,cpv_minor=00,led=1,en_setzone=1,mac=78restremoved,adp_mode=run,en_hol=0,grp_name=,en_grp=0

get_control_info ret=OK,pow=0,mode=3,adv=,stemp=25.0,shum=0,dt1=25.0,dt2=M,dt3=25.0,dt4=23.0,dt5=23.0,dt7=25.0, dh1=AUTO,dh2=50,dh3=0,dh4=0,dh5=0,dh7=AUTO,dhh=50,b_mode=3,b_stemp=25.0,b_shum=0,alert=255, f_rate=B,f_dir=0,b_f_rate=B,b_f_dir=0,dfr1=5,dfr2=5,dfr3=B,dfr4=A,dfr5=A,dfr6=5,dfr7=5,dfrh=5, dfd1=0,dfd2=0,dfd3=0,dfd4=0,dfd5=0,dfd6=0,dfd7=0,dfdh=0

get_model_info ret=OK,model=0ABA,type=N,pv=2,cpv=2,cpv_minor=00,mid=NA,humd=0,s_humd=0,acled=0,land=0, elec=0,temp=1,temp_rng=0,m_dtct=1,ac_dst=--,disp_dry=0,dmnd=0,en_scdltmr=1,en_frate=1, en_fdir=1,s_fdir=3,en_rtemp_a=0,en_spmode=0,en_ipw_sep=0,en_mompow=0

A/C returning PARAM NG

basic info: ret=OK,type=aircon,reg=eu,dst=1,ver=3_3_6,pow=0,err=0,location=0,name=%53%63%68%6c%61%66%65%6e%5f%45, icon=0,method=polling,port=30053,id=Name2,pw=pasword2,lpw_flag=0,adp_kind=2,pv=2, cpv=2,cpv_minor=00,led=1,en_setzone=1,mac=00restremoved,adp_mode=run,en_hol=0,grp_name=,en_grp=0

get_Control_info ret=OK,pow=0,mode=4,adv=,stemp=20.0,shum=0,dt1=25.0,dt2=M,dt3=25.0,dt4=20.0,dt5=20.0,dt7=25.0, dh1=AUTO,dh2=50,dh3=0,dh4=0,dh5=0,dh7=AUTO,dhh=50,b_mode=4,b_stemp=20.0,b_shum=0,alert=255, f_rate=A,f_dir=0,b_f_rate=A,b_f_dir=0,dfr1=5,dfr2=5,dfr3=5,dfr4=A,dfr5=A,dfr6=5,dfr7=5,dfrh=5, dfd1=0,dfd2=0,dfd3=0,dfd4=0,dfd5=0,dfd6=0,dfd7=0,dfdh=0

get_model_info ret=OK,model=0ABA,type=N,pv=2,cpv=2,cpv_minor=00,mid=NA,humd=0,s_humd=0,acled=0,land=0, elec=0,temp=1,temp_rng=0,m_dtct=1,ac_dst=--,disp_dry=0,dmnd=0,en_scdltmr=1,en_frate=1, en_fdir=1,s_fdir=3,en_rtemp_a=0,en_spmode=0,en_ipw_sep=0,en_mompow=0

[Apollon77]

Only idea would be to intercept the comands the mobile app sends to the devices and compare those

[afdy]

Mine does this too since the upgrade, looks like the web server on the wifi unit no longer accepts the hostname in DNS as a valid host, and instead needs IP address. Accessing via IP address is fine. Phew.

[mrmckeb]

Do these auto-update, out of interest?

[DjMomo]

Hello,

I confirm that doesn't work anymore with firmware 3.3.6 where it's working few weeks ago. Have a look on this tcpdump mobile app commands capture.

tcpdump.zip

Unzip and open with Wireshark

[Apollon77]

Ok, I see the following: all GET calls have a "lpw=" parameter added

[DjMomo]

OK after further investigation, it seems that it works when you use the IP address in the URL, but not when you use a hostname (this used to work). I have my network set up with DNS so that I don't have to worry about IP addresses changing (my DHCP assigns the same IP address to the same MAC each time, but I find using DNS cleaner). So with this firmware update, you get the 403 when you use a hostname it doesn't know about, but using the IP address works like it always did.

Sam problem for me. Local DNS was the problem. If I use IP it works again.

Ok, I see the following: all GET calls have a "lpw=" parameter added

But it's works with or without it for me.

[ghost]

I connected to the units from external network via modem port forwarding, and this mode also seems to no longer work. Now it is possible to call the units only from the internal network (or in the VPN) directly with their ip. No one has a solution?

I'm afraid Daikin can completely block the API in a future firmware update!

[P9999g]

Hi, I have a similar problem since the update to 3.3.6 when I put: http://192.168.0.107/aircon/set_control_info?pow=1&mode=1&stemp=26&shum=0&f_rate=B&f_dir=3 in any Browser it works as before with version 3.3.1 But if I send with a terminal or Packet Sender: GET /aircon/set_control_info?pow=1&mode=1&stemp=26&shum=0&f_rate=B&f_dir=3 HTTP/1.1\r\n\r\n the Daikin return: HTTP/1.0 403 HTTP_FORBIDDEN\r\nContent-Length: 0\r\nContent-Type: text/plain\r\n\r\n this was with 3.3.1. not, all was working. My problem is that I must send the string via tcp client. I use an AMX Controller for my home automations and on this controller its only possible to open a TCP-Client. I tried to copy the whole string from the browser and send this via TCP-Client same result. Have anybody an idea?

[roel-v]

Try sending a complete, valid HTTP 1.1 request, i.e. with a Host header etc.

[P9999g]

I tried this: "GET /aircon/set_control_info?pow=0&mode=1&stemp=26&shum=0&f_rate=B&f_dir=3 HTTP/1.1\r\nHost: 192.168.0.85\r\nUpgrade-Insecure-Requests: 1\r\nAccept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8\r\nUser-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_4) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.1 Safari/605.1.15\r\nAccept-Language: de-at\r\nAccept-Encoding: gzip, deflate\r\nConnection: keep-alive\r\n\r\n" its copied from the Safari, same problem, I tried also a copy from the firefox!

[ghost]

I found in a forum the solution to the 403 error problem when calling via dns or any other system that is not the internal ip of the daikin controller. The Daikin web service requires the HTTP header "Host" be set with the internal ip of the controller. For example: Host > 192.168.1.78 Once added this, the expected data came back from the Daikin controller even if calling via dns.

Original post link: https://forums.whirlpool.net.au/archive/2768285

[fpalab]

I have the adapter BRP069B42 (which should be an updated version of the A model) running FW 1.2.51 connected to a Daikin FVXS-F AC from 2013.

While testing the php web app, I got a lot of 403's and seldom correct responses. What fixed it, was to drop the php function file_get_contents and directly use sockets instead (socket_create, socket_connect, etc.) . The protocol only requires the standard GET line (with HTTP 1.0) and the additional Host header.

Why file_get_contents fails is still a mystery to me, since it should do exactly the same thing. Maybe it's a timing issue or some kind of header inserted by Apache.