On Sat, Feb 13, 2010 at 4:13 AM, Amos Jeffries <squid3_at_treenet.co.nz> wrote:
> Jeff Foster wrote:
>>
>> On Thu, Feb 11, 2010 at 6:09 PM, Amos Jeffries <squid3_at_treenet.co.nz>
>> wrote:
>>>
>>> Jeff Foster wrote:
>>>>>>
>>>>>> There appears to be a problem with the connection pinning in both
>>>>>> versions squid-2.7.stable7 and
>>>>>> squid-3.1.0.7. I have some network captures that show the client
>>>>>> (IE6) creating multiple TCP
>>>>>> connections to the squid proxy and the proxy creating multiple TCP
>>>>>> connections to an IIS server.
>>>>
>>>> ....
>>>>>>
>>>>>> I have tcpdump traces for both versions available.
>>>>>>
>>>>>> In the 3.1 dump summary, note that the client packet 207 is the server
>>>>>> packet 210.
>>>>>> The server should be on port 37159 and it is on port 37161.
>>>>>>
>>>>>> Can a developer look at this?
>>>>>
>>>>> There are quite a few pinning issues resolved since 3.1.0.7 (beta) was
>>>>> released.
>>>>> Try 3.1.0.16 beta.
>>>>>
>>>>> Amos
>>>>>
>>>> Sorry I mis-typed, I am running version 3.1.0.16.
>>>>
>>>> Not sure how connection pinning works. Does it tie a client TCP socket
>>>> to an upstream TCP socket? Or does it tie a client URL to an upstream
>>>> socket?
>>>>
>>>> Jeff F>
>>>
>>> 'tis complicated.
>>>
>>> The simplest view is that it ties a client TCP link, to a destination
>>> domain
>>> name.
>>>
>>> Warning, technical details ahead. As I understand it...
>>>
>>> It ties each input triplet (client TCP link, client IP, destination
>>> domain
>>> name) which has been NTLM or Kerberos auth "signed" by an auth
>>> request/challenge passing through them to a particular output pair
>>> (server
>>> TCP link, destination domain) where the auth challenge was answered
>>> correctly.
>>> It stays tied as long as both links are open.
>>>
>>>
>>> Requires persistent connections to be ON for both servers and clients.
>>>
>>> Requires http_port connection-auth=on or =auto
>>>
>>> Requires any cache_peer involved to also have connection-auth=on or =auto
>>>
>>> These last two requirements are met by default in Squid-3.1.
>>>
>> I have spent some time debugging and looking at the code and I don't
>> see how a client TCP connection is tied to an upstream TCP connection.
>> Can you point me to the code? I have looked at the client_side.cc
>> in both 2.7 and 3.1 and don't understand how the client port factors
>> into picking the upstream port.
>>
>> The original message has a tcpdump where the request comes in on
>> client source port 1919 and should go out to the upstream on port 37159
>> but is sent from port 37161.
>
> Must have been omitted. squid-users does not permit attachments AFAICT.
>
>
> The TCP link state is held by ConnStateData
> ConnStateData::pinning::*
> ConnStateData::pinConnection()
> ConnStateData::unpinConnection()
>
> pinned server connections are omitted from the general persistent
> connections cache on request completion. So they are never up for
> consideration for use by other clients while pinned.
>
> peer_select.cc pulls the server connection handle out of the ConnStateData
> for selection as priority over everything else for forward.cc to use as its
> destination.
>
> Amos
> --
> Please be using
> Current Stable Squid 2.7.STABLE8 or 3.0.STABLE24
> Current Beta Squid 3.1.0.16
>
The trace summary was at the bottom of the initial email. I am
including it here.
The summary includes packet number, time, source port and request info.
The problem is with packet 210 in the 'Server' (upstream) list.
The client requests '/simon/EFSM/efms.css' in packet #163 from port 1918.
This client connection has already been authenticated in client packets 85,
144, 157.
The second request for '/EFSM/efms.css' is in packet #207 from port 1919.
That request has the second stage of the NTLM authentication. If all client
connections were 'pinned', the request should come from port 37159 to
reach the server. It is coming from port 37161.
I can supply the original trace file if you would like to see it.
Client Packet summary
No. Time Src Info
7 0.001648 1916 GET http://simon/efms/ HTTP/1.0
16 0.559067 1916 GET http://simon/efms/ HTTP/1.0, NTLMSSP_NEGOTIATE
21 0.752159 1916 GET http://simon/efms/ HTTP/1.0, NTLMSSP_AUTH, User: WG
42 1.576078 1917 GET http://simon/efms/ HTTP/1.0
65 1.961280 1917 GET http://simon/efms/ HTTP/1.0, NTLMSSP_NEGOTIATE
70 2.151384 1917 GET http://simon/efms/ HTTP/1.0, NTLMSSP_AUTH, User: WG
85 2.991803 1918 GET http://simon/EFMS/efms.js HTTP/1.0
144 3.370616 1918 GET http://simon/EFMS/efms.js HTTP/1.0, NTLMSSP_NEGOTIA
157 3.560971 1918 GET http://simon/EFMS/efms.js HTTP/1.0, NTLMSSP_AUTH, U
163 3.780493 1918 GET http://simon/EFMS/efms.css HTTP/1.0
171 3.781469 1919 GET http://simon/Styles/perry_fix_font.css HTTP/1.0
174 3.781643 1920 GET http://simon/Styles/forms.css HTTP/1.0
179 3.782358 1921 GET http://simon/styles/dashboard.css HTTP/1.0
195 3.969630 1918 GET http://simon/javascript/std.js HTTP/1.0
207 4.161036 1919 GET http://simon/EFMS/efms.css HTTP/1.0, NTLMSSP_NEGOTI
Server (upstream) packet summary
No. Time Src Info
12 0.369931 37156 GET /efms/ HTTP/1.0
18 0.559496 37156 GET /efms/ HTTP/1.0, NTLMSSP_NEGOTIATE
23 0.752534 37156 GET /efms/ HTTP/1.0, NTLMSSP_AUTH, User: WGC\jfoste
61 1.758489 37157 GET /efms/ HTTP/1.0
67 1.961708 37157 GET /efms/ HTTP/1.0, NTLMSSP_NEGOTIATE
72 2.152100 37157 GET /efms/ HTTP/1.0, NTLMSSP_AUTH, User: WGC\jfoste
113 3.180079 37158 GET /EFMS/efms.js HTTP/1.0
146 3.371116 37158 GET /EFMS/efms.js HTTP/1.0, NTLMSSP_NEGOTIATE
159 3.561335 37158 GET /EFMS/efms.js HTTP/1.0, NTLMSSP_AUTH, User: WGC\jfo
168 3.781256 37158 GET /EFMS/efms.css HTTP/1.0
190 3.967221 37159 GET /Styles/perry_fix_font.css HTTP/1.0
191 3.967513 37160 GET /Styles/forms.css HTTP/1.0
192 3.967791 37161 GET /styles/dashboard.css HTTP/1.0
197 3.970336 37158 GET /javascript/std.js HTTP/1.0
210 4.161855 37161 GET /EFMS/efms.css HTTP/1.0, NTLMSSP_NEGOTIATE
Jeff F>
Received on Sat Feb 13 2010 - 20:17:25 MST
This archive was generated by hypermail 2.2.0 : Sun Feb 14 2010 - 12:00:05 MST