From owner-freebsd-net@FreeBSD.ORG Sun Apr 1 01:38:50 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 56AEE106566C for ; Sun, 1 Apr 2012 01:38:50 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2B3D88FC0A for ; Sun, 1 Apr 2012 01:38:49 +0000 (UTC) Received: by pbcwz17 with SMTP id wz17so3605839pbc.13 for ; Sat, 31 Mar 2012 18:38:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=CvZ3sCJRFwOFEzp5dAUN8NoJXVj9gmVda1I1v6HHOOw=; b=lBr7VZ39T+IA9qJTlj7cYT7y+KCvBizraUKDZ8tvIgTXcgaC8UfxqIm632m9tXFO/X XqMGXaK4DlmqtupwAfsSKkZRQAFTvCpmu57BB/Cd8Ni6Hxk+JHdpT+ZOQBfsNSzNI8Me MA0tYCbEzQfp9S/ZBVxt8ioMkyCvNpFrDRHhka6cOwkkRENSoJxpeB/dxce47Lxv1HOt 40ua7nsWeHWdIG8ida9ORIjtkshtXu9YdMBVqqEVv1viRycItI+C7PK4sti5N3XfoaWZ mtY2ovRMHYPfTbvJjRt0FWH09KSo9G1qKOl36iGDs5nipHheynbKJAfJnBcPFMycs3ap SODQ== MIME-Version: 1.0 Received: by 10.68.197.39 with SMTP id ir7mr9559889pbc.17.1333244329668; Sat, 31 Mar 2012 18:38:49 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.143.19.19 with HTTP; Sat, 31 Mar 2012 18:38:49 -0700 (PDT) In-Reply-To: <4F776DE5.5020507@rewt.org.uk> References: <4F776DE5.5020507@rewt.org.uk> Date: Sat, 31 Mar 2012 18:38:49 -0700 X-Google-Sender-Auth: EU0zy_NjB8eSNZXO8iak-EDDJto Message-ID: From: Adrian Chadd To: Joe Holden Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: kern.eventtimer.periodic 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, 01 Apr 2012 01:38:50 -0000 Hi, Please file a PR about this. Mav will need to know what situations aren't correctly being handled in his new timer framework. Adrian From owner-freebsd-net@FreeBSD.ORG Sun Apr 1 06:27:44 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4ECAC1065670 for ; Sun, 1 Apr 2012 06:27:44 +0000 (UTC) (envelope-from darernr@freebsd.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 14D9B8FC1E for ; Sun, 1 Apr 2012 06:27:43 +0000 (UTC) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id CFC3B20A96 for ; Sun, 1 Apr 2012 02:27:36 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute1.internal (MEProxy); Sun, 01 Apr 2012 02:27:36 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=6lXox6atFQfI5QQIUW1bJS YstPU=; b=fMfEKjj5Gott2Q67ealUZ/S+O8MA/xm563h3U0tTzfPHo057Gyj9n0 Lo2Pl6TJvbiWG1Gn+sgvWqQCOiZwNRii2hBQC+B3YwiHB60Y9mhyJJ9s8fv5Fq/U cfwcLzbVzvyrLX+mSe8OaxX1oi1mgT7ltC/cqxfh1z1OowGyuFNzQ= X-Sasl-enc: oRSj6xR2pEzAGbTebsiyVwMc8yj8ZXFPYRv/MfmE74nr 1333261656 Received: from [192.168.1.23] (dsl-202-45-110-141-static.VIC.netspace.net.au [202.45.110.141]) by mail.messagingengine.com (Postfix) with ESMTPSA id 14C12482491; Sun, 1 Apr 2012 02:27:34 -0400 (EDT) Message-ID: <4F780373.6030107@freebsd.org> Date: Sun, 01 Apr 2012 17:27:47 +1000 From: Darren Reed User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Andre Oppermann References: <4F75C1A3.4030401@freebsd.org> <4F75D9ED.7080707@freebsd.org> In-Reply-To: <4F75D9ED.7080707@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: darrenr@freebsd.org, freebsd-net@freebsd.org Subject: Re: FreeBSD TCP ignores zero window size 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, 01 Apr 2012 06:27:44 -0000 Andre, Your changes bring it closer to working correctly with a small change: rather than "tiwin > tp->snd_wnd", it should be "tiwin != tp->snd_wnd". In this trace, the remote end has set a window scale factor of 5 during connection establishment. The same change should be made in the if() a few lines down. The problem here is that it only tracks the window size as it grows, not as it shrinks. Thus the remote end setting its window size to 0 is ignored. But having made that change, there appears to be still one problem that still lingers. As can be seen below, freebsd 8.2 fails to properly ack the data that the remote end is trying to send, ultimately causing the connection to be dropped. Darren 16:06:50.207927 IP remote.ssh > freebsd82.62922: . 6268613:6270053(1440) ack 367219 win 128 16:06:50.208736 IP freebsd82.62922 > remote.ssh: . ack 6270053 win 8100 16:06:50.210902 IP remote.ssh > freebsd82.62922: . 6270053:6271493(1440) ack 367219 win 128 16:06:50.211752 IP freebsd82.62922 > remote.ssh: . ack 6271493 win 8280 16:06:50.229987 IP remote.ssh > freebsd82.62922: . ack 370099 win 38 16:06:50.419926 IP remote.ssh > freebsd82.62922: . ack 371315 win 0 16:06:50.422858 IP remote.ssh > freebsd82.62922: . ack 371315 win 0 16:06:51.207172 IP freebsd82.62922 > remote.ssh: . ack 6271493 win 8280 16:06:51.419263 IP remote.ssh > freebsd82.62922: . ack 371315 win 0 16:06:53.203547 IP remote.ssh > freebsd82.62922: . 6267173:6268613(1440) ack 371315 win 0 16:06:53.204320 IP freebsd82.62922 > remote.ssh: . ack 6271493 win 8280 16:06:53.415648 IP remote.ssh > freebsd82.62922: . ack 371315 win 0 16:06:59.207766 IP remote.ssh > freebsd82.62922: . 6267173:6268613(1440) ack 371315 win 0 16:06:59.208469 IP freebsd82.62922 > remote.ssh: . ack 6271493 win 8280 16:06:59.419342 IP remote.ssh > freebsd82.62922: . ack 371315 win 0 16:07:11.212606 IP remote.ssh > freebsd82.62922: . 6267173:6267697(524) ack 371315 win 0 16:07:11.213158 IP freebsd82.62922 > remote.ssh: . ack 6271493 win 8280 16:07:11.424414 IP remote.ssh > freebsd82.62922: . ack 371315 win 0 16:07:35.227356 IP remote.ssh > freebsd82.62922: . 6267173:6267697(524) ack 371315 win 0 16:07:35.227954 IP freebsd82.62922 > remote.ssh: . ack 6271493 win 8280 16:07:35.440105 IP remote.ssh > freebsd82.62922: . ack 371315 win 0 16:08:23.257747 IP remote.ssh > freebsd82.62922: . 6267173:6267697(524) ack 371315 win 0 16:08:23.258471 IP freebsd82.62922 > remote.ssh: . ack 6271493 win 8280 16:08:23.469790 IP remote.ssh > freebsd82.62922: . ack 371315 win 0 16:09:27.299037 IP remote.ssh > freebsd82.62922: . 6267173:6267697(524) ack 371315 win 0 16:09:27.299734 IP freebsd82.62922 > remote.ssh: . ack 6271493 win 8280 16:09:27.510740 IP remote.ssh > freebsd82.62922: . ack 371315 win 0 16:10:31.340328 IP remote.ssh > freebsd82.62922: . 6267173:6267697(524) ack 371315 win 0 16:10:31.340996 IP freebsd82.62922 > remote.ssh: . ack 6271493 win 8280 16:10:31.552639 IP remote.ssh > freebsd82.62922: . ack 371315 win 0 16:11:35.380906 IP remote.ssh > freebsd82.62922: . 6267173:6267697(524) ack 371315 win 0 16:11:35.381519 IP freebsd82.62922 > remote.ssh: . ack 6271493 win 8280 16:11:35.592948 IP remote.ssh > freebsd82.62922: . ack 371315 win 0 16:12:39.421327 IP remote.ssh > freebsd82.62922: . 6267173:6267697(524) ack 371315 win 0 16:12:39.421957 IP freebsd82.62922 > remote.ssh: . ack 6271493 win 8280 16:12:39.633531 IP remote.ssh > freebsd82.62922: . ack 371315 win 0 16:13:43.462137 IP remote.ssh > freebsd82.62922: . 6267173:6267697(524) ack 371315 win 0 16:13:43.462625 IP freebsd82.62922 > remote.ssh: . ack 6271493 win 8280 16:13:43.674110 IP remote.ssh > freebsd82.62922: . ack 371315 win 0 16:14:47.502951 IP remote.ssh > freebsd82.62922: . 6267173:6267697(524) ack 371315 win 0 16:14:47.503637 IP freebsd82.62922 > remote.ssh: . ack 6271493 win 8280 16:14:47.715729 IP remote.ssh > freebsd82.62922: . ack 371315 win 0 16:15:51.542134 IP remote.ssh > freebsd82.62922: . 6267173:6267697(524) ack 371315 win 0 16:15:51.542794 IP freebsd82.62922 > remote.ssh: . ack 6271493 win 8280 16:16:55.581199 IP remote.ssh > freebsd82.62922: R 6271493:6271493(0) ack 371315 win 0 From owner-freebsd-net@FreeBSD.ORG Mon Apr 2 00:44:33 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9F00F106566C for ; Mon, 2 Apr 2012 00:44:33 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2F92E8FC08 for ; Mon, 2 Apr 2012 00:44:32 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so2287117bkc.13 for ; Sun, 01 Apr 2012 17:44:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=4rbLGlZm/ICdkboVi5SfIlQqaTXfMWt1wXXPoHS13MU=; b=WJDuFzA/IcYJTodGKK7wIfz/WN0JWMpDEuU0X1wyrNcTQHFfCBY6oKOV2+GKs13Nyg 3YZ4v+iJITNP8wsweHiYpMZ1TbX8IDbQXGER9bfZOf0AIBjEn0lLHibJF1l1pKuYZWUG mkJPJJTdvWGG9ZxaSPYicw81k+POayu+IXdGzk8xXEL6l0PQsqxvtlj2YYZZSHU/ByIG bAGtzAyeDfY/x67UcBut1fhTh8ajmc0CzyHZOGV3HIPqs3vy2wsp0z72M/Zz+iQZ3RoW GJ647AtPIHvx21pJBp/cnrpRUHqiQJNQPbxs/zy/6QITy4U0Bd7kSEbyNRlzMVsbZKly h31Q== MIME-Version: 1.0 Received: by 10.204.9.194 with SMTP id m2mr2664248bkm.92.1333327471895; Sun, 01 Apr 2012 17:44:31 -0700 (PDT) Received: by 10.204.69.195 with HTTP; Sun, 1 Apr 2012 17:44:31 -0700 (PDT) Date: Sun, 1 Apr 2012 20:44:31 -0400 Message-ID: From: Zaphod Beeblebrox To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1 Subject: PXE Boot vmware 8.x fails after pxeboot. 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, 02 Apr 2012 00:44:33 -0000 I have had diskless FreeBSD machines before. I started this project with an eye to booting iscsi disks, but there seems to be no way to communicate the root disk path (and parameters) to FreeBSD --- something that might be solvable, but I need practical at the moment. So I fall back on NFS diskless with PXE boot (I may have used etherboot in the past --- it's been awhile). Anyways... this attempt is made with FreeBSD-9.0-RELEASE binaries. In my network, 192.168.0.1 is the DHCP and TFTP server. 192.168.0.52 is my NFS server. The new vmware guest is bridged and gets 192.168.0.135. It successfully gets 'pxeboot' onto the vmware guest --- pxeboot prints it's banner. Then the only network traffic I observe is DHCP Discover (vmware, presumably the pxeboot binary) followed by DHCP Offer (192.168.0.1 again) and this repeats. Now the dhcp offer gives a root path of "192.168.0.52:/vr/diskless/hit" ... and I've tried it with and without a trailing slash. Obviously this is something within the pxeboot's binary as no attempt to make the nfs mount occurs. From owner-freebsd-net@FreeBSD.ORG Mon Apr 2 03:52:23 2012 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 10234106566C for ; Mon, 2 Apr 2012 03:52:23 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id D43058FC1B for ; Mon, 2 Apr 2012 03:52:22 +0000 (UTC) Received: by pbcwz17 with SMTP id wz17so4394420pbc.13 for ; Sun, 01 Apr 2012 20:52:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=0DMMKsb6lcr29yMs6++GVUChqFM3nudKYAEtuyerM7E=; b=WajgubhLo9/FYSFBKRseFjeAbNUvGg5xtXKTpA6+SCvsVtEFmhYXGPoB4n/NTZEGKA WxKx+ricIrb9q4h0mrNssBxdhVl+gCvVDO4cbMlYwdj3hkRZoOOv/QyEcK1XDSwGFZr2 y55RwB2xkyP1eIoaagjFmRipyyTFsmQhoW2bzAZ+drriwjLD7+Puv7NLiHVfugZlNMGY HyTzcqgeTp0HM6qPHyzU3qHcGP+vzYCiOAbWw1E1sWRi2z4//j5vXbyReNgoWMGFemY0 P4pzXPNEOSQmpGjDEhanyBQB+lUCF1WOWCvV08SoZSCQ1NwkWRRar6aAbnUfCWBFbNlW NvfA== Received: by 10.68.135.195 with SMTP id pu3mr15561924pbb.54.1333338742691; Sun, 01 Apr 2012 20:52:22 -0700 (PDT) Received: from pyunyh@gmail.com ([114.111.62.249]) by mx.google.com with ESMTPS id f5sm13184480pbe.26.2012.04.01.20.52.19 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 01 Apr 2012 20:52:21 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 02 Apr 2012 12:52:15 -0700 From: YongHyeon PYUN Date: Mon, 2 Apr 2012 12:52:15 -0700 To: enoch Message-ID: <20120402195215.GA3571@michelle.cdnetworks.com> References: <20120330233819.GC7325@michelle.cdnetworks.com> <4F75C5EC.6090303@hotmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F75C5EC.6090303@hotmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: [nfe] DHCP failure on 8-stable 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: Mon, 02 Apr 2012 03:52:23 -0000 On Fri, Mar 30, 2012 at 10:40:44AM -0400, enoch wrote: > On 03/30/2012 19:38, YongHyeon PYUN wrote: > > On Fri, Mar 30, 2012 at 03:01:52AM -0400, enoch wrote: > >> Recently it became extremely difficult to pass the DHCP discovery step > >> on boot. Now I am using the buggy [nve] instead. > >> > >> Can anyone help? > >> > > > > Did you set synchronous_dhclient option in rc.conf? > > > > Yes: ifconfig_nfe0="SYNCDHCP" > > I guess [nfe] is undergoing gradual devel changes of some sort as before > it had some chance of reporting "empty headers" on initial ifconfig and > refusing to work. Sorry, I should have reported when encountering the > first problems rather than solve by reboot. Would you show me the output of both dmesg(nfe(4) and its PHY only) and 'sysctl dev.nfe.0.stats'? It would be also helpful to know whether nfe(4) still sees incoming traffic. Does assigning static IP work? > > In any case, the alternative [nve] should be marked "dangerous" as under > heavy load it tends to crash the system. > > Thanks, Enoch. > > >> > >> uname -a > >> ~~~~~~~~ > >> FreeBSD dome 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #7: Thu Mar 29 > >> 14:37:00 EDT 2012 root@dome:/usr/obj/usr/src/sys/DOME amd64 > >> > >> nfe0 fails at DHCPDISCOVER. > >> > >> ifconfig: > >> > >> nfe0: flags=8843 metric 0 mtu 1500 > >> options=82008 > >> ether 00:1f:bc:00:19:dc > >> inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 > >> media: Ethernet autoselect (100baseTX ) > >> status: active > >> > >> lspci: > >> > >> 00:14.0 Bridge: nVidia Corporation MCP51 Ethernet Controller (rev a3) Because there are several MCP51 variants, "pciconf -lcbv" is more more preferred one. From owner-freebsd-net@FreeBSD.ORG Mon Apr 2 05:10:12 2012 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 197181065674; Mon, 2 Apr 2012 05:10:12 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 7E7168FC14; Mon, 2 Apr 2012 05:10:11 +0000 (UTC) Received: by wgbds12 with SMTP id ds12so2197427wgb.31 for ; Sun, 01 Apr 2012 22:10:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=e6EkhFTsjYavYy+bMrTVKqdiZoY2Mok+IE/uPX1BP28=; b=KXMpQjp5e3buQbm6h82rdR7Wd6B62QfYjQkVbH9SxjSshOZTPF3yJIlg8aeovFfTZd 5yvjwCweyjUiDL7GJvvfSkeSpl0kCA5eyeP8b/0t5gSxClEyZ7DxG4h0CA8/eqrEB5cW Aa14fNPmv8tHml2pWY1MdaNHRyBpKp2POu4dO3q1IlnZdWx9NvysSrXbAU8mZQeVNsut UXtXQJ7JZY+GqjycqMGMaDnQt0z4cdBv8QZhzTFhw+8M+XCRC2RorQUBVFpvNXS4a0u1 t+VsA6xYe5GRDXWnDUDh/3ignFwwAEBqMyu1FdRhg5YXZ+U2pk0sdCYMgJZWdA2my5Sn D+0w== MIME-Version: 1.0 Received: by 10.180.89.9 with SMTP id bk9mr21085246wib.11.1333343410411; Sun, 01 Apr 2012 22:10:10 -0700 (PDT) Received: by 10.180.102.67 with HTTP; Sun, 1 Apr 2012 22:10:10 -0700 (PDT) Date: Mon, 2 Apr 2012 01:10:10 -0400 Message-ID: From: grarpamp To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 Cc: freebsd-isp@freebsd.org Subject: FreeBSD on/for switches/routers 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, 02 Apr 2012 05:10:12 -0000 Maybe people are doing things in this area... Just links. http://openvswitch.org/ http://www.openflow.org/ http://www.xorp.org/ http://pica8.com/ https://prontosystems.wordpress.com/ From owner-freebsd-net@FreeBSD.ORG Mon Apr 2 06:13:55 2012 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 62F4D1065672; Mon, 2 Apr 2012 06:13:55 +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 3786F8FC17; Mon, 2 Apr 2012 06:13:55 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q326Dtox043599; Mon, 2 Apr 2012 06:13:55 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q326DtNt043595; Mon, 2 Apr 2012 06:13:55 GMT (envelope-from linimon) Date: Mon, 2 Apr 2012 06:13:55 GMT Message-Id: <201204020613.q326DtNt043595@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/166501: [net] FreeBSD 9.0 generates incorrect SEC/ACK numbers under load 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, 02 Apr 2012 06:13:55 -0000 Old Synopsis: FreeBSD 9.0 generates incorrect SEC/ACK numbers under load New Synopsis: [net] FreeBSD 9.0 generates incorrect SEC/ACK numbers under load Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Apr 2 06:13:22 UTC 2012 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=166501 From owner-freebsd-net@FreeBSD.ORG Mon Apr 2 06:25:45 2012 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 7E540106566B; Mon, 2 Apr 2012 06:25:45 +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 4E2CD8FC14; Mon, 2 Apr 2012 06:25:45 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q326PjvY053426; Mon, 2 Apr 2012 06:25:45 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q326PjOQ053422; Mon, 2 Apr 2012 06:25:45 GMT (envelope-from linimon) Date: Mon, 2 Apr 2012 06:25:45 GMT Message-Id: <201204020625.q326PjOQ053422@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/166550: [netinet] [patch] Some log lines about arp do not include the new-line 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, 02 Apr 2012 06:25:45 -0000 Old Synopsis: [patch] Some log lines about arp do not include the new-line New Synopsis: [netinet] [patch] Some log lines about arp do not include the new-line Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Apr 2 06:25:24 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=166550 From owner-freebsd-net@FreeBSD.ORG Mon Apr 2 06:53:25 2012 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 49029106566B for ; Mon, 2 Apr 2012 06:53:25 +0000 (UTC) (envelope-from seth.mos@dds.nl) Received: from rotring.dds.nl (rotring.dds.nl [85.17.178.138]) by mx1.freebsd.org (Postfix) with ESMTP id 677678FC08 for ; Mon, 2 Apr 2012 06:53:23 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by rotring.dds.nl (Postfix) with ESMTP id 4D5F158CEB for ; Mon, 2 Apr 2012 08:53:17 +0200 (CEST) Received: from [10.0.2.53] (edge-pf.coltex.nl [91.227.27.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rotring.dds.nl (Postfix) with ESMTPSA id 89FE658B12 for ; Mon, 2 Apr 2012 08:53:11 +0200 (CEST) Message-ID: <4F794D1A.7020307@dds.nl> Date: Mon, 02 Apr 2012 08:54:18 +0200 From: Seth Mos User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4F74755A.2040308@dds.nl> In-Reply-To: <4F74755A.2040308@dds.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.3 at rotring X-Virus-Status: Clean Subject: Re: 6rd status 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, 02 Apr 2012 06:53:25 -0000 Op 29-3-2012 16:44, Seth Mos schreef: > Hi, > > I've been trying to use the srd device patch from Masakazu-san from > here. http://bougaidenpa.org/masakazu/archives/54 Only to reply to myself here, I've not seen response yet. I've now also tested the patched stf interface from hrs@. I tried getting it online using the 6rd prefix from either ATT or SwissCom but neither establishes 2 way comms. I see packets going out onto the wire proto 41 to the 6rd relay. And if I ping the IPv6 address from a remote end I see proto 41 traffic arriving in on the external interface from the 6rd relay. I never seem to be able to establish 2 way communications. e.g. Ping/dns etc. Pcaps here: http://iserv.nl/files/pfsense/6rd.pcap http://iserv.nl/files/pfsense/6rd-2.pcap Note that both the SwissCom and ATT use a /28 prefix. I am not sure if the patch takes that into account. I see that 6rd prefix lengths over 32 bits are not supported either way, which is a shame because there are actively people rolling that out. The pcaps do seem to indicate it takes the /28 prefix into account, but I'm not sure from reading the code. Can anybody see any light at the end of this (6rd) tunnel? Kind regards, Seth Mos > After walking through the configure steps and configuring a default > route I get a network unreachable. > > http://www.pastie.org/private/j6ufhloh2kqesznee6y8na > > [2.1-DEVELOPMENT][root@pfsense.localdomain]/root(6): ping6 -c1 > ipv6.google.com > PING6(56=40+8+8 bytes) 2a02:1205:25ea:19b0:: --> 2a00:1450:400c:c01::67 > ping6: sendmsg: Network is unreachable > ping6: wrote ipv6.l.google.com 16 chars, ret=-1 > > --- ipv6.l.google.com ping6 statistics --- > 1 packets transmitted, 0 packets received, 100.0% packet loss > [2.1-DEVELOPMENT][root@pfsense.localdomain]/root(7): > > Any ideas on where to look? > > Kind regards, > > Seth > _______________________________________________ > 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 Mon Apr 2 07:50:26 2012 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 BEBB2106566C for ; Mon, 2 Apr 2012 07:50:26 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 48CF38FC16 for ; Mon, 2 Apr 2012 07:50:26 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SEc1o-0007CS-B4 for freebsd-net@freebsd.org; Mon, 02 Apr 2012 09:50:16 +0200 Received: from pool-108-35-132-213.nwrknj.fios.verizon.net ([108.35.132.213]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 Apr 2012 09:50:16 +0200 Received: from ixew by pool-108-35-132-213.nwrknj.fios.verizon.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 Apr 2012 09:50:16 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: enoch Date: Mon, 02 Apr 2012 03:50:02 -0400 Lines: 108 Message-ID: References: <20120330233819.GC7325@michelle.cdnetworks.com> <4F75C5EC.6090303@hotmail.com> <20120402195215.GA3571@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: pool-108-35-132-213.nwrknj.fios.verizon.net User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120312 Thunderbird/11.0 In-Reply-To: <20120402195215.GA3571@michelle.cdnetworks.com> X-Enigmail-Version: 1.4 Subject: Re: [nfe] DHCP failure on 8-stable 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, 02 Apr 2012 07:50:26 -0000 On 04/02/2012 03:52 PM, YongHyeon PYUN wrote: > On Fri, Mar 30, 2012 at 10:40:44AM -0400, enoch wrote: >> On 03/30/2012 19:38, YongHyeon PYUN wrote: >>> On Fri, Mar 30, 2012 at 03:01:52AM -0400, enoch wrote: >>>> Recently it became extremely difficult to pass the DHCP discovery step >>>> on boot. Now I am using the buggy [nve] instead. >>>> >>>> Can anyone help? >>>> >>> >>> Did you set synchronous_dhclient option in rc.conf? >>> >> >> Yes: ifconfig_nfe0="SYNCDHCP" >> >> I guess [nfe] is undergoing gradual devel changes of some sort as before >> it had some chance of reporting "empty headers" on initial ifconfig and >> refusing to work. Sorry, I should have reported when encountering the >> first problems rather than solve by reboot. > > Would you show me the output of both dmesg(nfe(4) and its PHY only) > and 'sysctl dev.nfe.0.stats'? > It would be also helpful to know whether nfe(4) still sees > incoming traffic. > Does assigning static IP work? > Static IP direct communication attempt from this desktop to another laptop through a crossover cable fails as follows. Thanks. nfe0: flags=8843 metric 0 mtu 1500 options=82008 ether 00:1f:bc:00:19:dc inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 media: Ethernet autoselect (1000baseT ) status: active nfe0: link state changed to UP nfe0: port 0xf200-0xf207 mem 0xefffb000-0xefffbfff irq 21 at device 20.0 on pci0 miibus1: on nfe0 nfe0: Ethernet address: 00:1f:bc:00:19:dc nfe0: [FILTER] nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) nfe0: link state changed to UP nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) dev.nfe.0.stats.rx.frame_errors: 0 dev.nfe.0.stats.rx.extra_bytes: 0 dev.nfe.0.stats.rx.late_cols: 0 dev.nfe.0.stats.rx.runts: 0 dev.nfe.0.stats.rx.jumbos: 0 dev.nfe.0.stats.rx.fifo_overuns: 0 dev.nfe.0.stats.rx.crc_errors: 0 dev.nfe.0.stats.rx.fae: 0 dev.nfe.0.stats.rx.len_errors: 0 dev.nfe.0.stats.rx.unicast: 56 dev.nfe.0.stats.rx.multicast: 0 dev.nfe.0.stats.rx.broadcast: 280 dev.nfe.0.stats.tx.octets: 7517 dev.nfe.0.stats.tx.zero_rexmits: 51 dev.nfe.0.stats.tx.one_rexmits: 0 dev.nfe.0.stats.tx.multi_rexmits: 0 dev.nfe.0.stats.tx.late_cols: 0 dev.nfe.0.stats.tx.fifo_underuns: 0 dev.nfe.0.stats.tx.carrier_losts: 0 dev.nfe.0.stats.tx.excess_deferrals: 0 dev.nfe.0.stats.tx.retry_errors: 0 >> >> In any case, the alternative [nve] should be marked "dangerous" as under >> heavy load it tends to crash the system. >> >> Thanks, Enoch. >> >>>> >>>> uname -a >>>> ~~~~~~~~ >>>> FreeBSD dome 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #7: Thu Mar 29 >>>> 14:37:00 EDT 2012 root@dome:/usr/obj/usr/src/sys/DOME amd64 >>>> >>>> nfe0 fails at DHCPDISCOVER. >>>> >>>> ifconfig: >>>> >>>> nfe0: flags=8843 metric 0 mtu 1500 >>>> options=82008 >>>> ether 00:1f:bc:00:19:dc >>>> inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 >>>> media: Ethernet autoselect (100baseTX ) >>>> status: active >>>> >>>> lspci: >>>> >>>> 00:14.0 Bridge: nVidia Corporation MCP51 Ethernet Controller (rev a3) > > Because there are several MCP51 variants, "pciconf -lcbv" is more > more preferred one. > _______________________________________________ > 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 Mon Apr 2 08:59:42 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0FF47106566B for ; Mon, 2 Apr 2012 08:59:42 +0000 (UTC) (envelope-from xd11223@gmail.com) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id DF5F58FC14 for ; Mon, 2 Apr 2012 08:59:41 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1SEd6z-0002HK-Cc for freebsd-net@freebsd.org; Mon, 02 Apr 2012 01:59:41 -0700 Date: Mon, 2 Apr 2012 01:59:41 -0700 (PDT) From: ColinChu To: freebsd-net@freebsd.org Message-ID: <1333357181383-5611862.post@n5.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: SCTP-CMT in FreeBSD 9.0 Release 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, 02 Apr 2012 08:59:42 -0000 Hi, I'm using the FreeBSD8.2 to research CMT-SCTP. I use the same code in FreeBSD8.2, it could see the ESTABLISHED. But in FreeBSD 9.0, the status show the CLOSED. I try to capture the packet by tcpdump, there is nothing wrong compare in FreeBSD8.2. In FreeBSD9.0, the connection will ABORT directly. How to fix this problem? Thanks in advance. -- View this message in context: http://freebsd.1045724.n5.nabble.com/SCTP-CMT-in-FreeBSD-9-0-Release-tp5611862p5611862.html Sent from the freebsd-net mailing list archive at Nabble.com. From owner-freebsd-net@FreeBSD.ORG Mon Apr 2 09:06:17 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 964B81065672 for ; Mon, 2 Apr 2012 09:06:17 +0000 (UTC) (envelope-from rsb@berentweb.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id E7CE08FC1A for ; Mon, 2 Apr 2012 09:06:16 +0000 (UTC) Received: by lagv3 with SMTP id v3so4215368lag.13 for ; Mon, 02 Apr 2012 02:06:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=berentweb.com; s=google; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=Y1L4zkXHLCKQmTuG2c+ybFBTY+hwAC5MoKQrbo47DPc=; b=au5rRXM4T1jZzeZI7flseDz2C5rnDbgm75ygnofHuz10FVbu9m37ATpjlEO4IVakxv Mb1hic3GhpCG7eGTpX+Osdryif0L5deJNuJrYHJQcfzCSjBmEvDtCCR6KHjEE0335Ut9 hLl3sCzO8m1CfZRQtF4k9HPyOAd7oS8m6e+3U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :x-gm-message-state; bh=Y1L4zkXHLCKQmTuG2c+ybFBTY+hwAC5MoKQrbo47DPc=; b=J6VZAcauvv//GNmKMi8uvzjSvpi92J2pGLIpOwzcPZLuhbXag3WHNudanxYCJYXCK9 csLb5LKovH/o+h8wIRo+Bi30t3e8JOWKXd841W4q9mESDXUd+PNRVEv4FH4ZMwOWjvU6 jMPfjRJw8w+QmG8O9pQ17wDCGJY/lwmx+L04D/qhZian1GautE5VaIsQnAlZWB57yZjP rrwSntaCMC4wfbGZpiksUWSbGuKRHLMyzwyu/1kEOa1ehX/54/G75UTDRTGho/AXC8fC EdRfIXLmRxbel5dCSHMP47tGPD7iKRQu/tt9GlfwVTdZLt9j8gCVIrfOOBwocrfNaUaI 8Ozw== MIME-Version: 1.0 Received: by 10.152.131.3 with SMTP id oi3mr8916433lab.35.1333357570412; Mon, 02 Apr 2012 02:06:10 -0700 (PDT) Sender: rsb@berentweb.com Received: by 10.112.77.15 with HTTP; Mon, 2 Apr 2012 02:06:10 -0700 (PDT) X-Originating-IP: [85.110.29.196] In-Reply-To: <20120330054318.GB4154@DataIX.net> References: <20120330054318.GB4154@DataIX.net> Date: Mon, 2 Apr 2012 12:06:10 +0300 X-Google-Sender-Auth: NX3LNwBH-IbfBd9x20M9K39mJZY Message-ID: From: Beeblebrox To: freebsd-net@freebsd.org X-Gm-Message-State: ALoCoQm9vRiUCJSNYnTw6pmVQEdjrirtBOz5HHD583ceS64qF+WEIW7dHL6t0XVYhjxjlJBXFVlR Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: (no subject) 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, 02 Apr 2012 09:06:17 -0000 >> Why on earth would you do that when configuring the LAgg does this for you...! ALSO! you do not need an address on either of the nics!. That should be placed explicitly on the LAgg and add a alias for each sub address you would like.<< Incorrect! Try adding failover on 2 NIC's, leaving it up to lagg. You will see that lagg device gets MACaddr of NIC2 - and this,for diskless clients will not work because BOTH lagg and NIC2 need to be assigned MACaddr of NIC1. Without NIC1 MACaddr, the client will loose the credentials on server which it had established at boot-up. Suggest you read man lagg, example #2 (failover interface between wired and wireless) ++++++++++++++++ On Fri, Mar 30, 2012 at 8:43 AM, Jason Hellenthal wrote: > > > On Thu, Mar 29, 2012 at 04:42:38AM +0300, Beeblebrox wrote: > > Hi Adrian, > > > > Re your comments; you are 100% right, as I have not done steps 1 & 4 from > > your list below. > > I must also admit that my knowledge of networking, on a scale of 0-10, is > > probably -1. > > > > > > I assume you mean for Client? For example, re0 has static IP assigned by > > DHCP and re1 (GBit NIC) has no IP untill I assign same MAC Address as > re0, > > create lagg and do an ifconfig lagg. > > > > ***** > Why on earth would you do that when configuring the LAgg does this for > you...! > ***** > > ALSO! you do not need an address on either of the nics!. That should be > placed explicitly on the LAgg and add a alias for each sub address you > would like... > > > > > Can't boot Client at the moment as I have an NFS mount problem. All > > diskless clients boot from 192.168.2.1; DHCP, inetd, (and hopefully NFS) > > run from jail and are bound to that IP. No firewall (yet) on that NIC. > > > > I'd like to try steps 1 & 4 as per your suggestion and see if that solves > > it - so, > > 1. What commands should I run for steps 1 & 4 ? > > 2. lagg should be set up ass failover right? I assume loadbalance is > > impossible when hubs are involved? > > 3. Is it possible to assign lagg instruction through DHCP or some other > > service on HOST, rather than settings in CLIENT rc.conf? > > > > Thanks so much for your help... > > > > > > > > > On Wed, Mar 28, 2012 at 9:37 PM, Adrian Chadd > wrote: > > > > > >> Hi, > > >> > > >> what's the routing table and ifconfig output look like? > > >> > > >> It sounds like you're creating the interface and moving things over > > >> without: > > >> > > >> * deleting the route/IP table entry; > > >> * create the lagg; > > >> * adding the interfaces to the lagg, including the one you booted off > of; > > >> * assigning the correct IP and readding the default route. > > >> > > >> > > >> adrian > > >> > > > > > > > > _______________________________________________ > > 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" > > -- > ;s =; > From owner-freebsd-net@FreeBSD.ORG Mon Apr 2 09:25:09 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 711F7106566B for ; Mon, 2 Apr 2012 09:25:09 +0000 (UTC) (envelope-from rsb@berentweb.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id CCBBC8FC0C for ; Mon, 2 Apr 2012 09:25:07 +0000 (UTC) Received: by lagv3 with SMTP id v3so4240758lag.13 for ; Mon, 02 Apr 2012 02:25:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=berentweb.com; s=google; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=8tGVQIJr8JstQUUliK3xnLtqaTC2FM5cAdAtP0ye1G8=; b=NpzZ411gZ1Gs1OrTRq7S+nS/P1qiFB8wPlG9wRxyPYlFnDjSyhXo9l44/7jI91izoF HBN5Ibapx67ATic5gOKueZRdfYyldWVum6Hl7UPxrnphpJw8FOF40ezCz20Wua4oI0P5 JxilIoUp7f7HX5GFG5bqsFLugGJgmLQxf5yUg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :x-gm-message-state; bh=8tGVQIJr8JstQUUliK3xnLtqaTC2FM5cAdAtP0ye1G8=; b=O9lou6tdAwXmxujg7ajJ3C20Hl/VRTedRCwRpZ29emtYXvd2GqZYH9T1MGvwRnfZxP WCvkNPJlTXtc3QMd7XD2c+7kvLdRP80eZbGCHziHuHYU9HY8laH8gqeiIuAHvzLnC9R5 qCcA5xvgTu57fGO2DqnkXSb4I2+CipHXLYNs1peNJF0jxbeWGON5HFGxf35KKwT2Z/oX I99/dAL14L5LUELh1VSVkSnsMAb40oM+2whUv3kiyvVprAtFaf86v3ezWPAjfCBfP9qp HcSdKtoDRfakH13jXDxZm8E6/tYuGqhvlLNCvS8sKZqJzyQVZHPDsb1vd7+gMnwb+LzW vnAg== MIME-Version: 1.0 Received: by 10.152.131.3 with SMTP id oi3mr8975569lab.35.1333358706755; Mon, 02 Apr 2012 02:25:06 -0700 (PDT) Sender: rsb@berentweb.com Received: by 10.112.77.15 with HTTP; Mon, 2 Apr 2012 02:25:06 -0700 (PDT) X-Originating-IP: [85.110.29.196] In-Reply-To: <20120329072054.GA45082@server.vk2pj.dyndns.org> References: <20120329072054.GA45082@server.vk2pj.dyndns.org> Date: Mon, 2 Apr 2012 12:25:06 +0300 X-Google-Sender-Auth: gKesosWWU1bah-TLXdzQBcG_Y9U Message-ID: From: Beeblebrox To: freebsd-net@freebsd.org X-Gm-Message-State: ALoCoQmg2zenAceu9swA1SPHFvf5R9vU14ZjU5WcMpaAsKlZRt3+TfgTcpRfbJF5boKdbqcIFISS Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: lagg problems on diskless 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: Mon, 02 Apr 2012 09:25:09 -0000 Hi, Peter. I had looked into failover with wireless and tried it before posting, but got nowhere. I delayed posting an answer because I needed to do more fiddleing; and I made some headwy, but still problems: 1. With below setup in diskless client's rc.conf, the client is able to boot and gets to login screen: ifconfig_re1="up ether 00:30:67:91:6c:c2" cloned_interfaces="lagg0" ifconfig_lagg0="up laggproto failover laggport re1 192.168.2.2 netmask 255.255.255.0" 2. ifconfig at that point shows all good: same mac addr and lagg0 active. re0: flags=8843 metric 0 mtu 1500 options=8209b ether 00:30:67:91:6c:c2 inet 192.168.2.2 netmask 0xffffff00 broadcast 192.168.2.255 media: Ethernet autoselect (100baseTX ) status: active re1: flags=8843 metric 0 mtu 1500 options=8209b ether 00:30:67:91:6c:c2 media: Ethernet autoselect (1000baseT ) status: active lagg0: flags=8843 metric 0 mtu 1500 options=8209b ether 00:30:67:91:6c:c2 media: Ethernet autoselect status: active laggproto failover laggport: re1 flags=5 Now if I go and unplug NIC10/100 on diskless client and "list folder", the client will freeze - so failover does not switch. After some time passes, client informs that NFS server 192.168.2.1 is not responding. PS- I mistakenly double-posted: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=39210+0+current/freebsd-net *************************************************************** On Thu, Mar 29, 2012 at 10:20 AM, Peter Jeremy wrote: > On 2012-Mar-28 13:16:06 +0300, "Raif S. Berent" wrote: > >I have some problems implementing lagg(4) on dual NIC's on the diskless > >client side. It may be because my switch is a cheap, un-managed Gbit > switch > >or hopefully some other reason. I would like to either get lagg working > >properly or find an alternative method of solving the problem. > > Whilst I haven't specifically done this, I have done diskless booting > on a wired NIC and then switched to a wired/wifi lagg. Have a look at > http://www.bugs.au.freebsd.org/dokuwiki/doku.php/laggdiskless > > >I concede that under this structure lagg's loadbalance or LACP are > probably > >not going to work. > > FEC & LACP require support at both ends and so won't work. loadbalance > & roundrobin should work but aren't really appropriate unless your > interfaces are identical. > > >In general, as soon as lagg is brought up, NIC pool no longer responds to > >pings and gives an "I'm busy now" message. > > Yes. Once you create the lagg, the interfaces comprising it will no > longer work standalone and you can't atomically migrate the IP address > from re0 to lagg0 - hence the script linked from the above page. > > -- > Peter Jeremy > From owner-freebsd-net@FreeBSD.ORG Mon Apr 2 09:35:13 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4BF5B106566B for ; Mon, 2 Apr 2012 09:35:13 +0000 (UTC) (envelope-from rsb@berentweb.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id ABE798FC08 for ; Mon, 2 Apr 2012 09:35:12 +0000 (UTC) Received: by lagv3 with SMTP id v3so4254920lag.13 for ; Mon, 02 Apr 2012 02:35:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=berentweb.com; s=google; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=CST27wXVZYXfU1yABaP+kLF+2Q58OUb7g90A6kQmbAk=; b=UjDl2u6FhHQi3wmCGJrNFGZnbeqkRNdgORcBhYHAIxIfbpEtmmxDag/h2jgmjGuTpD XlPhx2+wx9qEHqHlSsvR4Z9e2S46kwYTPWWrXdVVgOqWLuv2LKRbM41C3dk147K63XmO BCYi9fPM2COoTdacw938eBAJTR7TKr6HzYXHw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :x-gm-message-state; bh=CST27wXVZYXfU1yABaP+kLF+2Q58OUb7g90A6kQmbAk=; b=IYY/Mh9dozvX9/v/xw/jgv2K1SONsj3z2Z+bq0Fy4XTkapv3KZ4KHDPBo8HLibQWYT xajgZi0COoKzFm50SvsNuiXWjrHxO146aAsvncSeGXTc9SpZvgw6QUdXF+WAQGLMQpAi ze8r4HejJekZ2TMG8sk0nMXeV2RPp9AwXgX0qH6Y2PlwmbYu3q9B2Efji7Mee0kMV3Wl ZIvJvB+VaWH0HVcpcGZOOacLmHMWxLXRbT98iNx/2E4uQhgnofYT53V0tVSn9lzkTMb5 Na/PkwineWQDl1Qodo9pdqGEc08q5XP6z0jf5kWlxTXWyy8EDi1ZRbMyde/hukQjmCxs /cLA== MIME-Version: 1.0 Received: by 10.152.105.211 with SMTP id go19mr8670567lab.51.1333359311552; Mon, 02 Apr 2012 02:35:11 -0700 (PDT) Sender: rsb@berentweb.com Received: by 10.112.77.15 with HTTP; Mon, 2 Apr 2012 02:35:11 -0700 (PDT) X-Originating-IP: [85.110.29.196] In-Reply-To: References: <20120330054318.GB4154@DataIX.net> Date: Mon, 2 Apr 2012 12:35:11 +0300 X-Google-Sender-Auth: 05syHFVxnJ4VoD51xVGDHojHD5A Message-ID: From: Beeblebrox To: freebsd-net@freebsd.org X-Gm-Message-State: ALoCoQmPpXD9w/ntOlCGXhhJDFWOPZY7TgUE0tuS41qWXr/ghRM88bVQOYafX+6MIwd/iA87qb+k Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: (no subject) 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, 02 Apr 2012 09:35:13 -0000 Discussion continued here, please: http://lists.freebsd.org/pipermail/freebsd-net/2012-April/031904.html From owner-freebsd-net@FreeBSD.ORG Mon Apr 2 10:07:16 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F10E0106564A for ; Mon, 2 Apr 2012 10:07:16 +0000 (UTC) (envelope-from Michael.Tuexen@lurchi.franken.de) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by mx1.freebsd.org (Postfix) with ESMTP id 8EBB08FC1D for ; Mon, 2 Apr 2012 10:07:16 +0000 (UTC) Received: from [212.201.126.51] (unknown [212.201.126.51]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 1B82D1C0B4622; Mon, 2 Apr 2012 12:07:14 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Michael Tuexen In-Reply-To: <1333357181383-5611862.post@n5.nabble.com> Date: Mon, 2 Apr 2012 12:07:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1333357181383-5611862.post@n5.nabble.com> To: ColinChu X-Mailer: Apple Mail (2.1257) Cc: freebsd-net@freebsd.org Subject: Re: SCTP-CMT in FreeBSD 9.0 Release 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, 02 Apr 2012 10:07:17 -0000 On Apr 2, 2012, at 10:59 AM, ColinChu wrote: > Hi, > I'm using the FreeBSD8.2 to research CMT-SCTP. > I use the same code in FreeBSD8.2, it could see the ESTABLISHED. > But in FreeBSD 9.0, the status show the CLOSED.=20 > I try to capture the packet by tcpdump, there is nothing wrong compare = in > FreeBSD8.2. >=20 > In FreeBSD9.0, the connection will ABORT directly. >=20 > How to fix this problem?=20 I need more information to help you... Can you provide a tracefile in .pcap file for all interfaces? (You can send them directly to tuexen@freebsd.org). Best regards Michael >=20 > Thanks in advance. >=20 >=20 >=20 > -- > View this message in context: = http://freebsd.1045724.n5.nabble.com/SCTP-CMT-in-FreeBSD-9-0-Release-tp561= 1862p5611862.html > Sent from the freebsd-net mailing list archive at Nabble.com. > _______________________________________________ > 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 From owner-freebsd-net@FreeBSD.ORG Mon Apr 2 10:32:33 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4512E1065675 for ; Mon, 2 Apr 2012 10:32:33 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx1.freebsd.org (Postfix) with ESMTP id 11B5C8FC1A for ; Mon, 2 Apr 2012 10:32:32 +0000 (UTC) Received: by dadz14 with SMTP id z14so10285053dad.17 for ; Mon, 02 Apr 2012 03:32:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=ndPVa3iSUx71ip+CYM6daRpfAHPp7NV2Ycgv58y+psI=; b=nQDD4g589yJxfIEc53h3jnMHFC+j/hLBbR0UcwdswksYM796YQKH1udCoVLUYxZ8QC 7mym2RUzYL8qi9xOI7A0OIY4rTNkjW3r/HEj0obqLckkHVEY5Wef3a+OSOuY3GPm34Wp SW9dbl3D6QdSZPze7lJvkVfkJI+rVbDeOUfgxkiwaYaNwm616niLaLVy9chcHoB8kytn 86MduG4a8ZG6wL5tEkPptia8EsUqVA5DPMG1qeIA1hQVqIDyboXBqqXuxfbO2DdbNGBh 1vBNdx5z+U+DHBPuhL1H/4LBIQGM40HBiLOLZ+t6NKr7grRlVfRLKjp1S100+H0v4tAJ lP7g== Received: by 10.68.237.36 with SMTP id uz4mr19731262pbc.165.1333362752663; Mon, 02 Apr 2012 03:32:32 -0700 (PDT) Received: from pyunyh@gmail.com ([114.111.62.249]) by mx.google.com with ESMTPS id z5sm13855976pbn.35.2012.04.02.03.32.30 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 Apr 2012 03:32:31 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 02 Apr 2012 19:32:25 -0700 From: YongHyeon PYUN Date: Mon, 2 Apr 2012 19:32:25 -0700 To: enoch Message-ID: <20120403023225.GD3571@michelle.cdnetworks.com> References: <20120330233819.GC7325@michelle.cdnetworks.com> <4F75C5EC.6090303@hotmail.com> <20120402195215.GA3571@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: [nfe] DHCP failure on 8-stable 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: Mon, 02 Apr 2012 10:32:33 -0000 On Mon, Apr 02, 2012 at 03:50:02AM -0400, enoch wrote: > On 04/02/2012 03:52 PM, YongHyeon PYUN wrote: > > On Fri, Mar 30, 2012 at 10:40:44AM -0400, enoch wrote: > >> On 03/30/2012 19:38, YongHyeon PYUN wrote: > >>> On Fri, Mar 30, 2012 at 03:01:52AM -0400, enoch wrote: > >>>> Recently it became extremely difficult to pass the DHCP discovery step > >>>> on boot. Now I am using the buggy [nve] instead. > >>>> > >>>> Can anyone help? > >>>> > >>> > >>> Did you set synchronous_dhclient option in rc.conf? > >>> > >> > >> Yes: ifconfig_nfe0="SYNCDHCP" > >> > >> I guess [nfe] is undergoing gradual devel changes of some sort as before > >> it had some chance of reporting "empty headers" on initial ifconfig and > >> refusing to work. Sorry, I should have reported when encountering the > >> first problems rather than solve by reboot. > > > > Would you show me the output of both dmesg(nfe(4) and its PHY only) > > and 'sysctl dev.nfe.0.stats'? > > It would be also helpful to know whether nfe(4) still sees > > incoming traffic. > > Does assigning static IP work? > > > > Static IP direct communication attempt from this desktop to another > laptop through a crossover cable fails as follows. Thanks. > > nfe0: flags=8843 metric 0 mtu 1500 > options=82008 > ether 00:1f:bc:00:19:dc > inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 > media: Ethernet autoselect (1000baseT > ) > status: active > > nfe0: link state changed to UP > nfe0: port 0xf200-0xf207 > mem 0xefffb000-0xefffbfff irq 21 at device 20.0 on pci0 > miibus1: on nfe0 It seems you've omitted PHY driver here. What PHY driver was attached to nfe(4)? > nfe0: Ethernet address: 00:1f:bc:00:19:dc > nfe0: [FILTER] > nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) > nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) > nfe0: link state changed to UP > nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) > nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) > nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) > > dev.nfe.0.stats.rx.frame_errors: 0 > dev.nfe.0.stats.rx.extra_bytes: 0 > dev.nfe.0.stats.rx.late_cols: 0 > dev.nfe.0.stats.rx.runts: 0 > dev.nfe.0.stats.rx.jumbos: 0 > dev.nfe.0.stats.rx.fifo_overuns: 0 > dev.nfe.0.stats.rx.crc_errors: 0 > dev.nfe.0.stats.rx.fae: 0 > dev.nfe.0.stats.rx.len_errors: 0 > dev.nfe.0.stats.rx.unicast: 56 > dev.nfe.0.stats.rx.multicast: 0 > dev.nfe.0.stats.rx.broadcast: 280 > dev.nfe.0.stats.tx.octets: 7517 > dev.nfe.0.stats.tx.zero_rexmits: 51 > dev.nfe.0.stats.tx.one_rexmits: 0 > dev.nfe.0.stats.tx.multi_rexmits: 0 > dev.nfe.0.stats.tx.late_cols: 0 > dev.nfe.0.stats.tx.fifo_underuns: 0 > dev.nfe.0.stats.tx.carrier_losts: 0 > dev.nfe.0.stats.tx.excess_deferrals: 0 > dev.nfe.0.stats.tx.retry_errors: 0 > Thanks. Would you show me the output of "pciconf -lcbv"? > >> > >> In any case, the alternative [nve] should be marked "dangerous" as under > >> heavy load it tends to crash the system. > >> > >> Thanks, Enoch. > >> > >>>> > >>>> uname -a > >>>> ~~~~~~~~ > >>>> FreeBSD dome 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #7: Thu Mar 29 > >>>> 14:37:00 EDT 2012 root@dome:/usr/obj/usr/src/sys/DOME amd64 > >>>> > >>>> nfe0 fails at DHCPDISCOVER. > >>>> > >>>> ifconfig: > >>>> > >>>> nfe0: flags=8843 metric 0 mtu 1500 > >>>> options=82008 > >>>> ether 00:1f:bc:00:19:dc > >>>> inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 > >>>> media: Ethernet autoselect (100baseTX ) > >>>> status: active > >>>> > >>>> lspci: > >>>> > >>>> 00:14.0 Bridge: nVidia Corporation MCP51 Ethernet Controller (rev a3) > > > > Because there are several MCP51 variants, "pciconf -lcbv" is more From owner-freebsd-net@FreeBSD.ORG Mon Apr 2 11:07:13 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AC2DF10656D2 for ; Mon, 2 Apr 2012 11:07:13 +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 93BD28FC1A for ; Mon, 2 Apr 2012 11:07:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q32B7DVg046860 for ; Mon, 2 Apr 2012 11:07:13 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q32B7CfS046858 for freebsd-net@FreeBSD.org; Mon, 2 Apr 2012 11:07:12 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 2 Apr 2012 11:07:12 GMT Message-Id: <201204021107.q32B7CfS046858@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, 02 Apr 2012 11:07:13 -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/166550 net [netinet] [patch] Some log lines about arp do not incl o kern/166501 net [net] FreeBSD 9.0 generates incorrect SEC/ACK numbers o kern/166462 net [gre] gre(4) when using a tunnel source address from c o kern/166372 net [patch] ipfilter drops UDP packets with zero checksum o kern/166285 net [arp] FreeBSD v8.1 REL p8 arp: unknown hardware addres o kern/166255 net [net] [patch] It should be possible to disable "promis o kern/165963 net [panic] [ipf] ipfilter/nat NULL pointer deference o kern/165903 net mbuf leak o kern/165863 net [panic] [netinet] [patch] in_lltable_prefix_free() rac o kern/165643 net [net] [patch] Missing vnet restores in net/if_ethersub o kern/165622 net [ndis][panic][patch] Unregistered use of FPU in kernel s kern/165562 net [request] add support for Intel i350 in FreeBSD 7.4 o kern/165526 net [bxe] UDP packets checksum calculation whithin if_bxe o kern/165488 net [ppp] [panic] Fatal trap 12 jails and ppp , kernel wit o kern/165305 net [ip6] [request] Feature parity between IP_TOS and IPV6 o kern/165296 net [vlan] [patch] Fix EVL_APPLY_VLID, update EVL_APPLY_PR o kern/165181 net [igb] igb freezes after about 2 weeks of uptime o kern/165174 net [patch] [tap] allow tap(4) to keep its address on clos o kern/165152 net [ip6] Does not work through the issue of ipv6 addresse o kern/164569 net [msk] [hang] msk network driver cause freeze in FreeBS o kern/164495 net [igb] connect double head igb to switch cause system t o kern/164490 net [pfil] Incorrect IP checksum on pfil pass from ip_outp o kern/164475 net [gre] gre misses RUNNING flag after a reboot o kern/164400 net [ipsec] immediate crash after the start of ipsec proce o kern/164265 net [netinet] [patch] tcp_lro_rx computes wrong checksum i o kern/163903 net [igb] "igb0:tx(0)","bpf interface lock" v2.2.5 9-STABL o kern/163481 net freebsd do not add itself to ping route packet o kern/162927 net [tun] Modem-PPP error ppp[1538]: tun0: Phase: Clearing o kern/162926 net [ipfilter] Infinite loop in ipfilter with fragmented I o kern/162558 net [dummynet] [panic] seldom dummynet panics o kern/162509 net [re] [panic] Kernel panic may be related to if_re.c (r o kern/162153 net [em] intel em driver 7.2.4 don't compile o kern/162110 net [igb] [panic] RELENG_9 panics on boot in IGB driver - o kern/162028 net [ixgbe] [patch] misplaced #endif in ixgbe.c o kern/161381 net [re] RTL8169SC - re0: PHY write failed o kern/161277 net [em] [patch] BMC cannot receive IPMI traffic after loa o kern/160873 net [igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 net Intel PRO/1000 connection breaks under load until rebo o kern/160693 net [gif] [em] Multicast packet are not passed from GIF0 t o kern/160420 net [msk] phy write timeout on HP 5310m o kern/160293 net [ieee80211] ppanic] kernel panic during network setup o kern/160206 net [gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net [udp] write UDPv4: No buffer space available (code=55) o kern/159629 net [ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net [tcp] [panic] panic: soabort: so_count o kern/159603 net [netinet] [patch] in_ifscrubprefix() - network route c o kern/159601 net [netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net [em] em watchdog timeouts o kern/159203 net [wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net [bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net [ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net [ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net [ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net [em] TSO breaks BPF packet captures with em driver f kern/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157785 net amd64 + jail + ipfw + natd = very slow outbound traffi o kern/157429 net [re] Realtek RTL8169 doesn't work with re(4) o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157209 net [ip6] [patch] locking error in rip6_input() (sys/netin o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155772 net ifconfig(8): ioctl (SIOCAIFADDR): File exists on direc o kern/155680 net [multicast] problems with multicast s kern/155642 net [request] Add driver for Realtek RTL8191SE/RTL8192SE W o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155420 net [vlan] adding vlan break existent vlan o kern/155177 net [route] [panic] Panic when inject routes in kernel o kern/155030 net [igb] igb(4) DEVICE_POLLING does not work with carp(4) o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [request]: Port brcm80211 driver from Linux to FreeBSD o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl o kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/152036 net [libc] getifaddrs(3) returns truncated sockaddrs for n o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co 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/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/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply 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 kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. p kern/145600 net TCP/ECN behaves different to CE/CWR than ns2 reference f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi 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/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144231 net bind/connect/sendto too strict about sockaddr length 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/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 kern/143034 net [panic] system reboots itself in tcp code [regression] 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 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, 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/140346 net [wlan] High bandwidth use causes loss of wlan connecti 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 p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) 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/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/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 f kern/138029 net [bpf] [panic] periodically kernel panic and reboot o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 p bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i 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/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/135502 net [periodic] Warning message raised by rtfree function i 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/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/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 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 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/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/132277 net [crypto] [ipsec] poor performance using cryptodevice f 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 kern/131601 net [ipfilter] [panic] 7-STABLE panic in nat_finalise (tcp o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o bin/131365 net route(8): route add changes interpretation of network 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/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow f 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 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 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 p kern/127360 net [socket] TOE socket options missing from sosetopt() 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/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126339 net [ipw] ipw driver drops the connection 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/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre 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 conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c 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/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 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net 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 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 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 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 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/111537 net [inet6] [patch] ip6_input() treats mbuf cluster wrong o kern/111457 net [ral] ral(4) freeze o kern/110284 net [if_ethersubr] Invalid Assumption in SIOCSIFADDR in et o kern/110249 net [kernel] [regression] [patch] setsockopt() error regre o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks 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] 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 o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv 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/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 p kern/85320 net [gre] [patch] possible depletion of kernel stack in ip 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 kern/82468 net Using 64MB tcp send/recv buffers, trafficflow stops, i 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/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 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/68889 net [panic] m_copym, length > size of mbuf chain 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 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/31940 net ip queue length too short for >500kpps 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 f kern/24959 net [patch] proper TCP_NOPUSH/TCP_CORK compatibility o conf/23063 net [arp] [patch] for static ARP tables in rc.network o kern/21998 net [socket] [patch] ident only for outgoing connections o kern/5877 net [socket] sb_cc counts control data as well as data dat 401 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Apr 2 13:39:41 2012 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 E74FE106566B for ; Mon, 2 Apr 2012 13:39:41 +0000 (UTC) (envelope-from trent@snakebite.org) Received: from exchange.liveoffice.com (exchla3.liveoffice.com [64.70.67.188]) by mx1.freebsd.org (Postfix) with ESMTP id C2A508FC15 for ; Mon, 2 Apr 2012 13:39:41 +0000 (UTC) Received: from EXHUB02.exchhosting.com (192.168.11.214) by exhub07.exchhosting.com (192.168.11.103) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 2 Apr 2012 06:38:20 -0700 Received: from EXMBX10.exchhosting.com ([fe80::9c37:32f6:a508:a44f]) by exhub02.exchhosting.com ([fe80::311c:a4c3:90a7:3e53%12]) with mapi; Mon, 2 Apr 2012 06:38:19 -0700 From: Trent Nelson To: =?iso-8859-1?Q?Seyit_=D6zg=FCr?= Date: Mon, 2 Apr 2012 06:38:17 -0700 Thread-Topic: Malformed syn packet cause %100 cpu and interrupts FreeBSD 9.0 release Thread-Index: Ac0Q1d1ft8lZAhMJRRiONQ0moPCbfQ== Message-ID: References: <3807CE6F3BF4B04EB897F4EBF2D258CE5C05F221@yuhanna.magnetdigital.local> <38FA7BAB-AC2B-4515-85CF-27F77C3F4313@mac.com> <3807CE6F3BF4B04EB897F4EBF2D258CE5C064A80@yuhanna.magnetdigital.local> <2805EAC2-BC15-4BC8-B85B-0908FCF255C5@mac.com> <3807CE6F3BF4B04EB897F4EBF2D258CE5C0651A4@yuhanna.magnetdigital.local> In-Reply-To: <3807CE6F3BF4B04EB897F4EBF2D258CE5C0651A4@yuhanna.magnetdigital.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-net@freebsd.org" Subject: Re: Malformed syn packet cause %100 cpu and interrupts FreeBSD 9.0 release 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, 02 Apr 2012 13:39:42 -0000 On Mar 22, 2012, at 5:30 AM, Seyit =D6zg=FCr wrote: > I solve the problem myself. > Thanks anyway For the records*, what'd you do? > Best regards. >=20 > Seyit =D6zg=FCr > Network Y=F6neticisi >=20 *: http://xkcd.com/979/ From owner-freebsd-net@FreeBSD.ORG Mon Apr 2 14:14:42 2012 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 00787106566C for ; Mon, 2 Apr 2012 14:14:42 +0000 (UTC) (envelope-from seyit.ozgur@istanbul.net) Received: from spamtrap1.istanbul.net (spamtrap1.istanbul.net [85.111.12.35]) by mx1.freebsd.org (Postfix) with ESMTP id 844968FC17 for ; Mon, 2 Apr 2012 14:14:41 +0000 (UTC) X-ASG-Debug-ID: 1333375409-0426b010a12dade0001-QdxwpM Received: from GAMMA.magnetdigital.local (gamma.magnetdigital.local [192.168.131.244]) by spamtrap1.istanbul.net with ESMTP id 4TcAQqhREpTbEXyr; Mon, 02 Apr 2012 17:03:50 +0300 (EEST) X-Barracuda-Envelope-From: seyit.ozgur@istanbul.net X-Barracuda-RBL-Trusted-Forwarder: 192.168.131.244 Received: from YUHANNA.magnetdigital.local ([fe80::1058:3088:f9b1:1346]) by GAMMA.magnetdigital.local ([fe80::3cca:d6ef:febb:fafb%17]) with mapi id 14.01.0218.012; Mon, 2 Apr 2012 17:03:29 +0300 From: =?iso-8859-9?Q?Seyit_=D6zg=FCr?= X-Barracuda-Apparent-Source-IP: fe80::1058:3088:f9b1:1346 To: Trent Nelson Thread-Topic: Malformed syn packet cause %100 cpu and interrupts FreeBSD 9.0 release X-ASG-Orig-Subj: RE: Malformed syn packet cause %100 cpu and interrupts FreeBSD 9.0 release Thread-Index: Ac0C5Fxpv2wbk7REQXGSXBWgiq7+JP//5aEA//bValCAEt3kAP//RObQgBLS34D//8fdgA== Date: Mon, 2 Apr 2012 14:03:28 +0000 Message-ID: <3807CE6F3BF4B04EB897F4EBF2D258CE5F8F79E4@yuhanna.magnetdigital.local> References: <3807CE6F3BF4B04EB897F4EBF2D258CE5C05F221@yuhanna.magnetdigital.local> <38FA7BAB-AC2B-4515-85CF-27F77C3F4313@mac.com> <3807CE6F3BF4B04EB897F4EBF2D258CE5C064A80@yuhanna.magnetdigital.local> <2805EAC2-BC15-4BC8-B85B-0908FCF255C5@mac.com> <3807CE6F3BF4B04EB897F4EBF2D258CE5C0651A4@yuhanna.magnetdigital.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [192.168.134.34] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0059_01CD10F2.85BCDED0" MIME-Version: 1.0 X-Barracuda-Connect: gamma.magnetdigital.local[192.168.131.244] X-Barracuda-Start-Time: 1333375409 X-Barracuda-URL: http://10.10.140.223:8000/cgi-mod/mark.cgi X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.92975 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-net@freebsd.org" Subject: RE: Malformed syn packet cause %100 cpu and interrupts FreeBSD 9.0 release 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, 02 Apr 2012 14:14:42 -0000 ------=_NextPart_000_0059_01CD10F2.85BCDED0 Content-Type: text/plain; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable it was fragmented packets.. i set up "net.inet.ip.fragpackets=3D0" there is no more fragmented packets.. This is not a solution for all systems.. Just i don't need fragmented packets.. that was stuck my ethernet card = while flooding.. Everything works fine atm. Seyit =D6zg=FCr Network Y=F6neticisi -----Original Message----- From: Trent Nelson [mailto:trent@snakebite.org]=20 Sent: Monday, April 02, 2012 4:38 PM To: Seyit =D6zg=FCr Cc: freebsd-net@freebsd.org Subject: Re: Malformed syn packet cause %100 cpu and interrupts FreeBSD = 9.0 release On Mar 22, 2012, at 5:30 AM, Seyit =D6zg=FCr wrote: > I solve the problem myself. > Thanks anyway For the records*, what'd you do? > Best regards. >=20 > Seyit =D6zg=FCr > Network Y=F6neticisi >=20 *: http://xkcd.com/979/ ------=_NextPart_000_0059_01CD10F2.85BCDED0-- From owner-freebsd-net@FreeBSD.ORG Mon Apr 2 14:31:49 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8D894106566B for ; Mon, 2 Apr 2012 14:31:49 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 633A98FC16 for ; Mon, 2 Apr 2012 14:31:49 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B4223B91C; Mon, 2 Apr 2012 10:31:48 -0400 (EDT) From: John Baldwin To: freebsd-net@freebsd.org Date: Mon, 2 Apr 2012 08:35:00 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201204020835.00357.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 02 Apr 2012 10:31:48 -0400 (EDT) Cc: Andrew Boyer Subject: Re: LACP kernel panics: /* unlocking is safe here */ 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, 02 Apr 2012 14:31:49 -0000 On Friday, March 30, 2012 6:04:24 pm Andrew Boyer wrote: > While investigating a LACP issue, I turned on LACP_DEBUG on a debug kernel. In this configuration it's easy to panic the kernel - just run 'ifconfig lagg0 laggproto lacp' on a lagg that's already in LACP mode and receiving LACP messages. > > The problem is that lagg_lacp_detach() drops the lagg wlock (with the comment in the title), which allows incoming LACP messages to get through lagg_input() while the structure is being destroyed in lacp_detach(). > > There's a very simple fix, but I don't know if it's the best way to fix it. Resetting the protocol before calling sc_detach causes any further incoming packets to be dropped until the lagg gets reconfigured. Thoughts? This looks sensible. > Is it safe to just hold on to the lagg wlock across the callout_drain() calls in lacp_detach()? That's what OpenBSD does. No, callout_drain() can sleep. Also, if this is using callout_init_mtx() or callout_init_rwlock() (which it probably should), then holding the lock across callout_drain() could deadlock. > -Andrew > > Index: sys/net/if_lagg.c > =================================================================== > --- sys/net/if_lagg.c (revision 233707) > +++ sys/net/if_lagg.c (working copy) > @@ -952,9 +952,10 @@ > } > if (sc->sc_proto != LAGG_PROTO_NONE) { > LAGG_WLOCK(sc); > + /* Reset protocol */ > + sc->sc_proto = LAGG_PROTO_NONE; > error = sc->sc_detach(sc); > - /* Reset protocol and pointers */ > - sc->sc_proto = LAGG_PROTO_NONE; > + /* Reset pointers */ > sc->sc_detach = NULL; > sc->sc_start = NULL; > sc->sc_input = NULL; > > -------------------------------------------------- > Andrew Boyer aboyer@averesystems.com > > > > > _______________________________________________ > 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" > -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Mon Apr 2 17:53:39 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 73EDF106566B for ; Mon, 2 Apr 2012 17:53:39 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from plsvl-mailgw-02.bluecoat.com (plsvl-mailgw-02.bluecoat.com [199.91.133.12]) by mx1.freebsd.org (Postfix) with ESMTP id 361548FC08 for ; Mon, 2 Apr 2012 17:53:39 +0000 (UTC) Received: from PWSVL-EXCHTS-01.internal.cacheflow.com (unknown [10.2.2.122]) by plsvl-mailgw-02.bluecoat.com (Postfix) with ESMTP id 6EBE0200CF; Mon, 2 Apr 2012 10:32:48 -0700 (PDT) Received: from pwsvl-excmbx-05.internal.cacheflow.com ([fe80::f848:d461:9aa9:59a8]) by PWSVL-EXCHTS-01.internal.cacheflow.com ([fe80::5c50:e2ba:8115:4223%20]) with mapi id 14.01.0289.001; Mon, 2 Apr 2012 10:53:37 -0700 From: "Li, Qing" To: Ryan Stone Thread-Topic: Removing an IPv6 address does not remove NDP entries on that subnet Thread-Index: AQHNDnkgJRkO9YzfY0abvrST7SLcoJaH0pmQ Date: Mon, 2 Apr 2012 17:53:36 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.2.2.106] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: freebsd-net Subject: RE: Removing an IPv6 address does not remove NDP entries on that subnet 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, 02 Apr 2012 17:53:39 -0000 >=20 > On Fri, Mar 30, 2012 at 12:28 AM, Li, Qing wrote: > >> * In a way this is a good thing as in6_lltable_prefix_free() is > >> guaranteed to crash your kernel in two different ways, and that's > not > >> counting the race conditions that it's subject to. > >> > > > > =A0 =A0 =A0 =A0Could you please elaborate with some details on the two > different > > =A0 =A0 =A0 =A0ways in6_lltable_prefix_free() crashes the kernel > definitively ? >=20 > First, it calls callout_drain on lle->le_timer, but that is never > initialized for a v6 llentry. Second, it never stops the ln_timer_ch > callout before it frees the llentry. Third, it modifies the lltable > without holding IF_AFDATA_LOCK(in.c has the third problem: see the > -net discussion about kern/165863). 1. The reference to &lle->la_timer instead of ln_timer_ch is fine=20 because lle_timer is defined as a union. 2. The manpage of "callout_drain()" reads=20 "The function callout_drain() is identical to callout_stop() except that it will wait for the callout to be completed if it is already in progress." 3. wrt IF_AFDATA_LOCK() I will check again. --Qing From owner-freebsd-net@FreeBSD.ORG Mon Apr 2 23:36:58 2012 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 2B0D51065670 for ; Mon, 2 Apr 2012 23:36:58 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id D5CD08FC08 for ; Mon, 2 Apr 2012 23:36:57 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SEqnp-0004SY-IG for freebsd-net@freebsd.org; Tue, 03 Apr 2012 01:36:49 +0200 Received: from pool-108-35-132-213.nwrknj.fios.verizon.net ([108.35.132.213]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 03 Apr 2012 01:36:49 +0200 Received: from ixew by pool-108-35-132-213.nwrknj.fios.verizon.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 03 Apr 2012 01:36:49 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: enoch Date: Mon, 02 Apr 2012 19:36:36 -0400 Organization: Linux Private Site Lines: 133 Message-ID: <87ty11670b.fsf@hotmail.com> References: <20120330233819.GC7325@michelle.cdnetworks.com> <4F75C5EC.6090303@hotmail.com> <20120402195215.GA3571@michelle.cdnetworks.com> <20120403023225.GD3571@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: pool-108-35-132-213.nwrknj.fios.verizon.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) Cancel-Lock: sha1:xQ8ITGjW6dvE1tFNc38u95KtIGU= Subject: Re: [nfe] DHCP failure on 8-stable 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, 02 Apr 2012 23:36:58 -0000 YongHyeon PYUN writes: > On Mon, Apr 02, 2012 at 03:50:02AM -0400, enoch wrote: >> On 04/02/2012 03:52 PM, YongHyeon PYUN wrote: >> > On Fri, Mar 30, 2012 at 10:40:44AM -0400, enoch wrote: >> >> On 03/30/2012 19:38, YongHyeon PYUN wrote: >> >>> On Fri, Mar 30, 2012 at 03:01:52AM -0400, enoch wrote: >> >>>> Recently it became extremely difficult to pass the DHCP discovery step >> >>>> on boot. Now I am using the buggy [nve] instead. >> >>>> >> >>>> Can anyone help? >> >>>> >> >>> >> >>> Did you set synchronous_dhclient option in rc.conf? >> >>> >> >> >> >> Yes: ifconfig_nfe0="SYNCDHCP" >> >> >> >> I guess [nfe] is undergoing gradual devel changes of some sort as before >> >> it had some chance of reporting "empty headers" on initial ifconfig and >> >> refusing to work. Sorry, I should have reported when encountering the >> >> first problems rather than solve by reboot. >> > >> > Would you show me the output of both dmesg(nfe(4) and its PHY only) >> > and 'sysctl dev.nfe.0.stats'? >> > It would be also helpful to know whether nfe(4) still sees >> > incoming traffic. >> > Does assigning static IP work? >> > >> >> Static IP direct communication attempt from this desktop to another >> laptop through a crossover cable fails as follows. Thanks. >> >> nfe0: flags=8843 metric 0 mtu 1500 >> options=82008 >> ether 00:1f:bc:00:19:dc >> inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 >> media: Ethernet autoselect (1000baseT >> ) >> status: active >> >> nfe0: link state changed to UP >> nfe0: port 0xf200-0xf207 >> mem 0xefffb000-0xefffbfff irq 21 at device 20.0 on pci0 >> miibus1: on nfe0 > > It seems you've omitted PHY driver here. What PHY driver was > attached to nfe(4)? > miibus1: on nfe0 rgephy1: PHY 1 on miibus1 >> nfe0: Ethernet address: 00:1f:bc:00:19:dc >> nfe0: [FILTER] >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) >> nfe0: link state changed to UP >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) >> >> dev.nfe.0.stats.rx.frame_errors: 0 >> dev.nfe.0.stats.rx.extra_bytes: 0 >> dev.nfe.0.stats.rx.late_cols: 0 >> dev.nfe.0.stats.rx.runts: 0 >> dev.nfe.0.stats.rx.jumbos: 0 >> dev.nfe.0.stats.rx.fifo_overuns: 0 >> dev.nfe.0.stats.rx.crc_errors: 0 >> dev.nfe.0.stats.rx.fae: 0 >> dev.nfe.0.stats.rx.len_errors: 0 >> dev.nfe.0.stats.rx.unicast: 56 >> dev.nfe.0.stats.rx.multicast: 0 >> dev.nfe.0.stats.rx.broadcast: 280 >> dev.nfe.0.stats.tx.octets: 7517 >> dev.nfe.0.stats.tx.zero_rexmits: 51 >> dev.nfe.0.stats.tx.one_rexmits: 0 >> dev.nfe.0.stats.tx.multi_rexmits: 0 >> dev.nfe.0.stats.tx.late_cols: 0 >> dev.nfe.0.stats.tx.fifo_underuns: 0 >> dev.nfe.0.stats.tx.carrier_losts: 0 >> dev.nfe.0.stats.tx.excess_deferrals: 0 >> dev.nfe.0.stats.tx.retry_errors: 0 >> > > Thanks. Would you show me the output of "pciconf -lcbv"? > nfe0@pci0:0:20:0: class=0x068000 card=0x10003842 chip=0x026910de rev=0xa3 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'MCP51 Network Bus Enumerator' class = bridge bar [10] = type Memory, range 32, base 0xefffb000, size 4096, enabled bar [14] = type I/O Port, range 32, base 0xf200, size 8, enabled cap 01[44] = powerspec 2 supports D0 D1 D2 D3 current D0 Interestingly, now that nfe0 is using a static IP it sometimes boots up properly. Are you interested in its good working? Thanks, Enoch. >> >> >> >> In any case, the alternative [nve] should be marked "dangerous" as under >> >> heavy load it tends to crash the system. >> >> >> >> Thanks, Enoch. >> >> >> >>>> >> >>>> uname -a >> >>>> ~~~~~~~~ >> >>>> FreeBSD dome 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #7: Thu Mar 29 >> >>>> 14:37:00 EDT 2012 root@dome:/usr/obj/usr/src/sys/DOME amd64 >> >>>> >> >>>> nfe0 fails at DHCPDISCOVER. >> >>>> >> >>>> ifconfig: >> >>>> >> >>>> nfe0: flags=8843 metric 0 mtu 1500 >> >>>> options=82008 >> >>>> ether 00:1f:bc:00:19:dc >> >>>> inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 >> >>>> media: Ethernet autoselect (100baseTX ) >> >>>> status: active >> >>>> >> >>>> lspci: >> >>>> >> >>>> 00:14.0 Bridge: nVidia Corporation MCP51 Ethernet Controller (rev a3) >> > >> > Because there are several MCP51 variants, "pciconf -lcbv" is more > _______________________________________________ > 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 Tue Apr 3 02:35:34 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DD20F1065670 for ; Tue, 3 Apr 2012 02:35:34 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx1.freebsd.org (Postfix) with ESMTP id A74768FC0A for ; Tue, 3 Apr 2012 02:35:34 +0000 (UTC) Received: by dadz14 with SMTP id z14so13125971dad.17 for ; Mon, 02 Apr 2012 19:35:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=Uxd0ARJoJwTjPE+hBP6aNHPxrsYu5KfS8r4gE8feJo0=; b=nUdwMvlxus6o/SGcW4X/J+O90YwIN7blU/Og/ODg4w0KNBlMgYYOr8Ynv9RbU21qlz ue7OyxQ6H6Rvv0Wmsn6XjcfF/9ViNFlIg0jrdDvtz3P9pz8OLBBnpOF7YNDPG9heqUq7 0/BLeRyRE1LE7yCOL40tGAqEVw1jfXDqo4kDRNRhy0BZLGp8z7VSLRWFzLv1cQMwPUvg toYTqq32jiWZczZ+v2Y8rgj3h+QsXh8VuCbAofGQm4zcZuJmctiaSruFJeYdjRhrysKj 79TquEsBXxiM9SkYqq13cTboTJufmTOczczsx0aVqzgM9Y3xg+HMA6kGISzT49MmSUPx y9FA== Received: by 10.68.189.170 with SMTP id gj10mr24931603pbc.121.1333420534215; Mon, 02 Apr 2012 19:35:34 -0700 (PDT) Received: from pyunyh@gmail.com ([114.111.62.249]) by mx.google.com with ESMTPS id r10sm15260520pbf.22.2012.04.02.19.35.31 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 Apr 2012 19:35:33 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 03 Apr 2012 11:35:21 -0700 From: YongHyeon PYUN Date: Tue, 3 Apr 2012 11:35:21 -0700 To: enoch Message-ID: <20120403183521.GA7380@michelle.cdnetworks.com> References: <20120330233819.GC7325@michelle.cdnetworks.com> <4F75C5EC.6090303@hotmail.com> <20120402195215.GA3571@michelle.cdnetworks.com> <20120403023225.GD3571@michelle.cdnetworks.com> <87ty11670b.fsf@hotmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="wac7ysb48OaltWcw" Content-Disposition: inline In-Reply-To: <87ty11670b.fsf@hotmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: [nfe] DHCP failure on 8-stable 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: Tue, 03 Apr 2012 02:35:34 -0000 --wac7ysb48OaltWcw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Apr 02, 2012 at 07:36:36PM -0400, enoch wrote: > YongHyeon PYUN writes: > > > On Mon, Apr 02, 2012 at 03:50:02AM -0400, enoch wrote: > >> On 04/02/2012 03:52 PM, YongHyeon PYUN wrote: > >> > On Fri, Mar 30, 2012 at 10:40:44AM -0400, enoch wrote: > >> >> On 03/30/2012 19:38, YongHyeon PYUN wrote: > >> >>> On Fri, Mar 30, 2012 at 03:01:52AM -0400, enoch wrote: > >> >>>> Recently it became extremely difficult to pass the DHCP discovery step > >> >>>> on boot. Now I am using the buggy [nve] instead. > >> >>>> > >> >>>> Can anyone help? > >> >>>> > >> >>> > >> >>> Did you set synchronous_dhclient option in rc.conf? > >> >>> > >> >> > >> >> Yes: ifconfig_nfe0="SYNCDHCP" > >> >> > >> >> I guess [nfe] is undergoing gradual devel changes of some sort as before > >> >> it had some chance of reporting "empty headers" on initial ifconfig and > >> >> refusing to work. Sorry, I should have reported when encountering the > >> >> first problems rather than solve by reboot. > >> > > >> > Would you show me the output of both dmesg(nfe(4) and its PHY only) > >> > and 'sysctl dev.nfe.0.stats'? > >> > It would be also helpful to know whether nfe(4) still sees > >> > incoming traffic. > >> > Does assigning static IP work? > >> > > >> > >> Static IP direct communication attempt from this desktop to another > >> laptop through a crossover cable fails as follows. Thanks. > >> > >> nfe0: flags=8843 metric 0 mtu 1500 > >> options=82008 > >> ether 00:1f:bc:00:19:dc > >> inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 > >> media: Ethernet autoselect (1000baseT > >> ) > >> status: active > >> > >> nfe0: link state changed to UP > >> nfe0: port 0xf200-0xf207 > >> mem 0xefffb000-0xefffbfff irq 21 at device 20.0 on pci0 > >> miibus1: on nfe0 > > > > It seems you've omitted PHY driver here. What PHY driver was > > attached to nfe(4)? > > > > miibus1: on nfe0 > rgephy1: PHY 1 on miibus1 > > >> nfe0: Ethernet address: 00:1f:bc:00:19:dc > >> nfe0: [FILTER] > >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) > >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) > >> nfe0: link state changed to UP > >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) > >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) > >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) > >> > >> dev.nfe.0.stats.rx.frame_errors: 0 > >> dev.nfe.0.stats.rx.extra_bytes: 0 > >> dev.nfe.0.stats.rx.late_cols: 0 > >> dev.nfe.0.stats.rx.runts: 0 > >> dev.nfe.0.stats.rx.jumbos: 0 > >> dev.nfe.0.stats.rx.fifo_overuns: 0 > >> dev.nfe.0.stats.rx.crc_errors: 0 > >> dev.nfe.0.stats.rx.fae: 0 > >> dev.nfe.0.stats.rx.len_errors: 0 > >> dev.nfe.0.stats.rx.unicast: 56 > >> dev.nfe.0.stats.rx.multicast: 0 > >> dev.nfe.0.stats.rx.broadcast: 280 > >> dev.nfe.0.stats.tx.octets: 7517 > >> dev.nfe.0.stats.tx.zero_rexmits: 51 > >> dev.nfe.0.stats.tx.one_rexmits: 0 > >> dev.nfe.0.stats.tx.multi_rexmits: 0 > >> dev.nfe.0.stats.tx.late_cols: 0 > >> dev.nfe.0.stats.tx.fifo_underuns: 0 > >> dev.nfe.0.stats.tx.carrier_losts: 0 > >> dev.nfe.0.stats.tx.excess_deferrals: 0 > >> dev.nfe.0.stats.tx.retry_errors: 0 > >> > > > > Thanks. Would you show me the output of "pciconf -lcbv"? > > > > nfe0@pci0:0:20:0: class=0x068000 card=0x10003842 chip=0x026910de rev=0xa3 hdr=0x00 > vendor = 'NVIDIA Corporation' > device = 'MCP51 Network Bus Enumerator' > class = bridge > bar [10] = type Memory, range 32, base 0xefffb000, size 4096, enabled > bar [14] = type I/O Port, range 32, base 0xf200, size 8, enabled > cap 01[44] = powerspec 2 supports D0 D1 D2 D3 current D0 > > Interestingly, now that nfe0 is using a static IP it sometimes boots > up properly. Are you interested in its good working? Yes I am. Would you try attached patch and let me know whether the patch makes any difference on your box? --wac7ysb48OaltWcw Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="nfe.power.diff" Index: sys/dev/nfe/if_nfe.c =================================================================== --- sys/dev/nfe/if_nfe.c (revision 233767) +++ sys/dev/nfe/if_nfe.c (working copy) @@ -836,12 +836,6 @@ if ((sc->nfe_flags & NFE_PWR_MGMT) == 0) return; - NFE_WRITE(sc, NFE_RXTX_CTL, NFE_RXTX_RESET | NFE_RXTX_BIT2); - NFE_WRITE(sc, NFE_MAC_RESET, NFE_MAC_RESET_MAGIC); - DELAY(100); - NFE_WRITE(sc, NFE_MAC_RESET, 0); - DELAY(100); - NFE_WRITE(sc, NFE_RXTX_CTL, NFE_RXTX_BIT2); pwr = NFE_READ(sc, NFE_PWR2_CTL); pwr &= ~NFE_PWR2_WAKEUP_MASK; if (sc->nfe_revid >= 0xa3 && @@ -849,6 +843,12 @@ sc->nfe_devid == PCI_PRODUCT_NVIDIA_NFORCE430_LAN2)) pwr |= NFE_PWR2_REVA3; NFE_WRITE(sc, NFE_PWR2_CTL, pwr); + NFE_WRITE(sc, NFE_RXTX_CTL, NFE_RXTX_RESET | NFE_RXTX_BIT2); + NFE_WRITE(sc, NFE_MAC_RESET, NFE_MAC_RESET_MAGIC); + DELAY(100); + NFE_WRITE(sc, NFE_MAC_RESET, 0); + DELAY(100); + NFE_WRITE(sc, NFE_RXTX_CTL, NFE_RXTX_BIT2); } --wac7ysb48OaltWcw-- From owner-freebsd-net@FreeBSD.ORG Tue Apr 3 05:27:07 2012 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 096EB106564A for ; Tue, 3 Apr 2012 05:27:07 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8A30C8FC08 for ; Tue, 3 Apr 2012 05:27:06 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so3753787bkc.13 for ; Mon, 02 Apr 2012 22:27:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=0EFq/60STCWYOu5O09dfopSzj6qGeBi0/FJsl/RJMRk=; b=JfnPIekE8TsluVp9xZx7qOdQa921Gwq0GyL6/PRKOyGy/KxC6Uui5p7nl4dmBOIV3d 4wjWp1r2OuNdDrTPBG3E2yNF/Km2jxN53+xc7OUXFYZn3+xAeDup3tBpD5k36aiWlJ+J LAX8H9NChItyky8V8fvPELyn/fC15vw98SohKXodGcwsb3dXfT55vZjmzzdf7i7TWb8B bMYXD3AxLYv4xBVYH/r5//+uOWYW8EC4oxDZWTXjK6Zj/lTeG85HHvYqQ+XC9m702iG8 iqpaA797d+ZcH4Lk1ewowqJefxR6ylgyAvsqdhyYMZE1QNFwOAAUJh8Pc4gi/9KYIHlC hn3g== MIME-Version: 1.0 Received: by 10.205.129.137 with SMTP id hi9mr4897261bkc.131.1333430825647; Mon, 02 Apr 2012 22:27:05 -0700 (PDT) Received: by 10.204.69.195 with HTTP; Mon, 2 Apr 2012 22:27:05 -0700 (PDT) In-Reply-To: References: Date: Tue, 3 Apr 2012 01:27:05 -0400 Message-ID: From: Zaphod Beeblebrox To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: PXE Boot vmware 8.x fails after pxeboot. 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, 03 Apr 2012 05:27:07 -0000 Replying to my own message, I add more below... On Sun, Apr 1, 2012 at 8:44 PM, Zaphod Beeblebrox wrote= : > I have had diskless FreeBSD machines before. =A0I started this project > with an eye to booting iscsi disks, but there seems to be no way to > communicate the root disk path (and parameters) to FreeBSD --- > something that might be solvable, but I need practical at the moment. > So I fall back on NFS diskless with PXE boot (I may have used > etherboot in the past --- it's been awhile). > > Anyways... this attempt is made with FreeBSD-9.0-RELEASE binaries. > > In my network, 192.168.0.1 is the DHCP and TFTP server. =A0192.168.0.52 > is my NFS server. =A0The new vmware guest is bridged and gets > 192.168.0.135. =A0It successfully gets 'pxeboot' onto the vmware guest > --- pxeboot prints it's banner. =A0Then the only network traffic I > observe is DHCP Discover (vmware, presumably the pxeboot binary) > followed by DHCP Offer (192.168.0.1 again) and this repeats. > > Now the dhcp offer gives a root path of > "192.168.0.52:/vr/diskless/hit" ... and I've tried it with and without > a trailing slash. > > Obviously this is something within the pxeboot's binary as no attempt > to make the nfs mount occurs. ... With a few more variations of this test, I came across a configuration where the pxeboot client loaded into the vmware system would continue to spam the "options next-server" host to mount "/" ... interestingly here, it seems to completely ignore "options root-path" ... both the ip address and the path portions alike. ... but said behavior only occurs with some set of random configuration changes on the returned DHCP packets and/or slightly different versions of pxeboot (which I've pulled from various hosts from 8.x through the 9.x that I'm trying to boot with. It strikes me that the pxeboot process is hanging somewhere ... or overwriting memory ... or somesuch ... on this box. Has anyone seen or investigated this type of behavior? From owner-freebsd-net@FreeBSD.ORG Tue Apr 3 05:45:49 2012 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 3ABA6106566C for ; Tue, 3 Apr 2012 05:45:49 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id D16F58FC08 for ; Tue, 3 Apr 2012 05:45:48 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SEwYs-0004br-KD for freebsd-net@freebsd.org; Tue, 03 Apr 2012 07:45:46 +0200 Received: from pool-108-35-132-213.nwrknj.fios.verizon.net ([108.35.132.213]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 03 Apr 2012 07:45:46 +0200 Received: from ixew by pool-108-35-132-213.nwrknj.fios.verizon.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 03 Apr 2012 07:45:46 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: enoch Date: Tue, 03 Apr 2012 01:45:30 -0400 Organization: Linux Private Site Lines: 143 Message-ID: <87obr95pxh.fsf@hotmail.com> References: <20120330233819.GC7325@michelle.cdnetworks.com> <4F75C5EC.6090303@hotmail.com> <20120402195215.GA3571@michelle.cdnetworks.com> <20120403023225.GD3571@michelle.cdnetworks.com> <87ty11670b.fsf@hotmail.com> <20120403183521.GA7380@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: pool-108-35-132-213.nwrknj.fios.verizon.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) Cancel-Lock: sha1:glxoQyoZLZmB/uGB+sA8JEf16AY= Subject: Re: [nfe] DHCP failure on 8-stable 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, 03 Apr 2012 05:45:49 -0000 YongHyeon PYUN writes: > On Mon, Apr 02, 2012 at 07:36:36PM -0400, enoch wrote: >> YongHyeon PYUN writes: >> >> > On Mon, Apr 02, 2012 at 03:50:02AM -0400, enoch wrote: >> >> On 04/02/2012 03:52 PM, YongHyeon PYUN wrote: >> >> > On Fri, Mar 30, 2012 at 10:40:44AM -0400, enoch wrote: >> >> >> On 03/30/2012 19:38, YongHyeon PYUN wrote: >> >> >>> On Fri, Mar 30, 2012 at 03:01:52AM -0400, enoch wrote: >> >> >>>> Recently it became extremely difficult to pass the DHCP discovery step >> >> >>>> on boot. Now I am using the buggy [nve] instead. >> >> >>>> >> >> >>>> Can anyone help? >> >> >>>> >> >> >>> >> >> >>> Did you set synchronous_dhclient option in rc.conf? >> >> >>> >> >> >> >> >> >> Yes: ifconfig_nfe0="SYNCDHCP" >> >> >> >> >> >> I guess [nfe] is undergoing gradual devel changes of some sort as before >> >> >> it had some chance of reporting "empty headers" on initial ifconfig and >> >> >> refusing to work. Sorry, I should have reported when encountering the >> >> >> first problems rather than solve by reboot. >> >> > >> >> > Would you show me the output of both dmesg(nfe(4) and its PHY only) >> >> > and 'sysctl dev.nfe.0.stats'? >> >> > It would be also helpful to know whether nfe(4) still sees >> >> > incoming traffic. >> >> > Does assigning static IP work? >> >> > >> >> >> >> Static IP direct communication attempt from this desktop to another >> >> laptop through a crossover cable fails as follows. Thanks. >> >> >> >> nfe0: flags=8843 metric 0 mtu 1500 >> >> options=82008 >> >> ether 00:1f:bc:00:19:dc >> >> inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 >> >> media: Ethernet autoselect (1000baseT >> >> ) >> >> status: active >> >> >> >> nfe0: link state changed to UP >> >> nfe0: port 0xf200-0xf207 >> >> mem 0xefffb000-0xefffbfff irq 21 at device 20.0 on pci0 >> >> miibus1: on nfe0 >> > >> > It seems you've omitted PHY driver here. What PHY driver was >> > attached to nfe(4)? >> > >> >> miibus1: on nfe0 >> rgephy1: PHY 1 on miibus1 >> >> >> nfe0: Ethernet address: 00:1f:bc:00:19:dc >> >> nfe0: [FILTER] >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) >> >> nfe0: link state changed to UP >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) >> >> >> >> dev.nfe.0.stats.rx.frame_errors: 0 >> >> dev.nfe.0.stats.rx.extra_bytes: 0 >> >> dev.nfe.0.stats.rx.late_cols: 0 >> >> dev.nfe.0.stats.rx.runts: 0 >> >> dev.nfe.0.stats.rx.jumbos: 0 >> >> dev.nfe.0.stats.rx.fifo_overuns: 0 >> >> dev.nfe.0.stats.rx.crc_errors: 0 >> >> dev.nfe.0.stats.rx.fae: 0 >> >> dev.nfe.0.stats.rx.len_errors: 0 >> >> dev.nfe.0.stats.rx.unicast: 56 >> >> dev.nfe.0.stats.rx.multicast: 0 >> >> dev.nfe.0.stats.rx.broadcast: 280 >> >> dev.nfe.0.stats.tx.octets: 7517 >> >> dev.nfe.0.stats.tx.zero_rexmits: 51 >> >> dev.nfe.0.stats.tx.one_rexmits: 0 >> >> dev.nfe.0.stats.tx.multi_rexmits: 0 >> >> dev.nfe.0.stats.tx.late_cols: 0 >> >> dev.nfe.0.stats.tx.fifo_underuns: 0 >> >> dev.nfe.0.stats.tx.carrier_losts: 0 >> >> dev.nfe.0.stats.tx.excess_deferrals: 0 >> >> dev.nfe.0.stats.tx.retry_errors: 0 >> >> >> > >> > Thanks. Would you show me the output of "pciconf -lcbv"? >> > >> >> nfe0@pci0:0:20:0: class=0x068000 card=0x10003842 chip=0x026910de rev=0xa3 hdr=0x00 >> vendor = 'NVIDIA Corporation' >> device = 'MCP51 Network Bus Enumerator' >> class = bridge >> bar [10] = type Memory, range 32, base 0xefffb000, size 4096, enabled >> bar [14] = type I/O Port, range 32, base 0xf200, size 8, enabled >> cap 01[44] = powerspec 2 supports D0 D1 D2 D3 current D0 >> >> Interestingly, now that nfe0 is using a static IP it sometimes boots >> up properly. Are you interested in its good working? > > Yes I am. Would you try attached patch and let me know whether the > patch makes any difference on your box? Sorry to report: The patch was applied (to 8-stable latest code) but out of 3 boots only one succeeded. Same stream of "nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0)" messages. > Index: sys/dev/nfe/if_nfe.c > =================================================================== > --- sys/dev/nfe/if_nfe.c (revision 233767) > +++ sys/dev/nfe/if_nfe.c (working copy) > @@ -836,12 +836,6 @@ > > if ((sc->nfe_flags & NFE_PWR_MGMT) == 0) > return; > - NFE_WRITE(sc, NFE_RXTX_CTL, NFE_RXTX_RESET | NFE_RXTX_BIT2); > - NFE_WRITE(sc, NFE_MAC_RESET, NFE_MAC_RESET_MAGIC); > - DELAY(100); > - NFE_WRITE(sc, NFE_MAC_RESET, 0); > - DELAY(100); > - NFE_WRITE(sc, NFE_RXTX_CTL, NFE_RXTX_BIT2); > pwr = NFE_READ(sc, NFE_PWR2_CTL); > pwr &= ~NFE_PWR2_WAKEUP_MASK; > if (sc->nfe_revid >= 0xa3 && > @@ -849,6 +843,12 @@ > sc->nfe_devid == PCI_PRODUCT_NVIDIA_NFORCE430_LAN2)) > pwr |= NFE_PWR2_REVA3; > NFE_WRITE(sc, NFE_PWR2_CTL, pwr); > + NFE_WRITE(sc, NFE_RXTX_CTL, NFE_RXTX_RESET | NFE_RXTX_BIT2); > + NFE_WRITE(sc, NFE_MAC_RESET, NFE_MAC_RESET_MAGIC); > + DELAY(100); > + NFE_WRITE(sc, NFE_MAC_RESET, 0); > + DELAY(100); > + NFE_WRITE(sc, NFE_RXTX_CTL, NFE_RXTX_BIT2); > } > > > _______________________________________________ > 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 Tue Apr 3 06:54:35 2012 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 74CB21065673 for ; Tue, 3 Apr 2012 06:54:35 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3D78E8FC12 for ; Tue, 3 Apr 2012 06:54:35 +0000 (UTC) Received: by pbcwz17 with SMTP id wz17so5635281pbc.13 for ; Mon, 02 Apr 2012 23:54:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=bc3wgJ6EcfFU4Vq/yjl8N+mZgmQuSrxcTtl4suTiQos=; b=iBh3PMpLq15yKBcoxy5pxKoErGZyoYl/O68RQq0Y/htfpd1gnkxK3hxh6Xz4tG+yk4 6h49buZSf8BWlJ4yxN3fR/yWM4k/lcGvfraTCJ0WPseKduu+g4fM5z/Dss1ILw06galg zxV1hQ13Ju+KGEdY0E5BA3MmGTrvQfw98QwfZ60Ob82YYJm7TZLOidYNTRzpGqM6Oa9I UY9MO07QZjZEVaV9RXxEeU7o1j2AJyJKyZbkBc7Glf95/bNT0SYrilN1riNoilCMthIM d/wVsQam/L41jOtEYIIN+xiB/F4N9CsXjtxlrwEnPp6HvBWd3eX75zntadqJUZu1NT3N ufbw== Received: by 10.68.201.201 with SMTP id kc9mr5604105pbc.50.1333436074789; Mon, 02 Apr 2012 23:54:34 -0700 (PDT) Received: from pyunyh@gmail.com ([114.111.62.249]) by mx.google.com with ESMTPS id f7sm15696024pbr.3.2012.04.02.23.54.32 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 Apr 2012 23:54:34 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 03 Apr 2012 15:54:22 -0700 From: YongHyeon PYUN Date: Tue, 3 Apr 2012 15:54:22 -0700 To: enoch Message-ID: <20120403225422.GB7380@michelle.cdnetworks.com> References: <20120330233819.GC7325@michelle.cdnetworks.com> <4F75C5EC.6090303@hotmail.com> <20120402195215.GA3571@michelle.cdnetworks.com> <20120403023225.GD3571@michelle.cdnetworks.com> <87ty11670b.fsf@hotmail.com> <20120403183521.GA7380@michelle.cdnetworks.com> <87obr95pxh.fsf@hotmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Fba/0zbH8Xs+Fj9o" Content-Disposition: inline In-Reply-To: <87obr95pxh.fsf@hotmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: [nfe] DHCP failure on 8-stable 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: Tue, 03 Apr 2012 06:54:35 -0000 --Fba/0zbH8Xs+Fj9o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Apr 03, 2012 at 01:45:30AM -0400, enoch wrote: > YongHyeon PYUN writes: > > > On Mon, Apr 02, 2012 at 07:36:36PM -0400, enoch wrote: > >> YongHyeon PYUN writes: > >> > >> > On Mon, Apr 02, 2012 at 03:50:02AM -0400, enoch wrote: > >> >> On 04/02/2012 03:52 PM, YongHyeon PYUN wrote: > >> >> > On Fri, Mar 30, 2012 at 10:40:44AM -0400, enoch wrote: > >> >> >> On 03/30/2012 19:38, YongHyeon PYUN wrote: > >> >> >>> On Fri, Mar 30, 2012 at 03:01:52AM -0400, enoch wrote: > >> >> >>>> Recently it became extremely difficult to pass the DHCP discovery step > >> >> >>>> on boot. Now I am using the buggy [nve] instead. > >> >> >>>> > >> >> >>>> Can anyone help? > >> >> >>>> > >> >> >>> > >> >> >>> Did you set synchronous_dhclient option in rc.conf? > >> >> >>> > >> >> >> > >> >> >> Yes: ifconfig_nfe0="SYNCDHCP" > >> >> >> > >> >> >> I guess [nfe] is undergoing gradual devel changes of some sort as before > >> >> >> it had some chance of reporting "empty headers" on initial ifconfig and > >> >> >> refusing to work. Sorry, I should have reported when encountering the > >> >> >> first problems rather than solve by reboot. > >> >> > > >> >> > Would you show me the output of both dmesg(nfe(4) and its PHY only) > >> >> > and 'sysctl dev.nfe.0.stats'? > >> >> > It would be also helpful to know whether nfe(4) still sees > >> >> > incoming traffic. > >> >> > Does assigning static IP work? > >> >> > > >> >> > >> >> Static IP direct communication attempt from this desktop to another > >> >> laptop through a crossover cable fails as follows. Thanks. > >> >> > >> >> nfe0: flags=8843 metric 0 mtu 1500 > >> >> options=82008 > >> >> ether 00:1f:bc:00:19:dc > >> >> inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 > >> >> media: Ethernet autoselect (1000baseT > >> >> ) > >> >> status: active > >> >> > >> >> nfe0: link state changed to UP > >> >> nfe0: port 0xf200-0xf207 > >> >> mem 0xefffb000-0xefffbfff irq 21 at device 20.0 on pci0 > >> >> miibus1: on nfe0 > >> > > >> > It seems you've omitted PHY driver here. What PHY driver was > >> > attached to nfe(4)? > >> > > >> > >> miibus1: on nfe0 > >> rgephy1: PHY 1 on miibus1 > >> > >> >> nfe0: Ethernet address: 00:1f:bc:00:19:dc > >> >> nfe0: [FILTER] > >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) > >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) > >> >> nfe0: link state changed to UP > >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) > >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) > >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) > >> >> > >> >> dev.nfe.0.stats.rx.frame_errors: 0 > >> >> dev.nfe.0.stats.rx.extra_bytes: 0 > >> >> dev.nfe.0.stats.rx.late_cols: 0 > >> >> dev.nfe.0.stats.rx.runts: 0 > >> >> dev.nfe.0.stats.rx.jumbos: 0 > >> >> dev.nfe.0.stats.rx.fifo_overuns: 0 > >> >> dev.nfe.0.stats.rx.crc_errors: 0 > >> >> dev.nfe.0.stats.rx.fae: 0 > >> >> dev.nfe.0.stats.rx.len_errors: 0 > >> >> dev.nfe.0.stats.rx.unicast: 56 > >> >> dev.nfe.0.stats.rx.multicast: 0 > >> >> dev.nfe.0.stats.rx.broadcast: 280 > >> >> dev.nfe.0.stats.tx.octets: 7517 > >> >> dev.nfe.0.stats.tx.zero_rexmits: 51 > >> >> dev.nfe.0.stats.tx.one_rexmits: 0 > >> >> dev.nfe.0.stats.tx.multi_rexmits: 0 > >> >> dev.nfe.0.stats.tx.late_cols: 0 > >> >> dev.nfe.0.stats.tx.fifo_underuns: 0 > >> >> dev.nfe.0.stats.tx.carrier_losts: 0 > >> >> dev.nfe.0.stats.tx.excess_deferrals: 0 > >> >> dev.nfe.0.stats.tx.retry_errors: 0 > >> >> > >> > > >> > Thanks. Would you show me the output of "pciconf -lcbv"? > >> > > >> > >> nfe0@pci0:0:20:0: class=0x068000 card=0x10003842 chip=0x026910de rev=0xa3 hdr=0x00 > >> vendor = 'NVIDIA Corporation' > >> device = 'MCP51 Network Bus Enumerator' > >> class = bridge > >> bar [10] = type Memory, range 32, base 0xefffb000, size 4096, enabled > >> bar [14] = type I/O Port, range 32, base 0xf200, size 8, enabled > >> cap 01[44] = powerspec 2 supports D0 D1 D2 D3 current D0 > >> > >> Interestingly, now that nfe0 is using a static IP it sometimes boots > >> up properly. Are you interested in its good working? > > > > Yes I am. Would you try attached patch and let me know whether the > > patch makes any difference on your box? > > Sorry to report: The patch was applied (to 8-stable latest code) but out > of 3 boots only one succeeded. Same stream of "nfe0: discard frame w/o > leading ethernet header (len 0 pkt len 0)" messages. Ok, back out previous patch and try attached one. --Fba/0zbH8Xs+Fj9o Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="nfe.power.diff2" Index: sys/dev/nfe/if_nfe.c =================================================================== --- sys/dev/nfe/if_nfe.c (revision 233822) +++ sys/dev/nfe/if_nfe.c (working copy) @@ -338,7 +338,10 @@ { struct nfe_softc *sc; struct ifnet *ifp; + struct mii_softc *miisc; + struct mii_data *mii; bus_addr_t dma_addr_max; + uint32_t pwr; int error = 0, i, msic, reg, rid; sc = device_get_softc(dev); @@ -614,6 +617,29 @@ device_printf(dev, "attaching PHYs failed\n"); goto fail; } + mii = device_get_softc(sc->nfe_miibus); + miisc = LIST_FIRST(&mii->mii_phys); + /* + * XXX + * This kind of magic should live in PHY driver. + * Should have better to way to use MII_OUI_REALTEK, MII_OUI_xxREALTEK + * and MII_MODEL_REALTEK_RTL8169S/MII_MODEL_xxREALTEK_RTL8169S. + */ + if (miisc->mii_mpd_oui == 0x00e04c || miisc->mii_mpd_oui == 0x000732) { + if (miisc->mii_mpd_model == 0x0011) { +#if 1 + device_printf(dev, "Forced PHY reset\n"); +#endif + pwr = NFE_READ(sc, NFE_PWR2_CTL); + NFE_WRITE(sc, NFE_PWR2_CTL, pwr | NFE_PWR2_PHY_RESET); + NFE_READ(sc, NFE_PWR2_CTL); + DELAY(1000 * 50); + NFE_WRITE(sc, NFE_PWR2_CTL, pwr); + NFE_READ(sc, NFE_PWR2_CTL); + DELAY(1000 * 50); + nfe_miibus_writereg(dev, miisc->mii_phy, 0x1F, 0); + } + } ether_ifattach(ifp, sc->eaddr); TASK_INIT(&sc->nfe_int_task, 0, nfe_int_task, sc); Index: sys/dev/nfe/if_nfereg.h =================================================================== --- sys/dev/nfe/if_nfereg.h (revision 233822) +++ sys/dev/nfe/if_nfereg.h (working copy) @@ -188,8 +188,9 @@ #define NFE_PWR_VALID (1 << 8) #define NFE_PWR_WAKEUP (1 << 15) -#define NFE_PWR2_WAKEUP_MASK 0x0f11 +#define NFE_PWR2_WAKEUP_MASK 0x0f15 #define NFE_PWR2_REVA3 (1 << 0) +#define NFE_PWR2_PHY_RESET 0x0004 #define NFE_PWR2_GATE_CLOCKS 0x0f00 #define NFE_MEDIA_SET 0x10000 --Fba/0zbH8Xs+Fj9o-- From owner-freebsd-net@FreeBSD.ORG Tue Apr 3 07:50:19 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1819F106566C for ; Tue, 3 Apr 2012 07:50:19 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from fallbackmx08.syd.optusnet.com.au (fallbackmx08.syd.optusnet.com.au [211.29.132.10]) by mx1.freebsd.org (Postfix) with ESMTP id DB1ED8FC0A for ; Tue, 3 Apr 2012 07:50:17 +0000 (UTC) Received: from mail30.syd.optusnet.com.au (mail30.syd.optusnet.com.au [211.29.133.193]) by fallbackmx08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q337oAb1030412 for ; Tue, 3 Apr 2012 17:50:10 +1000 Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail30.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q337nvP7026244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Apr 2012 17:49:59 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.5/8.14.4) with ESMTP id q337nuR9023726; Tue, 3 Apr 2012 17:49:56 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.5/8.14.5/Submit) id q337nsvh023709; Tue, 3 Apr 2012 17:49:54 +1000 (EST) (envelope-from peter) Date: Tue, 3 Apr 2012 17:49:54 +1000 From: Peter Jeremy To: Beeblebrox Message-ID: <20120403074954.GA19241@server.vk2pj.dyndns.org> References: <20120329072054.GA45082@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4Ckj6UjgE2iN1+kY" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@freebsd.org Subject: Re: lagg problems on diskless 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, 03 Apr 2012 07:50:19 -0000 --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Please don't top post. On 2012-Apr-02 12:25:06 +0300, Beeblebrox wrote: >I had looked into failover with wireless and tried it before posting, but >got nowhere. Wired/wireless on a diskfull system should be trivial. >1. With below setup in diskless client's rc.conf, the client is able to >boot and gets to login screen: >ifconfig_re1=3D"up ether 00:30:67:91:6c:c2" >cloned_interfaces=3D"lagg0" >ifconfig_lagg0=3D"up laggproto failover laggport re1 192.168.2.2 netmask >255.255.255.0" Assuming you're netbooting off re0, that looks correct. >2. ifconfig at that point shows all good: same mac addr and lagg0 active. >re0: flags=3D8843 metric 0 mtu 1500 >options=3D8209b >ether 00:30:67:91:6c:c2 >inet 192.168.2.2 netmask 0xffffff00 broadcast 192.168.2.255 This is wrong - there should't be an IP address on re0 at this point. >media: Ethernet autoselect (100baseTX ) >status: active >re1: flags=3D8843 metric 0 mtu 1500 >options=3D8209b >ether 00:30:67:91:6c:c2 >media: Ethernet autoselect (1000baseT ) >status: active >lagg0: flags=3D8843 metric 0 mtu 1= 500 >options=3D8209b >ether 00:30:67:91:6c:c2 >media: Ethernet autoselect >status: active >laggproto failover >laggport: re1 flags=3D5 > >Now if I go and unplug NIC10/100 on diskless client and "list folder", the >client will freeze - so failover does not switch. After some time passes, >client informs that NFS server 192.168.2.1 is not responding. lagg0 shows only one laggport so there's no failover. Are you sure you installed /etc/rc.d/lagg or an equivalent script? >PS- I mistakenly double-posted: >http://docs.freebsd.org/cgi/getmsg.cgi?fetch=3D39210+0+current/freebsd-net I replied to this one because it had a meaningful subject. --=20 Peter Jeremy --4Ckj6UjgE2iN1+kY Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk96q6IACgkQ/opHv/APuIdRwACgsuzqqwfUKxIiruUpKN9ZAHOs 4owAn2MscXvMvMNUxJy3ydl7VQsjtPkN =u2Wf -----END PGP SIGNATURE----- --4Ckj6UjgE2iN1+kY-- From owner-freebsd-net@FreeBSD.ORG Tue Apr 3 10:17:52 2012 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 D92BB106564A for ; Tue, 3 Apr 2012 10:17:52 +0000 (UTC) (envelope-from rsb@berentweb.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3C1C78FC0A for ; Tue, 3 Apr 2012 10:17:51 +0000 (UTC) Received: by lagv3 with SMTP id v3so6206037lag.13 for ; Tue, 03 Apr 2012 03:17:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=berentweb.com; s=google; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=vsSrcj6YYrGBBSbtH6M2T60OnYBi14+cqT/QjJnYkNI=; b=CnNHhNoP/ATYuLcIEraNQDvK35SG2po1+YfgxRXZVhWao8WP7RcHzKiMXSA9wPqE2i ficeJajt85lAIcSPLP2Qjcx3oF5ZfN0vEpMFwbk15g6769TaheBpxxDlFcbkmNboUqHo BEWGoQdp2kK3tlvqT+JF+LHOCQah3mXpmHOHo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :x-gm-message-state; bh=vsSrcj6YYrGBBSbtH6M2T60OnYBi14+cqT/QjJnYkNI=; b=hMptLjhBUL2jknr44xoNqK4zyHfRsPKsnXUxQ0y37SSQcE8e0F+lg3g/K0aQWLiHEn mv+Y9lwCONlhVaDZ4pInnr6wMXWxvy1bn/XGlxMoCq2FXaXgJ7SDzj9sOLZAoKjr8nrT dpHj/aQkTAmsDUD36tmVoWoIy0QXCcD93prlW3j5/RxT3J7ewrqcEdeAocBFcX4aBC3v rT+DYyMQ0+8g4e9o+d3HVyNTQTA5fhspdbV2PcrevQPYL3fUXAIIzKpL48Vv9fT25hTK Y08wA2pCepmjAnrg8urTHYR6CoVtEKe/BwAwCkwi2pL04EDp4LvGZv9YQLhfN9JA9URz MM8g== MIME-Version: 1.0 Received: by 10.152.132.166 with SMTP id ov6mr4568312lab.35.1333448270784; Tue, 03 Apr 2012 03:17:50 -0700 (PDT) Sender: rsb@berentweb.com Received: by 10.112.77.15 with HTTP; Tue, 3 Apr 2012 03:17:50 -0700 (PDT) X-Originating-IP: [85.110.29.196] In-Reply-To: <20120403074954.GA19241@server.vk2pj.dyndns.org> References: <20120329072054.GA45082@server.vk2pj.dyndns.org> <20120403074954.GA19241@server.vk2pj.dyndns.org> Date: Tue, 3 Apr 2012 13:17:50 +0300 X-Google-Sender-Auth: yKlzlRB5JO0_pNIPj3y30bG5UdU Message-ID: From: Beeblebrox To: freebsd-net@freebsd.org X-Gm-Message-State: ALoCoQmMkBV0uut4KSv4YhWl+eoBEJE2zTBmPjGlYShYQDr7w/LmfRGVOPrgNSJmBh8m/sRO/RGT Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: lagg problems on diskless 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, 03 Apr 2012 10:17:52 -0000 On Tue, Apr 3, 2012 at 10:49 AM, Peter Jeremy wrote: > Please don't top post. > > On 2012-Apr-02 12:25:06 +0300, Beeblebrox wrote: > >I had looked into failover with wireless and tried it before posting, but > >got nowhere. > > Wired/wireless on a diskfull system should be trivial. > > >1. With below setup in diskless client's rc.conf, the client is able to > >boot and gets to login screen: > >ifconfig_re1="up ether 00:30:67:91:6c:c2" > >cloned_interfaces="lagg0" > >ifconfig_lagg0="up laggproto failover laggport re1 192.168.2.2 netmask > >255.255.255.0" > > Assuming you're netbooting off re0, that looks correct. > > >2. ifconfig at that point shows all good: same mac addr and lagg0 active. > >re0: flags=8843 metric 0 mtu 1500 > > >options=8209b > >ether 00:30:67:91:6c:c2 > >inet 192.168.2.2 netmask 0xffffff00 broadcast 192.168.2.255 > > This is wrong - there should't be an IP address on re0 at this point. > > >media: Ethernet autoselect (100baseTX ) > >status: active > >re1: flags=8843 metric 0 mtu 1500 > > >options=8209b > >ether 00:30:67:91:6c:c2 > >media: Ethernet autoselect (1000baseT ) > >status: active > >lagg0: flags=8843 metric 0 mtu > 1500 > > >options=8209b > >ether 00:30:67:91:6c:c2 > >media: Ethernet autoselect > >status: active > >laggproto failover > >laggport: re1 flags=5 > > > >Now if I go and unplug NIC10/100 on diskless client and "list folder", the > >client will freeze - so failover does not switch. After some time passes, > >client informs that NFS server 192.168.2.1 is not responding. > > lagg0 shows only one laggport so there's no failover. Are you sure you > installed /etc/rc.d/lagg or an equivalent script? > > >PS- I mistakenly double-posted: > >http://docs.freebsd.org/cgi/getmsg.cgi?fetch=39210+0+current/freebsd-net > > I replied to this one because it had a meaningful subject. > > -- > Peter Jeremy > > Please don't top post. Wasn't aware I was doing that. This is better I hope? > Assuming you're netbooting off re0, that looks correct. YES, re0 is the BIOS detected NIC > Are you sure you installed /etc/rc.d/lagg or an equivalent script? I had not noticed the link to the script at the bottom - I placed script in DC's private conf//etc/rc.d then booted the DC. I got system freeze and 1 message: ifconfig: interface re0 cannot change link address! looking through the script I found the problem: lagg_tmp:=/mnt. My DC /root is *ro* so I'll have to change it to another tmp. Considering that my /var and /etc are md-mounted, using either seems out of the question. I also have /tmp mounted as tmpfs. Can I mkdir -p /tmp/lagg and mount lagg_tmp there or does it have to be an NFS shared location - what do you suggest? Thanks. From owner-freebsd-net@FreeBSD.ORG Tue Apr 3 11:51:58 2012 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 CC1E0106566C for ; Tue, 3 Apr 2012 11:51:58 +0000 (UTC) (envelope-from rsb@berentweb.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 31E798FC12 for ; Tue, 3 Apr 2012 11:51:57 +0000 (UTC) Received: by lagv3 with SMTP id v3so6343831lag.13 for ; Tue, 03 Apr 2012 04:51:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=berentweb.com; s=google; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=6O6mj+gTCf8pxr9d/rbNjj8Wr4IoQMbAhQwGn6SjF8Y=; b=BZz+ziYZlGFmElMwcv4Zu8cX786J4/NZVLbI33Nvdb9dccUncARNHQH5CCWREgJ4CE KPNtPj9PupJVuDlOp7sHq+z4WFMADYwc4pmDgUSUmRt4uoyWg07HW+cdkKuylDvWPqc3 /9dcSheTx3zB+ZITDvWb0ramhCU4Q6NQ7Z+2w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :x-gm-message-state; bh=6O6mj+gTCf8pxr9d/rbNjj8Wr4IoQMbAhQwGn6SjF8Y=; b=PTWNScQJqXyPJ3ycnV3u5O7EAFdk+OxeM+BpppAt6D3kKqRCR/gJbFP4xUotw9ey4S fSU4uof7FSl/1ILh0QLrnBj4yD2AO5OxRpTWeaRp93lIEFQ0kxqPvMx+Ok1G3885zlNa kkMOLNywiaogchlEo9At/mHmaBFhlZ5Ra1Yns5sL6opU60+LEUVzv6g1UMNTFHz2LUGB QkLXUOvRWosfG95YeEwPMwPYO87es/uT1bRcq7NJCZoEkXo9hPYTvE4gSx34zrQj/ezT 3Uwae0wXseWV7PiaMnjiTctTqFU/pMjMdoSyaGT9BsMbwxTmgi2ncwogOrLd5GCAP67r 8lKQ== MIME-Version: 1.0 Received: by 10.152.133.144 with SMTP id pc16mr13902233lab.0.1333453917052; Tue, 03 Apr 2012 04:51:57 -0700 (PDT) Sender: rsb@berentweb.com Received: by 10.112.77.15 with HTTP; Tue, 3 Apr 2012 04:51:57 -0700 (PDT) X-Originating-IP: [85.110.29.196] In-Reply-To: References: <20120329072054.GA45082@server.vk2pj.dyndns.org> <20120403074954.GA19241@server.vk2pj.dyndns.org> Date: Tue, 3 Apr 2012 14:51:57 +0300 X-Google-Sender-Auth: uUZJUq_kjQbo5xDozJIFg_DBv28 Message-ID: From: Beeblebrox To: freebsd-net@freebsd.org X-Gm-Message-State: ALoCoQmkDNzqlpQI+9qCwsF3FK+PrFut+qqoWmFuV0PlQnJCbt9K0Xu/BBEKiM6ENvXHAdm+9ds4 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: lagg problems on diskless 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, 03 Apr 2012 11:51:58 -0000 > > > > Please don't top post. > Wasn't aware I was doing that. This is better I hope? > > > Assuming you're netbooting off re0, that looks correct. > YES, re0 is the BIOS detected NIC > > > Are you sure you installed /etc/rc.d/lagg or an equivalent script? > I had not noticed the link to the script at the bottom - I placed script > in DC's private conf//etc/rc.d then booted the DC. I got system freeze > and 1 message: > ifconfig: interface re0 cannot change link address! > looking through the script I found the problem: lagg_tmp:=/mnt. My DC > /root is *ro* so I'll have to change it to another tmp. Considering that > my /var and /etc are md-mounted, using either seems out of the question. I > also have /tmp mounted as tmpfs. Can I mkdir -p /tmp/lagg and mount > lagg_tmp there or does it have to be an NFS shared location - what do you > suggest? > > Thanks. > Slightly different point of view: Under this scenario of dikless clients having dual NICs would CRAP be a choice to consider? From what I have read it can offer loadbalancing but as I understand it's not really applicable to diskless node situations? Thank You. From owner-freebsd-net@FreeBSD.ORG Tue Apr 3 13:45:23 2012 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 086BC106564A for ; Tue, 3 Apr 2012 13:45:23 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 2AADE8FC1B for ; Tue, 3 Apr 2012 13:45:21 +0000 (UTC) Received: (qmail 25802 invoked from network); 3 Apr 2012 13:43:38 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 3 Apr 2012 13:43:38 -0000 Message-ID: <4F7AFEEF.60708@freebsd.org> Date: Tue, 03 Apr 2012 15:45:19 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Darren Reed References: <4F75C1A3.4030401@freebsd.org> <4F75D9ED.7080707@freebsd.org> <4F780373.6030107@freebsd.org> In-Reply-To: <4F780373.6030107@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: darrenr@freebsd.org, freebsd-net@freebsd.org Subject: Re: FreeBSD TCP ignores zero window size 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, 03 Apr 2012 13:45:23 -0000 On 01.04.2012 09:27, Darren Reed wrote: > Andre, > > Your changes bring it closer to working correctly with a > small change: rather than "tiwin > tp->snd_wnd", it should > be "tiwin != tp->snd_wnd". In this trace, the remote end > has set a window scale factor of 5 during connection > establishment. > > The same change should be made in the if() a few lines down. Window updates are a tricky thing by that we must not accept old and outdated segments to update our window. Hence we have to test for freshness while at the same time be open enough to handle weird cases like bidirectional data transfers on lossy links with data waiting in reassembly queues on both sides. There are two clear cut cases we can accept a window update: a) the incoming segment ACK'ed new data (moved snd_una). b) the incoming segment carries new data (moved rcv_nxt). The latter gets tricky already with the addition of the reassembly queue. Here only segments that have a higher SEQ than highest already present in the reassembly queue are OK. And then we have a window probe where we'll get an answer that neither moves our ACK (zero byte probes) nor carries any data. Here the window update is vital for the future progress of the session. > The problem here is that it only tracks the window size as > it grows, not as it shrinks. Thus the remote end setting its > window size to 0 is ignored. My patch is wrong as the acked count is already integrated by the time we reach this spot. I'm working on a better implementation. > But having made that change, there appears to be still one > problem that still lingers. As can be seen below, freebsd 8.2 > fails to properly ack the data that the remote end is trying > to send, ultimately causing the connection to be dropped. It's the other way around. remote.ssh is sending old data which freebsd82.62922 has already ack'ed. The sessions seems to be de-synchronized, perhaps some middle box mucking with the segments trying to modulate something? > Darren > > 16:06:50.207927 IP remote.ssh > freebsd82.62922: . 6268613:6270053(1440) ack 367219 win 128 > > 16:06:50.208736 IP freebsd82.62922 > remote.ssh: . ack 6270053 win 8100 > 16:06:50.210902 IP remote.ssh > freebsd82.62922: . 6270053:6271493(1440) ack 367219 win 128 > > 16:06:50.211752 IP freebsd82.62922 > remote.ssh: . ack 6271493 win 8280 ACK 6,271,493 for data segment preceeding it. > 16:06:50.229987 IP remote.ssh > freebsd82.62922: . ack 370099 win 38 > 16:06:50.419926 IP remote.ssh > freebsd82.62922: . ack 371315 win 0 > 16:06:50.422858 IP remote.ssh > freebsd82.62922: . ack 371315 win 0 > 16:06:51.207172 IP freebsd82.62922 > remote.ssh: . ack 6271493 win 8280 > 16:06:51.419263 IP remote.ssh > freebsd82.62922: . ack 371315 win 0 > 16:06:53.203547 IP remote.ssh > freebsd82.62922: . 6267173:6268613(1440) ack 371315 win 0 > Incoming old data 6,267,173+1440 already ACK'ed 4320 bytes ago. > 16:06:53.204320 IP freebsd82.62922 > remote.ssh: . ack 6271493 win 8280 ACK for highest SEQ seen again to re-synchronize. > 16:06:53.415648 IP remote.ssh > freebsd82.62922: . ack 371315 win 0 > 16:06:59.207766 IP remote.ssh > freebsd82.62922: . 6267173:6268613(1440) ack 371315 win 0 > remote.ssh doesn't get and retransmits... > 16:06:59.208469 IP freebsd82.62922 > remote.ssh: . ack 6271493 win 8280 > 16:06:59.419342 IP remote.ssh > freebsd82.62922: . ack 371315 win 0 > 16:07:11.212606 IP remote.ssh > freebsd82.62922: . 6267173:6267697(524) ack 371315 win 0 > keeps on going with reduced MSS. > 16:07:11.213158 IP freebsd82.62922 > remote.ssh: . ack 6271493 win 8280 > 16:07:11.424414 IP remote.ssh > freebsd82.62922: . ack 371315 win 0 > 16:07:35.227356 IP remote.ssh > freebsd82.62922: . 6267173:6267697(524) ack 371315 win 0 > > 16:07:35.227954 IP freebsd82.62922 > remote.ssh: . ack 6271493 win 8280 > 16:07:35.440105 IP remote.ssh > freebsd82.62922: . ack 371315 win 0 > 16:08:23.257747 IP remote.ssh > freebsd82.62922: . 6267173:6267697(524) ack 371315 win 0 > > 16:08:23.258471 IP freebsd82.62922 > remote.ssh: . ack 6271493 win 8280 > 16:08:23.469790 IP remote.ssh > freebsd82.62922: . ack 371315 win 0 > 16:09:27.299037 IP remote.ssh > freebsd82.62922: . 6267173:6267697(524) ack 371315 win 0 > > 16:09:27.299734 IP freebsd82.62922 > remote.ssh: . ack 6271493 win 8280 > 16:09:27.510740 IP remote.ssh > freebsd82.62922: . ack 371315 win 0 > 16:10:31.340328 IP remote.ssh > freebsd82.62922: . 6267173:6267697(524) ack 371315 win 0 > > 16:10:31.340996 IP freebsd82.62922 > remote.ssh: . ack 6271493 win 8280 > 16:10:31.552639 IP remote.ssh > freebsd82.62922: . ack 371315 win 0 > 16:11:35.380906 IP remote.ssh > freebsd82.62922: . 6267173:6267697(524) ack 371315 win 0 > > 16:11:35.381519 IP freebsd82.62922 > remote.ssh: . ack 6271493 win 8280 > 16:11:35.592948 IP remote.ssh > freebsd82.62922: . ack 371315 win 0 > 16:12:39.421327 IP remote.ssh > freebsd82.62922: . 6267173:6267697(524) ack 371315 win 0 > > 16:12:39.421957 IP freebsd82.62922 > remote.ssh: . ack 6271493 win 8280 > 16:12:39.633531 IP remote.ssh > freebsd82.62922: . ack 371315 win 0 > 16:13:43.462137 IP remote.ssh > freebsd82.62922: . 6267173:6267697(524) ack 371315 win 0 > > 16:13:43.462625 IP freebsd82.62922 > remote.ssh: . ack 6271493 win 8280 > 16:13:43.674110 IP remote.ssh > freebsd82.62922: . ack 371315 win 0 > 16:14:47.502951 IP remote.ssh > freebsd82.62922: . 6267173:6267697(524) ack 371315 win 0 > > 16:14:47.503637 IP freebsd82.62922 > remote.ssh: . ack 6271493 win 8280 > 16:14:47.715729 IP remote.ssh > freebsd82.62922: . ack 371315 win 0 > 16:15:51.542134 IP remote.ssh > freebsd82.62922: . 6267173:6267697(524) ack 371315 win 0 > > 16:15:51.542794 IP freebsd82.62922 > remote.ssh: . ack 6271493 win 8280 > 16:16:55.581199 IP remote.ssh > freebsd82.62922: R 6271493:6271493(0) ack 371315 win 0 Retransmission timeout exhausted and sending a reset with the correct SEQ that freebsd82.62922 is trying to ack all the time! The time difference between that last sync-ack and the RST doesn't make it look like a direct response as in a closed socket. -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Apr 3 13:49:45 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0C459106566B; Tue, 3 Apr 2012 13:49:45 +0000 (UTC) (envelope-from andre@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D357B8FC08; Tue, 3 Apr 2012 13:49:44 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q33DniTh069175; Tue, 3 Apr 2012 13:49:44 GMT (envelope-from andre@freefall.freebsd.org) Received: (from andre@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q33DnijS069170; Tue, 3 Apr 2012 13:49:44 GMT (envelope-from andre) Date: Tue, 3 Apr 2012 13:49:44 GMT Message-Id: <201204031349.q33DnijS069170@freefall.freebsd.org> To: hunter@comsys.com.ua, andre@FreeBSD.org, freebsd-net@FreeBSD.org, andre@FreeBSD.org From: andre@FreeBSD.org Cc: Subject: Re: kern/166501: [pf] FreeBSD 9.0 generates incorrect SEC/ACK numbers under load 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, 03 Apr 2012 13:49:45 -0000 Old Synopsis: [net] FreeBSD 9.0 generates incorrect SEC/ACK numbers under load New Synopsis: [pf] FreeBSD 9.0 generates incorrect SEC/ACK numbers under load State-Changed-From-To: open->analyzed State-Changed-By: andre State-Changed-When: Tue Apr 3 13:46:57 UTC 2012 State-Changed-Why: The problem was found to be an issue with pf state modulation, not FreeBSD's TCP implementation. Responsible-Changed-From-To: freebsd-net->andre Responsible-Changed-By: andre Responsible-Changed-When: Tue Apr 3 13:46:57 UTC 2012 Responsible-Changed-Why: Take over. http://www.freebsd.org/cgi/query-pr.cgi?pr=166501 From owner-freebsd-net@FreeBSD.ORG Tue Apr 3 14:26:22 2012 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 17FB91065670; Tue, 3 Apr 2012 14:26:22 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id C73D68FC0A; Tue, 3 Apr 2012 14:26:21 +0000 (UTC) Received: from [192.168.43.26] (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.5/8.14.4) with ESMTP id q33EQK8g049327; Tue, 3 Apr 2012 10:26:20 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <4F7B0886.70200@sentex.net> Date: Tue, 03 Apr 2012 10:26:14 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Darren Baginski References: <167651329324260@web72.yandex.ru> <316881329935015@web67.yandex.ru> <4F453A06.9060101@sentex.net> <637271333462764@web119.yandex.ru> In-Reply-To: <637271333462764@web119.yandex.ru> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.71 on 64.7.153.18 Cc: "freebsd-net@freebsd.org" , Adrian Chadd , Jack Vogel Subject: Re: IGB freezes after about 2 weeks of uptime 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, 03 Apr 2012 14:26:22 -0000 Hi, Try the driver from HEAD. It has a number of fixes in it to both the igb and em drivers that is not yet in RELENG_9 nor 8 http://lists.freebsd.org/pipermail/svn-src-head/2012-March/035888.html ---Mike On 4/3/2012 10:19 AM, Darren Baginski wrote: > Still getting same errors on > FreeBSD srv-4-2.lab.local 9.0-STABLE FreeBSD 9.0-STABLE #3: Mon Apr 2 > 19:07:20 UTC 2012 > root@srv-4-2.lab.local:/usr/obj/usr/src/sys/GENERIC amd64 > It's only me or it's known problem ? > > 22.02.2012, 23:46, "Jack Vogel" : >> Mike is correct, 8.3 was looming, it is important to a lot of my >> customers so it >> has taken priority, 9 stable will be coming... >> >> Jack >> >> >> On Wed, Feb 22, 2012 at 10:55 AM, Mike Tancsa > > wrote: >> >> I dont think the driver changes from HEAD were ever MFC'd to 9.x. >> Only >> to 8.x >> >> ---Mike >> >> On 2/22/2012 1:23 PM, Darren Baginski wrote: >> > Same problem on >> > FreeBSD srv-4-2.lab.local 9.0-STABLE FreeBSD 9.0-STABLE #2: Wed >> Feb 22 18:10:53 UTC 2012 root@srv-4-2.lab.local >> :/usr/obj/usr/src/sys/GENERIC amd64 >> > >> > 16.02.2012, 02:27, "Jack Vogel" > >: >> >> And assuming its from the release, please upgrade it to HEAD >> and try again. >> >> >> >> Jack >> >> >> >> On Wed, Feb 15, 2012 at 2:14 PM, Adrian Chadd >> > wrote: >> >>> are you running the driver from that release, or the -HEAD driver? >> >>> >> >>> adrian >> >>> _______________________________________________ >> >>> 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 >> " >> > _______________________________________________ >> > 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 >> " >> > >> > >> >> -- >> ------------------- >> Mike Tancsa, tel +1 519 651 3400 >> Sentex Communications, mike@sentex.net >> Providing Internet services since 1994 www.sentex.net >> >> Cambridge, Ontario Canada http://www.tancsa.com/ -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-net@FreeBSD.ORG Tue Apr 3 14:19:27 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3C725106566B; Tue, 3 Apr 2012 14:19:27 +0000 (UTC) (envelope-from kickbsd@yandex.ru) Received: from forward6.mail.yandex.net (unknown [IPv6:2a02:6b8:0:202:22cf:30ff:fe6b:6ebc]) by mx1.freebsd.org (Postfix) with ESMTP id 8FDF78FC0C; Tue, 3 Apr 2012 14:19:26 +0000 (UTC) Received: from web119.yandex.ru (web119.yandex.ru [77.88.60.96]) by forward6.mail.yandex.net (Yandex) with ESMTP id 4F3E1112133E; Tue, 3 Apr 2012 18:19:25 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.com; s=mail; t=1333462765; bh=kioosrrSGF8wcrP9AZ4HaygHgiULc4iBfyyimFVFwJc=; h=From:To:Cc:In-Reply-To:References:Subject:MIME-Version:Message-Id: Date:Content-Transfer-Encoding:Content-Type; b=D52DOS9+ns0jkQaGbtbdSO2CKFFkUpNnlpd26oAqibh9c4Vvoguih1Bm9ynNOHa0j Tf8HmZ5MVpfz26yPtqCFJ9a9wrd6n7CatAuwwAeW38DSTBha+eDDeWAnu6ygTMuMQL fR0tHu4UhWxLpzQ2ta8skzfCsFvF1bsykmZPqknM= Received: from 127.0.0.1 (localhost.localdomain [127.0.0.1]) by web119.yandex.ru (Yandex) with ESMTP id E5F839318058; Tue, 3 Apr 2012 18:19:24 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.com; s=mail; t=1333462765; bh=kioosrrSGF8wcrP9AZ4HaygHgiULc4iBfyyimFVFwJc=; h=From:To:Cc:In-Reply-To:References:Subject:MIME-Version:Message-Id: Date:Content-Transfer-Encoding:Content-Type; b=D52DOS9+ns0jkQaGbtbdSO2CKFFkUpNnlpd26oAqibh9c4Vvoguih1Bm9ynNOHa0j Tf8HmZ5MVpfz26yPtqCFJ9a9wrd6n7CatAuwwAeW38DSTBha+eDDeWAnu6ygTMuMQL fR0tHu4UhWxLpzQ2ta8skzfCsFvF1bsykmZPqknM= Received: from leo.de.teleglobe.net (leo.de.teleglobe.net [64.86.53.146]) by web119.yandex.ru with HTTP; Tue, 03 Apr 2012 18:19:24 +0400 From: Darren Baginski Envelope-From: kickbsd@yandex.ru To: Jack Vogel In-Reply-To: References: <167651329324260@web72.yandex.ru> <316881329935015@web67.yandex.ru> <4F453A06.9060101@sentex.net> Message-Id: <637271333462764@web119.yandex.ru> Date: Tue, 03 Apr 2012 18:19:24 +0400 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Content-Transfer-Encoding: base64 X-Mailman-Approved-At: Tue, 03 Apr 2012 15:18:42 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-net@freebsd.org" , Adrian Chadd , Mike Tancsa Subject: Re: IGB freezes after about 2 weeks of uptime 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, 03 Apr 2012 14:19:27 -0000 PGRpdj5TdGlsbCBnZXR0aW5nIHNhbWUgZXJyb3JzIG9uPC9kaXY+PGRpdj6aRnJlZUJTRC BzcnYt NC0yLmxhYi5sb2NhbCA5LjAtU1RBQkxFIEZyZWVCU0QgOS4wLVNUQUJMRSAjMzogTW9uIE FwciCa MiAxOTowNzoyMCBVVEMgMjAxMiCaIJogcm9vdEBzcnYtNC0yLmxhYi5sb2NhbDovdXNyL2 9iai91 c3Ivc3JjL3N5cy9HRU5FUklDIJphbWQ2NDwvZGl2PjxkaXY+SXQncyBvbmx5IG1lIG9yIG l0J3Mg a25vd24gcHJvYmxlbSA/PC9kaXY+PGRpdj6aPC9kaXY+PGRpdj4yMi4wMi4yMDEyLCAyMz o0Niwg IkphY2sgVm9nZWwiICZsdDtqZnZvZ2VsQGdtYWlsLmNvbSZndDs6PC9kaXY+PGJsb2NrcX VvdGUg dHlwZT0iY2l0ZSI+TWlrZSBpcyBjb3JyZWN0LCA4LjMgd2FzIGxvb21pbmcsIGl0IGlzIG ltcG9y dGFudCB0byBhIGxvdCBvZiBteSBjdXN0b21lcnMgc28gaXQ8YnIgLz5oYXMgdGFrZW4gcH Jpb3Jp dHksIDkgc3RhYmxlIHdpbGwgYmUgY29taW5nLi4uPGJyIC8+PGJyIC8+SmFjazxiciAvPj xiciAv PjxiciAvPjxkaXY+T24gV2VkLCBGZWIgMjIsIDIwMTIgYXQgMTA6NTUgQU0sIE1pa2UgVG FuY3Nh IDxzcGFuIGRpcj0ibHRyIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOm1pa2VAc2VudGV4Lm5ldC I+bWlr ZUBzZW50ZXgubmV0PC9hPiZndDs8L3NwYW4+IHdyb3RlOjxiciAvPjxibG9ja3F1b3RlIH N0eWxl PSJtYXJnaW46MCAwIDAgMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZG luZy1s ZWZ0OjFleDsiPkkgZG9udCB0aGluayB0aGUgZHJpdmVyIGNoYW5nZXMgZnJvbSBIRUFEIH dlcmUg ZXZlciBNRkMnZCB0byA5LnguIJpPbmx5PGJyIC8+IHRvIDgueDxiciAvPiA8YnIgLz4gmi CaIJog mi0tLU1pa2U8YnIgLz48ZGl2PjxkaXY+PGJyIC8+IE9uIDIvMjIvMjAxMiAxOjIzIFBNLC BEYXJy ZW4gQmFnaW5za2kgd3JvdGU6PGJyIC8+ICZndDsgU2FtZSBwcm9ibGVtIG9uPGJyIC8+IC ZndDsg RnJlZUJTRCBzcnYtNC0yLmxhYi5sb2NhbCA5LjAtU1RBQkxFIEZyZWVCU0QgOS4wLVNUQU JMRSAj MjogV2VkIEZlYiAyMiAxODoxMDo1MyBVVEMgMjAxMiCaIJogPGEgaHJlZj0ibWFpbHRvOn Jvb3RA c3J2LTQtMi5sYWIubG9jYWwiPnJvb3RAc3J2LTQtMi5sYWIubG9jYWw8L2E+Oi91c3Ivb2 JqL3Vz ci9zcmMvc3lzL0dFTkVSSUMgmmFtZDY0PGJyIC8+ICZndDs8YnIgLz4gJmd0OyAxNi4wMi 4yMDEy LCAwMjoyNywgIkphY2sgVm9nZWwiICZsdDs8YSBocmVmPSJtYWlsdG86amZ2b2dlbEBnbW FpbC5j b20iPmpmdm9nZWxAZ21haWwuY29tPC9hPiZndDs6PGJyIC8+ICZndDsmZ3Q7IEFuZCBhc3 N1bWlu ZyBpdHMgZnJvbSB0aGUgcmVsZWFzZSwgcGxlYXNlIHVwZ3JhZGUgaXQgdG8gSEVBRCBhbm QgdHJ5 IGFnYWluLjxiciAvPiAmZ3Q7Jmd0OzxiciAvPiAmZ3Q7Jmd0OyBKYWNrPGJyIC8+ICZndD smZ3Q7 PGJyIC8+ICZndDsmZ3Q7IE9uIFdlZCwgRmViIDE1LCAyMDEyIGF0IDI6MTQgUE0sIEFkcm lhbiBD aGFkZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFkcmlhbkBmcmVlYnNkLm9yZyI+YWRyaWFuQG ZyZWVi c2Qub3JnPC9hPiZndDsgd3JvdGU6PGJyIC8+ICZndDsmZ3Q7Jmd0OyBhcmUgeW91IHJ1bm 5pbmcg dGhlIGRyaXZlciBmcm9tIHRoYXQgcmVsZWFzZSwgb3IgdGhlIC1IRUFEIGRyaXZlcj88Yn IgLz4g Jmd0OyZndDsmZ3Q7PGJyIC8+ICZndDsmZ3Q7Jmd0OyBhZHJpYW48YnIgLz4gJmd0OyZndD smZ3Q7 IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIC 8+ICZn dDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86ZnJlZWJzZC1uZXRAZnJlZWJzZC5vcmciPm ZyZWVi c2QtbmV0QGZyZWVic2Qub3JnPC9hPiBtYWlsaW5nIGxpc3Q8YnIgLz4gJmd0OyZndDsmZ3 Q7IDxh IGhyZWY9Imh0dHA6Ly9saXN0cy5mcmVlYnNkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ZyZW Vic2Qt bmV0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2xpc3RzLmZyZWVic2Qub3JnL21haWxtYW 4vbGlz dGluZm8vZnJlZWJzZC1uZXQ8L2E+PGJyIC8+ICZndDsmZ3Q7Jmd0OyBUbyB1bnN1YnNjcm liZSwg c2VuZCBhbnkgbWFpbCB0byAiPGEgaHJlZj0ibWFpbHRvOmZyZWVic2QtbmV0LXVuc3Vic2 NyaWJl QGZyZWVic2Qub3JnIj5mcmVlYnNkLW5ldC11bnN1YnNjcmliZUBmcmVlYnNkLm9yZzwvYT 4iPGJy IC8+ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX1 9fX188 YnIgLz4gJmd0OyA8YSBocmVmPSJtYWlsdG86ZnJlZWJzZC1uZXRAZnJlZWJzZC5vcmciPm ZyZWVi c2QtbmV0QGZyZWVic2Qub3JnPC9hPiBtYWlsaW5nIGxpc3Q8YnIgLz4gJmd0OyA8YSBocm VmPSJo dHRwOi8vbGlzdHMuZnJlZWJzZC5vcmcvbWFpbG1hbi9saXN0aW5mby9mcmVlYnNkLW5ldC IgdGFy Z2V0PSJfYmxhbmsiPmh0dHA6Ly9saXN0cy5mcmVlYnNkLm9yZy9tYWlsbWFuL2xpc3Rpbm ZvL2Zy ZWVic2QtbmV0PC9hPjxiciAvPiAmZ3Q7IFRvIHVuc3Vic2NyaWJlLCBzZW5kIGFueSBtYW lsIHRv ICI8YSBocmVmPSJtYWlsdG86ZnJlZWJzZC1uZXQtdW5zdWJzY3JpYmVAZnJlZWJzZC5vcm ciPmZy ZWVic2QtbmV0LXVuc3Vic2NyaWJlQGZyZWVic2Qub3JnPC9hPiI8YnIgLz4gJmd0Ozxici AvPiAm Z3Q7PGJyIC8+IDxiciAvPiA8L2Rpdj48L2Rpdj48c3Bhbj48c3BhbiBzdHlsZT0iY29sb3 I6Izg4 ODg4ODsiPi0tPGJyIC8+IC0tLS0tLS0tLS0tLS0tLS0tLS08YnIgLz4gTWlrZSBUYW5jc2 EsIHRl bCA8YSBocmVmPSJ0ZWw6JTJCMSUyMDUxOSUyMDY1MSUyMDM0MDAiPisxIDUxOSA2NTEgMz QwMDwv YT48YnIgLz4gU2VudGV4IENvbW11bmljYXRpb25zLCA8YSBocmVmPSJtYWlsdG86bWlrZU BzZW50 ZXgubmV0Ij5taWtlQHNlbnRleC5uZXQ8L2E+PGJyIC8+IFByb3ZpZGluZyBJbnRlcm5ldC BzZXJ2 aWNlcyBzaW5jZSAxOTk0IDxhIGhyZWY9Imh0dHA6Ly93d3cuc2VudGV4Lm5ldCIgdGFyZ2 V0PSJf YmxhbmsiPnd3dy5zZW50ZXgubmV0PC9hPjxiciAvPiBDYW1icmlkZ2UsIE9udGFyaW8gQ2 FuYWRh IJogPGEgaHJlZj0iaHR0cDovL3d3dy50YW5jc2EuY29tLyIgdGFyZ2V0PSJfYmxhbmsiPm h0dHA6 Ly93d3cudGFuY3NhLmNvbS88L2E+PGJyIC8+IDwvc3Bhbj48L3NwYW4+PC9ibG9ja3F1b3 RlPjwv ZGl2PjwvYmxvY2txdW90ZT4= From owner-freebsd-net@FreeBSD.ORG Tue Apr 3 15:38:48 2012 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 82733106564A for ; Tue, 3 Apr 2012 15:38:48 +0000 (UTC) (envelope-from darrenr@freebsd.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 48A898FC0A for ; Tue, 3 Apr 2012 15:38:48 +0000 (UTC) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id A16B621795 for ; Tue, 3 Apr 2012 11:38:47 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute1.internal (MEProxy); Tue, 03 Apr 2012 11:38:47 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:reply-to :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=jCXgeyaFG/fdwGMUJzmLC8 2z/vE=; b=bZvrjxxHbZkJ+BjWQw5INBtVjttht8TObwHlQVf0xzicJvkn/i/qRH Nykv0uCtehWWde2ccABUrFmH1Xb8iOSk5FxvmgUCY1hiQHGjteIijS26fF/k4cR6 l+LQtgJw3HSw34cAYuMHzzHDE+7LsuBA7dmwR9yrZuW7+YTj2+2yo= X-Sasl-enc: g5Fpsna5nowLPVhjajIxW9pZa8R8RQN7IUhz2KFl1Q1y 1333467527 Received: from [192.168.1.124] (dsl-202-45-110-141-static.VIC.netspace.net.au [202.45.110.141]) by mail.messagingengine.com (Postfix) with ESMTPSA id A105A482590; Tue, 3 Apr 2012 11:38:46 -0400 (EDT) Message-ID: <4F7B1981.1050009@freebsd.org> Date: Wed, 04 Apr 2012 01:38:41 +1000 From: Darren Reed Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-AU; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: Andre Oppermann References: <4F75C1A3.4030401@freebsd.org> <4F75D9ED.7080707@freebsd.org> <4F780373.6030107@freebsd.org> <4F7AFEEF.60708@freebsd.org> In-Reply-To: <4F7AFEEF.60708@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD TCP ignores zero window size X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: darrenr@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 15:38:48 -0000 On 3/04/2012 11:45 PM, Andre Oppermann wrote: > On 01.04.2012 09:27, Darren Reed wrote: >> Andre, >> >> Your changes bring it closer to working correctly with a >> small change: rather than "tiwin > tp->snd_wnd", it should >> be "tiwin != tp->snd_wnd". In this trace, the remote end >> has set a window scale factor of 5 during connection >> establishment. >> >> The same change should be made in the if() a few lines down. > > Window updates are a tricky thing by that we must not accept > old and outdated segments to update our window. Hence we have > to test for freshness while at the same time be open enough > to handle weird cases like bidirectional data transfers on > lossy links with data waiting in reassembly queues on both > sides. > > There are two clear cut cases we can accept a window update: > > a) the incoming segment ACK'ed new data (moved snd_una). > b) the incoming segment carries new data (moved rcv_nxt). > > The latter gets tricky already with the addition of the > reassembly queue. Here only segments that have a higher SEQ > than highest already present in the reassembly queue are OK. > > And then we have a window probe where we'll get an answer > that neither moves our ACK (zero byte probes) nor carries > any data. Here the window update is vital for the future > progress of the session. Hmmm, what about retransmitted data that fills a response in response to a TCP packet with SACK present? So that would be (b) from above but rcv_nxt does not get moved? So remote sends 4 packets with 1440 data bytes, freebsd82 receives pkts 1, 3 & 4, ACK's 1, uses SACK to repsond to 3 & 4, new data arrives from remote at freebsd82 but with the TCP window set to 0. >> The problem here is that it only tracks the window size as >> it grows, not as it shrinks. Thus the remote end setting its >> window size to 0 is ignored. > > My patch is wrong as the acked count is already integrated > by the time we reach this spot. I'm working on a better > implementation. Ok, I'll look forward to seeing and testing it. > It's the other way around. remote.ssh is sending old data > which freebsd82.62922 has already ack'ed. The sessions seems > to be de-synchronized, perhaps some middle box mucking with > the segments trying to modulate something? I suspect that the ISP is dropping packets and/or applying some other means of throttling the connection. So, yes. Darren From owner-freebsd-net@FreeBSD.ORG Tue Apr 3 15:39:20 2012 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 1233C106566C; Tue, 3 Apr 2012 15:39:20 +0000 (UTC) (envelope-from kickbsd@yandex.ru) Received: from forward8.mail.yandex.net (forward8.mail.yandex.net [IPv6:2a02:6b8:0:202::3]) by mx1.freebsd.org (Postfix) with ESMTP id 3027A8FC18; Tue, 3 Apr 2012 15:39:19 +0000 (UTC) Received: from web119.yandex.ru (web119.yandex.ru [77.88.60.96]) by forward8.mail.yandex.net (Yandex) with ESMTP id A69D1F61804; Tue, 3 Apr 2012 19:39:17 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.com; s=mail; t=1333467557; bh=6UxfzrWbxce7lZKaeO1qDKXsxTAPB8uwyJ5qKImPraI=; h=From:To:Cc:In-Reply-To:References:Subject:MIME-Version:Message-Id: Date:Content-Transfer-Encoding:Content-Type; b=iWm52tOKYkp7H6VFkxjoD64QVA49XqHEUKeltOc4+ELgp8Qg9Lo4AYQUHHRE3h2yh 9dLva/2GJF20ewfE4SWZC3F66Tm0BD3nWE4YowFpV1EgnnjKck6WFJZldzfGXosd5B rLV5+IJyfc3UmFlsJ4SX4WF1TQ9zn2oG/zT1rooA= Received: from 127.0.0.1 (localhost.localdomain [127.0.0.1]) by web119.yandex.ru (Yandex) with ESMTP id 491CC9318058; Tue, 3 Apr 2012 19:39:17 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.com; s=mail; t=1333467557; bh=6UxfzrWbxce7lZKaeO1qDKXsxTAPB8uwyJ5qKImPraI=; h=From:To:Cc:In-Reply-To:References:Subject:MIME-Version:Message-Id: Date:Content-Transfer-Encoding:Content-Type; b=iWm52tOKYkp7H6VFkxjoD64QVA49XqHEUKeltOc4+ELgp8Qg9Lo4AYQUHHRE3h2yh 9dLva/2GJF20ewfE4SWZC3F66Tm0BD3nWE4YowFpV1EgnnjKck6WFJZldzfGXosd5B rLV5+IJyfc3UmFlsJ4SX4WF1TQ9zn2oG/zT1rooA= Received: from leo.de.teleglobe.net (leo.de.teleglobe.net [64.86.53.146]) by web119.yandex.ru with HTTP; Tue, 03 Apr 2012 19:39:17 +0400 From: Darren Baginski Envelope-From: kickbsd@yandex.ru To: Mike Tancsa In-Reply-To: <4F7B0886.70200@sentex.net> References: <167651329324260@web72.yandex.ru> <316881329935015@web67.yandex.ru> <4F453A06.9060101@sentex.net> <637271333462764@web119.yandex.ru> <4F7B0886.70200@sentex.net> MIME-Version: 1.0 Message-Id: <671621333467557@web119.yandex.ru> Date: Tue, 03 Apr 2012 19:39:17 +0400 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=koi8-r Cc: "freebsd-net@freebsd.org" , Adrian Chadd , Jack Vogel Subject: Re: IGB freezes after about 2 weeks of uptime 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, 03 Apr 2012 15:39:20 -0000 Still getting: igb0: Watchdog timeout -- resetting igb0: Queue(0) tdh = 0, hw tdt = 15 igb0: TX(0) desc avail = 49374,Next TX to Clean = -559038242 igb0: link state changed to DOWN igb0: link state changed to UP igb0: Watchdog timeout -- resetting igb0: Queue(0) tdh = 16, hw tdt = 21 igb0: TX(0) desc avail = 49374,Next TX to Clean = -559038242 igb0: link state changed to DOWN igb0: link state changed to UP igb0: Watchdog timeout -- resetting igb0: Queue(0) tdh = 448, hw tdt = 454 igb0: TX(0) desc avail = 49374,Next TX to Clean = -559038242 igb0: link state changed to DOWN igb0: link state changed to UP [root@srv-4-2 ~]# uname -a FreeBSD srv-4-2.lab.local 10.0-CURRENT FreeBSD 10.0-CURRENT #4: Tue Apr 3 15:08:28 UTC 2012 root@srv-4-2.lab.local:/usr/obj/usr/src/sys/GENERIC amd64 03.04.2012, 18:26, "Mike Tancsa" : > Hi, > ššššššššTry the driver from HEAD. It has a number of fixes in it to both the > igb and em drivers that is not yet in RELENG_9 nor 8 > > http://lists.freebsd.org/pipermail/svn-src-head/2012-March/035888.html > > šššššššš---Mike > > On 4/3/2012 10:19 AM, Darren Baginski wrote: > >> šStill getting same errors on >> ššFreeBSD srv-4-2.lab.local 9.0-STABLE FreeBSD 9.0-STABLE #3: Mon Apr š2 >> š19:07:20 UTC 2012 >> šroot@srv-4-2.lab.local:/usr/obj/usr/src/sys/GENERIC šamd64 >> šIt's only me or it's known problem ? >> >> š22.02.2012, 23:46, "Jack Vogel" : >>> šMike is correct, 8.3 was looming, it is important to a lot of my >>> šcustomers so it >>> šhas taken priority, 9 stable will be coming... >>> >>> šJack >>> >>> šOn Wed, Feb 22, 2012 at 10:55 AM, Mike Tancsa >> š> wrote: >>> >>> šššššI dont think the driver changes from HEAD were ever MFC'd to 9.x. >>> ššššššOnly >>> šššššto 8.x >>> >>> šššššššššššš---Mike >>> >>> šššššOn 2/22/2012 1:23 PM, Darren Baginski wrote: >>>> šSame problem on >>>> šFreeBSD srv-4-2.lab.local 9.0-STABLE FreeBSD 9.0-STABLE #2: Wed >>> šššššFeb 22 18:10:53 UTC 2012 ššššroot@srv-4-2.lab.local >>> ššššš:/usr/obj/usr/src/sys/GENERIC šamd64 >>>> š16.02.2012, 02:27, "Jack Vogel" >> ššššš>: >>>>> šAnd assuming its from the release, please upgrade it to HEAD >>> šššššand try again. >>>>> šJack >>>>> >>>>> šOn Wed, Feb 15, 2012 at 2:14 PM, Adrian Chadd >>> ššššš> wrote: >>>>>> šare you running the driver from that release, or the -HEAD driver? >>>>>> >>>>>> šadrian >>>>>> š_______________________________________________ >>>>>> š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 >>> ššššš" >>>> š_______________________________________________ >>>> š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 >>> ššššš" >>> >>> ššššš-- >>> ššššš------------------- >>> šššššMike Tancsa, tel +1 519 651 3400 >>> šššššSentex Communications, mike@sentex.net >>> šššššProviding Internet services since 1994 www.sentex.net >>> ššššš >>> šššššCambridge, Ontario Canada ššhttp://www.tancsa.com/ > -- > ------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet services since 1994 www.sentex.net > Cambridge, Ontario Canada ššhttp://www.tancsa.com/ From owner-freebsd-net@FreeBSD.ORG Tue Apr 3 17:17:15 2012 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 5F6291065673 for ; Tue, 3 Apr 2012 17:17:15 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id BE24E8FC0A for ; Tue, 3 Apr 2012 17:17:14 +0000 (UTC) Received: (qmail 26906 invoked from network); 3 Apr 2012 17:15:29 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 3 Apr 2012 17:15:29 -0000 Message-ID: <4F7B3098.3090901@freebsd.org> Date: Tue, 03 Apr 2012 19:17:12 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: darrenr@freebsd.org References: <4F75C1A3.4030401@freebsd.org> <4F75D9ED.7080707@freebsd.org> <4F780373.6030107@freebsd.org> <4F7AFEEF.60708@freebsd.org> <4F7B1981.1050009@freebsd.org> In-Reply-To: <4F7B1981.1050009@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD TCP ignores zero window size 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, 03 Apr 2012 17:17:15 -0000 On 03.04.2012 17:38, Darren Reed wrote: > On 3/04/2012 11:45 PM, Andre Oppermann wrote: >> It's the other way around. remote.ssh is sending old data >> which freebsd82.62922 has already ack'ed. The sessions seems >> to be de-synchronized, perhaps some middle box mucking with >> the segments trying to modulate something? > > I suspect that the ISP is dropping packets and/or applying > some other means of throttling the connection. So, yes. That doesn't explain it. The other side is retransmitting data we have already received and acknowledged! There is not nothing we can do on our side. That behavior is totally non-compliant. The zero-window is not involved in this as it would affect FreeBSD sending data, not the other end sending data. Can you try to find out what kind of middle-box is mucking TCP here on your side and the other side? It must be some device that actively touches the TCP session transiting through it. A router with active queue management (like WFQ or RED) is not enough to cause this behavior. What is the OS of your remote.ssh? -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Apr 3 17:29:53 2012 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 61D851065672 for ; Tue, 3 Apr 2012 17:29:53 +0000 (UTC) (envelope-from rsb@berentweb.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id C61208FC12 for ; Tue, 3 Apr 2012 17:29:52 +0000 (UTC) Received: by lagv3 with SMTP id v3so6838690lag.13 for ; Tue, 03 Apr 2012 10:29:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=berentweb.com; s=google; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=tlWpxCgrgfKGo54DYhUaV4n3/ZIA4oXJR0mwDQXetEg=; b=YgtW3wjakJYdugrXNN44V35Stlgk0ag3cOm6fh8iUWCBKPkTNs0uhNwJ5uVPxzBs7e Y2BreUrDM7EYNG/I0nOcFYwCWVprIdnmoJazYMB2xydwYnv+zOYhcDnFC0WRh+X3onJI jKmTaA12bdsPOIsS05nWAireIQ5Cogcwb7Vj0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :x-gm-message-state; bh=tlWpxCgrgfKGo54DYhUaV4n3/ZIA4oXJR0mwDQXetEg=; b=WWVzBFkcmJG0MUhVVLtl+vik7VqUo5tt4jINlm1W8sSuTRa+49iwUS3/O58DTtuGSZ x+6ZjkQUvllFRpbIVXle0GMQUgNoMyubWcWQ/YRyN8xUQmCCccxz+soWBICOz6Jds7OU Mm6FDpBP+4iSn9eL43YGYibmdpKVSj0boXdqftX+yikQ3yste1PMEy6ucATOpcdpZLgS xNOsg/wJbHQ48wZRycwDCFOgIILAQsw/PBaHc5IsisN+yZQCNqANcdjDD5de8oVYXn/Q jTBTNYptAssluLAc5T0NRXnNcC6LpIlxnrsjUdQMVmsb/2D926e6cPhylX/RV5Z+RUD/ ReUw== MIME-Version: 1.0 Received: by 10.152.132.166 with SMTP id ov6mr6251898lab.35.1333474191591; Tue, 03 Apr 2012 10:29:51 -0700 (PDT) Sender: rsb@berentweb.com Received: by 10.112.77.15 with HTTP; Tue, 3 Apr 2012 10:29:51 -0700 (PDT) X-Originating-IP: [85.110.92.106] In-Reply-To: References: <20120329072054.GA45082@server.vk2pj.dyndns.org> <20120403074954.GA19241@server.vk2pj.dyndns.org> Date: Tue, 3 Apr 2012 20:29:51 +0300 X-Google-Sender-Auth: 0QevLboP9REi4hYcgoxS-_Wy_HE Message-ID: From: Beeblebrox To: freebsd-net@freebsd.org X-Gm-Message-State: ALoCoQnT6/ZG/2pMpEb+ZSTg9YTZk2NGddVF6MzyqaR35dm2Tw6xUqsnlZzVX00J04LPZAYrknls Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: lagg problems on diskless 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, 03 Apr 2012 17:29:53 -0000 On Tue, Apr 3, 2012 at 7:46 PM, Kevin Oberman wrote: > On Tue, Apr 3, 2012 at 4:51 AM, Beeblebrox wrote: > > Slightly different point of view: Under this scenario of dikless clients > > having dual NICs would CRAP be a choice to consider? From what I have > read > Typo or editorial comment^^^^^^ -) > > it can offer loadbalancing but as I understand it's not really applicable > > to diskless node situations? > -- > R. Kevin Oberman, Network Engineer > E-mail: kob6558@gmail.com > That's hilarious. It's a typo. Correction C-A-R-P. From owner-freebsd-net@FreeBSD.ORG Tue Apr 3 20:00:49 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BAA151065674 for ; Tue, 3 Apr 2012 20:00:49 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from fallbackmx07.syd.optusnet.com.au (fallbackmx07.syd.optusnet.com.au [211.29.132.9]) by mx1.freebsd.org (Postfix) with ESMTP id CFEFC8FC08 for ; Tue, 3 Apr 2012 20:00:48 +0000 (UTC) Received: from mail14.syd.optusnet.com.au (mail14.syd.optusnet.com.au [211.29.132.195]) by fallbackmx07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q33K0fan002721 for ; Wed, 4 Apr 2012 06:00:41 +1000 Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail14.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q33K0UlH023169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Apr 2012 06:00:31 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.5/8.14.4) with ESMTP id q33K0T4G024087; Wed, 4 Apr 2012 06:00:29 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.5/8.14.5/Submit) id q33K0SDR024086; Wed, 4 Apr 2012 06:00:28 +1000 (EST) (envelope-from peter) Date: Wed, 4 Apr 2012 06:00:27 +1000 From: Peter Jeremy To: Beeblebrox Message-ID: <20120403200027.GC25776@server.vk2pj.dyndns.org> References: <20120329072054.GA45082@server.vk2pj.dyndns.org> <20120403074954.GA19241@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cvVnyQ+4j833TQvp" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@freebsd.org Subject: Re: lagg problems on diskless 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, 03 Apr 2012 20:00:49 -0000 --cvVnyQ+4j833TQvp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-Apr-03 14:51:57 +0300, Beeblebrox wrote: >Slightly different point of view: Under this scenario of dikless clients >having dual NICs would CRAP be a choice to consider? From what I have read >it can offer loadbalancing but as I understand it's not really applicable >to diskless node situations? (Two amusing typos in one sentence). Based on what you've said so far, no. carp provides load-balancing or failover between two (or more) hosts. lagg provides load-balancing or failover between two (or more) NICs on one host. --=20 Peter Jeremy --cvVnyQ+4j833TQvp Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk97VtsACgkQ/opHv/APuIfcNgCfQJN4tK6O0u9V7nfm8/TpcwXJ BVcAn3bQggX1LdplbQ8Jze73nFdl1Hw0 =Kn2r -----END PGP SIGNATURE----- --cvVnyQ+4j833TQvp-- From owner-freebsd-net@FreeBSD.ORG Tue Apr 3 20:07:27 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 93E60106564A for ; Tue, 3 Apr 2012 20:07:27 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail35.syd.optusnet.com.au (mail35.syd.optusnet.com.au [211.29.133.51]) by mx1.freebsd.org (Postfix) with ESMTP id CD7198FC12 for ; Tue, 3 Apr 2012 20:07:26 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail35.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q33K7Gdr007081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Apr 2012 06:07:17 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.5/8.14.4) with ESMTP id q33K7GDn024790; Wed, 4 Apr 2012 06:07:16 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.5/8.14.5/Submit) id q33K7Gn7024789; Wed, 4 Apr 2012 06:07:16 +1000 (EST) (envelope-from peter) Date: Wed, 4 Apr 2012 06:07:16 +1000 From: Peter Jeremy To: Beeblebrox Message-ID: <20120403200715.GD25776@server.vk2pj.dyndns.org> References: <20120329072054.GA45082@server.vk2pj.dyndns.org> <20120403074954.GA19241@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0vzXIDBeUiKkjNJl" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@freebsd.org Subject: Re: lagg problems on diskless 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, 03 Apr 2012 20:07:27 -0000 --0vzXIDBeUiKkjNJl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-Apr-03 13:17:50 +0300, Beeblebrox wrote: >> Please don't top post. >Wasn't aware I was doing that. This is better I hope? Yes but there's no need to quote the entire mail you're replying to. >> Are you sure you installed /etc/rc.d/lagg or an equivalent script? >I had not noticed the link to the script at the bottom - I placed script in >DC's private conf//etc/rc.d then booted the DC. I got system freeze and >1 message: >ifconfig: interface re0 cannot change link address! >looking through the script I found the problem: lagg_tmp:=3D/mnt. My DC /r= oot >is *ro* so I'll have to change it to another tmp. Actually, it doesn't matter that the root is RO, just that /mnt exists so it can be used as a mountpoint. And, BTW, I've just noticed that, whilst $lagg_tmp is parameterised. /mnt is also hard-coded in several places in the script. Sorry about that. > Considering that my /var >and /etc are md-mounted, using either seems out of the question. I also >have /tmp mounted as tmpfs. Can I mkdir -p /tmp/lagg and mount lagg_tmp >there or does it have to be an NFS shared location - what do you suggest? AFAIR, I use a separate ramdisk because /etc/rc.d/lagg runs very early and other mountpoints cannot be relied on. --=20 Peter Jeremy --0vzXIDBeUiKkjNJl Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk97WHMACgkQ/opHv/APuIdceQCeMk0ZPTxNBiEVQPDclKKagc1o JfoAoJ/Og6oFAMkqz7E0PG4W1VyYeYxw =GFs4 -----END PGP SIGNATURE----- --0vzXIDBeUiKkjNJl-- From owner-freebsd-net@FreeBSD.ORG Tue Apr 3 22:09:01 2012 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 E6A671065670 for ; Tue, 3 Apr 2012 22:09:01 +0000 (UTC) (envelope-from darrenr@freebsd.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id AF59F8FC1A for ; Tue, 3 Apr 2012 22:09:01 +0000 (UTC) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 7A4A1211B2 for ; Tue, 3 Apr 2012 18:09:00 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute1.internal (MEProxy); Tue, 03 Apr 2012 18:09:00 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:reply-to :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=pXZKzZFuKhN6Jyv8LhJuTR 5zVwg=; b=Qn5dArifNCM66lMf9+558WH5JBReXnQ8C2CjC+t/4LI3haB64fBp80 sRj6a3jVQlJAw/0jj/0TW8LPlIWX+RJQY9tzmv+QS+iQkWpyiIPu0ixBlA4LfmUL kYC7zjPZ2tDEcE/GHh8oXtybpwtaQFt8osoWUc1pof/UVP1sXWdjY= X-Sasl-enc: 5A02SplajRVs74RYaQwyEWlUvnI6TpM/H4SAOMCB8Dlg 1333490940 Received: from [192.168.1.124] (dsl-202-45-110-141-static.VIC.netspace.net.au [202.45.110.141]) by mail.messagingengine.com (Postfix) with ESMTPSA id 79D704825B3; Tue, 3 Apr 2012 18:08:59 -0400 (EDT) Message-ID: <4F7B74F8.9080600@freebsd.org> Date: Wed, 04 Apr 2012 08:08:56 +1000 From: Darren Reed Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-AU; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: Andre Oppermann References: <4F75C1A3.4030401@freebsd.org> <4F75D9ED.7080707@freebsd.org> <4F780373.6030107@freebsd.org> <4F7AFEEF.60708@freebsd.org> <4F7B1981.1050009@freebsd.org> <4F7B3098.3090901@freebsd.org> In-Reply-To: <4F7B3098.3090901@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD TCP ignores zero window size X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: darrenr@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 22:09:02 -0000 On 4/04/2012 3:17 AM, Andre Oppermann wrote: > On 03.04.2012 17:38, Darren Reed wrote: >> On 3/04/2012 11:45 PM, Andre Oppermann wrote: >>> It's the other way around. remote.ssh is sending old data >>> which freebsd82.62922 has already ack'ed. The sessions seems >>> to be de-synchronized, perhaps some middle box mucking with >>> the segments trying to modulate something? >> >> I suspect that the ISP is dropping packets and/or applying >> some other means of throttling the connection. So, yes. > > That doesn't explain it. The other side is retransmitting data > we have already received and acknowledged! There is not > nothing we can do on our side. That behavior is totally > non-compliant. > > The zero-window is not involved in this as it would affect > FreeBSD sending data, not the other end sending data. > > Can you try to find out what kind of middle-box is mucking > TCP here on your side and the other side? It must be some > device that actively touches the TCP session transiting > through it. A router with active queue management (like WFQ > or RED) is not enough to cause this behavior. > > What is the OS of your remote.ssh? NetBSD. So its TCP behaviour is going to be a lot like FreeBSD's. Darren From owner-freebsd-net@FreeBSD.ORG Tue Apr 3 22:18:28 2012 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 2AE5D106566B for ; Tue, 3 Apr 2012 22:18:28 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id A85FB8FC12 for ; Tue, 3 Apr 2012 22:18:27 +0000 (UTC) Received: by wibhq7 with SMTP id hq7so152701wib.13 for ; Tue, 03 Apr 2012 15:18:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=8VOjhc1CqhKHEDR9Vp8t5h6OmUUnGZNxwDjBNyMRxZ8=; b=xDKChSXOeQK60b1cqQF7ohHJ1HUv+H7EkzoxKL7e96JMOni3/WzfGL/2eeMXmYQzPg At8Fx/a3IBipG9f6+qF72OVm2O6w8mPLiVccOmiAgKbbIctp3nXIgIUCwnMEAD/w2tXY oya96aj5JHTJ2Dmx8wOVwskwk3yMpgS/C00IGPO7/87ZV+9kCkeRXIno/LGRfXtik+o3 RM7/LO3QczuRLK8J3Wv9lanLuMjwCrZ9J7VnTxHQUgZLmf+LDDn95g5geP3TY7BVxc6Z X4C9jnqaTbXT4if+wrE91Uz515QpWFGbphSK7vdQYYVTyR+LfrcHp2jSBjtNN/C5FP+e Am/g== MIME-Version: 1.0 Received: by 10.180.92.71 with SMTP id ck7mr40612792wib.21.1333491506624; Tue, 03 Apr 2012 15:18:26 -0700 (PDT) Received: by 10.223.54.207 with HTTP; Tue, 3 Apr 2012 15:18:26 -0700 (PDT) In-Reply-To: References: <20120329072054.GA45082@server.vk2pj.dyndns.org> <20120403074954.GA19241@server.vk2pj.dyndns.org> Date: Tue, 3 Apr 2012 15:18:26 -0700 Message-ID: From: Kevin Oberman To: Beeblebrox Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: lagg problems on diskless 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, 03 Apr 2012 22:18:28 -0000 Does a 'dikless' server run eunichs? Sorry. I really should resist this kind of carp. Almost as bad as back when I sent a note to a customer about a requirement to adjust our 'peeing' policy. (And the spell checker won't catch that one.) On Tue, Apr 3, 2012 at 10:29 AM, Beeblebrox wrote: > On Tue, Apr 3, 2012 at 7:46 PM, Kevin Oberman wrote: > >> On Tue, Apr 3, 2012 at 4:51 AM, Beeblebrox wrote: >> > Slightly different point of view: Under this scenario of dikless clien= ts >> > having dual NICs would CRAP be a choice to consider? From what I have >> read >> Typo or editorial comment^^^^^^ =A0-) >> > it can offer loadbalancing but as I understand it's not really applica= ble >> > to diskless node situations? >> -- >> R. Kevin Oberman, Network Engineer >> E-mail: kob6558@gmail.com >> > > That's hilarious. It's a typo. Correction C-A-R-P. > _______________________________________________ > 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 R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-net@FreeBSD.ORG Tue Apr 3 22:28:41 2012 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 C260D106564A for ; Tue, 3 Apr 2012 22:28:41 +0000 (UTC) (envelope-from darrenr@freebsd.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 8A3C88FC17 for ; Tue, 3 Apr 2012 22:28:41 +0000 (UTC) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id D05CB2130A for ; Tue, 3 Apr 2012 18:28:34 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute6.internal (MEProxy); Tue, 03 Apr 2012 18:28:34 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:reply-to :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=YwarzRfKkX5FWJaXNeYb6Y ajuNc=; b=CusjTXeEt302Kk1k28QvGEN4dlI85HJwwqxtjzbBo00HZkl4OCeyHd euq6UVDLDosgwlEl0u8BCjgitP9DNSxEYugro87F13wj4tCeKpelS+Yp7HPLGxrk VXPISuxh4HfKArzH8Xfz6aGkquUo6o1fFs4AvwX41U23T13C0ZPwY= X-Sasl-enc: VD4PBt9TE6llituzijb+318JWI7vbgWGTsHbVNPFAo1z 1333492114 Received: from [192.168.1.124] (dsl-202-45-110-141-static.VIC.netspace.net.au [202.45.110.141]) by mail.messagingengine.com (Postfix) with ESMTPSA id D592F4825B3; Tue, 3 Apr 2012 18:28:33 -0400 (EDT) Message-ID: <4F7B798F.3080203@freebsd.org> Date: Wed, 04 Apr 2012 08:28:31 +1000 From: Darren Reed Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-AU; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: Andre Oppermann References: <4F75C1A3.4030401@freebsd.org> <4F75D9ED.7080707@freebsd.org> <4F780373.6030107@freebsd.org> <4F7AFEEF.60708@freebsd.org> <4F7B1981.1050009@freebsd.org> <4F7B3098.3090901@freebsd.org> In-Reply-To: <4F7B3098.3090901@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD TCP ignores zero window size X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: darrenr@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 22:28:41 -0000 On 4/04/2012 3:17 AM, Andre Oppermann wrote: > On 03.04.2012 17:38, Darren Reed wrote: >> On 3/04/2012 11:45 PM, Andre Oppermann wrote: >>> It's the other way around. remote.ssh is sending old data >>> which freebsd82.62922 has already ack'ed. The sessions seems >>> to be de-synchronized, perhaps some middle box mucking with >>> the segments trying to modulate something? >> >> I suspect that the ISP is dropping packets and/or applying >> some other means of throttling the connection. So, yes. > > That doesn't explain it. The other side is retransmitting data > we have already received and acknowledged! There is not > nothing we can do on our side. That behavior is totally > non-compliant. > > The zero-window is not involved in this as it would affect > FreeBSD sending data, not the other end sending data. > > Can you try to find out what kind of middle-box is mucking > TCP here on your side and the other side? It must be some > device that actively touches the TCP session transiting > through it. A router with active queue management (like WFQ > or RED) is not enough to cause this behavior. > > What is the OS of your remote.ssh? I should add that given the other end of this is NetBSD I have also been following up discussion of this behaviour on their appropriate list too. That discussion can be found here: http://mail-index.netbsd.org/tech-net/2012/04/01/msg003203.html The currently last installment of which is here: http://mail-index.netbsd.org/tech-net/2012/04/03/msg003216.html Darren From owner-freebsd-net@FreeBSD.ORG Tue Apr 3 22:59:30 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 55CB21065672 for ; Tue, 3 Apr 2012 22:59:30 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id AC33F8FC19 for ; Tue, 3 Apr 2012 22:59:29 +0000 (UTC) Received: (qmail 28368 invoked from network); 3 Apr 2012 22:57:41 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 3 Apr 2012 22:57:41 -0000 Message-ID: <4F7B80CE.90805@freebsd.org> Date: Wed, 04 Apr 2012 00:59:26 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: darrenr@freebsd.org References: <4F75C1A3.4030401@freebsd.org> <4F75D9ED.7080707@freebsd.org> <4F780373.6030107@freebsd.org> <4F7AFEEF.60708@freebsd.org> <4F7B1981.1050009@freebsd.org> In-Reply-To: <4F7B1981.1050009@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD TCP ignores zero window size 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, 03 Apr 2012 22:59:30 -0000 On 03.04.2012 17:38, Darren Reed wrote: > On 3/04/2012 11:45 PM, Andre Oppermann wrote: >> On 01.04.2012 09:27, Darren Reed wrote: >>> The problem here is that it only tracks the window size as >>> it grows, not as it shrinks. Thus the remote end setting its >>> window size to 0 is ignored. >> >> My patch is wrong as the acked count is already integrated >> by the time we reach this spot. I'm working on a better >> implementation. > > Ok, I'll look forward to seeing and testing it. Please test this patch: http://people.freebsd.org/~andre/tcp_input.c-windowupdate-2012040.diff I just completed a number of tests and inspected the debug output as well as the corresponding tcpdumps. In all could simulate it behaved correctly now with regard to tracking the window and updates. -- Andre From owner-freebsd-net@FreeBSD.ORG Wed Apr 4 01:57:38 2012 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 10EA0106566C for ; Wed, 4 Apr 2012 01:57:38 +0000 (UTC) (envelope-from darernr@freebsd.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id CF1EA8FC0A for ; Wed, 4 Apr 2012 01:57:37 +0000 (UTC) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 53C0021322 for ; Tue, 3 Apr 2012 21:57:37 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute1.internal (MEProxy); Tue, 03 Apr 2012 21:57:37 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=ZVr1Aig+39cQBD0qx1DJBh cCjZg=; b=MTmpcSHg2geTChC7tdwc1zGf9J6R6g3sMVICUi46RiOHNS9xZBLjWQ PUM15ZH6LfhzM4mdyyETTysT+hnBfiEwsl3ilmZdlzQ76yzX7SAMW0dHcB2wA2wg CmuvUsIL0BXBMWz9Yx+qED01rX2BqMIHLeyhq8a99XY3ed4Ygd220= X-Sasl-enc: V4uIq1r2HPsY4hIzGmQttKxmAbacQYd9w7LjALPfpJva 1333504656 Received: from [192.168.1.23] (dsl-202-45-110-141-static.VIC.netspace.net.au [202.45.110.141]) by mail.messagingengine.com (Postfix) with ESMTPSA id 47EB74825E0; Tue, 3 Apr 2012 21:57:35 -0400 (EDT) Message-ID: <4F7BB8AD.2090307@freebsd.org> Date: Wed, 04 Apr 2012 12:57:49 +1000 From: Darren Reed User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Andre Oppermann References: <4F75C1A3.4030401@freebsd.org> <4F75D9ED.7080707@freebsd.org> <4F780373.6030107@freebsd.org> <4F7AFEEF.60708@freebsd.org> <4F7B1981.1050009@freebsd.org> <4F7B80CE.90805@freebsd.org> In-Reply-To: <4F7B80CE.90805@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD TCP ignores zero window size 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, 04 Apr 2012 01:57:38 -0000 Andre Oppermann wrote: > On 03.04.2012 17:38, Darren Reed wrote: >> On 3/04/2012 11:45 PM, Andre Oppermann wrote: >>> On 01.04.2012 09:27, Darren Reed wrote: >>>> The problem here is that it only tracks the window size as >>>> it grows, not as it shrinks. Thus the remote end setting its >>>> window size to 0 is ignored. >>> >>> My patch is wrong as the acked count is already integrated >>> by the time we reach this spot. I'm working on a better >>> implementation. >> >> Ok, I'll look forward to seeing and testing it. > > Please test this patch: > http://people.freebsd.org/~andre/tcp_input.c-windowupdate-2012040.diff > > I just completed a number of tests and inspected the debug output as > well as the corresponding tcpdumps. In all could simulate it behaved > correctly now with regard to tracking the window and updates. As luck would have it, attempts to reproduce the problem today have failed. I suspect this is because the server at the other end is under less load than it has been in the recent past. I'll keep the patch applied and try it again in the future when I suspect that condition may arise again. Thanks, Darren From owner-freebsd-net@FreeBSD.ORG Wed Apr 4 04:37:34 2012 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 DD6001065670 for ; Wed, 4 Apr 2012 04:37:34 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 852698FC12 for ; Wed, 4 Apr 2012 04:37:34 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SFHyJ-0003uw-LI for freebsd-net@freebsd.org; Wed, 04 Apr 2012 06:37:27 +0200 Received: from pool-108-35-132-213.nwrknj.fios.verizon.net ([108.35.132.213]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 04 Apr 2012 06:37:27 +0200 Received: from ixew by pool-108-35-132-213.nwrknj.fios.verizon.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 04 Apr 2012 06:37:27 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: enoch Date: Wed, 04 Apr 2012 00:37:15 -0400 Lines: 131 Message-ID: <87sjgk5czo.fsf@hotmail.com> References: <20120330233819.GC7325@michelle.cdnetworks.com> <4F75C5EC.6090303@hotmail.com> <20120402195215.GA3571@michelle.cdnetworks.com> <20120403023225.GD3571@michelle.cdnetworks.com> <87ty11670b.fsf@hotmail.com> <20120403183521.GA7380@michelle.cdnetworks.com> <87obr95pxh.fsf@hotmail.com> <20120403225422.GB7380@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: pool-108-35-132-213.nwrknj.fios.verizon.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.93 (berkeley-unix) Cancel-Lock: sha1:oYH7XLf+ToPzg74ebYZNvfi6AxA= Subject: Re: [nfe] DHCP failure on 8-stable 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, 04 Apr 2012 04:37:34 -0000 YongHyeon PYUN writes: > On Tue, Apr 03, 2012 at 01:45:30AM -0400, enoch wrote: >> YongHyeon PYUN writes: >> >> > On Mon, Apr 02, 2012 at 07:36:36PM -0400, enoch wrote: >> >> YongHyeon PYUN writes: >> >> >> >> > On Mon, Apr 02, 2012 at 03:50:02AM -0400, enoch wrote: >> >> >> On 04/02/2012 03:52 PM, YongHyeon PYUN wrote: >> >> >> > On Fri, Mar 30, 2012 at 10:40:44AM -0400, enoch wrote: >> >> >> >> On 03/30/2012 19:38, YongHyeon PYUN wrote: >> >> >> >>> On Fri, Mar 30, 2012 at 03:01:52AM -0400, enoch wrote: >> >> >> >>>> Recently it became extremely difficult to pass the DHCP discovery step >> >> >> >>>> on boot. Now I am using the buggy [nve] instead. >> >> >> >>>> >> >> >> >>>> Can anyone help? >> >> >> >>>> >> >> >> >>> >> >> >> >>> Did you set synchronous_dhclient option in rc.conf? >> >> >> >>> >> >> >> >> >> >> >> >> Yes: ifconfig_nfe0="SYNCDHCP" >> >> >> >> >> >> >> >> I guess [nfe] is undergoing gradual devel changes of some sort as before >> >> >> >> it had some chance of reporting "empty headers" on initial ifconfig and >> >> >> >> refusing to work. Sorry, I should have reported when encountering the >> >> >> >> first problems rather than solve by reboot. >> >> >> > >> >> >> > Would you show me the output of both dmesg(nfe(4) and its PHY only) >> >> >> > and 'sysctl dev.nfe.0.stats'? >> >> >> > It would be also helpful to know whether nfe(4) still sees >> >> >> > incoming traffic. >> >> >> > Does assigning static IP work? >> >> >> > >> >> >> >> >> >> Static IP direct communication attempt from this desktop to another >> >> >> laptop through a crossover cable fails as follows. Thanks. >> >> >> >> >> >> nfe0: flags=8843 metric 0 mtu 1500 >> >> >> options=82008 >> >> >> ether 00:1f:bc:00:19:dc >> >> >> inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 >> >> >> media: Ethernet autoselect (1000baseT >> >> >> ) >> >> >> status: active >> >> >> >> >> >> nfe0: link state changed to UP >> >> >> nfe0: port 0xf200-0xf207 >> >> >> mem 0xefffb000-0xefffbfff irq 21 at device 20.0 on pci0 >> >> >> miibus1: on nfe0 >> >> > >> >> > It seems you've omitted PHY driver here. What PHY driver was >> >> > attached to nfe(4)? >> >> > >> >> >> >> miibus1: on nfe0 >> >> rgephy1: PHY 1 on miibus1 >> >> >> >> >> nfe0: Ethernet address: 00:1f:bc:00:19:dc >> >> >> nfe0: [FILTER] >> >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) >> >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) >> >> >> nfe0: link state changed to UP >> >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) >> >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) >> >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) >> >> >> >> >> >> dev.nfe.0.stats.rx.frame_errors: 0 >> >> >> dev.nfe.0.stats.rx.extra_bytes: 0 >> >> >> dev.nfe.0.stats.rx.late_cols: 0 >> >> >> dev.nfe.0.stats.rx.runts: 0 >> >> >> dev.nfe.0.stats.rx.jumbos: 0 >> >> >> dev.nfe.0.stats.rx.fifo_overuns: 0 >> >> >> dev.nfe.0.stats.rx.crc_errors: 0 >> >> >> dev.nfe.0.stats.rx.fae: 0 >> >> >> dev.nfe.0.stats.rx.len_errors: 0 >> >> >> dev.nfe.0.stats.rx.unicast: 56 >> >> >> dev.nfe.0.stats.rx.multicast: 0 >> >> >> dev.nfe.0.stats.rx.broadcast: 280 >> >> >> dev.nfe.0.stats.tx.octets: 7517 >> >> >> dev.nfe.0.stats.tx.zero_rexmits: 51 >> >> >> dev.nfe.0.stats.tx.one_rexmits: 0 >> >> >> dev.nfe.0.stats.tx.multi_rexmits: 0 >> >> >> dev.nfe.0.stats.tx.late_cols: 0 >> >> >> dev.nfe.0.stats.tx.fifo_underuns: 0 >> >> >> dev.nfe.0.stats.tx.carrier_losts: 0 >> >> >> dev.nfe.0.stats.tx.excess_deferrals: 0 >> >> >> dev.nfe.0.stats.tx.retry_errors: 0 >> >> >> >> >> > >> >> > Thanks. Would you show me the output of "pciconf -lcbv"? >> >> > >> >> >> >> nfe0@pci0:0:20:0: class=0x068000 card=0x10003842 chip=0x026910de rev=0xa3 hdr=0x00 >> >> vendor = 'NVIDIA Corporation' >> >> device = 'MCP51 Network Bus Enumerator' >> >> class = bridge >> >> bar [10] = type Memory, range 32, base 0xefffb000, size 4096, enabled >> >> bar [14] = type I/O Port, range 32, base 0xf200, size 8, enabled >> >> cap 01[44] = powerspec 2 supports D0 D1 D2 D3 current D0 >> >> >> >> Interestingly, now that nfe0 is using a static IP it sometimes boots >> >> up properly. Are you interested in its good working? >> > >> > Yes I am. Would you try attached patch and let me know whether the >> > patch makes any difference on your box? >> >> Sorry to report: The patch was applied (to 8-stable latest code) but out >> of 3 boots only one succeeded. Same stream of "nfe0: discard frame w/o >> leading ethernet header (len 0 pkt len 0)" messages. > > Ok, back out previous patch and try attached one. With these two patch files applied to the 8-stable code, buildkernel fails as follows. /usr/src/sys/modules/nfe/../../dev/nfe/if_nfe.c: In function 'nfe_attach': /usr/src/sys/modules/nfe/../../dev/nfe/if_nfe.c:629: error: 'struct mii_softc' has no member named 'mii_mpd_oui' /usr/src/sys/modules/nfe/../../dev/nfe/if_nfe.c:629: error: 'struct mii_softc' has no member named 'mii_mpd_oui' /usr/src/sys/modules/nfe/../../dev/nfe/if_nfe.c:630: error: 'struct mii_softc' has no member named 'mii_mpd_model' *** Error code 1 Sorry, I can't handle 9-stable. Enoch. > > _______________________________________________ > 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 Apr 4 05:05:00 2012 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 5D6D4106566B for ; Wed, 4 Apr 2012 05:05:00 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 23D468FC16 for ; Wed, 4 Apr 2012 05:05:00 +0000 (UTC) Received: by pbcwz17 with SMTP id wz17so614258pbc.13 for ; Tue, 03 Apr 2012 22:04:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=liWZKWsx4cWsR5hlk6lCfqv2OUWl1NOgcArEDIN1oaY=; b=RY+HsVeLAs/sBXsH/CWUdMAV+XYy7+nUjkvEuyVT+Fgl9SsBKug1RGJk83YgW1yzHJ JfeRkPyH3U+AjfUXoufAx/PfSwvrRPeB5PNCsRgroCkHg3I0hL9ujIgBw+0oY4sagNVY pn61hFCTeWA+4GcQOxHsx6SzxCa91Cu7nXJB8RUR55evkJPfeWKPAHpzjb2Vdz2/IgSB 1DXjKUmEY6T+rYB2tg0Fo0juxCw5vYxEJXgML4lCHptz+jIV8eLjcTgpbgTSQ5QoFakR yiCKRIpgvIbMvr8/zRLIj4E2HGrmgJZefS0TxnaMSR1u+aWw1faJb0pGqx9M/Iv7EGz7 OJTw== Received: by 10.68.130.67 with SMTP id oc3mr33775058pbb.149.1333515893987; Tue, 03 Apr 2012 22:04:53 -0700 (PDT) Received: from pyunyh@gmail.com ([114.111.62.249]) by mx.google.com with ESMTPS id r6sm17805290pbl.24.2012.04.03.22.04.51 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 Apr 2012 22:04:53 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 04 Apr 2012 14:04:45 -0700 From: YongHyeon PYUN Date: Wed, 4 Apr 2012 14:04:45 -0700 To: enoch Message-ID: <20120404210445.GB10911@michelle.cdnetworks.com> References: <20120330233819.GC7325@michelle.cdnetworks.com> <4F75C5EC.6090303@hotmail.com> <20120402195215.GA3571@michelle.cdnetworks.com> <20120403023225.GD3571@michelle.cdnetworks.com> <87ty11670b.fsf@hotmail.com> <20120403183521.GA7380@michelle.cdnetworks.com> <87obr95pxh.fsf@hotmail.com> <20120403225422.GB7380@michelle.cdnetworks.com> <87sjgk5czo.fsf@hotmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="AqsLC8rIMeq19msA" Content-Disposition: inline In-Reply-To: <87sjgk5czo.fsf@hotmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: [nfe] DHCP failure on 8-stable 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: Wed, 04 Apr 2012 05:05:00 -0000 --AqsLC8rIMeq19msA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Apr 04, 2012 at 12:37:15AM -0400, enoch wrote: > YongHyeon PYUN writes: > > > On Tue, Apr 03, 2012 at 01:45:30AM -0400, enoch wrote: > >> YongHyeon PYUN writes: > >> > >> > On Mon, Apr 02, 2012 at 07:36:36PM -0400, enoch wrote: > >> >> YongHyeon PYUN writes: > >> >> > >> >> > On Mon, Apr 02, 2012 at 03:50:02AM -0400, enoch wrote: > >> >> >> On 04/02/2012 03:52 PM, YongHyeon PYUN wrote: > >> >> >> > On Fri, Mar 30, 2012 at 10:40:44AM -0400, enoch wrote: > >> >> >> >> On 03/30/2012 19:38, YongHyeon PYUN wrote: > >> >> >> >>> On Fri, Mar 30, 2012 at 03:01:52AM -0400, enoch wrote: > >> >> >> >>>> Recently it became extremely difficult to pass the DHCP discovery step > >> >> >> >>>> on boot. Now I am using the buggy [nve] instead. > >> >> >> >>>> > >> >> >> >>>> Can anyone help? > >> >> >> >>>> > >> >> >> >>> > >> >> >> >>> Did you set synchronous_dhclient option in rc.conf? > >> >> >> >>> > >> >> >> >> > >> >> >> >> Yes: ifconfig_nfe0="SYNCDHCP" > >> >> >> >> > >> >> >> >> I guess [nfe] is undergoing gradual devel changes of some sort as before > >> >> >> >> it had some chance of reporting "empty headers" on initial ifconfig and > >> >> >> >> refusing to work. Sorry, I should have reported when encountering the > >> >> >> >> first problems rather than solve by reboot. > >> >> >> > > >> >> >> > Would you show me the output of both dmesg(nfe(4) and its PHY only) > >> >> >> > and 'sysctl dev.nfe.0.stats'? > >> >> >> > It would be also helpful to know whether nfe(4) still sees > >> >> >> > incoming traffic. > >> >> >> > Does assigning static IP work? > >> >> >> > > >> >> >> > >> >> >> Static IP direct communication attempt from this desktop to another > >> >> >> laptop through a crossover cable fails as follows. Thanks. > >> >> >> > >> >> >> nfe0: flags=8843 metric 0 mtu 1500 > >> >> >> options=82008 > >> >> >> ether 00:1f:bc:00:19:dc > >> >> >> inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 > >> >> >> media: Ethernet autoselect (1000baseT > >> >> >> ) > >> >> >> status: active > >> >> >> > >> >> >> nfe0: link state changed to UP > >> >> >> nfe0: port 0xf200-0xf207 > >> >> >> mem 0xefffb000-0xefffbfff irq 21 at device 20.0 on pci0 > >> >> >> miibus1: on nfe0 > >> >> > > >> >> > It seems you've omitted PHY driver here. What PHY driver was > >> >> > attached to nfe(4)? > >> >> > > >> >> > >> >> miibus1: on nfe0 > >> >> rgephy1: PHY 1 on miibus1 > >> >> > >> >> >> nfe0: Ethernet address: 00:1f:bc:00:19:dc > >> >> >> nfe0: [FILTER] > >> >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) > >> >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) > >> >> >> nfe0: link state changed to UP > >> >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) > >> >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) > >> >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) > >> >> >> > >> >> >> dev.nfe.0.stats.rx.frame_errors: 0 > >> >> >> dev.nfe.0.stats.rx.extra_bytes: 0 > >> >> >> dev.nfe.0.stats.rx.late_cols: 0 > >> >> >> dev.nfe.0.stats.rx.runts: 0 > >> >> >> dev.nfe.0.stats.rx.jumbos: 0 > >> >> >> dev.nfe.0.stats.rx.fifo_overuns: 0 > >> >> >> dev.nfe.0.stats.rx.crc_errors: 0 > >> >> >> dev.nfe.0.stats.rx.fae: 0 > >> >> >> dev.nfe.0.stats.rx.len_errors: 0 > >> >> >> dev.nfe.0.stats.rx.unicast: 56 > >> >> >> dev.nfe.0.stats.rx.multicast: 0 > >> >> >> dev.nfe.0.stats.rx.broadcast: 280 > >> >> >> dev.nfe.0.stats.tx.octets: 7517 > >> >> >> dev.nfe.0.stats.tx.zero_rexmits: 51 > >> >> >> dev.nfe.0.stats.tx.one_rexmits: 0 > >> >> >> dev.nfe.0.stats.tx.multi_rexmits: 0 > >> >> >> dev.nfe.0.stats.tx.late_cols: 0 > >> >> >> dev.nfe.0.stats.tx.fifo_underuns: 0 > >> >> >> dev.nfe.0.stats.tx.carrier_losts: 0 > >> >> >> dev.nfe.0.stats.tx.excess_deferrals: 0 > >> >> >> dev.nfe.0.stats.tx.retry_errors: 0 > >> >> >> > >> >> > > >> >> > Thanks. Would you show me the output of "pciconf -lcbv"? > >> >> > > >> >> > >> >> nfe0@pci0:0:20:0: class=0x068000 card=0x10003842 chip=0x026910de rev=0xa3 hdr=0x00 > >> >> vendor = 'NVIDIA Corporation' > >> >> device = 'MCP51 Network Bus Enumerator' > >> >> class = bridge > >> >> bar [10] = type Memory, range 32, base 0xefffb000, size 4096, enabled > >> >> bar [14] = type I/O Port, range 32, base 0xf200, size 8, enabled > >> >> cap 01[44] = powerspec 2 supports D0 D1 D2 D3 current D0 > >> >> > >> >> Interestingly, now that nfe0 is using a static IP it sometimes boots > >> >> up properly. Are you interested in its good working? > >> > > >> > Yes I am. Would you try attached patch and let me know whether the > >> > patch makes any difference on your box? > >> > >> Sorry to report: The patch was applied (to 8-stable latest code) but out > >> of 3 boots only one succeeded. Same stream of "nfe0: discard frame w/o > >> leading ethernet header (len 0 pkt len 0)" messages. > > > > Ok, back out previous patch and try attached one. > > With these two patch files applied to the 8-stable code, buildkernel > fails as follows. > > /usr/src/sys/modules/nfe/../../dev/nfe/if_nfe.c: In function 'nfe_attach': > /usr/src/sys/modules/nfe/../../dev/nfe/if_nfe.c:629: error: 'struct mii_softc' has no member named 'mii_mpd_oui' > /usr/src/sys/modules/nfe/../../dev/nfe/if_nfe.c:629: error: 'struct mii_softc' has no member named 'mii_mpd_oui' > /usr/src/sys/modules/nfe/../../dev/nfe/if_nfe.c:630: error: 'struct mii_softc' has no member named 'mii_mpd_model' > *** Error code 1 > Oops, sorry I forgot that this part of change was not merged to stable/8. I've attached a minimal patch which would be cleanly applied to stable/8. > Sorry, I can't handle 9-stable. Enoch. --AqsLC8rIMeq19msA Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="nfe.power.diff3" Index: sys/dev/nfe/if_nfereg.h =================================================================== --- sys/dev/nfe/if_nfereg.h (revision 233822) +++ sys/dev/nfe/if_nfereg.h (working copy) @@ -188,8 +188,9 @@ #define NFE_PWR_VALID (1 << 8) #define NFE_PWR_WAKEUP (1 << 15) -#define NFE_PWR2_WAKEUP_MASK 0x0f11 +#define NFE_PWR2_WAKEUP_MASK 0x0f15 #define NFE_PWR2_REVA3 (1 << 0) +#define NFE_PWR2_PHY_RESET 0x0004 #define NFE_PWR2_GATE_CLOCKS 0x0f00 #define NFE_MEDIA_SET 0x10000 --AqsLC8rIMeq19msA-- From owner-freebsd-net@FreeBSD.ORG Wed Apr 4 05:24:12 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DB9C9106564A for ; Wed, 4 Apr 2012 05:24:12 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 93DC78FC0C for ; Wed, 4 Apr 2012 05:24:12 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id q345OAfQ001384 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 3 Apr 2012 22:24:12 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4F7BDB21.5000703@freebsd.org> Date: Tue, 03 Apr 2012 22:24:49 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: networking working group at devsummit 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, 04 Apr 2012 05:24:12 -0000 I made a sub-page for the working group at: http://wiki.freebsd.org/201205DevSummit/Networking (directly ripped off the virtualization sub-page) feel free to add ideas etc. there. (or 'register' if you are coming to the devsummit). From owner-freebsd-net@FreeBSD.ORG Wed Apr 4 08:21:56 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4AF151065672; Wed, 4 Apr 2012 08:21:56 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (unknown [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 2554C8FC17; Wed, 4 Apr 2012 08:21:56 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id q348Lt3c063260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 Apr 2012 01:21:55 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.14.2/Submit) with UUCP id q348LtMd063259; Wed, 4 Apr 2012 01:21:55 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: from fbsd81 ([192.168.200.81]) by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA26143; Wed, 4 Apr 12 01:04:31 PDT Date: Wed, 04 Apr 2012 08:03:35 -0700 From: perryh@pluto.rain.com To: andre@freebsd.org Message-Id: <4f7c62c7.MUlfd0e/uNQsAVZG%perryh@pluto.rain.com> References: <4F75C1A3.4030401@freebsd.org> <4F75D9ED.7080707@freebsd.org> <4F780373.6030107@freebsd.org> <4F7AFEEF.60708@freebsd.org> <4F7B1981.1050009@freebsd.org> <4F7B3098.3090901@freebsd.org> In-Reply-To: <4F7B3098.3090901@freebsd.org> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: darrenr@freebsd.org, freebsd-net@freebsd.org Subject: Re: FreeBSD TCP ignores zero window size 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, 04 Apr 2012 08:21:56 -0000 Andre Oppermann wrote: > The other side is retransmitting data we have already received > and acknowledged ... That behavior is totally non-compliant. Any chance our ack of that data got dropped/lost enroute, and the other side is resending after timing out? From owner-freebsd-net@FreeBSD.ORG Wed Apr 4 10:13:17 2012 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 60F16106564A for ; Wed, 4 Apr 2012 10:13:17 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id C33568FC0A for ; Wed, 4 Apr 2012 10:13:16 +0000 (UTC) Received: (qmail 30789 invoked from network); 4 Apr 2012 10:11:23 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 4 Apr 2012 10:11:23 -0000 Message-ID: <4F7C1EB9.5060307@freebsd.org> Date: Wed, 04 Apr 2012 12:13:13 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: perryh@pluto.rain.com References: <4F75C1A3.4030401@freebsd.org> <4F75D9ED.7080707@freebsd.org> <4F780373.6030107@freebsd.org> <4F7AFEEF.60708@freebsd.org> <4F7B1981.1050009@freebsd.org> <4F7B3098.3090901@freebsd.org> <4f7c62c7.MUlfd0e/uNQsAVZG%perryh@pluto.rain.com> In-Reply-To: <4f7c62c7.MUlfd0e/uNQsAVZG%perryh@pluto.rain.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: darrenr@freebsd.org, freebsd-net@freebsd.org Subject: Re: FreeBSD TCP ignores zero window size 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, 04 Apr 2012 10:13:17 -0000 On 04.04.2012 17:03, perryh@pluto.rain.com wrote: > Andre Oppermann wrote: > >> The other side is retransmitting data we have already received >> and acknowledged ... That behavior is totally non-compliant. > > Any chance our ack of that data got dropped/lost enroute, and the > other side is resending after timing out? The correct ACK is retransmitted about a dozen times for re-synchronization. Unlikely that all of them get lost. On top of it the RST to terminate the session has the correct SEQ. Something's munging the SEQ/ACK space along the way here. -- Andre From owner-freebsd-net@FreeBSD.ORG Wed Apr 4 12:26:03 2012 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 D1723106568A for ; Wed, 4 Apr 2012 12:26:03 +0000 (UTC) (envelope-from rsb@berentweb.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 75F3F8FC1A for ; Wed, 4 Apr 2012 12:26:03 +0000 (UTC) Received: by vbmv11 with SMTP id v11so157654vbm.13 for ; Wed, 04 Apr 2012 05:26:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=berentweb.com; s=google; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=xM+C2Rfp8fqmn8osYw9uBDkOSOLYzhGP3z+Y5JWrD8Q=; b=HeILmqaolnA+d6VwTAlZpU3tC9iTxBD3edVm57X+d9y2P6PY2pgmHkg2wbtNUGrBlw Fq369oxL/yoGC70aa7mp5R80wr5gHMh4lPwsnw0LWOeqB2wjmKLuiVf2iAMF2tc80W13 lPpYP1iLnIO4mYlhSkL4SBrrrcQJG94Ci2HKw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :x-gm-message-state; bh=xM+C2Rfp8fqmn8osYw9uBDkOSOLYzhGP3z+Y5JWrD8Q=; b=IYgnyMkAKmBV1JlOlCNyBNs1CSUzi+tgNmTMkR9IKRrWmY4d925c8V+NqCmLlhDo36 XzcqPLOBG5Lo48oso4rW5JrwRfMHNm0tZckVsaWBu83Ce9GPRB0jr02LGBHQ2cW2zl9o LMC4f+Sn2tjuAcntexY2VbhD2Ubm/4WNr9zUNi5dl4H+nyFh+WB1MxWscVxMNtpsZP9D k9sAAhVphI5eolt/hZIJtf7FTGjY8Mr5GNi+am1vm+TzQ05t5F6+cq2gXwuCqyK/pHdB l95/GdFd3yiJwqoP26iLchIo90tB+uDXWeivtTywpxwQzrsP7R4swb29b3JnogdRvYtU y/zg== MIME-Version: 1.0 Received: by 10.52.68.228 with SMTP id z4mr6572960vdt.1.1333542362580; Wed, 04 Apr 2012 05:26:02 -0700 (PDT) Sender: rsb@berentweb.com Received: by 10.220.195.204 with HTTP; Wed, 4 Apr 2012 05:26:02 -0700 (PDT) X-Originating-IP: [85.110.92.106] In-Reply-To: References: <20120329072054.GA45082@server.vk2pj.dyndns.org> <20120403074954.GA19241@server.vk2pj.dyndns.org> Date: Wed, 4 Apr 2012 15:26:02 +0300 X-Google-Sender-Auth: ikhL_C_zD8TkOlCzQlTuIrFEDqM Message-ID: From: Beeblebrox To: freebsd-net@freebsd.org X-Gm-Message-State: ALoCoQlnj2IL66h5+C43MR/RwclIdIaXkNucHeKnmUI1liOKShd2HJ2Cj0mimxay5Ag1oOcx0gQr Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: lagg problems on diskless 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, 04 Apr 2012 12:26:03 -0000 > > > Almost as bad as back when I sent a note to a customer about a > requirement to adjust our 'peeing' policy. (And the spell checker > won't catch that one.) > > On Tue, Apr 3, 2012 at 10:29 AM, Beeblebrox wrote: > > On Tue, Apr 3, 2012 at 7:46 PM, Kevin Oberman wrote: > > > >> On Tue, Apr 3, 2012 at 4:51 AM, Beeblebrox > wrote: > >> > Slightly different point of view: Under this scenario of dikless > clients > >> > having dual NICs would CRAP be a choice to consider? From what I have > >> read > >> Typo or editorial comment^^^^^^ -) > >> > it can offer loadbalancing but as I understand it's not really > applicable > >> > to diskless node situations? > @ Kevin: > Does a 'dikless' server run eunichs? Sorry. I really should resist this kind of carp. One could assert that all forms of harem *gateway* control were eunichs-based. However, after a compound slip-up like that, there's no graceful recovery: pwned, I am. @Peter: Thanks for the explanation on carp, confirmed my understanding of its function. > Actually, it doesn't matter that the root is RO, just that /mnt exists so it can be used as a mountpoint. Why the error and why does it freeze the system then? More than happy just to go with default /mnt but the DC does not like it for some odd reason. > whilst $lagg_tmp is parameterised, /mnt is hard-coded in several places No big deal, easily corrected on my end. > AFAIR, I use a separate ramdisk because /etc/rc.d/lagg runs very early and other mountpoints cannot be relied on. Do you mean like a usb flash? From owner-freebsd-net@FreeBSD.ORG Wed Apr 4 13:51:42 2012 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 089D8106564A for ; Wed, 4 Apr 2012 13:51:42 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id A25658FC14 for ; Wed, 4 Apr 2012 13:51:41 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SFQcY-00052a-FX for freebsd-net@freebsd.org; Wed, 04 Apr 2012 15:51:34 +0200 Received: from pool-108-35-132-213.nwrknj.fios.verizon.net ([108.35.132.213]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 04 Apr 2012 15:51:34 +0200 Received: from ixew by pool-108-35-132-213.nwrknj.fios.verizon.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 04 Apr 2012 15:51:34 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: enoch Date: Wed, 04 Apr 2012 09:51:19 -0400 Lines: 141 Message-ID: <87vclfwqp4.fsf@hotmail.com> References: <20120330233819.GC7325@michelle.cdnetworks.com> <4F75C5EC.6090303@hotmail.com> <20120402195215.GA3571@michelle.cdnetworks.com> <20120403023225.GD3571@michelle.cdnetworks.com> <87ty11670b.fsf@hotmail.com> <20120403183521.GA7380@michelle.cdnetworks.com> <87obr95pxh.fsf@hotmail.com> <20120403225422.GB7380@michelle.cdnetworks.com> <87sjgk5czo.fsf@hotmail.com> <20120404210445.GB10911@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: pool-108-35-132-213.nwrknj.fios.verizon.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.93 (berkeley-unix) Cancel-Lock: sha1:lZmkL3jlpTj7tOdKI9GJnCTXurA= Subject: Re: [nfe] DHCP failure on 8-stable 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, 04 Apr 2012 13:51:42 -0000 YongHyeon PYUN writes: > On Wed, Apr 04, 2012 at 12:37:15AM -0400, enoch wrote: >> YongHyeon PYUN writes: >> >> > On Tue, Apr 03, 2012 at 01:45:30AM -0400, enoch wrote: >> >> YongHyeon PYUN writes: >> >> >> >> > On Mon, Apr 02, 2012 at 07:36:36PM -0400, enoch wrote: >> >> >> YongHyeon PYUN writes: >> >> >> >> >> >> > On Mon, Apr 02, 2012 at 03:50:02AM -0400, enoch wrote: >> >> >> >> On 04/02/2012 03:52 PM, YongHyeon PYUN wrote: >> >> >> >> > On Fri, Mar 30, 2012 at 10:40:44AM -0400, enoch wrote: >> >> >> >> >> On 03/30/2012 19:38, YongHyeon PYUN wrote: >> >> >> >> >>> On Fri, Mar 30, 2012 at 03:01:52AM -0400, enoch wrote: >> >> >> >> >>>> Recently it became extremely difficult to pass the DHCP discovery step >> >> >> >> >>>> on boot. Now I am using the buggy [nve] instead. >> >> >> >> >>>> >> >> >> >> >>>> Can anyone help? >> >> >> >> >>>> >> >> >> >> >>> >> >> >> >> >>> Did you set synchronous_dhclient option in rc.conf? >> >> >> >> >>> >> >> >> >> >> >> >> >> >> >> Yes: ifconfig_nfe0="SYNCDHCP" >> >> >> >> >> >> >> >> >> >> I guess [nfe] is undergoing gradual devel changes of some sort as before >> >> >> >> >> it had some chance of reporting "empty headers" on initial ifconfig and >> >> >> >> >> refusing to work. Sorry, I should have reported when encountering the >> >> >> >> >> first problems rather than solve by reboot. >> >> >> >> > >> >> >> >> > Would you show me the output of both dmesg(nfe(4) and its PHY only) >> >> >> >> > and 'sysctl dev.nfe.0.stats'? >> >> >> >> > It would be also helpful to know whether nfe(4) still sees >> >> >> >> > incoming traffic. >> >> >> >> > Does assigning static IP work? >> >> >> >> > >> >> >> >> >> >> >> >> Static IP direct communication attempt from this desktop to another >> >> >> >> laptop through a crossover cable fails as follows. Thanks. >> >> >> >> >> >> >> >> nfe0: flags=8843 metric 0 mtu 1500 >> >> >> >> options=82008 >> >> >> >> ether 00:1f:bc:00:19:dc >> >> >> >> inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 >> >> >> >> media: Ethernet autoselect (1000baseT >> >> >> >> ) >> >> >> >> status: active >> >> >> >> >> >> >> >> nfe0: link state changed to UP >> >> >> >> nfe0: port 0xf200-0xf207 >> >> >> >> mem 0xefffb000-0xefffbfff irq 21 at device 20.0 on pci0 >> >> >> >> miibus1: on nfe0 >> >> >> > >> >> >> > It seems you've omitted PHY driver here. What PHY driver was >> >> >> > attached to nfe(4)? >> >> >> > >> >> >> >> >> >> miibus1: on nfe0 >> >> >> rgephy1: PHY 1 on miibus1 >> >> >> >> >> >> >> nfe0: Ethernet address: 00:1f:bc:00:19:dc >> >> >> >> nfe0: [FILTER] >> >> >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) >> >> >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) >> >> >> >> nfe0: link state changed to UP >> >> >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) >> >> >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) >> >> >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) >> >> >> >> >> >> >> >> dev.nfe.0.stats.rx.frame_errors: 0 >> >> >> >> dev.nfe.0.stats.rx.extra_bytes: 0 >> >> >> >> dev.nfe.0.stats.rx.late_cols: 0 >> >> >> >> dev.nfe.0.stats.rx.runts: 0 >> >> >> >> dev.nfe.0.stats.rx.jumbos: 0 >> >> >> >> dev.nfe.0.stats.rx.fifo_overuns: 0 >> >> >> >> dev.nfe.0.stats.rx.crc_errors: 0 >> >> >> >> dev.nfe.0.stats.rx.fae: 0 >> >> >> >> dev.nfe.0.stats.rx.len_errors: 0 >> >> >> >> dev.nfe.0.stats.rx.unicast: 56 >> >> >> >> dev.nfe.0.stats.rx.multicast: 0 >> >> >> >> dev.nfe.0.stats.rx.broadcast: 280 >> >> >> >> dev.nfe.0.stats.tx.octets: 7517 >> >> >> >> dev.nfe.0.stats.tx.zero_rexmits: 51 >> >> >> >> dev.nfe.0.stats.tx.one_rexmits: 0 >> >> >> >> dev.nfe.0.stats.tx.multi_rexmits: 0 >> >> >> >> dev.nfe.0.stats.tx.late_cols: 0 >> >> >> >> dev.nfe.0.stats.tx.fifo_underuns: 0 >> >> >> >> dev.nfe.0.stats.tx.carrier_losts: 0 >> >> >> >> dev.nfe.0.stats.tx.excess_deferrals: 0 >> >> >> >> dev.nfe.0.stats.tx.retry_errors: 0 >> >> >> >> >> >> >> > >> >> >> > Thanks. Would you show me the output of "pciconf -lcbv"? >> >> >> > >> >> >> >> >> >> nfe0@pci0:0:20:0: class=0x068000 card=0x10003842 chip=0x026910de rev=0xa3 hdr=0x00 >> >> >> vendor = 'NVIDIA Corporation' >> >> >> device = 'MCP51 Network Bus Enumerator' >> >> >> class = bridge >> >> >> bar [10] = type Memory, range 32, base 0xefffb000, size 4096, enabled >> >> >> bar [14] = type I/O Port, range 32, base 0xf200, size 8, enabled >> >> >> cap 01[44] = powerspec 2 supports D0 D1 D2 D3 current D0 >> >> >> >> >> >> Interestingly, now that nfe0 is using a static IP it sometimes boots >> >> >> up properly. Are you interested in its good working? >> >> > >> >> > Yes I am. Would you try attached patch and let me know whether the >> >> > patch makes any difference on your box? >> >> >> >> Sorry to report: The patch was applied (to 8-stable latest code) but out >> >> of 3 boots only one succeeded. Same stream of "nfe0: discard frame w/o >> >> leading ethernet header (len 0 pkt len 0)" messages. >> > >> > Ok, back out previous patch and try attached one. >> >> With these two patch files applied to the 8-stable code, buildkernel >> fails as follows. >> >> /usr/src/sys/modules/nfe/../../dev/nfe/if_nfe.c: In function 'nfe_attach': >> /usr/src/sys/modules/nfe/../../dev/nfe/if_nfe.c:629: error: 'struct mii_softc' has no member named 'mii_mpd_oui' >> /usr/src/sys/modules/nfe/../../dev/nfe/if_nfe.c:629: error: 'struct mii_softc' has no member named 'mii_mpd_oui' >> /usr/src/sys/modules/nfe/../../dev/nfe/if_nfe.c:630: error: 'struct mii_softc' has no member named 'mii_mpd_model' >> *** Error code 1 >> > > Oops, sorry I forgot that this part of change was not merged to > stable/8. I've attached a minimal patch which would be cleanly > applied to stable/8. Wasn't the attached diff3 already included in diff2? Seems to me the wrong file was attached this time. Please advise. > >> Sorry, I can't handle 9-stable. Enoch. > > _______________________________________________ > 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 Apr 4 14:47:54 2012 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 C45AC1065672; Wed, 4 Apr 2012 14:47:54 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9C0948FC19; Wed, 4 Apr 2012 14:47:54 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 195CFB941; Wed, 4 Apr 2012 10:47:54 -0400 (EDT) From: John Baldwin To: freebsd-net@freebsd.org Date: Wed, 4 Apr 2012 10:43:47 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <4F7BDB21.5000703@freebsd.org> In-Reply-To: <4F7BDB21.5000703@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201204041043.47990.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 04 Apr 2012 10:47:54 -0400 (EDT) Cc: Subject: Re: networking working group at devsummit 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, 04 Apr 2012 14:47:54 -0000 On Wednesday, April 04, 2012 1:24:49 am Julian Elischer wrote: > I made a sub-page for the working group at: > > http://wiki.freebsd.org/201205DevSummit/Networking > > (directly ripped off the virtualization sub-page) > > feel free to add ideas etc. there. (or 'register' if you are coming to > the devsummit). Actually, please don't use that page as it has moved. Instead, go to the main wiki page for the devsummit and use the link to the page. I think it is "Network" instead of "Networking". -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Wed Apr 4 19:17:45 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2A107106564A for ; Wed, 4 Apr 2012 19:17:45 +0000 (UTC) (envelope-from access@gmail.com) Received: from dawggonedirty.com (secure-power.com [76.12.193.213]) by mx1.freebsd.org (Postfix) with ESMTP id D81218FC12 for ; Wed, 4 Apr 2012 19:17:44 +0000 (UTC) Received: (qmail 20995 invoked by uid 48); 4 Apr 2012 14:17:17 -0500 Date: 4 Apr 2012 14:17:17 -0500 Message-ID: <20120404191717.20990.qmail@dawggonedirty.com> To: freebsd-net@freebsd.org From: access@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Subject: Real Canned Butter - case X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: access@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 19:17:45 -0000 Name: Dear Friend, Email: access@gmail.com Dear Friend, How I Made 1 Million Pounds In Under 7 Years Without A Job! Congratulations: Get your $621 Commissions Now!!! It's So Simple That Even A Ten Year Old Could Learn This In Under 1 Hour!""It Doesn't Matter Where In The World You Are If You Have An Internet Connection & A PC You Can Claim Hundreds Of £Pounds For Just A Few Minutes Of Clicking A Mouse " Imagine waking up at 10am in the morning, having a quick look at your PC and finding the exact information you need to collect a quick $300 by lunchtime. You could take the afternoon off, play some golf, go shopping or spend some quality time with the family. Then do the same thing again in the evening, What a wonderful concept and you could be doing it today. Even during the boom years in any economy it's not possible to find a form of free income, BUT THIS IS EXACTLY THAT! and it will make you free money for the rest of your life. It's Easy To Make Money Everyday Even If You're Starting From Scratch With Zero Knowledge, Experience Or Budget!I'll Show You Exactly How. We've Start putting New 23 Members in YOUR TEAM for the April 1th-7th 2012 weekly commission cycle...and GROWING everyday earn by $100 up to $200 or more. IMPORTANT: JApril 07th 2012, 2010 is the Cut-Off day to lock in your position then faster you act the higher commission you will earn!!! Go Here To Secure not less than $621 commission Now and it still growing as many people joining under you. if you secure your position right away: The $803.85 commission will Arrive Through your Paypal or Credit Card ...Hurry this limited time, only 3 Positions are available Now. Once your Membership are set up, you will be able to earn $621 in less than 2 hours a day.I will show you how we do that and then I will help you through the process so that YOU SUCCEED! Date Commissions Send April 30, 2012 You will access your $621 in any ATM when you Join early and you follow instructions. http://bit.ly/HUfgGh TYPE DATE & TIME --- NEW MEMBERS --- COUNTRY P -- APRIL.03 @ 2:38 AM-----Adrian Cooper------------ United States P -- APRIL.03 @ 2:53 AM-----Cristoper Parker -------- United Kingdom P -- APRIL.03 @ 2:56 AM-----Mandene Armstrong-------- Germany M -- APRIL.03 @ 4:19 AM-----Gerbert Sindongpa-------- Singapore P -- APRIL.03 @ 4:28 AM-----Carlo Echevarria--------- Italy M -- APRIL.03 @ 6:01 AM-----lalaine ferguson--------- Australia P -- APRIL.03 @ 7:11 AM-----Rebecca Underwood-------- Hungary P -- APRIL.03 @ 7:39 AM-----Jericho Sanchez---------- Canada P -- APRIL.03 @ 9:42 AM-----Thomas Coolin------------ Sri Lanka M -- APRIL.03 @ 9:58 PM-----Grace Taylor------------- Russia P -- APRIL.03 @ 10:21 PM-----Gina Jonhson------------- New Zealand P -- APRIL.03 @ 11:24 PM-----Effren Christobal-------- Romania M -- APRIL.03 @ 11:33 PM-----Tracia Miller------------ Puerto Rico P -- APRIL.03 @ 11:41 PM-----Jane furlong------------- Potugal P -- APRIL.03 @ 11:47 PM-----Janice Pulbirds---------- United States P -- APRIL.03 @ 11:53 PM-----Shirley Roots------------ United States P -- APRIL.03 @ 1:45 AM --- Ryann Lambert ----------- Europe M -- APRIL.03 @ 12:34 AM --- Nick Gauci -------------- Calefornia M -- APRIL.03 @ 10:24 AM --- Don Riley --------------- Netherland P -- APRIL.03 @ 10:30 AM --- Lorne Whittaker --------- Swetzerland P -- APRIL.03 @ 02:14 AM --- Ashwani Vohra ----------- Brazil M -- APRIL.03 @ 2:34 AM --- Kevin Hunter ------------ United States P -- APRIL.03 @ 1:54 AM --- Charles James Mills ----- South Africa Therefore, you have a GUARANTEED $621 CommissionS every month from now on!. Earn $27 Per Process!Each $27 x 23 = $621 Commission will be yours...! Be Sure to Copy the link below & Paste into your browser and press enter: To Secure your $$621 commission! You will access your money in any ATM when you follow the instructions you receive. http://bit.ly/HUfgGh If you join Now, your membership automatic cover, And you can recieve bigger commissions waiting at the end of the month. Today its $621 For the start of the month of April if goes up daily until the end of the month. You must UPGRADE right away or before others do.... Caring for Your Success, Mark Falesaine Add to Calendar April 30 2012 http://www.internet-grocer.net/store/cart.php?m=product_detail&p=1351 From owner-freebsd-net@FreeBSD.ORG Wed Apr 4 21:24:04 2012 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 D75AA106564A for ; Wed, 4 Apr 2012 21:24:04 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from fallbackmx06.syd.optusnet.com.au (fallbackmx06.syd.optusnet.com.au [211.29.132.8]) by mx1.freebsd.org (Postfix) with ESMTP id 667A38FC0A for ; Wed, 4 Apr 2012 21:24:04 +0000 (UTC) Received: from mail16.syd.optusnet.com.au (mail16.syd.optusnet.com.au [211.29.132.197]) by fallbackmx06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q34LI107016825 for ; Thu, 5 Apr 2012 07:18:01 +1000 Received: from server.vk2pj.dyndns.org (c220-239-251-180.belrs5.nsw.optusnet.com.au [220.239.251.180]) by mail16.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q34LHrTU022776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 5 Apr 2012 07:17:54 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.5/8.14.4) with ESMTP id q34LHn3i018259 for ; Thu, 5 Apr 2012 07:17:49 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.5/8.14.5/Submit) id q34LHnZL018258 for freebsd-net@freebsd.org; Thu, 5 Apr 2012 07:17:49 +1000 (EST) (envelope-from peter) Date: Thu, 5 Apr 2012 07:17:49 +1000 From: Peter Jeremy To: freebsd-net@freebsd.org Message-ID: <20120404211749.GA16579@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="17pEHd4RhPHOinZp" Content-Disposition: inline X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) Subject: dhclient behaviour on link status changes 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, 04 Apr 2012 21:24:04 -0000 --17pEHd4RhPHOinZp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable /etc/devd.conf includes a rule to start dhclient when an Ethernet or 802.11 interface reports "link up", with a comment: "No link down rule exists because dhclient automatically exits when the link goes down." IMHO, this is the desired behaviour, unfortunately it's not the way dhclient actually behaves. In my experience, dhclient will exit when the interface goes down but ignores link status changes. Looking at the source, it seems to exit only when there's no usable route (by monitoring RTF_UP). dhclient does monitor the link status using SIOCGIFMEDIA but only at startup (it will exit if the link doesn't come up within 10s of dhclient starting) and during DHCP exchanges (if the link goes down when it's expecting a DHCP response then it exits). Can anyone explain the rationale behind the current behaviour? --=20 Peter Jeremy --17pEHd4RhPHOinZp Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk98un0ACgkQ/opHv/APuIeligCggIjN53HW/xbzhvj+0vC+9kSR L1UAoIpa2SlQ2gKVUJ8vdZ30oy6zQGoX =Zaha -----END PGP SIGNATURE----- --17pEHd4RhPHOinZp-- From owner-freebsd-net@FreeBSD.ORG Thu Apr 5 00:12:04 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C96331065670 for ; Thu, 5 Apr 2012 00:12:04 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx1.freebsd.org (Postfix) with ESMTP id 9377C8FC14 for ; Thu, 5 Apr 2012 00:12:04 +0000 (UTC) Received: by dadz14 with SMTP id z14so3256288dad.17 for ; Wed, 04 Apr 2012 17:12:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=HV957pZKhlgWd5jJCFkz9qxoVGwZGAQ+UyEmZepeuSQ=; b=y7TaI5meST+oE3OMGBLpdFCKRW0ELf8SZy5LBGA3jc5eRjeYRKBmTNSjFD9nnvQzvz U977LdGvPFQEAzH6cAvILNM05BGFgz/1rbzWiagaXb5ZIi+aUvA25Tk8o1HMpY8+6YUo 7xHxWjvUsfsfetElk126B42ZIMahJrmBpr04yecmjO93mU5YXYsr1AmQRuOjDPWyFkBA c3pQfprBUphDWPP7RHzNq8tjPrPZYHmgtapU7Zr0Mvy1HxR4UQPG2KCC1ghhx9PbvJte Ojpyet1DgWBFS5ndcqYu6OqFPwCZhwt0yXz4jGFfGZvUSxptJf6/owIxhBIU+MQ6Uife 2AMA== Received: by 10.68.195.169 with SMTP id if9mr2170602pbc.68.1333584724420; Wed, 04 Apr 2012 17:12:04 -0700 (PDT) Received: from pyunyh@gmail.com ([114.111.62.249]) by mx.google.com with ESMTPS id i5sm1657948pbf.19.2012.04.04.17.12.00 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 Apr 2012 17:12:02 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 05 Apr 2012 09:11:52 -0700 From: YongHyeon PYUN Date: Thu, 5 Apr 2012 09:11:52 -0700 To: enoch Message-ID: <20120405161152.GA14289@michelle.cdnetworks.com> References: <20120402195215.GA3571@michelle.cdnetworks.com> <20120403023225.GD3571@michelle.cdnetworks.com> <87ty11670b.fsf@hotmail.com> <20120403183521.GA7380@michelle.cdnetworks.com> <87obr95pxh.fsf@hotmail.com> <20120403225422.GB7380@michelle.cdnetworks.com> <87sjgk5czo.fsf@hotmail.com> <20120404210445.GB10911@michelle.cdnetworks.com> <87vclfwqp4.fsf@hotmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87vclfwqp4.fsf@hotmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: [nfe] DHCP failure on 8-stable 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: Thu, 05 Apr 2012 00:12:04 -0000 On Wed, Apr 04, 2012 at 09:51:19AM -0400, enoch wrote: > YongHyeon PYUN writes: > > > On Wed, Apr 04, 2012 at 12:37:15AM -0400, enoch wrote: > >> YongHyeon PYUN writes: > >> > >> > On Tue, Apr 03, 2012 at 01:45:30AM -0400, enoch wrote: > >> >> YongHyeon PYUN writes: > >> >> > >> >> > On Mon, Apr 02, 2012 at 07:36:36PM -0400, enoch wrote: > >> >> >> YongHyeon PYUN writes: > >> >> >> > >> >> >> > On Mon, Apr 02, 2012 at 03:50:02AM -0400, enoch wrote: > >> >> >> >> On 04/02/2012 03:52 PM, YongHyeon PYUN wrote: > >> >> >> >> > On Fri, Mar 30, 2012 at 10:40:44AM -0400, enoch wrote: > >> >> >> >> >> On 03/30/2012 19:38, YongHyeon PYUN wrote: > >> >> >> >> >>> On Fri, Mar 30, 2012 at 03:01:52AM -0400, enoch wrote: > >> >> >> >> >>>> Recently it became extremely difficult to pass the DHCP discovery step > >> >> >> >> >>>> on boot. Now I am using the buggy [nve] instead. > >> >> >> >> >>>> > >> >> >> >> >>>> Can anyone help? > >> >> >> >> >>>> > >> >> >> >> >>> > >> >> >> >> >>> Did you set synchronous_dhclient option in rc.conf? > >> >> >> >> >>> > >> >> >> >> >> > >> >> >> >> >> Yes: ifconfig_nfe0="SYNCDHCP" > >> >> >> >> >> > >> >> >> >> >> I guess [nfe] is undergoing gradual devel changes of some sort as before > >> >> >> >> >> it had some chance of reporting "empty headers" on initial ifconfig and > >> >> >> >> >> refusing to work. Sorry, I should have reported when encountering the > >> >> >> >> >> first problems rather than solve by reboot. > >> >> >> >> > > >> >> >> >> > Would you show me the output of both dmesg(nfe(4) and its PHY only) > >> >> >> >> > and 'sysctl dev.nfe.0.stats'? > >> >> >> >> > It would be also helpful to know whether nfe(4) still sees > >> >> >> >> > incoming traffic. > >> >> >> >> > Does assigning static IP work? > >> >> >> >> > > >> >> >> >> > >> >> >> >> Static IP direct communication attempt from this desktop to another > >> >> >> >> laptop through a crossover cable fails as follows. Thanks. > >> >> >> >> > >> >> >> >> nfe0: flags=8843 metric 0 mtu 1500 > >> >> >> >> options=82008 > >> >> >> >> ether 00:1f:bc:00:19:dc > >> >> >> >> inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 > >> >> >> >> media: Ethernet autoselect (1000baseT > >> >> >> >> ) > >> >> >> >> status: active > >> >> >> >> > >> >> >> >> nfe0: link state changed to UP > >> >> >> >> nfe0: port 0xf200-0xf207 > >> >> >> >> mem 0xefffb000-0xefffbfff irq 21 at device 20.0 on pci0 > >> >> >> >> miibus1: on nfe0 > >> >> >> > > >> >> >> > It seems you've omitted PHY driver here. What PHY driver was > >> >> >> > attached to nfe(4)? > >> >> >> > > >> >> >> > >> >> >> miibus1: on nfe0 > >> >> >> rgephy1: PHY 1 on miibus1 > >> >> >> > >> >> >> >> nfe0: Ethernet address: 00:1f:bc:00:19:dc > >> >> >> >> nfe0: [FILTER] > >> >> >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) > >> >> >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) > >> >> >> >> nfe0: link state changed to UP > >> >> >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) > >> >> >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) > >> >> >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) > >> >> >> >> > >> >> >> >> dev.nfe.0.stats.rx.frame_errors: 0 > >> >> >> >> dev.nfe.0.stats.rx.extra_bytes: 0 > >> >> >> >> dev.nfe.0.stats.rx.late_cols: 0 > >> >> >> >> dev.nfe.0.stats.rx.runts: 0 > >> >> >> >> dev.nfe.0.stats.rx.jumbos: 0 > >> >> >> >> dev.nfe.0.stats.rx.fifo_overuns: 0 > >> >> >> >> dev.nfe.0.stats.rx.crc_errors: 0 > >> >> >> >> dev.nfe.0.stats.rx.fae: 0 > >> >> >> >> dev.nfe.0.stats.rx.len_errors: 0 > >> >> >> >> dev.nfe.0.stats.rx.unicast: 56 > >> >> >> >> dev.nfe.0.stats.rx.multicast: 0 > >> >> >> >> dev.nfe.0.stats.rx.broadcast: 280 > >> >> >> >> dev.nfe.0.stats.tx.octets: 7517 > >> >> >> >> dev.nfe.0.stats.tx.zero_rexmits: 51 > >> >> >> >> dev.nfe.0.stats.tx.one_rexmits: 0 > >> >> >> >> dev.nfe.0.stats.tx.multi_rexmits: 0 > >> >> >> >> dev.nfe.0.stats.tx.late_cols: 0 > >> >> >> >> dev.nfe.0.stats.tx.fifo_underuns: 0 > >> >> >> >> dev.nfe.0.stats.tx.carrier_losts: 0 > >> >> >> >> dev.nfe.0.stats.tx.excess_deferrals: 0 > >> >> >> >> dev.nfe.0.stats.tx.retry_errors: 0 > >> >> >> >> > >> >> >> > > >> >> >> > Thanks. Would you show me the output of "pciconf -lcbv"? > >> >> >> > > >> >> >> > >> >> >> nfe0@pci0:0:20:0: class=0x068000 card=0x10003842 chip=0x026910de rev=0xa3 hdr=0x00 > >> >> >> vendor = 'NVIDIA Corporation' > >> >> >> device = 'MCP51 Network Bus Enumerator' > >> >> >> class = bridge > >> >> >> bar [10] = type Memory, range 32, base 0xefffb000, size 4096, enabled > >> >> >> bar [14] = type I/O Port, range 32, base 0xf200, size 8, enabled > >> >> >> cap 01[44] = powerspec 2 supports D0 D1 D2 D3 current D0 > >> >> >> > >> >> >> Interestingly, now that nfe0 is using a static IP it sometimes boots > >> >> >> up properly. Are you interested in its good working? > >> >> > > >> >> > Yes I am. Would you try attached patch and let me know whether the > >> >> > patch makes any difference on your box? > >> >> > >> >> Sorry to report: The patch was applied (to 8-stable latest code) but out > >> >> of 3 boots only one succeeded. Same stream of "nfe0: discard frame w/o > >> >> leading ethernet header (len 0 pkt len 0)" messages. > >> > > >> > Ok, back out previous patch and try attached one. > >> > >> With these two patch files applied to the 8-stable code, buildkernel > >> fails as follows. > >> > >> /usr/src/sys/modules/nfe/../../dev/nfe/if_nfe.c: In function 'nfe_attach': > >> /usr/src/sys/modules/nfe/../../dev/nfe/if_nfe.c:629: error: 'struct mii_softc' has no member named 'mii_mpd_oui' > >> /usr/src/sys/modules/nfe/../../dev/nfe/if_nfe.c:629: error: 'struct mii_softc' has no member named 'mii_mpd_oui' > >> /usr/src/sys/modules/nfe/../../dev/nfe/if_nfe.c:630: error: 'struct mii_softc' has no member named 'mii_mpd_model' > >> *** Error code 1 > >> > > > > Oops, sorry I forgot that this part of change was not merged to > > stable/8. I've attached a minimal patch which would be cleanly > > applied to stable/8. > > Wasn't the attached diff3 already included in diff2? Seems to me the > wrong file was attached this time. Please advise. diff2 is subset of diff3 but it can be merged to stable/8 and stable/7. Probably diff2 may have better chance to fully reinitialize PHY but let's see whether diff3 also makes difference on your box. So back out any changes and apply diff3. > > > > >> Sorry, I can't handle 9-stable. Enoch. From owner-freebsd-net@FreeBSD.ORG Thu Apr 5 02:39:57 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 71307106566B for ; Thu, 5 Apr 2012 02:39:57 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from fallbackmx09.syd.optusnet.com.au (fallbackmx09.syd.optusnet.com.au [211.29.132.242]) by mx1.freebsd.org (Postfix) with ESMTP id F1B648FC0A for ; Thu, 5 Apr 2012 02:39:56 +0000 (UTC) Received: from mail13.syd.optusnet.com.au (mail13.syd.optusnet.com.au [211.29.132.194]) by fallbackmx09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q352dttm012940 for ; Thu, 5 Apr 2012 12:39:55 +1000 Received: from server.vk2pj.dyndns.org (c220-239-251-180.belrs5.nsw.optusnet.com.au [220.239.251.180]) by mail13.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q352dlFI027489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 5 Apr 2012 12:39:48 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.5/8.14.4) with ESMTP id q352dlO3080803 for ; Thu, 5 Apr 2012 12:39:47 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.5/8.14.5/Submit) id q352dlkB080802 for freebsd-net@freebsd.org; Thu, 5 Apr 2012 12:39:47 +1000 (EST) (envelope-from peter) Date: Thu, 5 Apr 2012 12:39:46 +1000 From: Peter Jeremy To: freebsd-net@freebsd.org Message-ID: <20120405023946.GA63311@server.vk2pj.dyndns.org> References: <20120404211749.GA16579@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vkogqOf2sHV7VnPd" Content-Disposition: inline In-Reply-To: <20120404211749.GA16579@server.vk2pj.dyndns.org> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: dhclient behaviour on link status changes 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, 05 Apr 2012 02:39:57 -0000 --vkogqOf2sHV7VnPd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-Apr-05 07:17:49 +1000, Peter Jeremy wrote: >/etc/devd.conf includes a rule to start dhclient when an Ethernet or >802.11 interface reports "link up", with a comment: "No link down rule >exists because dhclient automatically exits when the link goes down." >IMHO, this is the desired behaviour, unfortunately it's not the way >dhclient actually behaves. In my experience, dhclient will exit when >the interface goes down but ignores link status changes. I found an easy way to correct the behaviour & submitted bin/166656 --=20 Peter Jeremy --vkogqOf2sHV7VnPd Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk99BfIACgkQ/opHv/APuIfaIgCglbGR/vx9zS1CS2lytVFFyJFY ilAAoMACrRtYALO7N06HDFmJHkV/AeUW =w4CZ -----END PGP SIGNATURE----- --vkogqOf2sHV7VnPd-- From owner-freebsd-net@FreeBSD.ORG Thu Apr 5 04:22:48 2012 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 856B3106564A for ; Thu, 5 Apr 2012 04:22:48 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 546248FC08 for ; Thu, 5 Apr 2012 04:22:48 +0000 (UTC) Received: by pbcwz17 with SMTP id wz17so1082277pbc.13 for ; Wed, 04 Apr 2012 21:22:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=5sS7k7vvK8lB2dqo04Fevs1qCuHQLxrK8bOwMWNUjSk=; b=SFfW/mCRZbKGh+O3R+XEqIN1/hLkEfUdeck2KXAcl1E0RaPiIgvXspfny1Vu4/owL/ O/zltmXFcA+Q5QZPr5cOEX914UBpYINnGe3j0CrB4Wuvtylv5Qe2k6tWI4V8BkKfmfkl TW33zOamkRCvuLPqdWipVnBPF++6c+9fh7dPPCC0AuuA3Jv8NpLEM3Aj2vzDeUyYacii 4s7+6qaTaU6s7nEJUAJw6F5qsc7AuGYAIt9w2rHgcbeEJ9itgcmTnnebLFPMdndn6any D5fmVXIOezi1j6p/wG4JTGLYBKzHa5bwB8Y6Ija7aqWFf0ddUaw9ktvi34ZQ3WvpIF5Z XLpg== Received: by 10.68.194.198 with SMTP id hy6mr3904146pbc.0.1333599767943; Wed, 04 Apr 2012 21:22:47 -0700 (PDT) Received: from pyunyh@gmail.com ([114.111.62.249]) by mx.google.com with ESMTPS id o9sm2088694pbe.60.2012.04.04.21.22.44 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 Apr 2012 21:22:46 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 05 Apr 2012 13:22:37 -0700 From: YongHyeon PYUN Date: Thu, 5 Apr 2012 13:22:37 -0700 To: Peter Jeremy Message-ID: <20120405202237.GC14289@michelle.cdnetworks.com> References: <20120404211749.GA16579@server.vk2pj.dyndns.org> <20120405023946.GA63311@server.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120405023946.GA63311@server.vk2pj.dyndns.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: dhclient behaviour on link status changes 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: Thu, 05 Apr 2012 04:22:48 -0000 On Thu, Apr 05, 2012 at 12:39:46PM +1000, Peter Jeremy wrote: > On 2012-Apr-05 07:17:49 +1000, Peter Jeremy wrote: > >/etc/devd.conf includes a rule to start dhclient when an Ethernet or > >802.11 interface reports "link up", with a comment: "No link down rule > >exists because dhclient automatically exits when the link goes down." > >IMHO, this is the desired behaviour, unfortunately it's not the way > >dhclient actually behaves. In my experience, dhclient will exit when > >the interface goes down but ignores link status changes. > > I found an easy way to correct the behaviour & submitted bin/166656 > Hmm, wouldn't this make dhclient die when speed/duplex/flow control of established connection is changed by admin or remote link partner? For instance, #ifconfig foo0 media mdiaopt flow > -- > Peter Jeremy From owner-freebsd-net@FreeBSD.ORG Thu Apr 5 04:45:03 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 95E13106566C for ; Thu, 5 Apr 2012 04:45:03 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail34.syd.optusnet.com.au (mail34.syd.optusnet.com.au [211.29.133.218]) by mx1.freebsd.org (Postfix) with ESMTP id 205B98FC0A for ; Thu, 5 Apr 2012 04:45:02 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c220-239-251-180.belrs5.nsw.optusnet.com.au [220.239.251.180]) by mail34.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q354j00H011782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Apr 2012 14:45:01 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.5/8.14.4) with ESMTP id q354j0wN093314; Thu, 5 Apr 2012 14:45:00 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.5/8.14.5/Submit) id q354ixMY093307; Thu, 5 Apr 2012 14:44:59 +1000 (EST) (envelope-from peter) Date: Thu, 5 Apr 2012 14:44:59 +1000 From: Peter Jeremy To: YongHyeon PYUN Message-ID: <20120405044459.GB63311@server.vk2pj.dyndns.org> References: <20120404211749.GA16579@server.vk2pj.dyndns.org> <20120405023946.GA63311@server.vk2pj.dyndns.org> <20120405202237.GC14289@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lEGEL1/lMxI0MVQ2" Content-Disposition: inline In-Reply-To: <20120405202237.GC14289@michelle.cdnetworks.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@freebsd.org Subject: Re: dhclient behaviour on link status changes 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, 05 Apr 2012 04:45:03 -0000 --lEGEL1/lMxI0MVQ2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-Apr-05 13:22:37 -0700, YongHyeon PYUN wrote: >On Thu, Apr 05, 2012 at 12:39:46PM +1000, Peter Jeremy wrote: >> On 2012-Apr-05 07:17:49 +1000, Peter Jeremy wrote: >> >/etc/devd.conf includes a rule to start dhclient when an Ethernet or >> >802.11 interface reports "link up", with a comment: "No link down rule >> >exists because dhclient automatically exits when the link goes down." >> >IMHO, this is the desired behaviour, unfortunately it's not the way >> >dhclient actually behaves. In my experience, dhclient will exit when >> >the interface goes down but ignores link status changes. >>=20 >> I found an easy way to correct the behaviour & submitted bin/166656 >Hmm, wouldn't this make dhclient die when speed/duplex/flow control >of established connection is changed by admin or remote link partner? >For instance, >#ifconfig foo0 media mdiaopt flow If the speed/duplex/flow control change triggered a "LINK DOWN" "LINK UP" kernel message then, yes, that would cause dhclient to restart. I think that depends on the NIC. I guess a potential work-around would be to have dhclient ignore outages shorter than a configurable value. I hadn't considered that because it's not something that I ever do on a running system. (This investigation was prompted by my ISP's approach to address grooming - they just remotely reboot the cablemodem and expect clients to re-DHCP. Existing valid leases are just ignored. Since the FreeBSD dhclient ignores the link outage, I just lose Internet connectivity until I manually restart DHCP). --=20 Peter Jeremy --lEGEL1/lMxI0MVQ2 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk99I0sACgkQ/opHv/APuIcGjwCeJqaxwJVIUe3od7C5NdFNjznC 46YAn3m27R/2mf5uxinJv09CQChyUWvq =TCQI -----END PGP SIGNATURE----- --lEGEL1/lMxI0MVQ2-- From owner-freebsd-net@FreeBSD.ORG Thu Apr 5 05:07:56 2012 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 F2D5C106564A for ; Thu, 5 Apr 2012 05:07:55 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 40F5E8FC0A for ; Thu, 5 Apr 2012 05:07:55 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so1210438bkc.13 for ; Wed, 04 Apr 2012 22:07:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=poQFd2HN1JgXgnxT4z3G6c5gM5V63CAl9iFHzXlftJo=; b=Gz9Tnbl7SGRvNhdLDykkg+ZsCdf2l1WIsdbxZhqribYHK477hMc1q8G8SKlF+w8dES oWztaTJQs1HTOuKFRBq4sgsXtHjVKdEKIoqZbUb1AqQwa3P/K2vz+QbMuCJq10nWgKI8 8QAiXl4GuMdkzRCvLb4nO/AVFzAFnqvK7aa+XjX2ZxbY8hTEdlpSlqUaF7Scs+jOdN7l AlW7oVi6ikdnFZpDmRNuFZN4VZCrOEyZYbBGUpYeGJHabg5FtsgmDtf5pwtrAR+d85mv V6LUzREcvU93aboOs/vs7wJN/9CHDNVpTEpmAt56zj0lMkCbYaqROYP0vQz1Xyys1fQD TZrA== MIME-Version: 1.0 Received: by 10.204.9.194 with SMTP id m2mr447926bkm.92.1333602474367; Wed, 04 Apr 2012 22:07:54 -0700 (PDT) Received: by 10.204.69.195 with HTTP; Wed, 4 Apr 2012 22:07:54 -0700 (PDT) In-Reply-To: References: Date: Thu, 5 Apr 2012 01:07:54 -0400 Message-ID: From: Zaphod Beeblebrox To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: PXE Boot vmware 8.x fails after pxeboot. 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, 05 Apr 2012 05:07:56 -0000 Replying to my own message again, I tried booting the same configuration on the raw computer hardware (as opposed to vmware). On the raw computer hardware, pxeboot correctly loads a kernel and boots it. This seems to imply that pxeboot and vmware 8.x don't play well together. On Tue, Apr 3, 2012 at 1:27 AM, Zaphod Beeblebrox wrote= : > Replying to my own message, I add more below... > > On Sun, Apr 1, 2012 at 8:44 PM, Zaphod Beeblebrox wro= te: >> I have had diskless FreeBSD machines before. =A0I started this project >> with an eye to booting iscsi disks, but there seems to be no way to >> communicate the root disk path (and parameters) to FreeBSD --- >> something that might be solvable, but I need practical at the moment. >> So I fall back on NFS diskless with PXE boot (I may have used >> etherboot in the past --- it's been awhile). >> >> Anyways... this attempt is made with FreeBSD-9.0-RELEASE binaries. >> >> In my network, 192.168.0.1 is the DHCP and TFTP server. =A0192.168.0.52 >> is my NFS server. =A0The new vmware guest is bridged and gets >> 192.168.0.135. =A0It successfully gets 'pxeboot' onto the vmware guest >> --- pxeboot prints it's banner. =A0Then the only network traffic I >> observe is DHCP Discover (vmware, presumably the pxeboot binary) >> followed by DHCP Offer (192.168.0.1 again) and this repeats. >> >> Now the dhcp offer gives a root path of >> "192.168.0.52:/vr/diskless/hit" ... and I've tried it with and without >> a trailing slash. >> >> Obviously this is something within the pxeboot's binary as no attempt >> to make the nfs mount occurs. > > ... With a few more variations of this test, I came across a > configuration where the pxeboot client loaded into the vmware system > would continue to spam the "options next-server" host to mount "/" ... > interestingly here, it seems to completely ignore "options root-path" > ... both the ip address and the path portions alike. > > ... but said behavior only occurs with some set of random > configuration changes on the returned DHCP packets and/or slightly > different versions of pxeboot (which I've pulled from various hosts > from 8.x through the 9.x that I'm trying to boot with. > > It strikes me that the pxeboot process is hanging somewhere ... or > overwriting memory ... or somesuch ... on this box. > > Has anyone seen or investigated this type of behavior? From owner-freebsd-net@FreeBSD.ORG Thu Apr 5 07:22:01 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 92C9D106564A; Thu, 5 Apr 2012 07:22:00 +0000 (UTC) (envelope-from saeedeh.motlagh@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id C955F8FC16; Thu, 5 Apr 2012 07:21:59 +0000 (UTC) Received: by wern13 with SMTP id n13so851984wer.13 for ; Thu, 05 Apr 2012 00:21:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=4awHPmcXUmkibPfiRGw7tpjDNzBdiVmHumpdjHJaSlo=; b=nJ0ix43kEC8q82FpKSUy0Xv2Ev9GYPH0YPn7GiYUCIq6QIV4PeiMWsmngTXfpR93pS PxAUppZkUknulEgkDmWX8tIYJCXiEx9pl7nptiXqTSOnMPA03eyzgJLlOV4pNyPQwaQx H134SZBo1uPigx61Jbgw9DLwvnMNGGdjrgR2qDE1mxatIJd/MpRfv/7VD/heOpfRzxjK P574smXyQVWidxDMfUPPNvKwifQSPyZH3KmAXkCquYmFRXNC0Pak8WZ4muxnYvYynU0q PB9GPbUHbzpb8iF0Xo0IipyfLdADBfnxzbI+3a70x/AYQQY7wGCrbmC1YMWYw/0bKRhW klNw== Received: by 10.216.136.202 with SMTP id w52mr930950wei.109.1333610518782; Thu, 05 Apr 2012 00:21:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.87.10 with HTTP; Thu, 5 Apr 2012 00:21:18 -0700 (PDT) From: saeedeh motlagh Date: Thu, 5 Apr 2012 00:21:18 -0700 Message-ID: To: freebsd-net , freebsd-questions@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: what is the path of kernel build directory? 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, 05 Apr 2012 07:22:01 -0000 hello guys i want to install the openvswitch 1.4.0 from a linux package. the below command should be executed: ./configure --with-linux=/lib/modules/'uname -r '/build this is a linux command and i should execute the FreeBSD equivalent but i don't know how to do that. the manual says: To build the Linux kernel module, so that you can run the kernel-based switch, pass the location of the kernel build directory on --with-linux. what is kernel build directory in FreeBSD9 amd64? or how i should execute this command? yours, From owner-freebsd-net@FreeBSD.ORG Thu Apr 5 13:00:47 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E589A106566B for ; Thu, 5 Apr 2012 13:00:47 +0000 (UTC) (envelope-from rsb@berentweb.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4FEB98FC17 for ; Thu, 5 Apr 2012 13:00:46 +0000 (UTC) Received: by lbok6 with SMTP id k6so12337lbo.13 for ; Thu, 05 Apr 2012 06:00:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=berentweb.com; s=google; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=QhoyrKTTodkZF+eD3+WVjsjtw0GohXlfc8UabNgv9Q0=; b=Z9CcI12QguasdD7VZ0wUIxwqzyCkmKJqSV6JPuDacPm2+y+Xt0buYq5uw4TtblXI+P pJjg2wVl2JblvH2F4agRsK+qSqiZnF691ySVtj5yN0Ztk7ha38axvgCyCTvt4JpVCmWE NDO7StQC45AIScJJKASYN9vzn7SZc69nHlWnY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :x-gm-message-state; bh=QhoyrKTTodkZF+eD3+WVjsjtw0GohXlfc8UabNgv9Q0=; b=lSVKn1s+iXlKo7twHaQ9k/4cYYs6AK9nRqk575U0URTo71vUWmiFUmu6w+L1yYdR8Z Owg1spX9XaV4gf1YshejhSj0fKUQpJBKLFsQW2A12dOuLYloBzd8czgOANBBHDNuo/2C t8gcq07IoDLLlBVaNFfqjGisXrhOB1UtU3rs8W4bldi1VlMPfrluOednREA4K+hY4j9d FI3nKgQm65XeOR3W2L1nz8ei8i8uursO5ca9rWlSTIJhXVPvb46cWwEmRzQJa3f4jMKT IkmGXW5f7Cw/5z4A8sTz0kZU9/DXKp7cEC+7jQVCaNw37NKvv6cihJ5+oPQ3/jQHNG12 nnUw== MIME-Version: 1.0 Received: by 10.152.110.116 with SMTP id hz20mr2764921lab.33.1333630387456; Thu, 05 Apr 2012 05:53:07 -0700 (PDT) Sender: rsb@berentweb.com Received: by 10.112.77.15 with HTTP; Thu, 5 Apr 2012 05:53:07 -0700 (PDT) X-Originating-IP: [85.110.138.250] In-Reply-To: References: <20120329072054.GA45082@server.vk2pj.dyndns.org> <20120403074954.GA19241@server.vk2pj.dyndns.org> Date: Thu, 5 Apr 2012 15:53:07 +0300 X-Google-Sender-Auth: KgC-Rryq3Cwm_h3Labxp_tYbHMw Message-ID: From: Beeblebrox To: freebsd-net@freebsd.org X-Gm-Message-State: ALoCoQlgavE2u2kqWjS4p9fYzcha0Xc2xeQk3DBVAi9cPpOVV4HkU4deBDrSzypq2W2m3I6yiduu Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: lagg problems on diskless 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: Thu, 05 Apr 2012 13:00:48 -0000 Since jail/etc/rc.d/lagg results in an error message "cannot change re0" and results in a system freeze on the DC, I tried the following in jail/etc/rc.conf: ifconfig_lagg0="up laggproto failover laggport re1 laggport re0 192.168.2.2 netmask 255.255.255.0" Resulting messages on the DC before freezing: re1: link state changed to down lagg0: 2 link states coalesced lagg0: link state changed to up re1: link state changed to up From owner-freebsd-net@FreeBSD.ORG Thu Apr 5 16:32:28 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A822E106566C for ; Thu, 5 Apr 2012 16:32:28 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4F8378FC16 for ; Thu, 5 Apr 2012 16:32:28 +0000 (UTC) Received: by iahk25 with SMTP id k25so2684669iah.13 for ; Thu, 05 Apr 2012 09:32:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=g6I1utq/xO1EbDSsn7kpNLdMLuZTZFs1qLbPHzvBdIk=; b=HEkFkKdYnfUxviKt+0QVb2rgiweb+pvXF8KtCbJv2MbXumT2KX10Qka+NW0iED3kS6 D1bQGhal8EBdVVG3NfIf5Xfnel/1mxHt5Q5oQevNh+5nP2Swfk+XzMXXtNsm3qzJpCE/ eiDWZgXdMfwuv6W+onVZYUmHrSLPrGsSCexL4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-gm-message-state; bh=g6I1utq/xO1EbDSsn7kpNLdMLuZTZFs1qLbPHzvBdIk=; b=LmQfRcoSbscYUjOxFOxkXWcrwlH/j1bN1Li3gmkdixzdxvC6iOmvwON0pgklX7ItIY B10iTcozd7AHjYqnYFi1akjqtS2ifoXZB92InSMOGmOAHNbcBpXzCgX/C950u/R4oiJb QzTZV7To4wM/5srj6qp35oZe1w37CGRn9V78rRnQBpyoaM9AGy1Wv0ZKNkzqkX/CsFy/ CtITNWhzS3lxEwXA7eCM9Lz/11jJeXrrZndhwfBVDKPpvhVefCRMFgIVYi3rmcpral0M EsoOMX9t1DdUcNMOMxCgvnc9YXmdrdFPgoaR8iX9gGJtRky7HIREOSLwSZTHXay14k6Q Q2dQ== Received: by 10.50.183.193 with SMTP id eo1mr2647126igc.20.1333643547319; Thu, 05 Apr 2012 09:32:27 -0700 (PDT) Received: from DataIX.net ([99.109.124.46]) by mx.google.com with ESMTPS id hq3sm17789311igc.0.2012.04.05.09.32.26 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Apr 2012 09:32:26 -0700 (PDT) Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q35GWNvX078898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Apr 2012 12:32:23 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Received: (from jhellenthal@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q35GWMQa074952; Thu, 5 Apr 2012 12:32:22 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Date: Thu, 5 Apr 2012 12:32:22 -0400 From: Jason Hellenthal To: saeedeh motlagh Message-ID: <20120405163222.GA13978@DataIX.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Gm-Message-State: ALoCoQmmcG10Fj5wLxfStgfNNYN1XrDLLUPREj9JWzGRloP9HoP46HqcrDN6A5ct8G2HzepVSpoY Cc: freebsd-net , freebsd-questions@freebsd.org Subject: Re: what is the path of kernel build directory? 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, 05 Apr 2012 16:32:28 -0000 /usr/obj/usr/src/sys// The handbook has a very clear section on this. Good luck. On Thu, Apr 05, 2012 at 12:21:18AM -0700, saeedeh motlagh wrote: > hello guys > i want to install the openvswitch 1.4.0 from a linux package. the below > command should be executed: > ./configure --with-linux=/lib/modules/'uname -r '/build > this is a linux command and i should execute the FreeBSD equivalent but i > don't know how to do that. the manual says: > > To build the Linux kernel module, so that you can run the > kernel-based switch, pass the location of the kernel build > directory on --with-linux. > > what is kernel build directory in FreeBSD9 amd64? or how i should execute > this command? > > yours, > _______________________________________________ > 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" -- ;s =; From owner-freebsd-net@FreeBSD.ORG Thu Apr 5 16:38:16 2012 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 1EA7D1065670; Thu, 5 Apr 2012 16:38:16 +0000 (UTC) (envelope-from bonomi@mail.r-bonomi.com) Received: from mail.r-bonomi.com (mx-out.r-bonomi.com [204.87.227.120]) by mx1.freebsd.org (Postfix) with ESMTP id C912B8FC0A; Thu, 5 Apr 2012 16:38:15 +0000 (UTC) Received: (from bonomi@localhost) by mail.r-bonomi.com (8.14.4/rdb1) id q35GdFO0043980; Thu, 5 Apr 2012 11:39:15 -0500 (CDT) Date: Thu, 5 Apr 2012 11:39:15 -0500 (CDT) From: Robert Bonomi Message-Id: <201204051639.q35GdFO0043980@mail.r-bonomi.com> To: freebsd-net@freebsd.org, freebsd-questions@freebsd.org, saeedeh.motlagh@gmail.com In-Reply-To: Cc: Subject: Re: what is the path of kernel build directory? 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, 05 Apr 2012 16:38:16 -0000 saeedeh motlagh wrote: > > hello guys > i want to install the openvswitch 1.4.0 from a linux package. the below > command should be executed: > ./configure --with-linux=/lib/modules/'uname -r '/build > this is a linux command and i should execute the FreeBSD equivalent but i > don't know how to do that. the manual says: > > To build the Linux kernel module, so that you can run the > kernel-based switch, pass the location of the kernel build > directory on --with-linux. > > what is kernel build directory in FreeBSD9 amd64? or how i should execute > this command? If you have to ask, you should *NOT* attempt to build this kernel module on FreeBSD. The kernel, kernel interfaes, etc. are *DIFFERENT* between Linux and FreeBSD. signficicant sourte-code changes will VERY PROBABLY be require to get the module to (a) compile, and (b) run, in a FreeBSD environment. To do _that_ -- modifying the sources -- 'where the build directory is' is a very _minor_ incidental piece of knowlege. If you don't have that incidental knowledge, is is virtually certain, you don't have the skill set to do the required source modifications. Executive summary -- this is a DDT issue. DDT ==> on't o hat!! From owner-freebsd-net@FreeBSD.ORG Thu Apr 5 18:36:41 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 87AF61065675 for ; Thu, 5 Apr 2012 18:36:41 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 2E6B88FC1B for ; Thu, 5 Apr 2012 18:36:41 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SFrXu-0000nX-EE for freebsd-net@freebsd.org; Thu, 05 Apr 2012 20:36:34 +0200 Received: from pool-108-35-132-213.nwrknj.fios.verizon.net ([108.35.132.213]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 05 Apr 2012 20:36:34 +0200 Received: from ixew by pool-108-35-132-213.nwrknj.fios.verizon.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 05 Apr 2012 20:36:34 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: enoch Date: Thu, 05 Apr 2012 14:36:12 -0400 Lines: 157 Message-ID: <87iphejaar.fsf@hotmail.com> References: <20120402195215.GA3571@michelle.cdnetworks.com> <20120403023225.GD3571@michelle.cdnetworks.com> <87ty11670b.fsf@hotmail.com> <20120403183521.GA7380@michelle.cdnetworks.com> <87obr95pxh.fsf@hotmail.com> <20120403225422.GB7380@michelle.cdnetworks.com> <87sjgk5czo.fsf@hotmail.com> <20120404210445.GB10911@michelle.cdnetworks.com> <87vclfwqp4.fsf@hotmail.com> <20120405161152.GA14289@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: pool-108-35-132-213.nwrknj.fios.verizon.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.93 (berkeley-unix) Cancel-Lock: sha1:6+iSZ3pWtdJCg8cjA/EEsMOyA4Q= Subject: Re: [nfe] DHCP failure on 8-stable 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, 05 Apr 2012 18:36:41 -0000 YongHyeon PYUN writes: > On Wed, Apr 04, 2012 at 09:51:19AM -0400, enoch wrote: >> YongHyeon PYUN writes: >> >> > On Wed, Apr 04, 2012 at 12:37:15AM -0400, enoch wrote: >> >> YongHyeon PYUN writes: >> >> >> >> > On Tue, Apr 03, 2012 at 01:45:30AM -0400, enoch wrote: >> >> >> YongHyeon PYUN writes: >> >> >> >> >> >> > On Mon, Apr 02, 2012 at 07:36:36PM -0400, enoch wrote: >> >> >> >> YongHyeon PYUN writes: >> >> >> >> >> >> >> >> > On Mon, Apr 02, 2012 at 03:50:02AM -0400, enoch wrote: >> >> >> >> >> On 04/02/2012 03:52 PM, YongHyeon PYUN wrote: >> >> >> >> >> > On Fri, Mar 30, 2012 at 10:40:44AM -0400, enoch wrote: >> >> >> >> >> >> On 03/30/2012 19:38, YongHyeon PYUN wrote: >> >> >> >> >> >>> On Fri, Mar 30, 2012 at 03:01:52AM -0400, enoch wrote: >> >> >> >> >> >>>> Recently it became extremely difficult to pass the DHCP discovery step >> >> >> >> >> >>>> on boot. Now I am using the buggy [nve] instead. >> >> >> >> >> >>>> >> >> >> >> >> >>>> Can anyone help? >> >> >> >> >> >>>> >> >> >> >> >> >>> >> >> >> >> >> >>> Did you set synchronous_dhclient option in rc.conf? >> >> >> >> >> >>> >> >> >> >> >> >> >> >> >> >> >> >> Yes: ifconfig_nfe0="SYNCDHCP" >> >> >> >> >> >> >> >> >> >> >> >> I guess [nfe] is undergoing gradual devel changes of some sort as before >> >> >> >> >> >> it had some chance of reporting "empty headers" on initial ifconfig and >> >> >> >> >> >> refusing to work. Sorry, I should have reported when encountering the >> >> >> >> >> >> first problems rather than solve by reboot. >> >> >> >> >> > >> >> >> >> >> > Would you show me the output of both dmesg(nfe(4) and its PHY only) >> >> >> >> >> > and 'sysctl dev.nfe.0.stats'? >> >> >> >> >> > It would be also helpful to know whether nfe(4) still sees >> >> >> >> >> > incoming traffic. >> >> >> >> >> > Does assigning static IP work? >> >> >> >> >> > >> >> >> >> >> >> >> >> >> >> Static IP direct communication attempt from this desktop to another >> >> >> >> >> laptop through a crossover cable fails as follows. Thanks. >> >> >> >> >> >> >> >> >> >> nfe0: flags=8843 metric 0 mtu 1500 >> >> >> >> >> options=82008 >> >> >> >> >> ether 00:1f:bc:00:19:dc >> >> >> >> >> inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 >> >> >> >> >> media: Ethernet autoselect (1000baseT >> >> >> >> >> ) >> >> >> >> >> status: active >> >> >> >> >> >> >> >> >> >> nfe0: link state changed to UP >> >> >> >> >> nfe0: port 0xf200-0xf207 >> >> >> >> >> mem 0xefffb000-0xefffbfff irq 21 at device 20.0 on pci0 >> >> >> >> >> miibus1: on nfe0 >> >> >> >> > >> >> >> >> > It seems you've omitted PHY driver here. What PHY driver was >> >> >> >> > attached to nfe(4)? >> >> >> >> > >> >> >> >> >> >> >> >> miibus1: on nfe0 >> >> >> >> rgephy1: PHY 1 on miibus1 >> >> >> >> >> >> >> >> >> nfe0: Ethernet address: 00:1f:bc:00:19:dc >> >> >> >> >> nfe0: [FILTER] >> >> >> >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) >> >> >> >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) >> >> >> >> >> nfe0: link state changed to UP >> >> >> >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) >> >> >> >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) >> >> >> >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) >> >> >> >> >> >> >> >> >> >> dev.nfe.0.stats.rx.frame_errors: 0 >> >> >> >> >> dev.nfe.0.stats.rx.extra_bytes: 0 >> >> >> >> >> dev.nfe.0.stats.rx.late_cols: 0 >> >> >> >> >> dev.nfe.0.stats.rx.runts: 0 >> >> >> >> >> dev.nfe.0.stats.rx.jumbos: 0 >> >> >> >> >> dev.nfe.0.stats.rx.fifo_overuns: 0 >> >> >> >> >> dev.nfe.0.stats.rx.crc_errors: 0 >> >> >> >> >> dev.nfe.0.stats.rx.fae: 0 >> >> >> >> >> dev.nfe.0.stats.rx.len_errors: 0 >> >> >> >> >> dev.nfe.0.stats.rx.unicast: 56 >> >> >> >> >> dev.nfe.0.stats.rx.multicast: 0 >> >> >> >> >> dev.nfe.0.stats.rx.broadcast: 280 >> >> >> >> >> dev.nfe.0.stats.tx.octets: 7517 >> >> >> >> >> dev.nfe.0.stats.tx.zero_rexmits: 51 >> >> >> >> >> dev.nfe.0.stats.tx.one_rexmits: 0 >> >> >> >> >> dev.nfe.0.stats.tx.multi_rexmits: 0 >> >> >> >> >> dev.nfe.0.stats.tx.late_cols: 0 >> >> >> >> >> dev.nfe.0.stats.tx.fifo_underuns: 0 >> >> >> >> >> dev.nfe.0.stats.tx.carrier_losts: 0 >> >> >> >> >> dev.nfe.0.stats.tx.excess_deferrals: 0 >> >> >> >> >> dev.nfe.0.stats.tx.retry_errors: 0 >> >> >> >> >> >> >> >> >> > >> >> >> >> > Thanks. Would you show me the output of "pciconf -lcbv"? >> >> >> >> > >> >> >> >> >> >> >> >> nfe0@pci0:0:20:0: class=0x068000 card=0x10003842 chip=0x026910de rev=0xa3 hdr=0x00 >> >> >> >> vendor = 'NVIDIA Corporation' >> >> >> >> device = 'MCP51 Network Bus Enumerator' >> >> >> >> class = bridge >> >> >> >> bar [10] = type Memory, range 32, base 0xefffb000, size 4096, enabled >> >> >> >> bar [14] = type I/O Port, range 32, base 0xf200, size 8, enabled >> >> >> >> cap 01[44] = powerspec 2 supports D0 D1 D2 D3 current D0 >> >> >> >> >> >> >> >> Interestingly, now that nfe0 is using a static IP it sometimes boots >> >> >> >> up properly. Are you interested in its good working? >> >> >> > >> >> >> > Yes I am. Would you try attached patch and let me know whether the >> >> >> > patch makes any difference on your box? >> >> >> >> >> >> Sorry to report: The patch was applied (to 8-stable latest code) but out >> >> >> of 3 boots only one succeeded. Same stream of "nfe0: discard frame w/o >> >> >> leading ethernet header (len 0 pkt len 0)" messages. >> >> > >> >> > Ok, back out previous patch and try attached one. >> >> >> >> With these two patch files applied to the 8-stable code, buildkernel >> >> fails as follows. >> >> >> >> /usr/src/sys/modules/nfe/../../dev/nfe/if_nfe.c: In function 'nfe_attach': >> >> /usr/src/sys/modules/nfe/../../dev/nfe/if_nfe.c:629: error: 'struct mii_softc' has no member named 'mii_mpd_oui' >> >> /usr/src/sys/modules/nfe/../../dev/nfe/if_nfe.c:629: error: 'struct mii_softc' has no member named 'mii_mpd_oui' >> >> /usr/src/sys/modules/nfe/../../dev/nfe/if_nfe.c:630: error: 'struct mii_softc' has no member named 'mii_mpd_model' >> >> *** Error code 1 >> >> >> > >> > Oops, sorry I forgot that this part of change was not merged to >> > stable/8. I've attached a minimal patch which would be cleanly >> > applied to stable/8. >> >> Wasn't the attached diff3 already included in diff2? Seems to me the >> wrong file was attached this time. Please advise. > > diff2 is subset of diff3 but it can be merged to stable/8 and > stable/7. Probably diff2 may have better chance to fully > reinitialize PHY but let's see whether diff3 also makes difference > on your box. > So back out any changes and apply diff3. I'm sorry, this if_nfereg.h patch is not enough. Boot failure frequency is just the same. I guess I should consider migrating to 9-stable. The problem with 9-stable is that most of the time it does not build :-( Thanks for your efforts. Enoch. > >> >> > >> >> Sorry, I can't handle 9-stable. Enoch. > _______________________________________________ > 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 Thu Apr 5 18:47:54 2012 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 092C21065670 for ; Thu, 5 Apr 2012 18:47:54 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id D7C3B8FC22 for ; Thu, 5 Apr 2012 18:47:53 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 52D55B96C for ; Thu, 5 Apr 2012 14:47:53 -0400 (EDT) From: John Baldwin To: net@freebsd.org Date: Thu, 5 Apr 2012 14:47:52 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201204051447.52619.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 05 Apr 2012 14:47:53 -0400 (EDT) Cc: Subject: [PATCH] Add 40g media types 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, 05 Apr 2012 18:47:54 -0000 The patch below adds 40G media types for what I think are the "common" media types we would see on FreeBSD (could be wrong). One caveat though, we are running awfully low on bits now, and we don't have enough room for the 100G media types after this. Not sure what we want to do about that. :( Index: net/if_media.h =================================================================== --- net/if_media.h (revision 233872) +++ net/if_media.h (working copy) @@ -150,6 +150,9 @@ #define IFM_10G_LRM 24 /* 10GBase-LRM 850nm Multi-mode */ #define IFM_UNKNOWN 25 /* media types not defined yet */ #define IFM_10G_T 26 /* 10GBase-T - RJ45 */ +#define IFM_40G_CR4 27 /* 40GBase-CR4 */ +#define IFM_40G_SR4 28 /* 40GBase-SR4 */ +#define IFM_40G_LR4 29 /* 40GBase-LR4 */ /* note 31 is the max! */ @@ -360,6 +363,9 @@ { IFM_10G_TWINAX_LONG, "10Gbase-Twinax-Long" }, \ { IFM_UNKNOWN, "Unknown" }, \ { IFM_10G_T, "10Gbase-T" }, \ + { IFM_40G_CR4, "40Gbase-CR4" }, \ + { IFM_40G_SR4, "40Gbase-SR4" }, \ + { IFM_40G_LR4, "40Gbase-LR4" }, \ { 0, NULL }, \ } @@ -658,6 +664,9 @@ { IFM_ETHER | IFM_10G_TWINAX_LONG, IF_Gbps(10ULL) }, \ { IFM_ETHER | IFM_10G_LRM, IF_Gbps(10ULL) }, \ { IFM_ETHER | IFM_10G_T, IF_Gbps(10ULL) }, \ + { IFM_ETHER | IFM_40G_CR4, IF_Gbps(40ULL) }, \ + { IFM_ETHER | IFM_40G_SR4, IF_Gbps(40ULL) }, \ + { IFM_ETHER | IFM_40G_LR4, IF_Gbps(40ULL) }, \ \ { IFM_TOKEN | IFM_TOK_STP4, IF_Mbps(4) }, \ { IFM_TOKEN | IFM_TOK_STP16, IF_Mbps(16) }, \ -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Thu Apr 5 21:47:16 2012 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 C11A3106564A; Thu, 5 Apr 2012 21:47:16 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 4C2EF8FC12; Thu, 5 Apr 2012 21:47:16 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 3D83425D3860; Thu, 5 Apr 2012 21:47:15 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 35907BE4371; Thu, 5 Apr 2012 21:47:14 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id fyUkQbs8PKYh; Thu, 5 Apr 2012 21:47:12 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id BB280BE4370; Thu, 5 Apr 2012 21:47:12 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <201204051447.52619.jhb@freebsd.org> Date: Thu, 5 Apr 2012 21:47:11 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201204051447.52619.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1084) Cc: net@freebsd.org Subject: Re: [PATCH] Add 40g media types 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, 05 Apr 2012 21:47:16 -0000 On 5. Apr 2012, at 18:47 , John Baldwin wrote: Hi, > The patch below adds 40G media types for what I think are the "common" = media=20 > types we would see on FreeBSD (could be wrong). One caveat though, = we are=20 > running awfully low on bits now, and we don't have enough room for the = 100G=20 > media types after this. Not sure what we want to do about that. :( Can't you also see a bright future for FDDI and Token Ring and the bling = of a Danish axe? Yeah, seems another experiment has proven to be going = better than expected a couple of decades ago. At this point I'd hope someone would get out the right MIB and tell us = here's the right thing to do... 100 will at least need 4 more bits, so you could as well fill the bits = also adding KR4 and FR for 40 or will have to face the problem with 400 = latest. /bz > Index: net/if_media.h > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- net/if_media.h (revision 233872) > +++ net/if_media.h (working copy) > @@ -150,6 +150,9 @@ > #define IFM_10G_LRM 24 /* 10GBase-LRM 850nm = Multi-mode */ > #define IFM_UNKNOWN 25 /* media types not = defined yet */ > #define IFM_10G_T 26 /* 10GBase-T - RJ45 */ > +#define IFM_40G_CR4 27 /* 40GBase-CR4 */ > +#define IFM_40G_SR4 28 /* 40GBase-SR4 */ > +#define IFM_40G_LR4 29 /* 40GBase-LR4 */ >=20 > /* note 31 is the max! */ >=20 > @@ -360,6 +363,9 @@ > { IFM_10G_TWINAX_LONG, "10Gbase-Twinax-Long" }, = \ > { IFM_UNKNOWN, "Unknown" }, = \ > { IFM_10G_T, "10Gbase-T" }, = \ > + { IFM_40G_CR4, "40Gbase-CR4" }, = \ > + { IFM_40G_SR4, "40Gbase-SR4" }, = \ > + { IFM_40G_LR4, "40Gbase-LR4" }, = \ > { 0, NULL }, = \ > } >=20 > @@ -658,6 +664,9 @@ > { IFM_ETHER | IFM_10G_TWINAX_LONG, IF_Gbps(10ULL) }, = \ > { IFM_ETHER | IFM_10G_LRM, IF_Gbps(10ULL) }, = \ > { IFM_ETHER | IFM_10G_T, IF_Gbps(10ULL) }, = \ > + { IFM_ETHER | IFM_40G_CR4, IF_Gbps(40ULL) }, = \ > + { IFM_ETHER | IFM_40G_SR4, IF_Gbps(40ULL) }, = \ > + { IFM_ETHER | IFM_40G_LR4, IF_Gbps(40ULL) }, = \ > = \ > { IFM_TOKEN | IFM_TOK_STP4, IF_Mbps(4) }, = \ > { IFM_TOKEN | IFM_TOK_STP16, IF_Mbps(16) }, = \ >=20 > --=20 > John Baldwin > _______________________________________________ > 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 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-net@FreeBSD.ORG Fri Apr 6 08:08:55 2012 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 7505C1065675 for ; Fri, 6 Apr 2012 08:08:55 +0000 (UTC) (envelope-from rsb@berentweb.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id D31BF8FC0C for ; Fri, 6 Apr 2012 08:08:54 +0000 (UTC) Received: by lagv3 with SMTP id v3so3043414lag.13 for ; Fri, 06 Apr 2012 01:08:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=berentweb.com; s=google; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=WI44mP7z3jCRNBTv+TDJxbCbH0xUXREg0/xHdA5Xgbs=; b=PVI9fve8yp7AVeU/zF306ihoiB4oEP4ylVRCxiA71IpMOa+4wNHq9L7vW/eMphOSd9 hQNrPAE1NFXAyZPfjlF6h0B4+9OSPU5HDYHIiLGZigiJJgdTiESGJ7hEHt2I9Vu33i4S e2K7gqRMT6LX34yMW2bpRz14oliaKhiSwVCrA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :x-gm-message-state; bh=WI44mP7z3jCRNBTv+TDJxbCbH0xUXREg0/xHdA5Xgbs=; b=ipUlUi6Ostmdfd8Fyqks+KoeqmHEF6TgYEXpt/PnxWJiSLKyczceY0Y+O85gf+iVRw JquX0it6hA+ik+QNfRZnpFJ8vytdNrWcODSAxw7R8WSg4PveHSlxGdINP2Ue5Y7fBud+ R1JvV0cSWHn2F5GgD2rWuYJxPRShXrUdmRZHGqswdT6CmyxOD2oGQYFqEp6eTXWrLnVA KNJoSyUjli/aW4UgY4U0nBgNjcpAz/3eMSImsJ4W3nhCZFrvFdwR/sSJtVPbD9wNufZV mliCTo/aqoAjUTmQecyooO7NrFkn8unl0C1/itZexNWpt9+kKlSPf1Qw6SiY7d+4j7nc GBAA== MIME-Version: 1.0 Received: by 10.152.111.161 with SMTP id ij1mr7324345lab.19.1333699727514; Fri, 06 Apr 2012 01:08:47 -0700 (PDT) Sender: rsb@berentweb.com Received: by 10.112.77.15 with HTTP; Fri, 6 Apr 2012 01:08:47 -0700 (PDT) X-Originating-IP: [85.110.138.250] In-Reply-To: References: <20120329072054.GA45082@server.vk2pj.dyndns.org> <20120403074954.GA19241@server.vk2pj.dyndns.org> Date: Fri, 6 Apr 2012 11:08:47 +0300 X-Google-Sender-Auth: oaWV0oyXp0taOofHkU0w9jiGafU Message-ID: From: Beeblebrox To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQl2VjHyH8ZcLUlAmHpHjLVUUjkP7gfhfixJTg/PNhfZ2gYPK6rr7NAuQ8vYdi6fmI1mnRBx Subject: Re: lagg problems on diskless 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: Fri, 06 Apr 2012 08:08:55 -0000 In a previous mail re this problem, Adrian Chadd had asked: What's the routing table and ifconfig output look like? It sounds like you're creating the interface and moving things over without: * deleting the route/IP table entry; * create the lagg; * adding the interfaces to the lagg, including the one you booted off of; * assigning the correct IP and readding the default route. In answer, info for the DC is below. This is the situation with the rc.d/lagg script disabled and below line in jail/etc/rc.conf commented out. Anything I do with lagg after this point freezes the system ifconfig_lagg0="up laggproto failover laggport re1 laggport re0 192.168.2.2 netmask 255.255.255.0" ROUTE TABLE: Destination Gateway Flags Refs Use Netif Expire default 192.168.2.1 UG 0 0 re0 127.0.0.1 link#3 UH 0 0 lo0 192.168.2.0/24 link#1 U 2 7653 re0 192.168.2.2 link#1 UHS 0 0 lo0 IFCONFIG re0: flags=8843 metric 0 mtu 1500 options=82008 ether 00:30:67:91:6c:c2 inet 192.168.2.2 netmask 0xffffff00 broadcast 192.168.2.255 media: Ethernet autoselect (100baseTX ) status: active re1: flags=8843 metric 0 mtu 1500 options=8209b ether 00:30:67:91:6c:c2 media: Ethernet autoselect (1000baseT ) status: active lo0: flags=8049 metric 0 mtu 16384 options=3 inet 127.0.0.1 netmask 0xff000000 lagg0: flags=8843 metric 0 mtu 1500 ether 00:30:67:91:6c:c2 media: Ethernet autoselect status: no carrier laggproto failover From owner-freebsd-net@FreeBSD.ORG Fri Apr 6 11:20:38 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AAA1E106566C for ; Fri, 6 Apr 2012 11:20:38 +0000 (UTC) (envelope-from seth.mos@dds.nl) Received: from rotring.dds.nl (rotring.dds.nl [85.17.178.138]) by mx1.freebsd.org (Postfix) with ESMTP id 63AD88FC0C for ; Fri, 6 Apr 2012 11:20:38 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by rotring.dds.nl (Postfix) with ESMTP id 0EEDE58BB5 for ; Fri, 6 Apr 2012 13:20:31 +0200 (CEST) Received: from [10.0.2.53] (edge-pf.coltex.nl [91.227.27.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rotring.dds.nl (Postfix) with ESMTPSA id 479E95879E for ; Fri, 6 Apr 2012 13:20:26 +0200 (CEST) Message-ID: <4F7ED1C1.7050903@dds.nl> Date: Fri, 06 Apr 2012 13:21:37 +0200 From: Seth Mos User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4F74755A.2040308@dds.nl> <4F794D1A.7020307@dds.nl> In-Reply-To: <4F794D1A.7020307@dds.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.3 at rotring X-Virus-Status: Clean Subject: Re: 6rd status 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, 06 Apr 2012 11:20:38 -0000 Op 2-4-2012 8:54, Seth Mos schreef: > Op 29-3-2012 16:44, Seth Mos schreef: >> Hi, >> > Only to reply to myself here, I've not seen response yet. Replying to myself again. I confirm that the 6rd patch to stf from hrs@ indeed works as advertised. The Charter and Sakura 6rd relays do not employ filtering which means these can be used from everywhere in the world. Sakura is about 500ms and Charter about 200ms from where I tested which limits the usability. One that thing that must be noted is that the patch does not support RFC5969 Standards track support 6rd. This uses a variable length for both the 6rd prefix and the v4 prefix length as long as it fits in the left 64 bits. From the RFC. http://tools.ietf.org/html/rfc5969 | n bits | o bits | m bits | 128-n-o-m bits | +---------------+--------------+-----------+------------------------+ | 6rd prefix | IPv4 address | subnet ID | interface ID | +---------------+--------------+-----------+------------------------+ |<--- 6rd delegated prefix --->| There is a dutch ISP rolling out with a 6rd prefix of 41 bits and a IPv4 prefix length of 17 bits resulting in a /56 delegated prefix for each user. (41 + (32 - 17)) = 56 The current 6rd patch does not provide such a facility from my limited testing. Theoretically it might work providing the IPv6 prefix and gateway are calculated with that math in mind. But I don't have the network to confirm this. This might be easy to support. Regards, Seth From owner-freebsd-net@FreeBSD.ORG Fri Apr 6 22:37:24 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D1DEF106566B for ; Fri, 6 Apr 2012 22:37:24 +0000 (UTC) (envelope-from rsb@berentweb.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 405288FC17 for ; Fri, 6 Apr 2012 22:37:24 +0000 (UTC) Received: by lagv3 with SMTP id v3so3541276lag.13 for ; Fri, 06 Apr 2012 15:37:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=berentweb.com; s=google; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=UEQwbsY1VB/5TJDJSVt57cn+7S961Pk9SB6/FGPoFJM=; b=P80J0kO8Jjb0STqsQYlgW1HSEc63Xwkk2QHPSUFqqBOp8/OVNbviKl1YkgJDvIih0N lgBpm18YUDr39ILFsM8iw8Ch/nt3OYmifWy7j/6ez13KzNjQcl+yoEWd94dUIwn1x12i 8Ji4RSCNx+s2MpnmMXYB6k1wAXACjWb4JVeE4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :x-gm-message-state; bh=UEQwbsY1VB/5TJDJSVt57cn+7S961Pk9SB6/FGPoFJM=; b=FxJRXTrmAGm2rsAN47jvjozpXtW0DpILXpuKr/dpfobvviiSqvUfKk6BSp1sIqCF2k qXNVUUXbSWyWe9a6O82hrK9M4dE2G87Nu2FEUBPdclw5QvSmT1IO++1p6hYS8PihEoO1 2xUGT3UfjIyI85Qe4c97FVoH/KDrMupLcQ9kN4Ov71jR1E1PqV7aozpylAbzo8FyE2m4 eBuoNr1qG1peEKriTSgXplGaCWiUXJBmj9Lr9ZLCmWZb5OMg3zKG3Kky4L3oaCnEMcHr MhxVHO8yHxF7AMAc/kCrKgVNsLUie4u6YbBNi8UpLR+stAWVrZT+SzibMjWC3tbXnpGG 4/kA== MIME-Version: 1.0 Received: by 10.152.132.132 with SMTP id ou4mr10951822lab.26.1333751842918; Fri, 06 Apr 2012 15:37:22 -0700 (PDT) Sender: rsb@berentweb.com Received: by 10.112.100.225 with HTTP; Fri, 6 Apr 2012 15:37:22 -0700 (PDT) X-Originating-IP: [85.110.138.250] In-Reply-To: References: <20120329072054.GA45082@server.vk2pj.dyndns.org> <20120403074954.GA19241@server.vk2pj.dyndns.org> Date: Sat, 7 Apr 2012 01:37:22 +0300 X-Google-Sender-Auth: PDkj9f6q4tYmXR5wNAk69xlwQhk Message-ID: From: Beeblebrox To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnEinaq94AoeRkqB6R+dKztIeBrd/HHm4lt0rowv0qdQzuPo5No/Uuf1D22rQdv6GCFCsVB Subject: Re: lagg problems on diskless 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: Fri, 06 Apr 2012 22:37:24 -0000 @Peter: My DC nodes already mount /tmp as tmpfs (a ramdisk). I have hence modified the script and defined lagg_tmp:=/tmp/mnt and added the line mkdir "$lagg_tmp" before the md creation. lagg still breaks, so I commented out the lines following "Actually flip the interface". Checking the DC status shows that /rescue contents have been copied to /tmp/mnt, so the script has worked up to that point. When I manually try cd /tmp/mnt && ./ifconfig re0 delete, I get the familiar "cannot delete re0" message. Regards. From owner-freebsd-net@FreeBSD.ORG Fri Apr 6 22:47:55 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 31E18106564A for ; Fri, 6 Apr 2012 22:47:54 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx1.freebsd.org (Postfix) with ESMTP id B3C1E8FC0C for ; Fri, 6 Apr 2012 22:47:54 +0000 (UTC) Received: by dadz14 with SMTP id z14so11014204dad.17 for ; Fri, 06 Apr 2012 15:47:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=2XRzjarjyYGVlX92qLJiIxa4lEUQ0BUXkA5lbkexkKU=; b=ulzlZW9Pq3wCspwaqc+LvRC0Q4wnIn013DDOg9ZSqe8D8xayZIgZv0hiHxPneAFoLQ irju1B72Oep6YkTMzQTw5WcnGCl4yfFSYPKfomrtRZD6k/RxLaz4rvkUbBbGOVOVXmKO YKrx6Z3nxmHjtWBIwsTe4EyB35mwj07gfYKq0kWdE0XJKw8CxzXhte7C5YuoqFS7sHr6 cTN3TY7DXKCECKvg9jJ6UwZ4mPEyVtNNaM1l4Vb89gOGCHb0mwh88CLLL+NU8gLKDwCL vJSYV6J9pqJ9Mjy2uh3ZIoSJ6ls9DssKCheYZ4RtB5zcXOM4kT2NpyA7N23oC/g0gaB9 gBvg== MIME-Version: 1.0 Received: by 10.68.203.4 with SMTP id km4mr18863155pbc.53.1333752474337; Fri, 06 Apr 2012 15:47:54 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.142.134.6 with HTTP; Fri, 6 Apr 2012 15:47:54 -0700 (PDT) In-Reply-To: References: <20120329072054.GA45082@server.vk2pj.dyndns.org> <20120403074954.GA19241@server.vk2pj.dyndns.org> Date: Fri, 6 Apr 2012 15:47:54 -0700 X-Google-Sender-Auth: uPTslZfTovdyznmbjIB0MZBjgpk Message-ID: From: Adrian Chadd To: Beeblebrox Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: lagg problems on diskless 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: Fri, 06 Apr 2012 22:47:55 -0000 Hi all, Note to doing anything on wifi: in STA mode, you can't (standards wise) send frames with a MAC that isn't yours. There's a conceptual fix for this - called "proxy-STA" - but noone's coded it up in net80211 and/or any driver. Adrian From owner-freebsd-net@FreeBSD.ORG Sat Apr 7 07:20:04 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2C96F106566B for ; Sat, 7 Apr 2012 07:20:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EBD718FC08 for ; Sat, 7 Apr 2012 07:20:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q377K37l051985 for ; Sat, 7 Apr 2012 07:20:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q377K3g8051984; Sat, 7 Apr 2012 07:20:03 GMT (envelope-from gnats) Date: Sat, 7 Apr 2012 07:20:03 GMT Message-Id: <201204070720.q377K3g8051984@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Maxim Ignatenko Cc: Subject: Re: kern/164490: [pfil] Incorrect IP checksum on pfil pass from ip_output() X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Maxim Ignatenko List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2012 07:20:04 -0000 The following reply was made to PR kern/164490; it has been noted by GNATS. From: Maxim Ignatenko To: bug-followup@freebsd.org Cc: Subject: Re: kern/164490: [pfil] Incorrect IP checksum on pfil pass from ip_output() Date: Sat, 7 Apr 2012 10:17:20 +0300 Method described in http://www.faqs.org/rfcs/rfc1624.html can be used to update checksum in ip_forward() after decreasing TTL. From owner-freebsd-net@FreeBSD.ORG Sat Apr 7 08:02:49 2012 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 DE9ED1065670 for ; Sat, 7 Apr 2012 08:02:48 +0000 (UTC) (envelope-from andy@fud.org.nz) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 57E868FC08 for ; Sat, 7 Apr 2012 08:02:48 +0000 (UTC) Received: by lbok6 with SMTP id k6so1424785lbo.13 for ; Sat, 07 Apr 2012 01:02:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=SR4Ic4RioPLVNS/VvTinqBt2iYPQgRoZV5q53l5pEU0=; b=gJNIRu3iz/bimlVcUq3lGR8OvrrI1U5bxMZ0iWjKWDnUez0RdYuWJSrwtNYXXzhmGr uGqXNNr/UFNVS0yKn586WCTgkOqNjbfSnWyzwG5jI89onkAFrOxYFHcDP3ThCCpByf8D jHDuTtu0KvcL/N2zfYRUdxlU1Bc3wicUt8nmlYVdpawQXa2FbVQduSy44wivwJkTF84L dzXpoDWPHJa951HGy6raNwP3UWt/+iuDiReTVUqbtS+/sx6NpKj3zQUuQJjrmlsu59To Gzlgd45qsSzGMdet0WgeGZigV83PJ2oKZ4ysCxdVjBG+w45uTnRxcOQD7fvpESX0C5Q+ GPLA== MIME-Version: 1.0 Received: by 10.152.129.69 with SMTP id nu5mr1180010lab.9.1333785767007; Sat, 07 Apr 2012 01:02:47 -0700 (PDT) Sender: andy@fud.org.nz Received: by 10.112.150.72 with HTTP; Sat, 7 Apr 2012 01:02:46 -0700 (PDT) In-Reply-To: <201204020835.00357.jhb@freebsd.org> References: <201204020835.00357.jhb@freebsd.org> Date: Sat, 7 Apr 2012 20:02:46 +1200 X-Google-Sender-Auth: sJflwS9OItCYhSofu7YOecKpRS4 Message-ID: From: Andrew Thompson To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnhE2haoxfj1PEtKdmnUBKb7YP64J97+uVLst7GV/89wI3cPOiTzz8c3Ge67Qy1olr9it3P Cc: freebsd-net@freebsd.org, Andrew Boyer Subject: Re: LACP kernel panics: /* unlocking is safe here */ 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, 07 Apr 2012 08:02:49 -0000 On 3 April 2012 00:35, John Baldwin wrote: > On Friday, March 30, 2012 6:04:24 pm Andrew Boyer wrote: >> While investigating a LACP issue, I turned on LACP_DEBUG on a debug kern= el. > In this configuration it's easy to panic the kernel - just run 'ifconfig = lagg0 > laggproto lacp' on a lagg that's already in LACP mode and receiving LACP > messages. >> >> The problem is that lagg_lacp_detach() drops the lagg wlock (with the > comment in the title), which allows incoming LACP messages to get through > lagg_input() while the structure is being destroyed in lacp_detach(). >> >> There's a very simple fix, but I don't know if it's the best way to fix = it. > Resetting the protocol before calling sc_detach causes any further incomi= ng > packets to be dropped until the lagg gets reconfigured. =A0Thoughts? > > This looks sensible. Changing the order also needs an additional check as LAGG_PROTO_NONE no longer means the detach is finished. If one ioctl sleeps then we may nullify all the pointers upon wake that have already been set by the other ioctl. Does this look ok? Index: if_lagg.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- if_lagg.c (revision 233252) +++ if_lagg.c (working copy) @@ -950,11 +950,11 @@ lagg_ioctl(struct ifnet *ifp, u_long cmd, caddr_t error =3D EPROTONOSUPPORT; break; } + LAGG_WLOCK(sc); if (sc->sc_proto !=3D LAGG_PROTO_NONE) { - LAGG_WLOCK(sc); + /* Reset protocol first in case detach unlocks */ + sc->sc_proto =3D LAGG_PROTO_NONE; error =3D sc->sc_detach(sc); - /* Reset protocol and pointers */ - sc->sc_proto =3D LAGG_PROTO_NONE; sc->sc_detach =3D NULL; sc->sc_start =3D NULL; sc->sc_input =3D NULL; @@ -966,8 +966,11 @@ lagg_ioctl(struct ifnet *ifp, u_long cmd, caddr_t sc->sc_lladdr =3D NULL; sc->sc_req =3D NULL; sc->sc_portreq =3D NULL; - LAGG_WUNLOCK(sc); + } else if (sc->sc_input !=3D NULL) { + /* Still detaching */ + error =3D EBUSY; } + LAGG_WUNLOCK(sc); if (error !=3D 0) break; for (int i =3D 0; i < (sizeof(lagg_protos) / From owner-freebsd-net@FreeBSD.ORG Sat Apr 7 10:18:55 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 079D31065670; Sat, 7 Apr 2012 10:18:55 +0000 (UTC) (envelope-from subbsd@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id B8C7D8FC15; Sat, 7 Apr 2012 10:18:54 +0000 (UTC) Received: by obbwc18 with SMTP id wc18so5295981obb.13 for ; Sat, 07 Apr 2012 03:18:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=EXl/j+brDjUjkI087dwsYmnmjrZ/4vA5iHwX0HGls6U=; b=L8WGW49qm4n+tsGIb5CKrscLmg2Hb/Wb2W97gcj1QGHyjc6FUbNsR10dG7xERCW1LP Qx+eG/ZE7e0do1JsHJNwFp0CXU+LBF2KrnUrlcyyGPAYcLf7Ir2SaBDEuheg6tZcEpef O5/vtc/DfnWIFcBqE70SS3NFjV0GjoPrpF6usU4fceazfIvaMx/oWkZSpzKBsNJpw7hH W7TMcOP/CFKHSH5jDYs+SqzpUljEbrNVKjlsGX9D9RcrPasTkcNkR+yRUnaNXtzg05rU JsiHm1+LTOmK4A9PRfkD0vEogZ7I2fy8XjWxbM3RZPO5RvDV6WKtohKLwLTFYENDualz 8rdg== MIME-Version: 1.0 Received: by 10.182.136.41 with SMTP id px9mr1295238obb.21.1333793934169; Sat, 07 Apr 2012 03:18:54 -0700 (PDT) Received: by 10.60.123.48 with HTTP; Sat, 7 Apr 2012 03:18:54 -0700 (PDT) Date: Sat, 7 Apr 2012 14:18:54 +0400 Message-ID: From: Subbsd To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: msk0: watchdog timeout in the HEAD 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, 07 Apr 2012 10:18:55 -0000 After updating kernel from 9-STABLE to 10-CURRENT (amd64) msk interfaces stop working with "watchdog timout" error. Watchdog arises at a traffic 100-300+ Kb, for example: make - C /usr/ports fetchindex (on the fresh boot) reaches 11-15% before watchdog coming pciconf -vl | grep -A4 ^msk mskc0@pci0:3:0:0: class=0x020000 card=0x84391043 chip=0x438111ab rev=0x11 hdr=0x00 vendor = 'Marvell Technology Group Ltd.' device = 'Yukon Optima 88E8059 [PCIe Gigabit Ethernet Controller with AVB]' class = network subclass = ethernet msk(4)-related tunables doesn't change behavior. svn://svn.freebsd.org/base/stable/9 works fine. What more can i give for diagnostics? From owner-freebsd-net@FreeBSD.ORG Sat Apr 7 13:37:22 2012 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 1087F106566C; Sat, 7 Apr 2012 13:37:22 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 71CE88FC0C; Sat, 7 Apr 2012 13:37:21 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q37DbFmZ011732; Sat, 7 Apr 2012 16:37:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q37DbFsC087667; Sat, 7 Apr 2012 16:37:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q37DbF6O087666; Sat, 7 Apr 2012 16:37:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 7 Apr 2012 16:37:15 +0300 From: Konstantin Belousov To: jfv@freebsd.org Message-ID: <20120407133715.GU2358@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tUz0VHt16N2FDcQT" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: jhb@freebsd.org, net@freebsd.org Subject: 82574L hangs (with r233708 e1000 driver). 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, 07 Apr 2012 13:37:22 -0000 --tUz0VHt16N2FDcQT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I bought Intel Atom motherboard DN2800MT, which has integrated if_em LOM, reported by pciconf as em0@pci0:1:0:0: class=3D0x020000 card=3D0x20128086 chip=3D0x10d38086 rev=3D= 0x00 hdr=3D0x00 82574L Gigabit Network Connection It seems that any non-trivial network activity on the interface causes reliable interface hang, which can be temporary cured by ifconfig down/up. This happens both with outdated stable/9 sys/dev/e1000 and with driver from HEAD merged into stable/9. I currently use the copy of dev/e1000 at rev. r233708. Disabling MSI-X makes the hand to occur slightly less often. I can reproduce the hang in approximately a minute by scp'ing large file from other machine to /dev/null on the DN2800MT. This makes the board completely unusable for me. The driver reports itself as em0: port 0x2000-0x201f mem 0x= c0400000-0xc041ffff,0xc0000000-0xc03fffff,0xc0420000-0xc0423fff irq 16 at d= evice 0.0 on pci1 em0: attempting to allocate 3 MSI-X vectors (5 supported) msi: routing MSI-X IRQ 258 to local APIC 0 vector 60 msi: routing MSI-X IRQ 259 to local APIC 0 vector 61 msi: routing MSI-X IRQ 260 to local APIC 0 vector 62 em0: using IRQs 258-260 for MSI-X em0: Using MSIX interrupts with 3 vectors em0: bpf attached em0: Ethernet address: 00:22:4d:7a:47:f6 em0: Link is up 1000 Mbps Full Duplex The board is connected to ProCurve switch, there is no link flaps. When hang occur, dmesg output of # sysctl dev.em.0.debug=3D1 dev.em.0.debug: Interface is RUNNING and ACTIVE em0: hw tdh =3D 357, hw tdt =3D 357 em0: hw rdh =3D 323, hw rdt =3D 273 em0: Tx Queue Status =3D 0 em0: TX descriptors avail =3D 1024 em0: Tx Descriptors avail failure =3D 0 em0: RX discarded packets =3D 0 em0: RX Next to Check =3D 274 em0: RX Next to Refresh =3D 273 and # sysctl dev.em.0 dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 7.3.2 dev.em.0.%driver: em dev.em.0.%location: slot=3D0 function=3D0 handle=3D\_SB_.PCI0.RP01.PXSX dev.em.0.%pnpinfo: vendor=3D0x8086 device=3D0x10d3 subvendor=3D0x8086 subde= vice=3D0x2012 class=3D0x020000 dev.em.0.%parent: pci1 dev.em.0.nvm: -1 dev.em.0.debug: -1 dev.em.0.fc: 3 dev.em.0.rx_int_delay: 0 dev.em.0.tx_int_delay: 66 dev.em.0.rx_abs_int_delay: 66 dev.em.0.tx_abs_int_delay: 66 dev.em.0.rx_processing_limit: 100 dev.em.0.eee_control: 0 dev.em.0.link_irq: 0 dev.em.0.mbuf_alloc_fail: 0 dev.em.0.cluster_alloc_fail: 0 dev.em.0.dropped: 0 dev.em.0.tx_dma_fail: 0 dev.em.0.rx_overruns: 0 dev.em.0.watchdog_timeouts: 0 dev.em.0.device_control: 1074790984 dev.em.0.rx_control: 67141634 dev.em.0.fc_high_water: 18432 dev.em.0.fc_low_water: 16932 dev.em.0.queue0.txd_head: 400 dev.em.0.queue0.txd_tail: 400 dev.em.0.queue0.tx_irq: 1835 dev.em.0.queue0.no_desc_avail: 0 dev.em.0.queue0.rxd_head: 331 dev.em.0.queue0.rxd_tail: 273 dev.em.0.queue0.rx_irq: 1392 dev.em.0.mac_stats.excess_coll: 0 dev.em.0.mac_stats.single_coll: 0 dev.em.0.mac_stats.multiple_coll: 0 dev.em.0.mac_stats.late_coll: 0 dev.em.0.mac_stats.collision_count: 0 dev.em.0.mac_stats.symbol_errors: 0 dev.em.0.mac_stats.sequence_errors: 0 dev.em.0.mac_stats.defer_count: 0 dev.em.0.mac_stats.missed_packets: 0 dev.em.0.mac_stats.recv_no_buff: 0 dev.em.0.mac_stats.recv_undersize: 0 dev.em.0.mac_stats.recv_fragmented: 0 dev.em.0.mac_stats.recv_oversize: 0 dev.em.0.mac_stats.recv_jabber: 0 dev.em.0.mac_stats.recv_errs: 0 dev.em.0.mac_stats.crc_errs: 0 dev.em.0.mac_stats.alignment_errs: 0 dev.em.0.mac_stats.coll_ext_errs: 0 dev.em.0.mac_stats.xon_recvd: 0 dev.em.0.mac_stats.xon_txd: 0 dev.em.0.mac_stats.xoff_recvd: 0 dev.em.0.mac_stats.xoff_txd: 0 dev.em.0.mac_stats.total_pkts_recvd: 6475 dev.em.0.mac_stats.good_pkts_recvd: 6475 dev.em.0.mac_stats.bcast_pkts_recvd: 3 dev.em.0.mac_stats.mcast_pkts_recvd: 1 dev.em.0.mac_stats.rx_frames_64: 4 dev.em.0.mac_stats.rx_frames_65_127: 220 dev.em.0.mac_stats.rx_frames_128_255: 12 dev.em.0.mac_stats.rx_frames_256_511: 17 dev.em.0.mac_stats.rx_frames_512_1023: 907 dev.em.0.mac_stats.rx_frames_1024_1522: 5315 dev.em.0.mac_stats.good_octets_recvd: 8963959 dev.em.0.mac_stats.good_octets_txd: 331463 dev.em.0.mac_stats.total_pkts_txd: 4297 dev.em.0.mac_stats.good_pkts_txd: 4297 dev.em.0.mac_stats.bcast_pkts_txd: 4 dev.em.0.mac_stats.mcast_pkts_txd: 0 dev.em.0.mac_stats.tx_frames_64: 4 dev.em.0.mac_stats.tx_frames_65_127: 4146 dev.em.0.mac_stats.tx_frames_128_255: 122 dev.em.0.mac_stats.tx_frames_256_511: 18 dev.em.0.mac_stats.tx_frames_512_1023: 1 dev.em.0.mac_stats.tx_frames_1024_1522: 6 dev.em.0.mac_stats.tso_txd: 0 dev.em.0.mac_stats.tso_ctx_fail: 0 dev.em.0.interrupts.asserts: 3 dev.em.0.interrupts.rx_pkt_timer: 0 dev.em.0.interrupts.rx_abs_timer: 0 dev.em.0.interrupts.tx_pkt_timer: 0 dev.em.0.interrupts.tx_abs_timer: 0 dev.em.0.interrupts.tx_queue_empty: 0 dev.em.0.interrupts.tx_queue_min_thresh: 0 dev.em.0.interrupts.rx_desc_min_thresh: 0 dev.em.0.interrupts.rx_overrun: 0 #=20 Any help ? --tUz0VHt16N2FDcQT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk+AQwoACgkQC3+MBN1Mb4gPygCfYnbGWH8nKI164thCu9zdxkSI KRgAn0sCUdMObv1yjy/elnNpDMrit89s =a/qn -----END PGP SIGNATURE----- --tUz0VHt16N2FDcQT-- From owner-freebsd-net@FreeBSD.ORG Sat Apr 7 20:34:42 2012 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 079001065673; Sat, 7 Apr 2012 20:34:42 +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 D037B8FC0C; Sat, 7 Apr 2012 20:34:41 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q37KYfpp021408; Sat, 7 Apr 2012 20:34:41 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q37KYf7B021404; Sat, 7 Apr 2012 20:34:41 GMT (envelope-from linimon) Date: Sat, 7 Apr 2012 20:34:41 GMT Message-Id: <201204072034.q37KYf7B021404@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/166724: [re] if_re watchdog timeout 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, 07 Apr 2012 20:34:42 -0000 Old Synopsis: if_re watchdog timeout New Synopsis: [re] if_re watchdog timeout Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Apr 7 20:34:20 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=166724 From owner-freebsd-net@FreeBSD.ORG Sat Apr 7 20:36:31 2012 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 B38951065670; Sat, 7 Apr 2012 20:36:31 +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 873368FC08; Sat, 7 Apr 2012 20:36:31 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q37KaVm7021916; Sat, 7 Apr 2012 20:36:31 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q37KaVMd021912; Sat, 7 Apr 2012 20:36:31 GMT (envelope-from linimon) Date: Sat, 7 Apr 2012 20:36:31 GMT Message-Id: <201204072036.q37KaVMd021912@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/166727: [msk] msk driver keeps erroring 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, 07 Apr 2012 20:36:31 -0000 Synopsis: [msk] msk driver keeps erroring Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Apr 7 20:36:24 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=166727 From owner-freebsd-net@FreeBSD.ORG Sat Apr 7 22:06:45 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9E0E8106564A; Sat, 7 Apr 2012 22:06:45 +0000 (UTC) (envelope-from nitroboost@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 45D7D8FC12; Sat, 7 Apr 2012 22:06:45 +0000 (UTC) Received: by obbwc18 with SMTP id wc18so5854066obb.13 for ; Sat, 07 Apr 2012 15:06:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TDvb5evkzNhRO2VK20OwHI26A3j9LXj+Ix8swXrAJxw=; b=Woc7fLaoQHl7MaorkA91bjtBlaJTi7YYXhCHPbmsshYTUZuw0TAFOnuB8zm11HgvxU ylFMytJKqLPk//IUTHn33XErzatCK7lkZQPWFjS9/MeGGEueeThSDUvJQTBHfbFlu/S9 1DSAAVXU8rzUrQYKXUC77ppjbVxP2c06DbCcm8Jek0ztw2MjTl9Ahh5imXoBLA6esZcJ jpNgmCEo40SEIbOpBFn5uj1Dbqn4nIouiQd7ZmM+KR/8+48bd0VBwAtHibXoG895MvSk MkrETyDy9liuHl9P4vMyw1e9qSr/n02VxLSl0XMCXHU47c3P/JOyyF/JGcl3v5lWevZV YelQ== MIME-Version: 1.0 Received: by 10.60.14.226 with SMTP id s2mr3501254oec.29.1333836399212; Sat, 07 Apr 2012 15:06:39 -0700 (PDT) Received: by 10.182.89.33 with HTTP; Sat, 7 Apr 2012 15:06:38 -0700 (PDT) In-Reply-To: <20120407133715.GU2358@deviant.kiev.zoral.com.ua> References: <20120407133715.GU2358@deviant.kiev.zoral.com.ua> Date: Sat, 7 Apr 2012 15:06:38 -0700 Message-ID: From: Jason Wolfe To: Konstantin Belousov Content-Type: multipart/mixed; boundary=e89a8fb1f9c4c3774204bd1dfc0a Cc: jfv@freebsd.org, jhb@freebsd.org, net@freebsd.org Subject: Re: 82574L hangs (with r233708 e1000 driver). 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, 07 Apr 2012 22:06:45 -0000 --e89a8fb1f9c4c3774204bd1dfc0a Content-Type: text/plain; charset=ISO-8859-1 On Sat, Apr 7, 2012 at 6:37 AM, Konstantin Belousov wrote: > I bought Intel Atom motherboard DN2800MT, which has integrated if_em > LOM, reported by pciconf as > em0@pci0:1:0:0: class=0x020000 card=0x20128086 chip=0x10d38086 rev=0x00 hdr=0x00 > 82574L Gigabit Network Connection > It seems that any non-trivial network activity on the interface causes > reliable interface hang, which can be temporary cured by ifconfig down/up. > This happens both with outdated stable/9 sys/dev/e1000 and with driver > from HEAD merged into stable/9. I currently use the copy of dev/e1000 > at rev. r233708. Disabling MSI-X makes the hand to occur slightly less > often. > > I can reproduce the hang in approximately a minute by scp'ing large > file from other machine to /dev/null on the DN2800MT. This makes the > board completely unusable for me. > > The driver reports itself as > em0: port 0x2000-0x201f mem 0xc0400000-0xc041ffff,0xc0000000-0xc03fffff,0xc0420000-0xc0423fff irq 16 at device 0.0 on pci1 > em0: attempting to allocate 3 MSI-X vectors (5 supported) > msi: routing MSI-X IRQ 258 to local APIC 0 vector 60 > msi: routing MSI-X IRQ 259 to local APIC 0 vector 61 > msi: routing MSI-X IRQ 260 to local APIC 0 vector 62 > em0: using IRQs 258-260 for MSI-X > em0: Using MSIX interrupts with 3 vectors > em0: bpf attached > em0: Ethernet address: 00:22:4d:7a:47:f6 > em0: Link is up 1000 Mbps Full Duplex > > The board is connected to ProCurve switch, there is no link flaps. > > When hang occur, dmesg output of # sysctl dev.em.0.debug=1 > dev.em.0.debug: Interface is RUNNING and ACTIVE > em0: hw tdh = 357, hw tdt = 357 > em0: hw rdh = 323, hw rdt = 273 > em0: Tx Queue Status = 0 > em0: TX descriptors avail = 1024 > em0: Tx Descriptors avail failure = 0 > em0: RX discarded packets = 0 > em0: RX Next to Check = 274 > em0: RX Next to Refresh = 273 > > [..snip..] > Any help ? Konstantin, It doesn't appear to be the exact issue I was seeing, but here is a patch that did resolve issues with my 82574L buffers filling and requiring a down/up to recover. It was the result of the 'Intel 82574L interface wedging - em7.3.2/8.2-STABLE' if you'd like to peruse that. Jason --e89a8fb1f9c4c3774204bd1dfc0a Content-Type: application/octet-stream; name="if_em7.2.3_fix.diff" Content-Disposition: attachment; filename="if_em7.2.3_fix.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h0r7pw0x2 ZGlmZiAtcnVOIHNyYy5zdG9jay9zeXMvZGV2L2UxMDAwL2lmX2VtLmMgc3JjL3N5cy9kZXYvZTEw MDAvaWZfZW0uYwotLS0gc3JjLnN0b2NrL3N5cy9kZXYvZTEwMDAvaWZfZW0uYwkyMDEyLTAxLTMx IDE1OjQ3OjEwLjAwMDAwMDAwMCAtMDcwMAorKysgc3JjL3N5cy9kZXYvZTEwMDAvaWZfZW0uYwky MDEyLTAzLTE4IDIzOjA4OjAzLjAwMDAwMDAwMCAtMDcwMApAQCAtMTkzLDEzICsxOTMsMTQgQEAK IHN0YXRpYyBpbnQJZW1fc2h1dGRvd24oZGV2aWNlX3QpOwogc3RhdGljIGludAllbV9zdXNwZW5k KGRldmljZV90KTsKIHN0YXRpYyBpbnQJZW1fcmVzdW1lKGRldmljZV90KTsKLXN0YXRpYyB2b2lk CWVtX3N0YXJ0KHN0cnVjdCBpZm5ldCAqKTsKLXN0YXRpYyB2b2lkCWVtX3N0YXJ0X2xvY2tlZChz dHJ1Y3QgaWZuZXQgKiwgc3RydWN0IHR4X3JpbmcgKik7CiAjaWZkZWYgRU1fTVVMVElRVUVVRQog c3RhdGljIGludAllbV9tcV9zdGFydChzdHJ1Y3QgaWZuZXQgKiwgc3RydWN0IG1idWYgKik7CiBz dGF0aWMgaW50CWVtX21xX3N0YXJ0X2xvY2tlZChzdHJ1Y3QgaWZuZXQgKiwKIAkJICAgIHN0cnVj dCB0eF9yaW5nICosIHN0cnVjdCBtYnVmICopOwogc3RhdGljIHZvaWQJZW1fcWZsdXNoKHN0cnVj dCBpZm5ldCAqKTsKKyNlbHNlCitzdGF0aWMgdm9pZAllbV9zdGFydChzdHJ1Y3QgaWZuZXQgKik7 CitzdGF0aWMgdm9pZAllbV9zdGFydF9sb2NrZWQoc3RydWN0IGlmbmV0ICosIHN0cnVjdCB0eF9y aW5nICopOwogI2VuZGlmCiBzdGF0aWMgaW50CWVtX2lvY3RsKHN0cnVjdCBpZm5ldCAqLCB1X2xv bmcsIGNhZGRyX3QpOwogc3RhdGljIHZvaWQJZW1faW5pdCh2b2lkICopOwpAQCAtMjM0LDcgKzIz NSw3IEBACiBzdGF0aWMgdm9pZAllbV9kaXNhYmxlX2ludHIoc3RydWN0IGFkYXB0ZXIgKik7CiBz dGF0aWMgdm9pZAllbV91cGRhdGVfc3RhdHNfY291bnRlcnMoc3RydWN0IGFkYXB0ZXIgKik7CiBz dGF0aWMgdm9pZAllbV9hZGRfaHdfc3RhdHMoc3RydWN0IGFkYXB0ZXIgKmFkYXB0ZXIpOwotc3Rh dGljIGJvb2wJZW1fdHhlb2Yoc3RydWN0IHR4X3JpbmcgKik7CitzdGF0aWMgdm9pZAllbV90eGVv ZihzdHJ1Y3QgdHhfcmluZyAqKTsKIHN0YXRpYyBib29sCWVtX3J4ZW9mKHN0cnVjdCByeF9yaW5n ICosIGludCwgaW50ICopOwogI2lmbmRlZiBfX05PX1NUUklDVF9BTElHTk1FTlQKIHN0YXRpYyBp bnQJZW1fZml4dXBfcngoc3RydWN0IHJ4X3JpbmcgKik7CkBAIC04MzYsNiArODM3LDcgQEAKIGVt X3Jlc3VtZShkZXZpY2VfdCBkZXYpCiB7CiAJc3RydWN0IGFkYXB0ZXIgKmFkYXB0ZXIgPSBkZXZp Y2VfZ2V0X3NvZnRjKGRldik7CisJc3RydWN0IHR4X3JpbmcJKnR4ciA9IGFkYXB0ZXItPnR4X3Jp bmdzOwogCXN0cnVjdCBpZm5ldCAqaWZwID0gYWRhcHRlci0+aWZwOwogCiAJRU1fQ09SRV9MT0NL KGFkYXB0ZXIpOwpAQCAtODQzLDggKzg0NSwyMiBAQAogCQllMTAwMF9yZXN1bWVfd29ya2Fyb3Vu ZHNfcGNobGFuKCZhZGFwdGVyLT5odyk7CiAJZW1faW5pdF9sb2NrZWQoYWRhcHRlcik7CiAJZW1f aW5pdF9tYW5hZ2VhYmlsaXR5KGFkYXB0ZXIpOworCisJaWYgKChpZnAtPmlmX2ZsYWdzICYgSUZG X1VQKSAmJgorCSAgICAoaWZwLT5pZl9kcnZfZmxhZ3MgJiBJRkZfRFJWX1JVTk5JTkcpICYmIGFk YXB0ZXItPmxpbmtfYWN0aXZlKSB7CisJCWZvciAoaW50IGkgPSAwOyBpIDwgYWRhcHRlci0+bnVt X3F1ZXVlczsgaSsrLCB0eHIrKykgeworCQkJRU1fVFhfTE9DSyh0eHIpOworI2lmZGVmIEVNX01V TFRJUVVFVUUKKwkJCWlmICghZHJicl9lbXB0eShpZnAsIHR4ci0+YnIpKQorCQkJCWVtX21xX3N0 YXJ0X2xvY2tlZChpZnAsIHR4ciwgTlVMTCk7CisjZWxzZQorCQkJaWYgKCFJRlFfRFJWX0lTX0VN UFRZKCZpZnAtPmlmX3NuZCkpCisJCQkJZW1fc3RhcnRfbG9ja2VkKGlmcCwgdHhyKTsKKyNlbmRp ZgorCQkJRU1fVFhfVU5MT0NLKHR4cik7CisJCX0KKwl9CiAJRU1fQ09SRV9VTkxPQ0soYWRhcHRl cik7Ci0JZW1fc3RhcnQoaWZwKTsKIAogCXJldHVybiBidXNfZ2VuZXJpY19yZXN1bWUoZGV2KTsK IH0KQEAgLTk0OCw3ICs5NjQsNyBAQAogCX0KIAlpZl9xZmx1c2goaWZwKTsKIH0KLSNlbmRpZiAv KiBFTV9NVUxUSVFVRVVFICovCisjZWxzZSAgLyogIUVNX01VTFRJUVVFVUUgKi8KIAogc3RhdGlj IHZvaWQKIGVtX3N0YXJ0X2xvY2tlZChzdHJ1Y3QgaWZuZXQgKmlmcCwgc3RydWN0IHR4X3Jpbmcg KnR4cikKQEAgLTEwMDksMTQgKzEwMjUsOSBAQAogCQllbV9zdGFydF9sb2NrZWQoaWZwLCB0eHIp OwogCQlFTV9UWF9VTkxPQ0sodHhyKTsKIAl9Ci0JLyoKLQkqKiBJZiB3ZSB3ZW50IGluYWN0aXZl IHNjaGVkdWxlCi0JKiogYSB0YXNrIHRvIGNsZWFuIHVwLgotCSovCi0JaWYgKGlmcC0+aWZfZHJ2 X2ZsYWdzICYgSUZGX0RSVl9PQUNUSVZFKQotCQl0YXNrcXVldWVfZW5xdWV1ZSh0eHItPnRxLCAm dHhyLT50eF90YXNrKTsKIAlyZXR1cm47CiB9CisjZW5kaWYgLyogRU1fTVVMVElRVUVVRSAqLwog CiAvKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqCiAgKiAgSW9jdGwgZW50cnkgcG9pbnQKQEAgLTE0MTMsNyArMTQyNCw4 IEBACiAJaWYgKCFkcmJyX2VtcHR5KGlmcCwgdHhyLT5icikpCiAJCWVtX21xX3N0YXJ0X2xvY2tl ZChpZnAsIHR4ciwgTlVMTCk7CiAjZWxzZQotCWVtX3N0YXJ0X2xvY2tlZChpZnAsIHR4cik7CisJ aWYgKCFJRlFfRFJWX0lTX0VNUFRZKCZpZnAtPmlmX3NuZCkpCisJCWVtX3N0YXJ0X2xvY2tlZChp ZnAsIHR4cik7CiAjZW5kaWYKIAlFTV9UWF9VTkxPQ0sodHhyKTsKIApAQCAtMTQ4NiwxMCArMTQ5 OCwxMSBAQAogCQlpZiAoIWRyYnJfZW1wdHkoaWZwLCB0eHItPmJyKSkKIAkJCWVtX21xX3N0YXJ0 X2xvY2tlZChpZnAsIHR4ciwgTlVMTCk7CiAjZWxzZQotCQllbV9zdGFydF9sb2NrZWQoaWZwLCB0 eHIpOworCQlpZiAoIUlGUV9EUlZfSVNfRU1QVFkoJmlmcC0+aWZfc25kKSkKKwkJCWVtX3N0YXJ0 X2xvY2tlZChpZnAsIHR4cik7CiAjZW5kaWYKIAkJRU1fVFhfVU5MT0NLKHR4cik7Ci0JCWlmICht b3JlIHx8IChpZnAtPmlmX2Rydl9mbGFncyAmIElGRl9EUlZfT0FDVElWRSkpIHsKKwkJaWYgKG1v cmUpIHsKIAkJCXRhc2txdWV1ZV9lbnF1ZXVlKGFkYXB0ZXItPnRxLCAmYWRhcHRlci0+cXVlX3Rh c2spOwogCQkJcmV0dXJuOwogCQl9CkBAIC0xNTEwLDE3ICsxNTIzLDIxIEBACiB7CiAJc3RydWN0 IHR4X3JpbmcgKnR4ciA9IGFyZzsKIAlzdHJ1Y3QgYWRhcHRlciAqYWRhcHRlciA9IHR4ci0+YWRh cHRlcjsKLQlib29sCQltb3JlOworCXN0cnVjdCBpZm5ldAkqaWZwID0gYWRhcHRlci0+aWZwOwog CiAJKyt0eHItPnR4X2lycTsKIAlFTV9UWF9MT0NLKHR4cik7Ci0JbW9yZSA9IGVtX3R4ZW9mKHR4 cik7CisJZW1fdHhlb2YodHhyKTsKKyNpZmRlZiBFTV9NVUxUSVFVRVVFCisJaWYgKCFkcmJyX2Vt cHR5KGlmcCwgdHhyLT5icikpCisJCWVtX21xX3N0YXJ0X2xvY2tlZChpZnAsIHR4ciwgTlVMTCk7 CisjZWxzZQorCWlmICghSUZRX0RSVl9JU19FTVBUWSgmaWZwLT5pZl9zbmQpKQorCQllbV9zdGFy dF9sb2NrZWQoaWZwLCB0eHIpOworI2VuZGlmCisJLyogUmVlbmFibGUgdGhpcyBpbnRlcnJ1cHQg Ki8KKwlFMTAwMF9XUklURV9SRUcoJmFkYXB0ZXItPmh3LCBFMTAwMF9JTVMsIHR4ci0+aW1zKTsK IAlFTV9UWF9VTkxPQ0sodHhyKTsKLQlpZiAobW9yZSkKLQkJdGFza3F1ZXVlX2VucXVldWUodHhy LT50cSwgJnR4ci0+dHhfdGFzayk7Ci0JZWxzZQotCQkvKiBSZWVuYWJsZSB0aGlzIGludGVycnVw dCAqLwotCQlFMTAwMF9XUklURV9SRUcoJmFkYXB0ZXItPmh3LCBFMTAwMF9JTVMsIHR4ci0+aW1z KTsKIAlyZXR1cm47CiB9CiAKQEAgLTE1OTgsNyArMTYxNSw4IEBACiAJaWYgKCFkcmJyX2VtcHR5 KGlmcCwgdHhyLT5icikpCiAJCWVtX21xX3N0YXJ0X2xvY2tlZChpZnAsIHR4ciwgTlVMTCk7CiAj ZWxzZQotCWVtX3N0YXJ0X2xvY2tlZChpZnAsIHR4cik7CisJaWYgKCFJRlFfRFJWX0lTX0VNUFRZ KCZpZnAtPmlmX3NuZCkpCisJCWVtX3N0YXJ0X2xvY2tlZChpZnAsIHR4cik7CiAjZW5kaWYKIAlF MTAwMF9XUklURV9SRUcoJmFkYXB0ZXItPmh3LCBFMTAwMF9JTVMsIHR4ci0+aW1zKTsKIAlFTV9U WF9VTkxPQ0sodHhyKTsKQEAgLTE2MDgsNiArMTYyNiw3IEBACiBlbV9oYW5kbGVfbGluayh2b2lk ICpjb250ZXh0LCBpbnQgcGVuZGluZykKIHsKIAlzdHJ1Y3QgYWRhcHRlcgkqYWRhcHRlciA9IGNv bnRleHQ7CisJc3RydWN0IHR4X3JpbmcJKnR4ciA9IGFkYXB0ZXItPnR4X3JpbmdzOwogCXN0cnVj dCBpZm5ldCAqaWZwID0gYWRhcHRlci0+aWZwOwogCiAJaWYgKCEoaWZwLT5pZl9kcnZfZmxhZ3Mg JiBJRkZfRFJWX1JVTk5JTkcpKQpAQCAtMTYxOSw2ICsxNjM4LDE5IEBACiAJY2FsbG91dF9yZXNl dCgmYWRhcHRlci0+dGltZXIsIGh6LCBlbV9sb2NhbF90aW1lciwgYWRhcHRlcik7CiAJRTEwMDBf V1JJVEVfUkVHKCZhZGFwdGVyLT5odywgRTEwMDBfSU1TLAogCSAgICBFTV9NU0lYX0xJTksgfCBF MTAwMF9JTVNfTFNDKTsKKwlpZiAoYWRhcHRlci0+bGlua19hY3RpdmUpIHsKKwkJZm9yIChpbnQg aSA9IDA7IGkgPCBhZGFwdGVyLT5udW1fcXVldWVzOyBpKyssIHR4cisrKSB7CisJCQlFTV9UWF9M T0NLKHR4cik7CisjaWZkZWYgRU1fTVVMVElRVUVVRQorCQkJaWYgKCFkcmJyX2VtcHR5KGlmcCwg dHhyLT5icikpCisJCQkJZW1fbXFfc3RhcnRfbG9ja2VkKGlmcCwgdHhyLCBOVUxMKTsKKyNlbHNl CisJCQlpZiAoIUlGUV9EUlZfSVNfRU1QVFkoJmlmcC0+aWZfc25kKSkKKwkJCQllbV9zdGFydF9s b2NrZWQoaWZwLCB0eHIpOworI2VuZGlmCisJCQlFTV9UWF9VTkxPQ0sodHhyKTsKKwkJfQorCX0K IAlFTV9DT1JFX1VOTE9DSyhhZGFwdGVyKTsKIH0KIApAQCAtMjg5MSwyMCArMjkyMywyMSBAQAog CWlmcC0+aWZfc29mdGMgPSBhZGFwdGVyOwogCWlmcC0+aWZfZmxhZ3MgPSBJRkZfQlJPQURDQVNU IHwgSUZGX1NJTVBMRVggfCBJRkZfTVVMVElDQVNUOwogCWlmcC0+aWZfaW9jdGwgPSBlbV9pb2N0 bDsKKyNpZmRlZiBFTV9NVUxUSVFVRVVFCisJLyogTXVsdGlxdWV1ZSBzdGFjayBpbnRlcmZhY2Ug Ki8KKwlpZnAtPmlmX3RyYW5zbWl0ID0gZW1fbXFfc3RhcnQ7CisJaWZwLT5pZl9xZmx1c2ggPSBl bV9xZmx1c2g7CisjZWxzZQogCWlmcC0+aWZfc3RhcnQgPSBlbV9zdGFydDsKIAlJRlFfU0VUX01B WExFTigmaWZwLT5pZl9zbmQsIGFkYXB0ZXItPm51bV90eF9kZXNjIC0gMSk7CiAJaWZwLT5pZl9z bmQuaWZxX2Rydl9tYXhsZW4gPSBhZGFwdGVyLT5udW1fdHhfZGVzYyAtIDE7CiAJSUZRX1NFVF9S RUFEWSgmaWZwLT5pZl9zbmQpOworI2VuZGlmCQogCiAJZXRoZXJfaWZhdHRhY2goaWZwLCBhZGFw dGVyLT5ody5tYWMuYWRkcik7CiAKIAlpZnAtPmlmX2NhcGFiaWxpdGllcyA9IGlmcC0+aWZfY2Fw ZW5hYmxlID0gMDsKIAotI2lmZGVmIEVNX01VTFRJUVVFVUUKLQkvKiBNdWx0aXF1ZXVlIHN0YWNr IGludGVyZmFjZSAqLwotCWlmcC0+aWZfdHJhbnNtaXQgPSBlbV9tcV9zdGFydDsKLQlpZnAtPmlm X3FmbHVzaCA9IGVtX3FmbHVzaDsKLSNlbmRpZgkKIAogCWlmcC0+aWZfY2FwYWJpbGl0aWVzIHw9 IElGQ0FQX0hXQ1NVTSB8IElGQ0FQX1ZMQU5fSFdDU1VNOwogCWlmcC0+aWZfY2FwYWJpbGl0aWVz IHw9IElGQ0FQX1RTTzQ7CkBAIC0zNzEwLDcgKzM3NDMsNyBAQAogICogIHR4X2J1ZmZlciBpcyBw dXQgYmFjayBvbiB0aGUgZnJlZSBxdWV1ZS4KICAqCiAgKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKi8KLXN0YXRpYyBi b29sCitzdGF0aWMgdm9pZAogZW1fdHhlb2Yoc3RydWN0IHR4X3JpbmcgKnR4cikKIHsKIAlzdHJ1 Y3QgYWRhcHRlcgkqYWRhcHRlciA9IHR4ci0+YWRhcHRlcjsKQEAgLTM3MjQsNyArMzc1Nyw3IEBA CiAJLyogTm8gd29yaywgbWFrZSBzdXJlIHdhdGNoZG9nIGlzIG9mZiAqLwogICAgICAgICBpZiAo dHhyLT50eF9hdmFpbCA9PSBhZGFwdGVyLT5udW1fdHhfZGVzYykgewogCQl0eHItPnF1ZXVlX3N0 YXR1cyA9IEVNX1FVRVVFX0lETEU7Ci0gICAgICAgICAgICAgICAgcmV0dXJuIChGQUxTRSk7Cisg ICAgICAgICAgICAgICAgcmV0dXJuOwogCX0KIAogCXByb2Nlc3NlZCA9IDA7CkBAIC0zODEzLDEw ICszODQ2LDcgQEAKIAkvKiBEaXNhYmxlIHdhdGNoZG9nIGlmIGFsbCBjbGVhbiAqLwogCWlmICh0 eHItPnR4X2F2YWlsID09IGFkYXB0ZXItPm51bV90eF9kZXNjKSB7CiAJCXR4ci0+cXVldWVfc3Rh dHVzID0gRU1fUVVFVUVfSURMRTsKLQkJcmV0dXJuIChGQUxTRSk7CiAJfSAKLQotCXJldHVybiAo VFJVRSk7CiB9CiAKIApkaWZmIC1ydU4gc3JjLnN0b2NrL3N5cy9kZXYvZTEwMDAvaWZfaWdiLmMg c3JjL3N5cy9kZXYvZTEwMDAvaWZfaWdiLmMKLS0tIHNyYy5zdG9jay9zeXMvZGV2L2UxMDAwL2lm X2lnYi5jCTIwMTItMDEtMzEgMTU6NDc6MTAuMDAwMDAwMDAwIC0wNzAwCisrKyBzcmMvc3lzL2Rl di9lMTAwMC9pZl9pZ2IuYwkyMDEyLTAzLTE4IDIxOjQ1OjE1LjAwMDAwMDAwMCAtMDcwMApAQCAt MTcxLDEzICsxNzEsMTQgQEAKIHN0YXRpYyBpbnQJaWdiX3NodXRkb3duKGRldmljZV90KTsKIHN0 YXRpYyBpbnQJaWdiX3N1c3BlbmQoZGV2aWNlX3QpOwogc3RhdGljIGludAlpZ2JfcmVzdW1lKGRl dmljZV90KTsKLXN0YXRpYyB2b2lkCWlnYl9zdGFydChzdHJ1Y3QgaWZuZXQgKik7Ci1zdGF0aWMg dm9pZAlpZ2Jfc3RhcnRfbG9ja2VkKHN0cnVjdCB0eF9yaW5nICosIHN0cnVjdCBpZm5ldCAqaWZw KTsKICNpZiBfX0ZyZWVCU0RfdmVyc2lvbiA+PSA4MDAwMDAKIHN0YXRpYyBpbnQJaWdiX21xX3N0 YXJ0KHN0cnVjdCBpZm5ldCAqLCBzdHJ1Y3QgbWJ1ZiAqKTsKIHN0YXRpYyBpbnQJaWdiX21xX3N0 YXJ0X2xvY2tlZChzdHJ1Y3QgaWZuZXQgKiwKIAkJICAgIHN0cnVjdCB0eF9yaW5nICosIHN0cnVj dCBtYnVmICopOwogc3RhdGljIHZvaWQJaWdiX3FmbHVzaChzdHJ1Y3QgaWZuZXQgKik7CisjZWxz ZQorc3RhdGljIHZvaWQJaWdiX3N0YXJ0KHN0cnVjdCBpZm5ldCAqKTsKK3N0YXRpYyB2b2lkCWln Yl9zdGFydF9sb2NrZWQoc3RydWN0IHR4X3JpbmcgKiwgc3RydWN0IGlmbmV0ICppZnApOwogI2Vu ZGlmCiBzdGF0aWMgaW50CWlnYl9pb2N0bChzdHJ1Y3QgaWZuZXQgKiwgdV9sb25nLCBjYWRkcl90 KTsKIHN0YXRpYyB2b2lkCWlnYl9pbml0KHZvaWQgKik7CkBAIC0yNjEsNiArMjYyLDcgQEAKIHN0 YXRpYyB2b2lkCWlnYl9tc2l4X2xpbmsodm9pZCAqKTsKIHN0YXRpYyB2b2lkCWlnYl9oYW5kbGVf cXVlKHZvaWQgKmNvbnRleHQsIGludCBwZW5kaW5nKTsKIHN0YXRpYyB2b2lkCWlnYl9oYW5kbGVf bGluayh2b2lkICpjb250ZXh0LCBpbnQgcGVuZGluZyk7CitzdGF0aWMgdm9pZAlpZ2JfaGFuZGxl X2xpbmtfbG9ja2VkKHN0cnVjdCBhZGFwdGVyICopOwogCiBzdGF0aWMgdm9pZAlpZ2Jfc2V0X3N5 c2N0bF92YWx1ZShzdHJ1Y3QgYWRhcHRlciAqLCBjb25zdCBjaGFyICosCiAJCSAgICBjb25zdCBj aGFyICosIGludCAqLCBpbnQpOwpAQCAtNzk4LDYgKzgwMCw3IEBACiBpZ2JfcmVzdW1lKGRldmlj ZV90IGRldikKIHsKIAlzdHJ1Y3QgYWRhcHRlciAqYWRhcHRlciA9IGRldmljZV9nZXRfc29mdGMo ZGV2KTsKKwlzdHJ1Y3QgdHhfcmluZwkqdHhyID0gYWRhcHRlci0+dHhfcmluZ3M7CiAJc3RydWN0 IGlmbmV0ICppZnAgPSBhZGFwdGVyLT5pZnA7CiAKIAlJR0JfQ09SRV9MT0NLKGFkYXB0ZXIpOwpA QCAtODA1LDkgKzgwOCwyMSBAQAogCWlnYl9pbml0X21hbmFnZWFiaWxpdHkoYWRhcHRlcik7CiAK IAlpZiAoKGlmcC0+aWZfZmxhZ3MgJiBJRkZfVVApICYmCi0JICAgIChpZnAtPmlmX2Rydl9mbGFn cyAmIElGRl9EUlZfUlVOTklORykpCi0JCWlnYl9zdGFydChpZnApOwotCisJICAgIChpZnAtPmlm X2Rydl9mbGFncyAmIElGRl9EUlZfUlVOTklORykgJiYgYWRhcHRlci0+bGlua19hY3RpdmUpIHsK KwkJZm9yIChpbnQgaSA9IDA7IGkgPCBhZGFwdGVyLT5udW1fcXVldWVzOyBpKyssIHR4cisrKSB7 CisJCQlJR0JfVFhfTE9DSyh0eHIpOworI2lmIF9fRnJlZUJTRF92ZXJzaW9uID49IDgwMDAwMAor CQkJLyogUHJvY2VzcyB0aGUgc3RhY2sgcXVldWUgb25seSBpZiBub3QgZGVwbGV0ZWQgKi8KKwkJ CWlmICgoKHR4ci0+cXVldWVfc3RhdHVzICYgSUdCX1FVRVVFX0RFUExFVEVEKSA9PSAwKSAmJgor CQkJICAgICFkcmJyX2VtcHR5KGlmcCwgdHhyLT5icikpCisJCQkJaWdiX21xX3N0YXJ0X2xvY2tl ZChpZnAsIHR4ciwgTlVMTCk7CisjZWxzZQorCQkJaWYgKCFJRlFfRFJWX0lTX0VNUFRZKCZpZnAt PmlmX3NuZCkpCisJCQkJaWdiX3N0YXJ0X2xvY2tlZCh0eHIsIGlmcCk7CisjZW5kaWYKKwkJCUlH Ql9UWF9VTkxPQ0sodHhyKTsKKwkJfQorCX0KIAlJR0JfQ09SRV9VTkxPQ0soYWRhcHRlcik7CiAK IAlyZXR1cm4gYnVzX2dlbmVyaWNfcmVzdW1lKGRldik7CkBAIC0xMzIxLDE5ICsxMzM2LDE5IEBA CiAJCW1vcmUgPSBpZ2Jfcnhlb2YocXVlLCBhZGFwdGVyLT5yeF9wcm9jZXNzX2xpbWl0LCBOVUxM KTsKIAogCQlJR0JfVFhfTE9DSyh0eHIpOwotCQlpZiAoaWdiX3R4ZW9mKHR4cikpCi0JCQltb3Jl ID0gVFJVRTsKKwkJaWdiX3R4ZW9mKHR4cik7CiAjaWYgX19GcmVlQlNEX3ZlcnNpb24gPj0gODAw MDAwCiAJCS8qIFByb2Nlc3MgdGhlIHN0YWNrIHF1ZXVlIG9ubHkgaWYgbm90IGRlcGxldGVkICov CiAJCWlmICgoKHR4ci0+cXVldWVfc3RhdHVzICYgSUdCX1FVRVVFX0RFUExFVEVEKSA9PSAwKSAm JgogCQkgICAgIWRyYnJfZW1wdHkoaWZwLCB0eHItPmJyKSkKIAkJCWlnYl9tcV9zdGFydF9sb2Nr ZWQoaWZwLCB0eHIsIE5VTEwpOwogI2Vsc2UKLQkJaWdiX3N0YXJ0X2xvY2tlZCh0eHIsIGlmcCk7 CisJCWlmICghSUZRX0RSVl9JU19FTVBUWSgmaWZwLT5pZl9zbmQpKQorCQkJaWdiX3N0YXJ0X2xv Y2tlZCh0eHIsIGlmcCk7CiAjZW5kaWYKIAkJSUdCX1RYX1VOTE9DSyh0eHIpOwogCQkvKiBEbyB3 ZSBuZWVkIGFub3RoZXI/ICovCi0JCWlmIChtb3JlIHx8IChpZnAtPmlmX2Rydl9mbGFncyAmIElG Rl9EUlZfT0FDVElWRSkpIHsKKwkJaWYgKG1vcmUpIHsKIAkJCXRhc2txdWV1ZV9lbnF1ZXVlKHF1 ZS0+dHEsICZxdWUtPnF1ZV90YXNrKTsKIAkJCXJldHVybjsKIAkJfQpAQCAtMTM1Niw4ICsxMzcx LDM1IEBACiB7CiAJc3RydWN0IGFkYXB0ZXIgKmFkYXB0ZXIgPSBjb250ZXh0OwogCisJSUdCX0NP UkVfTE9DSyhhZGFwdGVyKTsKKwlpZ2JfaGFuZGxlX2xpbmtfbG9ja2VkKGFkYXB0ZXIpOworCUlH Ql9DT1JFX1VOTE9DSyhhZGFwdGVyKTsKK30KKworc3RhdGljIHZvaWQKK2lnYl9oYW5kbGVfbGlu a19sb2NrZWQoc3RydWN0IGFkYXB0ZXIgKmFkYXB0ZXIpCit7CisJc3RydWN0IHR4X3JpbmcJKnR4 ciA9IGFkYXB0ZXItPnR4X3JpbmdzOworCXN0cnVjdCBpZm5ldCAqaWZwID0gYWRhcHRlci0+aWZw OworCisJSUdCX0NPUkVfTE9DS19BU1NFUlQoYWRhcHRlcik7CiAJYWRhcHRlci0+aHcubWFjLmdl dF9saW5rX3N0YXR1cyA9IDE7CiAJaWdiX3VwZGF0ZV9saW5rX3N0YXR1cyhhZGFwdGVyKTsKKwlp ZiAoKGlmcC0+aWZfZHJ2X2ZsYWdzICYgSUZGX0RSVl9SVU5OSU5HKSAmJiBhZGFwdGVyLT5saW5r X2FjdGl2ZSkgeworCQlmb3IgKGludCBpID0gMDsgaSA8IGFkYXB0ZXItPm51bV9xdWV1ZXM7IGkr KywgdHhyKyspIHsKKwkJCUlHQl9UWF9MT0NLKHR4cik7CisjaWYgX19GcmVlQlNEX3ZlcnNpb24g Pj0gODAwMDAwCisJCQkvKiBQcm9jZXNzIHRoZSBzdGFjayBxdWV1ZSBvbmx5IGlmIG5vdCBkZXBs ZXRlZCAqLworCQkJaWYgKCgodHhyLT5xdWV1ZV9zdGF0dXMgJiBJR0JfUVVFVUVfREVQTEVURUQp ID09IDApICYmCisJCQkgICAgIWRyYnJfZW1wdHkoaWZwLCB0eHItPmJyKSkKKwkJCQlpZ2JfbXFf c3RhcnRfbG9ja2VkKGlmcCwgdHhyLCBOVUxMKTsKKyNlbHNlCisJCQlpZiAoIUlGUV9EUlZfSVNf RU1QVFkoJmlmcC0+aWZfc25kKSkKKwkJCQlpZ2Jfc3RhcnRfbG9ja2VkKHR4ciwgaWZwKTsKKyNl bmRpZgorCQkJSUdCX1RYX1VOTE9DSyh0eHIpOworCQl9CisJfQogfQogCiAvKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq CkBAIC0xNDM3LDcgKzE0NzksNyBAQAogCQlyZWdfaWNyID0gRTEwMDBfUkVBRF9SRUcoJmFkYXB0 ZXItPmh3LCBFMTAwMF9JQ1IpOwogCQkvKiBMaW5rIHN0YXR1cyBjaGFuZ2UgKi8KIAkJaWYgKHJl Z19pY3IgJiAoRTEwMDBfSUNSX1JYU0VRIHwgRTEwMDBfSUNSX0xTQykpCi0JCQlpZ2JfaGFuZGxl X2xpbmsoYWRhcHRlciwgMCk7CisJCQlpZ2JfaGFuZGxlX2xpbmtfbG9ja2VkKGFkYXB0ZXIpOwog CiAJCWlmIChyZWdfaWNyICYgRTEwMDBfSUNSX1JYTykKIAkJCWFkYXB0ZXItPnJ4X292ZXJydW5z Kys7CkBAIC0xNDU0LDcgKzE0OTYsOCBAQAogCWlmICghZHJicl9lbXB0eShpZnAsIHR4ci0+YnIp KQogCQlpZ2JfbXFfc3RhcnRfbG9ja2VkKGlmcCwgdHhyLCBOVUxMKTsKICNlbHNlCi0JaWdiX3N0 YXJ0X2xvY2tlZCh0eHIsIGlmcCk7CisJaWYgKCFJRlFfRFJWX0lTX0VNUFRZKCZpZnAtPmlmX3Nu ZCkpCisJCWlnYl9zdGFydF9sb2NrZWQodHhyLCBpZnApOwogI2VuZGlmCiAJSUdCX1RYX1VOTE9D Syh0eHIpOwogCXJldHVybiBQT0xMX1JFVFVSTl9DT1VOVChyeF9kb25lKTsKQEAgLTE0NzEsMTYg KzE1MTQsMjYgQEAKIHsKIAlzdHJ1Y3QgaWdiX3F1ZXVlICpxdWUgPSBhcmc7CiAJc3RydWN0IGFk YXB0ZXIgKmFkYXB0ZXIgPSBxdWUtPmFkYXB0ZXI7CisJc3RydWN0IGlmbmV0ICAgKmlmcCA9IGFk YXB0ZXItPmlmcDsKIAlzdHJ1Y3QgdHhfcmluZyAqdHhyID0gcXVlLT50eHI7CiAJc3RydWN0IHJ4 X3JpbmcgKnJ4ciA9IHF1ZS0+cnhyOwogCXUzMgkJbmV3aXRyID0gMDsKLQlib29sCQltb3JlX3R4 LCBtb3JlX3J4OworCWJvb2wJCW1vcmVfcng7CiAKIAlFMTAwMF9XUklURV9SRUcoJmFkYXB0ZXIt Pmh3LCBFMTAwMF9FSU1DLCBxdWUtPmVpbXMpOwogCSsrcXVlLT5pcnFzOwogCiAJSUdCX1RYX0xP Q0sodHhyKTsKLQltb3JlX3R4ID0gaWdiX3R4ZW9mKHR4cik7CisJaWdiX3R4ZW9mKHR4cik7Cisj aWYgX19GcmVlQlNEX3ZlcnNpb24gPj0gODAwMDAwCisJLyogUHJvY2VzcyB0aGUgc3RhY2sgcXVl dWUgb25seSBpZiBub3QgZGVwbGV0ZWQgKi8KKwlpZiAoKCh0eHItPnF1ZXVlX3N0YXR1cyAmIElH Ql9RVUVVRV9ERVBMRVRFRCkgPT0gMCkgJiYKKwkgICAgIWRyYnJfZW1wdHkoaWZwLCB0eHItPmJy KSkKKwkJaWdiX21xX3N0YXJ0X2xvY2tlZChpZnAsIHR4ciwgTlVMTCk7CisjZWxzZQorCWlmICgh SUZRX0RSVl9JU19FTVBUWSgmaWZwLT5pZl9zbmQpKQorCQlpZ2Jfc3RhcnRfbG9ja2VkKHR4ciwg aWZwKTsKKyNlbmRpZgogCUlHQl9UWF9VTkxPQ0sodHhyKTsKIAogCW1vcmVfcnggPSBpZ2Jfcnhl b2YocXVlLCBhZGFwdGVyLT5yeF9wcm9jZXNzX2xpbWl0LCBOVUxMKTsKQEAgLTE1MzgsNyArMTU5 MSw3IEBACiAKIG5vX2NhbGM6CiAJLyogU2NoZWR1bGUgYSBjbGVhbiB0YXNrIGlmIG5lZWRlZCov Ci0JaWYgKG1vcmVfdHggfHwgbW9yZV9yeCkKKwlpZiAobW9yZV9yeCkKIAkJdGFza3F1ZXVlX2Vu cXVldWUocXVlLT50cSwgJnF1ZS0+cXVlX3Rhc2spOwogCWVsc2UKIAkJLyogUmVlbmFibGUgdGhp cyBpbnRlcnJ1cHQgKi8K --e89a8fb1f9c4c3774204bd1dfc0a-- From owner-freebsd-net@FreeBSD.ORG Sat Apr 7 23:22:09 2012 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 67E091065675; Sat, 7 Apr 2012 23:22:09 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 94E6E8FC0A; Sat, 7 Apr 2012 23:22:08 +0000 (UTC) Received: by wgbds12 with SMTP id ds12so3141299wgb.31 for ; Sat, 07 Apr 2012 16:22:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2nwHL9CgcXippUgOgu5XXBL9a9DLx+adVWHtDFJtq9M=; b=BkqvK99V6p0a4C9hCP88AZW3k4p9oRCZS9UHRTzfoLwRlNwvxg+W0hrx+ILF9OnTsk OHQqkpmAWGny8/0WLOspqDYi+whk2TJWiLlYCDkBeYWQjFKZ1aH8VGKk9qsvTNIQ1use rTF5XNU6TDrs9QGH/SZkybLk7gc/QB54LbfjNUt1iWY9L/UJrmnn8x7B1wJ1jOGbNmel f1E5Li0yDW5jLpDLL7jdxdU2uQbmZ6t/9uO3UfkoOF4D+qc6gDMKWuT5QFW9x89rF2QA 2A6/2ZpYq6UlJ+TDFQPO8TwVvAJleEP+ZKYrnrywOrJ4d4XNAV0XminsZB92bpvOGgHL J6rw== MIME-Version: 1.0 Received: by 10.216.144.223 with SMTP id n73mr1439295wej.65.1333840927399; Sat, 07 Apr 2012 16:22:07 -0700 (PDT) Received: by 10.180.3.170 with HTTP; Sat, 7 Apr 2012 16:22:07 -0700 (PDT) In-Reply-To: <20120407133715.GU2358@deviant.kiev.zoral.com.ua> References: <20120407133715.GU2358@deviant.kiev.zoral.com.ua> Date: Sat, 7 Apr 2012 16:22:07 -0700 Message-ID: From: Jack Vogel To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: jfv@freebsd.org, jhb@freebsd.org, net@freebsd.org Subject: Re: 82574L hangs (with r233708 e1000 driver). 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, 07 Apr 2012 23:22:09 -0000 Make sure you have any firmware up to the latest available, if that doesn't help let me know and I'll check internally to see if there are any outstanding issues in shared code, that will be after the weekend. Jack On Sat, Apr 7, 2012 at 6:37 AM, Konstantin Belousov wrote: > I bought Intel Atom motherboard DN2800MT, which has integrated if_em > LOM, reported by pciconf as > em0@pci0:1:0:0: class=0x020000 card=0x20128086 chip=0x10d38086 rev=0x00 > hdr=0x00 > 82574L Gigabit Network Connection > It seems that any non-trivial network activity on the interface causes > reliable interface hang, which can be temporary cured by ifconfig down/up. > This happens both with outdated stable/9 sys/dev/e1000 and with driver > from HEAD merged into stable/9. I currently use the copy of dev/e1000 > at rev. r233708. Disabling MSI-X makes the hand to occur slightly less > often. > > I can reproduce the hang in approximately a minute by scp'ing large > file from other machine to /dev/null on the DN2800MT. This makes the > board completely unusable for me. > > The driver reports itself as > em0: port 0x2000-0x201f mem > 0xc0400000-0xc041ffff,0xc0000000-0xc03fffff,0xc0420000-0xc0423fff irq 16 at > device 0.0 on pci1 > em0: attempting to allocate 3 MSI-X vectors (5 supported) > msi: routing MSI-X IRQ 258 to local APIC 0 vector 60 > msi: routing MSI-X IRQ 259 to local APIC 0 vector 61 > msi: routing MSI-X IRQ 260 to local APIC 0 vector 62 > em0: using IRQs 258-260 for MSI-X > em0: Using MSIX interrupts with 3 vectors > em0: bpf attached > em0: Ethernet address: 00:22:4d:7a:47:f6 > em0: Link is up 1000 Mbps Full Duplex > > The board is connected to ProCurve switch, there is no link flaps. > > When hang occur, dmesg output of # sysctl dev.em.0.debug=1 > dev.em.0.debug: Interface is RUNNING and ACTIVE > em0: hw tdh = 357, hw tdt = 357 > em0: hw rdh = 323, hw rdt = 273 > em0: Tx Queue Status = 0 > em0: TX descriptors avail = 1024 > em0: Tx Descriptors avail failure = 0 > em0: RX discarded packets = 0 > em0: RX Next to Check = 274 > em0: RX Next to Refresh = 273 > > and # sysctl dev.em.0 > dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 7.3.2 > dev.em.0.%driver: em > dev.em.0.%location: slot=0 function=0 handle=\_SB_.PCI0.RP01.PXSX > dev.em.0.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x8086 > subdevice=0x2012 class=0x020000 > dev.em.0.%parent: pci1 > dev.em.0.nvm: -1 > dev.em.0.debug: -1 > dev.em.0.fc: 3 > dev.em.0.rx_int_delay: 0 > dev.em.0.tx_int_delay: 66 > dev.em.0.rx_abs_int_delay: 66 > dev.em.0.tx_abs_int_delay: 66 > dev.em.0.rx_processing_limit: 100 > dev.em.0.eee_control: 0 > dev.em.0.link_irq: 0 > dev.em.0.mbuf_alloc_fail: 0 > dev.em.0.cluster_alloc_fail: 0 > dev.em.0.dropped: 0 > dev.em.0.tx_dma_fail: 0 > dev.em.0.rx_overruns: 0 > dev.em.0.watchdog_timeouts: 0 > dev.em.0.device_control: 1074790984 > dev.em.0.rx_control: 67141634 > dev.em.0.fc_high_water: 18432 > dev.em.0.fc_low_water: 16932 > dev.em.0.queue0.txd_head: 400 > dev.em.0.queue0.txd_tail: 400 > dev.em.0.queue0.tx_irq: 1835 > dev.em.0.queue0.no_desc_avail: 0 > dev.em.0.queue0.rxd_head: 331 > dev.em.0.queue0.rxd_tail: 273 > dev.em.0.queue0.rx_irq: 1392 > dev.em.0.mac_stats.excess_coll: 0 > dev.em.0.mac_stats.single_coll: 0 > dev.em.0.mac_stats.multiple_coll: 0 > dev.em.0.mac_stats.late_coll: 0 > dev.em.0.mac_stats.collision_count: 0 > dev.em.0.mac_stats.symbol_errors: 0 > dev.em.0.mac_stats.sequence_errors: 0 > dev.em.0.mac_stats.defer_count: 0 > dev.em.0.mac_stats.missed_packets: 0 > dev.em.0.mac_stats.recv_no_buff: 0 > dev.em.0.mac_stats.recv_undersize: 0 > dev.em.0.mac_stats.recv_fragmented: 0 > dev.em.0.mac_stats.recv_oversize: 0 > dev.em.0.mac_stats.recv_jabber: 0 > dev.em.0.mac_stats.recv_errs: 0 > dev.em.0.mac_stats.crc_errs: 0 > dev.em.0.mac_stats.alignment_errs: 0 > dev.em.0.mac_stats.coll_ext_errs: 0 > dev.em.0.mac_stats.xon_recvd: 0 > dev.em.0.mac_stats.xon_txd: 0 > dev.em.0.mac_stats.xoff_recvd: 0 > dev.em.0.mac_stats.xoff_txd: 0 > dev.em.0.mac_stats.total_pkts_recvd: 6475 > dev.em.0.mac_stats.good_pkts_recvd: 6475 > dev.em.0.mac_stats.bcast_pkts_recvd: 3 > dev.em.0.mac_stats.mcast_pkts_recvd: 1 > dev.em.0.mac_stats.rx_frames_64: 4 > dev.em.0.mac_stats.rx_frames_65_127: 220 > dev.em.0.mac_stats.rx_frames_128_255: 12 > dev.em.0.mac_stats.rx_frames_256_511: 17 > dev.em.0.mac_stats.rx_frames_512_1023: 907 > dev.em.0.mac_stats.rx_frames_1024_1522: 5315 > dev.em.0.mac_stats.good_octets_recvd: 8963959 > dev.em.0.mac_stats.good_octets_txd: 331463 > dev.em.0.mac_stats.total_pkts_txd: 4297 > dev.em.0.mac_stats.good_pkts_txd: 4297 > dev.em.0.mac_stats.bcast_pkts_txd: 4 > dev.em.0.mac_stats.mcast_pkts_txd: 0 > dev.em.0.mac_stats.tx_frames_64: 4 > dev.em.0.mac_stats.tx_frames_65_127: 4146 > dev.em.0.mac_stats.tx_frames_128_255: 122 > dev.em.0.mac_stats.tx_frames_256_511: 18 > dev.em.0.mac_stats.tx_frames_512_1023: 1 > dev.em.0.mac_stats.tx_frames_1024_1522: 6 > dev.em.0.mac_stats.tso_txd: 0 > dev.em.0.mac_stats.tso_ctx_fail: 0 > dev.em.0.interrupts.asserts: 3 > dev.em.0.interrupts.rx_pkt_timer: 0 > dev.em.0.interrupts.rx_abs_timer: 0 > dev.em.0.interrupts.tx_pkt_timer: 0 > dev.em.0.interrupts.tx_abs_timer: 0 > dev.em.0.interrupts.tx_queue_empty: 0 > dev.em.0.interrupts.tx_queue_min_thresh: 0 > dev.em.0.interrupts.rx_desc_min_thresh: 0 > dev.em.0.interrupts.rx_overrun: 0 > # > > Any help ? >