From owner-freebsd-net@FreeBSD.ORG Fri Apr 29 18:28:56 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 814CF1065672 for ; Fri, 29 Apr 2011 18:28:56 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 502658FC1A for ; Fri, 29 Apr 2011 18:28:56 +0000 (UTC) Received: by pvg11 with SMTP id 11so3170970pvg.13 for ; Fri, 29 Apr 2011 11:28:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:date:to:subject:message-id:reply-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=+nJaCvgFP+GAk3dfMu5ZK2gu8Tayzc3vSxuSpscfH0g=; b=wRMi0bVpu0HiIsxwxy6Vzq0SFbANeU6hVlwYjRIeYr3WOycVHv+jXlAn/wfwPeuihf jo2YOWs7plv/UB1Njp49XHnpi6KAiGS+xtBBeeP4GvNpGjyNsE8dWPdDbSCMV92tR/ML AXYBE6SbgYHvpYIVJ5AsLa8aVeWUcQFtnbqno= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=SSukikhR8CwO2ZDxfAbKf6SMtJRepNaDGNzevFb6aN4SQvhV+uDMr/pq7m1ORGdh1v 7NdWWPR+Nsizx1Iz/bp6/zy0zxPy29sHOKqhHbSxqOwTuNtAc4j6WPsw3zgcfR1GZWDI WT6f26heHjUIqKEqr/PYBB5SyUt0khggW7afU= Received: by 10.142.117.5 with SMTP id p5mr1934612wfc.246.1304101735789; Fri, 29 Apr 2011 11:28:55 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id p40sm3490216wfc.7.2011.04.29.11.28.52 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Apr 2011 11:28:53 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 29 Apr 2011 11:28:07 -0700 From: YongHyeon PYUN Date: Fri, 29 Apr 2011 11:28:07 -0700 To: freebsd-net@freebsd.org Message-ID: <20110429182807.GA21084@michelle.cdnetworks.com> References: <201104290001.p3T01EvQ082443@artema.vpn.ibs> <20110429095231.GA17786@relay.ibs.dn.ua> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="fUYQa+Pmc3FrFX/N" Content-Disposition: inline In-Reply-To: <20110429095231.GA17786@relay.ibs.dn.ua> User-Agent: Mutt/1.4.2.3i Subject: Re: collisions on tun interfaces ... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 18:28:56 -0000 --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Apr 29, 2011 at 12:52:31PM +0300, Zeus V Panchenko wrote: > Hi, > > may somebody epxplain it for me, what can cause collisions on tun > interfaces created by ppp(8) and openvpn? > > > uname -a > FreeBSD 8.2-STABLE #0 i386 > > > netstat -i > Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll > tun0 1492 18940349 0 0 15737760 0 45668 > tun0 1492 A.B.C.D A-B-C-D.domain 15623965 - - 12429351 - - > tun1 1500 12721670 0 0 9957662 0 11161 > tun1 1500 E.F.G.H E-F-G-H.vpn 6454 - - 445751 - - > > > rl0: flags=8843 metric 0 mtu 1500 > options=3808 > ether 00:30:4f:67:cf:81 > media: Ethernet autoselect (100baseTX ) > status: active > tun0: flags=8051 metric 0 mtu 1492 > options=80000 > inet A.B.C.D --> A1.B1.C1.D1 netmask 0xffffffff > Opened by PID 3943 > tun1: flags=8051 metric 0 mtu 1500 > options=80000 > inet E.F.G.H --> E1.F1.G1.H1 netmask 0xffffffff > Opened by PID 1387 > > tun0 is created by ppp(8) > > in /etc/ppp.conf is: > default: > set log Phase Chat LCP IPCP CCP tun command > set server /var/run/ppp/internet "" 0177 > set device PPPoE:rl0 > set speed sync > enable lqr echo > set lqrperiod 30 > set login > set ctsrts off > add default HISADDR > set timeout 0 > set redial 0 0 > set cd 5 > > tun1 is created by OpenVPN with configuration: > client > dev tun1 > proto udp > ... > > so, what can cause the collisions and can i fix them? > It seems tun(4) just increments collision counter whenever it can't enqueue packet. Because it's not collision at all I think it's a bug that had been there from day 1. Just nuking updating the counter will address the issue. You still can get the previous collision counter of tun(4) with d option of netstat which shows number of packets dropped due to send queue full. --fUYQa+Pmc3FrFX/N Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="tun.diff" Index: sys/net/if_tun.c =================================================================== --- sys/net/if_tun.c (revision 221175) +++ sys/net/if_tun.c (working copy) @@ -661,10 +661,8 @@ } error = (ifp->if_transmit)(ifp, m0); - if (error) { - ifp->if_collisions++; + if (error) return (ENOBUFS); - } ifp->if_opackets++; return (0); } --fUYQa+Pmc3FrFX/N--