(Illustration by Gaich Muramatsu)
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. JanReceived on 2002-09-02 22:50:09