Sorry if this is OT, but I''m out of ideas. As of a few weeks ago I''m having trouble working on a remote computer via ssh. When I''m using pine or vim (non gui version), there is often a considerable delay (sometimes 1 sec or more!) between pressing a key and seeing the result on screen. Establishing a ssh connection is not a problem. I''m talking about a single home workstation with cable modem. Contracted bandwidth is 256Kbps, which is not great but has proven to be adequate (prior to the present issue, that is). I checked that the actual speed of transfer is consistent with the expected parameters. I have no problem browsing or downloading. I have in policy: #SOURCE DEST POLICY LOG LIMIT:BURST # LEVEL fw net ACCEPT net all DROP #info # # THE FOLLOWING POLICY MUST BE LAST # all all REJECT info #LAST LINE -- DO NOT REMOVE In rules: #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER # PORT PORT(S) DEST # LIMIT ACCEPT net:193.136.196.0/24 fw icmp 8 DROP net fw icmp 8 #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE I didn''t have the ACCEPT line, but thought it might be the problem. Is this relevant at all? And should I accept icmp from everywhere, in case signals from the ISP are being blocked? Would this be a sensible thing to do? The distribution is gentoo; shorewall 1.4.10; my ethernet card is just a RealTek, but it didn''t give me any troubles before this. I even toggled between kernel 2.6 and 2.4, in case some bad configuration is causing it. Thanks for any help. -- Jorge Almeida
On Wed, 2004-07-14 at 10:18 +0100, Jorge Almeida wrote:> In rules: > > #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER > # PORT PORT(S) DEST > # LIMIT > ACCEPT net:193.136.196.0/24 fw icmp 8 > DROP net fw icmp 8 > #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE > > I didn''t have the ACCEPT line, but thought it might be the problem. Is > this relevant at all? And should I accept icmp from everywhere, in case > signals from the ISP are being blocked? Would this be a sensible thing > to do? >ICMP types 8 and 0 (Echo Request and Reply respectively) are not necessary for normal communication. They can be blocked or allowed, there will not be any effect on TCP sessions. You do want things such as host or port unreachables so that you don''t have to wait an eternity for a connection to timeout. You don''t need to explicitly permit these as they are handled for you. -- David T Hollis <dhollis@davehollis.com>
> Sorry if this is OT, but I''m out of ideas. > > As of a few weeks ago I''m having trouble working on a remote computer > via ssh. When I''m using pine or vim (non gui version), there is often a > considerable delay (sometimes 1 sec or more!) between pressing a key and > seeing the result on screen. Establishing a ssh connection is not a > problem. > > I''m talking about a single home workstation with cable modem. Contracted > bandwidth is 256Kbps, which is not great but has proven to be adequate > (prior to > the present issue, that is). I checked that the actual speed of transfer > is consistent with the expected parameters. > I have no problem browsing or downloading. > > I have in policy: > > #SOURCE DEST POLICY LOG LIMIT:BURST > # LEVEL > fw net ACCEPT > net all DROP #info > # > # THE FOLLOWING POLICY MUST BE LAST > # > all all REJECT info > #LAST LINE -- DO NOT REMOVE > > In rules: > > #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL > RATE USER > # PORT PORT(S) DEST > # LIMIT > ACCEPT net:193.136.196.0/24 fw icmp 8 > DROP net fw icmp 8 > #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE > > I didn''t have the ACCEPT line, but thought it might be the problem. Is > this relevant at all? And should I accept icmp from everywhere, in case > signals from the ISP are being blocked? Would this be a sensible thing > to do? >Crucial information missing: was it fixed by adding the ACCEPT icmp line? ICMP is useful for traffic control, but ICMP type 8 is echo request. You''re thinking type 4, source quench. Is there other traffic from/to your home network simultaneously? If so, you should probably consider enabling quality of service to prioritize ssh over http/ftp. However, it seems just as likely that it''s your work''s firewall causing the issue, as they''re almost certainly supporting lots of traffic.> The distribution is gentoo; shorewall 1.4.10; my ethernet card is just a > RealTek, but it didn''t give me any troubles before this. I even toggled > between kernel 2.6 and 2.4, in case some bad configuration is causing > it. > > Thanks for any help. > -- > Jorge Almeida > _______________________________________________ > Shorewall-users mailing list > Post: Shorewall-users@lists.shorewall.net > Subscribe/Unsubscribe: > https://lists.shorewall.net/mailman/listinfo/shorewall-users > Support: http://www.shorewall.net/support.htm > FAQ: http://www.shorewall.net/FAQ.htm >-- Jack At Monkeynoodle.Org: It''s A Scientific Venture... "Every gun that is made, every warship launched, every rocket fired, signifies in the final sense a theft from those who hunger and are not fed, those who are cold and are not clothed." -- President Dwight D. Eisenhower, April 16, 1953
On Wed, 14 Jul 2004, Jack Coates wrote:> > Crucial information missing: was it fixed by adding the ACCEPT icmp line?Nope.> > ICMP is useful for traffic control, but ICMP type 8 is echo request. > You''re thinking type 4, source quench. > > Is there other traffic from/to your home network simultaneously? If so, > you should probably consider enabling quality of service to prioritize ssh > over http/ftp.Well, just the normal traffic. I may be browsing or something like that, but the trouble started a few weeks ago, and the amount of traffic didn''t change. And the kind of traffic involved is really lightweight (vim and pine).>However, it seems just as likely that it''s your work''s > firewall causing the issue, as they''re almost certainly supporting lots of > traffic. >Could you elaborate a bit more on that? At work (at section level, corresponding to the IPs in my rules file) we don''t have a hardware firewall, just a non-filtering hardware router. (On the other hand, at institution level all sorts of bad things can happen.) I checked with some co-workers, and they don''t have the same problem. Could this be caused by lots of infected windows boxes sharing my ISP? Thanks. -- Jorge Almeida
On Wed, 14 Jul 2004, David T Hollis wrote:> ICMP types 8 and 0 (Echo Request and Reply respectively) are not > necessary for normal communication. They can be blocked or allowed, > there will not be any effect on TCP sessions. You do want things such > as host or port unreachables so that you don''t have to wait an eternity > for a connection to timeout. You don''t need to explicitly permit these > as they are handled for you. > --Thank you, I can forget this hypothesis, then. -- Jorge Almeida
> As of a few weeks ago I''m having trouble working on a remote computer > via ssh. When I''m using pine or vim (non gui version), there is often a > considerable delay (sometimes 1 sec or more!) between pressing a key and > seeing the result on screen. Establishing a ssh connection is not a > problem.I am willing to bet that they are running _huge_ buffers/packets/frames in their system to improve downloading/streaming/such, but that does impact interactive applications. My ISP tried a similar trick until myself and a few others ''kindly'' pointed out to them that this was unacceptable according to their own terms of usage. They stopped, and interactivity response times returned to normal.
On Wed, 14 Jul 2004, j2 wrote:> I am willing to bet that they are running _huge_ buffers/packets/frames in > their system to improve downloading/streaming/such, but that does impact > interactive applications. > > My ISP tried a similar trick until myself and a few others ''kindly'' pointed > out to them that this was unacceptable according to their own terms of > usage. They stopped, and interactivity response times returned to normal. >That agrees with what one can expect from this ISP, judging by their general behavior (contacting an extraterrestrial by telephatic means is easier than contacting their *support* team by phone). (And no, changing ISP is not an easy option.) So, is there some way to verify your hypothesis? If I had some verifiable data I might be able to get it to some higher instance. A long shot but better than nothing... Thank you. -- Jorge Almeida
> That agrees with what one can expect from this ISP, judging by their > general behavior (contacting an extraterrestrial by telephatic meansis> easier than contacting their *support* team by phone). (And no,changing> ISP is not an easy option.) So, is there some way to verify your > hypothesis? If I had some verifiable data I might be able to get it to > some higher instance. A long shot but better than nothing...Well, what I did was use wondershaper to throttle bandwidth, (but downstream throttling can only be done in a rather clumsy way) and after fiddling about I was able to recover interactivity, and while it is not _proof_ of anything, it sure is indicative.
>> That agrees with what one can expect from this ISP, judging by their >> general behavior (contacting an extraterrestrial by telephatic means > is >> easier than contacting their *support* team by phone). (And no, > changing >> ISP is not an easy option.) So, is there some way to verify your >> hypothesis? If I had some verifiable data I might be able to get it to >> some higher instance. A long shot but better than nothing... > > Well, what I did was use wondershaper to throttle bandwidth, (but > downstream throttling can only be done in a rather clumsy way) and after > fiddling about I was able to recover interactivity, and while it is not > _proof_ of anything, it sure is indicative.wondershaper truly rocks. It can''t make it perfect, but it can improve things quite a bit. It''s done wonders for my VoIP. -- Jack At Monkeynoodle.Org: It''s A Scientific Venture... "Believe what you''re told; there''d be chaos if everyone thought for themselves." -- Top Dog hotdog stand, Berkeley, CA
On Thu, 15 Jul 2004, Jan Johansson wrote:> Well, what I did was use wondershaper to throttle bandwidth, (but > downstream throttling can only be done in a rather clumsy way) and after > fiddling about I was able to recover interactivity, and while it is not > _proof_ of anything, it sure is indicative.Thank you, I''ll try that. -- Jorge Almeida