You two obviously have no idea what you are saying.
How can the logs being completely empty mean that it is a problem on my side?
I have clearly stated that a T4XS series works just fine. This means that traffic has to be passing and there should be a valid ssl_access_log if nothing else.
Good luck thenā¦
If the traffic back to your phone is somehow blocked by one of the firewalls involved it canā¦
You obviously have no idea of how weird things can behave when routing or firewalling problems are involvedā¦
Have you ever null routed traffic back to an IP to temporarily block an hack attempt on one of your servers? I didā¦
While the communication with the system I was taking care of was established I was not letting my server talk back to the offending IPā¦
In essence, it looked like the server was not answering while it was actually trying to but not allowed to because of the null routeā¦
Have you ever seen an Internet security product block access between an HTTP server and its application server, I didā¦ The security company who conducted those tests was sure they had crashed our application server but I proved them otherwise because I established that only the link between the two servers was down, nothing else, and we tracked down the problem to the Internet security productā¦
That security company was sure they had crashed our app but their hack attempts had actually freaked out the Internet security product which began thinking the HTTP server was attacking the application serverā¦
Have you ever messed up (or had to fix messed up) subnet masks? Sometime one of the devices is able to talk to the other while the other is unable to because it doesnāt get routed to the right placeā¦
Have you ever put a server in a REAL DMZ (not a consumer router one) where you have to allow on a per port basis access to the outside, have to consider every possible fallback of the protocols involved (an example of that is DNS queries which switch from UDP to TCP sometimes (long answers, zone transfers, etcā¦)ā¦).
(A real DMZ actually puts more restrictions on outbound traffic than the LAN usually).
I did, even my home test server is setted up that wayā¦
The fact that you are not considering those kind of problems shows that you donāt have the necessary experience to question what we are saying because you would realize these are real possibilitiesā¦
Now as far as telephony knowledge is concerned I bow down to @tonyclewis which I doubt I will ever match in knowledge as far as this is concerned so I find your comment rather insulting to both him and meā¦
If this was a simple problem you would probably not have needed help so you have to consider weirder problemsā¦
As I said when I started this post, good luckā¦
This was my last post in this threadā¦
Nick
PS: You didnāt give enough information on your setup to figure out what is so different between your PC and those phonesā¦
iām not getting into a pissing match about who knows what.
My problem was simply stated with all relevant details.
To put it even more simply:
The same two phones (T42G/T46G) on the same network works to one system and not another over HTTPS.
The same two phones (T42G/T46G) on the same network works to all systems over HTTP.
A T46S on the same network works to all systems over HTTPS and HTTP.
I was told to check the logs.
The logs are empty. This is not possible if the system is correctly logging because even putting aside all the errors, the valid SSL connections from the T46S should be listed in ssl_access_log, yet the log is empty.
This has nothing to do with any network connectivity or firewall on any system on any side of this issue.
So @tonyclewis tell me where these supposed logs I need to check are if they are not the default logs.
I already told you. If nothing is in the apache logs than the phone is not reaching it. Look on your phone logs for the second time.
And my point is that the apache logs are invalid in the first place because even valid connections are not showing up in the log.
scroll back up and read it all again.
Also, as mentioned, it does show a 408 error when the G series attempt to connect over HTTPS.
I did take a pcap from one of the phones and it shows the phone receiving the SSL certificate
Ok well not sure how to help. I donāt know yealink phones but their logs should show you whatās going on or give u a hint.
There is nothing different about the phones.
Something is different between FreePBX 13 and FreePBX 14. Obviously this is no longer CentOS 6, so what is done differently in the SSL configuration?
This is CentOS7 derived. Not sure what your problem is but it works for me with Sangoma Phones on SSL. Again I donāt much about yealink phones so hopefully someone else can assist you but they have to have logs. Review them and see what it shows.
Your SSL configuration is different between FreePBX 13 and FreePBX 14. It is that easy.
Phone talking to FreePBX 13:
<134>Oct 8 03:48:37 ATP [1022]: ATP <6+info > Upgrade from com.cfg
<134>Oct 8 03:48:37 LIBD[1022]: DCMN<6+info > Connecting pbx.domain.com:1443
<134>Oct 8 03:48:37 LIBD[1022]: DCMN<6+info > Connecting IP = 45.XXX.XXX.XXX, Port = 1443
<134>Oct 8 03:48:37 LIBD[1022]: DCMN<6+info > ssl cipher num is 18
<134>Oct 8 03:48:37 LIBD[1022]: DCMN<6+info > SSL_connect (read done)
<134>Oct 8 03:48:38 LIBD[1022]: DCMN<6+info > SSL_connect (read done)
<134>Oct 8 03:48:38 LIBD[1022]: HTTP<6+info > Request Line: GET /y000000000029.cfg HTTP/1.1
<134>Oct 8 03:48:38 LIBD[1022]: HTTP<6+info > Host: pbx.domain.com:1443
<134>Oct 8 03:48:38 LIBD[1022]: HTTP<6+info > User-Agent: Yealink SIP-T42G 29.82.0.20 00:15:65:65:xx:xx
<134>Oct 8 03:48:38 LIBD[1022]: HTTP<6+info > process response
<133>Oct 8 03:48:38 LIBD[1022]: HTTP<5+notice> response code: 200
<134>Oct 8 03:48:38 LIBD[1022]: HTTP<6+info > Content-Length: 12129
<134>Oct 8 03:48:38 LIBD[1022]: HTTP<6+info > connection: close
<133>Oct 8 03:48:38 LIBD[1022]: HTTP<5+notice> response process finish!
<133>Oct 8 03:48:38 LIBD[1022]: HTTP<5+notice> recv : 12129 bytes
<134>Oct 8 03:48:38 ATP [1022]: ATP <6+info > need_cmp_md5=1
<134>Oct 8 03:48:38 ATP [1022]: ATP <6+info > cfg md5 same!
<132>Oct 8 03:48:38 ATP [1022]: ATP <4+warnin> error: phone_setting.inactive_backlight_level
<134>Oct 8 03:48:38 ATP [1022]: ATP <6+info > skip item<phone_setting.inactive_backlight_level>
<134>Oct 8 03:48:38 ATP [1022]: ATP <6+info > parse item finish
Phone Talking to FreePBX 14:
<134>Oct 8 03:33:08 ATP [780]: ATP <6+info > Upgrade from mac.boot
<134>Oct 8 03:33:08 LIBD[780]: DCMN<6+info > Connecting pbx.domain.com:1443
<134>Oct 8 03:33:08 LIBD[780]: DCMN<6+info > Connecting IP = 107.XXX.XXX.XXX, Port = 1443
<134>Oct 8 03:33:08 LIBD[780]: DCMN<6+info > SSL_connect (read done)
<134>Oct 8 03:33:08 Log [900]: WEB <6+info > URI: /servlet?p=settings-autop&q=result&Rajax=0.09716529952707398
<134>Oct 8 03:33:08 Log [900]: ETLL<6+info > mkit_call failed! src[0x000c72a8] name[__h900] tar[0xc4098f94] name[autoServer] msg[0x00030206] ret[-1] size[0]
<134>Oct 8 03:33:08 Log [900]: WEB <6+info > Partition free(byte): /tmp/ [104325120], /config/ [90112], /data/ [90112]
<134>Oct 8 03:33:13 Log [900]: ETLL<6+info > mkit_call failed! src[0x000c72a8] name[__h900] tar[0xc4098f94] name[autoServer] msg[0x00030206] ret[-1] size[0]
<134>Oct 8 03:33:13 Log [900]: WEB <6+info > URI: /servlet?p=settings-autop&q=result&Rajax=0.8728236330210573
<134>Oct 8 03:33:13 Log [900]: WEB <6+info > Partition free(byte): /tmp/ [104321024], /config/ [90112], /data/ [90112]
<134>Oct 8 03:33:18 Log [900]: WEB <6+info > URI: /servlet?p=settings-autop&q=result&Rajax=0.649367081619797
<134>Oct 8 03:33:18 Log [900]: WEB <6+info > Partition free(byte): /tmp/ [104316928], /config/ [90112], /data/ [90112]
<134>Oct 8 03:33:18 Log [900]: ETLL<6+info > mkit_call failed! src[0x000c72a8] name[__h900] tar[0xc4098f94] name[autoServer] msg[0x00030206] ret[-1] size[0]
<134>Oct 8 03:33:23 Log [900]: WEB <6+info > URI: /servlet?p=settings-autop&q=result&Rajax=0.6691534391904461
<134>Oct 8 03:33:23 Log [900]: ETLL<6+info > mkit_call failed! src[0x000c72a8] name[__h900] tar[0xc4098f94] name[autoServer] msg[0x00030206] ret[-1] size[0]
<134>Oct 8 03:33:23 Log [900]: WEB <6+info > Partition free(byte): /tmp/ [104316928], /config/ [90112], /data/ [90112]
<134>Oct 8 03:33:28 Log [900]: WEB <6+info > URI: /servlet?p=settings-autop&q=result&Rajax=0.14837767361288257
<134>Oct 8 03:33:28 Log [900]: ETLL<6+info > mkit_call failed! src[0x000c72a8] name[__h900] tar[0xc4098f94] name[autoServer] msg[0x00030206] ret[-1] size[0]
<134>Oct 8 03:33:28 Log [900]: WEB <6+info > Partition free(byte): /tmp/ [104312832], /config/ [90112], /data/ [90112]
<134>Oct 8 03:33:33 Log [900]: WEB <6+info > URI: /servlet?p=settings-autop&q=result&Rajax=0.9179317121887864
<134>Oct 8 03:33:33 Log [900]: WEB <6+info > Partition free(byte): /tmp/ [104288256], /config/ [90112], /data/ [90112]
<134>Oct 8 03:33:33 Log [900]: ETLL<6+info > mkit_call failed! src[0x000c72a8] name[__h900] tar[0xc4098f94] name[autoServer] msg[0x00030206] ret[-1] size[0]
<134>Oct 8 03:33:37 LIBD[780]: DCMN<6+info > SSL_connect write/read error
<131>Oct 8 03:33:37 LIBD[780]: HTTP<3+error > Connect Error
<131>Oct 8 03:33:37 ATP [780]: ATP <3+error > https to file failed, code = -3, msg = Connect Failed, retry = 1
<134>Oct 8 03:33:37 ATP [780]: ATP <6+info > Wait 0 second to next file transfer!
Notice that the initial connection never completes when talking to FreePBX 14. The phone never gets a cipher like it did with FreePBX 13. This line: <134>Oct 8 03:48:37 LIBD[1022]: DCMN<6+info > ssl cipher num is 18
The code is open for you to see in ssl.conf for Apache. If you have any advice on what or how to fix it then we are all ears and will be happy to adjust.
And ssl.conf is clearly untouched. but that is not the only configuration file involved. That only affects apache.
What about all the configuration for openssl and whatever method you all use to generate the LE certificates.
I looked at /etc/pki/tls/openssl.cnf and it has minor differences between the two PBX versions.
Obviously for CentOS 7 (FreePBX 14) the openssl build is different than CentOS 6 (FreePBX 13).
FreePBX 13
yum list openssl
Loaded plugins: fastestmirror, kmod
Loading mirror speeds from cached hostfile
base | 2.0 kB 00:00
extras | 1.3 kB 00:00
pbx | 2.9 kB 00:00
schmooze-commercial | 2.9 kB 00:00
updates | 1.3 kB 00:00
Installed Packages
openssl.i686 1.0.1e-30.el6.11 @updates
openssl.x86_64 1.0.1e-30.el6.11 @anaconda-SHMZ-201501302108.x86_64/6.6
FreePBX 14
yum list openssl
Loaded plugins: fastestmirror, kmod
Loading mirror speeds from cached hostfile
Installed Packages
openssl.x86_64 1:1.0.1e-60.el7_3.1 installed
Available Packages
openssl.x86_64 1:1.0.2k-8.el7 sng-base
Why havenāt you upgraded Openssl
It was up to date before I went out of town last week.
And you have a problem with your repo.
Install 8 Packages (+8 Dependent packages)
Upgrade 278 Packages
Total size: 364 M
Is this ok [y/d/N]: y
Downloading packages:
Running transaction check
Running transaction test
Transaction check error:
file /usr/lib/firmware/ql2400_fw.bin from install of linux-firmware-20170606-56.gitc990aae.el7.noarch conflicts with file from package ql2400-firmware-7.03.00-1.el6_5.noarch
file /usr/lib/firmware/ql2500_fw.bin from install of linux-firmware-20170606-56.gitc990aae.el7.noarch conflicts with file from package ql2500-firmware-7.03.00-1.el6_5.noarch
Error Summary
-------------
So I will just do openssl
Upgrade 1 Package (+2 Dependent packages)
Total size: 2.6 M
Is this ok [y/d/N]: y
Downloading packages:
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Updating : 1:openssl-libs-1.0.2k-8.el7.x86_64 1/6
Updating : 1:openssl-1.0.2k-8.el7.x86_64 2/6
Updating : 1:openssl-libs-1.0.2k-8.el7.i686 3/6
Cleanup : 1:openssl-1.0.1e-60.el7_3.1.x86_64 4/6
Cleanup : 1:openssl-libs-1.0.1e-60.el7_3.1 5/6
Cleanup : 1:openssl-libs-1.0.1e-60.el7_3.1 6/6
Verifying : 1:openssl-1.0.2k-8.el7.x86_64 1/6
Verifying : 1:openssl-libs-1.0.2k-8.el7.i686 2/6
Verifying : 1:openssl-libs-1.0.2k-8.el7.x86_64 3/6
Verifying : 1:openssl-1.0.1e-60.el7_3.1.x86_64 4/6
Verifying : 1:openssl-libs-1.0.1e-60.el7_3.1.i686 5/6
Verifying : 1:openssl-libs-1.0.1e-60.el7_3.1.x86_64 6/6
Updated:
openssl.x86_64 1:1.0.2k-8.el7
Dependency Updated:
openssl-libs.i686 1:1.0.2k-8.el7 openssl-libs.x86_64 1:1.0.2k-8.el7
Complete!
Restarted httpd and no difference.
We have no issue with our repo. You have old EL6.5 packages installed that are conflicting you need to yum erase it appears those.
Jared,
I know you really want us to figure out how to fix this but this is not in any way a priority. Everything you need to go figure out the issue is open source. The httpd conf files. Certificate manager.
If you have time we would love it if you could figure it out and help us and the community. Otherwise this is not something we are looking into.
This was a FreePBX 13 to 14 upgrade. I did nothing but follow the upgrade process. so if old packages are left, it was caused by th eupgrade process.
That is why I have this thread. But just getting told ānot our problemā does not help me figure it out.
Did you do a early upgrade as the past 2 months the upgrade has been updated to make sure all el6 based RPMS got removed. Please remove any that still show up.