getpeername broken? ( was Re: probably problem with "lo" interface (Re: Strange problem with 2.3.42) )

From: Craig Schlenter (craig@qualica.com)
Date: Thu Feb 03 2000 - 13:46:41 EST


On Thu, Feb 03, 2000 at 09:02:41AM +0200, I wrote:
> On Wed, Feb 02, 2000 at 05:05:41PM -0800, David S. Miller wrote:
> > Date: Thu, 3 Feb 2000 01:14:22 +0000 (UTC)
> > From: Vesselin Atanasov <vesselin@bgnet.bg>
> >
> > I have same problem since 2.3.40. I have tracked it to a problem with "lo"
> > interface. It seems that after successfull authentication, login tries to
> > access 127.0.0.1 on port 111. The kernel responds with "port unreachable"
> > but for some reason login does not see it. Too bad I don't have time to
> > investigate the problem :-(
> >
> > tcpdump output, kernel config, and other info are available on request.
> >
> > Please, tcpdump would be useful. And it would be excellant if you
> > could get an 'strace' log of the process which gets stuck. I bet
> > it is calling getpeername() or similar to check the connected'ness
> > of the socket and we're doing the wrong thing.
>
> On a slightly related topic, I see that 2.3.41 (haven't checked .42 yet)
> still has the following check in inet_getname btw.:
>
> if (!sk->dport)
> return -ENOTCONN;
>
> 2.2.x has:
> if (!tcp_connected(sk->state))
> return(-ENOTCONN);
>
> The symptoms (in 2.3.18 when I reported this) were that strobe reported
> all ports as listening because the getpeername call always succeeded as I
> recall. I can dig up my original mail on this if it will help or retest
> on 2.3.42 as soon as I'm vaguely close to my development machine to see
> if the problem remains.

Just tested now on 2.3.42 and strobe still reports any port I choose as
listening so getpeername is still broken IMHO. I see that tcp_connected
has been removed in 2.3.41 so I'm fishing for recommendations on what
the affected line should look like ... I've ignorantly toyed with
                if (sk->state != SS_CONNECTED)
and
                if (sk->state == SS_UNCONNECTED)
but neither seem to have quite the right effect so I'd guess something
closer to the complexity of the original tcp_connected is required?

Thank you,

--Craig

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Mon Feb 07 2000 - 21:00:10 EST