[jira] [Comment Edited] (TS-3022) OCSP double free or corruption (!prev)
[
https://issues.apache.org/jira/browse/TS-3022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14111652#comment-14111652
]
Alan M. Carroll edited comment on TS-3022 at 8/27/14 12:45 AM:
---
If anyone is interested, the problem was the ticket logic called
SSL_get_ex_new_index instead of SSL_CTX_get_ex_new_index.
was (Author: amc):
If anyone is interested, the problem was the ticket logic call
SSL_get_ex_new_index instead of SSL_CTX_get_ex_new_index.
> OCSP double free or corruption (!prev)
> --
>
> Key: TS-3022
> URL: https://issues.apache.org/jira/browse/TS-3022
> Project: Traffic Server
> Issue Type: Bug
> Components: SSL
>Reporter: bettydramit
>Assignee: Alan M. Carroll
>Priority: Blocker
> Fix For: 5.1.0
>
>
> Centos 6 x86_64 gitmaster
> Enable ocsp
> config set
> {code}
> CONFIG proxy.config.ssl.ocsp.enabled INT 1
> CONFIG proxy.config.ssl.ocsp.update_period INT 60
> {code}
> {code}
> [E. Mgmt] log ==> [TrafficManager] using root directory '/usr'
> [TrafficServer] using root directory '/usr'
> *** glibc detected *** /usr/bin/traffic_server: double free or corruption
> (!prev): 0x02af8be0 ***
> === Backtrace: =
> /lib64/libc.so.6(+0x76166)[0x2ac6c2294166]
> /lib64/libc.so.6(+0x78c93)[0x2ac6c2296c93]
> /usr/lib64/libcrypto.so.10(CRYPTO_free+0x1d)[0x2ac6bfb990ad]
> /usr/lib64/libcrypto.so.10(+0x68ada)[0x2ac6bfb9aada]
> /usr/lib64/libssl.so.10(SSL_CTX_free+0x6e)[0x2ac6bf907e7e]
> /usr/bin/traffic_server(_ZN17SSLContextStorageD1Ev+0x59)[0x72c489]
> /usr/bin/traffic_server(_ZN13SSLCertLookupD0Ev+0x29)[0x72c5f9]
> /usr/bin/traffic_server(_ZN18ConfigInfoReleaser12handle_eventEiPv+0x17)[0x665da7]
> /usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x73f7bf]
> /usr/bin/traffic_server(_ZN7EThread7executeEv+0x5c3)[0x740173]
> /usr/bin/traffic_server[0x73eb5a]
> /lib64/libpthread.so.0(+0x79d1)[0x2ac6c13109d1]
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-3022) OCSP double free or corruption (!prev)
[
https://issues.apache.org/jira/browse/TS-3022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14111657#comment-14111657
]
ASF subversion and git services commented on TS-3022:
-
Commit d0da9a84101ef67376b4736b42e4e429dd26be9d in trafficserver's branch
refs/heads/5.1.x from [~amc]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=d0da9a8 ]
TS-3022: Fix double free for OCSP.
> OCSP double free or corruption (!prev)
> --
>
> Key: TS-3022
> URL: https://issues.apache.org/jira/browse/TS-3022
> Project: Traffic Server
> Issue Type: Bug
> Components: SSL
>Reporter: bettydramit
>Assignee: Alan M. Carroll
>Priority: Blocker
> Fix For: 5.1.0
>
>
> Centos 6 x86_64 gitmaster
> Enable ocsp
> config set
> {code}
> CONFIG proxy.config.ssl.ocsp.enabled INT 1
> CONFIG proxy.config.ssl.ocsp.update_period INT 60
> {code}
> {code}
> [E. Mgmt] log ==> [TrafficManager] using root directory '/usr'
> [TrafficServer] using root directory '/usr'
> *** glibc detected *** /usr/bin/traffic_server: double free or corruption
> (!prev): 0x02af8be0 ***
> === Backtrace: =
> /lib64/libc.so.6(+0x76166)[0x2ac6c2294166]
> /lib64/libc.so.6(+0x78c93)[0x2ac6c2296c93]
> /usr/lib64/libcrypto.so.10(CRYPTO_free+0x1d)[0x2ac6bfb990ad]
> /usr/lib64/libcrypto.so.10(+0x68ada)[0x2ac6bfb9aada]
> /usr/lib64/libssl.so.10(SSL_CTX_free+0x6e)[0x2ac6bf907e7e]
> /usr/bin/traffic_server(_ZN17SSLContextStorageD1Ev+0x59)[0x72c489]
> /usr/bin/traffic_server(_ZN13SSLCertLookupD0Ev+0x29)[0x72c5f9]
> /usr/bin/traffic_server(_ZN18ConfigInfoReleaser12handle_eventEiPv+0x17)[0x665da7]
> /usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x73f7bf]
> /usr/bin/traffic_server(_ZN7EThread7executeEv+0x5c3)[0x740173]
> /usr/bin/traffic_server[0x73eb5a]
> /lib64/libpthread.so.0(+0x79d1)[0x2ac6c13109d1]
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (TS-3022) OCSP double free or corruption (!prev)
[
https://issues.apache.org/jira/browse/TS-3022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll resolved TS-3022.
-
Resolution: Fixed
If anyone is interested, the problem was the ticket logic call
SSL_get_ex_new_index instead of SSL_CTX_get_ex_new_index.
> OCSP double free or corruption (!prev)
> --
>
> Key: TS-3022
> URL: https://issues.apache.org/jira/browse/TS-3022
> Project: Traffic Server
> Issue Type: Bug
> Components: SSL
>Reporter: bettydramit
>Assignee: Alan M. Carroll
>Priority: Blocker
> Fix For: 5.1.0
>
>
> Centos 6 x86_64 gitmaster
> Enable ocsp
> config set
> {code}
> CONFIG proxy.config.ssl.ocsp.enabled INT 1
> CONFIG proxy.config.ssl.ocsp.update_period INT 60
> {code}
> {code}
> [E. Mgmt] log ==> [TrafficManager] using root directory '/usr'
> [TrafficServer] using root directory '/usr'
> *** glibc detected *** /usr/bin/traffic_server: double free or corruption
> (!prev): 0x02af8be0 ***
> === Backtrace: =
> /lib64/libc.so.6(+0x76166)[0x2ac6c2294166]
> /lib64/libc.so.6(+0x78c93)[0x2ac6c2296c93]
> /usr/lib64/libcrypto.so.10(CRYPTO_free+0x1d)[0x2ac6bfb990ad]
> /usr/lib64/libcrypto.so.10(+0x68ada)[0x2ac6bfb9aada]
> /usr/lib64/libssl.so.10(SSL_CTX_free+0x6e)[0x2ac6bf907e7e]
> /usr/bin/traffic_server(_ZN17SSLContextStorageD1Ev+0x59)[0x72c489]
> /usr/bin/traffic_server(_ZN13SSLCertLookupD0Ev+0x29)[0x72c5f9]
> /usr/bin/traffic_server(_ZN18ConfigInfoReleaser12handle_eventEiPv+0x17)[0x665da7]
> /usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x73f7bf]
> /usr/bin/traffic_server(_ZN7EThread7executeEv+0x5c3)[0x740173]
> /usr/bin/traffic_server[0x73eb5a]
> /lib64/libpthread.so.0(+0x79d1)[0x2ac6c13109d1]
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-3022) OCSP double free or corruption (!prev)
[
https://issues.apache.org/jira/browse/TS-3022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14111648#comment-14111648
]
ASF subversion and git services commented on TS-3022:
-
Commit 51abbb40137acaa57a3a5caacca2b6c3690f365e in trafficserver's branch
refs/heads/master from [~amc]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=51abbb4 ]
TS-3022: Fix double free for OCSP.
> OCSP double free or corruption (!prev)
> --
>
> Key: TS-3022
> URL: https://issues.apache.org/jira/browse/TS-3022
> Project: Traffic Server
> Issue Type: Bug
> Components: SSL
>Reporter: bettydramit
>Assignee: Alan M. Carroll
>Priority: Blocker
> Fix For: 5.1.0
>
>
> Centos 6 x86_64 gitmaster
> Enable ocsp
> config set
> {code}
> CONFIG proxy.config.ssl.ocsp.enabled INT 1
> CONFIG proxy.config.ssl.ocsp.update_period INT 60
> {code}
> {code}
> [E. Mgmt] log ==> [TrafficManager] using root directory '/usr'
> [TrafficServer] using root directory '/usr'
> *** glibc detected *** /usr/bin/traffic_server: double free or corruption
> (!prev): 0x02af8be0 ***
> === Backtrace: =
> /lib64/libc.so.6(+0x76166)[0x2ac6c2294166]
> /lib64/libc.so.6(+0x78c93)[0x2ac6c2296c93]
> /usr/lib64/libcrypto.so.10(CRYPTO_free+0x1d)[0x2ac6bfb990ad]
> /usr/lib64/libcrypto.so.10(+0x68ada)[0x2ac6bfb9aada]
> /usr/lib64/libssl.so.10(SSL_CTX_free+0x6e)[0x2ac6bf907e7e]
> /usr/bin/traffic_server(_ZN17SSLContextStorageD1Ev+0x59)[0x72c489]
> /usr/bin/traffic_server(_ZN13SSLCertLookupD0Ev+0x29)[0x72c5f9]
> /usr/bin/traffic_server(_ZN18ConfigInfoReleaser12handle_eventEiPv+0x17)[0x665da7]
> /usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x73f7bf]
> /usr/bin/traffic_server(_ZN7EThread7executeEv+0x5c3)[0x740173]
> /usr/bin/traffic_server[0x73eb5a]
> /lib64/libpthread.so.0(+0x79d1)[0x2ac6c13109d1]
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (TS-3022) OCSP double free or corruption (!prev)
[
https://issues.apache.org/jira/browse/TS-3022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach reassigned TS-3022:
---
Assignee: Alan M. Carroll (was: James Peach)
[~amc] was looking at this one
> OCSP double free or corruption (!prev)
> --
>
> Key: TS-3022
> URL: https://issues.apache.org/jira/browse/TS-3022
> Project: Traffic Server
> Issue Type: Bug
> Components: SSL
>Reporter: bettydramit
>Assignee: Alan M. Carroll
>Priority: Blocker
> Fix For: 5.1.0
>
>
> Centos 6 x86_64 gitmaster
> Enable ocsp
> config set
> {code}
> CONFIG proxy.config.ssl.ocsp.enabled INT 1
> CONFIG proxy.config.ssl.ocsp.update_period INT 60
> {code}
> {code}
> [E. Mgmt] log ==> [TrafficManager] using root directory '/usr'
> [TrafficServer] using root directory '/usr'
> *** glibc detected *** /usr/bin/traffic_server: double free or corruption
> (!prev): 0x02af8be0 ***
> === Backtrace: =
> /lib64/libc.so.6(+0x76166)[0x2ac6c2294166]
> /lib64/libc.so.6(+0x78c93)[0x2ac6c2296c93]
> /usr/lib64/libcrypto.so.10(CRYPTO_free+0x1d)[0x2ac6bfb990ad]
> /usr/lib64/libcrypto.so.10(+0x68ada)[0x2ac6bfb9aada]
> /usr/lib64/libssl.so.10(SSL_CTX_free+0x6e)[0x2ac6bf907e7e]
> /usr/bin/traffic_server(_ZN17SSLContextStorageD1Ev+0x59)[0x72c489]
> /usr/bin/traffic_server(_ZN13SSLCertLookupD0Ev+0x29)[0x72c5f9]
> /usr/bin/traffic_server(_ZN18ConfigInfoReleaser12handle_eventEiPv+0x17)[0x665da7]
> /usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x73f7bf]
> /usr/bin/traffic_server(_ZN7EThread7executeEv+0x5c3)[0x740173]
> /usr/bin/traffic_server[0x73eb5a]
> /lib64/libpthread.so.0(+0x79d1)[0x2ac6c13109d1]
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-3022) OCSP double free or corruption (!prev)
[
https://issues.apache.org/jira/browse/TS-3022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14111528#comment-14111528
]
Alan M. Carroll commented on TS-3022:
-
I think I've replicated this. You must set this up, and then (2 or 3 times) do
* Modify ssl_multicert.config.
* traffic_line -x
Just doing one of these, or doing this sequence just once, has never triggered
the crash for me. I can get it to go off reliably if I do it repeatedly.
The crash is happening when freeing the certinfo instance. However, I cannot
find where the first free happens, even if I break on ats_free with the address
that will eventually cause the double free crash. It appears to crash on the
first free.
> OCSP double free or corruption (!prev)
> --
>
> Key: TS-3022
> URL: https://issues.apache.org/jira/browse/TS-3022
> Project: Traffic Server
> Issue Type: Bug
> Components: SSL
>Reporter: bettydramit
>Assignee: James Peach
>Priority: Blocker
> Fix For: 5.1.0
>
>
> Centos 6 x86_64 gitmaster
> Enable ocsp
> config set
> {code}
> CONFIG proxy.config.ssl.ocsp.enabled INT 1
> CONFIG proxy.config.ssl.ocsp.update_period INT 60
> {code}
> {code}
> [E. Mgmt] log ==> [TrafficManager] using root directory '/usr'
> [TrafficServer] using root directory '/usr'
> *** glibc detected *** /usr/bin/traffic_server: double free or corruption
> (!prev): 0x02af8be0 ***
> === Backtrace: =
> /lib64/libc.so.6(+0x76166)[0x2ac6c2294166]
> /lib64/libc.so.6(+0x78c93)[0x2ac6c2296c93]
> /usr/lib64/libcrypto.so.10(CRYPTO_free+0x1d)[0x2ac6bfb990ad]
> /usr/lib64/libcrypto.so.10(+0x68ada)[0x2ac6bfb9aada]
> /usr/lib64/libssl.so.10(SSL_CTX_free+0x6e)[0x2ac6bf907e7e]
> /usr/bin/traffic_server(_ZN17SSLContextStorageD1Ev+0x59)[0x72c489]
> /usr/bin/traffic_server(_ZN13SSLCertLookupD0Ev+0x29)[0x72c5f9]
> /usr/bin/traffic_server(_ZN18ConfigInfoReleaser12handle_eventEiPv+0x17)[0x665da7]
> /usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x73f7bf]
> /usr/bin/traffic_server(_ZN7EThread7executeEv+0x5c3)[0x740173]
> /usr/bin/traffic_server[0x73eb5a]
> /lib64/libpthread.so.0(+0x79d1)[0x2ac6c13109d1]
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (TS-3043) auth_proxy plugin doc doesn't talk about auth remap rule required
[ https://issues.apache.org/jira/browse/TS-3043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Miles Libbey resolved TS-3043. -- Resolution: Fixed > auth_proxy plugin doc doesn't talk about auth remap rule required > - > > Key: TS-3043 > URL: https://issues.apache.org/jira/browse/TS-3043 > Project: Traffic Server > Issue Type: Bug > Components: Documentation >Reporter: Miles Libbey > > When using the authproxy plugin, one must configure a remap rule to handle > the request that goes to the authorization server. The current docs don't > mention this. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-3043) auth_proxy plugin doc doesn't talk about auth remap rule required
[ https://issues.apache.org/jira/browse/TS-3043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14111489#comment-14111489 ] Miles Libbey commented on TS-3043: -- arg. missed the jira number in the commit: mlib...@apache.org master * b9cd6e3 (doc/reference/plugins/authproxy.en.rst) https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=b9cd6e3 : > auth_proxy plugin doc doesn't talk about auth remap rule required > - > > Key: TS-3043 > URL: https://issues.apache.org/jira/browse/TS-3043 > Project: Traffic Server > Issue Type: Bug > Components: Documentation >Reporter: Miles Libbey > > When using the authproxy plugin, one must configure a remap rule to handle > the request that goes to the authorization server. The current docs don't > mention this. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2653) SSL Error message cleanup
[
https://issues.apache.org/jira/browse/TS-2653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-2653:
Fix Version/s: (was: 5.1.0)
5.2.0
> SSL Error message cleanup
> -
>
> Key: TS-2653
> URL: https://issues.apache.org/jira/browse/TS-2653
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging, SSL
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 5.2.0
>
>
> We see a lot of SSL error messages in production. It would be good to
> determine if these are really errors or remove logging of some of these
> errors:
> {code}
> -bash-4.1$ tail -10 diags.log | cut -f4-20 -d : | grep SSL | sort | uniq
> -c | sort -rn
>3108 SSL::36:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>3079 SSL::32:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>3068 SSL::27:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>3051 SSL::44:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>3043 SSL::24:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>3041 SSL::47:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>3041 SSL::38:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>3040 SSL::46:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>3025 SSL::34:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>3025 SSL::25:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>3021 SSL::31:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>3011 SSL::42:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>3006 SSL::39:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>3004 SSL::29:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>3000 SSL::30:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>2996 SSL::43:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>2993 SSL::45:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>2977 SSL::40:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>2976 SSL::33:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>2974 SSL::41:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>2974 SSL::28:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>2958 SSL::37:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>2947 SSL::35:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>2922 SSL::26:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
> 28 SSL::36:error:14094415:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate expired:s3_pkt.c:1256:SSL alert number 45
> 26 SSL::24:error:14094415:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate expired:s3_pkt.c:1256:SSL alert number 45
> 25 SSL::44:error:14094415:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate expired:s3_pkt.c:1256:SSL alert number 45
> 25 SSL::27:error:14094415:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate expired:s3_pkt.c:1256:SSL alert number 45
> 24 SSL::34:error:14094415:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate expired:s3_pkt.c:1256:SSL alert number 45
> 24 SSL::30:error:14094415:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate expired:s3_pkt.c:1256:SSL alert number 45
> 23 SSL::39:error:14094415:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate expired:s3_pkt.c:1256:SSL alert number 45
> 23 SSL::33:error:14094415:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate expired:s3_pkt.c:1256:SSL alert number 45
> 23 SSL::32:error:14094415:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate expired:s3_pkt.c:1256:SSL alert number 45
> 22 SSL::44:error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert
> unknown ca:s3_pkt.c:1256:SSL alert number 48
> 21 SSL::38:error:14094415:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate expired:s3_pkt.c:1256:SSL alert
[jira] [Updated] (TS-2653) SSL Error message cleanup
[
https://issues.apache.org/jira/browse/TS-2653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-2653:
Assignee: Susan Hinrichs (was: Bryan Call)
> SSL Error message cleanup
> -
>
> Key: TS-2653
> URL: https://issues.apache.org/jira/browse/TS-2653
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging, SSL
>Reporter: Bryan Call
>Assignee: Susan Hinrichs
> Fix For: 5.2.0
>
>
> We see a lot of SSL error messages in production. It would be good to
> determine if these are really errors or remove logging of some of these
> errors:
> {code}
> -bash-4.1$ tail -10 diags.log | cut -f4-20 -d : | grep SSL | sort | uniq
> -c | sort -rn
>3108 SSL::36:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>3079 SSL::32:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>3068 SSL::27:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>3051 SSL::44:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>3043 SSL::24:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>3041 SSL::47:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>3041 SSL::38:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>3040 SSL::46:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>3025 SSL::34:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>3025 SSL::25:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>3021 SSL::31:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>3011 SSL::42:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>3006 SSL::39:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>3004 SSL::29:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>3000 SSL::30:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>2996 SSL::43:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>2993 SSL::45:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>2977 SSL::40:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>2976 SSL::33:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>2974 SSL::41:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>2974 SSL::28:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>2958 SSL::37:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>2947 SSL::35:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>2922 SSL::26:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
> 28 SSL::36:error:14094415:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate expired:s3_pkt.c:1256:SSL alert number 45
> 26 SSL::24:error:14094415:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate expired:s3_pkt.c:1256:SSL alert number 45
> 25 SSL::44:error:14094415:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate expired:s3_pkt.c:1256:SSL alert number 45
> 25 SSL::27:error:14094415:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate expired:s3_pkt.c:1256:SSL alert number 45
> 24 SSL::34:error:14094415:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate expired:s3_pkt.c:1256:SSL alert number 45
> 24 SSL::30:error:14094415:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate expired:s3_pkt.c:1256:SSL alert number 45
> 23 SSL::39:error:14094415:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate expired:s3_pkt.c:1256:SSL alert number 45
> 23 SSL::33:error:14094415:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate expired:s3_pkt.c:1256:SSL alert number 45
> 23 SSL::32:error:14094415:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate expired:s3_pkt.c:1256:SSL alert number 45
> 22 SSL::44:error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert
> unknown ca:s3_pkt.c:1256:SSL alert number 48
> 21 SSL::38:error:14094415:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate expired:s3_pkt.c:1256:SSL alert number 45
[jira] [Updated] (TS-2883) core dump in TSFetchCreate()
[
https://issues.apache.org/jira/browse/TS-2883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-2883:
Fix Version/s: (was: 5.1.0)
5.2.0
> core dump in TSFetchCreate()
>
>
> Key: TS-2883
> URL: https://issues.apache.org/jira/browse/TS-2883
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, SPDY
>Reporter: Sudheer Vinukonda
>Assignee: Bryan Call
> Labels: crash, yahoo
> Fix For: 5.2.0
>
> Attachments: TS-2883.diff
>
>
> {code}
> (gdb) bt
> #0 ink_freelist_new (f=0x2923050) at ink_queue.cc:202
> #1 0x004c0cd2 in alloc (contp=0x2b86821e2120,
> method=TS_FETCH_METHOD_POST,
> url=0x2b865d64f228
> "https://aa-mg5.mail.yahoo.com/ws/mail/v2.0/jsonrpc?appid=YahooMailNeo&m=BatchExecute&wssid=nG7kmTWsJCD&action=compose_0_savedraft&actionCount=88&debugmid=2_0_0_3_126623_AMNwimIAAC82U5ZXLwAAAFWGrR8&deb";...,
> version=0x2b865da5ace8 "HTTP/1.1", client_addr=,
> flags=) at ../lib/ts/Allocator.h:117
> #2 TSFetchCreate (contp=0x2b86821e2120, method=TS_FETCH_METHOD_POST,
> url=0x2b865d64f228
> "https://aa-mg5.mail.yahoo.com/ws/mail/v2.0/jsonrpc?appid=YahooMailNeo&m=BatchExecute&wssid=nG7kmTWsJCD&action=compose_0_savedraft&actionCount=88&debugmid=2_0_0_3_126623_AMNwimIAAC82U5ZXLwAAAFWGrR8&deb";...,
> version=0x2b865da5ace8 "HTTP/1.1", client_addr=,
> flags=) at InkAPI.cc:7289
> #3 0x005f117e in spdy_fetcher_launch (req=0x2b871c2fa900,
> method=TS_FETCH_METHOD_POST) at SpdyCallbacks.cc:187
> #4 0x005f1faa in spdy_process_syn_stream_frame (session= optimized out>, type=, frame=,
> user_data=0x2b86821e2120)
> at SpdyCallbacks.cc:295
> #5 spdy_on_ctrl_recv_callback (session=, type= optimized out>, frame=, user_data=0x2b86821e2120) at
> SpdyCallbacks.cc:335
> #6 0x00738050 in spdylay_session_on_syn_stream_received
> (session=0x2b865defce10, frame=0x2b858f987a20) at spdylay_session.c:1782
> #7 0x00738d57 in spdylay_session_process_ctrl_frame
> (session=0x2b865defce10, in=0x2b858f987a90 "\200\003", inlen= out>) at spdylay_session.c:2246
> #8 spdylay_session_mem_recv (session=0x2b865defce10, in=0x2b858f987a90
> "\200\003", inlen=) at spdylay_session.c:2805
> #9 0x00738f89 in spdylay_session_recv (session=0x2b865defce10) at
> spdylay_session.c:2828
> #10 0x005ef17b in spdy_process_read (this=0x2b86821e2120, event=100,
> edata=) at SpdyClientSession.cc:279
> #11 SpdyClientSession::state_session_readwrite (this=0x2b86821e2120,
> event=100, edata=) at SpdyClientSession.cc:236
> #12 0x0070dbd7 in handleEvent (this=0x2b86fc1d2cf0, event= optimized out>) at ../../iocore/eventsystem/I_Continuation.h:146
> #13 read_signal_and_update (this=0x2b86fc1d2cf0, event=)
> at UnixNetVConnection.cc:138
> #14 UnixNetVConnection::readSignalAndUpdate (this=0x2b86fc1d2cf0,
> event=) at UnixNetVConnection.cc:914
> #15 0x006fe66f in SSLNetVConnection::net_read_io
> (this=0x2b86fc1d2cf0, nh=0x2b858d46bbf0, lthread=0x2b858d468010) at
> SSLNetVConnection.cc:294
> #16 0x00705a72 in NetHandler::mainNetEvent (this=0x2b858d46bbf0,
> event=, e=) at UnixNet.cc:399
> #17 0x007323ef in handleEvent (this=0x2b858d468010, e=0x2a7db30,
> calling_code=5) at I_Continuation.h:146
> #18 EThread::process_event (this=0x2b858d468010, e=0x2a7db30, calling_code=5)
> at UnixEThread.cc:145
> #19 0x00732d93 in EThread::execute (this=0x2b858d468010) at
> UnixEThread.cc:269
> #20 0x0073179a in spawn_thread_internal (a=0x2e404e0) at Thread.cc:88
> #21 0x2b835bf28851 in start_thread () from /lib64/libpthread.so.0
> #22 0x00361a0e894d in clone () from /lib64/libc.so.6
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-3046) Phase out proxy.config.ssl.number.threads and force ET_NET threads to handle SSL connections
[ https://issues.apache.org/jira/browse/TS-3046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda updated TS-3046: -- Affects Version/s: (was: 7.0.0) Fix Version/s: 7.0.0 > Phase out proxy.config.ssl.number.threads and force ET_NET threads to handle > SSL connections > > > Key: TS-3046 > URL: https://issues.apache.org/jira/browse/TS-3046 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Sudheer Vinukonda >Priority: Critical > Fix For: 7.0.0 > > > This bug is a follow up on completely phasing out ET_SSL threads (refer > TS-2574 and TS-3045). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-3045) set default value for proxy.config.ssl.number.threads to "-1", to default ET_NET threads to handle SSL connections
[ https://issues.apache.org/jira/browse/TS-3045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda updated TS-3045: -- Affects Version/s: (was: 6.0.0) Fix Version/s: 6.0.0 > set default value for proxy.config.ssl.number.threads to "-1", to default > ET_NET threads to handle SSL connections > -- > > Key: TS-3045 > URL: https://issues.apache.org/jira/browse/TS-3045 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Sudheer Vinukonda >Priority: Critical > Fix For: 6.0.0 > > > Using ET_SSL threads to handle SSL connections affects sharing origin > sessions per thread pool (refer TS-2574). This limitation is addressed in > TS-2574 which forces to use ET_NET threads for SSL connections, when > proxy.config.ssl.number.threads is configured to -1. This bug is to change > the current default value "0" for proxy.config.ssl.number.threads to "-1" to > make this the default behavior. A separate bug for release 7.0 will be opened > to phase out proxy.config.ssl.number.threads completely and always use ET_NET > threads for ssl connections -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-3032) FATAL: ats_malloc: couldn't allocate XXXXXX bytes
[
https://issues.apache.org/jira/browse/TS-3032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14110941#comment-14110941
]
Zhao Yongming commented on TS-3032:
---
I'd suggest you get some tool to log the memory usage and other history data. a
tool we used very often in tracing issues like this is
https://github.com/alibaba/tsar
https://blog.zymlinux.net/index.php/archives/251 , any other tool that can find
out the data to compare is great.
when we deal with TS-1006, I even make some excel sheet to point out that the
memory is a big problem, the more data the better
> FATAL: ats_malloc: couldn't allocate XX bytes
> -
>
> Key: TS-3032
> URL: https://issues.apache.org/jira/browse/TS-3032
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 5.0.1
>Reporter: Nikolai Gorchilov
>Assignee: Brian Geffon
> Labels: crash
> Fix For: 5.2.0
>
>
> ATS 5.0.1 under Unbuntu 12.04.4 running happily for days suddenly crashes due
> to memory allocation issue. Happens once or twice a week.
> Server is having plenty of RAM - 128G - out of which 64G+ are free. Nothing
> suspicious in dmesg.
> {noformat}
> FATAL: ats_malloc: couldn't allocate 155648 bytes
> /z/bin/traffic_server - STACK TRACE:
> /z/lib/libtsutil.so.5(+0x1e837)[0x2b6251b3d837]
> /z/lib/libtsutil.so.5(ats_malloc+0x30)[0x2b6251b40c50]
> /z/bin/traffic_server(HdrHeap::coalesce_str_heaps(int)+0x34)[0x62e834]
> /z/bin/traffic_server(http_hdr_clone(HTTPHdrImpl*, HdrHeap*,
> HdrHeap*)+0x8f)[0x62a54f]
> /z/bin/traffic_server(HttpTransactHeaders::copy_header_fields(HTTPHdr*,
> HTTPHdr*, bool, long)+0x1ae)[0x5d08de]
> /z/bin/traffic_server(HttpTransact::build_request(HttpTransact::State*,
> HTTPHdr*, HTTPHdr*, HTTPVersion)+0x5c)[0x5b280c]
> /z/bin/traffic_server(HttpTransact::HandleCacheOpenReadMiss(HttpTransact::State*)+0x2c8)[0x5c2ce8]
> /z/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
> (*)(HttpTransact::State*))+0x66)[0x58e356]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x343)[0x599c03]
> /z/bin/traffic_server(HttpSM::set_next_state()+0x238)[0x5a0528]
> /z/bin/traffic_server(HttpSM::do_hostdb_lookup()+0x27a)[0x58e84a]
> /z/bin/traffic_server(HttpSM::set_next_state()+0xd48)[0x5a1038]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x343)[0x599c03]
> /z/bin/traffic_server(HttpSM::state_api_callback(int, void*)+0x8a)[0x59c81a]
> /z/bin/traffic_server(TSHttpTxnReenable+0x141)[0x4caa51]
> /z/lib/plugins/x3me_dscp.so(http_txn_hook(tsapi_cont*, TSEvent,
> void*)+0x236)[0x2b626342b508]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x102)[0x5999c2]
> /z/bin/traffic_server(HttpSM::state_cache_open_read(int,
> void*)+0x180)[0x59b070]
> /z/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x59ad98]
> /z/bin/traffic_server(HttpCacheSM::state_cache_open_read(int,
> void*)+0x173)[0x57bbb3]
> /z/bin/traffic_server(Cache::open_read(Continuation*, INK_MD5*, HTTPHdr*,
> CacheLookupHttpConfig*, CacheFragType, char*, int)+0x616)[0x6d65a6]
> /z/bin/traffic_server(CacheProcessor::open_read(Continuation*, URL*, bool,
> HTTPHdr*, CacheLookupHttpConfig*, long, CacheFragType)+0xb0)[0x6b1af0]
> /z/bin/traffic_server(HttpCacheSM::open_read(URL*, HTTPHdr*,
> CacheLookupHttpConfig*, long)+0x83)[0x57c2d3]
> /z/bin/traffic_server(HttpSM::do_cache_lookup_and_read()+0xfb)[0x58baeb]
> /z/bin/traffic_server(HttpSM::set_next_state()+0x888)[0x5a0b78]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x343)[0x599c03]
> /z/bin/traffic_server(HttpSM::set_next_state()+0x238)[0x5a0528]
> /z/bin/traffic_server(HttpSM::set_next_state()+0x7e2)[0x5a0ad2]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x343)[0x599c03]
> /z/bin/traffic_server(HttpSM::set_next_state()+0x238)[0x5a0528]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x343)[0x599c03]
> /z/bin/traffic_server(HttpSM::state_api_callback(int, void*)+0x8a)[0x59c81a]
> /z/bin/traffic_server(TSHttpTxnReenable+0x141)[0x4caa51]
> /z/lib/plugins/cacheurl.so(+0x17dc)[0x2b6263a477dc]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x102)[0x5999c2]
> /z/bin/traffic_server(HttpSM::state_api_callback(int, void*)+0x8a)[0x59c81a]
> /z/bin/traffic_server(TSHttpTxnReenable+0x141)[0x4caa51]
> /z/lib/plugins/tslua.so(+0x596f)[0x2b626363396f]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x102)[0x5999c2]
> /z/bin/traffic_server(HttpSM::state_api_callback(int, void*)+0x8a)[0x59c81a]
> /z/bin/traffic_server(TSHttpTxnReenable+0x141)[0x4caa51]
> /z/lib/plugins/stats_over_http.so(+0x1235)[0x2b6263228235]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x102)[0x5999c2]
> /z/bin/traffic_server(HttpSM::set_next_state()+0x238)[0x5a0528
[jira] [Commented] (TS-3020) Blind Tunnel fake request URL is IPv4 only
[
https://issues.apache.org/jira/browse/TS-3020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14110912#comment-14110912
]
Patrick McGleenon commented on TS-3020:
---
Here it is - there haven't been any significant changes in this file since 3.2
{code}
>From ba734420a4adb8a2c68d917ae22dcfa287bf101b Mon Sep 17 00:00:00 2001
From: root
Date: Tue, 26 Aug 2014 17:32:02 +0100
Subject: [PATCH] fixed Blind Tunnel fake URL for IPv6
---
proxy/http/HttpTransact.cc |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/proxy/http/HttpTransact.cc b/proxy/http/HttpTransact.cc
index b41f4c1..2c6f81a 100644
--- a/proxy/http/HttpTransact.cc
+++ b/proxy/http/HttpTransact.cc
@@ -613,10 +613,9 @@ HttpTransact::HandleBlindTunnel(State* s)
HTTPVersion ver(0, 9);
s->hdr_info.client_request.version_set(ver);
- struct in_addr dest_addr;
- dest_addr.s_addr = s->state_machine->ua_session->get_netvc()->get_local_ip();
+ char new_host[INET6_ADDRSTRLEN];
+ ats_ip_ntop(s->state_machine->ua_session->get_netvc()->get_local_addr(),
new_host, sizeof(new_host));
- char *new_host = inet_ntoa(dest_addr);
s->hdr_info.client_request.url_get()->host_set(new_host, strlen(new_host));
s->hdr_info.client_request.url_get()->port_set(s->state_machine->ua_session->get_netvc()->get_local_port());
--
1.7.1
{code}
> Blind Tunnel fake request URL is IPv4 only
> --
>
> Key: TS-3020
> URL: https://issues.apache.org/jira/browse/TS-3020
> Project: Traffic Server
> Issue Type: Bug
>Affects Versions: 3.2.5
>Reporter: Patrick McGleenon
>Assignee: Leif Hedstrom
>Priority: Minor
> Fix For: 5.2.0
>
>
> HttpTransact::HandleBlindTunnel creates a fake request with HTTP version 0.9
> and CONNECT method. The URL for CONNECT used is created from destination IP
> and port - currently this is IPv4 only.
> requests with IPv6 destination IP addresses still work fine with the
> BlindTunnel since ATS is able to figure out the correct IPv6 destination from
> the Host Header of the fake URL. So this is a problem just in the ATS
> logging
> attached is a suggested patch for 3.2 - the latest version of the file hasn't
> changed much since then
> {code}
> --- trafficserver-3.2.0/proxy/http/HttpTransact.cc2014-08-15
> 16:05:40.625721000 +0100
> +++ trafficserver-3.2.0.patched/proxy/http/HttpTransact.cc2014-08-15
> 16:58:23.563658000 +0100
> @@ -615,11 +615,12 @@
>HTTPVersion ver(0, 9);
>s->hdr_info.client_request.version_set(ver);
>
> - struct in_addr dest_addr;
> - dest_addr.s_addr =
> s->state_machine->ua_session->get_netvc()->get_local_ip();
> -
> - char *new_host = inet_ntoa(dest_addr);
> + // struct in_addr dest_addr;
>
> + // dest_addr.s_addr =
> s->state_machine->ua_session->get_netvc()->get_local_ip();
> + char new_host[INET6_ADDRSTRLEN];
> + ats_ip_ntop(s->state_machine->ua_session->get_netvc()->get_local_addr(),
> new_host, sizeof(new_host));
>s->hdr_info.client_request.url_get()->host_set(new_host, strlen(new_host));
> +
>// get_local_port() returns a port number in network order
> //opwv- FastPath
>// so it needs to be converted to host order (eg, in i386 machine)
> //opwv- FastPath
>
> //s->hdr_info.client_request.url_get()->port_set(ntohs(s->state_machine->ua_session->get_netvc()->get_local_port()));
> //opwv- FastPath
> {code}
> With patch:
> IPv4:
> Aug 18 09:49:24 - INFO - + Proxy's Request +
> Aug 18 09:49:24 - INFO - -- State Machine Id: 2
> Aug 18 09:49:24 - INFO - CONNECT 10.20.51.53:443 HTTP/1.1^M
> Aug 18 09:49:24 - INFO - Host: 10.20.51.53^M
> Aug 18 09:49:24 - INFO - Connection: close^M
> Aug 18 09:49:24 - INFO - ^M
> IPv6:
> Aug 18 09:47:18 - INFO - + Proxy's Request +
> Aug 18 09:47:18 - INFO - -- State Machine Id: 0
> Aug 18 09:47:18 - INFO - CONNECT [2001:410:0:51:20d:60ff:fe9c:eec4]:443
> HTTP/1.1^M
> Aug 18 09:47:18 - INFO - Host: 2001:410:0:51:20d:60ff:fe9c:eec4^M
> Aug 18 09:47:18 - INFO - Connection: close^M
> Aug 18 09:47:18 - INFO - ^M
> without patch:
> Aug 13 14:44:45 - INFO - + Proxy's Request +
> Aug 13 14:44:45 - INFO - -- State Machine Id: 17
> Aug 13 14:44:45 - INFO - CONNECT 0.0.0.0:443 HTTP/1.1^M
> Aug 13 14:44:45 - INFO - Host: 2001:410:0:51:20d:60ff:fe9c:eec4^M
> Aug 13 14:44:45 - INFO - Connection: close^M
> Aug 13 14:44:45 - INFO - ^M
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-3021) hosting.config vs volume.config
[ https://issues.apache.org/jira/browse/TS-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14110898#comment-14110898 ] Zhao Yongming commented on TS-3021: --- the hosting and volume is the same usage? I don't think so. the volume defines the partation spliting of the storage space, and the hosting assign them to hostname. unless you want to remove the control matcher, I'd not suggest to change thire file syntax. the config file is End User Interface, and we should do carefully discuss before we take any action. changes in UI is much evil than function renames in codes > hosting.config vs volume.config > --- > > Key: TS-3021 > URL: https://issues.apache.org/jira/browse/TS-3021 > Project: Traffic Server > Issue Type: Bug > Components: Configuration >Reporter: Igor Galić > Fix For: sometime > > > it appears to me that hosting.config and volume.config have a very similar > purpose / use-case. perhaps it would be good to merge those two. > --- > n.b.: i'm not up-to-date on the plans re lua-config, but even then we'll need > to consider how to present. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (TS-3039) OCSP stapling memory leaks
[
https://issues.apache.org/jira/browse/TS-3039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach reassigned TS-3039:
---
Assignee: James Peach
> OCSP stapling memory leaks
> --
>
> Key: TS-3039
> URL: https://issues.apache.org/jira/browse/TS-3039
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, SSL
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 5.2.0
>
>
> I enabled OCSP with a self-signed certificate (ie. a simple one that doesn't
> have OCSP issuer information in it.).
> {code}
> Process: traffic_server [7506]
> Path:/opt/ats/bin/traffic_server
> Load Address:0x10a52d000
> Identifier: traffic_server
> Version: 0
> Code Type: X86-64
> Parent Process: bash [7289]
> Date/Time: 2014-08-25 09:03:27.837 -0700
> OS Version: Mac OS X 10.9.4 (13E28)
> Report Version: 7
> leaks Report Version: 2.0
> Process 7506: 81597 nodes malloced for 54675 KB
> Process 7506: 61 leaks for 2880 total leaked bytes.
> Leak: 0x7fc5ba5091f0 size=112 zone: DefaultMallocZone_0xa643000
> 0x0b3ed6c0 0x0001 0x 0x ..>.
> 0x 0x 0x0001 0x0001
> 0x 0x 0x 0x
> 0x7115f3d0 0x7fff 0x 0x ...q
> 0x 0x 0x0001 0x
> 0x 0x 0x 0x
> 0x 0x 0x 0x2000 ...
> Call stack: [thread 0x7fff727e3310]: | start | main Main.cc:1568 |
> SSLNetProcessor::start(int, unsigned long) SSLNetProcessor.cc:71 |
> SSLCertificateConfig::startup() SSLConfig.cc:326 |
> SSLCertificateConfig::reconfigure() SSLConfig.cc:342 |
> SSLParseCertificateConfiguration(SSLConfigParams const*, SSLCertLookup*)
> SSLUtils.cc:1552 | ssl_store_ssl_context(SSLConfigParams const*,
> SSLCertLookup*, ssl_user_config const&) SSLUtils.cc:1395 |
> ssl_stapling_init_cert(ssl_ctx_st*, char const*) OCSPStapling.cc:111 |
> BIO_new_file | BIO_new | CRYPTO_malloc | ats_malloc ink_memory.cc:50 | malloc
> | malloc_zone_malloc
> Leak: 0x7fc5bc8f7900 size=32 zone: DefaultMallocZone_0xa643000
> 0x0f301131 0x04550306 0x74080c03 0x2e747365 1.0...Utest.
> 0x006d6f63 0x 0x 0x com.
> Call stack: [thread 0x7fff727e3310]: | start | main Main.cc:1568 |
> SSLNetProcessor::start(int, unsigned long) SSLNetProcessor.cc:71 |
> SSLCertificateConfig::startup() SSLConfig.cc:326 |
> SSLCertificateConfig::reconfigure() SSLConfig.cc:342 |
> SSLParseCertificateConfiguration(SSLConfigParams const*, SSLCertLookup*)
> SSLUtils.cc:1531 | ssl_store_ssl_context(SSLConfigParams const*,
> SSLCertLookup*, ssl_user_config const&) SSLUtils.cc:1395 |
> ssl_stapling_init_cert(ssl_ctx_st*, char const*) OCSPStapling.cc:113 |
> PEM_ASN1_read_bio | d2i_X509_AUX | ASN1_item_d2i | ASN1_item_ex_d2i |
> asn1_template_ex_d2i | asn1_template_noexp_d2i | ASN1_item_ex_d2i |
> asn1_template_ex_d2i | asn1_template_noexp_d2i | ASN1_item_ex_d2i |
> x509_name_ex_d2i | x509_name_canon | CRYPTO_malloc | ats_malloc
> ink_memory.cc:50 | malloc | malloc_zone_malloc
> Leak: 0x7fc5bc8f7920 size=48 zone: DefaultMallocZone_0xa643000
> 0x 0x 0x 0x
> 0x 0x0003 0xbcb19af0 0x7fc5
> 0x0009 0x46455141 0x77415142 0x00035452 AQEFBQAwRT..
> Call stack: [thread 0x7fff727e3310]: | start | main Main.cc:1568 |
> SSLNetProcessor::start(int, unsigned long) SSLNetProcessor.cc:71 |
> SSLCertificateConfig::startup() SSLConfig.cc:326 |
> SSLCertificateConfig::reconfigure() SSLConfig.cc:342 |
> SSLParseCertificateConfiguration(SSLConfigParams const*, SSLCertLookup*)
> SSLUtils.cc:1531 | ssl_store_ssl_context(SSLConfigParams const*,
> SSLCertLookup*, ssl_user_config const&) SSLUtils.cc:1395 |
> ssl_stapling_init_cert(ssl_ctx_st*, char const*) OCSPStapling.cc:113 |
> PEM_ASN1_read_bio | d2i_X509_AUX | ASN1_item_d2i | ASN1_item_ex_d2i |
> asn1_template_ex_d2i | asn1_template_noexp_d2i | ASN1_item_ex_d2i |
> asn1_template_ex_d2i | asn1_template_noexp_d2i | ASN1_item_ex_d2i |
> asn1_template_ex_d2i | asn1_template_noexp_d2i | ASN1_item_ex_d2i |
> asn1_d2i_ex_primitive | asn1_ex_c2i | c2i_ASN1_OBJECT | ASN1_OBJECT_new |
> CRYPTO_malloc | ats_malloc ink_memory.cc:50 | malloc | malloc_zone_malloc
> Leak: 0x7fc5bc8f8ed0 size=48 zone: DefaultMallocZone_0xa643000
> 0x 0x 0x 0x
> 0x 0x0009 0xbc8f8f00 0x7fc5
> 0x0009 0x 0x0
[jira] [Updated] (TS-3045) set default value for proxy.config.ssl.number.threads to "-1", to default ET_NET threads to handle SSL connections
[ https://issues.apache.org/jira/browse/TS-3045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda updated TS-3045: -- Priority: Critical (was: Major) > set default value for proxy.config.ssl.number.threads to "-1", to default > ET_NET threads to handle SSL connections > -- > > Key: TS-3045 > URL: https://issues.apache.org/jira/browse/TS-3045 > Project: Traffic Server > Issue Type: Bug > Components: Core >Affects Versions: 6.0.0 >Reporter: Sudheer Vinukonda >Priority: Critical > > Using ET_SSL threads to handle SSL connections affects sharing origin > sessions per thread pool (refer TS-2574). This limitation is addressed in > TS-2574 which forces to use ET_NET threads for SSL connections, when > proxy.config.ssl.number.threads is configured to -1. This bug is to change > the current default value "0" for proxy.config.ssl.number.threads to "-1" to > make this the default behavior. A separate bug for release 7.0 will be opened > to phase out proxy.config.ssl.number.threads completely and always use ET_NET > threads for ssl connections -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-3046) Phase out proxy.config.ssl.number.threads and force ET_NET threads to handle SSL connections
[ https://issues.apache.org/jira/browse/TS-3046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda updated TS-3046: -- Description: This bug is a follow up on completely phasing out ET_SSL threads (refer TS-2574 and TS-3045). (was: This bug is a follow up on completely phasing out ET_SSL threads (refer TS-2574 and TS-3045).) Priority: Critical (was: Major) > Phase out proxy.config.ssl.number.threads and force ET_NET threads to handle > SSL connections > > > Key: TS-3046 > URL: https://issues.apache.org/jira/browse/TS-3046 > Project: Traffic Server > Issue Type: Bug > Components: Core >Affects Versions: 7.0.0 >Reporter: Sudheer Vinukonda >Priority: Critical > > This bug is a follow up on completely phasing out ET_SSL threads (refer > TS-2574 and TS-3045). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-3046) Phase out proxy.config.ssl.number.threads and force ET_NET threads to handle SSL connections
Sudheer Vinukonda created TS-3046: - Summary: Phase out proxy.config.ssl.number.threads and force ET_NET threads to handle SSL connections Key: TS-3046 URL: https://issues.apache.org/jira/browse/TS-3046 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Sudheer Vinukonda This bug is a follow up on completely phasing out ET_SSL threads (refer TS-2574 and TS-3045). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-3046) Phase out proxy.config.ssl.number.threads and force ET_NET threads to handle SSL connections
[ https://issues.apache.org/jira/browse/TS-3046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda updated TS-3046: -- Affects Version/s: 7.0.0 > Phase out proxy.config.ssl.number.threads and force ET_NET threads to handle > SSL connections > > > Key: TS-3046 > URL: https://issues.apache.org/jira/browse/TS-3046 > Project: Traffic Server > Issue Type: Bug > Components: Core >Affects Versions: 7.0.0 >Reporter: Sudheer Vinukonda > > This bug is a follow up on completely phasing out ET_SSL threads (refer > TS-2574 and TS-3045). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-3045) set default value for proxy.config.ssl.number.threads to "-1", to default ET_NET threads to handle SSL connections
Sudheer Vinukonda created TS-3045: - Summary: set default value for proxy.config.ssl.number.threads to "-1", to default ET_NET threads to handle SSL connections Key: TS-3045 URL: https://issues.apache.org/jira/browse/TS-3045 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Sudheer Vinukonda Using ET_SSL threads to handle SSL connections affects sharing origin sessions per thread pool (refer TS-2574). This limitation is addressed in TS-2574 which forces to use ET_NET threads for SSL connections, when proxy.config.ssl.number.threads is configured to -1. This bug is to change the current default value "0" for proxy.config.ssl.number.threads to "-1" to make this the default behavior. A separate bug for release 7.0 will be opened to phase out proxy.config.ssl.number.threads completely and always use ET_NET threads for ssl connections -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-3045) set default value for proxy.config.ssl.number.threads to "-1", to default ET_NET threads to handle SSL connections
[ https://issues.apache.org/jira/browse/TS-3045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda updated TS-3045: -- Affects Version/s: 6.0.0 > set default value for proxy.config.ssl.number.threads to "-1", to default > ET_NET threads to handle SSL connections > -- > > Key: TS-3045 > URL: https://issues.apache.org/jira/browse/TS-3045 > Project: Traffic Server > Issue Type: Bug > Components: Core >Affects Versions: 6.0.0 >Reporter: Sudheer Vinukonda > > Using ET_SSL threads to handle SSL connections affects sharing origin > sessions per thread pool (refer TS-2574). This limitation is addressed in > TS-2574 which forces to use ET_NET threads for SSL connections, when > proxy.config.ssl.number.threads is configured to -1. This bug is to change > the current default value "0" for proxy.config.ssl.number.threads to "-1" to > make this the default behavior. A separate bug for release 7.0 will be opened > to phase out proxy.config.ssl.number.threads completely and always use ET_NET > threads for ssl connections -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2574) Sharing server sessions per thread doesn't work when doing https to http
[ https://issues.apache.org/jira/browse/TS-2574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14110862#comment-14110862 ] Sudheer Vinukonda commented on TS-2574: --- Just wanted to emphasize that, the solution committed here is to replace ET_SSL threads with ET_NET threads when ssl_threads are configured with value "-1", which will avoid having to share origin sessions across thread pools, when doing a mixed mode (http to https) connection. The limitation of not being able to share the origin sessions correctly when using ssl_threads still exists, but, (as discussed with Leif on the irc), with the plan to eventually phase out ET_SSL altogether in 6.0 or later, that limitation will not be addressed. > Sharing server sessions per thread doesn't work when doing https to http > > > Key: TS-2574 > URL: https://issues.apache.org/jira/browse/TS-2574 > Project: Traffic Server > Issue Type: Bug > Components: HTTP, SSL >Reporter: Bryan Call >Assignee: Brian Geffon > Fix For: 5.1.0 > > Attachments: TS-2574.patch > > > When running a reverse proxy with incoming https scheme and outgoing http, > the share server sessions value of 2 doesn't work. > Since the https and http thread pools are separate after using the http > connection it will be released to the http thread. When a new https request > comes in it will look in the https threads servers session pool to make a > request to the origin even though it is a http request. Of course it will > fail the lookup since the ports wont match. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2912) HEAD transaction on stale entry deletes cache entry
[ https://issues.apache.org/jira/browse/TS-2912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14110825#comment-14110825 ] William Bardwell commented on TS-2912: -- As I said are you sure that this really fixes things? And are you sure that you want conditional headers on a HEAD request, which the patch seems to do? > HEAD transaction on stale entry deletes cache entry > --- > > Key: TS-2912 > URL: https://issues.apache.org/jira/browse/TS-2912 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: William Bardwell >Assignee: weijin > Labels: review > Fix For: 5.1.0 > > Attachments: ts-2912.try1.diff > > > On a stale cache entry a HEAD gets tunneled to the origin, but when a 200 > comes back > HttpTransact::handle_cache_operation_on_forward_server_response(State* s) > deletes the cache entry, it seems like it should just ignore it (or check > ETag/Last-Modified and maybe delete if those don't match, but not > unconditionally.) > I am seeing this with 4.2.X with a plugin fiddling with stuff, but the code > looks the same in trunk, line 4318 looks like the problem line. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-3033) reimplement management protocol
[ https://issues.apache.org/jira/browse/TS-3033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14110737#comment-14110737 ] ASF subversion and git services commented on TS-3033: - Commit e6f56c5cfbb1bb90e29f30b34845ee161a32a41b in trafficserver's branch refs/heads/master from [~amc] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=e6f56c5 ] TS-3033: Build error fixes. > reimplement management protocol > --- > > Key: TS-3033 > URL: https://issues.apache.org/jira/browse/TS-3033 > Project: Traffic Server > Issue Type: Bug > Components: Core, Management API >Reporter: James Peach >Assignee: James Peach > Fix For: 5.2.0 > > > The management protocol is hand-crafted for each message type. That's a lot > of code and it makes it unnecessarily complicated to add new message types. > Let's introduce a simple, generic marshaling format and use that everywhere. > The format I have implemented can be used for signaling traffic_server as > well, but for now this is just changing API messages to traffic_manager. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-3041) add a way to show the installation layout
[
https://issues.apache.org/jira/browse/TS-3041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14110675#comment-14110675
]
ASF subversion and git services commented on TS-3041:
-
Commit 6f49aac45d330dcabbeea339cc2e9d21a8956084 in trafficserver's branch
refs/heads/master from [~amc]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=6f49aac ]
TS-3041: Fix missing virtual destructor (make compiler happy).
> add a way to show the installation layout
> -
>
> Key: TS-3041
> URL: https://issues.apache.org/jira/browse/TS-3041
> Project: Traffic Server
> Issue Type: New Feature
> Components: Configuration, Core
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 5.2.0
>
>
> Add a new {{traffic_layout}} tool that shows the layout of the Traffic Server
> installation. Nuke the really annoying code that dumps the layout to stdout
> when you build with {--enable-debug}}.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-3041) add a way to show the installation layout
[
https://issues.apache.org/jira/browse/TS-3041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14110676#comment-14110676
]
ASF subversion and git services commented on TS-3041:
-
Commit 5772a88b9cad62eb0c1903f1dc192dc0453d821a in trafficserver's branch
refs/heads/master from [~amc]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=5772a88 ]
TS-3041: Fix build link errors.
> add a way to show the installation layout
> -
>
> Key: TS-3041
> URL: https://issues.apache.org/jira/browse/TS-3041
> Project: Traffic Server
> Issue Type: New Feature
> Components: Configuration, Core
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 5.2.0
>
>
> Add a new {{traffic_layout}} tool that shows the layout of the Traffic Server
> installation. Nuke the really annoying code that dumps the layout to stdout
> when you build with {--enable-debug}}.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
