Version: 1.2 (using KDE KDE 3.5.1) Installed from: Gentoo Packages Compiler: gcc version 4.0.2 (Gentoo 4.0.2-r3, pie-8.7.8) OS: Linux This is really serious. Once in a while, Kontact goes into an infinite loop, and sends thousands and thousands of requests, asking to resolve "localhost.gateway.2wire.net". The router keeps replying with "127.0.0.1", but it's unable to handle that many requests. This basically brings down the internet on my computer, as well as my roommates' computers. "gateway.2wire.net" probably comes from my /etc/resolve.conf: # Generated by dhcpcd for interface eth0 domain gateway.2wire.net nameserver 192.168.1.254 Kontact uses from 5% to 30% of the CPU. I tried to run gdb on it, but it's hard to get a backtrace, since Kontact is not sending the requests 100% of the time. Most of the time I get this, probably not useful: #0 0xffffe410 in __kernel_vsyscall () #1 0x4b859891 in select () from /lib/libc.so.6 #2 0x428115e9 in QEventLoop::processEvents () from /usr/qt/3/lib/libqt-mt.so.3 #3 0x42871b1c in QEventLoop::enterLoop () from /usr/qt/3/lib/libqt-mt.so.3 #4 0x42871a76 in QEventLoop::exec () from /usr/qt/3/lib/libqt-mt.so.3 #5 0x4285c4d9 in QApplication::exec () from /usr/qt/3/lib/libqt-mt.so.3 #6 0x0805b185 in ?? () #7 0xbfa16740 in ?? () #8 0x00000001 in ?? () #9 0x00000001 in ?? () #10 0x00000000 in ?? () One time I got this: #0 0xffffe410 in __kernel_vsyscall () #1 0x4ba13c26 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x42b2e093 in QWaitCondition::wait () from /usr/qt/3/lib/libqt-mt.so.3 #3 0x43f8638f in KPIM::ThreadWeaver::Weaver::applyForWork () from /usr/kde/3.5/lib/libkdepim.so.1 #4 0x43f86e56 in KPIM::ThreadWeaver::Thread::run () from /usr/kde/3.5/lib/libkdepim.so.1 #5 0x42855f0a in QThreadInstance::start () from /usr/qt/3/lib/libqt-mt.so.3 #6 0x4ba11270 in start_thread () from /lib/libpthread.so.0 #7 0x4b86082e in clone () from /lib/libc.so.6 I tried to strace it... Lots of output, printed very quickly: Process 20235 attached - interrupt to quit select(29, [3 4 5 6 8 11 12 13 14 15 16 17 21 23 24 28], [], [], {0, 168000}) = 1 (in [28], left {0, 160000}) recvfrom(28, "\2041\205\200\0\1\0\1\0\1\0\1\tlocalhost\7gateway\0052"..., 16383, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.1.254")}, [16]) = 156 time([1139901798]) = 1139901798 gettimeofday({1139901798, 243363}, NULL) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1017, ...}) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1017, ...}) = 0 sendto(28, "\2042\1\0\0\1\0\0\0\0\0\0\tlocalhost\7gateway\0052"..., 45, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.1.254")}, 16) = 45 gettimeofday({1139901798, 243802}, NULL) = 0 gettimeofday({1139901798, 243903}, NULL) = 0 ioctl(4, FIONREAD, [0]) = 0 gettimeofday({1139901798, 243980}, NULL) = 0 select(29, [3 4 5 6 8 11 12 13 14 15 16 17 21 23 24 28], [], [], {0, 155564}) = 1 (in [28], left {0, 144000}) recvfrom(28, "\2042\205\200\0\1\0\1\0\1\0\1\tlocalhost\7gateway\0052"..., 16383, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.1.254")}, [16]) = 156 time([1139901798]) = 1139901798 gettimeofday({1139901798, 283319}, NULL) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1017, ...}) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1017, ...}) = 0 sendto(28, "\2043\1\0\0\1\0\0\0\0\0\0\tlocalhost\7gateway\0052"..., 45, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.1.254")}, 16) = 45 gettimeofday({1139901798, 283745}, NULL) = 0 gettimeofday({1139901798, 283847}, NULL) = 0 ioctl(4, FIONREAD, [0]) = 0 gettimeofday({1139901798, 283916}, NULL) = 0 select(29, [3 4 5 6 8 11 12 13 14 15 16 17 21 23 24 28], [], [], {0, 115628}) = 1 (in [28], left {0, 104000}) recvfrom(28, "\2043\205\200\0\1\0\1\0\1\0\1\tlocalhost\7gateway\0052"..., 16383, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.1.254")}, [16]) = 156 time([1139901798]) = 1139901798 gettimeofday({1139901798, 321969}, NULL) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1017, ...}) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1017, ...}) = 0 sendto(28, "\2044\1\0\0\1\0\0\0\0\0\0\tlocalhost\7gateway\0052"..., 45, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.1.254")}, 16) = 45 gettimeofday({1139901798, 322372}, NULL) = 0 gettimeofday({1139901798, 322482}, NULL) = 0 ioctl(4, FIONREAD, [0]) = 0 gettimeofday({1139901798, 322553}, NULL) = 0 select(29, [3 4 5 6 8 11 12 13 14 15 16 17 21 23 24 28], [], [], {0, 76991}) = 1 (in [28], left {0, 44000}) recvfrom(28, "\2044\205\200\0\1\0\1\0\1\0\1\tlocalhost\7gateway\0052"..., 16383, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.1.254")}, [16]) = 156 time([1139901798]) = 1139901798 gettimeofday({1139901798, 386355}, NULL) = 0 ...... Also, here's some output from tethereal: Capturing on eth0 1 0.000000 192.168.1.134 -> 192.168.1.254 DNS Standard query AAAA localhost.gateway.2wire.net 2 0.003173 192.168.1.254 -> 192.168.1.134 DNS Standard query response A 127.0.0.1 3 0.003536 192.168.1.134 -> 192.168.1.254 DNS Standard query AAAA localhost.gateway.2wire.net 4 0.003837 192.168.1.254 -> 192.168.1.134 DNS Standard query response A 127.0.0.1 5 0.004111 192.168.1.134 -> 192.168.1.254 DNS Standard query AAAA localhost.gateway.2wire.net 6 0.029162 192.168.1.254 -> 192.168.1.134 DNS Standard query response A 127.0.0.1 7 0.032820 192.168.1.134 -> 192.168.1.254 DNS Standard query AAAA localhost.gateway.2wire.net 8 0.074574 192.168.1.254 -> 192.168.1.134 DNS Standard query response A 127.0.0.1 9 0.075135 192.168.1.134 -> 192.168.1.254 DNS Standard query AAAA localhost.gateway.2wire.net 10 0.127305 192.168.1.254 -> 192.168.1.134 DNS Standard query response A 127.0.0.1 11 0.128193 192.168.1.134 -> 192.168.1.254 DNS Standard query AAAA localhost.gateway.2wire.net 12 0.170688 192.168.1.254 -> 192.168.1.134 DNS Standard query response A 127.0.0.1 13 0.172576 192.168.1.134 -> 192.168.1.254 DNS Standard query AAAA localhost.gateway.2wire.net 14 0.218549 192.168.1.254 -> 192.168.1.134 DNS Standard query response A 127.0.0.1 15 0.219870 homeportal.gateway.2wire.net -> Broadcast ARP Who has 192.168.1.125? Tell 192.168.1.254 16 0.223238 192.168.1.134 -> 192.168.1.254 DNS Standard query AAAA localhost.gateway.2wire.net 17 0.275258 192.168.1.254 -> 192.168.1.134 DNS Standard query response A 127.0.0.1 18 0.276781 192.168.1.134 -> 192.168.1.254 DNS Standard query AAAA localhost.gateway.2wire.net 19 0.317059 192.168.1.254 -> 192.168.1.134 DNS Standard query response A 127.0.0.1 20 0.317627 192.168.1.134 -> 192.168.1.254 DNS Standard query AAAA localhost.gateway.2wire.net 21 0.389871 192.168.1.254 -> 192.168.1.134 DNS Standard query response A 127.0.0.1 22 0.390739 192.168.1.134 -> 192.168.1.254 DNS Standard query AAAA localhost.gateway.2wire.net 23 0.441088 192.168.1.254 -> 192.168.1.134 DNS Standard query response A 127.0.0.1 24 0.441935 192.168.1.134 -> 192.168.1.254 DNS Standard query AAAA localhost.gateway.2wire.net 25 0.513919 192.168.1.254 -> 192.168.1.134 DNS Standard query response A 127.0.0.1 26 0.514790 192.168.1.134 -> 192.168.1.254 DNS Standard query AAAA localhost.gateway.2wire.net 27 0.544990 192.168.1.254 -> 192.168.1.134 DNS Standard query response A 127.0.0.1 28 0.552795 192.168.1.134 -> 192.168.1.254 DNS Standard query AAAA localhost.gateway.2wire.net 29 0.594995 192.168.1.254 -> 192.168.1.134 DNS Standard query response A 127.0.0.1 So Kontact sends about 20 requests / second. I hope you could figure out what's going on. This is *very* annoying.
Ok, now I got the same thing from Konqueror! Ethereal shows 20,000 messages in four minutes. This is unbelievable. strace shows pretty much the same output as for Kontact: ......... gettimeofday({1140302210, 268597}, NULL) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1017, ...}) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1017, ...}) = 0 sendto(29, "|k\1\0\0\1\0\0\0\0\0\0\tlocalhost\7gateway\0052"..., 45, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.1.254")}, 16) = 45 gettimeofday({1140302210, 269757}, NULL) = 0 gettimeofday({1140302210, 270002}, NULL) = 0 ioctl(3, FIONREAD, [0]) = 0 gettimeofday({1140302210, 270374}, NULL) = 0 select(30, [3 4 5 7 9 12 13 19 29], [], [], {0, 967295}) = 1 (in [29], left {0, 944000}) recvfrom(29, "|k\205\200\0\1\0\1\0\1\0\1\tlocalhost\7gateway\0052"..., 16383, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.1.254")}, [16]) = 156 time([1140302210]) = 1140302210 gettimeofday({1140302210, 294238}, NULL) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1017, ...}) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1017, ...}) = 0 sendto(29, "|l\1\0\0\1\0\0\0\0\0\0\tlocalhost\7gateway\0052"..., 45, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.1.254")}, 16) = 45 gettimeofday({1140302210, 294614}, NULL) = 0 gettimeofday({1140302210, 294703}, NULL) = 0 ioctl(3, FIONREAD, [0]) = 0 gettimeofday({1140302210, 294770}, NULL) = 0 select(30, [3 4 5 7 9 12 13 19 29], [], [], {0, 942899}) = 1 (in [29], left {0, 920000}) recvfrom(29, "|l\205\200\0\1\0\1\0\1\0\1\tlocalhost\7gateway\0052"..., 16383, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.1.254")}, [16]) = 156 time([1140302210]) = 1140302210 gettimeofday({1140302210, 319971}, NULL) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1017, ...}) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1017, ...}) = 0 sendto(29, "|m\1\0\0\1\0\0\0\0\0\0\tlocalhost\7gateway\0052"..., 45, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.1.254")}, 16) = 45 gettimeofday({1140302210, 321129}, NULL) = 0 gettimeofday({1140302210, 321370}, NULL) = 0 ioctl(3, FIONREAD, [0]) = 0 gettimeofday({1140302210, 321741}, NULL) = 0 select(30, [3 4 5 7 9 12 13 19 29], [], [], {0, 915928}) = 1 (in [29], left {0, 888000}) recvfrom(29, "|m\205\200\0\1\0\1\0\1\0\1\tlocalhost\7gateway\0052"..., 16383, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.1.254")}, [16]) = 156 time([1140302210]) = 1140302210 ...........
Ok, it's probably hard to reproduce such behavior... But can someone tell me how to debug this? How can I tell which function is responsible for sending the DNS queries?
This will be very hard to debug: 1) the function you're looking for is KNetwork::Internal::KGetAddrinfoWorker::run() (kdelibs/kdecore/network/kresolverstandardworkers.cpp line 956) 2) that function is ALWAYS run in an auxiliary thread (never the main event-loop thread) 3) the process doing the DNS lookups probably isn't kontact or konqueror but the IOSlave processes (kio_http, kio_pop3, kio_imap4, etc.), that you can't run -- you have to attach to running ones What's more, we catch any attempts to look up "localhost" and filter it out, since it's a well-known name and should always resolve to 127.0.0.1. What I'm more interested in is why it's trying to resolve "localhost.gateway.2wire.net" and why that often. So what I suggest you do is add a breakpoint to KNetwork::KResolver::start() and see what is asking for DNS resolution. Post the backtrace here so that we can help. Is there any way we can reproduce this?
Of course, I don't know how to reproduce it. Well, it seems to happen to Konqueror after it's been running for a few hours... Often in a Konqueror started because of restored session. But that's about it. But, it happened again, now in debug mode. I breakpointed KNetwork::KResolver::start() - and it was never reached. (That is, if I tell Konqueror to go to some website, it stops at the breakpoint. But not when it sends the localhost requests.) I suspended all kio-* services - kio-http, kio-file, etc. Still, requests are being sent. I tried to single-step in gdb - without debug info, so not terribly useful - but it seems that it IS in the main loop... And maybe even in Qt code. Here's what I have: .... (gdb) s Single stepping until exit from function _ZN10QEventLoop9enterLoopEv, which has no line number information. ### Requests keep getting sent... So I Ctrl-C it. Program received signal SIGINT, Interrupt. 0xffffe410 in __kernel_vsyscall () (gdb) s Single stepping until exit from function __kernel_vsyscall, which has no line number information. 0x4234563d in select () from /lib/libc.so.6 ### Nothing happened (gdb) s Single stepping until exit from function select, which has no line number information. 0x429ac5e9 in QEventLoop::processEvents () from /usr/qt/3/lib/libqt-mt.so.3 ### Still nothing (gdb) s Single stepping until exit from function _ZN10QEventLoop13processEventsEj, which has no line number information. 0x42a0cb1c in QEventLoop::enterLoop () from /usr/qt/3/lib/libqt-mt.so.3 ### A SINGLE request got sent right here (gdb) bt #0 0x42a0cb1c in QEventLoop::enterLoop () from /usr/qt/3/lib/libqt-mt.so.3 #1 0x42a0ca76 in QEventLoop::exec () from /usr/qt/3/lib/libqt-mt.so.3 #2 0x429f74d9 in QApplication::exec () from /usr/qt/3/lib/libqt-mt.so.3 #3 0x43bf3aff in kdemain () from /usr/kde/3.5/lib/libkdeinit_konqueror.so #4 0x422a4f1b in __libc_start_main () from /lib/libc.so.6 #5 0x080486a1 in ?? () (gdb) s ### Flood of requests, again. And it keeps going this way for the next 5 or so "Ctrl-C"s and "step"s. Then everything repeats - "step" returns immediately a few times, then sends a single request and returns, then flood again.
I gave up and added the line "127.0.0.1 localhost.gateway.2wire.net" to my /etc/hosts file... But it doesn't help!!! When I run "ping localhost.gateway.2wire.net", it doesn't send any DNS requests. But KDE programs still keep DoSing my router. Also, I attached gdb to Kile while it was sending the DNS requests, stepped a few times, then waited for a while. After that, when I told gdb to continue running, it kept stopping, saying "Program received signal SIG42, Real-time event 42." Does that mean anything? (Could it be related to the problem?) Is there any workaround for this? Anything that would stop the DoS attacks? (Other than not using KDE programs...)
SIG42? I've never seen that one. If you had said SIG32, 33 or 34, I could guess it was LinuxThreads. But I've never seen signal 42 be used *at all*. There's something really strange with your setup.
Ok... I found a way to reproduce it (on my system, at least). Apparently, this happens whenever I open a print dialog, and it tries to connect to CUPS at "localhost:631". Looks like the problem is actually in Qt, not KDE. KMCupsManager::slotAsyncConnect calls QSocket::connectToHost, which tries to resolve "localhost", but for some reason, it does that both in IPv4 and IPv6: qsocket.cpp, line 397: void QSocket::connectToHost(const QString &host, Q_UINT16 port) { .... d->dns4 = new QDns( host, QDns::A ); d->dns6 = new QDns( host, QDns::Aaaa ); .... } For QDns:A, it has a check for "localhost", at qdns.cpp, line 1350: if ( r->label().lower() == "localhost" ) { ... But nothing like that for QDns:Aaaa, of course. So it schedules a query to be sent. I don't know - maybe it's Ok to do that. It should resolve "localhost" in IPv4 and move on... But with other programs, that doesn't happen at all. Any ideas? I guess I'll play around with this more... Debugging Trolltech's code is not so bad after all :) Also, here's a backtrace of the place where the query gets sent: #0 QDnsDomain::cached (r=0x82b1e40) at qdns.cpp:1508 #1 0xb7040585 in QDns::addresses (this=0x82b1e40) at qdns.cpp:2020 #2 0xb705b660 in QSocket::tryConnecting (this=0x822a078) at qsocket.cpp:451 #3 0xb705bc30 in QSocket::connectToHost (this=0x822a078, host=@0x82b08d4, port=631) at qsocket.cpp:411 #4 0xb64091df in KMCupsManager::slotAsyncConnect (this=0x8282b08) at kmcupsmanager.cpp:959 #5 0xb641f0d3 in KMCupsManager::qt_invoke (this=0x8282b08, _id=6, _o=0xbfcbd0c8) at kmcupsmanager.moc:101 #6 0xb6de3bdf in QObject::activate_signal (this=0x823ace0, clist=0x823ad58, o=0xbfcbd0c8) at qobject.cpp:2355 #7 0xb71f0141 in QSignal::signal (this=0x823ace0, t0=@0x823ad08) at moc_qsignal.cpp:100 #8 0xb6e0599d in QSignal::activate (this=0x823ace0) at qsignal.cpp:212 #9 0xb6e0fcf4 in QSingleShotTimer::event (this=0x823acb8) at qtimer.cpp:286 #10 0xb6d6e299 in QApplication::internalNotify (this=0xbfcbdffc, receiver=0x823acb8, e=0xbfcbd468) at qapplication.cpp:2635 #11 0xb6d6e4bc in QApplication::notify (this=0xbfcbdffc, receiver=0x823acb8, e=0xbfcbd468) at qapplication.cpp:2358 #12 0xb76d7aa2 in KApplication::notify (this=0xbfcbdffc, receiver=0x823acb8, event=0xbfcbd468) at kapplication.cpp:550 #13 0xb7ea418d in QApplication::sendEvent (receiver=0x823acb8, event=0xbfcbd468) at qapplication.h:491 #14 0xb6d5dce8 in QEventLoop::activateTimers (this=0x8181318) at qeventloop_unix.cpp:556 #15 0xb6d0c273 in QEventLoop::processEvents (this=0x8181318, flags=4) at qeventloop_x11.cpp:389 #16 0xb6d8a331 in QEventLoop::enterLoop (this=0x8181318) at qeventloop.cpp:198 #17 0xb6d6cd73 in QApplication::enter_loop (this=0xbfcbdffc) at qapplication.cpp:2790 #18 0xb6fcaa74 in QDialog::exec (this=0x8200a08) at qdialog.cpp:432 #19 0xb7fa16be in PrintWrapper::slotPrint (this=0x81dba58) at printwrapper.cpp:272 #20 0xb7fa1802 in PrintWrapper::qt_invoke (this=0x81dba58, _id=45, _o=0xbfcbd9c8) at printwrapper.moc:89 #21 0xb6de3bdf in QObject::activate_signal (this=0x81da6a0, clist=0x81ddbc8, o=0xbfcbd9c8) at qobject.cpp:2355 #22 0xb71f0141 in QSignal::signal (this=0x81da6a0, t0=@0x81da6c8) at moc_qsignal.cpp:100 #23 0xb6e0599d in QSignal::activate (this=0x81da6a0) at qsignal.cpp:212 #24 0xb6e0fcf4 in QSingleShotTimer::event (this=0x81da678) at qtimer.cpp:286 #25 0xb6d6e299 in QApplication::internalNotify (this=0xbfcbdffc, receiver=0x81da678, e=0xbfcbdd68) at qapplication.cpp:2635 #26 0xb6d6e4bc in QApplication::notify (this=0xbfcbdffc, receiver=0x81da678, e=0xbfcbdd68) at qapplication.cpp:2358 #27 0xb76d7aa2 in KApplication::notify (this=0xbfcbdffc, receiver=0x81da678, event=0xbfcbdd68) at kapplication.cpp:550 #28 0xb7ea418d in QApplication::sendEvent (receiver=0x81da678, event=0xbfcbdd68) at qapplication.h:491 #29 0xb6d5dce8 in QEventLoop::activateTimers (this=0x8181318) at qeventloop_unix.cpp:556 #30 0xb6d0c273 in QEventLoop::processEvents (this=0x8181318, flags=4) at qeventloop_x11.cpp:389 #31 0xb6d8a331 in QEventLoop::enterLoop (this=0x8181318) at qeventloop.cpp:198 #32 0xb6d8a256 in QEventLoop::exec (this=0x8181318) at qeventloop.cpp:145 #33 0xb6d6cd47 in QApplication::exec (this=0xbfcbdffc) at qapplication.cpp:2758 #34 0xb7f9fe07 in kdemain (argc=1, argv=0xbfcbe184) at main.cpp:54 #35 0x08048742 in main (argc=1, argv=0xbfcbe184) at kprinter.la.cpp:2
Hm, actually, it's not just the print dialog. I tested Trolltech's example of a client at http://doc.trolltech.com/3.3/clientserver-example.html#x798 - and it sends the IPv6 "localhost" requests just as well. Looks like it's a problem with Socket::connectToHost.
Then this problem has been solved in Qt 4 already, since QDns is no longer used to do host lookups. The code in KMCupsManager shouldn't be using QSocket at all, though.
Closing old Resolved status bug.