Yealink firmware 54.81

[davidiwharper]

Hi Selintra

Just a quick FYI that I upgraded a Yealink T40P to firmware release T40-54.81.0.70 and it broke auto provisioning (including when I manually inputted the URL). I'm suspecting this was the phone and not SAIL, because downgrading back to the latest 54.80 series worked as expected.

If you would like any particular logs to take a look at please let me know.

Cheers
David

[sysadmin]

Thanks David

We'll speak to Yealink and I'll run some sims on it.   The new work we're currently doing on provisioning is a bit more tolerant of Yealink phones and their vagaries.  They seem to be the least structured when it comes to following any particular internal standards and we often see unexpected results both with new firmware and new phone models. 
 

[Del]

Is there a workaround for V81 firmware on the Yealink's?
I'm experiencing the same issue on 5.0.0-32 which as far as I can see is the still the latest public SAIL deb.
As David mentioned dropping the phones down to V80 fixes it and brings back auto/manual provisioning.

[sysadmin]

We'll need to see the output from syslog during a provisioning attempt.   I'd also like to see the URI which is coming off the Yealink phne please

[Del]

We'll need to see the output from syslog during a provisioning attempt.   I'd also like to see the URI which is coming off the Yealink phone please

The following is the syslog when a factory reset T19 E2 starts up and tries to auto provision.
Using latest firmware now v53.82.0.20 (same with 53.81.0.110, 53.81.0.70, 53.81.0.70 & 53.81.0.25)
Phone doesn't provision and stays at defaults.

Code Select Expand

Sep 15 23:40:50 sarkpbx responder: IN -------------------------------------------------------{
Sep 15 23:40:50 sarkpbx responder: SUBSCRIBE sip:MAC001565d2ab88@224.0.1.75 SIP/2.0
Sep 15 23:40:50 sarkpbx responder: Via: SIP/2.0/UDP 192.168.1.204:5059;branch=z9hG4bK1505515250
Sep 15 23:40:50 sarkpbx responder: From: <sip:MAC001565d2ab88@224.0.1.75>;tag=1505515250
Sep 15 23:40:50 sarkpbx responder: To: <sip:MAC001565d2ab88@224.0.1.75>
Sep 15 23:40:50 sarkpbx responder: Call-ID: 1505515250@192.168.1.204
Sep 15 23:40:50 sarkpbx responder: CSeq: 1 SUBSCRIBE
Sep 15 23:40:50 sarkpbx responder: Contact: <sip:MAC001565d2ab88@192.168.1.204:5059>
Sep 15 23:40:50 sarkpbx responder: Max-Forwards: 70
Sep 15 23:40:50 sarkpbx responder: User-Agent: Yealink SIP-T19P_E2 53.82.0.20
Sep 15 23:40:50 sarkpbx responder: Expires: 0
Sep 15 23:40:50 sarkpbx responder: Event: ua-profile;profile-type="device";vendor="yealink";model="SIP-T19P_E2";version="53.82.0.20"
Sep 15 23:40:50 sarkpbx responder: Accept: application/url
Sep 15 23:40:50 sarkpbx responder: Content-Length: 0
Sep 15 23:40:50 sarkpbx responder: ----------------------------------------------------------}
Sep 15 23:40:50 sarkpbx responder: Harvested MAC address 001565d2ab88
Sep 15 23:40:50 sarkpbx responder: Harvested Vendor yealink
Sep 15 23:40:50 sarkpbx responder: Harvested Model SIP-T19P_E2
Sep 15 23:40:50 sarkpbx responder: OUT (-> 192.168.1.204:5059) -------------------------------{
Sep 15 23:40:50 sarkpbx responder: SIP/2.0 200 OK
Sep 15 23:40:51 sarkpbx responder: Via: SIP/2.0/UDP 192.168.1.204:5059;branch=z9hG4bK1505515250
Sep 15 23:40:51 sarkpbx responder: From: <sip:MAC001565d2ab88@224.0.1.75>;tag=1505515250
Sep 15 23:40:51 sarkpbx responder: To: <sip:MAC001565d2ab88@224.0.1.75>
Sep 15 23:40:51 sarkpbx responder: Call-ID: 1505515250@192.168.1.204
Sep 15 23:40:51 sarkpbx responder: CSeq: 1 SUBSCRIBE
Sep 15 23:40:51 sarkpbx responder: Expires: 0
Sep 15 23:40:51 sarkpbx responder: Contact: <sip:224.0.1.75:5060>
Sep 15 23:40:51 sarkpbx responder: User-Agent: responder
Sep 15 23:40:51 sarkpbx responder: Content-Length: 0
Sep 15 23:40:51 sarkpbx responder: ----------------------------------------------------------}
Sep 15 23:40:51 sarkpbx responder: OUT-------------------------------------------------------{
Sep 15 23:40:51 sarkpbx responder: NOTIFY 192.168.1.204:5059 SIP/2.0
Sep 15 23:40:51 sarkpbx responder: Via: SIP/2.0/UDP 224.0.1.75:5060;rport
Sep 15 23:40:51 sarkpbx responder: Max-Forwards: 25
Sep 15 23:40:51 sarkpbx responder: Contact: <sip:224.0.1.75:5060>
Sep 15 23:40:51 sarkpbx responder: To: <sip:MAC001565d2ab88@224.0.1.75>;tag=1505515250
Sep 15 23:40:51 sarkpbx responder: From: <sip:MAC001565d2ab88@224.0.1.75>;tag=59bc56f3-1656616a
Sep 15 23:40:51 sarkpbx responder: Call-ID: 1505515250@192.168.1.204
Sep 15 23:40:51 sarkpbx responder: CSeq: 3 NOTIFY
Sep 15 23:40:51 sarkpbx responder: Content-Type: application/url
Sep 15 23:40:51 sarkpbx responder: User-Agent: responder
Sep 15 23:40:51 sarkpbx responder: Subscription-State: terminated;reason=timeout
Sep 15 23:40:51 sarkpbx responder: Event: ua-profile
Sep 15 23:40:51 sarkpbx responder: Content-Length: 33
Sep 15 23:40:51 sarkpbx responder:
Sep 15 23:40:51 sarkpbx responder: http://192.168.1.200/provisioning
Sep 15 23:40:51 sarkpbx responder: ----------------------------------------------------------}
Sep 15 23:40:51 sarkpbx apache2: 192.168.1.204 processing URI /provisioning/001565d2ab88.boot
Sep 15 23:40:51 sarkpbx apache2: 192.168.1.204 Found MAC 001565d2ab88
Sep 15 23:40:51 sarkpbx apache2: 192.168.1.204 sending config 001565d2ab88.boot


