On Tue, 2003-01-07 at 08:39, Mika Liljeberg wrote:
> > I can't speak to what 2.5.x's output is for this program, but i bet it's
> > the same. If it's not it must be a bug in my code :P
>
> According to Joaquim, and I can confirm this, Linux 2.5 returns the
> following:
>
> sock1's peer = '/tmp/sock1'
> sock2's peer = '/tmp/sock2'
>
> I have to agree that definately looks like a bug in Linux 2.5.
> getpeername() seems to return the local address rather than the remote.
Ah yeah, looking at the code I *think* I see the problem. Man, as a
freebsd person I never thought I'd be mucking around with linux kernel
source :)
anyway, here's the body of unix_getname (from linux 2.5.49,
net/unix/af_unix.c) with a 1 line patch:
1110 struct sock *sk = sock->sk;
1111 struct unix_sock *u = unix_sk(sk);
1112 struct sockaddr_un *sunaddr=(struct sockaddr_un *)uaddr;
1113 int err = 0;
1114
1115 if (peer) {
1116 sk = unix_peer_get(sk);
1117
1118 err = -ENOTCONN;
1119 if (!sk)
1120 goto out;
+ u = unix_sk (sk);
1121 err = 0;
1122 } else {
1123 sock_hold(sk);
1124 }
1125
1126 unix_state_rlock(sk);
1127 if (!u->addr) {
1128 sunaddr->sun_family = AF_UNIX;
1129 sunaddr->sun_path[0] = 0;
1130 *uaddr_len = sizeof(short);
1131 } else {
1132 struct unix_address *addr = u->addr;
1133
1134 *uaddr_len = addr->len;
1135 memcpy(sunaddr, addr->name, *uaddr_len);
1136
Please excuse the weird diff syntax, i'm using LXR since I don't have a
unix kernel tree on my machine here.
> > If you comment out the bind(2) call before sock1's connect(2) call then
> > sock2's peer shows up as "", but that's because it's not being bound.
>
> Incidentally, orbit does *not* bind the client socket. This means that
> getpeername() is *supposed* to return a zero path. Thus, zeroing the
> path name is harmless. It's a valid workaround for the Linux 2.5 bug,
> and merely redundant with Linux 2.4.
Hrm, yeah.
> What I *don't* understand is why the orbit code calls getpeername() in
> the first place. Maybe they just thought that was the easiest way to get
> a valid address structure.
Yeah, that's a good question, although it does open the code up to bugs
(obviously :)
Chris
_______________________________________________
evolution maillist - [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/evolution
