Hi
I am hoping to run Linux at work, however I am in a M$ shop. They have a M$
proxy server, which currently functions using Winsock, but the socks proxy does
not seem to work. I do not get challenged for a user/name and domain when I try
and access the proxy, and the firewally guy is not too keen on solving the
problem.
Any ideas on what I can do without having access to the proxy server myself. I
know my linux box is working because I can get out via other protocols than
HTTP. I talked them into giving me ftp, telnet etc... but he is not keen on
HTTP.
Cheers!
Andrew
|-------------------|
| [ ] High priority |
|-------------------|
BAA e-mail
|--------------------|
| [ ] Return Receipt |
|--------------------|
2 July 1999 06:18
From: Jan Kratochvil <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc: (bcc: Andrew J Sear/IT/LHR/BAA)
Subject: TCP/IP kernel stack problem
Hi
Right after restarting PPP interface the following TCP/IP agony occured
on the connection (which was probably closing that time) right during the
2 minute temporary drop of both PPP links noted below. The connection
was from "ssh" (with SO_KEEPALIVE flag set).
linux-2.2.10 machine is behind masquerade of linux-2.3.9 but the ACKs are
going even between these two hosts:
'client' 'masquerading' 'server'
linux-2.2.10 --(MAQUERADING)-- linux-2.3.9 --(outer line)-- linux-2.0.35
^^^ even here are ACKs hogging
Netstat from client linux-2.2.10 machine:
-------------------------------------------------------------------------------
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program
name
tcp 0 221 linux-2.2.10:1019 linux-2.0.35:22 FIN_WAIT1 -
-------------------------------------------------------------------------------
As you can see Send-Q is not empty and both sides are hogging the line (not
the 100% capacity of it - only very fast periodically). Also the rate of ACKs
is slowly increasing (it approx. doubled after I wrote this mail up to here).
No other communication (except NTP updates) is running on this line.
Tcpdump from client linux-2.2.10 machine:
-------------------------------------------------------------------------------
18:47:50.575617 linux-2.0.35.22 > linux-2.2.10.1019: . ack 1644304467 win 32736
(DF) [tos 0x10]
18:47:50.585605 linux-2.2.10.1019 > linux-2.0.35.22: . ack 1107997898 win 32256
(DF) [tos 0x10]
18:47:50.595609 linux-2.0.35.22 > linux-2.2.10.1019: . ack 1 win 32736 (DF) [tos
0x10]
18:47:50.605593 linux-2.2.10.1019 > linux-2.0.35.22: . ack 1107997898 win 32256
(DF) [tos 0x10]
18:47:50.875612 linux-2.0.35.22 > linux-2.2.10.1019: . ack 1 win 32736 (DF) [tos
0x10]
18:47:50.875673 linux-2.2.10.1019 > linux-2.0.35.22: . ack 1107997898 win 32256
(DF) [tos 0x10]
-------------------------------------------------------------------------------
and so on...
Attached is this dump in tcpdump libpcap packet capture format.
/proc/net/ip_masquerade from masquerading linux-2.3.9 machine:
-------------------------------------------------------------------------------
Prc FromIP FPrt ToIP TPrt Masq Init-seq Delta PDelta Expires
(free=40960,40958,40960)
TCP 0A064201:03FB C3711F7B:0016 EE48 00000000 0 0 90000
-------------------------------------------------------------------------------
Netstat from server linux-2.0.35 machine:
-------------------------------------------------------------------------------
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 72 linux-2.0.35:22 linux-2.3.9:61000 ESTABLISHED
-------------------------------------------------------------------------------
After writing this mail, it all fortunately suddenly stopped. I don't have
the record how the double-ACK from above transformed into this single-ACK
stream:
Tcpdump from client linux-2.2.10 machine:
A lot of the same ACKs and ...
-------------------------------------------------------------------------------
19:02:44.224007 linux-2.0.35.22 > linux-2.2.10.1019: . ack 4119390369 win 32736
(DF) [tos 0x10]
19:02:44.254002 linux-2.0.35.22 > linux-2.2.10.1019: . ack 4119390369 win 32736
(DF) [tos 0x10]
19:02:44.264010 linux-2.0.35.22 > linux-2.2.10.1019: . ack 4119390369 win 32736
(DF) [tos 0x10]
19:02:44.464006 linux-2.0.35.22 > linux-2.2.10.1019: . ack 4119390369 win 32736
(DF) [tos 0x10]
19:03:10.393537 linux-2.0.35.22 > linux-2.2.10.1019: P 3186969399:3186969451(52)
ack 4119390369 win 32736 (DF) [tos 0x10]
19:05:10.290858 linux-2.0.35.22 > linux-2.2.10.1019: P 3186969399:3186969451(52)
ack 4119390369 win 32736 (DF) [tos 0x10]
19:05:10.290952 linux-2.2.10.1019 > linux-2.0.35.22: R 1644304467:1644304467(0)
win 0 [tos 0x10]
-------------------------------------------------------------------------------
Lace
PS: Please gimme a CC as I'm not on this list. And I'm not able to provide
further info from this connection as it was apparently resetted. Ignore
this mail if the bug report is not useful.
The information contained in this e-mail is intended only for the
person or entity to which it is addressed and may contain confidential
and / or privileged material. If you are not the intended recipient
of this e-mail, the use of this information or any disclosure,
copying or distribution is prohibited and may be unlawful.
If you received this in error, please contact the sender
and delete the material from any computer.
snap.gz
Andrew J Sear
