From owner-freebsd-net@FreeBSD.ORG Sun Apr 27 15:00:16 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6F5FB2DB for ; Sun, 27 Apr 2014 15:00:16 +0000 (UTC) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 36AB91BED for ; Sun, 27 Apr 2014 15:00:16 +0000 (UTC) Received: by mail-yk0-f178.google.com with SMTP id 200so3523045ykr.9 for ; Sun, 27 Apr 2014 08:00:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=REsQwZuiSfOV6/iKqwlOOuh//J7zimK7z1BI+1J/C6Y=; b=WGkTCAu/vbS154bBZmHLAqLqgj9B6HDB+2bnCQTaMc20tUFY3iI/JLhON4YAv3o4gP DEWyzpRqTPvD7ZwqWfhj7Q4auS7eRCiDlDaZIhrAcs6wvnrqplsIMu/hZDpZPS1f7is9 HugDbn/5AGiT0B4D806z6ECR/DpxfJKEK+f8pjlnKQfieq1xAXVvyTSSwxYydcwo4TWO VdqBW7mINKP+4ECkarmEXN8u4vwg2n2YT8b2deh0x4owiqUr9jn+bhcJKGPFtu8rU53r uAJ282xIdLY1iJxJVCOuYYj2vpWgpdRVcFnX9D7HiXcz8TZ+l3P+xYOU701fb9e19Jay pfZw== MIME-Version: 1.0 X-Received: by 10.236.31.40 with SMTP id l28mr30144824yha.17.1398610815415; Sun, 27 Apr 2014 08:00:15 -0700 (PDT) Received: by 10.170.185.208 with HTTP; Sun, 27 Apr 2014 08:00:15 -0700 (PDT) Date: Sun, 27 Apr 2014 17:00:15 +0200 Message-ID: Subject: Random disconnects on 10.0 with mpd5/pptp + PF From: martin i To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2014 15:00:16 -0000 I turned on verbose logging in mpd.conf and did another set of tests. Client just logged in and stayed idle. Traffic of the active PPTP session looked like: Test #1: Apr 27 02:09:35 fbsd10 mpd: pptp0: recv EchoRequest Apr 27 02:09:35 fbsd10 mpd: id=0x6000000 Apr 27 02:09:35 fbsd10 mpd: pptp0: send EchoReply msg Apr 27 02:09:35 fbsd10 mpd: len=20 msgType=1 magic=0x1a2b3c4d type=6 Apr 27 02:09:35 fbsd10 mpd: id=0x6000000 result=1 err=0 ignore=0 Apr 27 02:10:35 fbsd10 mpd: pptp0: send EchoRequest msg Apr 27 02:10:35 fbsd10 mpd: len=16 msgType=1 magic=0x1a2b3c4d type=5 Apr 27 02:10:35 fbsd10 mpd: id=1 Apr 27 02:10:35 fbsd10 mpd: pptp0: recv EchoRequest Apr 27 02:10:35 fbsd10 mpd: id=0x7000000 Apr 27 02:10:35 fbsd10 mpd: pptp0: send EchoReply msg Apr 27 02:10:35 fbsd10 mpd: len=20 msgType=1 magic=0x1a2b3c4d type=6 Apr 27 02:10:35 fbsd10 mpd: id=0x7000000 result=1 err=0 ignore=0 Apr 27 02:10:35 fbsd10 mpd: pptp0: recv EchoReply Apr 27 02:10:35 fbsd10 mpd: id=1 result=1 err=0 ignore=0 Apr 27 02:11:35 fbsd10 mpd: pptp0: send EchoRequest msg Apr 27 02:11:35 fbsd10 mpd: len=16 msgType=1 magic=0x1a2b3c4d type=5 Apr 27 02:11:35 fbsd10 mpd: id=2 Apr 27 02:11:35 fbsd10 mpd: pptp0: read: Connection reset by peer Apr 27 02:11:35 fbsd10 mpd: pptp0: ctrl state ESTABLISHED --> DYING Apr 27 02:11:35 fbsd10 mpd: pptp0: killing connection with 49595 Apr 27 02:11:35 fbsd10 mpd: pptp0-0: killing channel Apr 27 02:11:35 fbsd10 mpd: [cloud_link-1] PPTP call terminated Apr 27 02:11:35 fbsd10 mpd: [cloud_link-1] device: DOWN event Test #2: Apr 27 02:28:16 fbsd10 mpd: len=20 msgType=1 magic=0x1a2b3c4d type=6 Apr 27 02:28:16 fbsd10 mpd: id=0x5000000 result=1 err=0 ignore=0 Apr 27 02:29:16 fbsd10 mpd: pptp0: recv EchoRequest Apr 27 02:29:16 fbsd10 mpd: id=0x6000000 Apr 27 02:29:16 fbsd10 mpd: pptp0: send EchoReply msg Apr 27 02:29:16 fbsd10 mpd: len=20 msgType=1 magic=0x1a2b3c4d type=6 Apr 27 02:29:16 fbsd10 mpd: id=0x6000000 result=1 err=0 ignore=0 Apr 27 02:30:16 fbsd10 mpd: pptp0: send EchoRequest msg Apr 27 02:30:16 fbsd10 mpd: len=16 msgType=1 magic=0x1a2b3c4d type=5 Apr 27 02:30:16 fbsd10 mpd: id=1 Apr 27 02:30:16 fbsd10 mpd: pptp0: read: Connection reset by peer Apr 27 02:30:16 fbsd10 mpd: pptp0: ctrl state ESTABLISHED --> DYING Apr 27 02:30:16 fbsd10 mpd: pptp0: killing connection with 49732 In test #2 connection went down even sooner. It seems that the "type 5" message has something to do with it. I checked the RFC 1661 for PPP specification but I found no information on what that type might be. I looked at mpd5 sources (v5.7); it seems it's defined in pptp_ctrl.h as PPTP_EchoRequest (type 6 is PPTP_EchoReply). I rebooted back to 9.2 to check the behavior there. I saw only type 6 messages: Apr 27 16:40:33 fbsd9 mpd: pptp0: recv EchoRequest Apr 27 16:40:33 fbsd9 mpd: id=0x23000000 Apr 27 16:40:33 fbsd9 mpd: pptp0: send EchoReply msg Apr 27 16:40:33 fbsd9 mpd: len=20 msgType=1 magic=0x1a2b3c4d type=6 Apr 27 16:40:33 fbsd9 mpd: id=0x23000000 result=1 err=0 ignore=0 Apr 27 16:41:33 fbsd9 mpd: pptp0: recv EchoRequest Apr 27 16:41:33 fbsd9 mpd: id=0x24000000 Apr 27 16:41:33 fbsd9 mpd: pptp0: send EchoReply msg Apr 27 16:41:33 fbsd9 mpd: len=20 msgType=1 magic=0x1a2b3c4d type=6 Apr 27 16:41:33 fbsd9 mpd: id=0x24000000 result=1 err=0 ignore=0 with no type 5 messages at all. Session stays up without problem. But logic to keep the link up is in the mpd5 which is the same version on 9.2 and 10.0. What can be the reason for sending those type 5 messages ? (or is my assumption even correct that it has something to do with my issue?) Martin