Rolling the phone back to 53.80.0.130 or older firmware fixes it and auto provision works fine.

Code Select Expand

Sep 15 23:59:35 sarkpbx responder: IN -------------------------------------------------------{
Sep 15 23:59:35 sarkpbx responder: SUBSCRIBE sip:MAC001565d2ab88@224.0.1.75 SIP/2.0
Sep 15 23:59:35 sarkpbx responder: Via: SIP/2.0/UDP 192.168.1.204:5059;branch=z9hG4bK1466380822
Sep 15 23:59:35 sarkpbx responder: From: <sip:MAC001565d2ab88@224.0.1.75>;tag=1466380822
Sep 15 23:59:35 sarkpbx responder: To: <sip:MAC001565d2ab88@224.0.1.75>
Sep 15 23:59:35 sarkpbx responder: Call-ID: 1466380822@192.168.1.204
Sep 15 23:59:35 sarkpbx responder: CSeq: 1 SUBSCRIBE
Sep 15 23:59:35 sarkpbx responder: Contact: <sip:MAC001565d2ab88@192.168.1.204:5059>
Sep 15 23:59:35 sarkpbx responder: Max-Forwards: 70
Sep 15 23:59:35 sarkpbx responder: User-Agent: Yealink SIP-T19P_E2 53.80.0.130
Sep 15 23:59:35 sarkpbx responder: Expires: 0
Sep 15 23:59:35 sarkpbx responder: Event: ua-profile;profile-type="device";vendor="yealink";model="SIP-T19P_E2";version="53.80.0.130"
Sep 15 23:59:35 sarkpbx responder: Accept: application/url
Sep 15 23:59:35 sarkpbx responder: Content-Length: 0
Sep 15 23:59:35 sarkpbx responder: ----------------------------------------------------------}
Sep 15 23:59:35 sarkpbx responder: Harvested MAC address 001565d2ab88
Sep 15 23:59:35 sarkpbx responder: Harvested Vendor yealink
Sep 15 23:59:35 sarkpbx responder: Harvested Model SIP-T19P_E2
Sep 15 23:59:35 sarkpbx responder: OUT (-> 192.168.1.204:5059) -------------------------------{
Sep 15 23:59:35 sarkpbx responder: SIP/2.0 200 OK
Sep 15 23:59:35 sarkpbx responder: Via: SIP/2.0/UDP 192.168.1.204:5059;branch=z9hG4bK1466380822
Sep 15 23:59:35 sarkpbx responder: From: <sip:MAC001565d2ab88@224.0.1.75>;tag=1466380822
Sep 15 23:59:35 sarkpbx responder: To: <sip:MAC001565d2ab88@224.0.1.75>
Sep 15 23:59:35 sarkpbx responder: Call-ID: 1466380822@192.168.1.204
Sep 15 23:59:35 sarkpbx responder: CSeq: 1 SUBSCRIBE
Sep 15 23:59:35 sarkpbx responder: Expires: 0
Sep 15 23:59:35 sarkpbx responder: Contact: <sip:224.0.1.75:5060>
Sep 15 23:59:35 sarkpbx responder: User-Agent: responder
Sep 15 23:59:35 sarkpbx responder: Content-Length: 0
Sep 15 23:59:35 sarkpbx responder: ----------------------------------------------------------}
Sep 15 23:59:35 sarkpbx responder: OUT-------------------------------------------------------{
Sep 15 23:59:35 sarkpbx responder: NOTIFY 192.168.1.204:5059 SIP/2.0
Sep 15 23:59:35 sarkpbx responder: Via: SIP/2.0/UDP 224.0.1.75:5060;rport
Sep 15 23:59:35 sarkpbx responder: Max-Forwards: 25
Sep 15 23:59:35 sarkpbx responder: Contact: <sip:224.0.1.75:5060>
Sep 15 23:59:35 sarkpbx responder: To: <sip:MAC001565d2ab88@224.0.1.75>;tag=1466380822
Sep 15 23:59:35 sarkpbx responder: From: <sip:MAC001565d2ab88@224.0.1.75>;tag=59bc5b57-39a1f363
Sep 15 23:59:35 sarkpbx responder: Call-ID: 1466380822@192.168.1.204
Sep 15 23:59:35 sarkpbx responder: CSeq: 3 NOTIFY
Sep 15 23:59:35 sarkpbx responder: Content-Type: application/url
Sep 15 23:59:35 sarkpbx responder: User-Agent: responder
Sep 15 23:59:35 sarkpbx responder: Subscription-State: terminated;reason=timeout
Sep 15 23:59:35 sarkpbx responder: Event: ua-profile
Sep 15 23:59:35 sarkpbx responder: Content-Length: 33
Sep 15 23:59:35 sarkpbx responder:
Sep 15 23:59:35 sarkpbx responder: http://192.168.1.200/provisioning
Sep 15 23:59:35 sarkpbx responder: ----------------------------------------------------------}
Sep 15 23:59:35 sarkpbx apache2: 192.168.1.204 processing URI /provisioning/y000000000053.cfg
Sep 15 23:59:35 sarkpbx apache2: 192.168.1.204 Found Yealink Y file  y000000000053.cfg
Sep 15 23:59:35 sarkpbx apache2: 192.168.1.204 sending config y000000000053.cfg
Sep 15 23:59:40 sarkpbx apache2: 192.168.1.204 processing URI /provisioning/001565d2ab88.cfg
Sep 15 23:59:40 sarkpbx apache2: 192.168.1.204 Found MAC 001565d2ab88
Sep 15 23:59:40 sarkpbx apache2: 192.168.1.204 sending config 001565d2ab88.cfg


