T23G won't donwload y000000000044.cfg from Provisioning Server

[rsardinha]

Hi,

I have 84 T23G using the firmware 44.84.0.15. All of then are using DHCP option 66 to inform the provision server as follows:

subnet 10.165.186.0 netmask 255.255.254.0 {
option routers 10.165.186.1;
option subnet-mask 255.255.254.0;
option ntp-servers 10.165.186.5;
option boot-server "http://10.165.186.5/provisioning";
option provision-server-ip "10.165.186.5";

The system generates the files dynamically, checking the apache logs the T23G is not downloading the y000000000044.cfg files as supposed.

ezipbx:/var/log/apache2# cat apache-access.log|grep -i 187.0
10.165.187.0 - - [11/Apr/2019:07:23:52 -0300] "GET /provisioning/805ec04587a3.boot HTTP/1.1" 200 5289 "-" "Yealink SIP-T23G 44.84.0.15 80:5e:c0:45:87:a3"
10.165.187.0 - - [11/Apr/2019:16:08:27 -0300] "GET /provisioning/805ec04587a3.boot HTTP/1.1" 200 5289 "-" "Yealink SIP-T23G 44.84.0.15 80:5e:c0:45:87:a3"

Checking my other telephones I could note that all other than T23G is downloading the model file. But T23 is not.

10.165.186.208 - - [11/Apr/2019:17:09:00 -0300] "GET /provisioning/y000000000038.cfg HTTP/1.1" 200 10676 "-" "Yealink SIP-T38G 38.70.0.185 00:15:65:99:5f:35"
10.165.186.208 - - [11/Apr/2019:17:09:09 -0300] "GET /provisioning/001565995f35.cfg HTTP/1.1" 200 5345 "-" "Yealink SIP-T38G 38.70.0.185 00:15:65:99:5f:35"
10.165.186.208 - - [11/Apr/2019:17:09:14 -0300] "GET /provisioning/yealink/dialplan/1.xml HTTP/1.1" 200 515 "-" "Yealink SIP-T38G 38.70.0.185 00:15:65:99:5f:35"


Looking the T23G log files that is not downloading:
<134>Apr 12 03:08:25 GUI [1150:1150]: ZERO<6+info > 705.135.524:add atp request
<134>Apr 12 03:08:26 GUI [1150:1150]: ZERO<6+info > 706.425.781:process autop msg[ATP_MSG_REQ_START_POWER_ON_UPDATE] wparam[0] lparam[0]
<134>Apr 12 03:08:26 ATP [1174]: ATP <6+info > Try upgrade by dhcp options
<131>Apr 12 03:08:26 ATP [1174]: ATP <3+error > url with auth parameter fail
<131>Apr 12 03:08:26 ATP [1174]: ATP <3+error > Get static config url is empty
<134>Apr 12 03:08:26 ATP [1174]: ATP <6+info > dect dongle state is 0
<134>Apr 12 03:08:26 ATP [1174]: ATP <6+info > Upgrade from mac.boot
<134>Apr 12 03:08:26 ATP [1174]: DURL<6+info > [DCMN]download to file...
<134>Apr 12 03:08:26 ATP [1174]: DURL<6+info > [DCMN]Use new short connect.
<134>Apr 12 03:08:27 ATP [1174]: DURL<6+info > [DCMN]HTTP request use auth = 0.
<134>Apr 12 03:08:27 ATP [1174]: DURL<6+info > [DCMN]ssl cipher:AES:!ADH:!LOW:!EXPORT:!NULL
<134>Apr 12 03:08:27 ATP [1174]: DURL<6+info > [DCMN]I will write to file: /tmp/xxx.cfg
<134>Apr 12 03:08:27 ATP [1174]: DURL<6+info > [DCMN]Request header
<134>Apr 12 03:08:27 ATP [1174]: DURL<6+info > [DCMN]GET /provisioning/805ec04587a3.boot HTTP/1.1
<134>Apr 12 03:08:27 ATP [1174]: DURL<6+info > [DCMN]Host: 10.165.186.5
<134>Apr 12 03:08:27 ATP [1174]: DURL<6+info > [DCMN]...
<134>Apr 12 03:08:27 ATP [1174]: DURL<6+info > [DCMN]Response header
<134>Apr 12 03:08:27 ATP [1174]: DURL<6+info > [DCMN]HTTP/1.1 200 OK
<134>Apr 12 03:08:27 ATP [1174]: DURL<6+info > [DCMN]Date: Thu, 11 Apr 2019 19:08:27 GMT
<134>Apr 12 03:08:27 ATP [1174]: DURL<6+info > [DCMN]Content-Length: 4918
<134>Apr 12 03:08:27 ATP [1174]: DURL<6+info > [DCMN]Recode is 200, Request ok.
<134>Apr 12 03:08:27 ATP [1174]: DURL<6+info > [DCMN]Connect is short Cleanup curl.
<134>Apr 12 03:08:27 ATP [1174]: DURL<6+info > [DCMN]download common success.
<134>Apr 12 03:08:27 ATP [1174]: ATP <6+info > need_cmp_md5=1
<134>Apr 12 03:08:27 ATP [1174]: ATP <6+info > cfg md5 same!
<134>Apr 12 03:08:27 ATP [1174]: ATP <6+info > Extend include files finished, all success, same md5
<134>Apr 12 03:08:27 ATP [1174]: ATP <6+info > parse item finish
<134>Apr 12 03:08:27 ATP [1174]: ATP <6+info > parse item for rom finish
<133>Apr 12 03:08:27 ATP [1174]: ATP <5+notice> sync switch not open!
<134>Apr 12 03:08:27 ATP [1174]: ATP <6+info > send end provision!!
<134>Apr 12 03:08:27 ATP [1174]: ATP <6+info > auto provision result is 0
<134>Apr 12 03:08:27 GUI [1150:1150]: ZERO<6+info > 707.914.337:process autop msg[ATP_MSG_NOTIFY_AUTOP_END] wparam[1] lparam[0]
<134>Apr 12 03:08:27 ATP [1174]: ATP <6+info > dect dongle state is 0
<134>Apr 12 03:08:27 ATP [1174]: ATP <6+info > Update success, and return
<134>Apr 12 03:08:27 ATP [1174]: ATP <6+info > Upgrade by DHCP4 option OK
<134>Apr 12 03:08:27 ATP [1174]: ATP <6+info > Upgrade by dhcp option success !
<134>Apr 12 03:08:27 ATP [1174]: ATP <6+info > Poweron by default order success
<134>Apr 12 03:08:27 ATP [1174]: ATP <6+info > SET ALL_MONITOR
<134>Apr 12 03:08:27 ATP [1174]: ATP <6+info > do the policy again


I'm sending the SYSLOG 6 package downloaded by in my phone:

[jolouis]

Does your system automatically generate .boot files also?

The way provisioning works, as of about version 80 or maybe 81, I can't remember now, is that the phone looks for .boot files first. If it gets an OK response for either [macaddy].boot or y000000000000.boot then it will ONLY read the boot file and process the directives specified in there. The problem is, even if the boot file is empty or contains nothing, the phone still stops its provisioning.

The only time it will fall back to the "old" provisioning style is if neither .boot file exists (and the server returns 404 or some other valid "does not exist" response code).

So you need to either a) Make sure that your server is not generating/serving up any kind of valid response for .boot file requests or B) create a valid .boot file and change your provisioning mechanisms accordingly.

