Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utcs!mnetor!seismo!brl-adm!caip!nike!ucbcad!ucbvax!RSCH.WISC.EDU!dave
From: dave@RSCH.WISC.EDU.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Re: The multi-home problem again
Message-ID: <8607200253.AA02499@rsch.wisc.edu>
Date: Sat, 19-Jul-86 23:12:26 EDT
Article-I.D.: rsch.8607200253.AA02499
Posted: Sat Jul 19 23:12:26 1986
Date-Received: Sun, 20-Jul-86 08:02:49 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 22
Approved: tcp-ip@sri-nic.arpa

Dave Mills writes:
>Yes, I really mean that the requests to [10.2.0.27] came back, apparently with
>valid data, but the address in the IP source-address field was [128.9.0.33],

This appears to be a bug in the 4.2 and 4.3 UDP implementations.
Actually, the way that the network interface between user programs and
the kernel is defined, there isn't any way to fix this in all cases.
This is because a user program can't specify which of the addresses for
a host should be used as the source address.

I ran across this bug yesterday while making queries to the UDP time
service on one of our hosts.  The same sort of thing happened, the
source address was not the address to which I had sent the query but
the other address for that host.

My solution to this problem is to recognize all of the addresses for a
host.  This seems easier than adding yet another version of the "send"
system call to 4.3.  I don't think this will help in the case of a name
server, though.  You can't possibly recognize an address you don't
know about!

dave