Manual provision syslog v53.82.0.20 (not working)

Code Select Expand

Sep 15 23:43:54 sarkpbx apache2: 192.168.1.204 processing URI /provisioning/001565d2ab88.boot
Sep 15 23:43:54 sarkpbx apache2: 192.168.1.204 Found MAC 001565d2ab88
Sep 15 23:43:54 sarkpbx apache2: 192.168.1.204 sending config 001565d2ab88.boot


Manual provision syslog 53.80.0.130 (working)

Code Select Expand

Sep 16 00:07:40 sarkpbx apache2: 192.168.1.204 processing URI /provisioning/y000000000053.cfg
Sep 16 00:07:40 sarkpbx apache2: 192.168.1.204 Found Yealink Y file  y000000000053.cfg
Sep 16 00:07:40 sarkpbx apache2: 192.168.1.204 sending config y000000000053.cfg
Sep 16 00:07:45 sarkpbx apache2: 192.168.1.204 processing URI /provisioning/001565d2ab88.cfg
Sep 16 00:07:45 sarkpbx apache2: 192.168.1.204 Found MAC 001565d2ab88
Sep 16 00:07:45 sarkpbx apache2: 192.168.1.204 sending config 001565d2ab88.cfg

Also have a T46 & T48 if you would like logs from those too.

