From owner-freebsd-net@FreeBSD.ORG Sun Oct 17 05:56:23 2010 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 479391065670 for ; Sun, 17 Oct 2010 05:56:23 +0000 (UTC) (envelope-from aragon@phat.za.net) Received: from mail.geek.sh (decoder.geek.sh [196.36.198.81]) by mx1.freebsd.org (Postfix) with ESMTP id D5ADB8FC12 for ; Sun, 17 Oct 2010 05:56:22 +0000 (UTC) Received: from igor.geek.sh (196-209-90-124.dynamic.isadsl.co.za [196.209.90.124]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.geek.sh (Postfix) with ESMTPSA id 48AFC3BAED for ; Sun, 17 Oct 2010 07:39:52 +0200 (SAST) Message-ID: <4CBA8C27.3030400@phat.za.net> Date: Sun, 17 Oct 2010 07:39:51 +0200 From: Aragon Gouveia User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.11) Gecko/20100725 Thunderbird/3.0.6 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: 8.1 bridge locking up X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Oct 2010 05:56:23 -0000 Hi, I have a FreeBSD 8.1-RELEASE-p1 system configured with two bridge interfaces. Every few hours or days the system stops responding or locks up. This is a system that had been running without problems before I upgraded it from a year old 8.0-STABLE a week ago. Most times when it locks up it still responds to pings. Some times I can still SSH to it, but otherwise I have to get on via console and reboot it. Almost all traffic destined to it or originated from it travels through an if_bridge(4) interface. Today I was able to use top to see the state of processes that are hanging: > 70232 root 1 116 20 5668K 3232K *lle 0:00 0.00% snmpget > 70235 root 1 116 20 5668K 3232K *if_af 0:00 0.00% snmpget > 70244 root 1 116 20 5668K 3220K *if_af 0:00 0.00% snmpget > 70245 root 1 116 20 5668K 3220K *if_af 0:00 0.00% snmpget > 70254 root 1 116 20 5668K 3220K *if_af 0:00 0.00% snmpget > 70306 root 1 96 0 3416K 1112K *if_af 0:00 0.00% ifconfig > 70296 root 1 96 0 3392K 1132K *if_af 0:00 0.00% ping The ping and ifconfig processes were started by me and couldn't be backgrounded or interrupted while in the above state. Today it's as if only one of the bridge interfaces had "crashed" since traffic through the other bridge interface was behaving fine. Really need to get to the bottom of this. Help? Thanks, Aragon From owner-freebsd-net@FreeBSD.ORG Sun Oct 17 14:37:14 2010 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 708BA106564A; Sun, 17 Oct 2010 14:37:14 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 15E608FC19; Sun, 17 Oct 2010 14:37:06 +0000 (UTC) Received: by bwz16 with SMTP id 16so19152bwz.13 for ; Sun, 17 Oct 2010 07:37:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:subject:date:message-id:to:mime-version :x-mailer; bh=zexa/tU7IaffUYVYD3ZmY4LVrIMGYPL3pCMzU0ZXJOk=; b=R7G+jaHZDDTfPFIinU+pirgQz94bIetmhY9x9tZItRBpaklTnCfQBtSopaYjNXFlQh RVlALPO3qzAzdta9rpt1NIMJ5EEWb6vPc3IYvXa12B6NyFtQXEp7x6Kg1XsSRxVrUgLs QPCJbWejQ4W7eMtERxDHTmjlvbiefRTCLV0tc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=Al+lXHTEsHjvyY9Iaei6hR/ZKdXG7QlutC2VOnpVQkUe4WgWuxPWWGWFXbG5BL2Nop wm6mkxS66317d3KL/IB8dxtsuEC4ijN/dZpUdh8x20QexSwf9XvOGcOHTh2RlDEw4bzf fDrIyH7Whs2HlEuIaBlJanOyJUXkmu58UQZEw= Received: by 10.204.101.132 with SMTP id c4mr3308643bko.87.1287324578899; Sun, 17 Oct 2010 07:09:38 -0700 (PDT) Received: from ndenev.totalterror.net (93-152-151-19.ddns.onlinedirect.bg [93.152.151.19]) by mx.google.com with ESMTPS id o12sm14872580bkb.21.2010.10.17.07.09.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 17 Oct 2010 07:09:37 -0700 (PDT) From: Nikolay Denev Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 17 Oct 2010 17:09:35 +0300 Message-Id: <7051D018-684F-417A-AAA0-00603B2FDCD4@gmail.com> To: freebsd-stable@freebsd.org, freebsd-net@freebsd.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Cc: Subject: ifconfig, vnets and interface names X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Oct 2010 14:37:14 -0000 Hello, While playing with vnet jails I've discovered the following oddity, = which probably is not what's expected to happen : First I'm creating two epair(4) interfaces : [16:51]root@nas:/home/ndenev# ifconfig epair0 create epair0a [16:51]root@nas:/home/ndenev# ifconfig epair1 create epair1a Then I'm creating two vnet jails : [16:51]root@nas:/home/ndenev# jail -c vnet name=3Dtest1 = host.hostname=3Dtest1 path=3D/ persist [16:51]root@nas:/home/ndenev# jail -c vnet name=3Dtest2 = host.hostname=3Dtest2 path=3D/ persist Now push one side of the epairs to each vnet : [16:51]root@nas:/home/ndenev# ifconfig epair0b vnet test1 [16:52]root@nas:/home/ndenev# ifconfig epair1b vnet test2 Rename the interfaces in the vnet jails : [16:52]root@nas:/home/ndenev# jexec test1 ifconfig epair0b name eth0 [16:52]root@nas:/home/ndenev# jexec test2 ifconfig epair1b name eth0 And now I'm destroying the vnets, so all of the interfaces are = "reclaimed" by the host : [16:52]root@nas:/home/ndenev# jail -r test1 [16:52]root@nas:/home/ndenev# jail -r test2 And that's what ifconfig shows after this : [16:52]root@nas:/home/ndenev# ifconfig =20 <... snip lo0 and physical interface ...> epair0a: flags=3D8842 metric 0 = mtu 1500 ether 02:8c:53:00:03:0a epair1a: flags=3D8842 metric 0 = mtu 1500 ether 02:b6:49:00:05:0a eth0: flags=3D8842 metric 0 mtu = 1500 ether 02:8c:53:00:04:0b ether 02:b6:49:00:06:0b Instead of two interfaces, I'm seeing one with to lladdrs, because of = the interface names being the same. Then I'm trying to destroy them : [16:52]root@nas:/home/ndenev# ifconfig eth0 destroy [16:53]root@nas:/home/ndenev# ifconfig=20 <... snip lo0 and physical interface ...> epair1a: flags=3D8842 metric 0 = mtu 1500 ether 02:b6:49:00:05:0a eth0: flags=3D8842 metric 0 mtu = 1500 ether 02:b6:49:00:06:0b [16:53]root@nas:/home/ndenev# ifconfig eth0 destroy So in this case there may be not a clean way to address one of the = interfaces specifically (i.e. destroy only the second one)? I've not investigated further, but I'm thinking probably this is just a = "bug" in ifconfig interpreting/parsing the information from the kernel. Maybe a solution is to extend ifconfig to be able print the interface = list along with the ifIndex values and also manage the interfaces by = index? Auto renaming also is also probably a possible solution (i.e. eth0_1 , = eth0_2 ) as these are interfaces coming from destroyed vnet's and are = not likely to be in use. (but still sounds scary :) ) Regards, Nikolay= From owner-freebsd-net@FreeBSD.ORG Sun Oct 17 16:20:08 2010 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 D43F5106566B; Sun, 17 Oct 2010 16:20:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 5B3B88FC13; Sun, 17 Oct 2010 16:20:08 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id BF40A41C80E; Sun, 17 Oct 2010 18:20:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id Qumscshu7ptY; Sun, 17 Oct 2010 18:20:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id CC66141C832; Sun, 17 Oct 2010 18:20:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 7F9824448F3; Sun, 17 Oct 2010 16:17:01 +0000 (UTC) Date: Sun, 17 Oct 2010 16:17:01 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Nikolay Denev In-Reply-To: <7051D018-684F-417A-AAA0-00603B2FDCD4@gmail.com> Message-ID: <20101017161256.U10185@maildrop.int.zabbadoz.net> References: <7051D018-684F-417A-AAA0-00603B2FDCD4@gmail.com> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org, FreeBSD virtualization mailing list Subject: Re: ifconfig, vnets and interface names X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: FreeBSD virtualization mailing list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Oct 2010 16:20:09 -0000 On Sun, 17 Oct 2010, Nikolay Denev wrote: > Hello, > > While playing with vnet jails I've discovered the following oddity, which probably is not what's expected to happen : > ... > And that's what ifconfig shows after this : > > [16:52]root@nas:/home/ndenev# ifconfig > <... snip lo0 and physical interface ...> > epair0a: flags=8842 metric 0 mtu 1500 > ether 02:8c:53:00:03:0a > epair1a: flags=8842 metric 0 mtu 1500 > ether 02:b6:49:00:05:0a > eth0: flags=8842 metric 0 mtu 1500 > ether 02:8c:53:00:04:0b > ether 02:b6:49:00:06:0b > > Instead of two interfaces, I'm seeing one with to lladdrs, because of the interface names being the same. > > Then I'm trying to destroy them : > > [16:52]root@nas:/home/ndenev# ifconfig eth0 destroy > [16:53]root@nas:/home/ndenev# ifconfig > <... snip lo0 and physical interface ...> > epair1a: flags=8842 metric 0 mtu 1500 > ether 02:b6:49:00:05:0a > eth0: flags=8842 metric 0 mtu 1500 > ether 02:b6:49:00:06:0b > [16:53]root@nas:/home/ndenev# ifconfig eth0 destroy > > > So in this case there may be not a clean way to address one of the interfaces specifically (i.e. destroy only the second one)? > > I've not investigated further, but I'm thinking probably this is just a "bug" in ifconfig interpreting/parsing the information from the kernel. > Maybe a solution is to extend ifconfig to be able print the interface list along with the ifIndex values and also manage the interfaces by index? > Auto renaming also is also probably a possible solution (i.e. eth0_1 , eth0_2 ) as these are interfaces coming from destroyed vnet's and are not likely to be in use. (but still sounds scary :) ) It's actually a bug in sys/net/if.c:if_vmove* we know about and that's on the todo list. I am not sure when the behaviour of ifconfig changed as previousy it would only show you one of the two interfaces with the single ether address. ifconfig -l however had shown eth0 twice. Neither is really what one would expect thus needs changing. /bz PS: freebsd-virtualization@ is the best list to report "VIMAGE" or "vnet" related problems. -- Bjoern A. Zeeb Welcome a new stage of life. From owner-freebsd-net@FreeBSD.ORG Sun Oct 17 16:37:40 2010 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 B947B106566B; Sun, 17 Oct 2010 16:37:40 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 167498FC14; Sun, 17 Oct 2010 16:37:39 +0000 (UTC) Received: by bwz16 with SMTP id 16so70782bwz.13 for ; Sun, 17 Oct 2010 09:37:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=6OR2FNsQpBNvTtYovYB9XJEyem1wX1SuuhpUo8VlFlQ=; b=kTmVVcFfyU7RGZDrGhXIAutYpRFtnJ5cvcSU1LD6Y3P7JzsGIWYhHm4wRnOvjivpNE yPMHG1ijZRICsZQDFpAdlBHFFIpMdXq/wc4kB6Fg/F1D3OFEj2syiWkB25faMhX+SrVN LwnuNJkJVZJ8GdRD8VCxvUTSKNLQT0VkwnZj8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=iq/YC1nbRWvFosp31P10yuH1gpLB6yu4caR2sQnm3hKYux0SEdsdoB/xJotX0SkXbn yrZJqFfejLkX1VSzavIvrwPZS5hpxig8rDnwDlHUdwbTn0WqPR9etwxSuXS3Ytgwgiil W/3RqHjlO6uQ3rQaMh0MGAu9JecK6avSLwh/0= Received: by 10.204.68.145 with SMTP id v17mr3447998bki.81.1287333458738; Sun, 17 Oct 2010 09:37:38 -0700 (PDT) Received: from ndenev.totalterror.net (93-152-151-19.ddns.onlinedirect.bg [93.152.151.19]) by mx.google.com with ESMTPS id a25sm14224025bks.20.2010.10.17.09.37.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 17 Oct 2010 09:37:37 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Nikolay Denev In-Reply-To: <20101017161256.U10185@maildrop.int.zabbadoz.net> Date: Sun, 17 Oct 2010 19:37:34 +0300 Content-Transfer-Encoding: 7bit Message-Id: References: <7051D018-684F-417A-AAA0-00603B2FDCD4@gmail.com> <20101017161256.U10185@maildrop.int.zabbadoz.net> To: FreeBSD virtualization mailing list X-Mailer: Apple Mail (2.1081) Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: ifconfig, vnets and interface names X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Oct 2010 16:37:40 -0000 On Oct 17, 2010, at 7:17 PM, Bjoern A. Zeeb wrote: > On Sun, 17 Oct 2010, Nikolay Denev wrote: > >> [ ... snip ... ] > > It's actually a bug in sys/net/if.c:if_vmove* we know about and that's > on the todo list. > Thanks, good to know. > I am not sure when the behaviour of ifconfig changed as previousy it > would only show you one of the two interfaces with the single ether > address. ifconfig -l however had shown eth0 twice. Neither is really > what one would expect thus needs changing. > > /bz > > PS: freebsd-virtualization@ is the best list to report "VIMAGE" or > "vnet" related problems. > Ok, I'll keep that in mind. > -- > Bjoern A. Zeeb Welcome a new stage of life. Regards, Nikolay From owner-freebsd-net@FreeBSD.ORG Sun Oct 17 18:27:39 2010 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 62A30106564A for ; Sun, 17 Oct 2010 18:27:39 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id E47B18FC0A for ; Sun, 17 Oct 2010 18:27:38 +0000 (UTC) Received: by ewy21 with SMTP id 21so123294ewy.13 for ; Sun, 17 Oct 2010 11:27:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9W4IFpYlrLQCJ0lB14R+j15dnBC4GG+6dQEtDI8kzSM=; b=XwPNyo3UK6PzXkL6kubscdZhOWLcb0ycPRCmVBPRugKCFixkS0iosapn/wAEGOGDzG +HBrhcB0ZjjKJcY2OwP8jz4OJtHE1aSEsaCYZCRtywx4ni/KMEBMf029dNoCJQk/t624 NwVrN7PQH+JDma8EdMdHzsRUYCIQNYaVw392Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Q5jSiWbrtRjLyznm6zlHI9vnk5pJcoYcZfMTvBJucL1IkEalffIX0yC9XTXwkJrehL WUy6tnWxDWjvNLF3FkOmgu37y4kqA8LnP0bC/k/k/kbu2xs+diXFeW4/8x1hT+rp4NqS Dm/uTycig3ijisiLTy8WvtAV1S+fUoc9AlkkU= MIME-Version: 1.0 Received: by 10.216.11.66 with SMTP id 44mr3523373wew.69.1287336199109; Sun, 17 Oct 2010 10:23:19 -0700 (PDT) Received: by 10.216.131.207 with HTTP; Sun, 17 Oct 2010 10:23:19 -0700 (PDT) In-Reply-To: References: <201008262259.QAA25138@lariat.net> <20100827062454.GB7160@relay.ibs.dn.ua> Date: Sun, 17 Oct 2010 12:23:19 -0500 Message-ID: From: Brandon Gooch To: "Li, Qing" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: zeus.panchenko@gmail.com, freebsd-net@freebsd.org Subject: Re: RADIX_MPATH usage information X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Oct 2010 18:27:39 -0000 On Fri, Aug 27, 2010 at 10:47 AM, Li, Qing wrote: > There are a couple of items I need to take care of > in this area, including the documentation, so I will get > it done this weekend. > > --Qing > > >> -----Original Message----- >> From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- >> net@freebsd.org] On Behalf Of Zeus V Panchenko >> Sent: Thursday, August 26, 2010 11:25 PM >> To: freebsd-net@freebsd.org >> Subject: Re: RADIX_MPATH usage information >> >> +1 >> >> -- >> Zeus V. Panchenko >> IT Dpt., IBS ltd =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0GMT+2 (EET) Qing, I've been looking for the documentation regarding this new feature, as I have the requirement of needing an ipfw(8) (or other firewall) setup. Unfortunately, I could find nothing, aside from the source code (which I'm attempting to read ATM). I have a computer with one em(4) interface with multiple VLANs running on top. I let the em0 interface configuration happen via DHCP, and I set the VLAN interfaces manually. I run 3 instances of sshd(8) on each separate VLAN interface, but I run into the issue of having the connection to each VLAN's sshd(8) instance attempt the return connection to the client via the default gateway of em0. So I've simply created an rc(8) script to handle manually configuring the routing table for each fib, something like a "my_networks.sh": #!/bin/sh # # PROVIDE: my_networks # REQUIRE: dhclient netif routing cleanvar # . /etc/rc.subr name=3D"my_networks" rcvar=3D${name}_enable start_cmd=3D"my_networks_start" stop_cmd=3D"my_networks_stop" my_networks_start() { setfib 1 route add default 192.168.1.1 -ifp vlan10 setfib 3 route delete 192.168.2.0/24 setfib 3 route delete 192.168.3.0/24 setfib 2 route add default 192.168.2.1 -ifp vlan20 setfib 3 route delete 192.168.1.0/24 setfib 3 route delete 192.168.3.0/24 setfib 3 route add default 192.168.3.1 -ifp vlan30 setfib 3 route delete 192.168.1.0/24 setfib 3 route delete 192.168.2.0/24 setfib 1 /usr/sbin/sshd -f /usr/local/etc/sshd_config_fib_1 setfib 2 /usr/sbin/sshd -f /usr/local/etc/sshd_config_fib_2 setfib 3 /usr/sbin/sshd -f /usr/local/etc/sshd_config_fib_3 } my_networks_stop() { setfib 1 route flush setfib 2 route flush setfib 3 route flush killall sshd } load_rc_config $name : ${my_networks_enable=3D"NO"} run_rc_command "$1" ...and it seems to work. I'm not sure how technically sound this method is, but I haven't found or read anything to confirm, condone or condemn the methodology. If I were to use the RADIX_MPATH option in the kernel, would this eliminate the need to delete routes from the "foreign" VLAN interfaces' routing table (to prevent return connection packets heading out the default gateway of em0, configured via DHCP)? Thanks! -Brandon From owner-freebsd-net@FreeBSD.ORG Sun Oct 17 21:38:55 2010 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 E61D8106564A; Sun, 17 Oct 2010 21:38:55 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 4AC458FC1A; Sun, 17 Oct 2010 21:38:54 +0000 (UTC) Received: from lawrence1.loshell.room52.net (ppp59-167-184-191.static.internode.on.net [59.167.184.191]) by lauren.room52.net (Postfix) with ESMTPSA id 228D67E8AE; Mon, 18 Oct 2010 08:38:53 +1100 (EST) Message-ID: <4CBB6CE9.1030009@freebsd.org> Date: Mon, 18 Oct 2010 08:38:49 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-AU; rv:1.9.2.9) Gecko/20101006 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Andre Oppermann References: <4CA5D1F0.3000307@freebsd.org> <4CA9B6AC.20403@freebsd.org> In-Reply-To: <4CA9B6AC.20403@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lauren.room52.net Cc: freebsd-net@freebsd.org, Sriram Gorti Subject: Re: Question on TCP reassembly counter X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Oct 2010 21:38:56 -0000 On 10/04/10 22:12, Lawrence Stewart wrote: > On 10/01/10 22:20, Andre Oppermann wrote: >> On 01.10.2010 12:01, Sriram Gorti wrote: >>> Hi, >>> >>> In the following is an observation when testing our XLR/XLS network >>> driver with 16 concurrent instances of netperf on FreeBSD-CURRENT. >>> Based on this observation, I have a question on which I hope to get >>> some understanding from here. >>> >>> When running 16 concurrent netperf instances (each for about 20 >>> seconds), it was found that after some number of runs performance >>> degraded badly (almost by a factor of 5). All subsequent runs remained >>> so. Started debugging this from TCP-side as other driver tests were >>> doing fine for comparably long durations on same board+s/w. >>> >>> netstat indicated the following: >>> >>> $ netstat -s -f inet -p tcp | grep discarded >>> 0 discarded for bad checksums >>> 0 discarded for bad header offset fields >>> 0 discarded because packet too short >>> 7318 discarded due to memory problems >>> >>> Then, traced the "discarded due to memory problems" to the following >>> counter: >>> >>> $ sysctl -a net.inet.tcp.reass >>> net.inet.tcp.reass.overflows: 7318 >>> net.inet.tcp.reass.maxqlen: 48 >>> net.inet.tcp.reass.cursegments: 1594<--- // corresponds to >>> V_tcp_reass_qsize variable >>> net.inet.tcp.reass.maxsegments: 1600 >>> >>> Our guess for the need for reassembly (in this low-packet-loss test >>> setup) was the lack of per-flow classification in the driver, causing >>> it to spew incoming packets across the 16 h/w cpus instead of packets >>> of a flow being sent to the same cpu. While we are working on >>> addressing this driver limitation, debugged further to see how/why the >>> V_tcp_reass_qsize grew (assuming that out-of-order segments should >>> have dropped to zero at the end of the run). It was seen that this >>> counter was actually growing up from the initial runs but only when it >>> reached near to maxsgements, perf degradation was seen. Then, started >>> looking at vmstat also to see how many of the reassembly segments were >>> lost. But, there were no segments lost. We could not reconcile "no >>> lost segments" with "growth of this counter across test runs". >> >> A patch is in the works to properly autoscale the reassembly queue >> and should be comitted shortly. >> >>> $ sysctl net.inet.tcp.reass ; vmstat -z | egrep "FREE|mbuf|tcpre" >>> net.inet.tcp.reass.overflows: 0 >>> net.inet.tcp.reass.maxqlen: 48 >>> net.inet.tcp.reass.cursegments: 147 >>> net.inet.tcp.reass.maxsegments: 1600 >>> ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP >>> mbuf_packet: 256, 0, 4096, 3200, 5653833, 0, 0 >>> mbuf: 256, 0, 1, 2048, 4766910, 0, 0 >>> mbuf_cluster: 2048, 25600, 7296, 6, 7297, 0, 0 >>> mbuf_jumbo_page: 4096, 12800, 0, 0, 0, 0, 0 >>> mbuf_jumbo_9k: 9216, 6400, 0, 0, 0, 0, 0 >>> mbuf_jumbo_16k: 16384, 3200, 0, 0, 0, 0, 0 >>> mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0, 0 >>> tcpreass: 20, 1690, 0, 845, 1757074, 0, 0 >>> >>> In view of these observations, my question is: is it possible for the >>> V_tcp_reass_qsize variable to be unsafely updated on SMP ? (The >>> particular flavor of XLS that was used in the test had 4 cores with 4 >>> h/w threads/core). I see that the tcp_reass function assumes some lock >>> is taken but not sure if it is the per-socket or the global tcp lock. >> >> The updating of the global counter is indeed unsafe and becomes obsolete >> with the autotuning patch. >> >> The patch is reviewed by me and ready for commit. However lstewart@ is >> currently writing his thesis and has only very little spare time. I'll >> send you the patch in private email so you can continue your testing. > > Quick update on this: patch is blocked while waiting for Jeff to review > some related UMA changes. As soon as I get the all clear I'll push > everything into head. Revision 213913 of the svn head branch finally has all patches. If you encounter any additional odd behaviour related to reassembly or notice net.inet.tcp.reass.overflows increasing, please let me know. Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Mon Oct 18 11:07:02 2010 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 D8AE21065672 for ; Mon, 18 Oct 2010 11:07:02 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C54D58FC0C for ; Mon, 18 Oct 2010 11:07:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o9IB72KJ029393 for ; Mon, 18 Oct 2010 11:07:02 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o9IB72oc029391 for freebsd-net@FreeBSD.org; Mon, 18 Oct 2010 11:07:02 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 18 Oct 2010 11:07:02 GMT Message-Id: <201010181107.o9IB72oc029391@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 11:07:02 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150257 net [msk] watchdog timeout o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o kern/150247 net [patch] [ixgbe] Version in -current won't build on 7.x o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co o kern/150148 net [ath] Atheros 5424/2424 - AR2425 stopped working with o kern/150052 net [wi] wi(4) driver does not work with wlan(4) driver fo f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net [ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149786 net [bwn] bwn on Dell Inspiron 1150: connections stall o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149539 net [ath] atheros ar9287 is not supported by ath_hal o kern/149516 net [ath] ath(4) hostap with fake MAC/BSSID results in sta o kern/149373 net [realtek/atheros]: None of my network card working o kern/149307 net [ath] Doesn't work Atheros 9285 o kern/149306 net [alc] Doesn't work Atheros AR8131 PCIe Gigabit Etherne o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148862 net [panic] page fault while in kernel mode at _mtx_lock_s o kern/148322 net [ath] Triggering atheros wifi beacon misses in hostap o kern/148317 net [ath] FreeBSD 7.x hostap memory leak in net80211 or At o kern/148078 net [ath] wireless networking stops functioning o kern/147985 net [alc] alc network driver + tso ( + vlan ? ) does not w o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147862 net [wpi] Possible bug in the wpi driver. Network Manager o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by o kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146759 net [cxgb] [patch] cxgb panic calling cxgb_set_lro() witho o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146517 net [ath] [wlan] device timeouts for ath wlan device on re o kern/146427 net [mwl] Additional virtual access points don't work on m o kern/146426 net [mwl] 802.11n rates not possible on mwl o kern/146425 net [mwl] mwl dropping all packets during and after high u f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o bin/145934 net [patch] add count option to netstat(1) o kern/145826 net [ath] Unable to configure adhoc mode on ath0/wlan0 o kern/145825 net [panic] panic: soabort: so_count o kern/145777 net [wpi] Intel 3945ABG driver breaks the connection after o kern/145728 net [lagg] Stops working lagg between two servers. o amd64/145654 net amd64-curent memory leak in kernel o kern/144987 net [wpi] [panic] injecting packets with wlaninject using o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144642 net [rum] [panic] Enabling rum interface causes panic o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 o kern/144572 net [carp] CARP preemption mode traffic partially goes to f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/143939 net [ipfw] [em] ipfw nat and em interface rxcsum problem o kern/143874 net [wpi] Wireless 3945ABG error. wpi0 could not allocate o kern/143868 net [ath] [patch] [request] allow Atheros watchdog timeout o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143595 net [wpi] [panic] Creating virtual interface over wpi0 in o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o conf/143079 net hostapd(8) startup missing multi wlan functionality o kern/143074 net [wi]: wi driver triggers panic o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142907 net [wpi] if_wpi unstable on ibm/lenovo x60 -- suspect fir o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 o kern/141777 net [rum] [patch] Support usbdevs / rum(4) for Buffalo WLI f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/141023 net [carp] CARP arp replays with wrong src mac o kern/140796 net [ath] [panic] privileged instruction fault o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph o kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140564 net [wpi] Problem with Intel(R) PRO/Wireless 3945ABG o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140245 net [ath] [panic] Kernel panic during network activity on o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL o kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139079 net [wpi] Failure to attach wpi(4) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138739 net [wpi] wpi(4) does not work very well under 8.0-BETA4 o amd64/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138620 net [lagg] [patch] lagg port bpf-writes blocked o kern/138427 net [wpi] [panic] Kernel panic after trying set monitor wl o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 o bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed o kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o kern/137775 net [netgraph] [patch] Add XMIT_FAILOVER to ng_one2many o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137592 net [ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on ne o bin/137484 net [patch] Integer overflow in wpa_supplicant(8) base64 e o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136943 net [wpi] [lor] wpi0_com_lock / wpi0 o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136836 net [ath] atheros card stops functioning after about 12 ho o bin/136661 net [patch] ndp(8) ignores -f option o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/136426 net [panic] spawning several dhclients in parallel panics o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134931 net [route] Route messages sent to all socket listeners re o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134168 net [ral] ral driver problem on RT2525 2.4GHz transceiver o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133613 net [wpi] [panic] kernel panic in wpi(4) o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o kern/132885 net [wlan] 802.1x broken after SVN rev 189592 o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132722 net [ath] Wifi ath0 associates fine with AP, but DHCP or I o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o bin/131365 net route(8): route add changes interpretation of network o kern/131153 net [iwi] iwi doesn't see a wireless network f kern/131087 net [ipw] [panic] ipw / iwi - no sent/received packets; iw f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg o kern/125721 net [ath] Terrible throughput/high ping latency with Ubiqu o kern/125617 net [ath] [panic] ath(4) related panic f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125501 net [ath] atheros cardbus driver hangs f kern/125332 net [ath] [panic] crash under any non-tiny networking unde o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111457 net [ral] ral(4) freeze o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks f kern/107279 net [ath] [panic] ath_start: attempted use of a free mbuf! o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] f kern/105348 net [ath] ath device stopps TX o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working f bin/97392 net ppp(8) hangs instead terminating o kern/97306 net [netgraph] NG_L2TP locks after connection with failed f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear f kern/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [arp] [patch] for static ARP tables in rc.network 364 problems total. From owner-freebsd-net@FreeBSD.ORG Sat Oct 16 03:55:16 2010 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 743061065696; Sat, 16 Oct 2010 03:55:16 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx09.syd.optusnet.com.au (fallbackmx09.syd.optusnet.com.au [211.29.132.242]) by mx1.freebsd.org (Postfix) with ESMTP id 749BB8FC15; Sat, 16 Oct 2010 03:55:15 +0000 (UTC) Received: from mail07.syd.optusnet.com.au (mail07.syd.optusnet.com.au [211.29.132.188]) by fallbackmx09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o9G1X1nn025708; Sat, 16 Oct 2010 12:33:01 +1100 Received: from c122-106-146-165.carlnfd1.nsw.optusnet.com.au (c122-106-146-165.carlnfd1.nsw.optusnet.com.au [122.106.146.165]) by mail07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o9G1Wt8u026565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 16 Oct 2010 12:32:56 +1100 Date: Sat, 16 Oct 2010 12:32:55 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: "Robert N. M. Watson" In-Reply-To: <93AB0F13-5995-4AAD-BEFC-A6F1317E3CA6@freebsd.org> Message-ID: <20101016114647.E63520@besplex.bde.org> References: <15387E38-1E6C-4347-BEA1-61AEE31B5544@freebsd.org> <93AB0F13-5995-4AAD-BEFC-A6F1317E3CA6@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Mon, 18 Oct 2010 11:36:11 +0000 Cc: FreeBSD Current , freebsd-net@freebsd.org, Garrett Cooper , Attilio Rao , Sergey Kandaurov , Jack F Vogel , Ryan Stone , Ryan Stone , Ed Maste Subject: Re: [PATCH] Netdump for review and testing -- preliminary version X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Oct 2010 03:55:16 -0000 On Fri, 15 Oct 2010, Robert N. M. Watson wrote: > On 15 Oct 2010, at 20:39, Garrett Cooper wrote: > >> But there are already some cases that aren't properly handled >> today in the ddb area dealing with dumping that aren't handled >> properly. Take for instance the following two scenarios: >> 1. Call doadump twice from the debugger. >> 2. Call doadump, exit the debugger, reenter the debugger, and call >> doadump again. >> Both of these scenarios hang reliably for me. >> I'm not saying that we should regress things further, but I'm just >> noting that there are most likely a chunk of edgecases that aren't >> being handled properly when doing dumps that could be handled better / >> fixed. Even thinking about calling doadump even once from within the debugger is an error. I was asleep when the similar error for panic was committed, and this error has propagated. Debuggers should use a trampoline to call the "any" function, not the least so that they can be used to debug the "any" function without the extra complications to make themself reentrant. I think gdb has always used a trampoline for this outside of the kernel. Not sure what it does within the kernel, but it would have even larger problems than in userland finding a place for the trampoline. In the kernel, there is the additional problem of keeping control while the "any" function is run. Other CPUs must be kept stopped and interrupts must be kept masked, except when the "any" function really needs other CPUs or unmasked interrupts. Single stepping also needs this and doesn't have it (other CPUs and interrupt handlers can run and execute any number of instructions while you are trying to execute a single one). All ddb "commands" that change the system state are really non-ddb commands that should use an external function via a trampoline. Panicing and dumping are just the largest ones, so they are the most impossible to do correctly as commands and the most in need of ddb to debug them. > Right: one of the points I've made to Attilio is that we need to move to a more principled model as to what sorts of things we allow in various kernel environments. The early boot is a special environment -- so is the debugger, but the debugger on panic is not the same as the debugger when you can continue. Likewise, the crash dumping code is special, but also not the same as the debugger. Right now, exceptional behaviour to limit hangs/etc is done inconsistently. We need to develop a set of principles that tell us what is permitted in what contexts, and then use that to drive design decisions, normalizing what's there already. ENONUNIXEDITOR. Format not recovered. panic() from within a debugger (or a fast interrupt handler, or a fast interrupt handler that has trappeded to the debugger by request...) is, although an error, not too bad since panic() must be prepared to work starting from the "any" state anyway, and as you mention it doesn'tneed to be able to return (except for RESTARTABLE_PANICS, which makes things impossibly difficult). Continuing from a debugger is feasible mainly because in the usual case the system state is not changed (except for time-dependent things). If you use it to modify memory or i/o or run one of its unsafe commands then you have to be careful. > This is not dissimilar to what we do with locking already, BTW: we define a set of kernel environments (fast interrupt handlers, non-sleepable threads, sleepable thread holding non-sleepable locks, etc), and based on those principles prevent significant sources of instability that might otherwise arise in a complex, concurrent kernel. We need to apply the same sort of approach to handling kernel debugging and crashing. Locking has imposed considerable discipline, which if followed by panic() would should how wrong most of the things done by panic() are -- it will hit locks, but shouldn't even be calling functions that have locks, since such functions expect their locks to work. The rules for fast interrupt handlers are simple and mostly not followed. They are that a fast interrupt handler may not access any state not specially locked by its subsystem. This means that they may not call any other subsystem or any upper layer except the null set of ones documented to be safe to call. In practice, this means not calling the "any" function, but it is necessary for atomic ops, bus space accesses, and a couple of scheduling functions to be safe enough. > BTW, my view is that except in very exceptional cases, it should not be possible to continue after generating a dump. Dumps often cause disk controllers to get reset, which may leave outstanding I/O in nasty situations. Unless the dump device and model is known not to interfere with operation, we should set state indicating that the system is non-continuable once a dump has occurred. It might be safe if the system reinitialized everything. Too hard for just dumping, but it is needed after resume anyway. So the following could reasonably work: - stop system while its state is believed to be good - dump - restart/resume. The order for this is unclear. Normal resume might want the system to have not stopped as much as it needed to for dumping. Bruce From owner-freebsd-net@FreeBSD.ORG Mon Oct 18 12:02:00 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D42EE10656A9; Mon, 18 Oct 2010 12:02:00 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A9A588FC16; Mon, 18 Oct 2010 12:02:00 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o9IC20Zw092646; Mon, 18 Oct 2010 12:02:00 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o9IC20k8092637; Mon, 18 Oct 2010 12:02:00 GMT (envelope-from linimon) Date: Mon, 18 Oct 2010 12:02:00 GMT Message-Id: <201010181202.o9IC20k8092637@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/151441: [iwi] iwi module not work properly using HP nc6220 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 12:02:00 -0000 Old Synopsis: iwi module New Synopsis: [iwi] iwi module not work properly using HP nc6220 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Oct 18 12:00:26 UTC 2010 Responsible-Changed-Why: Reclassify. To submitter: we are going to need more detail, e.g., your /var/run/dmesg.boot. http://www.freebsd.org/cgi/query-pr.cgi?pr=151441 From owner-freebsd-net@FreeBSD.ORG Mon Oct 18 12:25:06 2010 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 198CF10656A3 for ; Mon, 18 Oct 2010 12:25:06 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id BDB218FC2F for ; Mon, 18 Oct 2010 12:25:05 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1P7om0-0004ZT-NY for freebsd-net@freebsd.org; Mon, 18 Oct 2010 14:25:04 +0200 Received: from edr011.inf.tu-dresden.de ([141.76.6.11]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Oct 2010 14:25:04 +0200 Received: from js by edr011.inf.tu-dresden.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Oct 2010 14:25:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Julian Stecklina Date: Mon, 18 Oct 2010 14:19:20 +0200 Lines: 27 Message-ID: <87r5fn3d87.fsf@alien8.de> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: edr011.inf.tu-dresden.de User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:j49+hJdP7iHWpWU0exlGrGAZjaM= Subject: Mobile IPv6 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 12:25:06 -0000 --=-=-= Hello, I am trying to find out what the status of Mobile IPv6 in the FreeBSD network stack is. So far I discovered some traces in the rtadvd man page, but the rtadvd code doesn't seem to contain Mobile IPv6 support.. The most recent info I found is this KAME newsletter: http://www.kame.net/newsletter/20050707/ It doesn't seem to me that this SHISA stack was integrated into mainline FreeBSD. Can somebody comment on the status of Mobile IPv6 in FreeBSD? Regards, Julian --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAky8O04ACgkQ2EtjUdW3H9mHrQCgt0sLfoYO27Su8B1XJ2Lo2KG2 VrEAnRlLqGFXz5aAk3fSgwtJbLJTuV2o =BHO9 -----END PGP SIGNATURE----- --=-=-=-- From owner-freebsd-net@FreeBSD.ORG Mon Oct 18 12:47:55 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3CDB1106564A; Mon, 18 Oct 2010 12:47:55 +0000 (UTC) (envelope-from bschmidt@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 121838FC1D; Mon, 18 Oct 2010 12:47:55 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o9IClsKx038362; Mon, 18 Oct 2010 12:47:54 GMT (envelope-from bschmidt@freefall.freebsd.org) Received: (from bschmidt@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o9IClsRI038358; Mon, 18 Oct 2010 12:47:54 GMT (envelope-from bschmidt) Date: Mon, 18 Oct 2010 12:47:54 GMT Message-Id: <201010181247.o9IClsRI038358@freefall.freebsd.org> To: bschmidt@FreeBSD.org, freebsd-net@FreeBSD.org, bschmidt@FreeBSD.org From: bschmidt@FreeBSD.org Cc: Subject: Re: kern/131087: [ipw] [panic] ipw / iwi - no sent/received packets; iwi needs to be restarted; ipw / iwi causes kernel panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 12:47:55 -0000 Synopsis: [ipw] [panic] ipw / iwi - no sent/received packets; iwi needs to be restarted; ipw / iwi causes kernel panic Responsible-Changed-From-To: freebsd-net->bschmidt Responsible-Changed-By: bschmidt Responsible-Changed-When: Mon Oct 18 12:47:30 UTC 2010 Responsible-Changed-Why: over to me. http://www.freebsd.org/cgi/query-pr.cgi?pr=131087 From owner-freebsd-net@FreeBSD.ORG Mon Oct 18 13:08:59 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 638691065672; Mon, 18 Oct 2010 13:08:59 +0000 (UTC) (envelope-from bschmidt@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3980B8FC12; Mon, 18 Oct 2010 13:08:59 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o9ID8xlS060159; Mon, 18 Oct 2010 13:08:59 GMT (envelope-from bschmidt@freefall.freebsd.org) Received: (from bschmidt@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o9ID8whM060155; Mon, 18 Oct 2010 13:08:58 GMT (envelope-from bschmidt) Date: Mon, 18 Oct 2010 13:08:58 GMT Message-Id: <201010181308.o9ID8whM060155@freefall.freebsd.org> To: adamk@voicenet.com, bschmidt@FreeBSD.org, freebsd-net@FreeBSD.org From: bschmidt@FreeBSD.org Cc: Subject: Re: kern/131153: [iwi] iwi doesn't see a wireless network X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 13:08:59 -0000 Synopsis: [iwi] iwi doesn't see a wireless network State-Changed-From-To: open->closed State-Changed-By: bschmidt State-Changed-When: Mon Oct 18 13:08:13 UTC 2010 State-Changed-Why: Originator reported this issue is solved. http://www.freebsd.org/cgi/query-pr.cgi?pr=131153 From owner-freebsd-net@FreeBSD.ORG Mon Oct 18 18:40:44 2010 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 04976106567A; Mon, 18 Oct 2010 18:40:44 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5D8738FC14; Mon, 18 Oct 2010 18:40:41 +0000 (UTC) Received: by bwz16 with SMTP id 16so4733bwz.13 for ; Mon, 18 Oct 2010 11:40:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=gYpdvLJPkjZwsO12A/qbZFLQuhW3hn/+1V6u6O7rLp0=; b=HHGozPI6HMa3fVeAt6nNSctPYdNoONAiEmXOtv29QM3p06qoCARSXhq3BdTdoQ8c2c ef4X0Ghz/huwkr2Lh5nridvPY2Zb+sOYp4wXeLKWepNVW+zLzKJiWBQmkY6BsEHkbviT UFSfCpxhiQBRDoNDJHWOSeIDSYXtsywL0WBEM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; b=RN2B7ff4aZvMGiS0AyV897KKjaxIanils4EEo3wMWKgQNd4VmTEndweK5f4pRWMPkZ 9/FqnVGMotJIAkfbxOQQT1G05PfM0tDmUdkLzOJoo7KdENEsF8bvyphxaoQ6US9/H2ym 5nixuafaNEqa8nl+FHzcyG2jLfclOGYPhrb54= Received: by 10.204.99.131 with SMTP id u3mr4825872bkn.41.1287425465205; Mon, 18 Oct 2010 11:11:05 -0700 (PDT) MIME-Version: 1.0 Sender: ermal.luci@gmail.com Received: by 10.204.35.68 with HTTP; Mon, 18 Oct 2010 11:10:44 -0700 (PDT) From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= Date: Mon, 18 Oct 2010 19:10:44 +0100 X-Google-Sender-Auth: 8IlNRlSknaXVNiWcboSW7deCKz0 Message-ID: To: freebsd-pf@freebsd.org, freebsd-net Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: [PATCH] pf(4) patch from OpenBSD 4.5 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 18:40:44 -0000 Hello, the link http://people.freebsd.org/~eri/pf45_1.diff has the patch for pf(4) as of OpenBSD 4.5 version. The patch is against HEAD. After OpenBSD 4.5 the syntax has changed and this is the reason for such an 'old' version patch. After importing this one the work will go on the newest version and decisions on it will than be done. Be aware that this patch has even support for VIMAGE/VNET. It will enable you to run pf(4) with[in] jails+vnets or just vnets themselves with separate rulesets and policies. pfsync(4) can be loaded as a module also with this patch. Feedback is very welcome. Regards, -- Ermal From owner-freebsd-net@FreeBSD.ORG Tue Oct 19 03:16:38 2010 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 D3881106566C for ; Tue, 19 Oct 2010 03:16:38 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 1AAC48FC0C for ; Tue, 19 Oct 2010 03:16:37 +0000 (UTC) Received: by wwb13 with SMTP id 13so1066675wwb.31 for ; Mon, 18 Oct 2010 20:16:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=KNglrZGlqKNRcnJukhqTu94peDU8dKi9ZMEr6tTZrz0=; b=wVuoIZuf9cuLxG4FAlneYbm2TkZOJ66UjMsOJzfp4Viaat093OWDzvlVeXHmOHK5PI 8ngZSlyEelyZhlSUc5jGC+5qSUjXJjHAwy7YX56LrdoALF1Z1gtwTya7Agl+22IhBU4u bBNAFQhScI27fLFVEWWap5qMUF1jJiLK/ph3s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=eYGF3T3JPx/mCL2beHfsXyyAKwjTeX7SYPdsVWDEiHLlPN9SUKXawpJvIMkDVfulxF jLxwaS6V6hjpEcOaAtc/HB1vCDCDND+XtIigryJ7c7Cdm0YI4tFsEtBQ8765OxHvWUZi r63/JLZsbultZcrgdFaCkBObAGuWZ3uJJCnNI= MIME-Version: 1.0 Received: by 10.227.208.73 with SMTP id gb9mr5562348wbb.13.1287458196065; Mon, 18 Oct 2010 20:16:36 -0700 (PDT) Received: by 10.216.55.135 with HTTP; Mon, 18 Oct 2010 20:16:36 -0700 (PDT) In-Reply-To: References: Date: Mon, 18 Oct 2010 22:16:36 -0500 Message-ID: From: Brandon Gooch To: =?ISO-8859-1?Q?Ermal_Lu=E7i?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net , freebsd-pf@freebsd.org Subject: Re: [PATCH] pf(4) patch from OpenBSD 4.5 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 03:16:39 -0000 On Mon, Oct 18, 2010 at 1:10 PM, Ermal Lu=E7i wrote: > Hello, > > the link http://people.freebsd.org/~eri/pf45_1.diff has the patch for > pf(4) as of OpenBSD 4.5 version. > The patch is against HEAD. > After OpenBSD 4.5 the syntax has changed and this is the reason for > such an 'old' version patch. > > After importing this one the work will go on the newest version and > decisions on it will than be done. > > Be aware that this patch has even support for VIMAGE/VNET. > It will enable you to run pf(4) with[in] jails+vnets or just vnets > themselves with separate rulesets > and policies. > pfsync(4) can be loaded as a module also with this patch. > > Feedback is very welcome. Should this compile against HEAD, because I think we're missing a header: brandon@x300:~$ cd /usr/src brandon@x300:/usr/src$ patch < ~/pf45_1.diff brandon@x300:/usr/src$ cd /usr/src/sys/modules/pf brandon@x300:modules/pf$ sudo make Warning: Object directory not changed from original /usr/src/sys/modules/pf @ -> /usr/src/sys machine -> /usr/src/sys/amd64/include echo "#define DEV_PF 1" > opt_pf.h echo "#define DEV_PFLOG 1" >> opt_pf.h echo "#define DEV_PFSYNC 1" >> opt_pf.h echo "#define DEV_PFLOW 1" >> opt_pf.h echo "#define INET 1" > opt_inet.h echo "#define INET6 1" > opt_inet6.h echo "#define DEV_BPF 1" > opt_bpf.h :> opt_global.h clang -O2 -pipe -fno-strict-aliasing -D_KERNEL -DKLD_MODULE -nostdinc -I/usr/src/sys/modules/pf/../../contrib/pf -I. -I@ -I@/contrib/altq -fno-common -fno-omit-frame-pointer -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /usr/src/sys/modules/pf/../../contrib/pf/net/pf.c clang: warning: argument unused during compilation: '-mfpmath=3D387' /usr/src/sys/modules/pf/../../contrib/pf/net/pf.c:149:10: fatal error: 'net/if_pflow.h' file not found #include ^ 1 error generated. *** Error code 1 Thanks for working on this! -Brandon From owner-freebsd-net@FreeBSD.ORG Tue Oct 19 04:28:18 2010 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 C829E1065672; Tue, 19 Oct 2010 04:28:18 +0000 (UTC) (envelope-from max@laiers.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by mx1.freebsd.org (Postfix) with ESMTP id 587F58FC19; Tue, 19 Oct 2010 04:28:18 +0000 (UTC) Received: from [192.168.8.46] (75-147-189-33-Washington.hfc.comcastbusiness.net [75.147.189.33]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0Lxdhj-1ObXv62Jyt-016lu0; Tue, 19 Oct 2010 06:15:41 +0200 Message-ID: <4CBD1B68.2040502@laiers.net> Date: Mon, 18 Oct 2010 21:15:36 -0700 From: Max Laier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Brandon Gooch References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V02:K0:4SeBd2kN+fgjDDcdyFek/rwEAZKAo3N7v2mi29fXk00 TPZfZSo4oscCqSxp+h+HFHwH7TMyGU83bDG4RisOoVWvYERtF4 15zh0KYDgAeBhrCNdabA/E+hcYDYk4++q7rJzE53OwdpA6M6b4 RWi4J+1h5y/DyW7yw8nEvRBKOGtUqBKq2bI0RbsfBBnhqrApLW S9B+A+gdvrp9mXjtaHe8Q== Cc: =?ISO-8859-1?Q?Ermal_Lu=E7i?= , freebsd-net , freebsd-pf@freebsd.org Subject: Re: [PATCH] pf(4) patch from OpenBSD 4.5 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 04:28:19 -0000 On 18.10.2010 20:16, Brandon Gooch wrote: > On Mon, Oct 18, 2010 at 1:10 PM, Ermal Luçi wrote: >> Hello, >> >> the link http://people.freebsd.org/~eri/pf45_1.diff has the patch for >> pf(4) as of OpenBSD 4.5 version. >> The patch is against HEAD. >> After OpenBSD 4.5 the syntax has changed and this is the reason for >> such an 'old' version patch. >> >> After importing this one the work will go on the newest version and >> decisions on it will than be done. >> >> Be aware that this patch has even support for VIMAGE/VNET. >> It will enable you to run pf(4) with[in] jails+vnets or just vnets >> themselves with separate rulesets >> and policies. >> pfsync(4) can be loaded as a module also with this patch. >> >> Feedback is very welcome. > > Should this compile against HEAD, because I think we're missing a header: > > brandon@x300:~$ cd /usr/src > brandon@x300:/usr/src$ patch< ~/pf45_1.diff $ patch -p0 < ~/pf45_1.diff > brandon@x300:/usr/src$ cd /usr/src/sys/modules/pf > brandon@x300:modules/pf$ sudo make Regards, Max From owner-freebsd-net@FreeBSD.ORG Tue Oct 19 05:26:32 2010 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 3624A1065670 for ; Tue, 19 Oct 2010 05:26:32 +0000 (UTC) (envelope-from keiichi@iijlab.net) Received: from omgo.iij.ad.jp (mo30.iij.ad.jp [202.232.30.71]) by mx1.freebsd.org (Postfix) with ESMTP id DB3238FC19 for ; Tue, 19 Oct 2010 05:26:31 +0000 (UTC) DKIM-Signature: v=1;a=rsa-sha256;c=relaxed/simple;d=iijlab.net;h=Subject: Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding: Message-Id:References:To;i=keiichi@iijlab.net;s=omgo1;t=1287465163;x= 1288674763; bh=fgF03Z1OG+qXvW6fGn/OyIiLkazRIDIQvUNpxeMZJB4=; b=bsqHTAJ2n1YNQ7jA eLZ84fH2UzH7JcU8oqDCt4iw1V6mbjvRTjwNshJDcv0xlUMhvRAlq80Hn5pR7x5cKaCm79XJ1Y8jk NciLybtxrICZ6D+HzpIq8jpfHC6ZVERoeC5CQNFCYAQAmJArvicE2nH6GclgRAvhgWL30dW0XnXon 4=; Received: by omgo.iij.ad.jp (mo30) id o9J5ChPv000306; Tue, 19 Oct 2010 14:12:43 +0900 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Keiichi SHIMA In-Reply-To: <87r5fn3d87.fsf@alien8.de> Date: Tue, 19 Oct 2010 14:12:45 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <65BDFA9C-F663-4D3F-85F6-CCE860052870@iijlab.net> References: <87r5fn3d87.fsf@alien8.de> To: Julian Stecklina X-Mailer: Apple Mail (2.1081) Cc: freebsd-net@freebsd.org Subject: Re: Mobile IPv6 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 05:26:32 -0000 Hello, I was working on the code long time ago. Unfortunately we couldn't merge our work to the FreeBSD main stream, = mainly because our development power was not enough. Also, in the = latter stage of development, we were focusing on NetBSD. The code can = be found on sourceforge (http://sourceforge.net/projects/shisa/), but it = is almost 2 years old... --- Keiichi SHIMA Research Laboratory, IIJ Innovation Institute WIDE Project On Oct 18, 2010, at 9:19 PM, Julian Stecklina wrote: > Hello, >=20 > I am trying to find out what the status of Mobile IPv6 in the FreeBSD > network stack is. So far I discovered some traces in the rtadvd man > page, but the rtadvd code doesn't seem to contain Mobile IPv6 > support.. The most recent info I found is this KAME newsletter: > http://www.kame.net/newsletter/20050707/ It doesn't seem to me that = this > SHISA stack was integrated into mainline FreeBSD. >=20 > Can somebody comment on the status of Mobile IPv6 in FreeBSD? >=20 > Regards, > Julian From owner-freebsd-net@FreeBSD.ORG Tue Oct 19 06:46:14 2010 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 7CDBA1065693 for ; Tue, 19 Oct 2010 06:46:14 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 3E30D8FC08 for ; Tue, 19 Oct 2010 06:46:14 +0000 (UTC) Received: from lstewart.caia.swin.edu.au (lstewart.caia.swin.edu.au [136.186.229.95]) by lauren.room52.net (Postfix) with ESMTPSA id 8F1927E853; Tue, 19 Oct 2010 17:46:11 +1100 (EST) Message-ID: <4CBD3EB3.8030004@freebsd.org> Date: Tue, 19 Oct 2010 17:46:11 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20101004 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Julian Stecklina References: <87r5fn3d87.fsf@alien8.de> In-Reply-To: <87r5fn3d87.fsf@alien8.de> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lauren.room52.net Cc: freebsd-net@freebsd.org Subject: Re: Mobile IPv6 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 06:46:14 -0000 On 10/18/10 23:19, Julian Stecklina wrote: > Hello, > > I am trying to find out what the status of Mobile IPv6 in the FreeBSD > network stack is. So far I discovered some traces in the rtadvd man > page, but the rtadvd code doesn't seem to contain Mobile IPv6 > support.. The most recent info I found is this KAME newsletter: > http://www.kame.net/newsletter/20050707/ It doesn't seem to me that this > SHISA stack was integrated into mainline FreeBSD. > > Can somebody comment on the status of Mobile IPv6 in FreeBSD? As far as I'm aware, there's no support in the base system. Many years ago I worked on a MIPv6 FreeBSD testbed. The tech report is very old, but might provide some useful nuggets of information: http://caia.swin.edu.au/reports/040331A/CAIA-TR-040331A.pdf Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Tue Oct 19 13:39:03 2010 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 3B90410656B7; Tue, 19 Oct 2010 13:39:03 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 70C138FC18; Tue, 19 Oct 2010 13:39:02 +0000 (UTC) Received: by fxm12 with SMTP id 12so1594891fxm.13 for ; Tue, 19 Oct 2010 06:39:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=g0tRUsFxXcUpJvIeGEQ/weA0uyVYQk5TqORHfoXZKpc=; b=A/Vu83+7eqUkdH+Dymq5OsBnO6AgpvByKhnFZMDqT0QavnKMbLBGVX1QemqZuna4WT iLq3bQnAX7RH5u6eLOoSvTm1iBWFUy6qXvn3znXfZjZ/86dV9O8XKMt3MIxgJQeXOJQU bIwWd6/FSJUiRZcRUjfpMro3sUlNvvy+var0o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=wCnq4qodvZTIk2IeId25rZmFMLsZUKQkBUngEtDg/GwXbXsu7vfYn4/Qo1iHRy1tnM aKvKC4IOPSN2qSWUnKYflT8q9TEndS3ZZC15Jn5JUYQVqZXvmWNoFpj3NxdOBw4o3DJj zbRHLJzQQevcru0BE2D6HfMJP03TbgzxYA1BI= MIME-Version: 1.0 Received: by 10.216.51.21 with SMTP id a21mr6120131wec.50.1287495541194; Tue, 19 Oct 2010 06:39:01 -0700 (PDT) Received: by 10.216.55.135 with HTTP; Tue, 19 Oct 2010 06:39:01 -0700 (PDT) In-Reply-To: <4CBD1B68.2040502@laiers.net> References: <4CBD1B68.2040502@laiers.net> Date: Tue, 19 Oct 2010 08:39:01 -0500 Message-ID: From: Brandon Gooch To: Max Laier Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: =?ISO-8859-1?Q?Ermal_Lu=E7i?= , freebsd-net , freebsd-pf@freebsd.org Subject: Re: [PATCH] pf(4) patch from OpenBSD 4.5 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 13:39:03 -0000 On Mon, Oct 18, 2010 at 11:15 PM, Max Laier wrote: > On 18.10.2010 20:16, Brandon Gooch wrote: >> >> On Mon, Oct 18, 2010 at 1:10 PM, Ermal Lu=E7i =A0wrote: >>> >>> Hello, >>> >>> the link http://people.freebsd.org/~eri/pf45_1.diff has the patch for >>> pf(4) as of OpenBSD 4.5 version. >>> The patch is against HEAD. >>> After OpenBSD 4.5 the syntax has changed and this is the reason for >>> such an 'old' version patch. >>> >>> After importing this one the work will go on the newest version and >>> decisions on it will than be done. >>> >>> Be aware that this patch has even support for VIMAGE/VNET. >>> It will enable you to run pf(4) with[in] jails+vnets or just vnets >>> themselves with separate rulesets >>> and policies. >>> pfsync(4) can be loaded as a module also with this patch. >>> >>> Feedback is very welcome. >> >> Should this compile against HEAD, because I think we're missing a header= : >> >> brandon@x300:~$ cd /usr/src >> brandon@x300:/usr/src$ patch< =A0~/pf45_1.diff > > $ patch -p0 < ~/pf45_1.diff > >> brandon@x300:/usr/src$ cd /usr/src/sys/modules/pf >> brandon@x300:modules/pf$ sudo make > > Regards, > =A0Max Thanks Max! -Brandon From owner-freebsd-net@FreeBSD.ORG Tue Oct 19 16:48:37 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E861106566C; Tue, 19 Oct 2010 16:48:37 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id D8F418FC18; Tue, 19 Oct 2010 16:48:36 +0000 (UTC) Received: by pxi4 with SMTP id 4so643196pxi.13 for ; Tue, 19 Oct 2010 09:48:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.37.82 with SMTP id w18mr169194qad.377.1287506915444; Tue, 19 Oct 2010 09:48:35 -0700 (PDT) Sender: bschmidt@techwires.net Received: by 10.229.41.198 with HTTP; Tue, 19 Oct 2010 09:48:35 -0700 (PDT) X-Originating-IP: [84.180.214.123] In-Reply-To: <20101016124152.GA95535@FreeBSD.org> References: <4763016D.7060100@janh.de> <201010081944.50287.bschmidt@techwires.net> <20101009060239.GA88618@FreeBSD.org> <201010092046.41551.bschmidt@techwires.net> <20101010072730.GA91527@FreeBSD.org> <20101016124152.GA95535@FreeBSD.org> Date: Tue, 19 Oct 2010 18:48:35 +0200 X-Google-Sender-Auth: NfTN8T1A2255zEwCLkoV_boFq6k Message-ID: From: Bernhard Schmidt To: Alexey Dokuchaev Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: net@freebsd.org Subject: Re: Monitor mode not working for iwi(4) on 7.X X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 16:48:37 -0000 Alexey Dokuchaev : > On Sun, Oct 10, 2010 at 07:27:30AM +0000, Alexey Dokuchaev wrote: >> On Sat, Oct 09, 2010 at 08:46:41PM +0200, Bernhard Schmidt wrote: >> > On Saturday 09 October 2010 08:02:39 Alexey Dokuchaev wrote: >> > > Much better! =A0"airodump-ng iwi0" now sees stations in addition to = APs, >> > > which means it can utilize monitor mode. =A0"ifconfig iwi0 scan" how= ever >> > > does not work after that (and "list scan" returns no results) even i= f I >> > > put adapter back to normal (from promisc and monitor modes) with >> > > ifconfig(8). =A0kldunloading and loading module again fixes the issu= e. >> > >> > Due to enqueueing the scan command in an infinite loop (yeah.. scannin= g >> > returns every frame, that's monitor mode for that device.. *sigh*) we >> > might increment a queue index but never actually dequeueing the comman= d. >> > On 'down' we clear the command queue but not the indices resulting in >> > the cur index not pointing to a filled entry. Attached patch should fi= x >> > that. >> >> It does, thanks! =A0"list scan" gets populated after I -mediaopt monitor >> after scan; module reload is not required anymore. > > Not sure if this is a driver or ifconfig(8) problem, but after I -mediaop= t > monitor, ifconfig(8) still reports it in media line: > > =A0 =A0 =A0 =A0media: IEEE 802.11 Wireless Ethernet autoselect > > However, as I said, scan list gets populated, which suggests ifconfig(8) > is getting something wrong. =A0Doing -mediaopt monitor the second time > "knocks" ifconfig(8) though. I can't reproduce that on my stable/7 setup, neither in 'UP' nor in 'DOWN' state. Can you post the exact command sequence you've used? The output differs though.. # ifconfig iwi0 mediaopt monitor # ifconfig iwi0 up # ifconfig iwi0 | grep media media: IEEE 802.11 Wireless Ethernet autoselect (autoselect ) # ifconfig iwi0 -mediaopt monitor # ifconfig iwi0 | grep media media: IEEE 802.11 Wireless Ethernet autoselect # -- Bernhard From owner-freebsd-net@FreeBSD.ORG Tue Oct 19 18:57:36 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4E631065670 for ; Tue, 19 Oct 2010 18:57:36 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 35E3B8FC1D for ; Tue, 19 Oct 2010 18:57:35 +0000 (UTC) Received: by eydd26 with SMTP id d26so140095eyd.13 for ; Tue, 19 Oct 2010 11:57:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=TURUPlyVaegDrAZEMjgvptuJ68fiCCYW0LQQmW4bSd4=; b=f1AmlC4Ln55jOUM2sbKjgNfMAgxN/n1u9CtOPliMTSSBmK1JvkO1iXtT9l5oc68bWA a7J0rw7qWnm/+yWIEVleIY9i6tVqwj1UA+XYxMzjxu8Rk/4KUqjEcGggUb9Ug0MMZnp7 rTywpUQYkiZxLW9DQL3SWVrKHqQTfnYX6txn4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=xymF7F9jeR7o1kTfwi5eBJfPUDCsw8kU4FT9JrZcxOm31dLElOJfKpFrAPBy/l5TDu roFzVjNUGxolOkBl9f1eg6WhRUg6UVcNgdHXbDi/HC+eePyFW1k436Ox2lz5qG8b8P9U D5zEykdQ7LblXdurxn6/iYduGz4gi8wbY+emA= MIME-Version: 1.0 Received: by 10.216.2.75 with SMTP id 53mr6554225wee.48.1287514654806; Tue, 19 Oct 2010 11:57:34 -0700 (PDT) Received: by 10.216.183.146 with HTTP; Tue, 19 Oct 2010 11:57:34 -0700 (PDT) In-Reply-To: References: Date: Tue, 19 Oct 2010 18:57:34 +0000 Message-ID: From: Paul B Mahol To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: if_ndis: fix for panic with VIMAGE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 18:57:36 -0000 On 10/13/10, Paul B Mahol wrote: > On 10/12/10, Paul B Mahol wrote: >> On 10/11/10, Paul B Mahol wrote: >>> Hi, >>> >>> There is no single valid reason to call rt_ifmsg() in >>> ndis_linksts_done() >>> >>> Patch attached. >>> >> Ping. > Pong. Ping. From owner-freebsd-net@FreeBSD.ORG Tue Oct 19 19:12:14 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 947881065698 for ; Tue, 19 Oct 2010 19:12:14 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 58A288FC0A for ; Tue, 19 Oct 2010 19:12:13 +0000 (UTC) Received: by qyk10 with SMTP id 10so591356qyk.13 for ; Tue, 19 Oct 2010 12:12:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.215.199 with SMTP id hf7mr5321896qab.269.1287515532423; Tue, 19 Oct 2010 12:12:12 -0700 (PDT) Sender: bschmidt@techwires.net Received: by 10.229.41.198 with HTTP; Tue, 19 Oct 2010 12:12:12 -0700 (PDT) X-Originating-IP: [84.180.214.123] In-Reply-To: References: Date: Tue, 19 Oct 2010 21:12:12 +0200 X-Google-Sender-Auth: S9gUckD8xvLiJZ58mWpZNSZ_W8k Message-ID: From: Bernhard Schmidt To: Paul B Mahol Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Net Subject: Re: if_ndis: fix for panic with VIMAGE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 19:12:14 -0000 9, 2010 at 20:57, Paul B Mahol wrote: > On 10/13/10, Paul B Mahol wrote: >> On 10/12/10, Paul B Mahol wrote: >>> On 10/11/10, Paul B Mahol wrote: >>>> Hi, >>>> >>>> There is no single valid reason to call rt_ifmsg() in >>>> ndis_linksts_done() >>>> >>>> Patch attached. >>>> >>> Ping. >> Pong. > Ping. Committed, thanks. -- Bernhard From owner-freebsd-net@FreeBSD.ORG Tue Oct 19 20:57:11 2010 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 597CD106566B for ; Tue, 19 Oct 2010 20:57:11 +0000 (UTC) (envelope-from prt@prt.org) Received: from smtp6.uk.umis.net (smtp6.uk.umis.net [217.65.166.41]) by mx1.freebsd.org (Postfix) with ESMTP id D7ACB8FC1C for ; Tue, 19 Oct 2010 20:57:10 +0000 (UTC) Received: from [109.71.168.158] (helo=emma.local) by smtp6.uk.umis.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1P8Iqo-0003S7-Nh for freebsd-net@freebsd.org; Tue, 19 Oct 2010 20:32:02 +0000 Message-ID: <4CBE0042.4090905@prt.org> Date: Tue, 19 Oct 2010 21:32:02 +0100 From: Paul Thornton User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Problems with 8.1, PPPoE server, and Cisco client X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 20:57:11 -0000 Hi all, I'm hoping that someone can point me in the right direction to get enough debug to troubleshoot a very annoying connection problem with PPPoE to a Cisco. I have a freshly installed 8.1-RELEASE amd64 box with a very simple PPPoE daemon setup on it. This works fine for a test WinXP and Mac OS X client so I know that fundamentally that side of things should be OK. I have also used a similar setup (under 7.0) with all sorts of consumer routers doing PPPoE and it "just works". The server I'm testing with has VLANs on top of igb interfaces, and I haven't seen any other network issues. Using a Cisco 800 series as the client, however, things start off working fine - connects up OK, authenticates, etc. but then it immediately disconnects. There is no clear error as to why the disconnect happens at either end - hence my confusion. I've tried several routers (some direct Ethernet link, some via VDSL) and have upgraded to the latest IOS in an attempt to make this work, nothing changes. Have also tried with 7.2-RELEASE in case it was an 8.X issue - again, same problem seen. Any hints to help debug this (from either end) would be much appreciated. Thanks, Paul. Info follows: FreeBSD vdsl02a 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Tue Oct 19 14:48:21 UTC 2010 root@vdsl01a:/usr/src/sys/amd64/compile/PPPOE-ROUTER-2 amd64 ppp.conf: default: set log Chat Command Phase #turn on some logging. See man ppp.conf enable pap #turn on chap and pap accounting enable chap allow mode direct #turn on ppp bridging disable proxy #turn on ppp proxyarping disable ipv6cp #don't currently support v6 set mru 1492 #set mru below 1500 (PPPoE MTU issue) set mtu 1492 #set mtu below 1500 (PPPoE MTU issue) set timeout 0 enable lqr echo set echoperiod 5 accept dns set dns 217.65.160.42 set radius /etc/ppp/radius.conf set ifaddr 217.65.168.254/32 # access VLAN PPPoE definitions cv1004e: set device PPPoE:vlan1004:test cv1005e: set device PPPoE:vlan1005:test The daemon is running with the following command: > /usr/libexec/pppoed -P /var/run/pppoed-1005.pid -a test -l cv1005e vlan1005 The RADIUS plumbing works as expected, and the router gets past authentication and gets the correct IP address. ppp.log shows: > Oct 19 20:05:33 vdsl02a ppp[2234]: Phase: Using interface: tun0 > Oct 19 20:05:33 vdsl02a ppp[2234]: Phase: deflink: Created in closed state > Oct 19 20:05:33 vdsl02a ppp[2234]: Command: default: enable pap > Oct 19 20:05:33 vdsl02a ppp[2234]: Command: default: enable chap > Oct 19 20:05:33 vdsl02a ppp[2234]: Command: default: disable proxy > Oct 19 20:05:33 vdsl02a ppp[2234]: Command: default: disable ipv6cp > Oct 19 20:05:33 vdsl02a ppp[2234]: Command: default: set mru 1492 > Oct 19 20:05:33 vdsl02a ppp[2234]: Command: default: set mtu 1492 > Oct 19 20:05:33 vdsl02a ppp[2234]: Command: default: set timeout 0 > Oct 19 20:05:33 vdsl02a ppp[2234]: Command: default: enable lqr echo > Oct 19 20:05:33 vdsl02a ppp[2234]: Command: default: set echoperiod 5 > Oct 19 20:05:33 vdsl02a ppp[2234]: Command: default: accept dns > Oct 19 20:05:33 vdsl02a ppp[2234]: Command: default: set dns 217.65.160.42 > Oct 19 20:05:33 vdsl02a ppp[2234]: Command: default: set radius /etc/ppp/radius.conf > Oct 19 20:05:33 vdsl02a ppp[2234]: Command: default: set ifaddr 217.65.168.254/32 > Oct 19 20:05:33 vdsl02a ppp[2234]: Command: cv1005e: set device PPPoE:vlan1005:test > Oct 19 20:05:33 vdsl02a ppp[2234]: Phase: PPP Started (direct mode). > Oct 19 20:05:33 vdsl02a ppp[2234]: Phase: bundle: Establish > Oct 19 20:05:33 vdsl02a ppp[2234]: Phase: deflink: closed -> opening > Oct 19 20:05:33 vdsl02a ppp[2234]: Phase: deflink: Link is a netgraph node > Oct 19 20:05:33 vdsl02a ppp[2234]: Phase: deflink: Connected! > Oct 19 20:05:33 vdsl02a ppp[2234]: Phase: deflink: opening -> carrier > Oct 19 20:05:33 vdsl02a ppp[2234]: Phase: deflink: carrier -> lcp > Oct 19 20:05:33 vdsl02a ppp[2234]: Phase: bundle: Authenticate > Oct 19 20:05:33 vdsl02a ppp[2234]: Phase: deflink: his = none, mine = CHAP 0x05 > Oct 19 20:05:33 vdsl02a ppp[2234]: Phase: Chap Output: CHALLENGE > Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: Chap Output: CHALLENGE > Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: Chap Input: RESPONSE dropped (got id 1, not 2) > Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: Chap Input: RESPONSE (16 bytes from VT123456789@vdsl01) > Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: Radius: Request sent > Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: Radius(auth): ACCEPT received > Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: IP 217.65.167.1 > Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: Route: 217.65.167.64/29 217.65.167.1 1 > Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: MTU 1492 > Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: Netmask 255.255.255.255 > Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: Chap Output: SUCCESS > Oct 19 20:05:36 vdsl02a ppp[2234]: Warning: iface add: ioctl(SIOCAIFADDR, 217.65.168.254 -> 217.65.167.1): File exists > Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: deflink: lcp -> open > Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: bundle: Network > Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: deflink: open -> lcp > Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: bundle: Terminate > Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: deflink: read (0): Got zero bytes > Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: deflink: Disconnected! > Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: deflink: Connect time: 3 secs: 221 octets in, 241 octets out > Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: deflink: 7 packets in, 10 packets out > Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: total 154 bytes/sec, peak 142 bytes/sec on Tue Oct 19 20:05:34 2010 > Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: deflink: lcp -> closed > Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: bundle: Dead > Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: PPP Terminated (normal). And every time the router attempts to reconnect, the same thing is seen. Here is the log from the router's perspective: > *Oct 19 20:19:49.955: Sending PADI: Interface = GigabitEthernet0 > *Oct 19 20:19:49.955: PPPoE 0: I PADO R:d8d3.85c1.5eed L:5475.d038.ca7a Gi0 > *Oct 19 20:19:52.003: PPPOE: we've got our pado and the pado timer went off > *Oct 19 20:19:52.003: OUT PADR from PPPoE Session > *Oct 19 20:19:52.003: PPPoE 48: I PADS R:d8d3.85c1.5eed L:5475.d038.ca7a Gi0 > *Oct 19 20:19:52.003: IN PADS from PPPoE Session > *Oct 19 20:19:52.003: %DIALER-6-BIND: Interface Vi2 bound to profile Di0 > *Oct 19 20:19:52.003: PPPoE: Virtual Access interface obtained. > *Oct 19 20:19:52.003: PPPoE : encap string prepared > *Oct 19 20:19:52.003: [0]PPPoE 48: data path set to PPPoE Client > *Oct 19 20:19:52.007: %LINK-3-UPDOWN: Interface Virtual-Access2, changed state to up > *Oct 19 20:19:52.007: Vi2 PPP: Sending cstate UP notification > *Oct 19 20:19:52.007: Vi2 PPP: Processing CstateUp message > *Oct 19 20:19:52.011: PPP: Alloc Context [857AB7A4] > *Oct 19 20:19:52.011: ppp67 PPP: Phase is ESTABLISHING > *Oct 19 20:19:52.011: Vi2 PPP: Using dialer call direction > *Oct 19 20:19:52.011: Vi2 PPP: Treating connection as a callout > *Oct 19 20:19:52.011: Vi2 PPP: Session handle[91000003] Session id[67] > *Oct 19 20:19:52.011: Vi2 LCP: Event[OPEN] State[Initial to Starting] > *Oct 19 20:19:52.011: Vi2 PPP: No remote authentication for call-out > *Oct 19 20:19:52.011: Vi2 LCP: O CONFREQ [Starting] id 1 len 14 > *Oct 19 20:19:52.011: Vi2 LCP: MRU 1492 (0x010405D4) > *Oct 19 20:19:52.011: Vi2 LCP: MagicNumber 0x950F314C (0x0506950F314C) > *Oct 19 20:19:52.011: Vi2 LCP: Event[UP] State[Starting to REQsent] > *Oct 19 20:19:52.115: Vi2 LCP: I CONFREQ [REQsent] id 1 len 37 > *Oct 19 20:19:52.115: Vi2 LCP: ACFC (0x0802) > *Oct 19 20:19:52.115: Vi2 LCP: PFC (0x0702) > *Oct 19 20:19:52.115: Vi2 LCP: ACCM 0x00000000 (0x020600000000) > *Oct 19 20:19:52.115: Vi2 LCP: MRU 1492 (0x010405D4) > *Oct 19 20:19:52.115: Vi2 LCP: MagicNumber 0xFC1067FE (0x0506FC1067FE) > *Oct 19 20:19:52.115: Vi2 LCP: QualityType 0xC025 period 500 (0x0408C025000001F4) > *Oct 19 20:19:52.115: Vi2 LCP: AuthProto CHAP (0x0305C22305) > *Oct 19 20:19:52.115: Vi2 LCP: O CONFNAK [REQsent] id 1 len 12 > *Oct 19 20:19:52.115: Vi2 LCP: QualityType 0xC025 period 1000 (0x0408C025000003E8) > *Oct 19 20:19:52.115: Vi2 LCP: Event[Receive ConfReq-] State[REQsent to REQsent] > *Oct 19 20:19:52.115: Vi2 LCP: I CONFACK [REQsent] id 1 len 14 > *Oct 19 20:19:52.115: Vi2 LCP: MRU 1492 (0x010405D4) > *Oct 19 20:19:52.115: Vi2 LCP: MagicNumber 0x950F314C (0x0506950F314C) > *Oct 19 20:19:52.115: Vi2 LCP: Event[Receive ConfAck] State[REQsent to ACKrcvd] > *Oct 19 20:19:52.115: Vi2 LCP: I CONFREQ [ACKrcvd] id 2 len 37 > *Oct 19 20:19:52.115: Vi2 LCP: ACFC (0x0802) > *Oct 19 20:19:52.115: Vi2 LCP: PFC (0x0702) > *Oct 19 20:19:52.115: Vi2 LCP: ACCM 0x00000000 (0x020600000000) > *Oct 19 20:19:52.115: Vi2 LCP: MRU 1492 (0x010405D4) > *Oct 19 20:19:52.115: Vi2 LCP: MagicNumber 0xFC1067FE (0x0506FC1067FE) > *Oct 19 20:19:52.115: Vi2 LCP: QualityType 0xC025 period 1000 (0x0408C025000003E8) > *Oct 19 20:19:52.115: Vi2 LCP: AuthProto CHAP (0x0305C22305) > *Oct 19 20:19:52.115: Vi2 LCP: O CONFACK [ACKrcvd] id 2 len 37 > *Oct 19 20:19:52.115: Vi2 LCP: ACFC (0x0802) > *Oct 19 20:19:52.115: Vi2 LCP: PFC (0x0702) > *Oct 19 20:19:52.115: Vi2 LCP: ACCM 0x00000000 (0x020600000000) > *Oct 19 20:19:52.115: Vi2 LCP: MRU 1492 (0x010405D4) > *Oct 19 20:19:52.115: Vi2 LCP: MagicNumber 0xFC1067FE (0x0506FC1067FE) > *Oct 19 20:19:52.115: Vi2 LCP: QualityType 0xC025 period 1000 (0x0408C025000003E8) > *Oct 19 20:19:52.115: Vi2 LCP: AuthProto CHAP (0x0305C22305) > *Oct 19 20:19:52.115: Vi2 LCP: Event[Receive ConfReq+] State[ACKrcvd to Open] > *Oct 19 20:19:52.115: Vi2 LQM: I state Open magic 0xFC1067FE len 48 > *Oct 19 20:19:52.115: Vi2 LQM: LastOutLQRs 0 LastOutPackets/Octets 0/0 > *Oct 19 20:19:52.115: Vi2 LQM: PeerInLQRs 0 PeerInPackets/Discards/Errors/Octets 0/0/0/0 > *Oct 19 20:19:52.115: Vi2 LQM: PeerOutLQRs 1 PeerOutPackets/Octets 4/148 > *Oct 19 20:19:52.115: Vi2 PPP: Queue CHAP code[1] id[1] > *Oct 19 20:19:52.139: Vi2 PPP: Phase is AUTHENTICATING, by the peer > *Oct 19 20:19:52.139: Vi2 CHAP: Redirect packet to Vi2 > *Oct 19 20:19:52.139: Vi2 CHAP: I CHALLENGE id 1 len 21 > *Oct 19 20:19:52.139: Vi2 CHAP: No name received from peer > *Oct 19 20:19:52.139: Vi2 CHAP: Using hostname from interface CHAP > *Oct 19 20:19:52.139: Vi2 CHAP: Using password from interface CHAP > *Oct 19 20:19:52.139: Vi2 CHAP: O RESPONSE id 1 len 46 from "VT123456789@vdsl01" > *Oct 19 20:19:52.139: Vi2 LCP: State is Open > *Oct 19 20:19:52.147: Vi2 CHAP: I SUCCESS id 1 len 13 msg is "Welcome!!" > *Oct 19 20:19:52.147: Vi2 PPP: Phase is FORWARDING, Attempting Forward > *Oct 19 20:19:52.147: Vi2 PPP: Queue CCP code[1] id[1] > *Oct 19 20:19:52.147: Vi2 PPP: Queue IPCP code[1] id[1] > *Oct 19 20:19:52.151: Vi2 PPP DISC: Lower Layer disconnected > *Oct 19 20:19:52.151: Vi2 LCP: O TERMREQ [Open] id 2 len 4 > *Oct 19 20:19:52.151: Vi2 LCP: Event[CLOSE] State[Open to Closing] > *Oct 19 20:19:52.151: Vi2 PPP: Phase is TERMINATING > *Oct 19 20:19:52.151: PPPoE : Shutting down client session > *Oct 19 20:19:52.155: [0]PPPoE 48: O PADT R:d8d3.85c1.5eed L:5475.d038.ca7a Gi0 > *Oct 19 20:19:52.155: PPPoE: Failed to add PPPoE switching subblock > *Oct 19 20:19:52.155: %DIALER-6-UNBIND: Interface Vi2 unbound from profile Di0 > *Oct 19 20:19:52.155: Vi2 PPP: Block vaccess from being freed [0x10] > *Oct 19 20:19:52.155: Vi2 LCP: Event[DOWN] State[Closing to Initial] > *Oct 19 20:19:52.155: Vi2 PPP: Unlocked by [0x10] Still Locked by [0x0] > *Oct 19 20:19:52.155: Vi2 PPP: Free previously blocked vaccess > *Oct 19 20:19:52.155: Vi2 PPP: Phase is DOWN > *Oct 19 20:19:52.155: PPPoE 48: I PADT R:d8d3.85c1.5eed L:5475.d038.ca7a Gi0 > *Oct 19 20:19:52.159: %LINK-3-UPDOWN: Interface Virtual-Access2, changed state to down > *Oct 19 20:19:52.159: PPPoE: Unexpected Event!. PPPoE switching Subblockdestroy called Kernel config has the following additional options: > +options HZ=1000 > +options NETGRAPH > +options NETGRAPH_PPPOE > +options NETGRAPH_SOCKET > + > +options NETGRAPH_CISCO > +options NETGRAPH_ECHO > +options NETGRAPH_FRAME_RELAY > +options NETGRAPH_HOLE > +options NETGRAPH_LMI > +options NETGRAPH_RFC1490 > +options NETGRAPH_TTY > + > +options NETGRAPH_ASYNC > +options NETGRAPH_BPF > +options NETGRAPH_ETHER > +options NETGRAPH_IFACE > +options NETGRAPH_KSOCKET > +options NETGRAPH_L2TP > +options NETGRAPH_MPPC_ENCRYPTION > +options NETGRAPH_PPP > +options NETGRAPH_PPTPGRE > +options NETGRAPH_TEE > +options NETGRAPH_UI > +options NETGRAPH_VJC > + > +options DEVICE_POLLING From owner-freebsd-net@FreeBSD.ORG Tue Oct 19 21:05:24 2010 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 2E2C110656A4 for ; Tue, 19 Oct 2010 21:05:24 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (out-0-23.mx.aerioconnect.net [216.240.47.83]) by mx1.freebsd.org (Postfix) with ESMTP id 118088FC12 for ; Tue, 19 Oct 2010 21:05:23 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id o9JL5M47024410; Tue, 19 Oct 2010 14:05:22 -0700 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 2A82D2D601F; Tue, 19 Oct 2010 14:05:21 -0700 (PDT) Message-ID: <4CBE0846.1090203@freebsd.org> Date: Tue, 19 Oct 2010 14:06:14 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Paul Thornton References: <4CBE0042.4090905@prt.org> In-Reply-To: <4CBE0042.4090905@prt.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: freebsd-net@freebsd.org Subject: Re: Problems with 8.1, PPPoE server, and Cisco client X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 21:05:24 -0000 On 10/19/10 1:32 PM, Paul Thornton wrote: > > Hi all, > > I'm hoping that someone can point me in the right direction to get > enough debug to troubleshoot a very annoying connection problem with > PPPoE to a Cisco. > > I have a freshly installed 8.1-RELEASE amd64 box with a very simple > PPPoE daemon setup on it. This works fine for a test WinXP and Mac OS X > client so I know that fundamentally that side of things should be OK. I > have also used a similar setup (under 7.0) with all sorts of consumer > routers doing PPPoE and it "just works". The server I'm testing with > has VLANs on top of igb interfaces, and I haven't seen any other network > issues. > > Using a Cisco 800 series as the client, however, things start off > working fine - connects up OK, authenticates, etc. but then it > immediately disconnects. > There is no clear error as to why the disconnect happens at either end - > hence my confusion. I've tried several routers (some direct Ethernet > link, some via VDSL) and have upgraded to the latest IOS in an attempt > to make this work, nothing changes. > > Have also tried with 7.2-RELEASE in case it was an 8.X issue - again, > same problem seen. > > Any hints to help debug this (from either end) would be much appreciated. > > Thanks, > > Paul. Immediate things to look at: Wireshark understands all the protocols in question so get packet captures of good and bad sessions (as similar as you can) and see what is different. (wireshark reads tcpdump files so it's easy to capture). also for fun you might look at the documentation for running mpd.. I dont' remember if it can do a pppoe SERVER but I vaguely remember that it can. > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Tue Oct 19 21:30:08 2010 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 A26EC106566C for ; Tue, 19 Oct 2010 21:30:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 210A68FC17 for ; Tue, 19 Oct 2010 21:30:08 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 9012C41C65E; Tue, 19 Oct 2010 23:30:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id tvWf16fjBQ4z; Tue, 19 Oct 2010 23:30:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id AC56741C650; Tue, 19 Oct 2010 23:30:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 5A9734448F3; Tue, 19 Oct 2010 21:29:50 +0000 (UTC) Date: Tue, 19 Oct 2010 21:29:49 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Paul Thornton In-Reply-To: <4CBE0042.4090905@prt.org> Message-ID: <20101019212508.E46881@maildrop.int.zabbadoz.net> References: <4CBE0042.4090905@prt.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: Problems with 8.1, PPPoE server, and Cisco client X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 21:30:08 -0000 On Tue, 19 Oct 2010, Paul Thornton wrote: > default: > set log Chat Command Phase #turn on some logging. See man ppp.conf increase the log level for your test. According to the Cisco debug log the O(ther), which would be the FreeBSD to my understanding, sends a TERMREQ and closes the connection. >> Oct 19 20:05:36 vdsl02a ppp[2234]: Warning: iface add: ioctl(SIOCAIFADDR, 217.65.168.254 -> 217.65.167.1): File exists Not sure why that happens. >> Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: deflink: lcp -> open >> Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: bundle: Network >> Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: deflink: open -> lcp >> Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: bundle: Terminate And here it goes but the missing, probably lcp, information is missing in the log due to our log level. >> *Oct 19 20:19:52.139: Vi2 LCP: State is Open >> *Oct 19 20:19:52.147: Vi2 CHAP: I SUCCESS id 1 len 13 msg is "Welcome!!" >> *Oct 19 20:19:52.147: Vi2 PPP: Phase is FORWARDING, Attempting Forward >> *Oct 19 20:19:52.147: Vi2 PPP: Queue CCP code[1] id[1] >> *Oct 19 20:19:52.147: Vi2 PPP: Queue IPCP code[1] id[1] >> *Oct 19 20:19:52.151: Vi2 PPP DISC: Lower Layer disconnected >> *Oct 19 20:19:52.151: Vi2 LCP: O TERMREQ [Open] id 2 len 4 And here it goes away. And thanks to Cisco you cannot say why either here. The line above could be a hint if you can find it but ... /bz -- Bjoern A. Zeeb Welcome a new stage of life. From owner-freebsd-net@FreeBSD.ORG Tue Oct 19 21:53:07 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC02F106564A for ; Tue, 19 Oct 2010 21:53:07 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 71E608FC16 for ; Tue, 19 Oct 2010 21:53:07 +0000 (UTC) Received: by ewy21 with SMTP id 21so2135924ewy.13 for ; Tue, 19 Oct 2010 14:53:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=rNSTCfEz1Ov4rZg8TvZxJnjj5BCA6Q8yXOEc0Ggjgi0=; b=makUtbXqK0dcDuAC2pxbfbf5qlAwZ3uzpFcK5zcBWn7sHqgdcYxAbo44rQ1wQmky9j cz7lY4Mn4Hkr/0EJgUPkfugHkmVAgI8cpeHh2OuDhwbx8Qm83ax27bELyjMHkdA1eNcK pU+BY3jz79qa2aSu0EW/ydAIsGYpYjJrJ977c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=uiVj7BPZydmfJxjPlcio3KVLgDvbd6fllocJ6FOXcaOzImv5taKANfOrbA9KKljWe3 4TFIH+27i+yTLCisCSO+qAVhOqYCaDDb/6ONb1WQ0kaug2ieBqr3hL9S9diFKejx0Cdk KRxjnfAzQKq+ZB2WC3YC5DOveGfmhcS7/aAwk= MIME-Version: 1.0 Received: by 10.216.50.18 with SMTP id y18mr7246015web.113.1287525184813; Tue, 19 Oct 2010 14:53:04 -0700 (PDT) Received: by 10.216.183.146 with HTTP; Tue, 19 Oct 2010 14:53:04 -0700 (PDT) Date: Tue, 19 Oct 2010 21:53:04 +0000 Message-ID: From: Paul B Mahol To: net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: ndis: patch for review X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 21:53:07 -0000 Hi, First: we should pin curthread on CPU before we check on which CPU is curthread. Second: instead of sti & cli use critical sections when saving %fs register. Third: I do not know what happens if we get preempted while windows code were running, so leave critical section only _after_ executing windows code. diff --git a/sys/compat/ndis/kern_windrv.c b/sys/compat/ndis/kern_windrv.c index f231863..ba29fd2 100644 --- a/sys/compat/ndis/kern_windrv.c +++ b/sys/compat/ndis/kern_windrv.c @@ -613,8 +613,6 @@ struct gdt { extern uint16_t x86_getfs(void); extern void x86_setfs(uint16_t); extern void *x86_gettid(void); -extern void x86_critical_enter(void); -extern void x86_critical_exit(void); extern void x86_getldt(struct gdt *, uint16_t *); extern void x86_setldt(struct gdt *, uint16_t); @@ -668,8 +666,10 @@ extern void x86_setldt(struct gdt *, uint16_t); void ctxsw_utow(void) { - struct tid *t; + struct tid *t; + sched_pin(); + critical_enter(); t = &my_tids[curthread->td_oncpu]; /* @@ -685,12 +685,9 @@ ctxsw_utow(void) if (t->tid_self != t) x86_newldt(NULL); - x86_critical_enter(); t->tid_oldfs = x86_getfs(); t->tid_cpu = curthread->td_oncpu; - sched_pin(); x86_setfs(SEL_TO_FS(t->tid_selector)); - x86_critical_exit(); /* Now entering Windows land, population: you. */ } @@ -706,11 +703,10 @@ ctxsw_wtou(void) { struct tid *t; - x86_critical_enter(); t = x86_gettid(); x86_setfs(t->tid_oldfs); + critical_exit(); sched_unpin(); - x86_critical_exit(); /* Welcome back to UNIX land, we missed you. */ diff --git a/sys/compat/ndis/winx32_wrap.S b/sys/compat/ndis/winx32_wrap.S index c051504..fa4aa87 100644 --- a/sys/compat/ndis/winx32_wrap.S +++ b/sys/compat/ndis/winx32_wrap.S @@ -375,11 +375,3 @@ ENTRY(x86_setfs) ENTRY(x86_gettid) mov %fs:12,%eax ret - -ENTRY(x86_critical_enter) - cli - ret - -ENTRY(x86_critical_exit) - sti - ret From owner-freebsd-net@FreeBSD.ORG Tue Oct 19 22:39:31 2010 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 4B6C31065670 for ; Tue, 19 Oct 2010 22:39:31 +0000 (UTC) (envelope-from alireza.torabi@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id F26608FC08 for ; Tue, 19 Oct 2010 22:39:30 +0000 (UTC) Received: by qyk10 with SMTP id 10so766938qyk.13 for ; Tue, 19 Oct 2010 15:39:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=NsCtpR5BS6KahjdcdX9xeFE5EYX80nCFeaKtMVOPkYg=; b=VKdKsiw+nRGHbAdiSOGVBNeSNyAWK1bpwWxG+6ksQHhw0HthkQ8Qc6b+Rkh27rgJGR 0peciinMBdz/V2+VMOLhP7RPsuAtAgHSL/LFlb/NgThPCpQwUk0dahAW+TCPRHQnjYh9 L5vKGQA5hR6W3UNGfmXYWInAo9qrSfds3Pezg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=bEQsUUXOGNWs/2tQFDfSW9t6pPbF2mwCcJtbnZhPc9PnDMbtZ3X66ntx40armeMb9z QA8KlwmXFxX8qMzvStRfCQOQcnRjtfJKaRBUGyvN3sxrMsG9+r2kfptnz8dzkDaRzxL4 UZIjal9+iZvPnb0uJg/z4g95MnbpxPklFv3JE= MIME-Version: 1.0 Received: by 10.229.223.210 with SMTP id il18mr5684567qcb.133.1287526236273; Tue, 19 Oct 2010 15:10:36 -0700 (PDT) Received: by 10.229.11.143 with HTTP; Tue, 19 Oct 2010 15:10:36 -0700 (PDT) In-Reply-To: <20101019212508.E46881@maildrop.int.zabbadoz.net> References: <4CBE0042.4090905@prt.org> <20101019212508.E46881@maildrop.int.zabbadoz.net> Date: Tue, 19 Oct 2010 23:10:36 +0100 Message-ID: From: Alireza Torabi To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: Problems with 8.1, PPPoE server, and Cisco client X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 22:39:31 -0000 Just out of interest, Could you post the relevant Cisco configs. On 10/19/10, Bjoern A. Zeeb wrote: > On Tue, 19 Oct 2010, Paul Thornton wrote: > >> default: >> set log Chat Command Phase #turn on some logging. See man ppp.conf > > increase the log level for your test. According to the Cisco debug > log the O(ther), which would be the FreeBSD to my understanding, sends > a TERMREQ and closes the connection. > > >>> Oct 19 20:05:36 vdsl02a ppp[2234]: Warning: iface add: ioctl(SIOCAIFADDR, >>> 217.65.168.254 -> 217.65.167.1): File exists > > Not sure why that happens. > >>> Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: deflink: lcp -> open >>> Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: bundle: Network >>> Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: deflink: open -> lcp >>> Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: bundle: Terminate > > And here it goes but the missing, probably lcp, information is > missing in the log due to our log level. > > >>> *Oct 19 20:19:52.139: Vi2 LCP: State is Open >>> *Oct 19 20:19:52.147: Vi2 CHAP: I SUCCESS id 1 len 13 msg is "Welcome!!" >>> *Oct 19 20:19:52.147: Vi2 PPP: Phase is FORWARDING, Attempting Forward >>> *Oct 19 20:19:52.147: Vi2 PPP: Queue CCP code[1] id[1] >>> *Oct 19 20:19:52.147: Vi2 PPP: Queue IPCP code[1] id[1] >>> *Oct 19 20:19:52.151: Vi2 PPP DISC: Lower Layer disconnected >>> *Oct 19 20:19:52.151: Vi2 LCP: O TERMREQ [Open] id 2 len 4 > > And here it goes away. And thanks to Cisco you cannot say why either > here. The line above could be a hint if you can find it but ... > > /bz > > -- > Bjoern A. Zeeb Welcome a new stage of life. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Wed Oct 20 05:19:49 2010 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 913D0106566B for ; Wed, 20 Oct 2010 05:19:49 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id DAD9F8FC13 for ; Wed, 20 Oct 2010 05:19:48 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id o9K56OHi098293; Wed, 20 Oct 2010 16:06:24 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Wed, 20 Oct 2010 16:06:24 +1100 (EST) From: Ian Smith To: Paul Thornton In-Reply-To: <4CBE0042.4090905@prt.org> Message-ID: <20101020153635.A9562@sola.nimnet.asn.au> References: <4CBE0042.4090905@prt.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net@freebsd.org Subject: Re: Problems with 8.1, PPPoE server, and Cisco client X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 05:19:49 -0000 On Tue, 19 Oct 2010, Paul Thornton wrote: > I'm hoping that someone can point me in the right direction to get > enough debug to troubleshoot a very annoying connection problem with > PPPoE to a Cisco. > > I have a freshly installed 8.1-RELEASE amd64 box with a very simple > PPPoE daemon setup on it. This works fine for a test WinXP and Mac OS X > client so I know that fundamentally that side of things should be OK. I > have also used a similar setup (under 7.0) with all sorts of consumer > routers doing PPPoE and it "just works". The server I'm testing with > has VLANs on top of igb interfaces, and I haven't seen any other network > issues. > > Using a Cisco 800 series as the client, however, things start off > working fine - connects up OK, authenticates, etc. but then it > immediately disconnects. > There is no clear error as to why the disconnect happens at either end - > hence my confusion. I've tried several routers (some direct Ethernet > link, some via VDSL) and have upgraded to the latest IOS in an attempt > to make this work, nothing changes. > > Have also tried with 7.2-RELEASE in case it was an 8.X issue - again, > same problem seen. > > Any hints to help debug this (from either end) would be much appreciated. Just to add to what Julian and Bjoern said .. something about addressing / routing looks maybe odd to me, without knowing your network setup or much at all about vlans. Adding both lcp and ipcp to ppp logging should confirm success (or indicate problems) at those levels. > set ifaddr 217.65.168.254/32 > > Oct 19 20:05:33 vdsl02a ppp[2234]: Command: default: set ifaddr 217.65.168.254/32 > > Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: IP 217.65.167.1 > > Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: Route: 217.65.167.64/29 217.65.167.1 1 Does that all look right? > > Oct 19 20:05:36 vdsl02a ppp[2234]: Warning: iface add: ioctl(SIOCAIFADDR, 217.65.168.254 -> 217.65.167.1): File exists >From memory, 'File exists' means more like 'route exists' > > Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: deflink: open -> lcp > > Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: bundle: Terminate Bang. > And every time the router attempts to reconnect, the same thing is seen. > > Here is the log from the router's perspective: Maybe add IPCP logging on the Cisco too? No addressing info shown here. > > *Oct 19 20:19:52.139: Vi2 LCP: State is Open > > *Oct 19 20:19:52.147: Vi2 CHAP: I SUCCESS id 1 len 13 msg is "Welcome!!" > > *Oct 19 20:19:52.147: Vi2 PPP: Phase is FORWARDING, Attempting Forward > > *Oct 19 20:19:52.147: Vi2 PPP: Queue CCP code[1] id[1] > > *Oct 19 20:19:52.147: Vi2 PPP: Queue IPCP code[1] id[1] > > *Oct 19 20:19:52.151: Vi2 PPP DISC: Lower Layer disconnected > > *Oct 19 20:19:52.151: Vi2 LCP: O TERMREQ [Open] id 2 len 4 > > *Oct 19 20:19:52.151: Vi2 LCP: Event[CLOSE] State[Open to Closing] > > *Oct 19 20:19:52.151: Vi2 PPP: Phase is TERMINATING Definitely looks like LCP, but that could come from IPCP layer .. I've been using mpd for so long I hardly remember ppp logging. Just another stab in the dark, Ian From owner-freebsd-net@FreeBSD.ORG Wed Oct 20 06:46:08 2010 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 D5AAD106564A for ; Wed, 20 Oct 2010 06:46:08 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (out-0-32.mx.aerioconnect.net [216.240.47.92]) by mx1.freebsd.org (Postfix) with ESMTP id B6F2F8FC19 for ; Wed, 20 Oct 2010 06:46:08 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id o9K6k7J9020816; Tue, 19 Oct 2010 23:46:07 -0700 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id CE4E02D601B; Tue, 19 Oct 2010 23:46:06 -0700 (PDT) Message-ID: <4CBE9063.2030808@freebsd.org> Date: Tue, 19 Oct 2010 23:46:59 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Ian Smith References: <4CBE0042.4090905@prt.org> <20101020153635.A9562@sola.nimnet.asn.au> In-Reply-To: <20101020153635.A9562@sola.nimnet.asn.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: freebsd-net@freebsd.org, Paul Thornton Subject: Re: Problems with 8.1, PPPoE server, and Cisco client X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 06:46:08 -0000 On 10/19/10 10:06 PM, Ian Smith wrote: > On Tue, 19 Oct 2010, Paul Thornton wrote: > > > > > > Oct 19 20:05:36 vdsl02a ppp[2234]: Warning: iface add: ioctl(SIOCAIFADDR, 217.65.168.254 -> 217.65.167.1): File exists > > > From memory, 'File exists' means more like 'route exists' yes in 8.x the routing code changed somewhat. it is possible it is trying to put in a route that we now already put in automatically. > > > Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: deflink: open -> lcp > > > Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: bundle From owner-freebsd-net@FreeBSD.ORG Wed Oct 20 08:31:57 2010 Return-Path: Delivered-To: net@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1033) id 0ED6B1065674; Wed, 20 Oct 2010 08:31:57 +0000 (UTC) Date: Wed, 20 Oct 2010 08:31:57 +0000 From: Alexey Dokuchaev To: Bernhard Schmidt Message-ID: <20101020083156.GA57472@FreeBSD.org> References: <4763016D.7060100@janh.de> <201010081944.50287.bschmidt@techwires.net> <20101009060239.GA88618@FreeBSD.org> <201010092046.41551.bschmidt@techwires.net> <20101010072730.GA91527@FreeBSD.org> <20101016124152.GA95535@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: net@freebsd.org Subject: Re: Monitor mode not working for iwi(4) on 7.X X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 08:31:57 -0000 On Tue, Oct 19, 2010 Bernhard Schmidt wrote: > Alexey Dokuchaev wrote: > > Not sure if this is a driver or ifconfig(8) problem, but after I -mediaopt > > monitor, ifconfig(8) still reports it in media line: > > > > media: IEEE 802.11 Wireless Ethernet autoselect > > > > However, as I said, scan list gets populated, which suggests ifconfig(8) > > is getting something wrong. Doing -mediaopt monitor the second time > > "knocks" ifconfig(8) though. > > I can't reproduce that on my stable/7 setup, neither in 'UP' nor in 'DOWN' > state. Can you post the exact command sequence you've used? The output > differs though.. > > # ifconfig iwi0 mediaopt monitor > # ifconfig iwi0 up > # ifconfig iwi0 | grep media > media: IEEE 802.11 Wireless Ethernet autoselect (autoselect ) > # ifconfig iwi0 -mediaopt monitor > # ifconfig iwi0 | grep media > media: IEEE 802.11 Wireless Ethernet autoselect This scenario works. But try it out after aircrack-ng tools, which set (P)PROMISC mode on the card (and do not clear it after exit, but in my understanding this should not affect monitor mode and its indication, no?). ./danfe From owner-freebsd-net@FreeBSD.ORG Wed Oct 20 10:58:31 2010 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 5C1311065693 for ; Wed, 20 Oct 2010 10:58:31 +0000 (UTC) (envelope-from nr1c0re@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 1201E8FC18 for ; Wed, 20 Oct 2010 10:58:30 +0000 (UTC) Received: by qyk10 with SMTP id 10so1248704qyk.13 for ; Wed, 20 Oct 2010 03:58:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=ImYRfAc5PCTUcvLC9OPrBzsVBI6pvdDo8W/T8hyh0qo=; b=k8Vi8bP6K38pWWpbjg6sx/XZlxxxP9m19K3g9qKLgFv/2nKUG2yeRP3mNyG6CKmZRL fVPystrDIlHR1uFq1spGyM0o5sWVha/gBpIVTyb8BFZEB+EqAZSHBkKSnF1M/ZY8AD8P fbhO1a1HBfR1NpQLFMqTHJ+GCsaPlyG8F5QcU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=EaVSrz7icORmXEdXLFRMbOqO3kMrlscvqxfsAGeIcmeMEZFTK17oXnbjhwe+agMd02 5zMBQxdm89ShLMAMl/JmiXTwuijDypUk0r6ZIFk4vw+4N4Ckb607yv/SfjXt6QFq9QV4 UbW9j3d/bAQ0KUgCcPxIrksTwpbc3MaYY761U= MIME-Version: 1.0 Received: by 10.229.95.73 with SMTP id c9mr6321794qcn.111.1287572309829; Wed, 20 Oct 2010 03:58:29 -0700 (PDT) Received: by 10.229.238.82 with HTTP; Wed, 20 Oct 2010 03:58:29 -0700 (PDT) Date: Wed, 20 Oct 2010 14:58:29 +0400 Message-ID: From: c0re To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: carp and arp_rtrequest: bad gateway 1.1.1.5 (!AF_LINK) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 10:58:31 -0000 I got 2 servers with CARP enabled. One is MASTER, second - BACKUP. CARP is for HA of running some service on that servers. All works fine, but today I've got interesting case: Service was not responding for 5 minutes. Can't tell more details because it was said by not IT guy. Okay, I went to check logs on master and backup servers. All was fine except dmesg and messages: Master server has no recored in messages for about 1 hour. But on slave server I saw that: Oct 20 12:15:00 carp-backup kernel: arp_rtrequest: bad gateway 1.1.1.5 (!AF_LINK) Oct 20 12:15:00 carp-backup kernel: arp_rtrequest: bad gateway 1.1.1.6 (!AF_LINK) Oct 20 12:15:00 carp-backup kernel: arp_rtrequest: bad gateway 1.1.1.9 (!AF_LINK) .................. Oct 20 12:49:58 carp-backup kernel: arp_rtrequest: bad gateway 1.1.1.5 (!AF_LINK) Oct 20 12:49:58 carp-backup kernel: arp_rtrequest: bad gateway 1.1.1.6 (!AF_LINK) Oct 20 12:49:58 carp-backup kernel: arp_rtrequest: bad gateway 1.1.1.9 (!AF_LINK) Total about 300 records. Can anyone comment something about it? What was that? Backup server was loosing connectivity with Master server? In sysctl.conf I've got only net.inet.carp.preempt=1.Now I tuned log to net.inet.carp.log=2. This should log carp info messages. Am I right about loosing connectivity between master-backup servers or there can be another reason? From owner-freebsd-net@FreeBSD.ORG Wed Oct 20 14:23:25 2010 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 12FD91065670 for ; Wed, 20 Oct 2010 14:23:25 +0000 (UTC) (envelope-from prt@prt.org) Received: from smtp6.uk.umis.net (smtp6.uk.umis.net [217.65.166.41]) by mx1.freebsd.org (Postfix) with ESMTP id B5B4D8FC0C for ; Wed, 20 Oct 2010 14:23:24 +0000 (UTC) Received: from [109.71.168.158] (helo=emma.local) by smtp6.uk.umis.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1P8ZZa-0005hc-Ho for freebsd-net@freebsd.org; Wed, 20 Oct 2010 14:23:22 +0000 Message-ID: <4CBEFB5A.80704@prt.org> Date: Wed, 20 Oct 2010 15:23:22 +0100 From: Paul Thornton User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4CBE0042.4090905@prt.org> <4CBE0846.1090203@freebsd.org> In-Reply-To: <4CBE0846.1090203@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: Problems with 8.1, PPPoE server, and Cisco client X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 14:23:25 -0000 Hi, On 19/10/2010 22:06, Julian Elischer wrote: > Wireshark understands all the protocols in question so get packet > captures of good and > bad sessions (as similar as you can) and see what is different. > (wireshark reads > tcpdump files so it's easy to capture). As is often the case, the packets on the wire start telling the story of what is happening... still not sure about the why, but progress is being made. Thanks for that nudge. With a Windows XP client (I know, it was nearby though) the following things happen: Server -> Client PPP CHAP Success (Welcome!! message). Server -> Client PPP CCP config request Server -> Client IPCP Config request (setting IP address of server end) Client -> Server PPP CCP config request - and they carry on here working fine - With the Cisco client, things break at this point: Server -> Client PPP CHAP Success (Welcome!! message). Server -> Client PPP CCP Config request Server -> Client IPCP Config Request (setting IP address of server end) Client -> Server Termination request Server -> Client Termination ack So either that CCP request or the IPCP request is upsetting the Cisco. However, even with its debugging fully on for PPP, it isn't clear why. Initially, my server was requesting deflate compression and VJ compression - so I disabled all compression options in ppp.conf but it made no difference. The tcpdumps were taken after compression was disabled. The cisco config being used on the WAN interface and Dialer interface for testing is as follows. This is an 891 and so is an Ethernet WAN port (no VDSL or other cable interface to add problems): interface GigabitEthernet0 no ip address ip accounting output-packets duplex auto speed auto pppoe enable group global pppoe-client dial-pool-number 1 ! interface Dialer0 description PPPoE dialer mtu 1492 ip address negotiated no ip redirects no ip proxy-arp ip accounting output-packets encapsulation ppp ip tcp adjust-mss 1452 dialer pool 1 dialer-group 1 ppp mtu adaptive ppp authentication chap callin optional ppp chap hostname VT123456789@vdsl01 ppp chap password 0 LetMeIn123 ! ! ip route 0.0.0.0 0.0.0.0 Dialer0 ! dialer-list 1 protocol ip permit ! In terms of the routing, the route being added as a result of the Framed-Route radius attribute does have the correct syntax. For some reason, it had failed to add the /29 route to the routing table in my logs taken yesterday - although that now works fine. That may still be a potential issue but I don't think it is relevant now. To describe what addresses are what (and two of these have changed since yesterday as I was using some that were already occasionally used elsewhere on the network): WAN IP address of router: 217.65.167.128 /32 - set by RADIUS Framed-IP-Address value. LAN subnet of router: 217.65.167.160 /29 - set by RADIUS Framed-Route value. Router's LAN interface has 217.65.167.161/29. IP address of PPPoE server's end of PPP link: 217.65.168.254 VLAN 1005 is just the access side; it has the clients attached to it and has no IP address. Everything happening on there is PPPoE only. The server has another interface which is network side that carries traffic to and from the rest of the world. > also for fun you might look at the documentation for running mpd.. I > dont' remember if it > can do a pppoe SERVER but I vaguely remember that it can. I did once try mpd in the past - I remember it being hard to find any decent documentation for it; especially around PPPoE as a server. It looks very flexible as an option so I may have another crack at it if I can't make the standard ppp work. Does anyone know of any good howto for mpd and pppoe servers? My google skills have lacked severely so far. Here is part of the tcpdump with the XP client, starting at the CHAP success message. I've included quite a lot as there seems to be something going on with IPCP and setting DNS addresses - is this normal? (address ending 5e:ed is the server): > 14:40:27.733755 d8:d3:85:c1:5e:ed > 18:a9:05:db:8e:5c, ethertype PPPoE S (0x8864), length 35: PPPoE [ses 0x20] CHAP (0xc223), length 15: CHAP, Success (0x03), id 1, Msg Welcome!! > 14:40:27.733764 d8:d3:85:c1:5e:ed > 18:a9:05:db:8e:5c, ethertype PPPoE S (0x8864), length 26: PPPoE [ses 0x20] unknown (0x80fd), length 6: unknown ctrl-proto (0x80fd), Conf-Request (0x01), id 1, length 6 > 14:40:27.733770 d8:d3:85:c1:5e:ed > 18:a9:05:db:8e:5c, ethertype PPPoE S (0x8864), length 32: PPPoE [ses 0x20] IPCP (0x8021), length 12: IPCP, Conf-Request (0x01), id 1, length 12 > encoded length 10 (=Option(s) length 6) > 0x0000: 8021 0101 000a > IP-Addr Option (0x03), length 6: 217.65.168.254 > 0x0000: d941 a8fe > 14:40:27.741765 18:a9:05:db:8e:5c > d8:d3:85:c1:5e:ed, ethertype PPPoE S (0x8864), length 60: PPPoE [ses 0x20] unknown (0x80fd), length 12: unknown ctrl-proto (0x80fd), Conf-Request (0x01), id 6, length 12 > encoded length 10 (=Option(s) length 6) > 0x0000: 80fd 0106 000a > MPPC Option (0x12), length 6: > 0x0000: 0000 0001 > 14:40:27.741834 d8:d3:85:c1:5e:ed > 18:a9:05:db:8e:5c, ethertype PPPoE S (0x8864), length 32: PPPoE [ses 0x20] unknown (0x80fd), length 12: unknown ctrl-proto (0x80fd), Conf-Reject (0x04), id 6, length 12 > encoded length 10 (=Option(s) length 6) > 0x0000: 80fd 0406 000a > MPPC Option (0x12), length 6: > 0x0000: 0000 0001 > 14:40:27.741992 18:a9:05:db:8e:5c > d8:d3:85:c1:5e:ed, ethertype PPPoE S (0x8864), length 60: PPPoE [ses 0x20] IPCP (0x8021), length 36: IPCP, Conf-Request (0x01), id 7, length 36 > encoded length 34 (=Option(s) length 30) > 0x0000: 8021 0107 0022 > IP-Addr Option (0x03), length 6: 0.0.0.0 > 0x0000: 0000 0000 > Pri-DNS Option (0x81), length 6: 0.0.0.0 > 0x0000: 0000 0000 > Pri-NBNS Option (0x82), length 6: 0.0.0.0 > 0x0000: 0000 0000 > Sec-DNS Option (0x83), length 6: 0.0.0.0 > 0x0000: 0000 0000 > Sec-NBNS Option (0x84), length 6: 0.0.0.0 > 0x0000: 0000 0000 > 14:40:27.742107 d8:d3:85:c1:5e:ed > 18:a9:05:db:8e:5c, ethertype PPPoE S (0x8864), length 38: PPPoE [ses 0x20] IPCP (0x8021), length 18: IPCP, Conf-Reject (0x04), id 7, length 18 > encoded length 16 (=Option(s) length 12) > 0x0000: 8021 0407 0010 > Pri-NBNS Option (0x82), length 6: 0.0.0.0 > 0x0000: 0000 0000 > Sec-NBNS Option (0x84), length 6: 0.0.0.0 > 0x0000: 0000 0000 > 14:40:27.742343 18:a9:05:db:8e:5c > d8:d3:85:c1:5e:ed, ethertype PPPoE S (0x8864), length 60: PPPoE [ses 0x20] unknown (0x80fd), length 6: unknown ctrl-proto (0x80fd), Conf-Ack (0x02), id 1, length 6 > 14:40:27.742559 18:a9:05:db:8e:5c > d8:d3:85:c1:5e:ed, ethertype PPPoE S (0x8864), length 60: PPPoE [ses 0x20] IPCP (0x8021), length 12: IPCP, Conf-Ack (0x02), id 1, length 12 > encoded length 10 (=Option(s) length 6) > 0x0000: 8021 0201 000a > IP-Addr Option (0x03), length 6: 217.65.168.254 > 0x0000: d941 a8fe > 14:40:27.756103 18:a9:05:db:8e:5c > d8:d3:85:c1:5e:ed, ethertype PPPoE S (0x8864), length 60: PPPoE [ses 0x20] unknown (0x80fd), length 18: unknown ctrl-proto (0x80fd), Term-Request (0x05), id 8, length 18 > encoded length 16 (=Option(s) length 12) > 0x0000: 80fd 0508 0010 > 14:40:27.756150 d8:d3:85:c1:5e:ed > 18:a9:05:db:8e:5c, ethertype PPPoE S (0x8864), length 26: PPPoE [ses 0x20] unknown (0x80fd), length 6: unknown ctrl-proto (0x80fd), Term-Ack (0x06), id 8, length 6 > 14:40:27.756230 18:a9:05:db:8e:5c > d8:d3:85:c1:5e:ed, ethertype PPPoE S (0x8864), length 60: PPPoE [ses 0x20] IPCP (0x8021), length 24: IPCP, Conf-Request (0x01), id 9, length 24 > encoded length 22 (=Option(s) length 18) > 0x0000: 8021 0109 0016 > IP-Addr Option (0x03), length 6: 0.0.0.0 > 0x0000: 0000 0000 > Pri-DNS Option (0x81), length 6: 0.0.0.0 > 0x0000: 0000 0000 > Sec-DNS Option (0x83), length 6: 0.0.0.0 > 0x0000: 0000 0000 > 14:40:27.756316 d8:d3:85:c1:5e:ed > 18:a9:05:db:8e:5c, ethertype PPPoE S (0x8864), length 44: PPPoE [ses 0x20] IPCP (0x8021), length 24: IPCP, Conf-Nack (0x03), id 9, length 24 > encoded length 22 (=Option(s) length 18) > 0x0000: 8021 0309 0016 > IP-Addr Option (0x03), length 6: 217.65.167.128 > 0x0000: d941 a780 > Pri-DNS Option (0x81), length 6: 217.65.160.42 > 0x0000: d941 a02a > Sec-DNS Option (0x83), length 6: 255.255.255.255 > 0x0000: ffff ffff > 14:40:27.771794 18:a9:05:db:8e:5c > d8:d3:85:c1:5e:ed, ethertype PPPoE S (0x8864), length 60: PPPoE [ses 0x20] IPCP (0x8021), length 24: IPCP, Conf-Request (0x01), id 10, length 24 > encoded length 22 (=Option(s) length 18) > 0x0000: 8021 010a 0016 > IP-Addr Option (0x03), length 6: 217.65.167.128 > 0x0000: d941 a780 > Pri-DNS Option (0x81), length 6: 217.65.160.42 > 0x0000: d941 a02a > Sec-DNS Option (0x83), length 6: 255.255.255.255 > 0x0000: ffff ffff > 14:40:27.779058 d8:d3:85:c1:5e:ed > 18:a9:05:db:8e:5c, ethertype PPPoE S (0x8864), length 44: PPPoE [ses 0x20] IPCP (0x8021), length 24: IPCP, Conf-Ack (0x02), id 10, length 24 > encoded length 22 (=Option(s) length 18) > 0x0000: 8021 020a 0016 > IP-Addr Option (0x03), length 6: 217.65.167.128 > 0x0000: d941 a780 > Pri-DNS Option (0x81), length 6: 217.65.160.42 > 0x0000: d941 a02a > Sec-DNS Option (0x83), length 6: 255.255.255.255 > 0x0000: ffff ffff And here is the similar section from the Cisco router, it all goes downhill quickly (address ending 5e:ed is the server): > 14:59:44.053482 d8:d3:85:c1:5e:ed > 54:75:d0:38:ca:7a, ethertype PPPoE S (0x8864), length 35: PPPoE [ses 0x21] CHAP (0xc223), length 15: CHAP, Success (0x03), id 1, Msg Welcome!! > 14:59:44.053491 d8:d3:85:c1:5e:ed > 54:75:d0:38:ca:7a, ethertype PPPoE S (0x8864), length 26: PPPoE [ses 0x21] unknown (0x80fd), length 6: unknown ctrl-proto (0x80fd), Conf-Request (0x01), id 1, length 6 > 14:59:44.053498 d8:d3:85:c1:5e:ed > 54:75:d0:38:ca:7a, ethertype PPPoE S (0x8864), length 32: PPPoE [ses 0x21] IPCP (0x8021), length 12: IPCP, Conf-Request (0x01), id 1, length 12 > encoded length 10 (=Option(s) length 6) > 0x0000: 8021 0101 000a > IP-Addr Option (0x03), length 6: 217.65.168.254 > 0x0000: d941 a8fe > 14:59:44.059344 54:75:d0:38:ca:7a > d8:d3:85:c1:5e:ed, ethertype PPPoE S (0x8864), length 60: PPPoE [ses 0x21] LCP (0xc021), length 6: LCP, Term-Request (0x05), id 2, length 6 > 14:59:44.059739 d8:d3:85:c1:5e:ed > 54:75:d0:38:ca:7a, ethertype PPPoE S (0x8864), length 26: PPPoE [ses 0x21] LCP (0xc021), length 6: LCP, Term-Ack (0x06), id 2, length 6 > 14:59:44.060925 54:75:d0:38:ca:7a > d8:d3:85:c1:5e:ed, ethertype PPPoE D (0x8863), length 60: PPPoE PADT [ses 0x21] > 14:59:44.060939 d8:d3:85:c1:5e:ed > 54:75:d0:38:ca:7a, ethertype PPPoE D (0x8863), length 38: PPPoE PADT [ses 0x21] [Generic-Error "session closed"] Many thanks for ideas, suggestions, etc. so far. I'm not well clued up on the inner workings of PPP so any pointers to understand the IPCP or CCP requests that seem to be causing the problem would be welcome. Regards, Paul. From owner-freebsd-net@FreeBSD.ORG Wed Oct 20 16:30:03 2010 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 A36F31065674 for ; Wed, 20 Oct 2010 16:30:03 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (outc.internet-mail-service.net [216.240.47.226]) by mx1.freebsd.org (Postfix) with ESMTP id 7A1708FC1E for ; Wed, 20 Oct 2010 16:30:03 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id o9KGFtAm025124; Wed, 20 Oct 2010 09:15:55 -0700 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 221852D6012; Wed, 20 Oct 2010 09:15:52 -0700 (PDT) Message-ID: <4CBF15ED.6080606@freebsd.org> Date: Wed, 20 Oct 2010 09:16:45 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: Paul Thornton References: <4CBE0042.4090905@prt.org> <4CBE0846.1090203@freebsd.org> <4CBEFB5A.80704@prt.org> In-Reply-To: <4CBEFB5A.80704@prt.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: freebsd-net@freebsd.org Subject: Re: Problems with 8.1, PPPoE server, and Cisco client X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 16:30:03 -0000 On 10/20/10 7:23 AM, Paul Thornton wrote: > Hi, > > On 19/10/2010 22:06, Julian Elischer wrote: >> Wireshark understands all the protocols in question so get packet >> captures of good and >> bad sessions (as similar as you can) and see what is different. >> (wireshark reads >> tcpdump files so it's easy to capture). > As is often the case, the packets on the wire start telling the story of > what is happening... still not sure about the why, but progress is being > made. Thanks for that nudge. > > With a Windows XP client (I know, it was nearby though) the following > things happen: > > Server -> Client PPP CHAP Success (Welcome!! message). > Server -> Client PPP CCP config request > Server -> Client IPCP Config request (setting IP address of server end) > Client -> Server PPP CCP config request > - and they carry on here working fine - > > With the Cisco client, things break at this point: > Server -> Client PPP CHAP Success (Welcome!! message). > Server -> Client PPP CCP Config request > Server -> Client IPCP Config Request (setting IP address of server end) > Client -> Server Termination request > Server -> Client Termination ack > > So either that CCP request or the IPCP request is upsetting the Cisco. > However, even with its debugging fully on for PPP, it isn't clear why. > Initially, my server was requesting deflate compression and VJ > compression - so I disabled all compression options in ppp.conf but it > made no difference. The tcpdumps were taken after compression was disabled. > > The cisco config being used on the WAN interface and Dialer interface > for testing is as follows. This is an 891 and so is an Ethernet WAN > port (no VDSL or other cable interface to add problems): > > interface GigabitEthernet0 > no ip address > ip accounting output-packets > duplex auto > speed auto > pppoe enable group global > pppoe-client dial-pool-number 1 > ! > interface Dialer0 > description PPPoE dialer > mtu 1492 > ip address negotiated > no ip redirects > no ip proxy-arp > ip accounting output-packets > encapsulation ppp > ip tcp adjust-mss 1452 > dialer pool 1 > dialer-group 1 > ppp mtu adaptive > ppp authentication chap callin optional > ppp chap hostname VT123456789@vdsl01 > ppp chap password 0 LetMeIn123 > ! > ! > ip route 0.0.0.0 0.0.0.0 Dialer0 > ! > dialer-list 1 protocol ip permit > ! > > > > > > Here is part of the tcpdump with the XP client, starting at the CHAP > success message. I've included quite a lot as there seems to be > something going on with IPCP and setting DNS addresses - is this normal? > (address ending 5e:ed is the server): > [...] > And here is the similar section from the Cisco router, it all goes > downhill quickly (address ending 5e:ed is the server): > have you tried to connect this cisco router to anything else pppoe? (take it home and make it connect to your ISP for example?) The command from the server to set an address seems ok so I wonder if there is some setting on the cisco that doesn't like it. Unfortunately, despite having worked for cisco, my IOS foo is pretty weak. >> 14:59:44.053482 d8:d3:85:c1:5e:ed> 54:75:d0:38:ca:7a, ethertype PPPoE S (0x8864), length 35: PPPoE [ses 0x21] CHAP (0xc223), length 15: CHAP, Success (0x03), id 1, Msg Welcome!! >> 14:59:44.053491 d8:d3:85:c1:5e:ed> 54:75:d0:38:ca:7a, ethertype PPPoE S (0x8864), length 26: PPPoE [ses 0x21] unknown (0x80fd), length 6: unknown ctrl-proto (0x80fd), Conf-Request (0x01), id 1, length 6 >> 14:59:44.053498 d8:d3:85:c1:5e:ed> 54:75:d0:38:ca:7a, ethertype PPPoE S (0x8864), length 32: PPPoE [ses 0x21] IPCP (0x8021), length 12: IPCP, Conf-Request (0x01), id 1, length 12 >> encoded length 10 (=Option(s) length 6) >> 0x0000: 8021 0101 000a >> IP-Addr Option (0x03), length 6: 217.65.168.254 >> 0x0000: d941 a8fe >> 14:59:44.059344 54:75:d0:38:ca:7a> d8:d3:85:c1:5e:ed, ethertype PPPoE S (0x8864), length 60: PPPoE [ses 0x21] LCP (0xc021), length 6: LCP, Term-Request (0x05), id 2, length 6 >> 14:59:44.059739 d8:d3:85:c1:5e:ed> 54:75:d0:38:ca:7a, ethertype PPPoE S (0x8864), length 26: PPPoE [ses 0x21] LCP (0xc021), length 6: LCP, Term-Ack (0x06), id 2, length 6 >> 14:59:44.060925 54:75:d0:38:ca:7a> d8:d3:85:c1:5e:ed, ethertype PPPoE D (0x8863), length 60: PPPoE PADT [ses 0x21] >> 14:59:44.060939 d8:d3:85:c1:5e:ed> 54:75:d0:38:ca:7a, ethertype PPPoE D (0x8863), length 38: PPPoE PADT [ses 0x21] [Generic-Error "session closed"] > From owner-freebsd-net@FreeBSD.ORG Wed Oct 20 16:39:19 2010 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 2F406106566B for ; Wed, 20 Oct 2010 16:39:19 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 56B578FC15 for ; Wed, 20 Oct 2010 16:39:17 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id o9KGdFpq040034; Thu, 21 Oct 2010 03:39:15 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 21 Oct 2010 03:39:15 +1100 (EST) From: Ian Smith To: Paul Thornton In-Reply-To: <4CBEFB5A.80704@prt.org> Message-ID: <20101021024340.D9562@sola.nimnet.asn.au> References: <4CBE0042.4090905@prt.org> <4CBE0846.1090203@freebsd.org> <4CBEFB5A.80704@prt.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net@freebsd.org Subject: Re: Problems with 8.1, PPPoE server, and Cisco client X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 16:39:19 -0000 On Wed, 20 Oct 2010, Paul Thornton wrote: [..] > With a Windows XP client (I know, it was nearby though) the following > things happen: > > Server -> Client PPP CHAP Success (Welcome!! message). > Server -> Client PPP CCP config request > Server -> Client IPCP Config request (setting IP address of server end) > Client -> Server PPP CCP config request > - and they carry on here working fine - > > With the Cisco client, things break at this point: > Server -> Client PPP CHAP Success (Welcome!! message). > Server -> Client PPP CCP Config request > Server -> Client IPCP Config Request (setting IP address of server end) > Client -> Server Termination request > Server -> Client Termination ack > > So either that CCP request or the IPCP request is upsetting the Cisco. My money's on IPCP or maybe LCP so far .. > However, even with its debugging fully on for PPP, it isn't clear why. > Initially, my server was requesting deflate compression and VJ > compression - so I disabled all compression options in ppp.conf but it > made no difference. The tcpdumps were taken after compression was disabled. Good idea, keeps the logging reasonable meanwhile .. > The cisco config being used on the WAN interface and Dialer interface > for testing is as follows. This is an 891 and so is an Ethernet WAN > port (no VDSL or other cable interface to add problems): > > interface GigabitEthernet0 > no ip address > ip accounting output-packets > duplex auto > speed auto > pppoe enable group global > pppoe-client dial-pool-number 1 > ! > interface Dialer0 > description PPPoE dialer > mtu 1492 > ip address negotiated > no ip redirects > no ip proxy-arp > ip accounting output-packets > encapsulation ppp > ip tcp adjust-mss 1452 > dialer pool 1 > dialer-group 1 > ppp mtu adaptive > ppp authentication chap callin optional > ppp chap hostname VT123456789@vdsl01 > ppp chap password 0 LetMeIn123 > ! > ! > ip route 0.0.0.0 0.0.0.0 Dialer0 > ! > dialer-list 1 protocol ip permit > ! Left to those who speak cisco .. > Here is part of the tcpdump with the XP client, starting at the CHAP > success message. I've included quite a lot as there seems to be > something going on with IPCP and setting DNS addresses - is this normal? Looks pretty normal. Omitting 'unknown ctrl-proto (0x80fd)' MPPC stuff: > (address ending 5e:ed is the server): > > > 14:40:27.733755 d8:d3:85:c1:5e:ed > 18:a9:05:db:8e:5c, ethertype PPPoE S (0x8864), length 35: PPPoE [ses 0x20] CHAP (0xc223), length 15: CHAP, Success (0x03), id 1, Msg Welcome!! > > 14:40:27.733764 d8:d3:85:c1:5e:ed > 18:a9:05:db:8e:5c, ethertype PPPoE S (0x8864), length 26: PPPoE [ses 0x20] unknown (0x80fd), length 6: unknown ctrl-proto (0x80fd), Conf-Request (0x01), id 1, length 6 > > 14:40:27.733770 d8:d3:85:c1:5e:ed > 18:a9:05:db:8e:5c, ethertype PPPoE S (0x8864), length 32: PPPoE [ses 0x20] IPCP (0x8021), length 12: IPCP, Conf-Request (0x01), id 1, length 12 > > encoded length 10 (=Option(s) length 6) > > 0x0000: 8021 0101 000a > > IP-Addr Option (0x03), length 6: 217.65.168.254 > > 0x0000: d941 a8fe we want this address. > > 14:40:27.741992 18:a9:05:db:8e:5c > d8:d3:85:c1:5e:ed, ethertype PPPoE S (0x8864), length 60: PPPoE [ses 0x20] IPCP (0x8021), length 36: IPCP, Conf-Request (0x01), id 7, length 36 > > encoded length 34 (=Option(s) length 30) > > 0x0000: 8021 0107 0022 > > IP-Addr Option (0x03), length 6: 0.0.0.0 > > 0x0000: 0000 0000 > > Pri-DNS Option (0x81), length 6: 0.0.0.0 > > 0x0000: 0000 0000 > > Pri-NBNS Option (0x82), length 6: 0.0.0.0 > > 0x0000: 0000 0000 > > Sec-DNS Option (0x83), length 6: 0.0.0.0 > > 0x0000: 0000 0000 > > Sec-NBNS Option (0x84), length 6: 0.0.0.0 > > 0x0000: 0000 0000 it's open to persuasion for all these. > > 14:40:27.742107 d8:d3:85:c1:5e:ed > 18:a9:05:db:8e:5c, ethertype PPPoE S (0x8864), length 38: PPPoE [ses 0x20] IPCP (0x8021), length 18: IPCP, Conf-Reject (0x04), id 7, length 18 > > encoded length 16 (=Option(s) length 12) > > 0x0000: 8021 0407 0010 > > Pri-NBNS Option (0x82), length 6: 0.0.0.0 > > 0x0000: 0000 0000 > > Sec-NBNS Option (0x84), length 6: 0.0.0.0 > > 0x0000: 0000 0000 we don't do NBNS. > > 14:40:27.742559 18:a9:05:db:8e:5c > d8:d3:85:c1:5e:ed, ethertype PPPoE S (0x8864), length 60: PPPoE [ses 0x20] IPCP (0x8021), length 12: IPCP, Conf-Ack (0x02), id 1, length 12 > > encoded length 10 (=Option(s) length 6) > > 0x0000: 8021 0201 000a > > IP-Addr Option (0x03), length 6: 217.65.168.254 > > 0x0000: d941 a8fe it's happy with our IP addr. > > 14:40:27.756230 18:a9:05:db:8e:5c > d8:d3:85:c1:5e:ed, ethertype PPPoE S (0x8864), length 60: PPPoE [ses 0x20] IPCP (0x8021), length 24: IPCP, Conf-Request (0x01), id 9, length 24 > > encoded length 22 (=Option(s) length 18) > > 0x0000: 8021 0109 0016 > > IP-Addr Option (0x03), length 6: 0.0.0.0 > > 0x0000: 0000 0000 > > Pri-DNS Option (0x81), length 6: 0.0.0.0 > > 0x0000: 0000 0000 > > Sec-DNS Option (0x83), length 6: 0.0.0.0 > > 0x0000: 0000 0000 it still needs these. > > 14:40:27.756316 d8:d3:85:c1:5e:ed > 18:a9:05:db:8e:5c, ethertype PPPoE S (0x8864), length 44: PPPoE [ses 0x20] IPCP (0x8021), length 24: IPCP, Conf-Nack (0x03), id 9, length 24 > > encoded length 22 (=Option(s) length 18) > > 0x0000: 8021 0309 0016 > > IP-Addr Option (0x03), length 6: 217.65.167.128 > > 0x0000: d941 a780 > > Pri-DNS Option (0x81), length 6: 217.65.160.42 > > 0x0000: d941 a02a > > Sec-DNS Option (0x83), length 6: 255.255.255.255 > > 0x0000: ffff ffff so we offer it these. > > 14:40:27.771794 18:a9:05:db:8e:5c > d8:d3:85:c1:5e:ed, ethertype PPPoE S (0x8864), length 60: PPPoE [ses 0x20] IPCP (0x8021), length 24: IPCP, Conf-Request (0x01), id 10, length 24 > > encoded length 22 (=Option(s) length 18) > > 0x0000: 8021 010a 0016 > > IP-Addr Option (0x03), length 6: 217.65.167.128 > > 0x0000: d941 a780 > > Pri-DNS Option (0x81), length 6: 217.65.160.42 > > 0x0000: d941 a02a > > Sec-DNS Option (0x83), length 6: 255.255.255.255 > > 0x0000: ffff ffff it asks for just what we've offered, ok .. > > 14:40:27.779058 d8:d3:85:c1:5e:ed > 18:a9:05:db:8e:5c, ethertype PPPoE S (0x8864), length 44: PPPoE [ses 0x20] IPCP (0x8021), length 24: IPCP, Conf-Ack (0x02), id 10, length 24 > > encoded length 22 (=Option(s) length 18) > > 0x0000: 8021 020a 0016 > > IP-Addr Option (0x03), length 6: 217.65.167.128 > > 0x0000: d941 a780 > > Pri-DNS Option (0x81), length 6: 217.65.160.42 > > 0x0000: d941 a02a > > Sec-DNS Option (0x83), length 6: 255.255.255.255 > > 0x0000: ffff ffff so we ack those. Ready to roll at IPCP level. > And here is the similar section from the Cisco router, it all goes > downhill quickly (address ending 5e:ed is the server): > > > 14:59:44.053482 d8:d3:85:c1:5e:ed > 54:75:d0:38:ca:7a, ethertype PPPoE S (0x8864), length 35: PPPoE [ses 0x21] CHAP (0xc223), length 15: CHAP, Success (0x03), id 1, Msg Welcome!! > > 14:59:44.053491 d8:d3:85:c1:5e:ed > 54:75:d0:38:ca:7a, ethertype PPPoE S (0x8864), length 26: PPPoE [ses 0x21] unknown (0x80fd), length 6: unknown ctrl-proto (0x80fd), Conf-Request (0x01), id 1, length 6 > > 14:59:44.053498 d8:d3:85:c1:5e:ed > 54:75:d0:38:ca:7a, ethertype PPPoE S (0x8864), length 32: PPPoE [ses 0x21] IPCP (0x8021), length 12: IPCP, Conf-Request (0x01), id 1, length 12 > > encoded length 10 (=Option(s) length 6) > > 0x0000: 8021 0101 000a > > IP-Addr Option (0x03), length 6: 217.65.168.254 > > 0x0000: d941 a8fe we want this IP address. > > 14:59:44.059344 54:75:d0:38:ca:7a > d8:d3:85:c1:5e:ed, ethertype PPPoE S (0x8864), length 60: PPPoE [ses 0x21] LCP (0xc021), length 6: LCP, Term-Request (0x05), id 2, length 6 and it requests termination, that's it. Any reason the Cisco might reject that address? It's not even being too polite about it, not even a friendly Conf-Reject .. > > 14:59:44.059739 d8:d3:85:c1:5e:ed > 54:75:d0:38:ca:7a, ethertype PPPoE S (0x8864), length 26: PPPoE [ses 0x21] LCP (0xc021), length 6: LCP, Term-Ack (0x06), id 2, length 6 we ack its termination request. > > 14:59:44.060925 54:75:d0:38:ca:7a > d8:d3:85:c1:5e:ed, ethertype PPPoE D (0x8863), length 60: PPPoE PADT [ses 0x21] > > 14:59:44.060939 d8:d3:85:c1:5e:ed > 54:75:d0:38:ca:7a, ethertype PPPoE D (0x8863), length 38: PPPoE PADT [ses 0x21] [Generic-Error "session closed"] dunno. > Many thanks for ideas, suggestions, etc. so far. I'm not well clued up > on the inner workings of PPP so any pointers to understand the IPCP or > CCP requests that seem to be causing the problem would be welcome. I suspect that the ppp log from Greeting past LCP close including LCP, IPCP and (why not?) CCP logging with the cisco might show what's not acceptable, and to whom .. cheers, Ian From owner-freebsd-net@FreeBSD.ORG Wed Oct 20 16:57:54 2010 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 A80A9106566C for ; Wed, 20 Oct 2010 16:57:54 +0000 (UTC) (envelope-from alireza.torabi@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 57F9B8FC0A for ; Wed, 20 Oct 2010 16:57:54 +0000 (UTC) Received: by vws1 with SMTP id 1so2190547vws.13 for ; Wed, 20 Oct 2010 09:57:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=YTCi+Xehb70V2xQYJnKtYtbb8st7RmIu1lI9+w6+Kfk=; b=bJ4L+s0HhfI30A5a32o2qUcwCous+QUeMNT42zdE5gswC7eKPSL14UFnUp/JhHrNWy q8rM72Ig/IRb6Vg1M2AyoTb+cdYdtqomBQZSGOy+O7P43/W9YBaAUO67StuczPl1ZaE/ NbvoGZv7bRLPuYQvCVsNk7zaInZukmFEuBg1w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=To1wlYfJKVwikKUwJaHacgKn1fHVzigDAoZ/onvACTfc5jllK4R3TVXZhrZAgfgPsM Gs8bKa+r7V2iNyvwhr5O7bDtfhOnw/IASIyunARHdbG0tGRPocuYB2Jzb56UuHW6DxhI 3X8q2ow1ToKnY/YNZnbhkXpFacYSxZMxcPks8= MIME-Version: 1.0 Received: by 10.229.91.77 with SMTP id l13mr6649217qcm.282.1287593873363; Wed, 20 Oct 2010 09:57:53 -0700 (PDT) Received: by 10.229.11.143 with HTTP; Wed, 20 Oct 2010 09:57:53 -0700 (PDT) In-Reply-To: <20101021024340.D9562@sola.nimnet.asn.au> References: <4CBE0042.4090905@prt.org> <4CBE0846.1090203@freebsd.org> <4CBEFB5A.80704@prt.org> <20101021024340.D9562@sola.nimnet.asn.au> Date: Wed, 20 Oct 2010 17:57:53 +0100 Message-ID: From: Alireza Torabi To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: Problems with 8.1, PPPoE server, and Cisco client X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 16:57:54 -0000 have you tried pap instead of chap on Cisco dialer? On 10/20/10, Ian Smith wrote: > On Wed, 20 Oct 2010, Paul Thornton wrote: > > [..] > > > With a Windows XP client (I know, it was nearby though) the following > > things happen: > > > > Server -> Client PPP CHAP Success (Welcome!! message). > > Server -> Client PPP CCP config request > > Server -> Client IPCP Config request (setting IP address of server end) > > Client -> Server PPP CCP config request > > - and they carry on here working fine - > > > > With the Cisco client, things break at this point: > > Server -> Client PPP CHAP Success (Welcome!! message). > > Server -> Client PPP CCP Config request > > Server -> Client IPCP Config Request (setting IP address of server end) > > Client -> Server Termination request > > Server -> Client Termination ack > > > > So either that CCP request or the IPCP request is upsetting the Cisco. > > My money's on IPCP or maybe LCP so far .. > > > However, even with its debugging fully on for PPP, it isn't clear why. > > Initially, my server was requesting deflate compression and VJ > > compression - so I disabled all compression options in ppp.conf but it > > made no difference. The tcpdumps were taken after compression was > disabled. > > Good idea, keeps the logging reasonable meanwhile .. > > > The cisco config being used on the WAN interface and Dialer interface > > for testing is as follows. This is an 891 and so is an Ethernet WAN > > port (no VDSL or other cable interface to add problems): > > > > interface GigabitEthernet0 > > no ip address > > ip accounting output-packets > > duplex auto > > speed auto > > pppoe enable group global > > pppoe-client dial-pool-number 1 > > ! > > interface Dialer0 > > description PPPoE dialer > > mtu 1492 > > ip address negotiated > > no ip redirects > > no ip proxy-arp > > ip accounting output-packets > > encapsulation ppp > > ip tcp adjust-mss 1452 > > dialer pool 1 > > dialer-group 1 > > ppp mtu adaptive > > ppp authentication chap callin optional > > ppp chap hostname VT123456789@vdsl01 > > ppp chap password 0 LetMeIn123 > > ! > > ! > > ip route 0.0.0.0 0.0.0.0 Dialer0 > > ! > > dialer-list 1 protocol ip permit > > ! > > Left to those who speak cisco .. > > > Here is part of the tcpdump with the XP client, starting at the CHAP > > success message. I've included quite a lot as there seems to be > > something going on with IPCP and setting DNS addresses - is this normal? > > Looks pretty normal. Omitting 'unknown ctrl-proto (0x80fd)' MPPC stuff: > > > (address ending 5e:ed is the server): > > > > > 14:40:27.733755 d8:d3:85:c1:5e:ed > 18:a9:05:db:8e:5c, ethertype PPPoE > S (0x8864), length 35: PPPoE [ses 0x20] CHAP (0xc223), length 15: CHAP, > Success (0x03), id 1, Msg Welcome!! > > > 14:40:27.733764 d8:d3:85:c1:5e:ed > 18:a9:05:db:8e:5c, ethertype PPPoE > S (0x8864), length 26: PPPoE [ses 0x20] unknown (0x80fd), length 6: unknown > ctrl-proto (0x80fd), Conf-Request (0x01), id 1, length 6 > > > 14:40:27.733770 d8:d3:85:c1:5e:ed > 18:a9:05:db:8e:5c, ethertype PPPoE > S (0x8864), length 32: PPPoE [ses 0x20] IPCP (0x8021), length 12: IPCP, > Conf-Request (0x01), id 1, length 12 > > > encoded length 10 (=Option(s) length 6) > > > 0x0000: 8021 0101 000a > > > IP-Addr Option (0x03), length 6: 217.65.168.254 > > > 0x0000: d941 a8fe > > we want this address. > > > > 14:40:27.741992 18:a9:05:db:8e:5c > d8:d3:85:c1:5e:ed, ethertype PPPoE > S (0x8864), length 60: PPPoE [ses 0x20] IPCP (0x8021), length 36: IPCP, > Conf-Request (0x01), id 7, length 36 > > > encoded length 34 (=Option(s) length 30) > > > 0x0000: 8021 0107 0022 > > > IP-Addr Option (0x03), length 6: 0.0.0.0 > > > 0x0000: 0000 0000 > > > Pri-DNS Option (0x81), length 6: 0.0.0.0 > > > 0x0000: 0000 0000 > > > Pri-NBNS Option (0x82), length 6: 0.0.0.0 > > > 0x0000: 0000 0000 > > > Sec-DNS Option (0x83), length 6: 0.0.0.0 > > > 0x0000: 0000 0000 > > > Sec-NBNS Option (0x84), length 6: 0.0.0.0 > > > 0x0000: 0000 0000 > > it's open to persuasion for all these. > > > > 14:40:27.742107 d8:d3:85:c1:5e:ed > 18:a9:05:db:8e:5c, ethertype PPPoE > S (0x8864), length 38: PPPoE [ses 0x20] IPCP (0x8021), length 18: IPCP, > Conf-Reject (0x04), id 7, length 18 > > > encoded length 16 (=Option(s) length 12) > > > 0x0000: 8021 0407 0010 > > > Pri-NBNS Option (0x82), length 6: 0.0.0.0 > > > 0x0000: 0000 0000 > > > Sec-NBNS Option (0x84), length 6: 0.0.0.0 > > > 0x0000: 0000 0000 > > we don't do NBNS. > > > > 14:40:27.742559 18:a9:05:db:8e:5c > d8:d3:85:c1:5e:ed, ethertype PPPoE > S (0x8864), length 60: PPPoE [ses 0x20] IPCP (0x8021), length 12: IPCP, > Conf-Ack (0x02), id 1, length 12 > > > encoded length 10 (=Option(s) length 6) > > > 0x0000: 8021 0201 000a > > > IP-Addr Option (0x03), length 6: 217.65.168.254 > > > 0x0000: d941 a8fe > > it's happy with our IP addr. > > > > 14:40:27.756230 18:a9:05:db:8e:5c > d8:d3:85:c1:5e:ed, ethertype PPPoE > S (0x8864), length 60: PPPoE [ses 0x20] IPCP (0x8021), length 24: IPCP, > Conf-Request (0x01), id 9, length 24 > > > encoded length 22 (=Option(s) length 18) > > > 0x0000: 8021 0109 0016 > > > IP-Addr Option (0x03), length 6: 0.0.0.0 > > > 0x0000: 0000 0000 > > > Pri-DNS Option (0x81), length 6: 0.0.0.0 > > > 0x0000: 0000 0000 > > > Sec-DNS Option (0x83), length 6: 0.0.0.0 > > > 0x0000: 0000 0000 > > it still needs these. > > > > 14:40:27.756316 d8:d3:85:c1:5e:ed > 18:a9:05:db:8e:5c, ethertype PPPoE > S (0x8864), length 44: PPPoE [ses 0x20] IPCP (0x8021), length 24: IPCP, > Conf-Nack (0x03), id 9, length 24 > > > encoded length 22 (=Option(s) length 18) > > > 0x0000: 8021 0309 0016 > > > IP-Addr Option (0x03), length 6: 217.65.167.128 > > > 0x0000: d941 a780 > > > Pri-DNS Option (0x81), length 6: 217.65.160.42 > > > 0x0000: d941 a02a > > > Sec-DNS Option (0x83), length 6: 255.255.255.255 > > > 0x0000: ffff ffff > > so we offer it these. > > > > 14:40:27.771794 18:a9:05:db:8e:5c > d8:d3:85:c1:5e:ed, ethertype PPPoE > S (0x8864), length 60: PPPoE [ses 0x20] IPCP (0x8021), length 24: IPCP, > Conf-Request (0x01), id 10, length 24 > > > encoded length 22 (=Option(s) length 18) > > > 0x0000: 8021 010a 0016 > > > IP-Addr Option (0x03), length 6: 217.65.167.128 > > > 0x0000: d941 a780 > > > Pri-DNS Option (0x81), length 6: 217.65.160.42 > > > 0x0000: d941 a02a > > > Sec-DNS Option (0x83), length 6: 255.255.255.255 > > > 0x0000: ffff ffff > > it asks for just what we've offered, ok .. > > > > 14:40:27.779058 d8:d3:85:c1:5e:ed > 18:a9:05:db:8e:5c, ethertype PPPoE > S (0x8864), length 44: PPPoE [ses 0x20] IPCP (0x8021), length 24: IPCP, > Conf-Ack (0x02), id 10, length 24 > > > encoded length 22 (=Option(s) length 18) > > > 0x0000: 8021 020a 0016 > > > IP-Addr Option (0x03), length 6: 217.65.167.128 > > > 0x0000: d941 a780 > > > Pri-DNS Option (0x81), length 6: 217.65.160.42 > > > 0x0000: d941 a02a > > > Sec-DNS Option (0x83), length 6: 255.255.255.255 > > > 0x0000: ffff ffff > > so we ack those. Ready to roll at IPCP level. > > > And here is the similar section from the Cisco router, it all goes > > downhill quickly (address ending 5e:ed is the server): > > > > > 14:59:44.053482 d8:d3:85:c1:5e:ed > 54:75:d0:38:ca:7a, ethertype PPPoE > S (0x8864), length 35: PPPoE [ses 0x21] CHAP (0xc223), length 15: CHAP, > Success (0x03), id 1, Msg Welcome!! > > > 14:59:44.053491 d8:d3:85:c1:5e:ed > 54:75:d0:38:ca:7a, ethertype PPPoE > S (0x8864), length 26: PPPoE [ses 0x21] unknown (0x80fd), length 6: unknown > ctrl-proto (0x80fd), Conf-Request (0x01), id 1, length 6 > > > 14:59:44.053498 d8:d3:85:c1:5e:ed > 54:75:d0:38:ca:7a, ethertype PPPoE > S (0x8864), length 32: PPPoE [ses 0x21] IPCP (0x8021), length 12: IPCP, > Conf-Request (0x01), id 1, length 12 > > > encoded length 10 (=Option(s) length 6) > > > 0x0000: 8021 0101 000a > > > IP-Addr Option (0x03), length 6: 217.65.168.254 > > > 0x0000: d941 a8fe > > we want this IP address. > > > > 14:59:44.059344 54:75:d0:38:ca:7a > d8:d3:85:c1:5e:ed, ethertype PPPoE > S (0x8864), length 60: PPPoE [ses 0x21] LCP (0xc021), length 6: LCP, > Term-Request (0x05), id 2, length 6 > > and it requests termination, that's it. Any reason the Cisco might > reject that address? It's not even being too polite about it, not even > a friendly Conf-Reject .. > > > > 14:59:44.059739 d8:d3:85:c1:5e:ed > 54:75:d0:38:ca:7a, ethertype PPPoE > S (0x8864), length 26: PPPoE [ses 0x21] LCP (0xc021), length 6: LCP, > Term-Ack (0x06), id 2, length 6 > > we ack its termination request. > > > > 14:59:44.060925 54:75:d0:38:ca:7a > d8:d3:85:c1:5e:ed, ethertype PPPoE > D (0x8863), length 60: PPPoE PADT [ses 0x21] > > > 14:59:44.060939 d8:d3:85:c1:5e:ed > 54:75:d0:38:ca:7a, ethertype PPPoE > D (0x8863), length 38: PPPoE PADT [ses 0x21] [Generic-Error "session > closed"] > > dunno. > > > Many thanks for ideas, suggestions, etc. so far. I'm not well clued up > > on the inner workings of PPP so any pointers to understand the IPCP or > > CCP requests that seem to be causing the problem would be welcome. > > I suspect that the ppp log from Greeting past LCP close including LCP, > IPCP and (why not?) CCP logging with the cisco might show what's not > acceptable, and to whom .. > > cheers, Ian > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Wed Oct 20 17:15:21 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44F131065670; Wed, 20 Oct 2010 17:15:21 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id DDE018FC1F; Wed, 20 Oct 2010 17:15:20 +0000 (UTC) Received: by vws1 with SMTP id 1so2206669vws.13 for ; Wed, 20 Oct 2010 10:15:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.98.197 with SMTP id r5mr6666337qcn.217.1287594919864; Wed, 20 Oct 2010 10:15:19 -0700 (PDT) Sender: bschmidt@techwires.net Received: by 10.229.41.198 with HTTP; Wed, 20 Oct 2010 10:15:19 -0700 (PDT) X-Originating-IP: [84.180.206.219] In-Reply-To: <20101020083156.GA57472@FreeBSD.org> References: <4763016D.7060100@janh.de> <201010081944.50287.bschmidt@techwires.net> <20101009060239.GA88618@FreeBSD.org> <201010092046.41551.bschmidt@techwires.net> <20101010072730.GA91527@FreeBSD.org> <20101016124152.GA95535@FreeBSD.org> <20101020083156.GA57472@FreeBSD.org> Date: Wed, 20 Oct 2010 19:15:19 +0200 X-Google-Sender-Auth: -6zi5kQWytD0Of7CvQy97uNRwww Message-ID: From: Bernhard Schmidt To: Alexey Dokuchaev Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: net@freebsd.org Subject: Re: Monitor mode not working for iwi(4) on 7.X X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 17:15:21 -0000 2010/10/20 Alexey Dokuchaev : > On Tue, Oct 19, 2010 Bernhard Schmidt wrote: >> Alexey Dokuchaev wrote: >> > Not sure if this is a driver or ifconfig(8) problem, but after I -medi= aopt >> > monitor, ifconfig(8) still reports it in media line: >> > >> > =A0 =A0 media: IEEE 802.11 Wireless Ethernet autoselect >> > >> > However, as I said, scan list gets populated, which suggests ifconfig(= 8) >> > is getting something wrong. Doing -mediaopt monitor the second time >> > "knocks" ifconfig(8) though. >> >> I can't reproduce that on my stable/7 setup, neither in 'UP' nor in 'DOW= N' >> state. Can you post the exact command sequence you've used? The output >> differs though.. >> >> # ifconfig iwi0 mediaopt monitor >> # ifconfig iwi0 up >> # ifconfig iwi0 | grep media >> =A0 =A0 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect ) >> # ifconfig iwi0 -mediaopt monitor >> # ifconfig iwi0 | grep media >> =A0 =A0 media: IEEE 802.11 Wireless Ethernet autoselect > > This scenario works. =A0But try it out after aircrack-ng tools, which set > (P)PROMISC mode on the card (and do not clear it after exit, but in my > understanding this should not affect monitor mode and its indication, no?= ). Correct. # kldload if_iwi # aireplay-ng -9 iwi0 # ifconfig iwi0 iwi0: flags=3D28943 metric 0 mtu 1500 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect ) # ifconfig iwi0 -mediaopt monitor # ifconfig iwi0 iwi0: flags=3D28943 metric 0 mtu 1500 media: IEEE 802.11 Wireless Ethernet autoselect # hmm.. looks correct to me, am I doing something wrong? -- Bernhard From owner-freebsd-net@FreeBSD.ORG Wed Oct 20 17:52:06 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B19EF1065675 for ; Wed, 20 Oct 2010 17:52:06 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 777AB8FC22 for ; Wed, 20 Oct 2010 17:52:06 +0000 (UTC) Received: by qwe4 with SMTP id 4so2509486qwe.13 for ; Wed, 20 Oct 2010 10:52:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.95.66 with SMTP id c2mr6752712qcn.85.1287597125485; Wed, 20 Oct 2010 10:52:05 -0700 (PDT) Sender: bschmidt@techwires.net Received: by 10.229.41.198 with HTTP; Wed, 20 Oct 2010 10:52:05 -0700 (PDT) X-Originating-IP: [84.180.206.219] In-Reply-To: References: Date: Wed, 20 Oct 2010 19:52:05 +0200 X-Google-Sender-Auth: w87cfAwpicUhMo5pbl50LqsV0Dk Message-ID: From: Bernhard Schmidt To: Paul B Mahol Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: net@freebsd.org Subject: Re: ndis: patch for review X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 17:52:06 -0000 9, 2010 at 23:53, Paul B Mahol wrote: > Hi, > > First: we should pin curthread on CPU before we check on which CPU is cur= thread. > > Second: instead of sti & cli use critical sections when saving %fs regist= er. > > Third: I do not know what happens if we get preempted while windows > code were running, > so leave critical section only _after_ executing windows code. Do you have a test case for that? If so, can you post it? > diff --git a/sys/compat/ndis/kern_windrv.c b/sys/compat/ndis/kern_windrv.= c > index f231863..ba29fd2 100644 > --- a/sys/compat/ndis/kern_windrv.c > +++ b/sys/compat/ndis/kern_windrv.c > @@ -613,8 +613,6 @@ struct gdt { > =A0extern uint16_t =A0 =A0 =A0 =A0x86_getfs(void); > =A0extern void x86_setfs(uint16_t); > =A0extern void *x86_gettid(void); > -extern void x86_critical_enter(void); > -extern void x86_critical_exit(void); > =A0extern void x86_getldt(struct gdt *, uint16_t *); > =A0extern void x86_setldt(struct gdt *, uint16_t); > > @@ -668,8 +666,10 @@ extern void x86_setldt(struct gdt *, uint16_t); > =A0void > =A0ctxsw_utow(void) > =A0{ > - =A0 =A0 =A0 struct tid =A0 =A0 =A0 =A0 =A0 =A0 =A0*t; > + =A0 =A0 =A0 struct tid *t; > > + =A0 =A0 =A0 sched_pin(); > + =A0 =A0 =A0 critical_enter(); > =A0 =A0 =A0 =A0t =3D &my_tids[curthread->td_oncpu]; > > =A0 =A0 =A0 =A0/* > @@ -685,12 +685,9 @@ ctxsw_utow(void) > =A0 =A0 =A0 =A0if (t->tid_self !=3D t) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0x86_newldt(NULL); > > - =A0 =A0 =A0 x86_critical_enter(); > =A0 =A0 =A0 =A0t->tid_oldfs =3D x86_getfs(); > =A0 =A0 =A0 =A0t->tid_cpu =3D curthread->td_oncpu; > - =A0 =A0 =A0 sched_pin(); > =A0 =A0 =A0 =A0x86_setfs(SEL_TO_FS(t->tid_selector)); > - =A0 =A0 =A0 x86_critical_exit(); > > =A0 =A0 =A0 =A0/* Now entering Windows land, population: you. */ > =A0} > @@ -706,11 +703,10 @@ ctxsw_wtou(void) > =A0{ > =A0 =A0 =A0 =A0struct tid =A0 =A0 =A0 =A0 =A0 =A0 =A0*t; > > - =A0 =A0 =A0 x86_critical_enter(); > =A0 =A0 =A0 =A0t =3D x86_gettid(); > =A0 =A0 =A0 =A0x86_setfs(t->tid_oldfs); > + =A0 =A0 =A0 critical_exit(); > =A0 =A0 =A0 =A0sched_unpin(); > - =A0 =A0 =A0 x86_critical_exit(); > > =A0 =A0 =A0 =A0/* Welcome back to UNIX land, we missed you. */ > > diff --git a/sys/compat/ndis/winx32_wrap.S b/sys/compat/ndis/winx32_wrap.= S > index c051504..fa4aa87 100644 > --- a/sys/compat/ndis/winx32_wrap.S > +++ b/sys/compat/ndis/winx32_wrap.S > @@ -375,11 +375,3 @@ ENTRY(x86_setfs) > =A0ENTRY(x86_gettid) > =A0 =A0 =A0 =A0mov =A0 =A0 %fs:12,%eax > =A0 =A0 =A0 =A0ret > - > -ENTRY(x86_critical_enter) > - =A0 =A0 =A0 cli > - =A0 =A0 =A0 ret > - > -ENTRY(x86_critical_exit) > - =A0 =A0 =A0 sti > - =A0 =A0 =A0 ret > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > --=20 Bernhard From owner-freebsd-net@FreeBSD.ORG Wed Oct 20 19:21:05 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B3F2106566B; Wed, 20 Oct 2010 19:21:05 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 97FFF8FC15; Wed, 20 Oct 2010 19:21:04 +0000 (UTC) Received: by wwb13 with SMTP id 13so3168373wwb.31 for ; Wed, 20 Oct 2010 12:21:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=h8avQu1E+LZG1cmMaDOC2WY+kRCXBBpuOKu0k/rLk4g=; b=fMGj4UPJcSvjXH929AaXQB/FyrwDpQh7TLQdy6FgENqte5kQHlfo36TpsOMLMXEzdn s6thJqMkvijPyMwrRAtbZg2hFOxkOSIpY8jNZ+MPip0Ap42pAgVSKCLi9Pjts3NMS5Na U0EkJvlxInDdcnQbohs2wv+SlBPyVFX9OQKdU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=aQsrJ9MIqdf7ieIazSDsnU2heCuRgjp4TDp1L4vkoUAJK8q/8eiAA3hfzxFb7glZhK GFlCiKBj/i7RMwUBG0Fkox2mOJlMWmAVIRBCpK3dm36LsAkVcYnYp/d3balUqxR1qb2B a/ric5b371cLzlI5TnVzRNmfhW7TYjvwv0qkQ= MIME-Version: 1.0 Received: by 10.227.147.79 with SMTP id k15mr8195311wbv.128.1287602463075; Wed, 20 Oct 2010 12:21:03 -0700 (PDT) Received: by 10.216.183.146 with HTTP; Wed, 20 Oct 2010 12:21:03 -0700 (PDT) In-Reply-To: References: Date: Wed, 20 Oct 2010 21:21:03 +0200 Message-ID: From: Paul B Mahol To: Bernhard Schmidt Content-Type: text/plain; charset=ISO-8859-1 Cc: net@freebsd.org Subject: Re: ndis: patch for review X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 19:21:05 -0000 On 10/20/10, Bernhard Schmidt wrote: > 9, 2010 at 23:53, Paul B Mahol wrote: >> Hi, >> >> First: we should pin curthread on CPU before we check on which CPU is >> curthread. >> >> Second: instead of sti & cli use critical sections when saving %fs >> register. >> >> Third: I do not know what happens if we get preempted while windows >> code were running, >> so leave critical section only _after_ executing windows code. > > > Do you have a test case for that? If so, can you post it? Unfortunately I do not have test case for third problem. But not using sched_pin or/and critical sections correctly cause NTOS: timer %p fired even though it was canceled in my environment - causing watchdog on ndisX. And attempt to unload miniport driver after that will cause panic because something got corrupted. Theoretically when executing windows code there is small chance for our thread to be preempted and than it will actually cause %fs corruption on CPU we were running, and reading comments it appears FreeBSD use %fs for PCPU. > >> diff --git a/sys/compat/ndis/kern_windrv.c b/sys/compat/ndis/kern_windrv.c >> index f231863..ba29fd2 100644 >> --- a/sys/compat/ndis/kern_windrv.c >> +++ b/sys/compat/ndis/kern_windrv.c >> @@ -613,8 +613,6 @@ struct gdt { >> extern uint16_t x86_getfs(void); >> extern void x86_setfs(uint16_t); >> extern void *x86_gettid(void); >> -extern void x86_critical_enter(void); >> -extern void x86_critical_exit(void); >> extern void x86_getldt(struct gdt *, uint16_t *); >> extern void x86_setldt(struct gdt *, uint16_t); >> >> @@ -668,8 +666,10 @@ extern void x86_setldt(struct gdt *, uint16_t); >> void >> ctxsw_utow(void) >> { >> - struct tid *t; >> + struct tid *t; >> >> + sched_pin(); >> + critical_enter(); >> t = &my_tids[curthread->td_oncpu]; >> >> /* >> @@ -685,12 +685,9 @@ ctxsw_utow(void) >> if (t->tid_self != t) >> x86_newldt(NULL); >> >> - x86_critical_enter(); >> t->tid_oldfs = x86_getfs(); >> t->tid_cpu = curthread->td_oncpu; >> - sched_pin(); >> x86_setfs(SEL_TO_FS(t->tid_selector)); >> - x86_critical_exit(); >> >> /* Now entering Windows land, population: you. */ >> } >> @@ -706,11 +703,10 @@ ctxsw_wtou(void) >> { >> struct tid *t; >> >> - x86_critical_enter(); >> t = x86_gettid(); >> x86_setfs(t->tid_oldfs); >> + critical_exit(); >> sched_unpin(); >> - x86_critical_exit(); >> >> /* Welcome back to UNIX land, we missed you. */ >> >> diff --git a/sys/compat/ndis/winx32_wrap.S b/sys/compat/ndis/winx32_wrap.S >> index c051504..fa4aa87 100644 >> --- a/sys/compat/ndis/winx32_wrap.S >> +++ b/sys/compat/ndis/winx32_wrap.S >> @@ -375,11 +375,3 @@ ENTRY(x86_setfs) >> ENTRY(x86_gettid) >> mov %fs:12,%eax >> ret >> - >> -ENTRY(x86_critical_enter) >> - cli >> - ret >> - >> -ENTRY(x86_critical_exit) >> - sti >> - ret >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > > > > -- > Bernhard > From owner-freebsd-net@FreeBSD.ORG Wed Oct 20 20:53:13 2010 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 1BDD91065670; Wed, 20 Oct 2010 20:53:13 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 78DCA8FC16; Wed, 20 Oct 2010 20:53:12 +0000 (UTC) Received: by ewy21 with SMTP id 21so2791917ewy.13 for ; Wed, 20 Oct 2010 13:53:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=UWt0dHlGRTQr5n87BpAGxbwucqshBBcLbHMTUjyvYOY=; b=flh9PjkbuCoQqtH1pfgkeYrhVmWMphZLvcALsCRZdZl1etV23GwJEqeiHI49OYnJ5m MPSLyg1JvL7AhFc0u0My8cMYCwrE0X3saVbBHippvySrVC75x2aFyUJ9UXZH8PY/iK0L ObuI7px9dsx78lGMcRsOxvoQlSqWIpJRFQZEY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=BOceohfc7NwOH+2uC5iFBliyXjU4Ihf4B0jwViGkq9HkS6hYm1zB+rT0SyY+mlAUBU RULomogVrJETZIjr3Ii3zC/MHTZXKY3IefiyTQtBO19Owk6kWwClEGG/ZV12sKmW8TXj t/KirznHTfggXUh8KkNcEs8+/h2Tklt/KOhCE= MIME-Version: 1.0 Received: by 10.216.236.42 with SMTP id v42mr8768434weq.10.1287607991193; Wed, 20 Oct 2010 13:53:11 -0700 (PDT) Received: by 10.216.232.132 with HTTP; Wed, 20 Oct 2010 13:53:11 -0700 (PDT) Date: Wed, 20 Oct 2010 13:53:11 -0700 Message-ID: From: Jack Vogel To: FreeBSD Net , FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: IPV6 Checksum offload and TSO6 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 20:53:13 -0000 I had occasion to think about this, and I was wondering if someone is working to add either or both of these features, Intel's hardware supports it, it does not seem that hard to add, or am I missing something? Cheers, Jack From owner-freebsd-net@FreeBSD.ORG Wed Oct 20 22:20:39 2010 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 88E3E106564A; Wed, 20 Oct 2010 22:20:39 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 180C38FC12; Wed, 20 Oct 2010 22:20:39 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 4A3A841C710; Thu, 21 Oct 2010 00:20:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id QUYLdw37ZSmB; Thu, 21 Oct 2010 00:20:36 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 88AB341C71D; Thu, 21 Oct 2010 00:20:36 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 5C1EC44496D; Wed, 20 Oct 2010 22:20:15 +0000 (UTC) Date: Wed, 20 Oct 2010 22:20:15 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Jack Vogel In-Reply-To: Message-ID: <20101020221142.L66242@maildrop.int.zabbadoz.net> References: X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Net , FreeBSD Current Subject: Re: IPV6 Checksum offload and TSO6 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 22:20:39 -0000 On Wed, 20 Oct 2010, Jack Vogel wrote: Hi, > I had occasion to think about this, and I was wondering if someone is > working to add > either or both of these features, Intel's hardware supports it, it does not > seem that > hard to add, or am I missing something? Strange that I had been thinking of that last night and talking to poeple today. It's kind of on the roadmap here for mid-November. It's mostly freebsd infrastructure that's missing for it (along with some cleanup on the flags in a couple of places). tuexen@ wanted to get the CSUM_* stuff done for SCTP as well but I haven't re-pinged him on that one yet. Do you know if we have Intel cards in the netperf cluster that can actually do it for testing? What's the matrix for the various cards for v6 offloads? TCP/UDP/SCTP? IP? TSO? TOE? Imho noone does TOE6 yet (correct me if wrong) but I'd like to get the others all sorted then. /bz -- Bjoern A. Zeeb Welcome a new stage of life. Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html From owner-freebsd-net@FreeBSD.ORG Wed Oct 20 22:52:54 2010 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 ABEF4106564A; Wed, 20 Oct 2010 22:52:54 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 9AD268FC0A; Wed, 20 Oct 2010 22:52:53 +0000 (UTC) Received: by wwb13 with SMTP id 13so3383134wwb.31 for ; Wed, 20 Oct 2010 15:52:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=5bFxbqWdbnRws+HZ6CJ5lL96Jf+B1c48Vt3pHudMsUM=; b=ksLBefcWIXIsBXuiC1TznLgTj379zNz6Dg7J576bbOx/S7YzxosLPDz1mzW7kPfBwD /YDNJFq/cEVBKzzTYAXujHoRJRlhfL/7yfPZGs8YGF+hJJjHi9zsU0aaInZzcl6JF2aR YH79l2UqJZlQd4PTzK777E2JdmPIPPCBUjNzY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=PXCly3g9s0okyHQzoJmupj0vPPFJu5VrSTeirGQGQ8S0IGpNtDt973vanrEU0gNxWQ o2RgK5gFVnqpbVydx5c1ya3ojy1DtkIWiFOLFehAIw7sCdmzv+xIrAR6Ql8pRKNRSMXC kfJt6BVhKFwggrlfwxgC3mpOLqX3pQpug+P5U= MIME-Version: 1.0 Received: by 10.216.6.133 with SMTP id 5mr8845445wen.32.1287615171521; Wed, 20 Oct 2010 15:52:51 -0700 (PDT) Received: by 10.216.232.132 with HTTP; Wed, 20 Oct 2010 15:52:51 -0700 (PDT) In-Reply-To: <20101020221142.L66242@maildrop.int.zabbadoz.net> References: <20101020221142.L66242@maildrop.int.zabbadoz.net> Date: Wed, 20 Oct 2010 15:52:51 -0700 Message-ID: From: Jack Vogel To: "Bjoern A. Zeeb" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Net , FreeBSD Current Subject: Re: IPV6 Checksum offload and TSO6 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 22:52:54 -0000 Looked to me like Michael already has the SCTP stuff in the inet6 code. Not sure if it needs further enabling or what?? I'm not positive about what cards are in the netperf cluster. Any card that em, igb, and ixgbe supports can do the TCP/UDP checksum offloads whether in IPv4 or 6 if handed to it. TSO is a TCP segmentation so it also is a matter of IPv6 allowing it to do so, at least that is my present understanding. SCTP offload can only be handled in the igb and ixgbe drivers, none of the em hardware can do it (at least not as of today). Personally its TSO that I care most about, but the protocol checksums might as well be available too. Jack On Wed, Oct 20, 2010 at 3:20 PM, Bjoern A. Zeeb wrote: > On Wed, 20 Oct 2010, Jack Vogel wrote: > > Hi, > > > I had occasion to think about this, and I was wondering if someone is >> working to add >> either or both of these features, Intel's hardware supports it, it does >> not >> seem that >> hard to add, or am I missing something? >> > > Strange that I had been thinking of that last night and talking to > poeple today. It's kind of on the roadmap here for mid-November. > > It's mostly freebsd infrastructure that's missing for it (along with > some cleanup on the flags in a couple of places). tuexen@ wanted to > get the CSUM_* stuff done for SCTP as well but I haven't re-pinged > him on that one yet. > > Do you know if we have Intel cards in the netperf cluster that can > actually do it for testing? What's the matrix for the various cards > for v6 offloads? > TCP/UDP/SCTP? > IP? > TSO? > TOE? > > Imho noone does TOE6 yet (correct me if wrong) but I'd like to get > the others all sorted then. > > /bz > > -- > Bjoern A. Zeeb Welcome a new stage of life. > Going to jail sucks -- All my daemons like it! > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html > From owner-freebsd-net@FreeBSD.ORG Thu Oct 21 15:48:36 2010 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 37296106564A for ; Thu, 21 Oct 2010 15:48:36 +0000 (UTC) (envelope-from thomas.sevestre@tcare.fr) Received: from smtp19.orange.fr (smtp19.orange.fr [80.12.242.17]) by mx1.freebsd.org (Postfix) with ESMTP id F0CA48FC0C for ; Thu, 21 Oct 2010 15:48:35 +0000 (UTC) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf1912.orange.fr (SMTP Server) with ESMTP id F406F2000251 for ; Thu, 21 Oct 2010 17:26:17 +0200 (CEST) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf1912.orange.fr (SMTP Server) with ESMTP id E2A8E20006BD for ; Thu, 21 Oct 2010 17:26:17 +0200 (CEST) Received: from [192.168.1.32] (APuteaux-755-1-2-136.w90-35.abo.wanadoo.fr [90.35.33.136]) by mwinf1912.orange.fr (SMTP Server) with ESMTP id B14A42000251 for ; Thu, 21 Oct 2010 17:26:17 +0200 (CEST) X-ME-UUID: 20101021152617726.B14A42000251@mwinf1912.orange.fr Message-Id: <4EC6D4D7-3D86-45A1-B804-96F548CB5254@tcare.fr> From: Thomas Sevestre To: freebsd-net@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 21 Oct 2010 17:26:17 +0200 X-Mailer: Apple Mail (2.936) Subject: Tcpdump showing ghost traffic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 15:48:36 -0000 Hi all, I'm using freebsd 8 as a router. Say I have a sis0 interface. The interface is up and negociated, Ethernet LEDs are fine. Sometimes tcpdump shows traffic on the interface (tcpdump -lni sis0) but traffic LEDs doesn't blink and there is nothing going out of the router. Do you have any idea of what the problem could be? May be a link-layer driver bug? Thanks, Thomas From owner-freebsd-net@FreeBSD.ORG Fri Oct 22 02:02:10 2010 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 5DB6C106564A for ; Fri, 22 Oct 2010 02:02:10 +0000 (UTC) (envelope-from RCharlet@adaranet.com) Received: from barracuda.adaranet.com (smtp.adaranet.com [72.5.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 3942C8FC16 for ; Fri, 22 Oct 2010 02:02:09 +0000 (UTC) X-ASG-Debug-ID: 1287708243-0d0fb0d30001-QdxwpM Received: from SJ-EXCH-1.adaranet.com ([10.10.1.29]) by barracuda.adaranet.com with ESMTP id AnMHSw2u7YmugA7P for ; Thu, 21 Oct 2010 17:44:03 -0700 (PDT) X-Barracuda-Envelope-From: RCharlet@adaranet.com Received: from SJ-EXCH-1.adaranet.com ([fe80::7042:d8c2:5973:c523]) by SJ-EXCH-1.adaranet.com ([fe80::7042:d8c2:5973:c523%14]) with mapi; Thu, 21 Oct 2010 17:44:03 -0700 From: "Ricky Charlet" X-Barracuda-BBL-IP: fe80::7042:d8c2:5973:c523 X-Barracuda-RBL-IP: fe80::7042:d8c2:5973:c523 To: "freebsd-net@freebsd.org" Date: Thu, 21 Oct 2010 17:43:56 -0700 X-ASG-Orig-Subj: crashing problem I cant figure related to IF_ADDR_LOCK, BSD 8.0 Thread-Topic: crashing problem I cant figure related to IF_ADDR_LOCK, BSD 8.0 Thread-Index: ActxgjWBo5rfso0KSKCUpWP0Q92utQ== Message-ID: <32AB5C9615CC494997D9ABB1DB12783C024C9C16CC@SJ-EXCH-1.adaranet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Barracuda-Connect: UNKNOWN[10.10.1.29] X-Barracuda-Start-Time: 1287708243 X-Barracuda-URL: http://172.16.10.203:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at adaranet.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: crashing problem I cant figure related to IF_ADDR_LOCK, BSD 8.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2010 02:02:10 -0000 Howdy, FreeBSD 8.0-RELEASE running on an 8 core amd64 I'm writing a packet filter hook. It is an outbound hook at= tached with : pfil_add_hook(chkoutput, NULL, PFIL_OUT | PFIL_WAITOK, pfh_= inet); Inside the hook (chkoutput) I have the following code snipi= t (where I happen to know that ifp already points to an interface I specifi= cally don't want to process packets for): IF_ADDR_LOCK(ifp); TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_l= ink) { if (ifa->ifa_addr->sa_family =3D=3D AF_INET= ) { struct sockaddr_in *sa =3D = (struct sockaddr_in*)ifa->ifa_addr; if(sa->sin_addr.s_addr =3D= =3D ip->ip_src.s_addr) { /* nevermin= d */ IF_ADDR_UNL= OCK(ifp); return 0; } } } IF_ADDR_UNLOCK(ifp); Well, it runs fine / logically sound / does exactly what I = want. However, in later processing, on packets I am receiving (*not* traver= sing the output hook) I crash with various stack traces but all culminating= in sbdrop_internal. In that function, I have a pointer to an mbuf which i= s garbage (unreferencable) memory. - If I take the above code snipit out of my output hook, the syste= m remains stable. (though, of course, the hook is not doing all I want) - If I remove the LOCK and UNLOCK macros, the same crash happens. - If I take IFNET_RLOCK_NOSLEEP or IFNET_RLOCK, same crash happens= . I'm fairly convinced that my output hook at the IP layer is somehow corrupt= ing the receive socket layer. But I see no relationship. Even if I were run= ning beyond loop bounds here, I'm not really writing any memory. On the oth= er hand, I don't truly know my way around dealing with kernel locks and I'm= just mimicking code I saw in ip_input (the "Check for broadcast addresses= " bits). Any Ideas? Thanks in advance --- Ricky Charlet Adara Networks USA 408-433-4942 PS Some kgdb output here: #10 0xffffffff80860183 in calltrap () at /usr/src/sys/amd64/amd64/exception= .S:224 #11 0xffffffff805ec873 in sbdrop_internal (sb=3D0xffffff0001b976d0, len=3D0= ) at /usr/src/sys/kern/uipc_sockbuf.c:891 #12 0xffffffff806ff187 in tcp_do_segment (m=3D0xffffff000185f200, th=3D0xffffff00018f0024, so=3D0xffffff0001b97550, tp=3D0xffffff0001b24a= 50, drop_hdrlen=3D40, tlen=3D0, iptos=3D0 '\0', ti_locked=3D2) at /usr/src/sys/netinet/tcp_input.c:2357 #13 0xffffffff80700f72 in tcp_input (m=3D0xffffff000185f200, off0=3DVariabl= e "off0" is not available. ) at /usr/src/sys/netinet/tcp_input.c:1020 #14 0xffffffff806984ba in ip_input (m=3D0xffffff000185f200) ---Type to continue, or q to quit--- at /usr/src/sys/netinet/ip_input.c:775 #15 0xffffffff806423ee in netisr_dispatch_src (proto=3D1, source=3DVariable= "source" is not available. ) at /usr/src/sys/net/netisr.c:917 #16 0xffffffff8063ab2d in ether_demux (ifp=3D0xffffff0001579000, m=3D0xffff= ff000185f200) at /usr/src/sys/net/if_ethersubr.c:895 (kgdb) frame 11 #11 0xffffffff805ec873 in sbdrop_internal (sb=3D0xffffff0001b976d0, len=3D0= ) at /usr/src/sys/kern/uipc_sockbuf.c:891 891 if (m =3D=3D NULL) { (kgdb) print *sb $1 =3D {sb_sel =3D {si_tdlist =3D {tqh_first =3D 0x0, tqh_last =3D 0x0}, si= _note =3D {kl_list =3D { slh_first =3D 0x0}, kl_lock =3D 0xffffffff8055bf00 , kl_unlock =3D 0xffffffff8055bed0 , kl_assert_locked =3D 0xffffffff80559220 , kl_assert_unlocked =3D 0xffffffff80559230 , kl_lockarg =3D 0xffffff0001b97718}, si_mtx =3D 0x0}, sb_mtx =3D {lock= _object =3D { lo_name =3D 0xffffffff8096f9d5 "so_snd", lo_flags =3D 16973824, lo_da= ta =3D 0, lo_witness =3D 0x0}, mtx_lock =3D 18446742974221313824}, sb_sx =3D {l= ock_object =3D { lo_name =3D 0xffffffff8096ff95 "so_snd_sx", lo_flags =3D 36896768, lo= _data =3D 0, lo_witness =3D 0x0}, sx_lock =3D 1}, sb_state =3D 0, sb_mb =3D 0x8c46= 00000000, sb_mbtail =3D 0xffffff0001901900, sb_lastrecord =3D 0xffffff0001901900, sb_sndptr =3D 0x0, sb_sndptroff =3D 0, sb_cc =3D 0, sb_hiwat =3D 33580, s= b_mbcnt =3D 0, sb_mcnt =3D 0, sb_ccnt =3D 0, sb_mbmax =3D 262144, sb_ctl =3D 0, sb_lowat= =3D 2048, sb_timeo =3D 0, sb_flags =3D 2048, sb_upcall =3D 0, sb_upcallarg =3D 0x0} (kgdb) print *sb->sb_mb Cannot access memory at address 0x8c4600000000 (kgdb) From owner-freebsd-net@FreeBSD.ORG Fri Oct 22 07:10:53 2010 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 2133F106566B; Fri, 22 Oct 2010 07:10:53 +0000 (UTC) (envelope-from gsriram@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id DB4AD8FC1C; Fri, 22 Oct 2010 07:10:52 +0000 (UTC) Received: by pzk37 with SMTP id 37so85259pzk.13 for ; Fri, 22 Oct 2010 00:10:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=bTKqiuVAjtPR8lhlempYHrZEOffJpQ+Wli6BLwL05Ks=; b=m4eAVYJGtROxuYY+cMd+0KQldjEdMdeb/fwioDN2R8kWaEcrfrl8RkFbo8Kk79RPan m5NJWASNJiGGy8Lcrv3n6olqxqAaJC+hxQt2X2qoO+sKJ4C1/XdCz4F8Kg/TJcNKLkmE jJmrHYgmrAUCqQ95ydDyT2lHHW5jKfhwEo4wk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=XpsG0wsy/FM9Ja131eQXouJBEZqINTFneO1cseJPt3fZMRuraLQ36vEhSlAukRor4f 0BhXj0GNV7HRvyiang2tb1B6cRxWuwAa4B3hTprJoZHrVmetZogt7EqkpYfcEmF5xUtI 1rz3xKth/883pTXCm8yBeQGaQTg6U5kHKWYIg= MIME-Version: 1.0 Received: by 10.142.153.2 with SMTP id a2mr1652797wfe.380.1287731452257; Fri, 22 Oct 2010 00:10:52 -0700 (PDT) Received: by 10.143.156.8 with HTTP; Fri, 22 Oct 2010 00:10:52 -0700 (PDT) In-Reply-To: <4CBB6CE9.1030009@freebsd.org> References: <4CA5D1F0.3000307@freebsd.org> <4CA9B6AC.20403@freebsd.org> <4CBB6CE9.1030009@freebsd.org> Date: Fri, 22 Oct 2010 12:40:52 +0530 Message-ID: From: Sriram Gorti To: Lawrence Stewart Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, Andre Oppermann Subject: Re: Question on TCP reassembly counter X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2010 07:10:53 -0000 Hi, On Mon, Oct 18, 2010 at 3:08 AM, Lawrence Stewart wr= ote: > On 10/04/10 22:12, Lawrence Stewart wrote: >> On 10/01/10 22:20, Andre Oppermann wrote: >>> On 01.10.2010 12:01, Sriram Gorti wrote: >>>> Hi, >>>> >>>> In the following is an observation when testing our XLR/XLS network >>>> driver with 16 concurrent instances of netperf on FreeBSD-CURRENT. >>>> Based on this observation, I have a question on which I hope to get >>>> some understanding from here. >>>> >>>> When running 16 concurrent netperf instances (each for about 20 >>>> seconds), it was found that after some number of runs performance >>>> degraded badly (almost by a factor of 5). All subsequent runs remained >>>> so. Started debugging this from TCP-side as other driver tests were >>>> doing fine for comparably long durations on same board+s/w. >>>> >>>> netstat indicated the following: >>>> >>>> $ netstat -s -f inet -p tcp | grep discarded >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A00 discarded for bad checksums >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A00 discarded for bad header offset f= ields >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A00 discarded because packet too shor= t >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A07318 discarded due to memory proble= ms >>>> >>>> Then, traced the "discarded due to memory problems" to the following >>>> counter: >>>> >>>> $ sysctl -a net.inet.tcp.reass >>>> net.inet.tcp.reass.overflows: 7318 >>>> net.inet.tcp.reass.maxqlen: 48 >>>> net.inet.tcp.reass.cursegments: 1594<--- // corresponds to >>>> V_tcp_reass_qsize variable >>>> net.inet.tcp.reass.maxsegments: 1600 >>>> >>>> Our guess for the need for reassembly (in this low-packet-loss test >>>> setup) was the lack of per-flow classification in the driver, causing >>>> it to spew incoming packets across the 16 h/w cpus instead of packets >>>> of a flow being sent to the same cpu. While we are working on >>>> addressing this driver limitation, debugged further to see how/why the >>>> V_tcp_reass_qsize grew (assuming that out-of-order segments should >>>> have dropped to zero at the end of the run). It was seen that this >>>> counter was actually growing up from the initial runs but only when it >>>> reached near to maxsgements, perf degradation was seen. Then, started >>>> looking at vmstat also to see how many of the reassembly segments were >>>> lost. But, there were no segments lost. We could not reconcile "no >>>> lost segments" with "growth of this counter across test runs". >>> >>> A patch is in the works to properly autoscale the reassembly queue >>> and should be comitted shortly. >>> >>>> $ sysctl net.inet.tcp.reass ; vmstat -z | egrep "FREE|mbuf|tcpre" >>>> net.inet.tcp.reass.overflows: 0 >>>> net.inet.tcp.reass.maxqlen: 48 >>>> net.inet.tcp.reass.cursegments: 147 >>>> net.inet.tcp.reass.maxsegments: 1600 >>>> ITEM =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 SIZE =A0LIMIT =A0 =A0 USED = =A0 =A0 FREE =A0 =A0 =A0REQ FAIL SLEEP >>>> mbuf_packet: =A0 =A0 =A0 =A0 =A0 =A0256, =A0 =A0 =A00, =A0 =A04096, = =A0 =A03200, 5653833, =A0 0, =A0 0 >>>> mbuf: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 256, =A0 =A0 =A00, =A0 =A0 = =A0 1, =A0 =A02048, 4766910, =A0 0, =A0 0 >>>> mbuf_cluster: =A0 =A0 =A0 =A0 =A02048, =A025600, =A0 =A07296, =A0 =A0 = =A0 6, =A0 =A07297, =A0 0, =A0 0 >>>> mbuf_jumbo_page: =A0 =A0 =A0 4096, =A012800, =A0 =A0 =A0 0, =A0 =A0 = =A0 0, =A0 =A0 =A0 0, =A0 0, =A0 0 >>>> mbuf_jumbo_9k: =A0 =A0 =A0 =A0 9216, =A0 6400, =A0 =A0 =A0 0, =A0 =A0 = =A0 0, =A0 =A0 =A0 0, =A0 0, =A0 0 >>>> mbuf_jumbo_16k: =A0 =A0 =A0 16384, =A0 3200, =A0 =A0 =A0 0, =A0 =A0 = =A0 0, =A0 =A0 =A0 0, =A0 0, =A0 0 >>>> mbuf_ext_refcnt: =A0 =A0 =A0 =A0 =A04, =A0 =A0 =A00, =A0 =A0 =A0 0, = =A0 =A0 =A0 0, =A0 =A0 =A0 0, =A0 0, =A0 0 >>>> tcpreass: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A020, =A0 1690, =A0 =A0 =A0 0, = =A0 =A0 845, 1757074, =A0 0, =A0 0 >>>> >>>> In view of these observations, my question is: is it possible for the >>>> V_tcp_reass_qsize variable to be unsafely updated on SMP ? (The >>>> particular flavor of XLS that was used in the test had 4 cores with 4 >>>> h/w threads/core). I see that the tcp_reass function assumes some lock >>>> is taken but not sure if it is the per-socket or the global tcp lock. >>> >>> The updating of the global counter is indeed unsafe and becomes obsolet= e >>> with the autotuning patch. >>> >>> The patch is reviewed by me and ready for commit. =A0However lstewart@ = is >>> currently writing his thesis and has only very little spare time. =A0I'= ll >>> send you the patch in private email so you can continue your testing. >> >> Quick update on this: patch is blocked while waiting for Jeff to review >> some related UMA changes. As soon as I get the all clear I'll push >> everything into head. > > Revision 213913 of the svn head branch finally has all patches. If you > encounter any additional odd behaviour related to reassembly or notice > net.inet.tcp.reass.overflows increasing, please let me know. > Thanks for the fix. Tried it on XLR/XLS and the earlier tests pass now. net.inet.tcp.reass.overflows was always zero after the tests (and in the samples I took while the tests were running). One observation though: net.inet.tcp.reass.cursegments was non-zero (it was just 1) after 30 rounds, where each round is (as earlier) 15-concurrent instances of netperf for 20s. This was on the netserver side. And, it was zero before the netperf runs. On the other hand, Andre told me (in a separate mail) that this counter is not relevant anymore - so, should I just ignore it ? --- Sriram Gorti > Cheers, > Lawrence > From owner-freebsd-net@FreeBSD.ORG Fri Oct 22 07:59:57 2010 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 7E9DB106566C for ; Fri, 22 Oct 2010 07:59:57 +0000 (UTC) (envelope-from thomas.sevestre@tcare.fr) Received: from smtp2f.orange.fr (smtp2f.orange.fr [80.12.242.151]) by mx1.freebsd.org (Postfix) with ESMTP id 4191B8FC22 for ; Fri, 22 Oct 2010 07:59:57 +0000 (UTC) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2f11.orange.fr (SMTP Server) with ESMTP id 002E9800055C; Fri, 22 Oct 2010 09:59:56 +0200 (CEST) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2f11.orange.fr (SMTP Server) with ESMTP id E7E8E8000568; Fri, 22 Oct 2010 09:59:55 +0200 (CEST) Received: from [192.168.1.32] (APuteaux-755-1-9-124.w90-35.abo.wanadoo.fr [90.35.36.124]) by mwinf2f11.orange.fr (SMTP Server) with ESMTP id A8F8D800055C; Fri, 22 Oct 2010 09:59:55 +0200 (CEST) X-ME-UUID: 20101022075955692.A8F8D800055C@mwinf2f11.orange.fr Message-Id: From: Thomas Sevestre To: Julian Elischer , freebsd-net@freebsd.org In-Reply-To: <4CC072A3.1090402@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 22 Oct 2010 09:59:55 +0200 References: <4EC6D4D7-3D86-45A1-B804-96F548CB5254@tcare.fr> <4CC072A3.1090402@freebsd.org> X-Mailer: Apple Mail (2.936) Cc: Subject: Re: Tcpdump showing ghost traffic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2010 07:59:57 -0000 =09 Le 21 oct. 10 =E0 19:04, Julian Elischer a =E9crit : > On 10/21/10 8:26 AM, Thomas Sevestre wrote: >> Hi all, >> >> I'm using freebsd 8 as a router. Say I have a sis0 interface. The =20 >> interface is up and negociated, Ethernet LEDs are fine. >> Sometimes tcpdump shows traffic on the interface (tcpdump -lni =20 >> sis0) but traffic LEDs doesn't blink and there is nothing going out =20= >> of the router. >> >> Do you have any idea of what the problem could be? >> May be a link-layer driver bug? > > who is the traffic for and from? For instance, the router is pinging some address on his LAN. In this =20 case I had a machine wired directly to the router. By the way, it is not a firewall issue, packets wasn't blocked. > >> >> Thanks, >> Thomas >> >> >> >> >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-=20 >> unsubscribe@freebsd.org" >> > > From owner-freebsd-net@FreeBSD.ORG Fri Oct 22 10:30:46 2010 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 A58851065698 for ; Fri, 22 Oct 2010 10:30:46 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 200EF8FC22 for ; Fri, 22 Oct 2010 10:30:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id o9MAUhWW087729; Fri, 22 Oct 2010 21:30:44 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Fri, 22 Oct 2010 21:30:43 +1100 (EST) From: Ian Smith To: Thomas Sevestre In-Reply-To: Message-ID: <20101022205444.V9562@sola.nimnet.asn.au> References: <4EC6D4D7-3D86-45A1-B804-96F548CB5254@tcare.fr> <4CC072A3.1090402@freebsd.org> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-883686648-1287743443=:9562" Cc: freebsd-net@freebsd.org Subject: Re: Tcpdump showing ghost traffic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2010 10:30:46 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-883686648-1287743443=:9562 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Fri, 22 Oct 2010, Thomas Sevestre wrote: > Le 21 oct. 10 à > 19:04, Julian Elischer a écrit : > > > On 10/21/10 8:26 AM, Thomas Sevestre wrote: > > > Hi all, > > > > > > I'm using freebsd 8 as a router. Say I have a sis0 interface. The > > > interface is up and negociated, Ethernet LEDs are fine. > > > Sometimes tcpdump shows traffic on the interface (tcpdump -lni sis0) but > > > traffic LEDs doesn't blink and there is nothing going out of the router. > > > > > > Do you have any idea of what the problem could be? > > > May be a link-layer driver bug? > > > > who is the traffic for and from? > > For instance, the router is pinging some address on his LAN. In this case I > had a machine wired directly to the router. > By the way, it is not a firewall issue, packets wasn't blocked. tcpdump is in promiscuous mode, also seeing any traffic visible on the wire for other than your MAC address. Is there any of that? Would the LEDs flash when receiving that? Is the LAN off a switch, or a hub? Details like ifconfig and tcpdump output might help, obscured as needed. cheers, Ian --0-883686648-1287743443=:9562-- From owner-freebsd-net@FreeBSD.ORG Fri Oct 22 21:20:52 2010 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B53A106564A for ; Fri, 22 Oct 2010 21:20:52 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from mail2.timeinc.net (mail2.timeinc.net [64.236.74.30]) by mx1.freebsd.org (Postfix) with ESMTP id 052B28FC08 for ; Fri, 22 Oct 2010 21:20:51 +0000 (UTC) Received: from mail.timeinc.net (mail.timeinc.net [64.12.55.166]) by mail2.timeinc.net (8.13.8/8.13.8) with ESMTP id o9ML9XWu026973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Oct 2010 17:09:33 -0400 Received: from ws-mteterin.dev.pathfinder.com (ws-mteterin.dev.pathfinder.com [209.251.223.173]) by mail.timeinc.net (8.13.8/8.13.8) with SMTP id o9ML9XeQ019856; Fri, 22 Oct 2010 17:09:33 -0400 Message-ID: <4CC1FD8D.7000108@aldan.algebra.com> Date: Fri, 22 Oct 2010 17:09:33 -0400 From: "Mikhail T." Organization: Virtual Estates, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; uk; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: net@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: wpaul@ctr.columbia.edu Subject: Strange problem with sk0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2010 21:20:52 -0000 Hello! I have a rather bizarre problem with my on-board sk interface... It only works, when tcpdump is running... Seriously. It negotiates with the switch (1000baseT/full-duplex) just fine, but, unless tcpdump has it open (and in "promiscuous" mode), no traffic seems to go through. It would not respond to pings -- not even from the switch itself, nothing. But, as soon as I start tcpdump -- even if tcpdump never has anything to output: tcpdump -i sk0 -n src host 10.non.existent.IP Traffic starts flowing just fine... Do I simply have flaky hardware? The motherboard is old, and, for some reason, I need to "remind" sk0, what its ethernet address upon reboote (it starts off with 00:00:00:00:00:00). Any other explanations for what is happening? There are plenty of other systems (computers, VoIP phone, two TVs) on this switch and all are fine... I did try different ports on it -- same results. I also tried forcing things down to 100/half-duplex -- no change... Thanks! Yours, -mi From owner-freebsd-net@FreeBSD.ORG Fri Oct 22 23:38:21 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A4AB106564A for ; Fri, 22 Oct 2010 23:38:21 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id E484B8FC0C for ; Fri, 22 Oct 2010 23:38:20 +0000 (UTC) Received: by gxk2 with SMTP id 2so1130530gxk.13 for ; Fri, 22 Oct 2010 16:38:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=vQOfy9niFIKORj+l07s3Kvz9fKgTIrQc3AxhaCTQktI=; b=dmYyk6V6ydMxLvB+YDYNkJ3mJrbrGQxDj47VqLUJsW5HDpaiNtwWQ94ESnTUmBLvdm Wgb1zHAwubSq3fYkeJQ2AiychoRq/SYtH59tSmv8atvXcJkkb9R594swXBUEom5XKo3G Dngppk39vp1sH7hH+FzwJMGRLmtu8ON+Dym/A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=csY/5eGf3Qq/xmp7xsaMWawDHlpYWVqlxrHzWGtQ3ih1IHkdEHEjfU0JiqbZ3IURwW mk/AxOyEcmBgETrNPCdzsZGQQp81LJo90ZRdVadxLx7pFvQMesXhorPAbngU7I3HKbbo X3gbAttRnB5hS4arU2rPSsKae+M3olU4j95YI= Received: by 10.151.6.9 with SMTP id j9mr4438572ybi.372.1287789140105; Fri, 22 Oct 2010 16:12:20 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id v12sm3906579ybk.11.2010.10.22.16.12.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 22 Oct 2010 16:12:18 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 22 Oct 2010 16:10:44 -0700 From: Pyun YongHyeon Date: Fri, 22 Oct 2010 16:10:44 -0700 To: "Mikhail T." Message-ID: <20101022231044.GC17093@michelle.cdnetworks.com> References: <4CC1FD8D.7000108@aldan.algebra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CC1FD8D.7000108@aldan.algebra.com> User-Agent: Mutt/1.4.2.3i Cc: wpaul@ctr.columbia.edu, net@freebsd.org Subject: Re: Strange problem with sk0 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, 22 Oct 2010 23:38:21 -0000 On Fri, Oct 22, 2010 at 05:09:33PM -0400, Mikhail T. wrote: > Hello! > > I have a rather bizarre problem with my on-board sk interface... It only > works, when tcpdump is running... > > Seriously. It negotiates with the switch (1000baseT/full-duplex) just > fine, but, unless tcpdump has it open (and in "promiscuous" mode), no > traffic seems to go through. It would not respond to pings -- not even > from the switch itself, nothing. > > But, as soon as I start tcpdump -- even if tcpdump never has anything to > output: > > tcpdump -i sk0 -n src host 10.non.existent.IP > > Traffic starts flowing just fine... Do I simply have flaky hardware? The > motherboard is old, and, for some reason, I need to "remind" sk0, what > its ethernet address upon reboote (it starts off with 00:00:00:00:00:00). > The all 0 station address is clear indication of source of problem. Normally ethernet controllers drop frames not destined for the station address unless promiscuous mode is activated. tcpdump is one of program that activates the promiscuous mode. To narrow down the issue, show me the output both dmesg and pciconf -lvcb. > Any other explanations for what is happening? There are plenty of other > systems (computers, VoIP phone, two TVs) on this switch and all are > fine... I did try different ports on it -- same results. I also tried > forcing things down to 100/half-duplex -- no change... > It seems sk(4) failed to extract station address from controller so I have to know why it happens on your box. > Thanks! Yours, > > -mi From owner-freebsd-net@FreeBSD.ORG Fri Oct 22 23:59:15 2010 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 3D1AB1065675; Fri, 22 Oct 2010 23:59:15 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id AF9828FC29; Fri, 22 Oct 2010 23:59:14 +0000 (UTC) Received: from lawrence1.loshell.room52.net (ppp59-167-184-191.static.internode.on.net [59.167.184.191]) by lauren.room52.net (Postfix) with ESMTPSA id 55FD27E87B; Sat, 23 Oct 2010 10:59:12 +1100 (EST) Message-ID: <4CC2254C.7070104@freebsd.org> Date: Sat, 23 Oct 2010 10:59:08 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-AU; rv:1.9.2.9) Gecko/20101006 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Sriram Gorti References: <4CA5D1F0.3000307@freebsd.org> <4CA9B6AC.20403@freebsd.org> <4CBB6CE9.1030009@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lauren.room52.net Cc: freebsd-net@freebsd.org, Andre Oppermann Subject: Re: Question on TCP reassembly counter X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2010 23:59:15 -0000 On 10/22/10 18:10, Sriram Gorti wrote: > Hi, > > On Mon, Oct 18, 2010 at 3:08 AM, Lawrence Stewart wrote: >> On 10/04/10 22:12, Lawrence Stewart wrote: >>> On 10/01/10 22:20, Andre Oppermann wrote: >>>> On 01.10.2010 12:01, Sriram Gorti wrote: >>>>> Hi, >>>>> >>>>> In the following is an observation when testing our XLR/XLS network >>>>> driver with 16 concurrent instances of netperf on FreeBSD-CURRENT. >>>>> Based on this observation, I have a question on which I hope to get >>>>> some understanding from here. >>>>> >>>>> When running 16 concurrent netperf instances (each for about 20 >>>>> seconds), it was found that after some number of runs performance >>>>> degraded badly (almost by a factor of 5). All subsequent runs remained >>>>> so. Started debugging this from TCP-side as other driver tests were >>>>> doing fine for comparably long durations on same board+s/w. >>>>> >>>>> netstat indicated the following: >>>>> >>>>> $ netstat -s -f inet -p tcp | grep discarded >>>>> 0 discarded for bad checksums >>>>> 0 discarded for bad header offset fields >>>>> 0 discarded because packet too short >>>>> 7318 discarded due to memory problems >>>>> >>>>> Then, traced the "discarded due to memory problems" to the following >>>>> counter: >>>>> >>>>> $ sysctl -a net.inet.tcp.reass >>>>> net.inet.tcp.reass.overflows: 7318 >>>>> net.inet.tcp.reass.maxqlen: 48 >>>>> net.inet.tcp.reass.cursegments: 1594<--- // corresponds to >>>>> V_tcp_reass_qsize variable >>>>> net.inet.tcp.reass.maxsegments: 1600 >>>>> >>>>> Our guess for the need for reassembly (in this low-packet-loss test >>>>> setup) was the lack of per-flow classification in the driver, causing >>>>> it to spew incoming packets across the 16 h/w cpus instead of packets >>>>> of a flow being sent to the same cpu. While we are working on >>>>> addressing this driver limitation, debugged further to see how/why the >>>>> V_tcp_reass_qsize grew (assuming that out-of-order segments should >>>>> have dropped to zero at the end of the run). It was seen that this >>>>> counter was actually growing up from the initial runs but only when it >>>>> reached near to maxsgements, perf degradation was seen. Then, started >>>>> looking at vmstat also to see how many of the reassembly segments were >>>>> lost. But, there were no segments lost. We could not reconcile "no >>>>> lost segments" with "growth of this counter across test runs". >>>> >>>> A patch is in the works to properly autoscale the reassembly queue >>>> and should be comitted shortly. >>>> >>>>> $ sysctl net.inet.tcp.reass ; vmstat -z | egrep "FREE|mbuf|tcpre" >>>>> net.inet.tcp.reass.overflows: 0 >>>>> net.inet.tcp.reass.maxqlen: 48 >>>>> net.inet.tcp.reass.cursegments: 147 >>>>> net.inet.tcp.reass.maxsegments: 1600 >>>>> ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP >>>>> mbuf_packet: 256, 0, 4096, 3200, 5653833, 0, 0 >>>>> mbuf: 256, 0, 1, 2048, 4766910, 0, 0 >>>>> mbuf_cluster: 2048, 25600, 7296, 6, 7297, 0, 0 >>>>> mbuf_jumbo_page: 4096, 12800, 0, 0, 0, 0, 0 >>>>> mbuf_jumbo_9k: 9216, 6400, 0, 0, 0, 0, 0 >>>>> mbuf_jumbo_16k: 16384, 3200, 0, 0, 0, 0, 0 >>>>> mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0, 0 >>>>> tcpreass: 20, 1690, 0, 845, 1757074, 0, 0 >>>>> >>>>> In view of these observations, my question is: is it possible for the >>>>> V_tcp_reass_qsize variable to be unsafely updated on SMP ? (The >>>>> particular flavor of XLS that was used in the test had 4 cores with 4 >>>>> h/w threads/core). I see that the tcp_reass function assumes some lock >>>>> is taken but not sure if it is the per-socket or the global tcp lock. >>>> >>>> The updating of the global counter is indeed unsafe and becomes obsolete >>>> with the autotuning patch. >>>> >>>> The patch is reviewed by me and ready for commit. However lstewart@ is >>>> currently writing his thesis and has only very little spare time. I'll >>>> send you the patch in private email so you can continue your testing. >>> >>> Quick update on this: patch is blocked while waiting for Jeff to review >>> some related UMA changes. As soon as I get the all clear I'll push >>> everything into head. >> >> Revision 213913 of the svn head branch finally has all patches. If you >> encounter any additional odd behaviour related to reassembly or notice >> net.inet.tcp.reass.overflows increasing, please let me know. >> > > Thanks for the fix. Tried it on XLR/XLS and the earlier tests pass > now. net.inet.tcp.reass.overflows was always zero after the tests (and > in the samples I took while the tests were running). Great, thanks for testing. > One observation though: net.inet.tcp.reass.cursegments was non-zero > (it was just 1) after 30 rounds, where each round is (as earlier) > 15-concurrent instances of netperf for 20s. This was on the netserver > side. And, it was zero before the netperf runs. On the other hand, > Andre told me (in a separate mail) that this counter is not relevant > anymore - so, should I just ignore it ? It's relevant, just not guaranteed to be 100% accurate at any given point in time. The value is calculated based on synchronised access to UMA zone stats and unsynchronised access to UMA per-cpu zone stats. The latter is safe, but causes the overall result to potentially be inaccurate due to use of stale data. The accuracy vs overhead tradeoff was deemed worthwhile for informational counters like this one. That being said, I would not expect the value to remain persistently at 1 after all TCP activity has finished on the machine. It won't affect performance, but I'm curious to know if the calculation method has a flaw. I'll try to reproduce locally, but can you please confirm if the value stays at 1 even after many minutes of no TCP activity? Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Sat Oct 23 07:52:24 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF86A106566C; Sat, 23 Oct 2010 07:52:24 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A511A8FC0C; Sat, 23 Oct 2010 07:52:24 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o9N7qOUt029989; Sat, 23 Oct 2010 07:52:24 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o9N7qOEp029985; Sat, 23 Oct 2010 07:52:24 GMT (envelope-from linimon) Date: Sat, 23 Oct 2010 07:52:24 GMT Message-Id: <201010230752.o9N7qOEp029985@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/151593: [igb] [panic] Kernel panic when bringing up igb network adapter with MSI-X enabled X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Oct 2010 07:52:24 -0000 Old Synopsis: Kernel panic when bringing up igb network adapter with MSI-X enabled New Synopsis: [igb] [panic] Kernel panic when bringing up igb network adapter with MSI-X enabled Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Oct 23 07:51:51 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=151593