From owner-freebsd-net@FreeBSD.ORG Fri Apr 29 18:46:36 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 7DE94106564A for ; Fri, 29 Apr 2011 18:46:36 +0000 (UTC) (envelope-from zeus@relay.ibs.dn.ua) Received: from relay.ibs.dn.ua (relay.ibs.dn.ua [91.216.196.25]) by mx1.freebsd.org (Postfix) with ESMTP id 157238FC0A for ; Fri, 29 Apr 2011 18:46:35 +0000 (UTC) Received: from relay.ibs.dn.ua (localhost [127.0.0.1]) by relay.ibs.dn.ua with ESMTP id p3TIkYtH042146 for ; Fri, 29 Apr 2011 21:46:34 +0300 (EEST) Received: (from zeus@localhost) by relay.ibs.dn.ua (8.14.4/8.14.4/Submit) id p3TIkYLi042145 for freebsd-net@freebsd.org; Fri, 29 Apr 2011 21:46:34 +0300 (EEST) Date: Fri, 29 Apr 2011 21:46:34 +0300 From: Zeus V Panchenko To: freebsd-net@freebsd.org Message-ID: <20110429184634.GA34176@relay.ibs.dn.ua> Mail-Followup-To: freebsd-net@freebsd.org References: <201104290001.p3T01EvQ082443@artema.vpn.ibs> <20110429095231.GA17786@relay.ibs.dn.ua> <20110429182807.GA21084@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20110429182807.GA21084@michelle.cdnetworks.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 8.1-RELEASE X-Editor: GNU Emacs 23.2.1 X-Face: iVBORw0KGgoAAAANSUhEUgAAACoAAAAqBAMAAAA37dRoAAAAFVBMVEWjjoiZhHDWzcZuW1U wOT+RcGxziJxEN0lIAAABrklEQVQokV2STXLbMAyFQaraE3a5dzSTfR1IF7CQrM3QuECn9z9DH0 gxzgSyFvr88PBD0uJxoR6BE+e8LtRgohE5ZB50sODP/REbfUnte/z12+llCekLUSKenFIMke6Be WinE8H0RJHSN71rUQp64gFDmtDDhRk0zam3FzpNVFprhwPGaFo6oY9wDBJQ9Qz6EuKyROJjDGa+ uza4VOTa8iHlN58Yv5BF9+4BGl0LA5pUD5xKXg4aQlVZm0co3NKxCGxQpu3aC352Gv3DZONmwQd tkrlaylV3YSew7bWtwAZF/zi9jblmprPoL7ktzeFSxmarVNmWRi+Bmxg7Y7tbGtR8XZUxLTo86G thANsssetjp3POuBvMBRlw6jRa5pKN7yVlP+F2lyiZGSMf5hnSU6eAVupmtfjRcxy0momwpxDnz 06hwnOWvBnUdR8U2/KX7cq26u1Jy5xFZMPOVONRbRUrwey8Qar6cWgf12xSymQuVX0DfYd4R8kN Hg0qCtLeaYZcj8B90M2N0cEX1P0vKSxw7NLy/3X8Qeriusu66jNA37P4Mn5QRTG2hz4d9D/6E3a EX852nwAAAABJRU5ErkJggg== Subject: Re: collisions on tun interfaces ... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: zeus@ibs.dn.ua 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:46:36 -0000 YongHyeon PYUN (pyunyh@gmail.com) [11.04.29 21:29] wrote: > 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. thanks, and is there way to influence that? -- Zeus V. Panchenko IT Dpt., IBS ltd GMT+2 (EET)