Version: CVS of 05/11/02 (using KDE Devel) Installed from: Compiled sources Compiler: gcc 3.2 OS: Linux I use a modem to connect to my ISP. Kopete starts with the rest of my desktop, but if I try to connect it after dialling in, the plugins (MSN + ICQ) fail to connect. They remain in the connecting state. If I start Kopete _after_ dialling in, it works properly. It appears that either IM servers' IP addresses are looked up at startup, which fails, or that the resolver is setup once at startup, and so does not notice when my /etc/resolv.conf is modified when I dial in. I've checked this theory by looking up the servers (messenger.hotmail.com and login.icq.com) IP addresses by hand and entering these in kopeterc, and this solves my problem. However, the hostnames are a more reliable way of connecting as the servers seem to be running some kind of rotating DNS for load balancing. No other programs exhibit this behaviour.
Subject: Re: [Kopete-devel] New: Kopete won't connect if started before Internet connection On Wednesday 06 November 2002 11:10, William Stephenson wrote: > It appears that either IM servers' IP addresses are looked up at startup, > which fails, or that the resolver is setup once at startup, and so does not > notice when my /etc/resolv.conf is modified when I dial in. That's standard behaviour for all unix programs that I know of. Changing /etc/hosts during runtime doesn't work either, nor for KDE apps nor for console apps. > No other programs exhibit this behaviour. Are you sure about this? Until I read this line I was about to reassign this bug as a wishlist item to kdelibs (KExtendedSocket), but if other apps do this all right then it must be somewhere in Kopete. Though I fail to see why Kopete is acting different here.
Subject: test of resolving hostnames Yes, I am sure - I just did a quick check with Konq, Kmail, KSirc and Licq. All of them were able to resolve IP addresses once there was a PPP connection despite being started while there was no useful data in /etc/resolv.conf. AFAIK only the first 2 use KDE network code. The only app I recall DID that behaved like Kopete does was Netscape 4.x. Will
Subject: Re: [Kopete-devel] Kopete won't connect if started before Internet connection On Wednesday 06 November 2002 19:30, Will Stephenson wrote: > ------- You are receiving this mail because: ------- > You are the assignee for the bug, or are watching the assignee. > > http://bugs.kde.org/show_bug.cgi?id=50279 > > ------- Additional Comments From will@stevello.free-online.co.uk > 2002-11-06 19:30 ------- Subject: test of resolving hostnames > > Yes, I am sure - I just did a quick check with Konq, Kmail, KSirc and > Licq. All of them were able to resolve IP addresses once there was a PPP > connection despite being started while there was no useful data in > /etc/resolv.conf. Very strange. In the case of Konq and KMail it could be because they use I/O slaves, which are separate processes, but that doesn't cover ksirc and licq. Still I don't get this at all, the MSN plugin uses KExtendedSocket all over the place and has no other socket code. Why would changing resolv.conf not be picked up here, but work correctly in other applications?
Subject: Re: [Kopete-devel] Kopete won't connect if started before Internet connection > Why would changing resolv.conf not be picked up here, but work >correctly in other applications? We call res_init() if we get a lookup error to force a re-read of /etc/resolv.conf Can it be that you use asynchronous lookups in Kopete? I think the asynchronous lookup doesn't call res_init() when it fails. See KExtendedSocket::doLookup() Cheers, Waldo
Subject: Re: [Kopete-devel] Kopete won't connect if started before Internet connection On Wed, 6 Nov 2002, Waldo Bastian wrote: > We call res_init() if we get a lookup error to force a re-read of > /etc/resolv.conf Can it be that you use asynchronous lookups in > Kopete? I think the asynchronous lookup doesn't call res_init() when > it fails. > > See KExtendedSocket::doLookup() Last line of msnsocket.cpp, method MSNSocket::connect: m_socket->startAsyncConnect(); That explains a whole lot if it doesn't do res_init here :-) Looking at the code it looks to me that startAsyncConnect() still calls doLookup() internally though, but not in all cases. Can I consider this a bug in KExtendedSocket and reassign this bug there, or am I supposed to handle this some way in Kopete itself?
No, this needs to be handled in KExtendedSocket. In fact the static function doResInit() in qdns.cpp needs to be called in order to force Qt to reread the nameserver information. That is currently not possible. TrollTech: I would like to have a function QDns::reset() that calls doResInit() to reread the nameservers. Not sure what should happen with outstanding queries in such case. Ideally they should just proceed as is. Alternatively they could be aborted but then they should either be automatically reissued or return with some sort of EAGAIN errorcode so that the caller can reissue them.
Subject: New Issue from qt-bugs@trolltech.com Hello, This is an auto-reply to your email with the subject "[Bug 50279] Kopete won't connect if started before Internet connection". We have read your email but require more time to deal with it. We have assigned it the issue number #10388; please use this number if you email us about the issue. We regret that we cannot guarantee a personal reply. When submitting bug reports please make sure that you tell us which version of Qt and which platform you are using. If you provide a small self-contained and compilable example that demonstrates the problem we will probably be able to identify the cause and propose a solution much faster than if you just give a general description. Typically bug reporters modify one of the smaller Qt examples to reproduce their problem. If you are experiencing a build problem, make sure that your compiler is correctly installed and that you have applied any necessary patches; see these pages for further information: http://www.trolltech.com/developer/platforms/index.html http://www.trolltech.com/developer/compilers/index.html You might also want to try the latest Qt snapshot to see if the problem has already been addressed in our development tree. Snapshots are available from http://www.trolltech.com/developer/download/snapshots.html Best regards, The Trolltech Support Team -- http://www.trolltech.com
Subject: Re: [Issue N10388] Kopete won't connect if started before Internet connection Hi, > No, this needs to be handled in KExtendedSocket. In fact the static > function doResInit() in qdns.cpp needs to be called in order to force > Qt to reread the nameserver information. That is currently not > possible. > > TrollTech: I would like to have a function QDns::reset() that calls > doResInit() to reread the nameservers. > [...] This is not the only problem that QDns has (e.g., it supports only DNS lookups, but some systems are configured to use other types of hostname resolution). We are well aware of the problem and are considering to use a more stable way to do hostname resolution (basically, the only safe way to do it is to rely on system calls, like gethostbyname()). Having said this, it also means that those changes won't be made for one of the next upcoming bugfix releases. I am afraid to say that if you need a solution in the nearer future, the best way to do it, is to use gethostbyname() and use the IP address for the socket calls. Best regards, Rainer -- Rainer M. Schmid Trolltech AS, Waldemar Thranes gate 98, NO-0175 Oslo, Norway
A possible way out for the problem would do be to do a synchronous lookup, while still using the asynchronous connection. You'd do that by calling m_socket->lookup() before calling m_socket->startAsyncConnect(). The problem is, of course, that that's a blocking call. However, if /etc/resolv.conf is properly configured for unconnected state, the resolution will fail immediately. The only problem will be the lookup delay when the user is connected. That said, I agree with the report from Trolltech. We are all missing an underlying asynchronous lookup method. While glibc provides an experimental one (getaddrinfo_a), it's far from being widespread. I have tried myself to write an async-DNS library and the project is open in SourceForge (resolver), but I haven't had time to dedicate to it. There's also project libdenise that aims at the same goal. The only real solution for the moment for QDns and asynchronous lookup is to do the lookup in another thread... TrollTech: when you do write the new code, please use getaddrinfo(3), or at least gethostbyname2_r(3)
Subject: kdenonbeta/kopete/protocols/msn CVS commit by mklingens: Fix some obscure problems in the DNS lookups: // Ideally we want to the full connection to MSN to be handled async, but due // to some design issues in QDns this fails if people with dialup connections // start Kopete before their internet connection. The workaround from // TrollTech is to not use QDns, but use the libc gethostbyname call instead. // The sync calls in KExtendedSocket use this, only the async lookup uses DNS. // This is slightly annoying as it blocks the GUI for the duration of the DNS // lookup, but properly configured systems will hardly notice that. Besides, // there's nothing we can do about it... For Qt 4/KDE 4 we can hopefully // leave the lookup to the socket again and remove the manual lookup call. // This cannot be fixed in Qt 3 unfortunately. This commit fixes the Kopete side of bug 50279, but in fact it's more a KExtendedSocket/QDns problem (bug is already reassigned there), so I'm not closing it. It also works around the problem with recent glibcs for debian unstable and Mandrake Cooker that breaks QDns, so it also 'fixes' bug 52494. Here the real problem is beyond our reach as well, but it works nevertheless as workaround for now. CCMAIL: 50279@bugs.kde.org CCMAIL: 52494-done@bugs.kde.org M +15 -0 msnsocket.cpp 1.47 --- kdenonbeta/kopete/protocols/msn/msnsocket.cpp #1.46:1.47 @@ -99,4 +99,19 @@ void MSNSocket::connect( const QString & aboutToConnect(); + + // FIXME KDE4? + // Ideally we want to the full connection to MSN to be handled async, + // but due to some design issues in QDns this fails if people with + // dialup connections start Kopete before their internet connection. + // The workaround from TrollTech is to not use QDns, but use the + // libc gethostbyname call instead. The sync calls in KExtendedSocket + // use this, only the async lookup uses DNS. + // This is slightly annoying as it blocks the GUI for the duration + // of the DNS lookup, but properly configured systems will hardly + // notice that. Besides, there's nothing we can do about it... + // For Qt 4/KDE 4 we can hopefully leave the lookup to the socket + // again and remove the manual lookup call. This cannot be fixed + // in Qt 3 unfortunately. + m_socket->lookup(); m_socket->startAsyncConnect(); }
Subject: New Issue from qt-bugs@trolltech.com Hello, This is an auto-reply to your email with the subject "[Bug 50279] Kopete won't connect if started before Internet connection". We have read your email but require more time to deal with it. We have assigned it the issue number #13578; please use this number if you email us about the issue. We regret that we cannot guarantee a personal reply. When submitting bug reports please make sure that you tell us which version of Qt and which platform you are using. If you provide a small self-contained and compilable example that demonstrates the problem we will probably be able to identify the cause and propose a solution much faster than if you just give a general description. Typically bug reporters modify one of the smaller Qt examples to reproduce their problem. If you are experiencing a build problem, make sure that your compiler is correctly installed and that you have applied any necessary patches; see these pages for further information: http://www.trolltech.com/developer/platforms/index.html http://www.trolltech.com/developer/compilers/index.html You might also want to try the latest Qt snapshot to see if the problem has already been addressed in our development tree. Snapshots are available from http://www.trolltech.com/developer/download/snapshots.html Best regards, The Trolltech Support Team -- http://www.trolltech.com
I'm changing the status on this bug to LATER. When the new socket API is in place, we will hopefully be able to do asynchronous lookups without problems. Till then, doing a synchronous lookup is the only solution. Or if TT will provide us with a method to reset their /etc/resolv.conf cache inside QDns.