Yealink phones won't auto-provision

[CCAdmin]

We have a Google Cloud linux 3CX, installed from the PBXExpress wizard.
There seems to be several issues I've noticed with this automatic installed 3CX.

1) Our Yealink phones no longer auto-provision.
We have the router setup with option 66 correctly and with our previous windows hosted PBX, over the internet as well, the phones would provision just fine. Ever since moving to this Google cloud PBX, we are no longer able to auto-provision. The phones don't use the DHCP option 66 any longer, and even if we manually put in the provisioning link on the phone, it never provisions.

2) Several directories in Linux are locked out to changes.
I made changes to different phone provisionings on the 3CX server, the event viewer shows "RPS request for Yealink T22 IP Phone of {user} ({ext}) delivered successfully", but if I go into the directory and open the {mac}.cfg file, the changes aren't there. In fact, all of the CFG files show the date of when the PBX was first created using the PBXExpress interface. None of them allow changes. I've noticed several folders/files that are supposedly owned by "phonesystem", but changes aren't allowed by that user?

I don't think the PBXExpress process is setting proper permissions on the linux directories?

 

[CCAdmin]

Just to add, I have even created a FW rule on the Google cloud allowing all traffic to/from my Corporate office and the 3CX server, so absolutely no ports (both UDP and TCP) are being blocked between us, yet nothing still.

 

[CCAdmin]

I also disabled "Only Accept Trusted Certificates" on one of the phones I'm testing with, but still nothing. Saw that as a possible solution in another post, but it didn't work in our case.

 

[McFired]

Try Option 132. That is the default option built into all Yealink phones.

 

[Saqqara]

Try Option 132. That is the default option built into all Yealink phones.

Option 132 is for vlan, not what the OP is experiencing

Option 66 is the correct option

 

[Saqqara]

The provisioning link, does the fqdn resolve to the external IP address of the Google Cloud ?

Are there any blacklisted IP's , on the 3CX console in the PBX Status you will see blacklisted IPs

 

[CCAdmin]

Yes, it resolves properly to the external IP of the Google Cloud PBX.

No blacklisted IP's. We specifically "allow" our IP's on the PBX blacklist to ensure they don't ever get blocked.

 

[CCAdmin]

We have also tried the provisioning with both HTTP and HTTPS, still nothing.

 

[cobaltit]

So 3CX no longer generates static config files for either Windows or Linux so what you are seeing is not a permissions issue but rather it seems like you restored a backup if there are config files. Either way, I would make sure you can actually grab a config by going to the provisioning URL/mac.cfg and make sure you can download the file. The URL should be HTTPS only as HTTP won't work remotely.

 

[NickD_3CX]

but if I go into the directory and open the {mac}.cfg file, the changes aren't there. In fact, all of the CFG files show the date of when the PBX was first created using the PBXExpress interface.

I would make sure you can actually grab a config by going to the provisioning URL/mac.cfg and make sure you can download the file. The URL should be HTTPS only as HTTP won't work remotely.

...and to add to this, it is best to actually delete the {mac}.cfg files from the directory as this may be what is causing the problem.
Because of some older phone models, the nginx config is configured to first check if it finds a file in this directory, and if not, ask 3CX to generate one on the fly.

 

[cobaltit]

@NickD_3CX

Thanks for adding that note. I was not aware of that behavior.

 

[CCAdmin]

I am able to download a CFG file just fine.
Example: "https://myserver.3cx.us/provisioning/tzagbhxasj/000000000000.cfg" works perfectly.

I deleted the mac.cfg that corresponds to a test phone I'm working with and tried the "autoprovision now", but still nothing. The phone just sits there and never provisions.

 

[CCAdmin]

So 3CX no longer generates static config files for either Windows or Linux so what you are seeing is not a permissions issue but rather it seems like you restored a backup if there are config files. Either way, I would make sure you can actually grab a config by going to the provisioning URL/mac.cfg and make sure you can download the file. The URL should be HTTPS only as HTTP won't work remotely.

If 3CX no longer uses static config files, how does the phone get its configuration?
If there's no {mac}.cfg file to grab, then what does the phone get, and from where?
Does the server create a temp file, then delete it?

 

[cobaltit]

The config file is generated dynamically on the fly. I would test with actual mac.cfg and not 000.cfg and confirm the config file looks good. If the config file looks good and you can view it from the same network as the phones (ruling out firewall issue) then perhaps your phones firmware is behind. LE certificate wasn't installed in Yealink phones until current firmwares (last available v73 firmware for older phones and v80 or v81 for newer ones. You could test this by disabling the certificate checking (Only Accept Trusted Certificates I think its called). If the phone provisions after setting that then you need to manually upgrade firmware.

 

[CCAdmin]

The phones are already on the latest approved 3CX firmware (I'm now testing with a T22p and a T23g). We've already tested disabling the certificate checking. That did nothing to help.

How am I supposed to check downloading the mac.cfg file when it is created dynamically then removed? No mac.cfg file exists on an on-going basis. The file that was there was old from the upgrade process as mentioned above. Once that file was removed, no other file has shown up in its place. That's what I was mentioning before about a potential rights issue with the PBX Express installs. It feels like something is missing in their auto-setup process.

 

[NickD_3CX]

Then I think its time to check the Yealink logs to see what is happening. I would say go into its interface and:
1) Settings --> Configuration and set the Log Levels to max (I think its 6)
2) Press Confirm, then Start.
3) Settings --> Auto Provisioning, in the Server URL field will in the Provisioning URL that you get from 3CX (if its not filled in already...). If it's filled in make sure it's correct! I've spent 2 hours once troubleshooting a mistype....
4) Press Confirm, then "Auto Provision Now"
5) Wait until the Yealink interface does its thing.
6) Go back to Settings --> Configuration, press Stop and then Export.
7) Download file and search with the FQDN to get to the relevant section of the log.

This should give you some insight as to why the phone isn't getting something.

 

[CCAdmin]

Well, good news and bad news.

Good news, after patching 3CX to the latest SP4, auto-provisioning is now suddenly working.
So I guess they fixed whatever was causing Yealinks not to auto-provision.

Bad news, no clue what the issue was.
Didn't see anything in the patch changes about auto-provisioning, but it definitely fixed us.

Thank you everyone for your suggestions!

 

[CCAdmin]

Lol, nice, the phone was too new for the PBX.
Then the PBX should'nt have been claiming that's the firmware it wanted on the phone!
I put the exact firmware on the phone that the PBX wanted it to have (even though the centralized firmware updating is broken - another ticket of mine).

 

[cobaltit]

I'm guessing that services weren't restarted after deleting the stale cfg files on the file system. As far as how do you check the cfg file it's a simply putting the provisioning patch + mac.cfg in your browser and checking what it retrieves (or doesn't if something is broken).