BTW: While posting this bug I got this message again, reloading the page works 

Loading https://bugs.kde.org/query.cgi?GoAheadAndLogIn=1 give me some strange pages. See next screenshots.
Loading http://www.sparkasse-minden-luebbecke.de instead give me no errors.

Created attachment 22750 [details]
Konqueror rendering error

Created attachment 22751 [details]
Konqueror problem 2

After reloading the page I've got this error.

If I try to load the page with http://... (instead of https://...) the page is
loaded correctly

*** This bug has been marked as a duplicate of 154785 ***

I don't think that these two bugs a the same, because I get a different error message and my bug also appears with non-ssl pages (perhaps I triggered bug #154785 while trying to reproduce mine). 

I investigated a little more on "my" bug: The bug was introduced after rc2 (I compiled rc2 for test today and everything is alright) and I think it must have been somewhere before christmas although I'm not sure when. Any hint how to find the change without having to test every single revision since rc2?

Ok, it's not the same bug, because mine is still there. I also have some problems with kmail with a quite similar error message:
[...]
kmail(2488)/kio (Slave) KIO::Slave::createSlave: createSlave ' "pop3" ' for"pop3://klaus%40dimde.info@pop.1und1.de:110"
kmail(2488)/kio (KIOConnection) KIO::ConnectionServer::listenForRemote: Listening on  "local:/tmp/ksocket-kladim/kmailUS2488.slave-socket"
kmail(2488)/kio (KIOJob) KIO::SlaveInterface::dispatch: error  123   "pop.1und1.de: Unknown error"
kmail(2488)/kdeui (KNotification) KNotification::slotReceivedId: 0
kmail(2488)/kdeui (KNotification) KNotification::~KNotification: 0
[...]
so I think the bug has something to do with KIO::ConnectionServer. But after a reload it works again, but the pages a rendered very strange (like the image attached by FiNeX). 

Further investigation showed that the bug was introduced after 2007-12-23 (i checked out the revision from that date). As far as I can see in the commit logs round that date have a quite large commit with the comment "Santa merged newssl to protect your christmas shopping." which affects a lot of source files. I think this bug should be reassigned to some kio because it's not a konqueror-only bug.

