QSocket problem with transconnect (proxy)?

[Michael Goffioul]

Simon Hausmann wrote:
> 
> On Wed, Jun 19, 2002 at 11:15:59AM +0200, Michael Goffioul wrote:
> > Hi,
> >
> > I found a weird behavior in QSocket but I don't know if it's a bug
> > or not. I found the problem when using QSocket along with transconnect,
> > a utility that redirect "connect" calls to a HTTP proxy by preloading
> > a dynamic library.
> >
> > The problem appeared when trying to make a connection on localhost:631.
> > I traced the process inside QSocket and here's what's happening (more
> > or less):
> > 1) perform a host lookup
> > 2) tried to connect on the first address found (127.0.0.1)
> > 3) in my case the connection is established immediately, that is
> >    d->socket->connect() returns true. The write socket notifier
> >    is enabled.
> > 4) the notifier fires an event on QSocket -> QSocket::tryConnection()
> > 5) tries AGAIN to connect but this time using d->addr and d->port,
> >    however d->addr == 0.0.0.0. I looked into qsocket.cpp and this is
> >    the only place where d->addr is used, so I don't know if d->addr
> >    can be different from 0.0.0.0, and where it might be set to something
> >    different.
> >
> > I found it because when you use transconnect, each connect is analyzed
> > by this utility: the first address 127.0.0.1 is usually covered and
> > considered as local such that no proxy is used. However the second
> > one 0.0.0.0 is not covered as local address and the utility tries to
> > use the proxy and just fails.
> 
> I think this is a bug in transconnect, or rather: A missing feature.
> 
> What QSocket does is to make the socket non-blocking. Then it issues
> the first connect(), which immediately returns with EINPROGRESS, as
> the socket is non-blocking. As the socketnotifier indicates
> writability, QSocket issues a second connect() (on the same fd) ,
> which (in the normal case) returns 0, indicating a connection
> success.

I don't think that's what happening. As I explained above, the first
connect attempt establish the connection immediately, this can
happen even if the socket is non-blocking (for example on a LAN).
The socketnotifier being enabled, an event is fired, triggering
QSocket::sn_write() -> QSocket::tryConnection(). The latter again
tries to establish the connection, but the problem is that now it
is using d->addr, which contains 0.0.0.0, it's not the same fd.
This is the only place in the whole qsocket.cpp file where
d->addr is used, I couldn't find any place where this might be
set to something else. No surprise then that it contains 0.0.0.0.
But trying to connect on 0.0.0.0 fails using transconnect.
Don't know where's the fault, though.

Michael.

-- 
------------------------------------------------------------------
Michael Goffioul		IMEC-DESICS-MIRA
e-mail: goffioul at imec.be	(Mixed-Signal and RF Applications)
Tel:    +32/16/28-8510		Kapeldreef, 75
Fax:    +32/16/28-1515		3001 HEVERLEE, BELGIUM
------------------------------------------------------------------