[rsardinha]

That is exactly the problem. The server is generating correctly both files (y00000000044.boot and MAC.boot), but in apache logs I only can see the T23G downloading the MAC.cfg. It did not even try to download the y0000000044.cfg, or it was be displayed in apache logs. The files are working fine, tested with curl.

What I'm not understanding is why T23 is not downloading and T38 is it.

10.165.186.208 - - [11/Apr/2019:17:09:00 -0300] "GET /provisioning/y000000000038.cfg HTTP/1.1" 200 10676 "-" "Yealink SIP-T38G 38.70.0.185 00:15:65:99:5f:35"
10.165.186.208 - - [11/Apr/2019:17:09:09 -0300] "GET /provisioning/001565995f35.cfg HTTP/1.1" 200 5345 "-" "Yealink SIP-T38G 38.70.0.185 00:15:65:99:5f:35"
10.165.186.208 - - [11/Apr/2019:17:09:14 -0300] "GET /provisioning/yealink/dialplan/1.xml HTTP/1.1" 200 515 "-" "Yealink SIP-T38G 38.70.0.185 00:15:65:99:5f:35"



10.165.187.0 - - [11/Apr/2019:07:23:52 -0300] "GET /provisioning/805ec04587a3.boot HTTP/1.1" 200 5289 "-" "Yealink SIP-T23G 44.84.0.15 80:5e:c0:45:87:a3"
10.165.187.0 - - [11/Apr/2019:16:08:27 -0300] "GET /provisioning/805ec04587a3.boot HTTP/1.1" 200 5289 "-" "Yealink SIP-T23G 44.84.0.15 80:5e:c0:45:87:a3"

[rsardinha]

(04-12-2019 01:31 PM)jolouis Wrote:  Does your system automatically generate .boot files also?

The way provisioning works, as of about version 80 or maybe 81, I can't remember now, is that the phone looks for .boot files first. If it gets an OK response for either [macaddy].boot or y000000000000.boot then it will ONLY read the boot file and process the directives specified in there. The problem is, even if the boot file is empty or contains nothing, the phone still stops its provisioning.

The only time it will fall back to the "old" provisioning style is if neither .boot file exists (and the server returns 404 or some other valid "does not exist" response code).

So you need to either a) Make sure that your server is not generating/serving up any kind of valid response for .boot file requests or B) create a valid .boot file and change your provisioning mechanisms accordingly.

You was right. I've found the explanation in Yealink SIP IP Phones Auto Provisioning Guide_V83_10 in page nine.

Thank you.