From owner-freebsd-bugs@FreeBSD.ORG Thu Dec 3 12:00:17 2009 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED7D41065722 for ; Thu, 3 Dec 2009 12:00:16 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id F11CB8FC1E for ; Thu, 3 Dec 2009 12:00:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nB3C0BvT095067 for ; Thu, 3 Dec 2009 12:00:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nB3C0Bff095066; Thu, 3 Dec 2009 12:00:11 GMT (envelope-from gnats) Resent-Date: Thu, 3 Dec 2009 12:00:11 GMT Resent-Message-Id: <200912031200.nB3C0Bff095066@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Alexander Zagrebin Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18F99106566B for ; Thu, 3 Dec 2009 11:58:23 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21]) by mx1.freebsd.org (Postfix) with ESMTP id 055518FC13 for ; Thu, 3 Dec 2009 11:58:23 +0000 (UTC) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.3/8.14.3) with ESMTP id nB3BwMqM096071 for ; Thu, 3 Dec 2009 11:58:22 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.3/8.14.3/Submit) id nB3BwMKu096069; Thu, 3 Dec 2009 11:58:22 GMT (envelope-from nobody) Message-Id: <200912031158.nB3BwMKu096069@www.freebsd.org> Date: Thu, 3 Dec 2009 11:58:22 GMT From: Alexander Zagrebin To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: kern/141134: "ioctl (SIOCAIFADDR): File exists" error when configuring ppp interfaces X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 12:00:17 -0000 >Number: 141134 >Category: kern >Synopsis: "ioctl (SIOCAIFADDR): File exists" error when configuring ppp interfaces >Confidential: no >Severity: serious >Priority: high >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Dec 03 12:00:11 UTC 2009 >Closed-Date: >Last-Modified: >Originator: Alexander Zagrebin >Release: FreeBSD 8.0-RELEASE >Organization: - >Environment: FreeBSD gw.vosz.local 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sun Nov 29 00:37:18 MSK 2009 root@gw.vosz.local:/usr/src/sys/amd64/compile/KERNEL amd64 >Description: I use mpd 5.3 (ports/net/mpd5) as vpn server. After upgrading to 8.0-RELEASE from 7.2-RELEASE I began to receive complaints from users. They says, that the first attempt to connect to our vpn server always fails, and only the second attempt is successful. The log files confirms this. I have found how to reproduce this problem with command line. I'll create the interface tun10: # ifconfig tun10 create inet 192.168.100.1 192.168.100.10 netmask 0xffffffff # ifconfig tun10 tun10: flags=8051 metric 0 mtu 1500 inet 192.168.100.1 --> 192.168.100.10 netmask 0xffffffff # netstat -rn .. 192.168.100.1 link#13 UHS 0 0 lo0 192.168.100.10 link#13 UH 0 0 tun10 .. # ping -c1 192.168.100.1 PING 192.168.100.1 (192.168.100.1): 56 data bytes 64 bytes from 192.168.100.1: icmp_seq=0 ttl=64 time=0.050 ms --- 192.168.100.1 ping statistics --- 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.050/0.050/0.050/0.000 ms All right. The interface was successfully created, loopback route was added, and i can ping self. Now I'll create the interface tun11 for another peer: # ifconfig tun11 create inet 192.168.100.1 192.168.100.11 netmask 0xffffffff ifconfig: ioctl (SIOCAIFADDR): File exists # ifconfig tun11 tun11: flags=8051 metric 0 mtu 1500 inet 192.168.100.1 --> 192.168.100.11 netmask 0xffffffff # netstat -rn .. 192.168.100.1 link#13 UHS 0 1 lo0 192.168.100.10 link#13 UH 0 0 tun10 192.168.100.11 link#14 UH 0 0 tun11 .. The first problem: ifconfig returned error, but interface was successfully configured. The same error, returned from ioctl, forces ppp daemon to terminate ipcp and disconnect a peer. Now I'll destroy tun11 and will create it again or will reconfigure it with the same parameters (the result is the same): # ifconfig tun11 destroy # ifconfig tun11 create inet 192.168.100.1 192.168.100.11 netmask 0xffffffff or # ifconfig tun11 inet 192.168.100.1 192.168.100.11 netmask 0xffffffff # netstat -rn .. 192.168.100.1 link#14 UHS 0 0 lo0 192.168.100.10 link#13 UH 0 0 tun10 192.168.100.11 link#14 UH 0 0 tun11 .. There is no error from ifconfig now. It's strange. loopback route was changed. This explains why the second attempt of a peer to connect is successful. If we'll create additional interfaces (tun12,tun13, etc), the behavior will the same. The second problem: Suppose the peer on tun11 terminates her session. # ifconfig tun11 destroy # netstat -rn .. 192.168.100.10 link#13 UH 0 0 tun10 .. # ping -c1 192.168.100.1 PING 192.168.100.1 (192.168.100.1): 56 data bytes --- 192.168.100.1 ping statistics --- 1 packets transmitted, 0 packets received, 100.0% packet loss So loopback route to 192.168.100.1 was deleted and I'll can't ping self. It's correct for destroyed tun11 (link#14), but as still there is the tun10 (link#13), we need loopback route to 192.168.100.1 After looking to the sources and doing some debugging I have found, that the first problem (EEXIST from ioctl) occurs because of call ifa_add_loopback_route from in_ifinit (in.c:928). So I temporary disabled adding loopback routes via net.link.ether.inet.useloopback, but this is bad idea. >How-To-Repeat: See the "full description" >Fix: To prevent adding of loopback routes I use sysctl net.link.ether.inet.useloopback=0 >Release-Note: >Audit-Trail: >Unformatted: