[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: strange IP question
- To: misc_(_at_)_openbsd_(_dot_)_org
- Subject: Re: strange IP question
- From: Claudio Jeker <cjeker_(_at_)_diehard_(_dot_)_n-r-g_(_dot_)_com>
- Date: Thu, 16 Dec 2004 01:11:49 +0059
- Mail-followup-to: Claudio Jeker <cjeker_(_at_)_diehard_(_dot_)_n-r-g_(_dot_)_com>, misc_(_at_)_openbsd_(_dot_)_org
On Wed, Dec 15, 2004 at 02:46:22PM +0100, Toni Mueller wrote:
> Hi Claudio,
> On Wed, 15.12.2004 at 13:49:13 +0100, Claudio Jeker <cjeker_(_at_)_diehard_(_dot_)_n-r-g_(_dot_)_com> wrote:
> > On Wed, Dec 15, 2004 at 12:08:53PM +0100, Toni Mueller wrote:
> > > # /sbin/ifconfig fxp3
> > > fxp3: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1400
> > > address: 00:30:48:51:58:55
> > > media: Ethernet autoselect (100baseTX full-duplex)
> > > status: active
> > > inet 172.16.60.1 netmask 0xffff0000 broadcast 172.16.255.255
> > > inet6 fe80::230:48ff:fe51:5855%fxp3 prefixlen 64 scopeid 0x4
> > > inet 18.104.22.168 netmask 0xffff0000 broadcast 22.214.171.124
> > > inet 10.200.0.81 netmask 0xfffffff8 broadcast 10.200.0.87
> > Sorry this is how it works. For sockets that are not bound to a specific
> > address with bind(2) the first/primary IP of the outgoing interface is
> > used. This hurts when you overload a interface with multiple networks as
> > in your example.
> well, the primary address is 172.16.60.1 and not 10.x
> The addresses 10.x and 180.x are only aliased to this interface,
> that's why I'm uncomfortable with this situation.
> Therefore, I guess I'm seeing an error, according to your description
> about how it should work.
> I'm very interested in a reason why this is so, and how much work
> it would be to change this behaviour if it is "ok" to change it
> to select the source IP according to the route entry which the
> packet should use.
Bah. Stupid me and nobody noticed it. I was writing faster then thinking.
First of all outgoing connections do a route lookup and use the info
(ro->ro_rt->rt_ifa) attached to this route for setting the local address
of unbount connections. So traffic comming from your system is sent with
the correct address -- at least most of it.
Now what you are seeing are ICMP error messages (need frag) as your
outgoing link has only a mtu of 1378 and the DF bit is set in the IP
header. So the machine acting as a server needs to send back an icmp error
message and there the wrong ip is selected.
Ok, I tracked it down ifaof_ifpforaddr() which should find an interface
address specific to an interface best matching a given address.
When it does not find a best match the last ifa with the same AF is used.
In your case 10.200.0.81.
Now let me get some sleep and I will fix this tomorrow.