[jira] [Resolved] (TS-1017) Upgrade LogHost / LogSock to IPv6.
[ https://issues.apache.org/jira/browse/TS-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll resolved TS-1017. - Resolution: Fixed Updated log collation to be IPv6 compliant. commit d876163be2c2e576f177672cf7d7b60510e1f1e Upgrade LogHost / LogSock to IPv6. -- Key: TS-1017 URL: https://issues.apache.org/jira/browse/TS-1017 Project: Traffic Server Issue Type: Improvement Components: Logging Affects Versions: 3.0.0 Reporter: Alan M. Carroll Assignee: Alan M. Carroll Fix For: 3.1.4 Remote logging should be able to work on IPv6. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1166) proxy/Stuffer.cc is not IPv6 compatible.
[ https://issues.apache.org/jira/browse/TS-1166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll resolved TS-1166. - Resolution: Fixed Assignee: Alan M. Carroll File is not used, removed. End of problem. commit db6e185899852457680752709fbf68ca58dbb251 proxy/Stuffer.cc is not IPv6 compatible. Key: TS-1166 URL: https://issues.apache.org/jira/browse/TS-1166 Project: Traffic Server Issue Type: Bug Components: Clustering Affects Versions: 3.1.3 Reporter: Alan M. Carroll Assignee: Alan M. Carroll Priority: Minor Labels: gethostbyname, ipv6 Fix For: 3.1.4 Parent IP tracking in proxy/Stuff.cc is IPv4 only. Also the use of ink_gethostbyname should be removed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1167) proxy/ParentSelection.cc is not IPv6 compliant.
[ https://issues.apache.org/jira/browse/TS-1167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll resolved TS-1167. - Resolution: Fixed Changed to use ats_ip_getbestaddrinfo. commit 441413b3a3ffc623365894ee7f9f9bc0e3119a5b proxy/ParentSelection.cc is not IPv6 compliant. --- Key: TS-1167 URL: https://issues.apache.org/jira/browse/TS-1167 Project: Traffic Server Issue Type: Bug Components: Clustering Affects Versions: 3.1.3 Reporter: Alan M. Carroll Assignee: Alan M. Carroll Priority: Minor Labels: ipv6, parent, socks Fix For: 3.1.4 setup_socks_servers is IPv4 only. It should be changed to use getaddrinfo() and handle IPv6 addresses. This may require changing ParentRecord. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1168) Remap blind tunnel handling is not IPv6 compliant
[ https://issues.apache.org/jira/browse/TS-1168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll resolved TS-1168. - Resolution: Fixed Changed to use getaddrinfo. commit ebd4601e03863e6cb30b6f020d592651e10bd642 Remap blind tunnel handling is not IPv6 compliant - Key: TS-1168 URL: https://issues.apache.org/jira/browse/TS-1168 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.1.3 Reporter: Alan M. Carroll Assignee: Alan M. Carroll Priority: Minor Labels: blind, ipv6, remap, tunnel Fix For: 3.1.4 When a blind tunnel request is received, the hostname is set as the IP address. This is hardwired for IPv4. ink_gethostbyname should be replaced by getaddrinfo and the logic made IPv6 compliant. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1138) IpMap::fill does not handle singleton, then range correctly.
[ https://issues.apache.org/jira/browse/TS-1138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll resolved TS-1138. - Resolution: Fixed IpMap::fill does not handle singleton, then range correctly. Key: TS-1138 URL: https://issues.apache.org/jira/browse/TS-1138 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.1.2 Reporter: Alan M. Carroll Assignee: Alan M. Carroll Priority: Minor Fix For: 3.1.3 If you use IpMap::fill on a singleton, and then a range, the resulting ranges can overlap the singleton. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-57) Logging: IP's being logged in text mode when binary mode enabled for logging
[ https://issues.apache.org/jira/browse/TS-57?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll resolved TS-57. --- Resolution: Fixed Fix Version/s: (was: 3.3.0) 3.1.2 Assignee: Alan M. Carroll (was: George Paul) Fixed by TS-989. Logging: IP's being logged in text mode when binary mode enabled for logging - Key: TS-57 URL: https://issues.apache.org/jira/browse/TS-57 Project: Traffic Server Issue Type: Bug Components: Logging Affects Versions: 2.0.0a Environment: All platforms Reporter: George Paul Assignee: Alan M. Carroll Priority: Trivial Fix For: 3.1.2 It was reported that IP's were being logged in text mode when binary logging was enabled. This needs to be investigated and addressed if needed. -George -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1077) HTTP ports cannot be configured for IPv6 and transparency.
[ https://issues.apache.org/jira/browse/TS-1077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll resolved TS-1077. - Resolution: Fixed Committed patch. See the attached ts-1077.txt for more detail on the changes. HTTP ports cannot be configured for IPv6 and transparency. -- Key: TS-1077 URL: https://issues.apache.org/jira/browse/TS-1077 Project: Traffic Server Issue Type: Improvement Components: HTTP Affects Versions: 3.1.1 Reporter: Alan M. Carroll Assignee: Alan M. Carroll Labels: configuration, http, ipv6, ports Fix For: 3.1.2 Attachments: ts-1077.diff, ts-1077.txt The syntax of records.config has IPv6 and transparency as mutually exclusive options. This should be changed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1088) Allow Per-transaction Transparency (TProxy) Override
[ https://issues.apache.org/jira/browse/TS-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll resolved TS-1088. - Resolution: Fixed Commit 1236723. Changed function to TSHttpTxnOutgoingTransparencySet to be more consistent. Allow Per-transaction Transparency (TProxy) Override Key: TS-1088 URL: https://issues.apache.org/jira/browse/TS-1088 Project: Traffic Server Issue Type: New Feature Components: HTTP, TS API Affects Versions: 3.1.0 Environment: The feature was built on top of a 3.1.0 release candidate, however only minor adjustments are needed for HEAD Reporter: B Wyatt Assignee: Alan M. Carroll Fix For: 3.1.2 Attachments: tsapi-allow-transparency.patch Address level transparency (using TProxy) is propagated forward from the incoming connection based on global configuration. This feature allows internal and external systems that use the TS api to disable propagation on a per transaction basis. The result is that the client=proxy connection transparently appears as a client=origin server connection and the proxy=origin server connection is opaque. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1089) Allow Plugins to create transparent internal http connections
[ https://issues.apache.org/jira/browse/TS-1089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll resolved TS-1089. - Resolution: Fixed Commit 1236915. Allow Plugins to create transparent internal http connections - Key: TS-1089 URL: https://issues.apache.org/jira/browse/TS-1089 Project: Traffic Server Issue Type: New Feature Components: TS API Affects Versions: 3.1.0 Environment: This feature was built on top of a 3.1.0 release candidate. Unfortunately, it will superficially conflict with the IPv6 changes (I'm including it in case someone needs to update it before I do) Reporter: B Wyatt Assignee: Alan M. Carroll Fix For: 3.1.2 Attachments: trans-pluginvc.patch, ts-1089.diff Plugins can create a fake connection HTTP connection into the proxy and provide a logging address. This feature allows those connections to appear to the rest of trafficsever as incoming transparent connections (such as the ones accepted by tproxy enabled installations). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-693) Automatic Navigation links should point at the EN version if the current language isn't available.
[ https://issues.apache.org/jira/browse/TS-693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll resolved TS-693. Resolution: Fixed This was fixed during the last auto-navigation update. Automatic Navigation links should point at the EN version if the current language isn't available. -- Key: TS-693 URL: https://issues.apache.org/jira/browse/TS-693 Project: Traffic Server Issue Type: Bug Components: Documentation Affects Versions: 2.1.7 Reporter: Alan M. Carroll Assignee: Alan M. Carroll Priority: Minor Fix For: Doc 3.0 If we have a page in the documentation that available in a non-EN language (e.g. ZW), then where should the generated Next/Back links point if there is not a ZW version of those targets? Currently they aren't available. Instead, the links should point at the EN version if the same language target doesn't exist. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1022) LogEntryHeader is a serialized structure but uses vague types.
[ https://issues.apache.org/jira/browse/TS-1022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll resolved TS-1022. - Resolution: Fixed Changed LogBufferHeader and LogBufferEntry to use size specific types. Should should make the data more portable. r1204112 LogEntryHeader is a serialized structure but uses vague types. -- Key: TS-1022 URL: https://issues.apache.org/jira/browse/TS-1022 Project: Traffic Server Issue Type: Bug Components: Logging Affects Versions: 3.1.0 Reporter: Alan M. Carroll Assignee: Alan M. Carroll Priority: Minor Fix For: 3.1.2 LogEntryHeader in proxy/logging/LogBuffer.h uses the type long and unsigned even though is used directly as serialized data. This means (among other things) that binary logs have different formats depending on whether ATS was built in 32 bit mode or 64 bit mode. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-982) TSHttpTxnClientAddrGet provides malformed sockaddr_in
[ https://issues.apache.org/jira/browse/TS-982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll resolved TS-982. Resolution: Fixed Changed to use ink_inet_ip4_set which handles the issue. However, checking the original code it looks like the API expects host order input. I added comments to the header to make this clear. r1197187 TSHttpTxnClientAddrGet provides malformed sockaddr_in - Key: TS-982 URL: https://issues.apache.org/jira/browse/TS-982 Project: Traffic Server Issue Type: Bug Affects Versions: 3.0.1 Reporter: William Bardwell Assignee: Alan M. Carroll Priority: Minor Fix For: 3.1.1 It looks like PluginVCCore::set_passive_addr() and set_active_addr() never set the address family. And the address and port look like they are getting byte swapped. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1010) strlcpy breaks WCCP Security
[ https://issues.apache.org/jira/browse/TS-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll resolved TS-1010. - Resolution: Fixed Fix Version/s: 3.1.1 Changed back to strncpy. strlcpy breaks WCCP Security Key: TS-1010 URL: https://issues.apache.org/jira/browse/TS-1010 Project: Traffic Server Issue Type: Bug Components: Network Affects Versions: 3.1.0 Reporter: Alan M. Carroll Assignee: Alan M. Carroll Labels: wccp Fix For: 3.1.1 The requirements for WCCP security key handling are precisely those of strncpy - * The buffer must be zero padded. * The terminating nul must *not* be copied if the key fills the buffer. Rather than doing something complex with strlcpy to satisfy these requirements it is much easier to simply use strncpy. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-984) LogFile::roll crash at Machine::instance
[
https://issues.apache.org/jira/browse/TS-984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll resolved TS-984.
Resolution: Fixed
LogFile::roll crash at Machine::instance
Key: TS-984
URL: https://issues.apache.org/jira/browse/TS-984
Project: Traffic Server
Issue Type: Bug
Components: Logging
Affects Versions: 3.1.0
Reporter: Zhao Yongming
Assignee: Alan M. Carroll
Labels: crash
Fix For: 3.1.1
Attachments: ts-984.diff
this is a strange error when I testing the current trunk with logging
colation server enabled:
{code}
[Oct 16 01:24:48.643] Server {0x2b4967f51760} WARNING: File
/var/log/trafficserver/ex_squid.log will be rolled because a LogObject with
different format is requesting the same filename
FATAL: Machine.cc:37: failed assert `_instance || !Machine instance accessed
before initialization`
/usr/bin/traffic_server - STACK TRACE:
/usr/lib64/trafficserver/libtsutil.so.3(ink_fatal_va+0xc5)[0x2b49651a5109]
/usr/lib64/trafficserver/libtsutil.so.3(ink_fatal+0xa3)[0x2b49651a51bb]
/usr/lib64/trafficserver/libtsutil.so.3(_ink_assert+0xc2)[0x2b49651a3aee]
/usr/bin/traffic_server(Machine::instance()+0x24)[0x634a04]
/usr/bin/traffic_server(LogFile::roll(long, long)+0x230)[0x5f8138]
/usr/bin/traffic_server(LogObjectManager::_solve_filename_conflicts(LogObject*,
int)+0x489)[0x603263]
/usr/bin/traffic_server(LogObjectManager::_manage_object(LogObject*, bool,
int)+0x126)[0x6029ea]
/usr/bin/traffic_server(LogObjectManager::manage_object(LogObject*,
int)+0x2d)[0x5e9e27]
/usr/bin/traffic_server(LogConfig::read_xml_log_config(int)+0x3189)[0x5f28c9]
/usr/bin/traffic_server(LogConfig::setup_log_objects()+0x229)[0x5edd63]
/usr/bin/traffic_server(LogConfig::init(LogConfig*)+0x254)[0x5ec3ea]
/usr/bin/traffic_server(Log::init(int)+0x30c)[0x5e8134]
/usr/bin/traffic_server(main+0xb6a)[0x5161a4]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x2b49673b4ebd]
/usr/bin/traffic_server[0x4cc789]
{code}
there is two problem here:
1, why the machine is not initialized?
2, what does WARNING: File /var/log/trafficserver/ex_squid.log will be
rolled because a LogObject with different format is requesting the same
filename mean? is that harm?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-989) Update logging to be IPv6 compatible.
[ https://issues.apache.org/jira/browse/TS-989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll resolved TS-989. Resolution: Fixed Update logging to be IPv6 compatible. - Key: TS-989 URL: https://issues.apache.org/jira/browse/TS-989 Project: Traffic Server Issue Type: Improvement Components: Logging Affects Versions: 3.1.0 Reporter: Alan M. Carroll Assignee: Alan M. Carroll Labels: ipv6, logging Fix For: 3.1.2 Change logging to support IPv6 data. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-695) Should have notation for including all generated navigation links.
[
https://issues.apache.org/jira/browse/TS-695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll resolved TS-695.
Resolution: Fixed
Committed updated nav generator logic which should fix this.
Should have notation for including all generated navigation links.
--
Key: TS-695
URL: https://issues.apache.org/jira/browse/TS-695
Project: Traffic Server
Issue Type: Bug
Components: Documentation
Affects Versions: 2.1.7
Reporter: Alan M. Carroll
Assignee: Alan M. Carroll
Priority: Minor
Fix For: Doc 3.0
Add the notation for Navigation links so that '[*](*)' means add all
generated Navigation links that haven't already been specified here. So if
the user specified links were [Next](*) [Elsewhere](http:/...) [*](*) then
potentially Back and Top would be added after Elsewhere but Next
would not.
Read '(' '*' ')' for (*). Freakin' smilies.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-988) Upgrade ICP support for IPv6
[ https://issues.apache.org/jira/browse/TS-988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll resolved TS-988. Resolution: Fixed ID10T error. Double bonus because I forgot that the regression tests don't detect problems in traffic_manager. Should be working now, I was able to replicate the problem and fix it locally. Upgrade ICP support for IPv6 Key: TS-988 URL: https://issues.apache.org/jira/browse/TS-988 Project: Traffic Server Issue Type: Improvement Components: Clustering Affects Versions: 3.1.0 Reporter: Alan M. Carroll Assignee: Alan M. Carroll Priority: Minor Labels: icp, ipv6 Fix For: 3.1.2 Make ICP compatible with IPv6. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-988) Upgrade ICP support for IPv6
[ https://issues.apache.org/jira/browse/TS-988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll resolved TS-988. Resolution: Fixed Upgrade ICP support for IPv6 Key: TS-988 URL: https://issues.apache.org/jira/browse/TS-988 Project: Traffic Server Issue Type: Improvement Components: Clustering Affects Versions: 3.1.0 Reporter: Alan M. Carroll Assignee: Alan M. Carroll Priority: Minor Labels: icp, ipv6 Fix For: 3.1.2 Make ICP compatible with IPv6. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-991) WCCP can stall during a restart.
[ https://issues.apache.org/jira/browse/TS-991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll resolved TS-991. Resolution: Fixed Fix Version/s: (was: 3.1.2) 3.1.1 Changed view update logic to generate an assignment if the last reported time of a cache in the view is not the time of the last packet (so the cache has left and returned to the view in the router's opinion but not in the client's opinion). WCCP can stall during a restart. Key: TS-991 URL: https://issues.apache.org/jira/browse/TS-991 Project: Traffic Server Issue Type: Bug Components: Management Affects Versions: 3.1.0 Reporter: Alan M. Carroll Assignee: Alan M. Carroll Labels: wccp Fix For: 3.1.1 If the WCCP router uses an identifying IP address which is not the same as the source IP address on the packet (which is allowed by the WCCP spec) then the TS client side WCCP code can fail to properly generate an assignment. This happens during a window after a restart when TS is trying to set up the WCCP view while the router has not yet realized TS has restarted. The client WCCP logic then soft stalls and doesn't generate a new assignement when the router responses are processed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-934) Proxy Mutex null pointer crash
[ https://issues.apache.org/jira/browse/TS-934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll resolved TS-934. Resolution: Fixed Patch committed 1187108. This reduces the problem but may not be a complete fix. It improves the situation enough to use but we may need to re-open this bug later. Proxy Mutex null pointer crash -- Key: TS-934 URL: https://issues.apache.org/jira/browse/TS-934 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.1.0 Environment: Debian 6.0.2 quadcore, forward transparent proxy. Reporter: Alan M. Carroll Assignee: Alan M. Carroll Fix For: 3.1.2 Attachments: ts-934-patch.txt [Client report] We had the cache crash gracefully twice last night on a segfault. Both times the callstack produced by trafficserver's signal handler was: /usr/bin/traffic_server[0x529596] /lib/libpthread.so.0(+0xef60)[0x2ab09a897f60] [0x2ab09e7c0a10] usr/bin/traffic_server(HttpServerSession::do_io_close(int)+0xa8)[0x567a3c] /usr/bin/traffic_server(HttpVCTable::cleanup_entry(HttpVCTableEntry*)+0x4c)[0x56aff6] /usr/bin/traffic_server(HttpVCTable::cleanup_all()+0x64)[0x56b07a] /usr/bin/traffic_server(HttpSM::kill_this()+0x120)[0x57c226] /usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0x208)[0x571b28] /usr/bin/traffic_server(Continuation::handleEvent(int, void*)+0x69)[0x4e4623] I went through the disassembly and the instruction that it is on in ::do_io_close is loading the value of diags (not dereferencing it) so it is unlikely that that through a segfault (unless this is some how in thread local storage and that is corrupt). The kernel message claimed that the instruction pointer was 0x4e438e which in this build is in ProxyMutexPtr::operator -() on the instruction that dereferences the object pointer to get the stored mutex pointer (bingo!), so it would seem that at some point we are dereferencing a null safe pointer. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-963) ip_allow.config parsing bug
[
https://issues.apache.org/jira/browse/TS-963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll resolved TS-963.
Resolution: Fixed
r1183051
ip_allow.config parsing bug
---
Key: TS-963
URL: https://issues.apache.org/jira/browse/TS-963
Project: Traffic Server
Issue Type: Bug
Components: Configuration
Affects Versions: 3.1.0
Environment: CentOS 5.5 64-bit
Reporter: David Eagen
Assignee: Alan M. Carroll
Fix For: 3.1.1
The ip_allow.config file is not read correctly. It appears that later lines
replace earlier lines if the IP ranges overlap. So, a config file like this
does not result in the desired range being allowed. Instead, only the reject
line is used. This can be confirmed by enabling debug logging.
src_ip=172.16.11.0-172.16.19.255action=ip_allow
more allow ranges ...
src_ip=0.0.0.0-255.255.255.255 action=ip_deny
This configuration results in the following debug log:
[Sep 20 15:06:52.348] Server {0x2b19b4be3d70} DEBUG: (ip-allow) 1 ACL entries.
Line 33: deny 0.0.0.0 - 255.255.255.255
Commenting out the global deny line results in:
[Sep 20 15:14:11.247] Server {0x2b3458cf7d70} DEBUG: (ip-allow) 8 ACL entries.
Line 16: allow 172.16.3.0 - 172.16.3.255
Line 30: allow 172.16.79.21 - 172.16.79.26
Client IP's outside the allow range are denied by default. So I can still
implement the same thing but not with the same configuration used in previous
versions of ATS. Also, The documentation indicates that the line is parsed
from the top down so that the first entry matching the connecting host is
used but it does not function that way.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-938) Our outgoing (request) Via: header seems to always default to 127.0.0.1 as the IP identifier
[ https://issues.apache.org/jira/browse/TS-938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll resolved TS-938. Resolution: Fixed Our outgoing (request) Via: header seems to always default to 127.0.0.1 as the IP identifier Key: TS-938 URL: https://issues.apache.org/jira/browse/TS-938 Project: Traffic Server Issue Type: Bug Components: Network Affects Versions: 3.1.0 Reporter: Leif Hedstrom Assignee: Alan M. Carroll Fix For: 3.1.1 This can cause serious problems, because if the other end is also an ATS server, also defaulting to thinking it's on 127.0.0.1, will treat this as a loop, and send a 400 response. We ought to try to send something more intelligent as the hex-IP in the request Via: header. This is particularly problematic when ATS is used as a forward (or intercepting) proxy, and have outgoing Via: headers enabled. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-926) Enable IPv6 in HTTP handling.
[ https://issues.apache.org/jira/browse/TS-926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll resolved TS-926. Resolution: Fixed Enable IPv6 in HTTP handling. - Key: TS-926 URL: https://issues.apache.org/jira/browse/TS-926 Project: Traffic Server Issue Type: Improvement Components: HTTP Affects Versions: 3.0.1 Reporter: Alan M. Carroll Assignee: Alan M. Carroll Labels: ipv6 Fix For: 3.1.1 Having put most of the infrastructure in place, the next step is to enable IPv6 for actually HTTP transactions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