I don't know if anybody besides me is still reading this bug but some more information:
The bug appears on a self compiled cross-linux-from-scratch system as well as on openSuSE 10.3. In both cases is kde compiled from sources. The System is a Athlon64 non-multilib system in the first case and a partly multilib system (i didn't compile kde for 32bit) in the case of openSuSE.  

*** Bug 155147 has been marked as a duplicate of this bug. ***

Created attachment 23122 [details]
tcpdump -i eth1 from konqueror open www.kde.org

..
22:25:56.999063 IP fritz.fonwlan.box.domain > noname.danf-ak2: 23040 0/1/0 (78)
22:26:01.953378 IP noname.danf-ak2 > fritz.fonwlan.box.domain: 17175+ AAAA? www.kde.org. (29)
22:26:01.966960 IP noname.afrog > fritz.fonwlan.box.domain: 54223+ AAAA? www.kde.org. (29)
22:26:01.978981 IP noname.boinc-client > fritz.fonwlan.box.domain: 23040+ AAAA? www.kde.org. (29)
22:26:02.002075 IP fritz.fonwlan.box.domain > noname.danf-ak2: 23040 0/1/0 (78)
22:26:06.951139 IP noname.danf-ak2 > fritz.fonwlan.box.domain: 17175+ AAAA? www.kde.org. (29)
22:26:06.963294 IP noname.afrog > fritz.fonwlan.box.domain: 54223+ AAAA? www.kde.org. (29)
22:26:06.975309 IP noname.boinc-client > fritz.fonwlan.box.domain: 23040+ AAAA? www.kde.org. (29)
22:26:06.999135 IP fritz.fonwlan.box.domain > noname.danf-ak2: 23040 0/1/0 (78)
..

maybe a IPv6 Problem? I have disabled IPv6 in my opensuse 10.3

I have contacted AVM Support (http://www.avm.de) (Router: FritBox 7071)

Interesting, I have a router from AVM too (FritzBox 7050). But IPv6 is disabled in both my distributions. 

I can't reproduce this with a recent snapshot of SVN. This bug is hardly reproducible as it does not show always, but I realized that *every time* I reproduced it, it was related to a timeout issue. When page takes more than X secs to load, then, this message is displayed, in my case, refreshing the page is a workarround for this.

I have similar behaviour in my Konqueror (4.00.00, built on Gentoo Linux with gcc-4.2.1).

Webpages on localhost are loaded quite fast, but most pages on the web sometimes take up to 45 seconds or more to finally display - although the window title is already set to what is in the <title> tag of the page to be loaded. I can't really reproduce it. Quite often, I get the timeouts mentioned above, too.

I'm also between an AVM router (Fritz!BOX 5050). When I'm using a VPN connection to my university to have a tunnel through the router, the problem suddenly disappears and everything seems to be fine.

Another note: I never had problems with pages www.google.de or www.kernel.org.  But with almost every other page quite always (makes working with KDE4 real painful at the moment). And as I told above it seems to be a kio problem. 

BTW Bug #155157 seems to be a duplicate

I'm between ASUS 6020 ADSL Modem (with router mode enabled), and when I'm using an OpenVPN connection to my office, the problem is disappears and all works good

Hmm, it's very-very strange bug. I took my home notebook to my work, and connected it to office network directly, not via OpenVPN. There is no problem with access to Internet via Konqueror - the problem disappeared. At the work we use PC-based router with FreeBSD 5.3 OS. 

Another strange thing - Konqueror 3.5.8 works good in both locations: at the home and at the office.

Does it mean, that I need to test a large amount of ADSL modems to paired it with KDE4? :(

Created attachment 23337 [details]
tcpdump log during attempt of opening http://opennet.ru in Konqueror

I see some strange connections from my host to 1.0.0.0 by http port, when I use
Konqueror. There is no such connections when I use Mozilla Firefox.

Anybody can explain this?

I capture some packets during Kopete ICQ account login:

20:49:11.142001 IP sysadm-nb.32786 > mygateway1.ar7.domain: 30826+ AAAA? login.oscar.aol.com. (37)
20:49:11.156531 IP mygateway1.ar7.domain > sysadm-nb.32786: 30826 1/1/0 CNAME[|domain]
20:49:11.168158 IP sysadm-nb.32786 > mygateway1.ar7.domain: 27235+ A? login.oscar.aol.com. (37)
20:49:11.169662 IP mygateway1.ar7.domain > sysadm-nb.32786: 27235- 1/0/0 A 1.0.0.0 (53)
20:49:11.170796 IP sysadm-nb.56911 > 1.0.0.0.aol: S 1580219526:1580219526(0) win 5840 <mss 1460,sackOK,timestamp 469756 0,nop,wscale 6>
20:49:14.167984 IP sysadm-nb.56911 > 1.0.0.0.aol: S 1580219526:1580219526(0) win 5840 <mss 1460,sackOK,timestamp 470506 0,nop,wscale 6>

It looks like router return IP 1.0.0.0 for login.oscar.aol.com , isn't it?

But why my router do it for KDE4 apps only?

Here a capturing packets when I connect to ICQ server via SIM

21:02:58.552182 IP sysadm-nb.32787 > mygateway1.ar7.domain: 33119+ A? login.icq.com. (31)
21:02:58.565441 IP mygateway1.ar7.domain > sysadm-nb.32787: 33119 2/4/4 CNAME[|domain]
21:02:58.661284 IP sysadm-nb.32788 > mygateway1.ar7.domain: 38441+ A? login.icq.com. (31)
21:02:58.662981 IP mygateway1.ar7.domain > sysadm-nb.32788: 38441- 1/0/0 A login.icq.com (47)
21:02:58.663894 IP sysadm-nb.32789 > mygateway1.ar7.domain: 63301+ PTR? 89.200.12.64.in-addr.arpa. (43)
21:02:58.665430 IP mygateway1.ar7.domain > sysadm-nb.32789: 63301- 1/0/0 (70)
21:02:58.665870 IP sysadm-nb.32790 > mygateway1.ar7.domain: 8383+ A? login.icq.com. (31)
21:02:58.667443 IP mygateway1.ar7.domain > sysadm-nb.32790: 8383- 1/0/0 A login.icq.com (47)
21:02:58.701920 IP sysadm-nb.51255 > login.icq.com.aol: S 1675506970:1675506970(0) win 5840 <mss 1460,sackOK,timestamp 676638 0,nop,wscale 6>
21:02:58.859631 IP login.icq.com.aol > sysadm-nb.51255: S 1351861239:1351861239(0) ack 1675506971 win 16384 <mss 1360>
21:02:58.859905 IP sysadm-nb.51255 > login.icq.com.aol: . ack 1 win 5840
21:02:59.014664 IP login.icq.com.aol > sysadm-nb.51255: P 1:11(10) ack 1 win 16384
21:02:59.014856 IP sysadm-nb.51255 > login.icq.com.aol: . ack 11 win 5840
21:02:59.053455 IP sysadm-nb.51255 > login.icq.com.aol: P 1:93(92) ack 11 win 5840
21:02:59.211969 IP login.icq.com.aol > sysadm-nb.51255: . ack 93 win 16384
21:02:59.231325 IP login.icq.com.aol > sysadm-nb.51255: P 11:316(305) ack 93 win 16384

Looks like good, isn't it?

Very-very dirty-dirty workaround for me: 

- disable DHCP configuration for my network card
- manually set IP address, default gateway, and (!) IP address of another well-known-for-me DNS server instead address that router give via DHCP to notebook.

And it seems to be work!

21:55:59.798909 IP sysadm-nb.33065 > is.afei.itech.ru.domain: 49580+ AAAA? login.oscar.aol.com. (37)
21:55:59.973609 IP is.afei.itech.ru.domain > sysadm-nb.33065: 49580 1/1/0 CNAME[|domain]
21:55:59.973805 IP sysadm-nb.33065 > is.afei.itech.ru.domain: 59106+ A? login.oscar.aol.com. (37)
21:56:00.263350 IP is.afei.itech.ru.domain > sysadm-nb.33065: 59106 2/4/0 CNAME[|domain]
21:56:00.263905 IP sysadm-nb.50483 > bucp1-vip-m.blue.aol.com.aol: S 9113465:9113465(0) win 5840 <mss 1460,sackOK,timestamp 1472029 0,nop,wscale 6>
21:56:00.419315 IP bucp1-vip-m.blue.aol.com.aol > sysadm-nb.50483: S 3111077942:3111077942(0) ack 9113466 win 16384 <mss 1360>
21:56:00.419367 IP sysadm-nb.50483 > bucp1-vip-m.blue.aol.com.aol: . ack 1 win 5840
21:56:00.573521 IP bucp1-vip-m.blue.aol.com.aol > sysadm-nb.50483: P 1:11(10) ack 1 win 16384
21:56:00.573558 IP sysadm-nb.50483 > bucp1-vip-m.blue.aol.com.aol: . ack 11 win 5840
21:56:00.574274 IP sysadm-nb.50483 > bucp1-vip-m.blue.aol.com.aol: P 1:39(38) ack 11 win 5840
21:56:00.728778 IP bucp1-vip-m.blue.aol.com.aol > sysadm-nb.50483: . ack 39 win 16384
21:56:00.735157 IP bucp1-vip-m.blue.aol.com.aol > sysadm-nb.50483: P 11:39(28) ack 39 win 16384
21:56:00.735471 IP sysadm-nb.50483 > bucp1-vip-m.blue.aol.com.aol: P 39:149(110) ack 39 win 5840
21:56:00.893408 IP bucp1-vip-m.blue.aol.com.aol > sysadm-nb.50483: . ack 149win 16384
21:56:00.897677 IP bucp1-vip-m.blue.aol.com.aol > sysadm-nb.50483: P 39:636(597) ack 149 win 16384

...

Kopete and Konqueror works. But what is work wrong: KDE4 or my router?

Wow, thanks Pawel you did it. I tried your last hints and found that the bug disappears when I write some real nameserver to resolv.conf and not the ip of my router (wich worked before). Anyway it remains a bug in my opinion because it worked without problems before christmas (see above). But as a workaround the above given works fine...

Ups, sorry. Mispelled your name Pavel

Great detective work there... I'll try to catch the network guy and ask about this..

It's your router. It's possibly getting confused because of the IPv6 query. Nothing I can or will do about it. Please use a better nameserver (a local, caching nameserver will do just fine).

My system also doesn't have IPv6 support enabled and it's working for me with the workaround putting a real nameserver to /etc/resolv.conf. But that's a really dirty one, because all the host names of the systems on the local network typically get resolved by the router and that, of course, doesn't work that way. Furthermore, /etc/resolv.conf gets updated each time I restart the network interface because of the running DHCP server.

Maybe you could do a simple check if the system has IPv6 enabled before doing any IPv6 queries so the system doesn't get confused anymore? I talked to a friend concerning this problem and got this piece of code from him doing this particular check:

#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <unistd.h>

#include <stdio.h>

int main (int argc, char **argv) {
  int sock = socket (PF_INET6, SOCK_STREAM, 0);
  if (sock < 0) {
    printf ("IPv6 is not supported!\n");
  } else {
    close (sock);
    printf ("IPv6 is supported!\n");
  }

  return 0;
}

To put it mildly, I think forcing the user to set up a local nameserver just to get the web browser working is simply not the best solution. It'd be great if you reconsidered your opinion.

IPv6 disabled in my OpenSUSE system during setup, but Konqueror use IPv6 forcerly. May be, should add the checking of list of enabled protocols in OS?

Btw, the same problem was found in Ubuntu 7.10 
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/81057

I think, that this bug may be CLOSED 

I have the same problem (even in 4.0.1) with OpenSUSE 10.3 packages.

I'm not using any of the ADSL modems mentioned above, but I worked around the problem simply by using real DNS addresses instead of my router.

Next to that, Konqueror 3 and all other existing browsers work well without any such tweaking. Are you sure you want to close the bugreport at this point?

Additional detail: now that Konqueror 4 is able to reach the internet, it can no longer reach servers on my local network (same "Unknown error").

Is there any solution available atm (besides setting a different Nameserver in /etc/resolv.conf manually)? I have the same problem. Firefox and Konqueror 3.5.8 are working, but not Konqu from 4.0.1. Seems my router is providing garbage for ipv6 and Konqu no longer falls back to ipv4 or respects "KDE_NO_IPV6" any more.

I got the exact same problem for quite some while now, with kde 4.0.x and 4.1-svn, using both AVM Fritz!Box 7170 and 3131 routers. Today I tested with a Linksys WRT45G with dd-wrt firmware and it worked without any problems. The Fritz!Boxes are very common here in Germany so I guess this issue has quite some impact on home users.

Sorry for the spam but I forgot to note that I already tried to work around this issue by playing with setting my ISP's dns server in /etc/resolv.conf and even with a local dns server (pdnsd version 1.2.6) and it didn't change anything for me, I'm not able to access any website with konqeror and also everything which connects to the internet, like the newsticker plasma applet, doesn't work as well , seems to be not only dns related or at least the mentioned workarounds don't work (for me). KDE3 and GTK applications however work without any problem, also ktorrent seems to work. But konqueror is really a no go at the moment.

Same here :/

I have the same problem, Debian Sid on AMD64, problem occurs both with KDE 4.0.0 amd 4.0.1. My router is also a FritzBox. I have now been forced to switch to Firefox... This should be a high priority bug, as it makes KDE useless for all affected people wanting to browse the net...

It is not only konqueror which is affected. So i think it should be reassigned to someone else. 

Other KDE4 Software for example amarok 2 (from svn) has the same problem for http connections.

Hosts with a AAAA record are working fine. For example 6bone.net 

BTW: I am using an AVM Fritz!Box too.  But other software (for example "host") can do AAAA record querys without any problems to it. So IMHO not the routers itself are the problems.

It seems that qt4 is not causing the bug. The qt4.4 demo browser is not affected. 

I think making AAAA record querys on systems with no ipv6 support (like mine, i have not even ipv6 modules loaded) is a bug. 

I have looked at it with wireshark. Konqueror is making sometimes AAAA record querys before A querys. In such cases it does make them over and over agin. It seems that is doesn't like the answer it gets from the AVM boxes. So if there is an AAAA record it goes fine and is doing the A record query direct after that. That is weird it doesn't use the AAAA record at all (how should it if there is no ipv6 connection or even support in my kernel?)

btw: here is the support answer from AVM (Fritzbox) (in german)

---
Im Mitschnitt ist zwar zu erkennen, dass es IPv6 DNS-Anfragen an die Box
gibt, diese werden aber (ebenso wie die IPv4 Anfragen innerhalb der
gleichen Sekunde) von der Box auch beantwortet. Wir können hier daher kein
direktes Problem in der FRITZ!Box bzw. deren DNS-Server erkennen.
---

Is there still any effort to solve that problem, or is it an abandoned bug? I still can't use Konqueror 4... If I manually set some real DNS IP addresses, Konqueror 4 mostly works except for servers on my local network. If I let the DNS address be my router's IP, then it's the opposite: only my local network is accessible.

I'm not completely convinced that there is no bug on Konqueror 4's part. There are a variety of computers occasionally using my local network (under Mac OS X, various Linux distributions, Windows) and the only problematic case is Konqueror 4 and related apps (like KGet 4).

As always, I don't have the skills to debug the problem, but I'm ready to test any patch... Anything to get it working properly!

I can reproduce the probmen here with a self-built Konqueror 4.0.2 on my Gentoo machine (gcc 4.1.2). Konqueror does not show any Webpages here, I get a timeout and an "unknown error".

P.S.: after using a local dns server (pdnsd), Konqueror works fine. I also use a DSL router (FRITZ!Box WLAN 3030).

Since this bug bars users from using Konqueror for all users using an affected network environment, the severity should be major. There is no work-around within KDE (Using KDE in a different network environment is not really an acceptable work-around).

I agree. Even reverting to Konqueror 3 has drawbacks: Konqueror 3 tries to use KGet 4 for downloads, but KGet 4 doesn't work for the same reason Konqueror 4 fails... It took me a little while to force Konqueror 3 to use KGet 3.

Changing title to be a little more specific. I hope this summary catches more attention.

Checked current Debian unstable (svn as of 2 April) bug not fixed, konqueror not usable.

Re-closing. I am not fixing this.

Fix your DNS servers.

I'm closing WONTFIX. Don't reopen unless you want to take the assignment for this bug and provide a patch.

Thiago said the resolver code used is the same as in KDE 3, Qt, Firefox... So there may be a bug somewhere else:

Trigger7| thiago_home: maybe it is not the resolver code, but something on top of it which is broken right now?
thiago_home| could be

Before discovering this bug I opened #162600. This may be an issue with kio. Thiago said to this report:
>> thiago_home<< Trigger7: that might be useful information, but I am no longer dealing with KIO... I just did some porting there.

So I'd say let's move to #162600. One thing is sure: This is definitely no konqueror bug. It is in kio or even deeper.

*** Bug 163464 has been marked as a duplicate of this bug. ***