Date: Tue, 22 Aug 2000 14:06:06 -0400 (EDT) From: rwatson@freebsd.org To: FreeBSD-gnats-submit@freebsd.org Subject: kern/20785: changing interface IP in same subnet doesn't propagate properly Message-ID: <200008221806.OAA07374@fledge.watson.org>
next in thread | raw e-mail | index | archive | help
>Number: 20785 >Category: kern >Synopsis: changing IP address on an interface may not propagate properly >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Aug 22 11:10:01 PDT 2000 >Closed-Date: >Last-Modified: >Originator: Robert Watson >Release: FreeBSD 4.1-STABLE i386 >Organization: >Environment: numocking# uname -a FreeBSD numocking.gw.tislabs.com 4.1-STABLE FreeBSD 4.1-STABLE #1: Mon Aug 7 14 :13:19 EDT 2000 root@numocking.gw.tislabs.com:/usr/src/sys/compile/MOCKING i386 >Description: Changing the IP address of an interface may not necessarily cause new sockets to make use of the new IP address, if the address is in the same subnet as the previous address under IPv4. This only seems to affect outgoing packets to non-local addresses; the correct IP is used for outgoing local packets on the subnet. >How-To-Repeat: (terminal one) ifconfig xl0 inet 192.168.11.200 route add default 192.168.11.1 (terminal two) tcpdump -eni xl0 (terminal one) ifconfig xl0 inet 192.168.11.100 ping -c 100 128.2.1.2 (terminal two output) tcpdump: listening on xl0 14:00:24.529628 0:c0:4f:3b:cb:62 0:a0:cc:67:f6:fe 0800 98: 192.168.11.200 > 128. 2.1.2: icmp: echo request 14:00:24.568225 0:a0:cc:67:f6:fe 0:c0:4f:3b:cb:62 0800 98: 128.2.1.2 > 192.168.1 1.200: icmp: echo reply And needless to say, the echo responses don't propagate back up the stack to the ping application, as they are for the wrong IP. A ping of 192.168.11.1 works fine. >Fix: Work-around is to revert back to the old IP, or to delete and re-add the default gateway route entry. Presumably the outgoing IP address is tied to the route entry somehow, so any use of that route forces use of the old IP, which is no longer valid for that interface. Given that the new IP address is in the same subnet, ideally we could make use of the same route entry. In any case, continuing to make use of the now defunct IP address is counter-intuitive (and misbehavior, in my view). I have not tried this with interfaces other than xl0. >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200008221806.OAA07374>