41.5")}, 16) = -1 EALREADY (Operation already in progress)
select(256, NULL, [3], NULL, {0, 0}) = 0 (Timeout)
connect(3, {sin_family=AF_INET, sin_port=htons(80),
sin_addr=inet_addr("a.b.c.d")}, 16) = -1 EALREADY (Operation already
in progress)
select(256, NULL, [3], NULL, {0, 0}) = 0 (Timeout)
connect(3, {sin_family=AF_INET, sin_port=htons(80),
sin_addr=inet_addr("a.b.c.d")}, 16) = -1 EALREADY (Operation already
in progress)
select(256, NULL, [3], NULL, {0, 0}) = 0 (Timeout)
connect(3, {sin_family=AF_INET, sin_port=htons(80),
sin_addr=inet_addr("a.b.c.d")}, 16) = -1 EALREADY (Operation already
in progress)
select(256, NULL, [3], NULL, {0, 0}) = 0 (Timeout)
connect(3, {sin_family=AF_INET, sin_port=htons(80),
sin_addr=inet_addr("
When I try to telnet to the server/port I'm using lynx to reach,
I get no connection at all. A tcpdump of the connect attempt shows
outoing SYNs but no incoming packets at all.
So what I imagine is happening is lynx (2.3 BETA) calls 'connect'
with a non-blocking socket, and connect returns immediately. Then lynx
selects with a zero timeout, the select returns, and lynx calls connect
again. But why would lynx do anything so stupid?
Does anyone know if this is because lynx is confused by Linux's
return value (EALREADY) or because lynx is really brain damaged or
because of a bug in lynx, or what?
David Schwartz