Re: odd behaviour of transparent https proxy
Shachar, Thank you for your detailed suggestions, however I can no longer reproduce the problem; someone probably corrected it over the weekend. I'll continue the hunt when the problem reappears. > > > Seems like an ack storm, but I really can't decipher tcpdump's analysis. > Can you send me a snapshot in output mode (tcpdump -w file -s 1500)? > > Also, do traceroute to the destination you mention. Then (assuming you > have hping installed) do "hping dst -p 443 -S -L 0 -T -M 1234567" > (replace dst with the right IP address). Hit ^Z every time it gets > stuck, and let it run until you start seeing "SA" rather than "TTL > expired". This should let us see whether it's a transparent proxy > somewhere along the road. Do the same replacing 443 with 80. > > Shachar -- Dan Kenigsberghttp://www.cs.technion.ac.il/~dankenICQ 162180901 = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: odd behaviour of transparent https proxy
Dan Kenigsberg wrote: Few days ago someone (probably) did something to the transparent https proxy that buffers me from the world. Since then, I cannot access https servers. It is my problem, and not the proxy maintainers', because Windows machines seems to be immune to this. I don't really know where to start looking for an answer. All I know is that telneting to an https server causes a flood of ACKs right after the connection is established. I'd love hearing some ideas. Using FC1, kernel 2.4.22. The beginning of an extremely boring tcpdump follows. 19:27:00.568656 danken-lap.32848 > server.https: S 2458091977:2458091977(0) win 5840 (DF) [tos 0x10] 19:27:00.587290 server.https > danken-lap.32848: S 2237799451:2237799451(0) ack 2458091978 win 16384 (DF) 19:27:00.587314 danken-lap.32848 > server.https: . ack 1 win 5840 (DF) [tos 0x10] 19:27:00.589938 server.https > danken-lap.32848: . ack 1 win 16384 (DF) 19:27:00.589953 danken-lap.32848 > server.https: . ack 1 win 5840 (DF) [tos 0x10] Seems like an ack storm, but I really can't decipher tcpdump's analysis. Can you send me a snapshot in output mode (tcpdump -w file -s 1500)? Also, do traceroute to the destination you mention. Then (assuming you have hping installed) do "hping dst -p 443 -S -L 0 -T -M 1234567" (replace dst with the right IP address). Hit ^Z every time it gets stuck, and let it run until you start seeing "SA" rather than "TTL expired". This should let us see whether it's a transparent proxy somewhere along the road. Do the same replacing 443 with 80. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
odd behaviour of transparent https proxy
Few days ago someone (probably) did something to the transparent https proxy that buffers me from the world. Since then, I cannot access https servers. It is my problem, and not the proxy maintainers', because Windows machines seems to be immune to this. I don't really know where to start looking for an answer. All I know is that telneting to an https server causes a flood of ACKs right after the connection is established. I'd love hearing some ideas. Using FC1, kernel 2.4.22. The beginning of an extremely boring tcpdump follows. 19:27:00.568656 danken-lap.32848 > server.https: S 2458091977:2458091977(0) win 5840 (DF) [tos 0x10] 19:27:00.587290 server.https > danken-lap.32848: S 2237799451:2237799451(0) ack 2458091978 win 16384 (DF) 19:27:00.587314 danken-lap.32848 > server.https: . ack 1 win 5840 (DF) [tos 0x10] 19:27:00.589938 server.https > danken-lap.32848: . ack 1 win 16384 (DF) 19:27:00.589953 danken-lap.32848 > server.https: . ack 1 win 5840 (DF) [tos 0x10] 19:27:00.592834 server.https > danken-lap.32848: . ack 1 win 16384 (DF) 19:27:00.592844 danken-lap.32848 > server.https: . ack 1 win 5840 (DF) [tos 0x10] 19:27:00.596724 server.https > danken-lap.32848: . ack 1 win 16384 (DF) 19:27:00.596733 danken-lap.32848 > server.https: . ack 1 win 5840 (DF) [tos 0x10] 19:27:00.599182 server.https > danken-lap.32848: . ack 1 win 16384 (DF) 19:27:00.599192 danken-lap.32848 > server.https: . ack 1 win 5840 (DF) [tos 0x10] 19:27:00.601536 server.https > danken-lap.32848: . ack 1 win 16384 (DF) 19:27:00.601545 danken-lap.32848 > server.https: . ack 1 win 5840 (DF) [tos 0x10] 19:27:00.603536 server.https > danken-lap.32848: . ack 1 win 16384 (DF) 19:27:00.603547 danken-lap.32848 > server.https: . ack 1 win 5840 (DF) [tos 0x10] 19:27:00.605561 server.https > danken-lap.32848: . ack 1 win 16384 (DF) 19:27:00.605571 danken-lap.32848 > server.https: . ack 1 win 5840 (DF) [tos 0x10] 19:27:00.607912 server.https > danken-lap.32848: . ack 1 win 16384 (DF) 19:27:00.607922 danken-lap.32848 > server.https: . ack 1 win 5840 (DF) [tos 0x10] 19:27:00.609851 server.https > danken-lap.32848: . ack 1 win 16384 (DF) 19:27:00.609860 danken-lap.32848 > server.https: . ack 1 win 5840 (DF) [tos 0x10] 19:27:00.612200 server.https > danken-lap.32848: . ack 1 win 16384 (DF) 19:27:00.612210 danken-lap.32848 > server.https: . ack 1 win 5840 (DF) [tos 0x10] 19:27:00.614465 server.https > danken-lap.32848: . ack 1 win 16384 (DF) 19:27:00.614474 danken-lap.32848 > server.https: . ack 1 win 5840 (DF) [tos 0x10] 19:27:00.616581 server.https > danken-lap.32848: . ack 1 win 16384 (DF) 19:27:00.616590 danken-lap.32848 > server.https: . ack 1 win 5840 (DF) [tos 0x10] 19:27:00.620711 server.https > danken-lap.32848: . ack 1 win 16384 (DF) 19:27:00.620720 danken-lap.32848 > server.https: . ack 1 win 5840 (DF) [tos 0x10] 19:27:00.624248 server.https > danken-lap.32848: . ack 1 win 16384 (DF) 19:27:00.624257 danken-lap.32848 > server.https: . ack 1 win 5840 (DF) [tos 0x10] 19:27:00.627768 server.https > danken-lap.32848: . ack 1 win 16384 (DF) 19:27:00.627778 danken-lap.32848 > server.https: . ack 1 win 5840 (DF) [tos 0x10] 19:27:00.631333 server.https > danken-lap.32848: . ack 1 win 16384 (DF) 19:27:00.631343 danken-lap.32848 > server.https: . ack 1 win 5840 (DF) [tos 0x10] 19:27:00.634099 server.https > danken-lap.32848: . ack 1 win 16384 (DF) 19:27:00.634108 danken-lap.32848 > server.https: . ack 1 win 5840 (DF) [tos 0x10] 19:27:00.636764 server.https > danken-lap.32848: . ack 1 win 16384 (DF) 19:27:00.636774 danken-lap.32848 > server.https: . ack 1 win 5840 (DF) [tos 0x10] 19:27:00.638857 server.https > danken-lap.32848: . ack 1 win 16384 (DF) -- Dan Kenigsberghttp://www.cs.technion.ac.il/~dankenICQ 162180901 = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
