On 10/07/2013 2:12 a.m., x-man wrote:
Hello, recently migrated from squid 3.1.19 to 3.3.5, and under 3.1.19 I was having perfect TPROXY setup working, and now absolutely same config is failing in 3.3.5
The only change related to TPROXY between 3.1 and 3.3 is the addition of HTTP Host: header security. Squid 3.3 is not only spoofing the client IP on the outgoing traffic but is also sending any traffic which fails the Host: validation direct to the original server IP being used by the client.
This is the log I managed to get 91.239.13.61 is the web site i'm trying to open and 192.168.1.106 is my test PC IP address The browser shows error: "Error 324 (net::ERR_EMPTY_RESPONSE): The server closed the connection without sending any data." What can be the problem, and is it somehow related to this BUG #3329: --- 2013/07/09 19:39:04.523 kid1| Connection.cc(32) ~Connection: BUG #3329: Orphan Comm::Connection: local=91.239.13.61:80 remote=192.168.1.106:59222 FD 12 flags=17 ----- 2013/07/09 19:39:04.523 kid1| Intercept.cc(364) Lookup: address BEGIN: me/client= 91.239.13.61:80, destination/me= 192.168.1.106:59222 2013/07/09 19:39:04.523 kid1| TcpAcceptor.cc(264) acceptOne: Listener: local=[::]:8081 remote=[::] FD 15 flags=25 accepted new connection local=91.239.13.61:80 remote=192.168.1.106:59222 FD 12 flags=17 handler Subscription: 0x254b210*1 2013/07/09 19:39:04.523 kid1| AsyncCall.cc(18) AsyncCall: The AsyncCall httpAccept constructed, this=0x25529e0 [call141] 2013/07/09 19:39:04.523 kid1| cbdata.cc(419) cbdataInternalLock: cbdataLock: 0x21920e8=3 2013/07/09 19:39:04.523 kid1| AsyncCall.cc(85) ScheduleCall: TcpAcceptor.cc(292) will call httpAccept(local=91.239.13.61:80 remote=192.168.1.106:59222 FD 12 flags=17, flag=-1, data=0x21920e8) [call141] 2013/07/09 19:39:04.523 kid1| ModEpoll.cc(139) SetSelect: FD 15, type=1, handler=1, client_data=0x254cc58, timeout=0 2013/07/09 19:39:04.523 kid1| AsyncCallQueue.cc(51) fireNext: entering httpAccept(local=91.239.13.61:80 remote=192.168.1.106:59222 FD 12 flags=17, flag=-1, data=0x21920e8) 2013/07/09 19:39:04.523 kid1| AsyncCall.cc(30) make: make call httpAccept [call141] 2013/07/09 19:39:04.523 kid1| cbdata.cc(510) cbdataReferenceValid: cbdataReferenceValid: 0x21920e8 2013/07/09 19:39:04.523 kid1| client_side.cc(3335) httpAccept: httpAccept: local=[::]:8081 remote=[::] FD 15 flags=25: accept failure: (0) No error.
Here is the problem. For some reason Squid is encountering an error accept()'ing the new connection, but there is no system code or message available about it.
Can you try with the latest 3.3 release please? any fix which you get will be for the latest code.
2013/07/09 19:39:04.523 kid1| AsyncCallQueue.cc(53) fireNext: leaving httpAccept(local=91.239.13.61:80 remote=192.168.1.106:59222 FD 12 flags=17, flag=-1, data=0x21920e8) 2013/07/09 19:39:04.523 kid1| cbdata.cc(456) cbdataInternalUnlock: cbdataUnlock: 0x21920e8=2 2013/07/09 19:39:04.523 kid1| Connection.cc(32) ~Connection: BUG #3329: Orphan Comm::Connection: local=91.239.13.61:80 remote=192.168.1.106:59222 FD 12 flags=17 Please share your thoughts.... -- View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-3-3-5-problems-with-Tproxy-tp4660968.html Sent from the Squid - Users mailing list archive at Nabble.com.
