Date: Thu, 03 Jun 2021 18:01:19 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 256393] Issue with recreation of ppp/tun interfaces Message-ID: <bug-256393-7501-9A0w4lDf3j@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-256393-7501@https.bugs.freebsd.org/bugzilla/> References: <bug-256393-7501@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D256393 --- Comment #3 from Nathan Whitehorn <nwhitehorn@FreeBSD.org> --- I at least found the proximate problem: root@conference:/home/nwhitehorn # netstat -rn -f inet Routing tables Internet: Destination Gateway Flags Netif Expire default 128.135.X.X UGS vtnet0 127.0.0.1 link#2 UH lo0 128.135.X.X/25 link#1 U vtnet0 128.135.X.X link#1 UHS lo0 169.254.169.254 128.135.X.X UGHS vtnet0 192.168.42.1 127.0.0.1 UH lo0 <- this is the IP th= at the tunnel will use once established, and it didn't go away when the tunnel interface did If I delete the route to the tunnel endpoint on the loopback interface that appeared: root@conference:/home/nwhitehorn # route delete 192.168.42.1 delete host 192.168.42.1 Then the connection re-establishes itself without issue. The route in question seems to have been added by routed(8), replacing the link-level default route, though I am not sure why it is not going away when routed(8) exits and the interface disappears or why routed(8) is re-writing= it: root@conference:/home/nwhitehorn # netstat -rn -f inet Routing tables Internet: Destination Gateway Flags Netif Expire default 128.135.X.X UGS vtnet0 127.0.0.1 link#2 UH lo0 128.135.X.X/25 link#1 U vtnet0 128.135.X.X link#1 UHS lo0 169.254.X.X 128.135.X.X UGHS vtnet0 192.168.42.0/24 192.168.42.2 UGS tun0 192.168.42.1 link#3 UHS lo0 <- Original loopback route 192.168.42.2 link#3 UH tun0 root@conference:/home/nwhitehorn # service routed start Starting routed. root@conference:/home/nwhitehorn # netstat -rn -f inet Routing tables Internet: Destination Gateway Flags Netif Expire default 128.135.X.X UGS vtnet0 10.7.114.0/24 192.168.42.2 UG tun0 127.0.0.1 link#2 UH lo0 128.135.X.X/25 link#1 U vtnet0 128.135.X.X link#1 UHS lo0 157.132.6.8/29 192.168.42.2 UG tun0 169.254.X.X 128.135.158.134 UGHS vtnet0 192.168.1.0/24 192.168.42.2 UG tun0 192.168.2.0/24 192.168.42.2 UG tun0 192.168.3.0/24 192.168.42.2 UG tun0 192.168.5.0/24 192.168.42.2 UG tun0 192.168.42.0/24 192.168.42.2 UGS tun0 192.168.42.1 127.0.0.1 UH lo0 <- Rewritten by route= d(8) 192.168.42.2 link#3 UH tun0 192.168.176.0/24 192.168.42.2 UG tun0 On the 12.2 system on the other end of this link, the same loopback host ro= ute is present, but it doesn't seem to prevent re-IP'ing the link: $ netstat -rn -f inet Routing tables Internet: Destination Gateway Flags Netif Expire 192.168.42.1 link#5 UHS tun0 192.168.42.2 127.0.0.1 UH lo0 My suspicion is that the actual problem is that some of the routing-table verification code that went in recently is preventing adding an IP address = with an address to which there is already a route on another interface. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-256393-7501-9A0w4lDf3j>