I'm unable to access some https sites for some reason. I can access https://mail.google.com for example, but not my banking site, or another encrypted site. I turned off iptables but still no luck. I also went in the GUI and turned off the firewall from there (isn't that also iptables?). I have a Windows box on a hub with the FC6 box (only two on that hub) which can access those other sites no problem. So the problem is definitely local to my FC6 machine.
Any suggestions?
Thanks,
Jacques B
On Wed, 2007-01-31 at 06:01 -0500, Jacques B. wrote:
I'm unable to access some https sites for some reason. I can access https://mail.google.com for example, but not my banking site, or another encrypted site. I turned off iptables but still no luck. I also went in the GUI and turned off the firewall from there (isn't that also iptables?). I have a Windows box on a hub with the FC6 box (only two on that hub) which can access those other sites no problem. So the problem is definitely local to my FC6 machine.
Any suggestions?
What's the actual error message? It could be a name resolution issue, if one thing works and others don't.
What's the actual error message? It could be a name resolution issue, if one thing works and others don't.
No error, just times out/hangs. Actually whois is also not working. Also just hangs. In /var/log message I do have the following:
Jan 31 06:22:08 localhost restorecond: Will not restore a file with more than one hard link (/etc/resolv.conf) No such file or directory Jan 31 06:22:10 localhost restorecond: terminated Jan 31 06:22:10 localhost restorecond: Will not restore a file with more than one hard link (/etc/resolv.conf) Success
I ran find -samefile /etc/resolve.conf to identify what files had hard links to this file (ls -l showed two hard links) and it hit on this file in addition to the actual file above: /etc/sysconfig/networking/profiles/default/resolv.conf
The contents of /etc/resolve.conf is:
; generated by /sbin/dhclient-script nameserver ##.#.###.## nameserver ##.#.###.## search localdomain
I neutered the IPs obviously.
Thanks,
Jacques
On 1/31/07, Jacques B. jjrboucher@gmail.com wrote:
What's the actual error message? It could be a name resolution issue, if one thing works and others don't.
I ran Wireshark and compared the output of my Windows box vs Linux box connecting to the online banking site. In both cases I see the Client side Hello, Server side Hello, Certificate, and Key exchange, encrypted handshake, etc. All seems to work pretty much the same on both sides (remembering that both are connected to a hub so I was able to do all my sniffing from the same environment - my Linux box). But the Linux side just hangs with "Loading..." and "Waiting for www1.banking_url.com".
Makes me wonder if it's a browser setting...
So I try Konqueror - same thing. The status bar at the bottom has "Retrieving 26.8 KB from www1.banking_url.com" and nothing else. Also hangs...
Thanks,
Jacques B.
On Wednesday 31 January 2007 12:44, Jacques B. wrote:
On 1/31/07, Jacques B. jjrboucher@gmail.com wrote:
What's the actual error message? It could be a name resolution issue, if one thing works and others don't.
I ran Wireshark and compared the output of my Windows box vs Linux box connecting to the online banking site. In both cases I see the Client side Hello, Server side Hello, Certificate, and Key exchange, encrypted handshake, etc. All seems to work pretty much the same on both sides (remembering that both are connected to a hub so I was able to do all my sniffing from the same environment - my Linux box). But the Linux side just hangs with "Loading..." and "Waiting for www1.banking_url.com".
Makes me wonder if it's a browser setting...
So I try Konqueror - same thing. The status bar at the bottom has "Retrieving 26.8 KB from www1.banking_url.com" and nothing else. Also hangs...
The usual suspects are javascript, flash, activeX. I'd start by checking javascript settings. Oh yes, and some such sites need popups available.
Anne
On Wednesday 31 January 2007 13:02, Anne Wilson wrote:
The usual suspects are javascript, flash, activeX. I'd start by checking javascript settings. Oh yes, and some such sites need popups available.
One more thing I've remembered. I used to have Mozilla set to only display graphics from the originating site, and I saw something similar to what you describe. Banks, and many others, sometimes use external urls to deliver the graphics, so that setting had to be changed. What I did was to allow all graphics, load the site, note where the graphics loaded from, then make an exception rule for that site before switching back to the original setting.
HTH
Anne
The usual suspects are javascript, flash, activeX. I'd start by checking javascript settings. Oh yes, and some such sites need popups available.
One more thing I've remembered. I used to have Mozilla set to only display graphics from the originating site, and I saw something similar to what you describe. Banks, and many others, sometimes use external urls to deliver the graphics, so that setting had to be changed. What I did was to allow all graphics, load the site, note where the graphics loaded from, then make an exception rule for that site before switching back to the original setting.
HTH
Anne
Thanks Anne,
I had the bank URL in trusted sites, but added their other domains as well just in case. Javascript is enabled, and I haven't done anything to prohibit graphics from loading so I don't think that is the problem. And I don't imagine it's ActiveX because it works fine from home.
I'm going to re-boot into my SuSE partition and see how it behaves from there.
I'll post an update.
Thanks,
Jacques
I'm going to re-boot into my SuSE partition and see how it behaves from there.
I'll post an update.
Well I'm in SuSe now (default 10.1 install) and it works fine. So there is something wrong with settings over on my FC6 partition.
Other than iptable and the GUI firewall settings, is there anything I can shut down to test for the problem? Do the settings of Firefox carry over to Konqueror (I can't imagine)? If not, then I should have been able to access the site from Konqueror had FF been the culprit.
Surfing to other locations do not appear to be a problem at all. Just navigating to certain https sites, and doing a whois.
Thanks,
Jacques
The usual suspects are javascript, flash, activeX. I'd
start by checking
javascript settings. Oh yes, and some such sites need
popups available.
One more thing to try. cd to /tmp and do a wget on the URL to the site that hangs. See if it hangs in wget. This could eliminate some possibilites.
This is similar to a problem I have been chasing for some time. On a friends FC6 machine, they cannot access a particular site which is not https (normal http). It just hangs and times out. I can get to the site fine from my FC6 machine. I ran ethereal (wire shark) on each machine and then did a wget of the URL. On the failing machine, 14 of about 22 blocks of data came across and then the site just stops sending data. The Windows machine on the same router can get through fine but the FC4 machine on the same router has the same problem at the FC6 machine.
My next plan is to drag a different make of router over there and configure it to have the same mac address as the original and swap it in. If that does not tell me anything, then I am running out of ideas.
Bob Styma
On Wed, 2007-01-31 at 09:50 -0500, Jacques B. wrote:
I'm going to re-boot into my SuSE partition and see how it behaves from there.
I'll post an update.
Well I'm in SuSe now (default 10.1 install) and it works fine. So there is something wrong with settings over on my FC6 partition.
Other than iptable and the GUI firewall settings, is there anything I can shut down to test for the problem? Do the settings of Firefox carry over to Konqueror (I can't imagine)? If not, then I should have been able to access the site from Konqueror had FF been the culprit.
Surfing to other locations do not appear to be a problem at all. Just navigating to certain https sites, and doing a whois.
---- try adding this to /etc/sysctl.conf
# hack to fix problems with internet routers net.ipv4.tcp_window_scaling = 0
and then reloading sysctl
/sbin/sysctl -p
and see if that helps
Craig
On Wednesday 31 January 2007 14:50, Jacques B. wrote:
I'm going to re-boot into my SuSE partition and see how it behaves from there.
I'll post an update.
Well I'm in SuSe now (default 10.1 install) and it works fine. So there is something wrong with settings over on my FC6 partition.
Other than iptable and the GUI firewall settings, is there anything I can shut down to test for the problem? Do the settings of Firefox carry over to Konqueror (I can't imagine)? If not, then I should have been able to access the site from Konqueror had FF been the culprit.
Surfing to other locations do not appear to be a problem at all. Just navigating to certain https sites, and doing a whois.
How about giving us the bank's url? At least we could see whether it's a general problem in FC or just a config problem that needs sorting.
Anne
On Wed, 2007-01-31 at 09:00 -0600, Styma, Robert E (Robert) wrote:
The usual suspects are javascript, flash, activeX. I'd
start by checking
javascript settings. Oh yes, and some such sites need
popups available.
One more thing to try. cd to /tmp and do a wget on the URL to the site that hangs. See if it hangs in wget. This could eliminate some possibilites.
This is similar to a problem I have been chasing for some time. On a friends FC6 machine, they cannot access a particular site which is not https (normal http). It just hangs and times out. I can get to the site fine from my FC6 machine. I ran ethereal (wire shark) on each machine and then did a wget of the URL. On the failing machine, 14 of about 22 blocks of data came across and then the site just stops sending data. The Windows machine on the same router can get through fine but the FC4 machine on the same router has the same problem at the FC6 machine.
My next plan is to drag a different make of router over there and configure it to have the same mac address as the original and swap it in. If that does not tell me anything, then I am running out of ideas.
Your problem sounds definitely like a tcp-window problem. Particularly the receiving of some packets and then just not getting any more.... Somewhere in the path between your FC6 machine and the remote site there is an "ill-behaved" router. It may not be the one at your location, but rather one somewhere else in the path to the remote site....
As someone else pointed out in this thread, you want to adjust one kernel parameter by adding a line to /etc/sysctl.conf:
net.ipv4.tcp_window_scaling = 0
Then after saving the file run,
sysctl -p
Then try to navigate freshly to the site and see if things improve.... :-) Apparently we turned on a more aggressive form of the algorithm a few kernel releases ago and it is pointing out some "failings" of some routers in the world who are not following spec....
Theoretically, you might get poorer performance with some sites that would allow a larger tcp-window, but I don't think you'll probably notice other than on some large file transfers....
I travel a lot and find myself having to do this in certain "hotels"....
--Rob
try adding this to /etc/sysctl.conf
# hack to fix problems with internet routers net.ipv4.tcp_window_scaling = 0
and then reloading sysctl
/sbin/sysctl -p
and see if that helps
Craig
That did it!! Thanks to all for your input. Special thanks to Craig and Robert for the solution!
I'm running FC5 at home and it has never been an issue there. And I had pretty much eliminated all other possibilities outside of FC6 settings. As you explained rather the more aggressive algorithm recently added to the kernel has identified a problem with one of our routers.
Just to help me (and no doubt others) understand, what exactly did I do and why?
Thanks,
Jacques
On Wed, 2007-01-31 at 11:53 -0500, Jacques B. wrote:
try adding this to /etc/sysctl.conf
# hack to fix problems with internet routers net.ipv4.tcp_window_scaling = 0
and then reloading sysctl
/sbin/sysctl -p
and see if that helps
Craig
That did it!! Thanks to all for your input. Special thanks to Craig and Robert for the solution!
I'm running FC5 at home and it has never been an issue there. And I had pretty much eliminated all other possibilities outside of FC6 settings. As you explained rather the more aggressive algorithm recently added to the kernel has identified a problem with one of our routers.
Just to help me (and no doubt others) understand, what exactly did I do and why?
One of the threads of discussion can be found here:
http://kerneltrap.org/node/6723
It would also impact an FC5 system as long as it had been "updated" to a later kernel.... It is also completely dependent on the "path" that the packets take. So from home, you may not be crossing the offending router, while at work you are. Of course, it might actually be the router at work. The goal, apparently, is to improve performance on large data activity and hence the feature being tuned up in the later kernel.... While we're officially "correct", some hardware in the middle may not understand it, but hopefully over time the problem hardware will go away.... :-)
--Rob
One of the threads of discussion can be found here:
http://kerneltrap.org/node/6723
It would also impact an FC5 system as long as it had been "updated" to a later kernel.... It is also completely dependent on the "path" that the packets take. So from home, you may not be crossing the offending router, while at work you are. Of course, it might actually be the router at work. The goal, apparently, is to improve performance on large data activity and hence the feature being tuned up in the later kernel.... While we're officially "correct", some hardware in the middle may not understand it, but hopefully over time the problem hardware will go away.... :-)
--Rob
Thanks. Checking that out now.
Jacques B.
Craig White:
try adding this to /etc/sysctl.conf
# hack to fix problems with internet routers net.ipv4.tcp_window_scaling = 0
Jacques B.:
That did it!! Thanks to all for your input. Special thanks to Craig and Robert for the solution!
If that hadn't been it, the other thing I would have suggested, and is probably worth remembering for the future, is whether your browsers are set up to verify revocation of SSL certificates. That often fails, and without giving you any clues as to what's going wrong.
If that hadn't been it, the other thing I would have suggested, and is probably worth remembering for the future, is whether your browsers are set up to verify revocation of SSL certificates. That often fails, and without giving you any clues as to what's going wrong.
Thanks for that additional tip. I just checked and I don't see anything set up to check for revocations. In this case it was going to the URL and I could see the padlock at the bottom right. So it was navigating there but couldn't finish downloading the page. In reading through the URL that Rob sent me plus his explanation, the behaviour was consistent with what one would expect for such a problem (dropped packets).
Thanks,
Jacques B.
On Wed, 2007-01-31 at 13:44 -0500, Jacques B. wrote:
One of the threads of discussion can be found here:
http://kerneltrap.org/node/6723
It would also impact an FC5 system as long as it had been "updated" to a later kernel.... It is also completely dependent on the "path" that the packets take. So from home, you may not be crossing the offending router, while at work you are. Of course, it might actually be the router at work. The goal, apparently, is to improve performance on large data activity and hence the feature being tuned up in the later kernel.... While we're officially "correct", some hardware in the middle may not understand it, but hopefully over time the problem hardware will go away.... :-)
--Rob
Thanks. Checking that out now.
Jacques B.
Hi, Jacques and others, I am having a similar problem, but the window scaling didn't fix the issue. As I read the information in the link, I saw that they had ECN disabled. However, I didn't see how or where to do that. Can someone please tell me where that control exists?
Regards, Les H
Hi, Jacques and others, I am having a similar problem, but the window scaling didn't fix the issue. As I read the information in the link, I saw that they had ECN disabled. However, I didn't see how or where to do that. Can someone please tell me where that control exists?
Regards, Les H
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
The best I can offer is this that I found online @ http://www.tux.org/lkml/
# Why does the 2.4 kernel report Connection refused when connecting to sites which work fine with earlier kernels?
* (DW) The 2.4 kernel is designed to make your Internet Experience more pleasurable. One of the ways in which it does so is by implementing Explicit Congestion Notification - a new method defined in RFC 3168 for improving TCP performance in the presence of congestion by allowing routers to provide an early warning of traffic flow problems. Unfortunately, there are bugs in some firewall products which cause them to reject incoming packets with ECN enabled. If your own firewall is broken in this respect, you should check with your vendor for a fix. If the site to which you cannot connect is not under your control, then after you have contacted the administrator of the offending site to let them know about their problem, you can disable ECN in the 2.4 kernel either by disabling the CONFIG_INET_ECN option and recompiling the kernel, or by executing the following command as root: # echo 0 > /proc/sys/net/ipv4/tcp_ecn
Looks like they are creating a file with a 0 value. But strange that it would be a /proc file seeing that is gone on shutdown.
Jacques B.
On Thu, 2007-02-01 at 17:48 -0500, Jacques B. wrote:
Hi, Jacques and others, I am having a similar problem, but the window scaling didn't fix the issue. As I read the information in the link, I saw that they had ECN disabled. However, I didn't see how or where to do that. Can someone please tell me where that control exists?
Regards, Les H
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
The best I can offer is this that I found online @ http://www.tux.org/lkml/
# Why does the 2.4 kernel report Connection refused when connecting to sites which work fine with earlier kernels?
* (DW) The 2.4 kernel is designed to make your Internet Experiencemore pleasurable. One of the ways in which it does so is by implementing Explicit Congestion Notification - a new method defined in RFC 3168 for improving TCP performance in the presence of congestion by allowing routers to provide an early warning of traffic flow problems. Unfortunately, there are bugs in some firewall products which cause them to reject incoming packets with ECN enabled. If your own firewall is broken in this respect, you should check with your vendor for a fix. If the site to which you cannot connect is not under your control, then after you have contacted the administrator of the offending site to let them know about their problem, you can disable ECN in the 2.4 kernel either by disabling the CONFIG_INET_ECN option and recompiling the kernel, or by executing the following command as root: # echo 0 > /proc/sys/net/ipv4/tcp_ecn
Looks like they are creating a file with a 0 value. But strange that it would be a /proc file seeing that is gone on shutdown.
The file is created on boot by the kernel (ever hear of "procfs"?) and by default contains a "1". Doing the echo replaces the "1" with a "0" and turns off ECN. If you want to make it permanent, then put an entry in /etc/sysctl.conf:
net.ipv4.tcp_ecn = 0
and it'll get set to 0 when sysctl is run via the /etc/rc.d/rc.sysinit script during startup.
---------------------------------------------------------------------- - Rick Stevens, Senior Systems Engineer rstevens@vitalstream.com - - VitalStream, Inc. http://www.vitalstream.com - - - - Never test for an error condition you don't know how to handle. - ----------------------------------------------------------------------
On Thu, 2007-02-01 at 15:14 -0800, Rick Stevens wrote:
echo 0 > /proc/sys/net/ipv4/tcp_ecn
Thanks, Rick, I do know what echo does, I just don't know how to read anymore I guess. What is the correct word that describes this? DUUUUHHHH!
Thanks again, and especially for avoiding sarcasm when the opportunity arose.
Regards, Les H
I've had a problem accessing some https sites a few times. In two of those cases, it turned out that I had updated firefox with a firefox session open. That firefox session gave me strange errors on https sites. Finally, I figured out that exiting and restarting firefox seems to be necessary after an update. It wasn't always obvious to me because I'd done the update a day earlier but hadn't gone to any https sites since the update.
David
On Wed, 2007-01-31 at 13:44 -0500, Jacques B. wrote:
One of the threads of discussion can be found here:
http://kerneltrap.org/node/6723
It would also impact an FC5 system as long as it had been "updated" to
a
later kernel.... It is also completely dependent on the "path" that
the
packets take. So from home, you may not be crossing the offending router, while at work you are. Of course, it might actually be the router at work. The goal, apparently, is to improve performance on large data activity and hence the feature being tuned up in the later kernel.... While we're officially "correct", some hardware in the middle may not understand it, but hopefully over time the problem hardware will go away.... :-)
--Rob
Thanks. Checking that out now.
Jacques B.
Hi, Jacques and others, I am having a similar problem, but the window scaling didn't fix the issue. As I read the information in the link, I saw that they had ECN disabled. However, I didn't see how or where to do that. Can someone please tell me where that control exists?
Regards, Les H
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
_________________________________________________________________ Invite your Hotmail contacts to join your friends list with Windows Live Spaces http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=http://spa...
The file is created on boot by the kernel (ever hear of "procfs"?) and by default contains a "1". Doing the echo replaces the "1" with a "0" and turns off ECN. If you want to make it permanent, then put an entry in /etc/sysctl.conf:
net.ipv4.tcp_ecn = 0and it'll get set to 0 when sysctl is run via the /etc/rc.d/rc.sysinit script during startup.
- Rick Stevens, Senior Systems Engineer rstevens@vitalstream.com -
Thanks Rick. I am aware of what the /proc directory is, hence why I was a bit confused by the solution seeing it would only be for that session (unless you put that in /etc/profile to happen at each startup but that didn't seem like the best way to do it). I was not aware that you could make that change permanently via /etc/sysctl.conf. Prior to the troubles I had herein and your solution I was not aware of that file. Not something that I have had to deal with before.
Thanks,
Jacques B.
On Fri, 2007-02-02 at 07:47 -0800, David L wrote:
I've had a problem accessing some https sites a few times. In two of those cases, it turned out that I had updated firefox with a firefox session open. That firefox session gave me strange errors on https sites. Finally, I figured out that exiting and restarting firefox seems to be necessary after an update. It wasn't always obvious to me because I'd done the update a day earlier but hadn't gone to any https sites since the update.
That is not my problem. I have made the changes to both ECN and window size, but still no go on some areas of the problem website. It is financial and requires login, so I can't send the site name to you guys to check out.
Regards, Les H
That is not my problem. I have made the changes to both ECN and window size, but still no go on some areas of the problem website. It is financial and requires login, so I can't send the site name to you guys to check out.
Regards, Les H
Have you tried an alternate browser such as Konqueror? Just to eliminate the browser as being the problem (be it problem with Flash, ActiveX, or the situation noted previously where upgrading was a problem). Were you able to access the site before without any problem? Is it possible the site is using a non-standard port which is being blocked by a firewall (software or hardware)? You could download a live distro (Knoppix, Helix, SuSE, Ubuntu, whatever) and try and connect with the same machine using one of those. If that still doesn't work then your problem is not with the OS but the machine or more likely than not something else up the line.
Jacques B.