[Del]

I could be way off the mark, but this is what I believe is the issue -

From what I can see v81 and above can now support an optional "mac.boot" file, if it exists.
After reading Yealink docs this file is used to customize the download sequence of the cfg files.
This is an example template from Yealink for the .boot file:

Code Select Expand

#!version:1.0.0.1
## The header above must appear as-is in the first line
     
include:config <xxx.cfg>
include:config "xxx.cfg" 
     
overwrite_mode = 1

What seems to happen is when SAIL "sending config 001565d2ab88.boot" the contents of that file (192.168.1.200/provisioning/001565d2ab88.boot) is the contents of the 001565d2ab88.cfg file, this content is not what the Yealink expects to see as the boot file so it never goes any further.

I imagine it expects/wants to see something like this when it receives the 001565d2ab88.boot file from SAIL:

Code Select Expand

[code]#!version:1.0.0.1
## The header above must appear as-is in the first line
     
include:config "y000000000053.cfg"
include:config "001565d2ab88.cfg " 
     
overwrite_mode = 1

Then it will grab the cfg files referenced and provision correctly.

The easiest fix would be for SAIL not to attempt to send any .boot file - if no boot file exists then the Yealink's revert back the standard common cfg then MAC cfg files (which we know works)

Paragraph from latest Yealink Prov Doc:
If boot file is found on the provisioning server, the IP phones download the boot file first, and then download the configuration files referenced in the boot file in sequence during auto provisioning. You can customize the download sequence of configuration files in the boot file as required.
If boot file is not found on the provisioning server, IP phones download the common CFG file first, and then the MAC-Oriented CFG file during auto provisioning ? i.e., the old mechanism for auto provisioning. You can select whether to use the boot file or not for auto provisioning according to your deployment scenario.

[Del]

I've done the following test, which seems to prove the theory -

I created a new T19 extension (410) with a bogus MAC address not being used (001565D2AF2E)
I then edited the T19 extension I'm testing to provision (001565d2ab88) and in the provisioning tab replaced everything with:

Code Select Expand

#!version:1.0.0.1
## The header above must appear as-is in the first line
     
include:config "y000000000053.cfg"
include:config "001565D2AF2E.cfg" 
     
overwrite_mode = 1

I saved/committed then I made sure the T19 was on the latest firmware and reset the T19 to factory defaults and let it reboot.
When it came back on it had successfully grabbed the cfg files and auto provisioned as bogus extension 410.
Obviously it's provisioned as the wrong extension, but it seems to prove that with the correct format/content in the .boot file, the newer firmware can auto provision fine.

Syslog

Code Select Expand

Sep 16 02:15:20 sarkpbx apache2: 192.168.1.204 processing URI /provisioning/001565d2ab88.boot
Sep 16 02:55:20 sarkpbx apache2: 192.168.1.204 Found MAC 001565d2ab88
Sep 16 02:55:20 sarkpbx apache2: 192.168.1.204 sending config 001565d2ab88.boot
Sep 16 02:55:20 sarkpbx apache2: 192.168.1.204 processing URI /provisioning/y000000000053.cfg
Sep 16 02:15:20 sarkpbx apache2: 192.168.1.204 Found Yealink Y file  y000000000053.cfg
Sep 16 02:15:20 sarkpbx apache2: 192.168.1.204 sending config y000000000053.cfg
Sep 16 02:15:20 sarkpbx apache2: 192.168.1.204 processing URI /provisioning/001565D2AF2E.cfg
Sep 16 02:15:20 sarkpbx apache2: 192.168.1.204 Found MAC 001565D2AF2E
Sep 16 02:15:20 sarkpbx apache2: 192.168.1.204 sending config 001565D2AF2E.cfg

