Search squid archive

invalid request problem with wireshark capturing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
   






[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux