On Mon, Sep 02, 2002 at 09:04:38PM -0400, Luis and Kim Soltero wrote:
> I am having a very similar problem to R. Church but on 
> a RH7.3 system.  For some reason the codalist server
> will not post my e-mails to the list althogh I am subscribed
> and have been receiving e-mail from the list.  

There is a quite agressive spamfilter active, Codalist has been
receiving about 30-40 spams a day, I had to 'moderate' every message by
hand for a while until I was sure it the filter caught all spam (and not
dropping too much legitimate email). One day the coda.cs.cmu.edu domain
got blacklisted as a 'spam site', but because we were relaying or got
hacked, but simply because codalist accepted and forwarded spam.

In your case the email address probably pushes the filter to it's edge
and anything suspicious, not finding your mailserver's MX records or
other normally minor 'issues', would be enough to drop the mail into a
mailbox that I hardly ever check.

Because the spam filter has been a bit overagressive, you're not the
first whose email was dropped, I recently switched to allowing only
subscribers to post. This is why Stephen Turnbull's xemacs.org address
wasn't accepted. However at the same time I forgot to remove the spam
filter, so at the moment there are probably only a handful of people
that are both subscribed and don't trigger the filter, sigh. That should
be fixed soon (will look into it later tonight).

> Anyway,  Here is my posting.  Maybe it will shed
> light on the situation.... Both R. Church and I have
> servers with dual ethernet cards and we feel
> that the problem might have something to do
> with this.

Oh, yeah multihoming is not only hard to get right, there are several
ways to do it and Coda servers don't really like any way it is done.

Coda clients shouldn't have a problem with multi-homing. In fact my
laptop currently has 802.11b, ppp and ethernet interfaces in use, and
my client has no problem talking to the servers as long as routing is
set up right.

> It seems that the server sees the request from the client
> but when it tries to reply the data is sent out the
> wrong interface (???) and the request times out.

The server sends the replies to the source ip-address of the received
request. This address is typically identical to the ip-address of the
outgoing interface on the client, normally that should work just fine.

A more likely problem is that initially the server is only asked for
'volume location information', the actual volume could for instance be
on another Coda server.

This looks something like,

    ServerCount 3
    Replica0 id c7000085, Server0 128.2.191.192
    Replica1 id c9000082, Server1 128.2.209.199
    Replica2 id dd000085, Server2 128.2.222.111

The client then connects to the replicas hosted on server at these
ip-addresses. And here is the big issue, in the GetVolumeInfo reply
packet there is only room for a single ip-address. So on a multi-homed
server it just contains the first ip-address that you get after doing,

    gethostbyname(hostname());

On some systems this used to return 127.0.0.1 (localhost), i.e. the
client would try to connect to a server over the loopback interface.

On a correctly configured multi-homed server (at least correct in my
eyes) the address should be an address that is routeable for anyone,
whatever network they are connected.

> Destination     Gateway         Genmask         Flags   MSS Window  irtt
> Iface
> 64.192.180.0    0.0.0.0         255.255.255.0   U        40 0          0 eth1
> 192.168.1.0     0.0.0.0         255.255.255.0   U        40 0          0 eth0
> 127.0.0.0       0.0.0.0         255.0.0.0       U        40 0          0 lo
> 0.0.0.0         64.192.180.50   0.0.0.0         UG       40 0          0 eth1

eth1 is your 'universally routable address', so that should be the
address that is associated with your hostname.

> **** but the remote venus just hangs although traffic is
> **** being sent back to it
> 02:09:40 client_GetVenusId: got new host 66.19.136.44:1030
> 02:09:40 Building callback conn.
> 02:09:40 No idle WriteBack conns, building new one
> 02:09:40 Writeback message to 66.19.136.44 port 1030 on conn 2d9b21e0
> succeeded
> 02:17:26 Callback failed RPC2_DEAD (F) for ws 66.19.136.44:1030
> 02:17:26 Unbinding RPC2 connection 520389087

At this point the remote venus is probably trying to connect to a Coda
server at ip-address 192.168.1.0, to which there is no route.

The unroutable ip-address is actually stored in the server. As far as I
remember the VLDB and VRDB files only refer to it by 'serverid'. So
fixing up the ip returned by gethostbyname('servername') (/etc/hosts?)
and restarting the server should be sufficient.

However, your public address seems to be a dynamic address and can
change at random times when the dhcp lease expires. I don't really have
a solution for that. The server really should return a hostname with the
volume information so that clients can re-resolve it to an ip-address
when a connection dies.

Jan