So it seems that SAIL would need to either rework the Yealink provisioning to include a correct format .boot file or just not send a .boot file to the Yealink and let it skip to the default cfg files (which seems to make the most sense)

[Del]

After a little messing, I managed to "hack" SAIL provisioning to get v81/82 Yealink's to now provision.
Basically I just added a check for .boot in (opt/sark/provisioning/device.php) if .boot is found in the request it ignores it and sends 404/exit.
Once ignored the Yealink's come back and request the .cfg as before, allowing provisioning again.

I have no knowledge of PHP or coding so I just bumbled my way through it, no idea if it will break something else (I only have Yealink's here).
I'm sure you will implement a much better/nicer way when you get the chance.

This is what I've added (above the check for Yealink Y)

Code Select Expand

// check for Yealink Boot file
if (preg_match('/^(.*).boot$/',$frequest)  ) {
logit ("Ignoring Yealink Boot file");
send404();
exit;
}
else {

(Then added the extra } to close it off later)

Portion from syslog with edited device.php (with Yealink on v82 Sept 13th 2017 release). Provisions fine.

Code Select Expand

Sep 16 13:12:58 sarkpbx apache2: 192.168.1.204 processing URI /provisioning/001565d2ab88.boot
Sep 16 13:12:58 sarkpbx apache2: 192.168.1.204 Ignoring Yealink Boot file
Sep 16 13:12:58 sarkpbx apache2: 192.168.1.204 processing URI /provisioning/y000000000000.boot
Sep 16 13:12:58 sarkpbx apache2: 192.168.1.204 Ignoring Yealink Boot file
Sep 16 13:12:58 sarkpbx apache2: 192.168.1.204 processing URI /provisioning/y000000000053.cfg
Sep 16 13:12:58 sarkpbx apache2: 192.168.1.204 Found Yealink Y file  y000000000053.cfg
Sep 16 13:12:58 sarkpbx apache2: 192.168.1.204 sending config y000000000053.cfg
Sep 16 13:13:00 sarkpbx apache2: 192.168.1.204 processing URI /provisioning/001565d2ab88.cfg
Sep 16 13:13:00 sarkpbx apache2: 192.168.1.204 Found MAC 001565d2ab88
Sep 16 13:13:00 sarkpbx apache2: 192.168.1.204 sending config 001565d2ab88.cfg

[sysadmin]

Hi Del,

I just looked at the latest V5 beta work and it has much the same construct as you have added.  Good work.   Here is what we have, it's almost identical to yours.

Code Select Expand


// check for Yealink boot file request and ignore it           
                        if (preg_match('/\.boot$/',$frequest)) {
                                logIt("Yealink bootfile request for " . $_SERVER["REQUEST_URI"] . ", Sending 404 and giving up");
                                send404();
                                exit;
                        }   


So I'll leave this here but the issue is fixed in the next out which is looking as tho' it will 5.1 but that may change.

Thanks for the input

[davidiwharper]

Thanks for keeping on this one folks. Much appreciated.

[compsos]

Hi S
We just added the new code to the device.php file and it solved a phone that would not provision (T42G). Others on the same network were OK.
Thanks.

[Del]

So I'll leave this here but the issue is fixed in the next out which is looking as tho' it will 5.1 but that may change.

Thanks, your code works great. Look forward to trying the new version when it becomes available.

[sysadmin]

There is a lot of new stuff in 5.1 and it's taking longer than we would like to get it out the door.   I'm hoping we'll have an early out before year end.  It isn't that different to 5.0 but the provisioning engine has seen a big change to be smarter with the likes of Yealink, where we figure out the model type on the fly.  You just declare a "Yealink" and we figure out which Yealink it is the first time we see it. 

There's also the option of packet inspection on the firewall which helps keep the baddies out.

 

[davidiwharper]

Regarding Yealink autodetection, will that interfere with the ability to add newer models into the SAIL templates list as they come out?

[sysadmin]

You will still be able to add your own templates if you wish so even if a manufacturer makes a big change the engine doesn't recognise you should still be able to handle it between our releases.   Historically, Yealink tend to be more likely to make potentially disruptive changes than other manufacturers.

I'll know better in a week or two when we run a sim at the distributor on the recent flurry of new Yealink models.