[squid-users] invalid request problem with wireshark capturing

hi still the problem of invalid request problem exist in my caches server, i will explain this problem with more deletes here hopping there is some thing i don't know about in squid solve this problem as a trying i did capturing to the invalid request and the captured packet deletes is Frame 4139: 110 bytes on wire (880 bits), 110 bytes captured (880 bits) Arrival Time: Mar 13, 2012 11:53:02.536140000 AST Epoch Time: 1331628782.536140000 seconds Time delta from previous captured frame: 0.008177000 seconds Time delta from previous displayed frame: 0.008177000 seconds Time since reference or first frame: 51.377354000 seconds Frame Number: 4139 Frame Length: 110 bytes (880 bits) Capture Length: 110 bytes (880 bits) Frame is marked: False Frame is ignored: False Protocols in frame: eth:ip:tcp:http:data Coloring Rule Name: HTTP Coloring Rule String: http || tcp.port == 80 Internet Protocol, Src: 192.168.40.3 (192.168.40.3), Dst: 10.10.10(10.10.10.53) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) Total Length: 96 Identification: 0x23e0 (9184) Flags: 0x02 (Don't Fragment Fragment offset: 0 Time to live : 127 Protocol : TCP (6) Header checksum: 0xdacd [correct] source 10.10.10.53 (10.10.10.53 Destination: 192.168.40.3 (192.168.40.3) Transmission Control Protocol, Src Port:49869 (49869), Dst Port: http (80), seq: Source port: 49869 (49869) Destination port: http (80) [Stream index: 240] Sequence number: 1 (relative squence number) [NEXT squence number: 57 (relative sequence number)] Acknowledgement number: 1 (relative ack number) Header length: 20 bytes Flags: 0x18 (PSH, ACK) window size: 17520 (scaled) Checksum: 0xba28 [validation disabled] [SEQ/ACK analysis] *Hypertext Transfer Protocol   *DATA (56 bytes)    Data:0569ff24fdd6dbd18ffe4d2f2fffaa9020alae217a53923a..     [Length: 56] the squid is recognize the ips of the client in the access.log file, the policy routing in mikrotik done using the dstnat rule, what ever packets comes from any source ip address except the ip of the cache server in the tcp port at port 80 is distend to the ip address of the cache port 80 to be a clear it's the same as this linux rule this rule is for clearance not applied in the linux iptables (because i don't know who to explain to you what i did in mikrotik router) iptables -t nat -A PREROUTING -p tcp --dport 80 ! -s 192.168.40.2 -j DNAT --to-destination 192.168.40.2:80 where 192.168.40.2 is the ip of the cache server if the problem is with sending ssl request to the cache server through the 80 port but why this happening this type of traffic should work on port number 433 so the mikrotik rule does not applied for this type of traffic and this traffic is directed to the internet directly, i hope i was clear in describing the problem thanks with my best regards
Received on Wed Mar 14 2012 - 19:04:00 MDT